What is lost when converting 12 bit imagery to 8 bit?

Question

SPOT 6/7 satellite imagery is captured with a dynamic range of 12 bits per pixel per channel (ref). However almost all of the SPOT imagery I have seen in use has been 8 bits per channel, and split into RGB natural colour (Bands-321) and Near-infrared-RG false colour (Bands-432). What information is lost in this 12 to 8 bits conversion?

I'm wondering if we should be altering our request for purchase specifications to deliver the full bit depth.

Although I'm referencing SPOT imagery specifically the question is general and really applies to any satellite or sensor system.

Update: Cross posted to Gdal-Dev mailing list, http://osgeo-org.1560.x6.nabble.com/gdal-dev-What-is-lost-when-converting-12-bit-imagery-to-8-bit-tt5482829.html. Feel free to crib the good bits from that conversation and add to your answers.

Answer 1

I know that you have tried to frame this as a general question, rather than specific to SPOT 6/7, but it's really a little of both.

The naive answer to the "general" question "what is lost when transforming 12-bit raster data to 8-bit?" is "4 bits of precision." This answer may not be terribly useful though because there are different ways to stretch the data from 12-bits to 8-bits and it also depends on what the 12-bit numbers represent. Are they physical units such as spectral radiance? If yes, then stretching to 8-bits may obliterate the physical meaning of the pixel values. Are the 12-bit numbers all in the range [0-255] already? If yes, then stretching from 12-bit to 8-bit won't "lose" anything, but will make the file smaller.

In the case of SPOT 6/7, you might find it helpful to review the SPOT image user guide, particularly the descriptions of different processing levels in section 2.3. If you're ordering Primary Products (as opposed to Standard Orthos), one might want to preserve the original 12-bit range in order to perform some quantitative analysis that depends on the physical units (scaled spectral radiance at sensor, in this case), or at least benefits from having as much of the original information as possible (such as some stereo photogrammetry pipelines). If one just wants to look at color composites (without having to stretch the images oneself), then ordering Primary Products stretched to 8-bits should be fine. It's not clear to me from the docs what stretch is performed to transform from 12-bits to 8-bits in the Primary Products. Preserving the 12-bits also gives a customer the option of defining their own stretch or other radiometric transformation.

tl;dr: Maybe nothing is lost, maybe it completely breaks a workflow. It depends on the use case.

Answer 2

8 bits can encode a number from 0 to 255 (2 to the power of 8 values)

12 bits can encode a number from 0 to 4095 (2 to the power of 12 values)

In the simplest way of converting from 12 bits to 8 bits the last four bits will be set to zero, and the remaining bits shifted right four places. Its like rounding decimal numbers to the nearest 100 or 1000.

What's lost then is fine detail. For example with decimal numbers, the ability to discriminate between values of 9 and 12 - think how if rounded to the nearest 10 they'll both be 10 in the data. The same happens with binary data truncated from 12 to 8 bits.

I say "the simplest way of converting" because other methods could be used that preserve detail in certain regions of the intensity - perhaps the highest and lowest parts of the image can be encoded with less dynamic range, taking fewer bits, by a non-linear scaling of the raw data. That leaves more bits to encode the data in the middle of the intensity region, which might be the important part.

Answer 3

The position I've moved to after reading through and thinking about all the responses here and gdal-dev (here) is we need to ask for both 8 & 12 bit from the vendors.

8 bit is for visual use. It can be viewed on all displays and most programs without modification. Since this is 90%+ of usage scenarios having them ready to go is definitely beneficial to us. Additionally having the processing done in advance by a skilled supplier will save a lot of work -- and might even be a better visualization than we could produce ourselves. Producing good visuals across scenes systematically is not trivial.

The main drawback to automated 12 to 8 bit RGB products is that they tend to be very suboptimal in dark or bright areas (shadows, water, snow). This is because the fixed white and black point anchors needed to span the scene sets can not account for individual scene variation.

We should also ask imagery suppliers to describe their bit-reduction process. This will allow us to determine how it affects our application.

In audio terms, its a bit like cutting either the bass or the treble - what is best for you depends on what you want to do with the music afterwards.

• 8 bits allows numbers from 0 to 255 (2 to the power of 8 values)
• 12 bits allows numbers from 0 to 4095 (2 to the power of 12 values)

The simplest way conversion from 12 to 8 bits is setting the last four to zero, and the remaining bits shifted right four places. Its like rounding decimals to the nearest 100 or 1000.

What's lost is fine detail. For example the ability to discriminate between values of 9 and 12 - if rounded to the nearest 10 they'll both be 10 in the data. The same happens with binary data truncated from 12 to 8 bits.

There are other methods that could be used that preserve detail in certain regions of the intensity - perhaps the highest and lowest parts of the image can be encoded with less dynamic range, taking fewer bits, by a non-linear scaling of the raw data. That leaves more bits to encode the data in the middle of the intensity region, which might be the most important part.

12 bit is for analytic use. When using imagery for analytically (e.g. converting pixel values to reflectance) you probably do not want the 8 bit product. With the 12 bit values of 0-4095 compared to 8 bit's 0-255 there is opportunity to do careful scene dependent conversion in a way that best brings out the details available in the source data. There are a lot of methods, and they generally require time and patience. The challenge is sometimes called tone mapping.

Planet has a blog post describing how to manually convert single scene imagery to 8bit RGB at A Hands-On Guide to Color Correction. It's a good article as it explains the theory for how certain things are done instead of merely giving a recipe of steps.

To get GDAL in the mix: gdal-translate can do simple tone mapping with the -scale parameter.

A special note regarding SPOT6/7: 12 bit orthorectified (level 2 processing) does not appear to available as a standard product, so to get 8 & 12 it might be necessary to purchase both Standard and Primary products. See SPOT image user guide, particularly the descriptions of different processing levels in section 2.3.

---

This answer summarized from the contributions of @rs_burner, @spacedman, @nils-erik-jørgensen, Frank Warmerdam, and Patrick Young. Thank you!

Answer 4

Roughly you can say that we lose 4 bits when someone do things like that. Most satellite imagery will be in 16 bit format (Sentinel, Landsat, WorldView etc) preserving the 12 bit data format. Kompsat has 14 bit data presented in 16 bit format. 222*2 = 16 times 4 channels = 64. mathematically you loose all your data and sit back with 1/64 part of the original data. Or you receive 1.5% of the original data. People claim that the loss is not as huge as this math shows because the sensor do not use the whole range of numbers. So maybe you only lose 97% of the original data. For mapping people it is not important. If you want to use machine learning, you lose the possibility to classify your data.

There is a reason why the sensor is 12 bit and not 8 bit. Why spend billions on a camera when you just need a GoPro camera. So get your satellite data from a professional supplier. They give you 16 bit TIFF. Maybe you have to pay for it, but at least you can use the data.

Spacedman: 'perhaps the highest and lowest parts of the image can be encoded with less dynamic range, taking fewer bits, by a non-linear scaling of the raw data' What if the data you want to look at are in the highest or lowest parts? Who can know this?