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)
Change History (13)
by , 16 years ago
Attachment: | i8u_c_i.img added |
---|
by , 16 years ago
Attachment: | correct.bmp added |
---|
comment:1 by , 16 years ago
Keywords: | HFA added |
---|---|
Owner: | changed from | to
Status: | new → assigned |
comment:2 by , 16 years ago
comment:3 by , 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:5 by , 15 years ago
Milestone: | 1.5.4 → 1.6.0 |
---|---|
Resolution: | → fixed |
Status: | assigned → closed |
comment:6 by , 15 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
Found another case of unique value table problem, See attached same image and screenshot.
by , 15 years ago
Attachment: | csanjack_lr_screenshot.JPG added |
---|
comment:7 by , 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:9 by , 9 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
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.
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 :
We should report:
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: