<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,sans-serif">Patrick,</div><div class="gmail_default" style="font-family:arial,sans-serif"><br></div></div><div class="gmail_default" style="font-family:arial,sans-serif">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. </div><div class="gmail_default" style="font-family:arial,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,sans-serif">Beyond nit-picking, I think my point is: </div><div class="gmail_default" style="font-family:arial,sans-serif"> - 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.</div><div class="gmail_default" style="font-family:arial,sans-serif"> - 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.</div><div class="gmail_default" style="font-family:arial,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,sans-serif">Best regards,</div><div class="gmail_default" style="font-family:arial,sans-serif">Frank</div><div class="gmail_default" style="font-family:arial,sans-serif"><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 17, 2021 at 11:13 PM Patrick Young <<a href="mailto:patrick.mckendree.young@gmail.com">patrick.mckendree.young@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">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 <a href="https://en.wikipedia.org/wiki/Tone_mapping#:~:text=Tone%20mapping%20is%20a%20technique,a%20more%20limited%20dynamic%20range." target="_blank">tone mapping</a>. Planet had a nice blog post describing how they manually convert their imagery to 8bit RGB <a href="https://www.planet.com/pulse/color-correction/" target="_blank">here</a>. If you were using the imagery for analytic things (e.g. converting pixel values to reflectance) you'd probably not want the 8bit product.<div><br></div><div>To get GDAL in the mix, note that gdal_translate can do simple tone mapping for you: <a href="https://gdal.org/programs/gdal_translate.html#cmdoption-gdal_translate-scale" target="_blank">https://gdal.org/programs/gdal_translate.html#cmdoption-gdal_translate-scale</a><br><div><br></div><div>Patrick<br><div><br></div><div><br><div><br></div><div><br></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 17, 2021 at 3:23 PM <<a href="mailto:Matt.Wilkie@yukon.ca" target="_blank">Matt.Wilkie@yukon.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div lang="EN-CA">
<div>
<p>SPOT 6/7 satellite imagery is captured with a dynamic range of 12 bits per pixel per channel (<a href="https://eos.com/spot-6-and-7/" target="_blank">ref</a>). 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?<u></u><u></u></p>
<p>I'm wondering if we should be altering our request for purchase specifications to deliver the full bit depth.<u></u><u></u></p>
<p><em>Although I'm referencing SPOT imagery specifically the question is general and really applies to any satellite or sensor system.</em><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:10pt;font-family:Arial,sans-serif">Cross-post:
<a href="https://gis.stackexchange.com/questions/390315/what-is-lost-when-converting-12-bit-imagery-to-8-bit" target="_blank">
https://gis.stackexchange.com/questions/390315/what-is-lost-when-converting-12-bit-imagery-to-8-bit</a><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:10pt;font-family:Arial,sans-serif"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:10pt;font-family:Arial,sans-serif"><u></u> <u></u></span></p>
<p class="MsoNormal" style="margin-top:4pt;line-height:115%;vertical-align:middle">
<b><span lang="EN-US" style="font-size:9pt;line-height:115%;font-family:Arial,sans-serif">Matt Wilkie</span></b><span lang="EN-US" style="font-size:9pt;line-height:115%;font-family:Arial,sans-serif"><u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:9pt;font-family:Arial,sans-serif">Geomatics Analyst<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:9pt;font-family:Arial,sans-serif">Environment
<span style="color:rgb(46,116,181)">|</span> Technology, Innovation and Mapping<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:9pt;font-family:Arial,sans-serif">T 867-667-8133
<span style="color:rgb(46,116,181)">|</span> </span><u><span style="font-size:9pt;font-family:Arial,sans-serif"><a href="http://yukon.ca/" target="_blank"><span lang="EN-US" style="color:windowtext">Yukon.ca</span></a><u></u><u></u></span></u></p>
<p class="MsoNormal"><i><span style="font-size:9pt;font-family:Arial,sans-serif">Hours: 08:30-16:30, Tue-Wed: Office, Thu-Fri: Remote.<u></u><u></u></span></i></p>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
</blockquote></div>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><font face="monospace">---------------------------------------+--------------------------------------<br>I set the clouds in motion - turn up | Frank Warmerdam, <a href="mailto:warmerdam@pobox.com" target="_blank">warmerdam@pobox.com</a><br>light and sound - activate the windows | +1 650-701-7823<br>and watch the world go round - Rush | Geospatial Software Developer</font></div></div></div></div></div></div>