Re: [gdal-dev] Rectify TIFF: Difference between applied GCP and warped image
Hi Jukka, you're correct. ArcMap is doing the on-the-fly transformation with the dataset, I applied the gcps using gdal_translate to. With both gdal_warp and ArcMap Rectify I use second order polynomial. I also found, that some areas of my source image are cut out from the gdal_warp destination dataset. Here are my gdalinfos to the files: Input Dataset with gcp: Driver: GTiff/GeoTIFF Files: gdal_translate.tif Size is 6132, 5940 Coordinate System is `' GCP Projection = GCP[ 0]: Id=1, Info= (5734.32993305,4261.44895879) -> (611521.018414,5787817.29357,0) GCP[ 1]: Id=2, Info= (572.485136268,3616.16282333) -> (612191.853158,5789322.98631,0) GCP[ 2]: Id=3, Info= (938.059974162,5259.97607362) -> (611658.464864,5789364.12734,0) GCP[ 3]: Id=4, Info= (399.270774586,4637.53045143) -> (611897.913259,5789465.33066,0) GCP[ 4]: Id=5, Info= (175.9077093,3518.3785654) -> (612261.413077,5789435.00343,0) GCP[ 5]: Id=6, Info= (65.1081071915,1318.06325259) -> (612926.481389,5789252.39979,0) GCP[ 6]: Id=7, Info= (2058.05461478,861.869252792) -> (612872.84906,5788621.71163,0) GCP[ 7]: Id=8, Info= (3197.85958388,934.608945675) -> (612747.965477,5788289.12972,0) GCP[ 8]: Id=9, Info= (4888.93938213,1463.60781341) -> (612426.762337,5787815.07664,0) GCP[ 9]: Id=10, Info= (5126.7206471,3450.97792497) -> (611812.932465,5787930.73745,0) GCP[ 10]: Id=11, Info= (4165.58848947,4831.95198662) -> (611488.508427,5788352.14431,0) GCP[ 11]: Id=12, Info= (1596.03095142,4691.55418917) -> (611766.991386,5789112.70647,0) GCP[ 12]: Id=13, Info= (2611.86113409,5865.48875961) -> (611315.082149,5788919.03108,0) GCP[ 13]: Id=14, Info= (1753.54106193,2650.51125969) -> (612364.509943,5788875.28655,0) GCP[ 14]: Id=15, Info= (3623.30422048,166.767269129) -> (612934.192512,5788086.76226,0) GCP[ 15]: Id=16, Info= (3033.49120733,4610.79484584) -> (611663.462367,5788668.84676,0) Metadata: COLORSPACE=GREYSCALE COMPRESSION_RATE_TARGET=1 VERSION=2 Image Structure Metadata: INTERLEAVE=BAND Corner Coordinates: Upper Left (0.0,0.0) Lower Left (0.0, 5940.0) Upper Right ( 6132.0,0.0) Lower Right ( 6132.0, 5940.0) Center ( 3066.0, 2970.0) Band 1 Block=6132x1 Type=Byte, ColorInterp=Gray Description = Grayscale Metadata: DESCRIPTION=Grayscale Output gdal_warp: Driver: GTiff/GeoTIFF Files: gdal_translate-gdal_warp.tif gdal_translate-gdal_warp.tfw Size is 7464, 7627 Coordinate System is `' Origin = (610977.12658413767,5789708.87666271810) Pixel Size = (0.314972716042089,-0.314972716042089) Metadata: COLORSPACE=GREYSCALE COMPRESSION_RATE_TARGET=1 VERSION=2 Image Structure Metadata: COMPRESSION=LZW INTERLEAVE=BAND Corner Coordinates: Upper Left ( 610977.127, 5789708.877) Lower Left ( 610977.127, 5787306.580) Upper Right ( 613328.083, 5789708.877) Lower Right ( 613328.083, 5787306.580) Center ( 612152.605, 5788507.728) Band 1 Block=256x256 Type=Byte, ColorInterp=Gray Description = Grayscale Metadata: DESCRIPTION=Grayscale Output ArcMap: Driver: GTiff/GeoTIFF Files: gdal_translate-arcmap_rectify.tif gdal_translate-arcmap_rectify.tif.ovr gdal_translate-arcmap_rectify.tfw gdal_translate-arcmap_rectify.tif.aux.xml Size is 5969, 6098 Coordinate System is `' Origin = (610973.23454512621,5789712.96747139470) Pixel Size = (0.3952467,-0.39524700031) Image Structure Metadata: INTERLEAVE=BAND Corner Coordinates: Upper Left ( 610973.235, 5789712.967) Lower Left ( 610973.235, 5787302.751) Upper Right ( 613332.464, 5789712.967) Lower Right ( 613332.464, 5787302.751) Center ( 612152.849, 5788507.859) Band 1 Block=128x128 Type=Byte, ColorInterp=Gray Min=0.000 Max=240.000 Minimum=0.000, Maximum=240.000, Mean=98.616, StdDev=85.272 NoData Value=256 Overviews: 2985x3049, 1493x1525, 747x763, 374x382, 187x191 Metadata: STATISTICS_MAXIMUM=240 STATISTICS_MEAN=98,615651896887 STATISTICS_MINIMUM=0 STATISTICS_STDDEV=85,271724597078 Thanks! Mit freundlichen Grüßen Richard Bischof Landesamt für Geoinformation und Landesvermessung Niedersachsen (LGLN) - Regionaldirektion Hameln-Hannover - Dezernat 2 - Geodatenmanagement Constantinstraße 40, 30177 Hannover Tel.:+49 511 30245-314 Fax: +49 511 30245-360 mailto:richard.bisc...@lgln.niedersachsen.de www.lgln.de/rd-hm -Ursprüngliche Nachricht- Von: gdal-dev [mailto:gdal-dev-boun...@lists.osgeo.org] Im Auftrag von Jukka Rahkonen Gesendet: Dienstag, 12. April 2016 19:34 An: gdal-dev@lists.osgeo.org Betreff: Re: [gdal-dev] Rectify TIFF: Difference between applied GCP and warped image Bischof, Richard lgln.niedersachsen.de> writes: > > Hello there, > > I`m trying to rectify a lots of dataset in tiff format using gdal. I'am using Windows 7 Professional, gdal > 1.11.2 . > > My steps / comm
[gdal-dev] GeoTiff 16bit to 8bit with GDAL 11.x
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). Thanks for your help, Chris -- 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
Re: [gdal-dev] GeoTiff 16bit to 8bit with GDAL 11.x
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 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
