Hum, then I have no clue. Yes I tested with a dataset with zeros. You can file a ticket on Trac with the dataset and the .clr file attached, provided that the dataset is not too big (no more than 1 MB). Otherwise, you'll have to provide a link to the dataset.
Le Tuesday 23 February 2010 22:26:44 Matt Williamson, vous avez écrit : > 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@lists.osgeo.org > >> http://lists.osgeo.org/mailman/listinfo/gdal-dev _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev