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 >> [email protected] >> http://lists.osgeo.org/mailman/listinfo/gdal-dev > > _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
