Opened 14 years ago
Closed 5 years ago
Last modified 5 years ago
#3253 closed defect (fixed)
EHdr driver cannot read .clr files with holes and negative values
|Reported by:||lpinner||Owned by:||Even Rouault|
Colour table expansion does not seem to honour nodata values. The first colour table entry is being assigned to the lowest pixel value, which in this case is the nodata value (-32768), and it fails at the last pixel value as there is no corresponding colour table entry.
C:\WorkSpace\gdal>gdalinfo --version GDAL 1.6.2, released 2009/07/31 C:\WorkSpace\gdal>gdalinfo testaus.bil Driver: EHdr/ESRI .hdr Labelled Files: testaus.bil testaus.hdr testaus.stx testaus.clr Size is 415, 340 Coordinate System is `' Origin = (112.505000000000000,-10.004999999999999) Pixel Size = (0.100000000000000,-0.100000000000000) Corner Coordinates: Upper Left ( 112.5050000, -10.0050000) Lower Left ( 112.5050000, -44.0050000) Upper Right ( 154.0050000, -10.0050000) Lower Right ( 154.0050000, -44.0050000) Center ( 133.2550000, -27.0050000) Band 1 Block=415x1 Type=Int16, ColorInterp=Palette Min=-500.000 Max=2000.000 Minimum=-500.000, Maximum=2000.000, Mean=824.100, StdDev=741.800 NoData Value=-32768 Color Table (RGB with 25 entries) 0: 127,40,65,255 1: 154,168,118,255 2: 172,218,120,255 3: 82,77,117,255 4: 245,192,117,255 5: 222,0,86,255 6: 191,173,69,255 7: 14,110,243,255 8: 102,86,25,255 9: 97,139,179,255 10: 211,152,39,255 11: 141,88,211,255 12: 225,127,60,255 13: 128,244,208,255 14: 162,132,156,255 15: 193,78,134,255 16: 202,170,254,255 17: 6,252,240,255 18: 157,235,249,255 19: 183,201,168,255 20: 91,144,146,255 21: 153,252,228,255 22: 243,122,213,255 23: 14,105,160,255 24: 145,97,47,255 C:\WorkSpace\gdal>gdal_translate -of JPEG -expand rgb testaus.bil testexp.jpg Input file size is 415, 340 0ERROR 1: No entry 2000.
Change History (10)
comment:1 by , 14 years ago
by , 14 years ago
comment:2 by , 14 years ago
Sorry, folks. The nodata value is actually zero. Still does not get honoured during colourtable expansion. Test files updated.
comment:3 by , 14 years ago
Even, Any thoughts on this?
comment:4 by , 14 years ago
|Summary:||Color table expansion does honour nodata values → EHdr driver cannot read .clr files with holes and negative values|
the issue is not in the color expansion code. It's in fact a defect of the EHdr driver that doesn't correctly read the .clr file. The code currently ignores the first column of that file which at first sight contains the index value corresponding to the RGB triplet of the 2nd, 3rd and 4th column. It just supposes, without checking, that it's sequentially numbered from 0. But with this dataset, we have 2 problems : the first column is not sequentially numbered from 0 and some indices are negative (this is consistant with the values of the .bil). The first problem could be solved by reading the index and using it when calling SetColorEntry(), but I don't see how the second one can be taken into account with the current color table model that only supports non negative index values... One possibility would be to use a raster attribute table when we detect that the .clr file cannot be correctly reported as a color table object.
comment:5 by , 14 years ago
|Keywords:||EHdr GDALColorTable added|
|Priority:||normal → low|
I concur with your analysis. The GDALColorTable is not ready for this sort of color table, and I doubt implementing it as a RAT would actually accomplish anything useful for anyone. I am inclined to do nothing unless we had some reason to believe that irregular .clr tables that still fit the GDALColorTable model are common. If I we had a real example of one of these we could at least use the first column setting the color entries.
For now I will do nothing.
comment:6 by , 14 years ago
According to the EHdr spec (http://www.esri.com/library/whitepapers/pdfs/eximgav.pdf), color tables with non sequentially numbered index are valid. I've also found that http://www.ngdc.noaa.gov/mgg/topo/elev/esri/clr/ has .clr files with negative values. So in r18126, I've used the value of the first column to set the color entries, but only for positive values. Negative values are just ignored and a CPLDebug warning is issued for the first "invalid" index.
I've found a workaround to do the color expansion of the EHdr file with negative values. The gdaldem utility (new in GDAL 1.7.0) can recognize a .clr file as a valid color table description file ! You just need to add a new line with " 0 0 0 0" and try "gdaldem color-relief testaus.bil testaus.clr testaus_rgb.tif"
comment:7 by , 14 years ago
comment:8 by , 5 years ago
|Status:||new → closed|
comment:9 by , 5 years ago
Ummm... title should actually be "Color table expansion does not honour nodata values", sorry.