x3f raw file format enhancement

A somewhat theoretical reasoning on the potential of the Sigma SD14 camera:

According to official sources, the Foveon sensor has a 12 bit per pixel/color (36 bit/pixel) readout wich would equate to to a dynamic range of 1:4090 or 72 dB. The dynamic range is probably limited because of dark current (noise) and has been quoted to be in the 62 - 65 dB on this forum which wold equate to 1:1259 - 1:1778. To fully encode this dynamic range, a minimum of 11 bits are needed (1:2048).

The x3f raw format image file only uses 8 bits pixel/color (24 bit/pixel) resolution, wich equates to a dynamic range of 1:256 or 48 dB. Would it not make sese to retain the full 12 x 3 bit pixel resolution in the raw format file, to increase potential of image creation with the Phot Pro software.

Jpeg color space is limited to 3 x 8 bit but this might also change in the future.

As Sigma markets the camera towards a "artist" user category (and the militant defence of Sigma image quality from the participents of this forum), I think it would make sense to add to the "quality product" image with this option. It shuld be possible with a firmware revision.

This mod does increase filespace requirements with 50%, but this is of lesser importance for the select user with todays storaga size/price options.

(Not a Sigma user, but do admire the Sigma/Foveon image quality. Definitly a SD14 speculant.)

--
F.Swartz

The X3F format already contains 36bit color data in its current manifestation.

Not according to this documentation:
http://www.x3f.info/technotes/FileDocs/X3F_Format.pdf
--
F.Swartz

Fredrik Swartz said:

The x3f raw format image file only uses 8 bits pixel/color (24
bit/pixel) resolution, wich equates to a dynamic range of 1:256 or
48 dB. Would it not make sese to retain the full 12 x 3 bit pixel
resolution in the raw format file, to increase potential of image
creation with the Phot Pro software.

Click to expand...

I don't think we could use Fill-Light and Highligh & Shadow effectively with 8bit files. Not sure though. If I remember correctly somebody here (Pavel Sokolov?) tried to read X3F file and claimed that it was in 14bit format. But I'm not sure if I remember correctly.

Miikael Leskinen

MBL81 said:

Fredrik Swartz said:

The x3f raw format image file only uses 8 bits pixel/color (24
bit/pixel) resolution, wich equates to a dynamic range of 1:256 or
48 dB. Would it not make sese to retain the full 12 x 3 bit pixel
resolution in the raw format file, to increase potential of image
creation with the Phot Pro software.

Click to expand...

I don't think we could use Fill-Light and Highligh & Shadow
effectively with 8bit files. Not sure though. If I remember
correctly somebody here (Pavel Sokolov?) tried to read X3F file and
claimed that it was in 14bit format. But I'm not sure if I
remember correctly.

Miikael Leskinen

Click to expand...

it does; the pdf he is referring to does not state the pixel depth in the x3f file for anything other then the preview (which is 8x8x8 bits).

internally the full sizes data are 14bits deep (x3)

That might well be true, but I have not been able to confirm that with an actual x3f file. Any available from the Sigma site are much to small to be 14x3 uncompressed (21bit more likely). Can any of you provide an original x3f image file for me to look into?
--
F.Swartz

I can give you a file. Just send me a email.

Miikael Leskinen

Fredrik Swartz said:

Not according to this documentation:
http://www.x3f.info/technotes/FileDocs/X3F_Format.pdf

Click to expand...

That document actually says nothing about how the RAW data is held, but does describe how you get to the preview images. This is what section 3.2 refers to with the Data Format entry. Note that it says "Others: Reserved".

This document is all about how to access the metadata from an X3F file, not how to process or even access the RAW data (though it's easy to figure out where it is as I think it's just another Image type).

--
---> Kendall
http://InsideAperture.com
http://www.pbase.com/kgelner
http://www.pbase.com/sigmasd9/user_home

Fredrik Swartz said:

That might well be true, but I have not been able to confirm that
with an actual x3f file. Any available from the Sigma site are much
to small to be 14x3 uncompressed (21bit more likely). Can any of
you provide an original x3f image file for me to look into?

Click to expand...

The RAW data is compressed (loslessly), I think huffman. What you should really do is download DCRaw and look at the code that parses the X3F data.

Thought it was 16x3 actually... pretty sure it's stored on even byte boundaries.

--
---> Kendall
http://InsideAperture.com
http://www.pbase.com/kgelner
http://www.pbase.com/sigmasd9/user_home

It tried to find small file so it wouldn't eat all my server space.
http://www.students.tut.fi/~leskine4/IMG04008.X3F

Miikael Leskinen

Yeah, I think you're right. It would mean that the Huffman encoding manages an almost 50% size reduction for this particular images.
--
F.Swartz

Sounds about right... assuming there is an extra 0x0 word at the end of each 48bits of padded color information to align to 64bits (future expansion for luma / alpha channel?) , and each 16bits of color contains 12 bits of information from the sensor, that's an immediate 20 bits per 64 that can be reduced to 2 bits in the coding, reducing almost 30% before actually compressing any image information... this math is probably off though because of other issues and my lack of knowledge of their exact methods...

Huffman encoding assigns a number to each posssible pixel/color intensity value depending on relative probability. High probability colors intensities (within the actual image) gets the lowest numbers and therefore the shortest code. A color intensity value not in the actual image could have any size number, as it would not be present in the image data. The datafile includes a huffnman codetable to decode the specific image data.

I have not had the time to look into the DCRaw sourcecode, so I don't know if there are separate codetables for each color.

The encoding dos not rely on byte boundaries at all, as each image pixel/color number size depends on probability. Any record size or byte boundaries would only complicate the encodeing scheme. A channel with no signal would be encoded as 1 bit per pixel.
--
F.Swartz

Another thing; a perfect photo of a continous RGB color space chart would be incompressible, in theory, as huffman encoding is lossless.

Example image file of monchorome and RGB chart anyone?
--
F.Swartz

Fredrik Swartz said:

Huffman encoding assigns a number to each posssible pixel/color
intensity value depending on relative probability. High probability
snip

Click to expand...

...

Which is where I got my numbers from, although like I said they are off a little. In the average scene where colors are distributed in a typical manner, the 16-20 bit 0 padding (20 from 16bit + 4bits unused at next color) will have the highest frequency within the set of data to be compressed, and get the shortest binary representation. The file format would seem to indicate a 256 element coding table (for the preview images, at least) corresponding to 8 bit words, causing the 16 bit 0 sequence to reduce to two bits (11), assuming that at 25% of the file this is the most frequently occuring set of inputs.

Fredrik Swartz said:

That might well be true, but I have not been able to confirm that
with an actual x3f file. Any available from the Sigma site are much
to small to be 14x3 uncompressed (21bit more likely). Can any of
you provide an original x3f image file for me to look into?

Click to expand...

take my tool to export raw to tiff ( without any transformations )
http://www.photofo.com/downloads/x3f.zip

--
http://www.pbase.com/crea7or/
http://crea70r.photosight.ru

Fredrik Swartz said:

Another thing; a perfect photo of a continous RGB color space chart
would be incompressible, in theory, as huffman encoding is lossless.

Example image file of monchorome and RGB chart anyone?

Click to expand...

gretag macbeth 24
http://www.photofo.com/downloads/img04815.x3f

--
http://www.pbase.com/crea7or/
http://crea70r.photosight.ru

Thank you! The chart is discrete wich probably means that each of the 24 color squares will need 3 possible values per channel, summa 72 (for a noise of + - 1 bit/channel). If this where the only colours in the image, the codetable would be limited to 48 entries per channel, for a mean code length of 6.2 bit per pixel/color. File image data set would be 7.6 MByte.

As the actual file size is smaller, the set of most probable channel signal values will have to be smaller. Certanly so since the black&white monochrome background adds data to all channels.

Have anyone done a comparision of image quality while decoding the 3xf file with PhotoPro or DCRaw?

--
F.Swartz

Fredrik Swartz said:

entries per channel, for a mean code length of 6.2 bit per
pixel/color. File image data set would be 7.6 MByte.

Click to expand...

I did not calculated it especially, but spend a lot of time on huffman optimization ( asm ), the most frequent value is 7 bits per pixel as I remember.

Fredrik Swartz said:

As the actual file size is smaller, the set of most probable
channel signal values will have to be smaller. Certanly so since
the black&white monochrome background adds data to all channels.

Have anyone done a comparision of image quality while decoding the
3xf file with PhotoPro or DCRaw?

Click to expand...

PhotoPro is the best.

here some tests:
http://www.pbase.com/crea7or/temp

--
http://www.pbase.com/crea7or/
http://crea70r.photosight.ru

Very interesting images. I wonder why there is so much hush-hush about raw file formats and post processing software. I cannot se how a camera maker wuld loose on the availability of better/alternative processing software, though this may be unneeded for the foveon file format.

Can and Nik raw files seems to loose a lot of spatial resolution in post processing. I hav not been able to find an image in their native 10+Mpicel resolution that is usable without a 50% reduction.
--
F.Swartz