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 <[email protected]> > > 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 _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
