Thank you all. This is good information and helps solidify my thinking: we ask for both.
We want to keep getting the processed to 8bit visual imagery as we don’t have the capacity to that in-house for the amount of data we get. However we also want to have 12 bit for those occasions when analysis is primary goal, and we do this also. Cheers, -Matt From: Frank Warmerdam <warmer...@pobox.com> Sent: March 17, 2021 8:29 PM To: Patrick Young <patrick.mckendree.yo...@gmail.com> Cc: Matt.Wilkie <matt.wil...@yukon.ca>; gdal dev <gdal-dev@lists.osgeo.org> Subject: Re: [gdal-dev] What is lost when converting 12 bit imagery to 8 bit? 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<mailto: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<mailto: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<https://imsva91-ctp.trendmicro.com:443/wis/clicktime/v1/query?url=http%3a%2f%2fyukon.ca&umid=4069A3E7-BDC7-3505-BA97-48548791B267&auth=c132af8ee7c9d1278d61a701569070a095ce962e-48dacb3d842116a19074c604a613050cec3e1729> 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
