Chronos > Software Dev

Raw video format

(1/2) > >>

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?


Dan D:
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)? :)

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.

Dan D:
Awesome, thanks! I just finished writing a Cython library to import the 12 bit packed RAW files into 16-bit arrays for post analysis and conversion in Python. This will be useful for those of us who like to write our own post processing and image analysis tools and do fancy time-series analysis. I'll start a Github project for it eventually! Incorporating a metadata scanline will make things much more user friendly.

Dan D:
I've just pushed a beta version of my Python package that reads Chronos RAW files to Github.

It's part of a larger package for scientific imaging data formats that I'm working on that reads weird camera file formats into easy to use NumPy arrays which can then be exported to any format you like with about 2-3 lines of code.  I've included support for the 0.2.3 beta RAW formats 'chronos14_12bit_noheader' and 'chronos14_16bit_noheader' where the user must specify the height and width of the frame as there is no metadata / header in the file itself at this stage. The actual file reading is done in C (via cython) so it's pretty fast.  The package also handles standard formats ie. 8/16/32 bit TIFF, H.264 movies etc. using ImageMagick and FFMpeg libraries.  Tested working on MacOS, should work on Linux too.  I will test it on Ubuntu next week.

I only have monochrome cameras, so I've not incorporated colour sensor RAW support yet. If someone would like to send me sample 12 and 16 bit RAW files from a colour camera, I'd be happy to add support for it.

Once we have a header scanline added, I'll add more RAW formats to the list of supported ones.


[0] Message Index

[#] Next page

Go to full version