[gdal-dev] Possible bug in gdaldem color-relief,
zero always transparent
even.rouault at mines-paris.org
Tue Feb 23 17:55:48 EST 2010
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.
> 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
More information about the gdal-dev