#1806 closed defect (invalid)
Geotiffs are shown striped with HEAD
Reported by: | Ari Jolma | Owned by: | warmerdam |
---|---|---|---|
Priority: | high | Milestone: | |
Component: | GDAL_Raster | Version: | unspecified |
Severity: | critical | Keywords: | gtiff |
Cc: | Even Rouault, Mateusz Łoskot |
Description
Somewhere after revision 11982 the geotiff driver has been broken. With the 11982 I get a large geotiff nicely on screen but with the HEAD the same geotiff looks like it is missing every second horizontal scanline. I read the overview from the geotiff using GDALRasterIO.
Change History (7)
comment:1 by , 17 years ago
comment:2 by , 17 years ago
example 1:
Driver: GTiff/GeoTIFF Files: clc_fi25m.tif Size is 28800, 49600 Coordinate System is: LOCAL_CS["unnamed", UNIT["unknown",1]] Origin = (3020012.500000000000000,7839987.500000000000000) Pixel Size = (25.000000000000000,-25.000000000000000) Metadata: AREA_OR_POINT=Point TIFFTAG_SOFTWARE=Arc/Info TIFFTAG_XRESOLUTION=0.039999999 TIFFTAG_YRESOLUTION=0.039999999 TIFFTAG_RESOLUTIONUNIT=1 (unitless) Corner Coordinates: Upper Left ( 3020012.500, 7839987.500) Lower Left ( 3020012.500, 6599987.500) Upper Right ( 3740012.500, 7839987.500) Lower Right ( 3740012.500, 6599987.500) Center ( 3380012.500, 7219987.500) Band 1 Block=28800x1 Type=Byte, ColorInterp=Palette Color Table (RGB with 256 entries)
example2:
Driver: GTiff/GeoTIFF Files: 20O_DEM2.TIF Size is 3201, 3201 Coordinate System is `' Origin = (3340000.000000000000000,6800000.000000000000000) Pixel Size = (25.000000000000000,-25.000000000000000) Metadata: TIFFTAG_SOFTWARE=Arc/Info TIFFTAG_XRESOLUTION=0.039999999 TIFFTAG_YRESOLUTION=0.039999999 TIFFTAG_RESOLUTIONUNIT=1 (unitless) Corner Coordinates: Upper Left ( 3340000.000, 6800000.000) Lower Left ( 3340000.000, 6719975.000) Upper Right ( 3420025.000, 6800000.000) Lower Right ( 3420025.000, 6719975.000) Center ( 3380012.500, 6759987.500) Band 1 Block=3201x2 Type=UInt16, ColorInterp=Gray
comment:3 by , 17 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
Hmm, damn. Most probably the problem is with my GDAL tree (again). In a completely fresh copy of the HEAD compiled here I don't see the problem. In an old tree updated to HEAD, make cleaned and made again, I now get the error: TIFFReadDirectory: Failed to read directory at offset 0. I use external libtiff from GTK+. These two trees shouln't have any other differences besides the latter (the problem one) having postgis driver included.
comment:4 by , 17 years ago
Cc: | added |
---|---|
Keywords: | gtiff added |
For reference the only likely problem commit since 11982 is r11999 which addressed flushing issues for pixel interleaved datasets in files with overviews - especially I think when building the overviews.
I'm concerned that there may be an issue with older versions of the libtiff code and current GDAL. If you can demonstrate a problem with GDAL trunk and older released versions of libtiff I'd be interested in hearing about it.
comment:5 by , 17 years ago
I said above that the only difference was the postgresql driver. In fact in the faulty compile I had *internal* jpeg, png, and tiff, while in the working version they were *external*. Thus it would seem that the internal ones did not work(?). I'm testing now now with changing the faulty one to use external tiff whether that makes any difference.
comment:6 by , 17 years ago
Ok, I think I know what happened. The faulty build used the tiff headers from the external libtiff although it was using the internal one. It used the external tiff headers because GTK+ include has both zlib.h and tiff headers. configure had determined to use external zlib. Compilation of rikdataset failed because zlib.h was not available. I added -Ipath_to_GTK_include to let it have the zlib.h of the external ... and thus also wrong tiff headers and voilá.
comment:7 by , 17 years ago
I agree with you Frank that the only potential faulty revision after r11982 could be r11999, but it should have no influence on reading geotiffs as its supposed effect is only for writing. But who knows...
Ari, I think the best thing to do to be sure that there's no influence of previous builds would be to : 1) In a directory A, checkout a fresh copy of HEAD and ./configure --with-libtiff=internal, make and do your tests 2) In a directory B, checkout a fresh copy of HEAD and ./configure, make and do your tests
There might be for example some influence of the upgrade to libtiff4 (r11957) while updating your GDAL tree if it dated back this revision.
I've just done the little exercice described above myself and couldn't find any difference
Could you provide more information on your geotiff (gdalinfo on it for example), or better attach it to your ticket ?