Done. RESTServer part of the task is obsolete.
Tue, May 22
Fri, May 18
Wed, May 16
Tue, May 8
"Is camera link just lvds?
What are the implications, requirements?"
Mon, May 7
Sat, May 5
It looks really cool!
Wed, May 2
someone doing something very similar: http://www.bmcuser.com/showthread.php?21668
Apr 26 2018
Apr 25 2018
Apr 21 2018
Use HTML email validator for that, as normal one is very picky, but not everything is allowed in the emails, see GMail docs for example: https://developers.google.com/gmail/design/reference/supported_css
Apr 20 2018
Done, build passes after adjustments. Needs maybe some meaningful tests at the end, but for this new task should be created.
Apr 19 2018
Resolved with merge of PR [https://github.com/apertus-open-source-cinema/opencine/pull/38]
Apr 17 2018
The main focus will be on I2C, SPI and GPIO signals, where the latter ones should have predictable delays because they might control timing sensitive signals (exposure control, trigger, etc). There is no need to handle large bandwidth or complex communication like AMBA here.
Balance of generality and simplicity is essential and I recommend glancing at PCIe TLP packages.
Possibly a much-simplified version of this would work here.
Apr 16 2018
@Gookfilm how do you want to connect the handle to the body electronically?
an example from zacuto https://www.zacuto.com/control-grip
arduino lanc controller
Apr 15 2018
Created new footer as replacement for phplist one, see general newsletter thread for info.
Added hyperlink to logo, adjusted "here" URL.
Apr 14 2018
Apr 13 2018
Add a PR for the task, completed at: https://github.com/apertus-open-source-cinema/opencine/pull/38. Kindly pull and resolve.
Apr 12 2018
Edited the new links.
Apr 11 2018
Looks good, I just added the https://github.com/apertus-open-source-cinema/pcb-aoi repo to phabricator
turn apertus.org logo into link to www.apertus.org ?
Apr 10 2018
Finally restored the page again, not pretty, but fiducial search is working and the image is unwarped.
Apr 9 2018
This link is open for all
Cannot open it without logging in or subscription.
This is the paper that demosaics/ interpolates the pixel as well as preserve the edge information.:
Apr 5 2018
It'll do for the first month.
Apr 4 2018
These seems super interesting, I see it as a potential tool to help tweaking the color science of the camera.
Apr 2 2018
Duplicate to T989
Mar 30 2018
this electronic controlled ND filter built in would be the perfect solution for two reasons:
Mar 22 2018
Awesome, that's perfect!
Scrolling back, I noticed you said ‘cool idea’ about the extra bottom hole a while back. It didn’t make it into the current revision though.
Snap, totally forgot about the Compact Shell! Which is kind of a cage, I guess. And cages are... You need to buy a cage or extra rails for more mounting points with every new camera you buy these days. It would be great if cameras had all the mounting points themselves. Saves both weight and money.
And maybe add an extra 1/4” hole on the bottom end of the camera, right underneath the 1/4” hole on the right hand side while you’re at it. A rail there could allow my wooden side handle to be attached.
Thanks guys. For the camera to work without a cage, I really need at least two 1/4” holes on either side, vertically aligned. So the right hand side has got that covered, the left hand side doesn’t. One extra hole down below would allow a Nato rail to be attached and then we’d be home free.
Mar 21 2018
Mar 20 2018
Mar 17 2018
Mar 16 2018
Mar 14 2018
perhaps we should change the title of this thread - or move it to "websockets" REST doesn't seem to make sense anymore...
Mar 13 2018
Mar 12 2018
I am not worried about the display of these values in realtime using a Vue value store (modified by websocket information). I think we could get to 30fps with less than 100ms latency - if the hist3 can pump the info out that fast - and still manage the wifi and the websockets...
I would also suggest we try decimating the histogram number of samples and bitdepth drastically and try sending multiple measurements per second, after all as filmmaker you are not interested in details of the spikes, rather see a general value distribution and how it changes when opening or closing a lens aperture for example. I guess test gpu acceleration on smartphones for drawing these could be worth a try.
Ok - I see. Then the interface will also need to show a folder list (with preview / editing options and perhaps metadata viewer - respective to data type.) Do you also expect / hope to send whitelisted commands via some kind of mock-shell?
Wow - I didn't know that that was one of the deliverables.
It isn't currently (well the camera can capture pictures of course - but not serve them over http yet) but could be useful in the future.
Wow - I didn't know that that was one of the deliverables. What do you mean by "etc."? Yes, we can serve from any folder. We would need to investigate the possibility of sym-linking a "DCIM" type of folder, but there isn't any real reason why it shouldn't work.
Can we also easily serve files (like images, etc.) from the camera internal linux user space to clients without lighttp (for photography like applications)? If yes then I guess we could consider getting rid of lighttp.
As far as security is concerned, you are probably right sending and receiving flatbuffers. We don’t want DAEMON to unexpectedly crash.
Here is how we could even serve http with libwebsockets, which would help to do the automatic upgrade to ws:// - it is public domain licensed.