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)
Change History (8)
comment:1 by , 17 years ago
Cc: | added |
---|
comment:2 by , 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.
follow-up: 4 comment:3 by , 17 years ago
Keywords: | geotiff gdal added |
---|---|
Owner: | set to |
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.
comment:4 by , 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 , 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 , 17 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
I believe this is the same issue as reported in:
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.
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.