Opened 16 years ago

Closed 9 years ago

#2419 closed defect (fixed)

Returning incorrect color table from an IMAGINE image

Reported by: yanchen Owned by: warmerdam
Priority: normal Milestone:
Component: GDAL_Raster Version: 1.5.2
Severity: normal Keywords: HFA
Cc: pgao@…

Description

The color table returned from an IMAGINE image is incorrect. The color table has 75 entries, but the image contains pixel values beyond 0-74, e.g. 80, 114, and etc. Attached are two files, one is a picture of what it should look, and the other is the problem image.

Attachments (4)

i8u_c_i.img (59.2 KB ) - added by yanchen 16 years ago.
correct.bmp (960.1 KB ) - added by yanchen 16 years ago.
csanjack_lr.img (157.2 KB ) - added by gaopeng 15 years ago.
Another test case for incorrect table
csanjack_lr_screenshot.JPG (98.7 KB ) - added by gaopeng 15 years ago.

Download all attachments as: .zip

Change History (13)

by yanchen, 16 years ago

Attachment: i8u_c_i.img added

by yanchen, 16 years ago

Attachment: correct.bmp added

comment:1 by warmerdam, 16 years ago

Keywords: HFA added
Owner: changed from Frank Warmerdam to warmerdam
Status: newassigned

comment:2 by Even Rouault, 16 years ago

This must be somehow related to #974.

In fact, I discovered that at offset 4782 of the file, there is an array of 75 little-endian doubles whose values are : 0, 1, 4, 5, 10, 11, 14, 15, 18, .... Let's call this table "indirection". The real color table that GDAL should report is realColorTable[indirection[i]]=badColorTable[i].

That is to say that instead of reporting :

    0: 0,0,0,255
    1: 0,0,85,255
    2: 0,36,0,255
    3: 0,36,85,255
    4: 0,73,170,255
    5: 0,73,255,255
    6: 0,109,170,255
    7: 0,109,255,255
    8: 0,146,170,255

We should report:

    0: 0,0,0,255
    1: 0,0,85,255
    2: 0,0,0,255
    3: 0,0,0,255
    4: 0,36,0,255
    5: 0,36,85,255
    6: 0,0,0,255
    7: 0,0,0,255
    8: 0,0,0,255
    9: 0,0,0,255
   10: 0,73,170,255
   11: 0,73,255,255
   12: 0,0,0,255
   13: 0,0,0,255
   14: 0,109,170,255
   15: 0,109,255,255
   16: 0,0,0,255
   17: 0,0,0,255
   18: 0,146,170,255

I discovered that by opening the image with ERDAS ViewFinder and saving it back to Imagine again. The latest color table is the one of the saved file.

Extract of hfatest on i8u_c_i.img:

    Descriptor_Table(Edsc_Table) @ 4086 + 4 @ 4214
    + numrows = 75

      #Bin_Function840#(Edsc_BinFunction840) @ 4222 + 1053 @ 4350
      + startBin = 0
      + binCount = 75
      + origBinCount = 75
      + binFunction =
      +     type =
      +         string = `BFUnique'
      +     MIFDictionary = `{1:lnumrows,1:lnumcolumns,1:e13:EGDA_TYPE_U1,EGDA_TYPE_U2,EGDA_TYPE_U4,EGDA_TYPE_U8,EGDA_TYPE_S8,EGDA_TYPE_U16,EGDA_TYPE_S16,EGDA_TYPE_U32,EGDA_TYPE_S32,EGDA_TYPE_F32,EGDA_TYPE_F64,EGDA_TYPE_C64,EGDA_TYPE_C128,datatype,1:e4:EGDA_SCALAR_OBJECT,EGDA_TABLE_OBJECT,EGDA_MATRIX_OBJECT,EGDA_RASTER_OBJECT,objecttype,}Egda_BaseData,{1:LnumBins,1:*bbinLimits,}BFUnique,.'
      +     MIFObject = `K'
      + title =
      +     string = `Unique Value'

      Red(Edsc_Column) @ 5403 + 14 @ 6131
      + numRows = 75
      + columnDataPtr = 5531
      + dataType = real
      + maxNumChars = 0

comment:3 by warmerdam, 16 years ago

I concur with Even. The solution would be to add support for the "BFUnique" binning function which arguably requires us to parse the MIFDictionary describing the MIFObject with the unique values list.

I'll take care of this as time permits.

comment:4 by warmerdam, 15 years ago

Taking a crack at this today.

comment:5 by warmerdam, 15 years ago

Milestone: 1.5.41.6.0
Resolution: fixed
Status: assignedclosed

I have implemented support to read the unique values table in trunk (r15711) and added a test case in the test suite (r15710).

This change is pretty dramatic for retrofitting to 1.5.x branch so I'm not going to do that unless there is a demonstrated need.

by gaopeng, 15 years ago

Attachment: csanjack_lr.img added

Another test case for incorrect table

comment:6 by gaopeng, 15 years ago

Resolution: fixed
Status: closedreopened

Found another case of unique value table problem, See attached same image and screenshot.

by gaopeng, 15 years ago

Attachment: csanjack_lr_screenshot.JPG added

comment:7 by warmerdam, 15 years ago

I have reviewed the file and there is no sign of a colormap in the file. It does have a histogram using BFUnique binning which gets ignored because the histogram code does not understand BFUnique. Did you want me to engineer the same support into the histogram code? Do you think this will affect how the image is displayed? Was there any associated .aux file that was not provided?

comment:8 by warmerdam, 12 years ago

Milestone: 1.6.4

Removing milestone.

comment:9 by Jukka Rahkonen, 9 years ago

Resolution: fixed
Status: reopenedclosed

The latter test file had no color table so it does not belong to this issue. Closing it again. Better to create a new ticket for "csanjack_lr.img" if needed.

Note: See TracTickets for help on using tickets.