<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace">Hi Even,</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">Thanks so much for this quick and thorough response. The workaround made it possible to fix my code, and I've extended it to multi-band GeoTIFF files (my RGB composites) as</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace"><div class="gmail_default">gdal_translate -ot Byte -of vrt -b 1 -b 1 -b 2 -b 3 -scale_4 -scale_1 -scale_2 -scale_3 infile.tif infile_8bit.vrt</div><div class="gmail_default">gdal_translate -b 2 -b 3 -b 4 infile_8bit.vrt infile_8bit.tif</div><div class="gmail_default"><br></div><div class="gmail_default">Un grand merci!</div><div class="gmail_default"><br></div><div class="gmail_default">Chris</div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 13, 2016 at 1:32 PM, Even Rouault <span dir="ltr"><<a href="mailto:even.rouault@spatialys.com" target="_blank">even.rouault@spatialys.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Le mercredi 13 avril 2016 22:26:45, Christine Waigl a écrit :<br>
> Hi all,<br>
><br>
> I have been using the GDAL command line tools to pre-process various kinds<br>
> of remote sensing imagery datasets in GeoTIFF format. This includes<br>
> resampling 16 bit images (eg. from Landsat 8) to 8-bit and to combine bands<br>
> into RBG composites.<br>
><br>
> In GDAL 11.4 (and previous 11.x that I tried), this doesn't work any more:<br>
><br>
> gdal_translate -ot Byte -scale [sceneID]_Bn.tif [sceneID]_8bit_Bn.tif<br>
><br>
> ​I usually apply this to the already clipped RGB composites, but digging<br>
> deeper, even for single-band images what seems to be happening is that the<br>
> -scale option doesn't correctly calculates the source range:<br>
><br>
><br>
</span>>    - If I use the command above, or with -scale_1, the whole output file<br>
<span class="">>    has a value 0 for each pixel<br>
</span>>    - If I use the "-b 1 -scale", the whole output file has a value 255 at<br>
>    each pixel<br>
>    - If I use "-scale src_min src_max" with a manually inserted src_min and<br>
<span class="">>    src_max, I get a reasonable result (though not necessarily identical to<br>
> the GDAL result with automatically calculated min and max.<br>
><br>
><br>
> What is driving me absolutely bonkers, though, is that *occasionally* the<br>
> command "-b 1 -scale" DOES produce a correct 8-bit file. It's not<br>
> reproducible, though: if I delete all 8bit files and re-run the script over<br>
> a whole set of 16 bit files, a whole different file may be resampled<br>
> correctly.<br>
><br>
> With GDAL 2.0.2, my old script (written when GDAL was at 1.8.x on my<br>
> machine) seems to be working at the moment, but my main system is currently<br>
> at 11.4, and I have a reason not to upgrade right away. Is there a way to<br>
> make it work with 11.4? I could run gdalinfo first and extract min and max<br>
> from the stats, and then feed this into gdal_translate, but I'd like to<br>
> avoid this path if possible. A test file (a file subsetted with<br>
> "gdal_translate -projwin... " from a whole Landsat 8 band) is here:<br>
> <a href="http://www2.gi.alaska.edu/~cwaigl/images/LC80660142015170LGN00_B5_clip.tif" rel="noreferrer" target="_blank">http://www2.gi.alaska.edu/~cwaigl/images/LC80660142015170LGN00_B5_clip.tif</a><br>
> (3.8 MB).<br>
<br>
</span>Christine,<br>
<br>
Thanks for the report. Random issues are often a sign of uninitialized memory and running through Valgrind confirmed it.<br>
And it confirms that the issues exists in all versions starting with 1.11, so the fact<br>
that it runs with 2.0.2 is just luck.<br>
<br>
A workaround is to do the following. Be sure to put -scale_2 *before* -scale_1. And be sure to use -b 1 in the second<br>
gdal_translate as the band 2 scale/offset in the VRT might be junk.<br>
<br>
$ gdal_translate -b 1 -b 1 -scale_2 -scale_1 -ot byte LC80660142015170LGN00_B5_clip.tif out.vrt -of vrt<br>
$ gdal_translate -b 1 out.vrt out.tif<br>
<br>
Fixed per <a href="https://trac.osgeo.org/gdal/ticket/6455" rel="noreferrer" target="_blank">https://trac.osgeo.org/gdal/ticket/6455</a> .<br>
<span class="HOEnZb"><font color="#888888"><br>
Even<br>
<br>
--<br>
Spatialys - Geospatial professional services<br>
<a href="http://www.spatialys.com" rel="noreferrer" target="_blank">http://www.spatialys.com</a><br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div style="color:rgb(0,0,0)"><font face="monospace, monospace"><span style="font-size:12.8px">Christine (Chris) Waigl - </span><a href="mailto:cwaigl@alaska.edu" style="font-size:12.8px;color:rgb(17,85,204)" target="_blank">cwaigl@alaska.edu</a><span style="font-size:12.8px"> -  </span><a value="+19074745483" style="font-size:12.8px;color:rgb(17,85,204)">+1-907-474-5483</a><span style="font-size:12.8px"> - Skype: cwaigl_work</span><br></font></div><div style="color:rgb(0,0,0)"><font face="monospace, monospace">Geophysical Institute, UAF, 903 Koyukuk Drive, Fairbanks, AK 99775-7320, USA</font></div></div></div></div></div>
</div>