Changes between Initial Version and Version 1 of Ticket #1732


Ignore:
Timestamp:
Aug 1, 2007, 3:34:33 PM (17 years ago)
Author:
warmerdam
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #1732

    • Property Keywords hfa added
    • Property Status newassigned
    • Property Component defaultGDAL_Raster
    • Property Milestone1.5.0
  • Ticket #1732 – Description

    initial v1  
    11I 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:
    22
     3{{{
    34            sEntry.c1 = (short) (padfRed[iColor]   * 255);
    45            sEntry.c2 = (short) (padfGreen[iColor] * 255);
     
    67            sEntry.c4 = (short) (padfAlpha[iColor]  * 255);
    78            poCT->SetColorEntry( iColor, &sEntry );
     9}}}
    810
    911Currently, 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]. 
     
    1416
    1517
    16 REPRO
    17 ================
     18== REPRO ==
     19
    1820I'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.
    1921
    2022A short demo of the FP rounding issue based on the second entry in the CLUT:
     23{{{
    2124        double df = 0.0039215686274509803; // taken from CLUT, entry #2.
    2225        short s;
     
    2427        printf ("df = %lf, s = %d\n", df, s);  // linux/gcc32, s==0; win32/vc8 s==1
    2528        return 0;
     29}}}
    2630
    27 ============
    2831I  verified that ArcMap 9.2 will read this image and indicates a true greyscale palette!