Messages

16

Software Dev / Re: Raw video format

« on: December 24, 2017, 01:06:24 AM »

I'll work on getting an extra scanline at the top of the image with info about resolution and frame size. It'll be useful for other formats at a later time as well.

17

Software Dev / Raw video format

« on: December 20, 2017, 04:15:30 PM »

As probably evident I'm one of the main people working on the raw saving pipeline. One of the issues that I'm facing is what the output format should be and I'd like input on what would work best.

Right now I'm mainly working on getting DNG/TIFF working. DNG may be required for the bayer-encoded colour cameras but otherwise the two are interchangeable.

DNG/TIFF have different ways of being implemented including saving a series of images and saving all the images into a single file.

One option that I'd love to implement is the lossless-jpeg format available in DNG as it may be reasonable to do this either on the FPGA or using the DSP or video pipeline on the main CPU. LZW, PackBits, ZIP and gzip are also available for TIFF but details on what software accepts is difficult to track down.

Are there any other formats which would also work or would be more ideal?

Thanks

18

Software Dev / Re: Software V0.3 Beta

« on: December 20, 2017, 03:59:28 PM »

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.

19

Software Dev / Re: Software V0.3 Beta

« on: December 19, 2017, 02:28:54 PM »

Does this mean we can upgrade our 16g camera to a 32g one, just by dropping in a second 16g card?

if yes, do you have any links to where I can purchase said 16g card that will be fully compatible?

Technically yes. The only sticks we really support are the ones supplying but any dual-rank 8 or 16GB DDR3 dimms should work in the camera.
A quick search finds these: https://www.newegg.ca/Product/Product.aspx?Item=9SIADER6682991 (not endorsing, just did a quick search)

20

Software Dev / Re: Software V0.3 Beta

« on: December 19, 2017, 02:23:27 PM »

Which interface should be USB stick plug in ? The eSATA interface or the OTG interface ?

The eSATA interface. Make sure the stick is FAT32 (under windows 10 you may have to use 3rd party software to format as this because they've removed the option on drives larger than, IIRC, 64GB)

21

Chronos User Discussion / Re: raw recording

« on: December 19, 2017, 02:20:52 PM »

The latest beta software has raw saving support.

The format is very raw right now. It simply saves the data either as packed 12-bit or 16bit either LSB or MSB justified. There's no encapsulation or formatting. It's just raw words one after the other.

We're still working on a better format so if there's a specific format your software supports let us know. Right now the highest on the list is DNG image sequence. There is an issue where a portion of one of the main libraries we have available for saving doesn't support anything higher than 8bpp so we need to patch or rewrite that before we can get an encapsulated format such as DNG working.

22

Software Dev / Re: raw video data

« on: December 15, 2017, 02:03:09 PM »

Raw saving of files is now available in the newest beta software. It will only save to SD/USB/SATA drives but you can download the saved video to a computer using the USB-OTG port by scp'ing from the camera. On the latest update USB should give you a network interface and you can log in using root with no password. The file location is listed under the save setting dialog.

An API to control the camera, stream video and get video directly without going through saving it to local media is in the works but still a ways off. There are some major changes needed for the camera application itself before that becomes available. It is quite high on our priorities once we get the major bugs worked out.

23

Software Dev / Re: Software V0.3 Beta

« on: December 15, 2017, 01:55:32 PM »

I'll have to give this a shot.

A couple questions/comments:

1. Thank you for being able to retain settings between reboots.
2. Stupid question, how fast does it currently save at? Faster save FPS will really help those 17,000 fps shots. I'm always paranoid and put big handles on my saves.
3. Easier trigger delay will be handy. Always hard to judge how long to wait before hitting the trigger. Now I can just hit it when stuff happens and know that I'll have a handle on the end.
4. What ram configurations have been used on cameras shipped thus far? Just wondering if I have  2 8gb or 1 16.
5. RAW saving I presume is uncompressed video? Is there. Information about the differences between the option you listed? Sounds like a great option for retaining maximum detail when you know you will be running the video through an editor.
6. Standalone mode will be interesting to try.

7. I know we are all waiting for this, but how are things going with HDMI support?

Thanks again for all your hard work.

2. Saving will scale with how quickly it can get data to the SD card or other media. At 1280x1024 it's limited to about 60fps but can go as high as 190fps while saving lower resolution or quality.
4. All 16GB models were shipped with a single 16GB stick
5. RAW is simply a packed raw format. Each image is saved one after another without any wrapping or containers - I.E. it's not a TIFF or anything. This is still a work in progress and the goal will be to save DNG/TIFF image series or some other better supported format.
7. HDMI is one of those more difficult problems. In my testing I've been able to get HDMI working from the command line but only while the application was not running. It's something we're working on but it won't be ready until at least the next update.

--- More info about RAW
There are three raw formats: 16bpp, 16bpp right-justified and 12bpp packed.

Because the data coming off the sensor is 12bpp the smallest raw files will be saved in the last mode but that's also the least supported format for reading/writing.

16bpp and 16bpp right-justified both add 4 bits of 0 to either the most significant or least significant bits.
For 16bpp (left-justified) that means that all values will be from 0-65536 (or just under that) and for the right-justified version it'll be 0-4096. The first of these two formats will be better supported by software.

Right now I've prototyped a python script that can convert the raw format into a series of b/w TIFFs but it's in very early stages of development. From colour sensors you'll get the full bayer pattern in the raw data and right now most software that can normally handle bayer-encoded images is not detecting it due to being a TIFF. Once I have it able to make a DNG image series instead with the proper coding for editing software I'll release it so it can be used.

All of the raw saving is still quite preliminary as the goal will be to get the camera saving directly as a more standardized way such as DNG photo series or CinimaDNG.

24

Software Dev / Re: Software update V0.2

« on: December 15, 2017, 01:37:47 PM »

Any time line on when the Audio input and the HDMI Output will be supported?
Those 2 items and RAW would make this camera sell like hot cakes.

Three things I noticed that there needed
#1 A factory reset button for all settings or per page.
#2 A percentage meter like you have on the battery but for the amount of storage left.
#3 A button to clear the cash or ram. Unless it's set up for roll over.
If it is there needs to be something in the manual stating it.
I'm just used to cameras you do not edit on. You shoot it. It saves the hole thing. In point at record start. Out at record stop. Perhaps that can be a button we can X on, or X off.

If you update to V0.3 beta software: Settings reset is in Utils under "settings" tab. There's also options there for saving and recovering saved settings.
This is a beta feature so please let me know if it works or if there are any issues with it.

Good idea on the storage left indicator. Will look at adding something like that. Right now it will give a warning if you try saving a file that is larger than 4GB or larger than the space left on the device.

The buffer memory will automatically roll over; there should be no reason to clear it.

As for HDMI and Audio - both are looking like they may get into the next update. We have HDMI working partially on a development camera but there are some that need to be overcome before it can be integrated into the application. Audio is in a similar state.