The position I've moved to after reading through and thinking about all the responses here and gdal-dev<https://lists.osgeo.org/mailman/listinfo/gdal-dev> (here<http://osgeo-org.1560.x6.nabble.com/gdal-dev-What-is-lost-when-converting-12-bit-imagery-to-8-bit-tt5482829.html>) 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<https://en.wikipedia.org/wiki/Tone_mapping#:%7E:text=Tone%20mapping%20is%20a%20technique,a%20more%20limited%20dynamic%20range.>. Planet has a blog post describing how to manually convert single scene imagery to 8bit RGB at A Hands-On Guide to Color Correction<https://www.planet.com/pulse/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<https://gis.stackexchange.com/questions/tagged/gdal-translate> can do simple tone mapping for you with the -scale<https://gdal.org/programs/gdal_translate.html#cmdoption-gdal_translate-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<https://earth.esa.int/eogateway/documents/20142/37627/SPOT-6-7-imagery-user-guide.pdf>, particularly the descriptions of different processing levels in section 2.3. ________________________________ This answer summarized from the contributions of @rs_burner, @spacedman, @Vince, Frank Warmerdam, and Patrick Young. Thank you! Matt Wilkie Geomatics Analyst Environment | Technology, Innovation and Mapping T 867-667-8133 | Yukon.ca<http://yukon.ca/> Hours: 08:30-16:30, Tue-Wed: Office, Thu-Fri: Remote.
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
