Hi Even, 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
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 gdal_translate -b 2 -b 3 -b 4 infile_8bit.vrt infile_8bit.tif Un grand merci! Chris On Wed, Apr 13, 2016 at 1:32 PM, Even Rouault <even.roua...@spatialys.com> wrote: > Le mercredi 13 avril 2016 22:26:45, Christine Waigl a écrit : > > Hi all, > > > > I have been using the GDAL command line tools to pre-process various > kinds > > of remote sensing imagery datasets in GeoTIFF format. This includes > > resampling 16 bit images (eg. from Landsat 8) to 8-bit and to combine > bands > > into RBG composites. > > > > In GDAL 11.4 (and previous 11.x that I tried), this doesn't work any > more: > > > > gdal_translate -ot Byte -scale [sceneID]_Bn.tif [sceneID]_8bit_Bn.tif > > > > I usually apply this to the already clipped RGB composites, but digging > > deeper, even for single-band images what seems to be happening is that > the > > -scale option doesn't correctly calculates the source range: > > > > > > - If I use the command above, or with -scale_1, the whole output file > > has a value 0 for each pixel > > - If I use the "-b 1 -scale", the whole output file has a value 255 at > > each pixel > > - If I use "-scale src_min src_max" with a manually inserted src_min > and > > src_max, I get a reasonable result (though not necessarily identical > to > > the GDAL result with automatically calculated min and max. > > > > > > What is driving me absolutely bonkers, though, is that *occasionally* the > > command "-b 1 -scale" DOES produce a correct 8-bit file. It's not > > reproducible, though: if I delete all 8bit files and re-run the script > over > > a whole set of 16 bit files, a whole different file may be resampled > > correctly. > > > > With GDAL 2.0.2, my old script (written when GDAL was at 1.8.x on my > > machine) seems to be working at the moment, but my main system is > currently > > at 11.4, and I have a reason not to upgrade right away. Is there a way to > > make it work with 11.4? I could run gdalinfo first and extract min and > max > > from the stats, and then feed this into gdal_translate, but I'd like to > > avoid this path if possible. A test file (a file subsetted with > > "gdal_translate -projwin... " from a whole Landsat 8 band) is here: > > > http://www2.gi.alaska.edu/~cwaigl/images/LC80660142015170LGN00_B5_clip.tif > > (3.8 MB). > > Christine, > > Thanks for the report. Random issues are often a sign of uninitialized > memory and running through Valgrind confirmed it. > And it confirms that the issues exists in all versions starting with 1.11, > so the fact > that it runs with 2.0.2 is just luck. > > 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 > gdal_translate as the band 2 scale/offset in the VRT might be junk. > > $ gdal_translate -b 1 -b 1 -scale_2 -scale_1 -ot byte > LC80660142015170LGN00_B5_clip.tif out.vrt -of vrt > $ gdal_translate -b 1 out.vrt out.tif > > Fixed per https://trac.osgeo.org/gdal/ticket/6455 . > > Even > > -- > Spatialys - Geospatial professional services > http://www.spatialys.com > -- Christine (Chris) Waigl - cwa...@alaska.edu - +1-907-474-5483 - Skype: cwaigl_work Geophysical Institute, UAF, 903 Koyukuk Drive, Fairbanks, AK 99775-7320, USA
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev