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

[Christine Waigl]

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.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.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 - cwaigl at alaska.edu -  +1-907-474-5483 - Skype:
cwaigl_work
Geophysical Institute, UAF, 903 Koyukuk Drive, Fairbanks, AK 99775-7320, USA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20160414/72b57a69/attachment.html>