Support raw file formats

[jpambrun]

Support raw input for encoding and output for decoding where we can specify number of rows, columns and bands, data type, endianness and signedness. This will make it much easier to test with medical imaging.

Which brings another question: do you support signed pixel data?

[FLIF-hub]

Pixel values are currently assumed to be unsigned, but it wouldn't be hard to support signed pixel values, since internally everything is using signed ints anyway.

The current implementation already does support PNM input/output; it should be trivial to add a PNM header to your raw data or to remove it from the output. Is that good enough?

[jpambrun]

It was meant as a suggestion for future enhancement. I usually use Matlab for benchmark and found it was easier to use raw format than PNM. Thanks for the quick response though.

[psykauze]

I'm waiting for this improvement too for camera raw pictures (RGB bayer filters). This should be useful for archiving (and viewing it more losslessly on a LCD screen if there is ICC profile support).

For better efficiency, maybe you could separate R pixels (X/2 * Y/2), G pixels (X/1 * Y/2) and B pixels (X/2 * Y/2) in three gray layers. Also, there's many bit-depth like 8bits/pixel, 10bits (recent phone sensors), 12bits, 14bits (professional reflexes), 16bits/pixel (this and higher bit-depth are more exotical), ...

[wraybowling]

It makes more sense to me to expand FLIF to support for the pixels' exponent value ala RGBE. As I remember (it's been a while) there are a bunch of different bayer filters, and thus a lot of different RAW image formats associated with them. I think OpenEXR works that way.

[psykauze]

Yes, there's not only one kind of Color Filter Aray. But camera's sensor "usualy" use a 2x2 matrix (like [R,G1][G2,B], there's also a [E,R][G,B] form with "E" for Emerald/Cyan or [W, R][B,G] W for White).

I think the CFA Pattern can be stored as metadata like in RAW format (it might be just dumped from the RAW and stored as is).

There's now three options for compressing the data: 1) Compress the picture in grayscale without any manipulation but "Is MANIAC efficient with the 'mosaic' pattern?" 2) Separate each "color" to a X/2 * Y/2 grayscale layer and compress it (more efficient?) 3) Threat each pattern as an unique pixel (like, in bit form, rrr...ggg...ggg...bbb...) but the pixel is 4* bigger (Reflex use 14bit sensors so 14bit for red, 28bits green and 14bits for blue so 56bits per "pixel")

[sipa]

I expect that the best compression would be obtained for RGGB to convert it first to an image with one pixel per matrix, with 4 'colors' (R, (G1+G2)/2, B, G1-G2).l, allowing even the YIQ transformation to be performed on the first 3. FLIF does take correlation between color planes of the same pixel into account, so this should be better than encoding it just as 4 greyscale images.

For sensors with other colors... just treating the different subpixels of a matrix as different color planes of a single pixel is probably best. I believe the internal encoder does not care about what the meaning of the different color planes is.

[jpambrun]

Camera raw in interesting, but I really meant raw multi-band matrices saved to files without headers. For instance, from the documentation of OpenJpeg :

-F width>,<height>,<ncomp>,<bitdepth>,{s,u}@<dx1x:...:x Raw input image characteristics. If subsampling is omitted, 1x1 is assumed for all components. Required only if RAW or RAWL input file is provided. Example of a raw 512x512 image with 4:2:0 subsampling -F 512,512,3,8,u@1x1:2x2:2x2

[psykauze]

I'm sorry, I did not understand instantly that you would like to add non-headed raw support to the flif tool and not raw support in the file format.