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

[Even Rouault]

Le jeudi 14 avril 2016 22:48:23, Christine Waigl a écrit :
> 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

You're likely to hit the bug again with the above. Rather try (basically band 4 of the VRT is the "junk band" ):

gdal_translate -ot Byte -of vrt -b 1 -b 2 -b 3 -b 3 -scale_4 -scale_1 -scale_2 -scale_3 infile.tif infile_8bit.vrt
gdal_translate -b 1 -b 2 -b 3 infile_8bit.vrt infile_8bit.tif


> 
> Un grand merci!
> 
> Chris
> 
> 
> On Wed, Apr 13, 2016 at 1:32 PM, Even Rouault <even.rouault at 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.ti
> > f
> > 
> > > (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

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com