[gdal-dev] Possible bug in gdaldem color-relief, zero always transparent

[Matt Williamson]

Hmm! Thanks, that is definitely not something I would have checked--However, I don't think it's my problem. I checked my .clr file I'm running, and I don't see anything out of the ordinary:

$ xxd T_SFC.clr 
0000000: 2d34 302e 3020 2031 3237 2032 3535 2032  -40.0  127 255 2
0000010: 3535 0a2d 3330 2e31 2020 3139 3220 3235  55.-30.1  192 25
...
0000070: 320a 2d31 302e 3020 2020 3634 2020 3634  2.-10.0   64  64
0000080: 2020 3634 0a2d 302e 3120 2020 3132 3720    64.-0.1   127 
0000090: 3132 3720 3132 3720 3235 350a 3020 2020  127 127 255.0   
00000a0: 2020 2020 3634 2020 3634 2031 3237 2032      64  64 127 2
00000b0: 3535 0a30 2e31 2020 2020 2036 3420 2036  55.0.1     64  6
00000c0: 3420 3132 3720 3235 350a 392e 3920 2020  4 127 255.9.9   
...

You ran it on a dataset with zeroes? Everything works properly for me except the zero values in the source GeoTIFF--everything else is colored as expected, with the correct alpha values.

In fact (I probably should have mentioned this), when I first noticed the problem, I did not have the 0.1 value line in there, and it was actually interpolating the alpha from 0-255 between the values 0 and 9.9 (i.e. it got progressively more opaque between those values).

Also, FWIW, I encountered this issue under 1.7.0 and upgraded to 1.7.1 to make sure it wasn't a bug fixed in .1, but no, it does it in both versions.

-Matt


On Feb 23, 2010, at 1:50 PM, Even Rouault wrote:

> I think the problem lies in you .clr file. I pasted the content from the email 
> into a file, and when looking with an hexadecimal editor, I see that there 
> are several instances of a strange hexadecimal sequence "0xc2 0xa0" that is 
> used as a separator between the figures. If your original .clr file has 
> really those, and they are not an artifact of pasting into the email, then 
> this is the cause of your issue, as the parser only supports spaces, 
> tabulations, commas or colons. When fixing the clr file, I get expected 
> results.
> 
> Le Tuesday 23 February 2010 20:12:14 Matt Williamson, vous avez écrit :
>> Hello List,
>> 
>> I may have encountered a bug in gdaldem color-relief. When I use it to
>> apply a color map to a GeoTIFF band that has positive and negative and zero
>> values, the zero pixels are always translated as having alpha 0, even if
>> the color map file explicitly states zero values should be opaque.
>> 
>> e.g., I'm using a command like this one:
>> 
>> gdaldem color-relief MinT_SFC.EPSG_900913.tif colortables/T_SFC.clr
>> pngs/test.png -alpha -b 1 -of PNG
>> 
>> and a segment of the color table file reads as follows:
>> 
>> -10.0   64  64  64
>> -0.1   127 127 127 255
>> 0       64  64 127 255
>> 0.1     64  64 127 255
>> 9.9    127 127 192
>> 
>> I can provide a sample dataset that produces this problem, but I'm not sure
>> what the etiquette on attaching files in this list is.
>> 
>> Can anyone confirm they see the same behavior? I'm using 1.7.1, compiled
>> locally. The behavior appears whether my -of is PNG or GTiff, so I don't
>> think it's a driver issue.
>> 
>> I know this has nothing to do with generating elevation maps, but it's too
>> convenient a way to apply a color map to float data--I had been using
>> mapserver just to make colorized PNGs, and gdaldem is so much cleaner.
>> 
>> Thanks!
>> 
>> -Matt
>> 
>> _______________________________________________
>> gdal-dev mailing list
>> gdal-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
> 
>