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

[Even Rouault]

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 at lists.osgeo.org
> >> http://lists.osgeo.org/mailman/listinfo/gdal-dev