Changes between Initial Version and Version 1 of Ticket #1732
- Timestamp:
- Aug 1, 2007, 3:34:33 PM (17 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #1732
- Property Keywords hfa added
- Property Status new → assigned
- Property Component default → GDAL_Raster
- Property Milestone → 1.5.0
-
Ticket #1732 – Description
initial v1 1 1 I was chasing down an issue with GDAL's support for palettized Imagine files and think I found a defect in HFARasterBand. In the construtor we convert from a 0..1 double to a 0..255 short. But we do so by truncation: 2 2 3 {{{ 3 4 sEntry.c1 = (short) (padfRed[iColor] * 255); 4 5 sEntry.c2 = (short) (padfGreen[iColor] * 255); … … 6 7 sEntry.c4 = (short) (padfAlpha[iColor] * 255); 7 8 poCT->SetColorEntry( iColor, &sEntry ); 9 }}} 8 10 9 11 Currently, this code suffers from two difficulties: (a) it gives different answers on different platforms (b) rounding rather than truncation would seem to be the natural way to map from [0..1] to [0..255]. … … 14 16 15 17 16 REPRO 17 ================ 18 == REPRO == 19 18 20 I'm attaching a small repro image "grey.img." Despite the name, it contains an RGB lookup table. Under linux/gcc3.2 the lookup table is not quite grey; under win32/vc8 it creates slightly different not-quite grey lookup table. I've confirmed the differences are due to FP rounding. Looking at the values read from the table and the name of the file, the obvious intent is that the table be an RGB palette that implements gray scale. Unfortunately, I used application level printf() calls to dump the entries in the table. 19 21 20 22 A short demo of the FP rounding issue based on the second entry in the CLUT: 23 {{{ 21 24 double df = 0.0039215686274509803; // taken from CLUT, entry #2. 22 25 short s; … … 24 27 printf ("df = %lf, s = %d\n", df, s); // linux/gcc32, s==0; win32/vc8 s==1 25 28 return 0; 29 }}} 26 30 27 ============28 31 I verified that ArcMap 9.2 will read this image and indicates a true greyscale palette!