Ticket #2361 (closed defect: fixed)

Opened 3 months ago

Last modified 3 months ago

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

Reported by: rouault Assigned to: 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

05/09/08 12:47:17 changed by warmerdam

  • status changed from new to assigned.
  • cc set to dron.
  • component changed from default to GDAL_Raster.

Even,

I'll dig into this on my PPC Mac.

05/18/08 00:55:21 changed by warmerdam

  • status changed from assigned to closed.
  • resolution set to fixed.
  • milestone set to 1.6.0.

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.