Opened 12 years ago

Closed 12 years ago

#2361 closed defect (fixed)

[GTiff] GTiffOddBitsBand::IReadBlock fails for some data types on big endian hosts

Reported by: Even Rouault Owned by: warmerdam
Priority: normal Milestone: 1.6.0
Component: GDAL_Raster Version: 1.5.0
Severity: normal Keywords: gtiff odd bits band
Cc: dron

Description

On epimetheus, the new test files (int24.tif and float24.tif in gcore/tiff_read.py) are not read with the correct checksum. This looks very much as an endianness problem. But it's a bit strange that int10.tif, int12.tif and float16.tif don't fail.

Change History (2)

comment:1 Changed 12 years ago by warmerdam

Cc: dron added
Component: defaultGDAL_Raster
Status: newassigned

Even,

I'll dig into this on my PPC Mac.

comment:2 Changed 12 years ago by warmerdam

Milestone: 1.6.0
Resolution: fixed
Status: assignedclosed

libtiff provides swapping to local machine order for 24bit values but the GTiffOddBitsBand::IReadBlock() code did not anticipate this being done. I have added a special case for 24bit integer and floating point data to account for this.

Change made in trunk (r14485). No corresponding change in 1.5 branch since 24bit files are very esoteric.

Note: See TracTickets for help on using tickets.