Patrick, FWIW, Rob's post is on the process he uses in Photoshop to prepare images for various venues. For imagery published through the platform we (Planet) do not use per-image white-point and black-point (or we would not have day to day, and scene to scene consistency). We do apply color curves Rob prepared in our automated process but with "fixed" black/white point which results in an automated 8bit RGB product that tends to be very suboptimal in dark or bright areas. The imagery Planet shows in our web-explorer interface is served from highly compressed JPEG-in-TIFF adding an additional layer of image damage. :-) While that pains me, we are keeping around nearly 3 billion scenes online at nearly full resolution for fast visualization so some compromises have to be made.
Beyond nit-picking, I think my point is: - given 12bit "rawer" data you have the opportunity to do careful scene dependent conversion to 8bit in a way that best brings out the details available in the source data if you have the time and patience. - having this process done for you in advance by a skilled supplier (perhaps in such a way as to maintain reasonable consistency for large area coverages) may actually save you a lot of work if you mostly just want to fairly generic visualization - and it might even be a better visualization than you would do yourself if you aren't going to do a lot of work. Best regards, Frank On Wed, Mar 17, 2021 at 11:13 PM Patrick Young < patrick.mckendree.yo...@gmail.com> wrote: > I would guess you usually see 8bit RGB images because that is what your > monitor can display. What is lost is a deeper question, per channel you > have to squeeze the original [0 - 4095] pixel value range per channel down > to [0 -255], and there are lots of ways to do it. The problem is sometimes > called tone mapping > <https://en.wikipedia.org/wiki/Tone_mapping#:~:text=Tone%20mapping%20is%20a%20technique,a%20more%20limited%20dynamic%20range.>. > Planet had a nice blog post describing how they manually convert their > imagery to 8bit RGB here <https://www.planet.com/pulse/color-correction/>. > If you were using the imagery for analytic things (e.g. converting pixel > values to reflectance) you'd probably not want the 8bit product. > > To get GDAL in the mix, note that gdal_translate can do simple tone > mapping for you: > https://gdal.org/programs/gdal_translate.html#cmdoption-gdal_translate-scale > > Patrick > > > > > > On Wed, Mar 17, 2021 at 3:23 PM <matt.wil...@yukon.ca> wrote: > >> SPOT 6/7 satellite imagery is captured with a dynamic range of 12 bits >> per pixel per channel (ref <https://eos.com/spot-6-and-7/>). 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.* >> >> Cross-post: >> https://gis.stackexchange.com/questions/390315/what-is-lost-when-converting-12-bit-imagery-to-8-bit >> >> >> >> >> >> *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 >> > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev > -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | +1 650-701-7823 and watch the world go round - Rush | Geospatial Software Developer
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
