Question

Practically, I don't understand the use of the sBIT chunk in an PNG file.

I'm storing PNG files from an 11 bits/channel RGB source, so I dutifully set the sBIT chunk in my (c) code:

...
png_color_8 sig_bit;

sig_bit.gray = 0;
sig_bit.alpha = 0;
sig_bit.red = 11;
sig_bit.green = 11;
sig_bit.blue = 11;

png_set_sBIT(png_ptr, info_ptr, &sig_bit);
...
/* save the png */

When the images are viewed a windows viewer (native Vista picture viewer/Paint.net), the lower 8 bits are truncated, so I only can see the upper 3 bits. I would have thought the sBIT chunk would automagically instruct readers to left shift the pixels by 5 bits to MSB justify the data for display. Doesn't seem to be the case.

When I open the png files in my code that either have or don't have an sBIT chunk, and do the following:

png_color_8p sig_bit;
if (png_get_valid(png_ptr, info_ptr, PNG_INFO_sBIT)) {
    png_get_sBIT(png_ptr, info_ptr, &sig_bit);
    png_set_shift(png_ptr, sig_bit);
}

The pixel data is the same.

What is the use model of the sBIT chunk? Can I somehow use the sBIT chunk to MSB justify the pixel data for viewing, but see the "original" data for numerical analysis?

Was it helpful?

Solution

The sBIT Chunk tells the decoder the number of significant bits in the pixel data. In essence, it tells the decoder that the data has already been shifted left to fit in a standard bit depth. E.g. For your case of 11-bit data, you should have shifted the pixels left by 5 bits and stored them as 16-bits per pixel. The decoder will see that out of the 16-bits in each color, only the top 11 are significant, so that it can potentially recompress the image in a new format knowing that there are only 11 useful bits out of the 16.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top