8-bit vs 16-bit Precision, and Indexing

8-bit vs 16-bit Precision, and Indexing - Printable Version

+- Gimp-Forum.net (https://www.gimp-forum.net)
+-- Forum: GIMP (https://www.gimp-forum.net/Forum-GIMP)
+--- Forum: General questions (https://www.gimp-forum.net/Forum-General-questions)
+--- Thread: 8-bit vs 16-bit Precision, and Indexing (/Thread-8-bit-vs-16-bit-Precision-and-Indexing)

8-bit vs 16-bit Precision, and Indexing - Mango Turtl - 08-22-2021

Just a couple questions that I can't seem to find the answer for online, so I figured I would ask here.

Online, it says that editing a photo with 8-bit precision is easier on a computer's RAM, and reduces file size. I have no trouble with RAM usage, and I shoot a lot of my photos in 16-bit RAW format, so I edit photos with that. However, I'm VERY interested in the reduced file size.

It seems to me that if I edit a photo in 16-bit and then convert it to 8-bit precision after I'm done, it still makes it may smaller in size...and flipping between 16-bit and 8-bit via the history tab, I can't see an actual difference. Does anyone know what actually happens to the photo if I switch to the 8-bit precision after I'm done editing? And what's the difference between just using 8-bit precision and using indexed colors, since I can see a VERY visible difference if I index the colors as well.

I'd really like to know how much information I'm losing if I switch to 8-bit precision, without indexing, after I'm already done editing the original 16-bit photo.

Thanks!

Edit: Looking at the colorcube analysis, both the original 16-bit and converted 8-bit PNGs have the same amount of unique colors. Obviously, the indexed version only has 256. Does this mean that if I don't index, no actual visible information is lost by converting it to 8-bit?

RE: 8-bit vs 16-bit Precision, and Indexing - rich2005 - 08-22-2021

8 bit and 16 bit for RGB images are the number of bits per channel so 8 bit = 24 bits per pixel , 16 bit = 48 bits per channel/

That determines the number of colours available. Covert from 16 bit to 8 bit and colours are lost but it all depends on the image, it might not be as severe as it sounds.

Indexed Images are very different, each pixel is assigned a colour from a colormap, the colour map only contains 256 values so you only get what is available in the color map. Converting from RGB to Indexed will try and make the best colormap from the image. and can 'dither' the boundary between colours to give an impression of a smooth transition.

see: https://www.cambridgeincolour.com/tutorials/bit-depth.htm which is worth a read.

8 bit = greyscale colours
24 bit = 16 million colours
48 bit = 281 trillion colours

Quote:Edit: Looking at the colorcube analysis, both the original 16-bit and converted 8-bit PNGs have the same amount of unique colors. Obviously, the indexed version only has 256. Does this mean that if I don't index, no actual visible information is lost by converting it to 8-bit?

As far as I know, colourcube is stuck in the past and is only 8 bit ( 24 bit 16 million colours)

RE: 8-bit vs 16-bit Precision, and Indexing - Mango Turtl - 08-22-2021

(08-22-2021, 08:01 AM)rich2005 Wrote: 8 bit and 16 bit for RGB images are the number of bits per channel so 8 bit = 24 bits per pixel , 16 bit = 48 bits per channel/

That determines the number of colours available. Covert from 16 bit to 8 bit and colours are lost but it all depends on the image, it might not be as severe as it sounds.

Indexed Images are very different, each pixel is assigned a colour from a colormap, the colour map only contains 256 values so you only get what is available in the color map. Converting from RGB to Indexed will try and make the best colormap from the image. and can 'dither' the boundary between colours to give an impression of a smooth transition.

see: https://www.cambridgeincolour.com/tutorials/bit-depth.htm which is worth a read.

8 bit = greyscale
24 bit = 16 million colours
48 bit = 281 trillion colours

Quote:Edit: Looking at the colorcube analysis, both the original 16-bit and converted 8-bit PNGs have the same amount of unique colors. Obviously, the indexed version only has 256. Does this mean that if I don't index, no actual visible information is lost by converting it to 8-bit?

As far as I know, colourcube is stuck in the past and is only 8 bit ( 24 bit 16 million colours)

Okay, I'm not that techy so I might need a rephrase. But what I'm getting is that unless there's MORE than the 16 million color limit in the original 16-bit image, then converting it into 8-bit won't change much. And don't worry, I'm definitely not messing with indexing. Just trying to lower file size without reducing resolution or detail by much.

RE: 8-bit vs 16-bit Precision, and Indexing - rich2005 - 08-22-2021

Quote:...snip..what I'm getting is that unless there's MORE than the 16 million color limit in the original 16-bit image, then converting it into 8-bit won't change much.

It depends on where you get that 16-bit image.
If you want a better estimate of the number of (unique) colours in an image then use ImageMagick identify

Code:

identify -format "UniqueColors: %k\n" image.ext

As an example: The same RAW image (12 bit ?) imported (using nufraw) into Gimp. First as 8 bit and exported as an 8 bit tif.
Then a separate import as 16 bit into Gimp, exported as 16 bit tif.

[attachment=6562]

Then export format. A jpeg is 8 bit but worth editing as 16 bit to avoid effects such as ramping. When exported it is back to 8 bit and file size determined by the jpeg quality setting.
Those tiff images above and the 16 bit is obviously much bigger than the 8 bit even with compression. 130 MB versus 44 MB.

RE: 8-bit vs 16-bit Precision, and Indexing - Ofnuts - 08-22-2021

You won't see a difference usually because your screen electronics use 8-bit/channel (and in fact probably the whole chain between Gimp and the display is 8-bits). The real difference is in the processing.

When you are working with 8-bit per channel, things degrade very quickly. Consider this:

You make a rather minor brightness adjustment in your image, so mid-gray (127) becomes 137.
All the values in the 0-127 range are mapped to values in the 0-137 range. Some of the 0-137 values won't correspond to anything in the original 0-127 range, so you will have gaps.
In the 127-255 range, things are worse, because we are mapping 127-255 to 137-255, so we are missing 10 "slots", so some of the 137-255 values will correspond to two values (or even three in the bad cases) from the 127-255 range.
So all in all you have lost 10 values, about 5% of the range.
Where you have gaps (ie jumps in values) you can get "banding" in the image.
Where you combine values, you have flat areas

Things are a bit hidden because the gaps or overcrowdings usually do not happen together in the three color channels, but this can show up in large area o light (skies...).

[attachment=6563]

In 16-bit this can happen to, but to a much lesser extent

[attachment=6564]

Also, in 8-bit, there is a "gamma-compression", which means that the actual values are corrected (power 2.2) to give more range to the darks. This hjelp to keep details in the shadows, but at the expense of the lights.

In practice, Gimp now works in high-precision internally (32-bit floating-point), so the image precision only tells it how to store intermediate values (ie, your layers, channels, selections). If your image is 32-bit floatin-point, you skip conversion steps and the processing can be faster.

Last, to give you an idea the usefulness of using high-precision even for your layers:

[attachment=6565]

The high precision in 2.10 avoids some artefacts (less moiré in 2.10 even in 8-bit) but the result is still choppy, because the bump map could only have 256 values (the bump map was produced by filling a feathered circle selection).