Messages

16

Software Dev / Re: Speed boost to 38k fps?

« on: December 21, 2017, 04:18:01 PM »

I've been able to successfully take images at 38,565 fps by reducing the field of view to 336 x 96 pixels, then pressing the 'Max' button to select framerate.  I'm driving the shutter gate from an external signal, which I set very slightly slower (38,560 fps) to avoid dropping frames. It works great!

17

Software Dev / Re: Software V0.3 Beta

« on: December 21, 2017, 12:12:24 AM »

Cheers!

• I'll see if I can reliably reproduce the external sync bugs when I get back to the lab in early Jan. I'm generating my TTL sync signal from a Beaglebone Black's PRU so I can pretty much make it do whatever I want. If you want me to test anything with external triggering, let me know.
• I've found by looking at the sync output vs the gating input on a scope that there's a random delay between the shutter gate input rising edge and the output sync rising edge, it can be anywhere from about 200ns to 1.1us. It's not jitter, just a bias that changes depending on the framerate. The jitter is much smaller, more like 11 ns (I guess that's the clock rate). I suppose the delay is an artifact of the way the FPGA's handling the timing. When the light source is a microsecond strobe pulse, we have to delay it an extra microsecond or two to avoid the problem. For some science experiments, the time between subsequent exposures is super important and so knowing this delay is necessary. If we could reliably predict the exposure delay as a function of the camera's settings, that would be super cool.
• The live preview is handy in externally gated mode as it immediately lets me know that my strobe light and exposure timing are aligned - as well as making sure my image is in focus. If it was disabled to improve stability, I'd have to rely on an oscilloscope signal from the frame sync output to tell the timing, and getting things focused up would be a lot more annoying - I'd have to change modes back and forth.
• If audio support is a way off, flashing the screen for completed saving or putting a brightly coloured alert message on the screen would work.
• Understood re. the speed of saving issue, binning, ADC signals etc.

Dan

18

Software Dev / Re: Raw video format

« on: December 20, 2017, 11:31:04 PM »

Hi Loial

I'm probably going to end up dumping the 12-bit packed raw binary data most of the time - I'm using the camera in a research environment.
However, the next best thing would be 16-bit TIFF, which has the advantage of being readable by most scientific software packages right out of the box. I'm using a monochrome camera though, I appreciate that writing 16-bit RGB TIFF data from the color model will not be so efficient!

I've tried both multipage TIFF (all frames in one big file) and sequences of TIFF images on high-end high speed scientific cameras. I've run into major problems with multipage TIFF, and strongly recommend saving a directory of numbered TIFF files instead, being aware of the file management inconvenience that can cause. In my experience, there seems to be an effective 4GB file size limit in the TIFF standard, which will cause trouble for anyone who wants to dump more than 3 GB of the RAM at once (allowing for the zero padding). Most scientific software will stop reading a multipage TIFF at 4 gb even if the file is bigger! So yeah, multiple files is the way to go if you're going to pick which to implement first.

ps. Any chance the 12 bit packed RAW mode could be modified to write a few bytes of header data to make writing decoders for it easier? (i.e. pixels width and height and bits per pixel)?

19

Software Dev / Re: Software V0.3 Beta

« on: December 20, 2017, 07:15:14 AM »

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.

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.

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.

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.

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.