Opened 16 years ago
Closed 16 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 by , 16 years ago
| Cc: | added |
|---|---|
| Component: | default → GDAL_Raster |
| Status: | new → assigned |
comment:2 by , 16 years ago
| Milestone: | → 1.6.0 |
|---|---|
| Resolution: | → fixed |
| Status: | assigned → closed |
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.
Even,
I'll dig into this on my PPC Mac.