Geotiffs are shown striped with HEAD

[ajolma]

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.

[rouault]

Could you provide more information on your geotiff (gdalinfo on it for example), or better attach it to your ticket ?

[ajolma]

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

[ajolma]

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.

[warmerdam]

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.

[ajolma]

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.

[ajolma]

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á.

[rouault]

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