[gdal-dev] GeoTiff 16bit to 8bit with GDAL 11.x

[Even Rouault]

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