First of all; Thanks for the fantastic feedback. This is a huge help!
Hey guys, thanks for releasing the beta software early! Sorry for long post. Bug reports and tips below.
I'm using the camera in an optics lab at a university. RAW is essential; 12 bit packed mode is great! Our lab has some high end scientific high speed cameras that cost at LEAST 30x more than the Chronos. I've done side by side comparisons and the Chronos is really holding its own - great work Dave & co. Next year, I'll write up and share the data. The only thing that lets the camera down right now is the lack of a remote control API via ethernet and a working HDMI output so we can control & view remotely. I'm sure it will come! :-)
If anyone else is planning to put the Chronos 1.4 to scientific use, perhaps we should start a forum page for sharing code, tips, and example videos of cool stuff. I'm hoping to write an ImageJ/Fiji plugin for reading in the raw data next year. For now, I've got a Python program successfully extracting frames from the 12 bit packed format with no trouble. Once I've optimised the code (it's rather slow and lacking comments), I'll put it on Github. Planning to add support for directly reading gzipped raw files so we can have true lossless compression.
I've done a whole lot of playing about with the 0.2.3 beta in the last few days on my monochrome 8 GB model and I've found some interesting bugs and workarounds. Info will follow for those who care. I'm happy to field-test stuff and follow up on bug fixes if it helps.
Awesome to hear you got that working. I only just made the 16bpp translation and was going to tackle the 12bpp packed format in the next bit.
Dan D.
WRITE FILES BIGGER THAN 4GB!
When trying to dump the whole RAM to RAW, the fat32 file size limit of 4GB is a REAL pain. And almost as bad, I can't write past the first 8 GB of fat32 media. I'm going to assume NTFS is out of the question, and exFAT is not supported yet. Since the Chronos is running *nix, I thought I'd take a punt and format my flash drive to ext3 - and it works!! I can now save the FULL ram of the camera (8gb) in a single hit to one file, and to boot I can use the whole size of the drive rather than just the first 8GB! The "above 4GB" warning message will still appear - just acknowledge & continue saving. This is super cool, with two drawbacks. One, mounting ext2/3/4 in windows & mac is a pain - and two, the save speed is roughly half that of fat32.
I'm getting best save performance to a high-end USB 3.0 compatible thumb drive formatted fat32, at about 13 MB/s. It's twice as fast as a '30 MB/s' rated SD card, which seems to only give me about 7 MB/s? Maybe it's not a good card.
The save performance should improve in the future - we've found a rather annoying "feature" of the video pipeline in use in that it does a memcpy to move the frame into kernel space from OMX. This is where all the extra speed that saving to USB or eSATA should be given is being eaten up; the CPU can only move so much data.
It's in the pipeline of things that need to be fixed but probably won't be fixed before the network control features are at least somewhat working.
EXTERNAL SYNC
I've found that if you want to gate the shutter from a TTL signal or at least sync the start of exposure from an external clock, you need to set the internal framerate to be just slightly higher than the incoming signal, otherwise frames can drop. i.e. 1 kHz square wave on BNC cable, camera set at 1000 fps, some frames dropped, but if camera is expecting 1001 fps, no dropped frames. Setting the internal frame rate too high above the external signal can also sometimes cause unreliable sync though.
Good to know detail. We generally use the gating from another camera for testing and of course the timing would always be close enough that it won't cause problems. Another side of this is it's generally a very good idea to change the frame time down on a slave camera before changing the master timing - this would also be true for external signals as we've seen the application crash once every now and then and haven't tracked down why yet - something timing-wise in the FPGA.
BUG REPORTS
i) The eject SD / eject USB in the Util menu are throwing "failed to eject" errors for me every time in v0.2.3. The "safely eject" button in the Play:Settings screen works.
ii) Aborting save of RAW can cause the camera to crash on occasion (it goes to a shutting down screen and hangs)
iii) 12 bit packed RAW files are often truncated a couple frames short of the requested mark out point. Sometimes the files end halfway through a pixel! i.e. record 1000 frames, save all of it to 12 bit packed RAW, saving UI counts up to 1000 and done, and I end up with 991 frames and a bit of the next frame in my file. This is not a file size limit issue as far as I can tell.
iv) When saving, the counter over-runs the mark out point by 5-6 frames. If mark out is at the end of the memory, it will overflow and count back up to 5 or 6. Maybe connected to (iii) or could be aesthetic.
v) Warning about file size being too large for fat32 storage (above 4GB) is wrong when using 12 bit packed format - it shows the error once the file gets above about 3 GB. I think the calculation for the warning is assuming that the file being saved will be 16 bpp?
vi) When the total data saved to a fat32 drive reaches 8 GB, a save error occurs (sure...) but then the playback & live framebuffer displays go green and distorted on the left, and black on the right side, as if the software suddenly thinks my mono camera is a color model and is misinterpreting the data. Putting in a new empty media and redoing the Save causes the problem to go away.
vii) Sometimes when I boot, the camera has suddenly gone into Gated mode (1 frame!). I think this is related to the next bug.
viii) I use the external shutter gate option a lot. If I try and change resolutions and frame rates when this is enabled, bad things happen, which can be any of the following:
- the display stops updating or becomes partially obscured by a block of static
- the camera goes into Gated mode (1 frame) and refuses to accept a change of setting
- camera can get stuck in a permanent recording loop (red led stuck on, record button does nothing)
- camera can refuse to shut down and will still be misbehaving when rebooted!
This did not happen with software v0.2 and is a new bug.
Workaround: turn off external shutter gating before changing frame rates and resolutions. Once settings are good, then switch back to external gating.
When the bad things above happen, turn off external gating and hard reset the camera. I had to actually pull the power cord and battery and hard reboot for the problem to resolve.
Thanks - will check into these details. I'll make note on any that are specific.
iii) I haven't been able to read 12bpp data yet so didn't catch this. Will test and figure out what's causing that. For now it would be a good idea to always record a dozen extra frames. Please let me know if there are any frames missing from what you can tell. One of the other features in the pipe is overlay text and/or embedded data so it'll be easier to catch dropped frames. There should be none at this time based on the tests we've done of the other save modes.
iv) cosmetic if it's not dropping frames - the pipeline is async so may play a few more frames into the cpu-side buffer before everything's shut down. I'll note that to make a quick fix to hold the frame number and position if it's past the end but for now it's useful for seeing if there are dropped frames.
vi) raw recording still uses the 24bit interface by encoding two pixels side by side. In verilog this would be Pixel1={Blue[7:0],Green[7:4]}, Pixel2 = {Green[3:0],Red[7:0]}... Already fixed for next beta update, will get that out when there are a few more bugs fixed.
vii/viii) Gated mode, as noted above with the changing of resolution, has some edge cases in the FPGA side that can cause crashing of the pipeline in there. If you find anything that can reproduce this easily Please let us know, this has been a tricky one to track down.
Would it be acceptable to turn off live preview if not currently recording when in gated mode?
FEATURE REQUESTS
- Partitioned memory mode is cool. I don't see support for being able to switch memory segments yet though, did I miss something?
- Saving the whole RAM to RAW can be a slow affair. It would be super cool to have an option to turn on an auditory alert or screen flash when saving is done so I know to look up from my laptop!
- I connected IO2 with frame sync output to an oscilloscope at 1Meg impedance and the signal was very funky until I pulled it down to 50 Ohms. In a future version of the camera, can you include a 50R pulldown resistor option for either IO2 or IO3?
- Does the hardware support binning mode? i.e. read out each block of 2x2 pixels as a single virtual pixel with 4x the effective sensitivity, image is now 1/4 the size.
- Can you modify the RAW formats to add a few bytes of header data? Ie pixels width and height, bits per pixel (for discriminating RGB and mono data files), and may be camera serial no? Most scientific cameras write data out this way. ImageJ / FIJI RAW reader by default assumes the first 1024 bytes of scientific camera RAW are header anyway.
- I see the specs list two 1 MS/s ADCs. Is there any way we could use these for recording an arbitrary signal like a pressure or temperature sensor in sync with the movie? Are they wired to the mic jack?
- Is Krontech willing to share who they buy their CMOS arrays from? I'm not going to go into competition
, but often these details need to go into the methods sections of scientific journal papers.
Will work on those. The indicator when save complete is really good. As soon as audio is working I'll make sure that's one of the options.
The sensor does include a binning mode but we haven't set it up or tested it yet.
The ADC inputs are on the terminal connector along with trigger 2 and 3. Once we overlay or embedded data we can save the analog values there. It will be a bit as we haven't started implementing this part.
We are using Luxima sensors.
