Opened 17 years ago

Closed 17 years ago

#268 closed defect (invalid)

TIFF Not Rendering When Bottom of Image Crosses Current Window

Reported by: crispinatime Owned by: warmerdam
Priority: medium Milestone: 2.0
Component: General Version: 1.2.0
Severity: major Keywords: geotiff gdal
Cc: warmerdam External ID:

Description

I have a folder of TIFF (Packbits) images accessed via an unmanaged alias. If I connect to any individual file (or the folder) then I can zoom and pan around all of the image(s) BUT if the bottom edge of the image crosses my map window the partial TIFF that should be shown is *not* rendered. I can pan North until the whole of the TIFF image is within the window bounds and the image renders correctly again. Crossing other edges is OK.

I re-saved my TIFFs as GIF and the issue is resolved.

It should be easy to recreate but I can post a large sample image if required.

Attachments (2)

NS40NE_TIF_GDALinfo.txt (5.2 KB ) - added by crispinatime 17 years ago.
gdalInfo of TIFF
NS40NE.TFW (53 bytes ) - added by crispinatime 17 years ago.
TFW for problem file

Download all attachments as: .zip

Change History (8)

comment:1 by warmerdam, 17 years ago

Cc: warmerdam added

Hi,

Would it be possible to get a "gdalinfo" report on the TIFF file in question? If you don't have gdalinfo already, you can use install FWTools (http://fwtools.maptools.org) to get gdalinfo.

Generally speaking, I find this behavior quite surprising.

by crispinatime, 17 years ago

Attachment: NS40NE_TIF_GDALinfo.txt added

gdalInfo of TIFF

by crispinatime, 17 years ago

Attachment: NS40NE.TFW added

TFW for problem file

comment:2 by crispinatime, 17 years ago

Hi,

Thanks for your time - it looks (from CPL_DEBUG-ON) that there is an issue with the final line of the image - so whenever the bottom of the image crosses the window there is a failure. I have used this image in previous MG6.5 releases and (from memory) it comes direct from the supplier - in this case Ordnance Survey.

On a connected note, why when my TFW says the image origin is at X,Y does MG/GDAL then use this as the centr of the upper-left pixel and offset the upper-left by half-a-unit. Is this expected behaviour? Is this consistent with my underatanding of how the image is processed in other systems reading the georef files?

Regards,

Crispin

ERROR 1: IReadBlock failed at X offset 16, Y offset 78 ERROR 1: D:\Data\EAC\StreetMappig_TINY/NS40NE.tif:PackBitsDecode: Not enough dat a for scanline 2048 ERROR 1: TIFFReadEncodedTile() failed.

ERROR 1: IReadBlock failed at X offset 16, Y offset 78 ERROR 1: D:\Data\EAC\StreetMappig_TINY/NS40NE.tif:PackBitsDecode: Not enough dat a for scanline 2048 ERROR 1: TIFFReadEncodedTile() failed.

ERROR 1: IReadBlock failed at X offset 16, Y offset 78 GDAL: GDALClose(D:\Data\EAC\StreetMappig_TINY/NS40NE.tif)

GDAL: 26501 block reads on 6241 block band 1 of D:\Data\EAC\StreetMappig_TINY/NS 40NE.tif.

comment:3 by warmerdam, 17 years ago

Keywords: geotiff gdal added
Owner: set to warmerdam

Crispin,

The half pixel offset is due to world files referencing the center of the top left pixel as the origin while GDAL references the top left corner of the top left pixel as the origin. So, no problem.

Can you provide the TIFF file for me to test with? I believe this is a known problem with files that have incomplete final strips, and is essentially a bug in libtiff.

in reply to:  3 comment:4 by crispinatime, 17 years ago

Can you provide the TIFF file for me to test with?

Can I send this to your email address (e.g. the pobox account or another) as I should not be posting the file on a public site. If you need my email address our old (pre-1Spatial) accounts are still live and easier to find at http://www.ime.co.uk/ime/content/general/staff.jsp

comment:5 by warmerdam, 17 years ago

Crispin,

Files of up to about 10MB may be emailed to my warmerdam@… account. Larger files should be staged somewhere for me to fetch.

comment:6 by warmerdam, 17 years ago

Resolution: invalid
Status: newclosed

I believe this is the same issue as reported in:

http://trac.osgeo.org/gdal/ticket/1179

I am going to close this bug report, and pursue the issue there since it is really a GDAL library problem, and seemingly not specific to MapGuide in any way.

Note: See TracTickets for help on using tickets.