<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Ok, got some clarification.<div><div><br></div><div>The _real_ problem was that my dataset did not have it's NODATA value set properly. That being the case, gdaldem apparently assumes 0 is the NODATA value...sort of...if you have an "nv" line in the color table, perhaps. Since I had a "nv" line in my color table, it seems that the setting for 0 and the setting for nv were conflicting. The result was still rather odd, so I might still toss this in the bug tracker and see what you guys think of the behavior.</div><div><br></div><div>I tried removing the nv entry from the color table, and the results were perfectly sensible. Removing the explicit zero entry and leaving the nv setting produced strange results...it seems that in this case, the value for zero gets set to black with the opacity of the nv entry, unless the nv entry has opacity 255, in which case the zero value is the color specified for nv.</div><div><br></div><div>It's probably one of those cases where if you have a nv entry specified for a dataset without a NODATA value, then the behavior is undefined...which is fine, but it took me a while to figure out what the heck was going on. What's really strange to me though is that the <i>actual</i> NODATA pixels (-30000, in this case) also seemed to be taking on the nv color settings, correctly, even though no NODATA value was set...a fluke probably, but whatever.</div><div><br></div><div>On a separate note, the reason I had a file with no NODATA value specified was that I expected gdalwarp to pass-through the NODATA value from the source file if none of the -*nodata switches were present--but it doesn't. I can mostly understand this, but it's somewhat counterintuitive since gdal_translate works this way. Also, I am forced to specify a value for -dstnodata to get it to work--but as it happens I'm trying to process multiple files in batch, which have different output data types, and different source NODATA values...is there a way to have gdalwarp passthrough the NODATA value from the source to the destination file automatically?</div><div><br></div><div>Thanks again,</div><div><br></div><div>-Matt</div><div><br></div><div><br></div></div><div><div>On Feb 23, 2010, at 3:55 PM, Even Rouault wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Hum, then I have no clue. Yes I tested with a dataset with zeros.<br><br>You can file a ticket on Trac with the dataset and the .clr file attached, <br>provided that the dataset is not too big (no more than 1 MB). Otherwise, <br>you'll have to provide a link to the dataset.<br><br>Le Tuesday 23 February 2010 22:26:44 Matt Williamson, vous avez écrit :<br><blockquote type="cite">Hmm! Thanks, that is definitely not something I would have<br></blockquote><blockquote type="cite">checked--However, I don't think it's my problem. I checked my .clr file I'm<br></blockquote><blockquote type="cite">running, and I don't see anything out of the ordinary:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">$ xxd T_SFC.clr<br></blockquote><blockquote type="cite">0000000: 2d34 302e 3020 2031 3237 2032 3535 2032 -40.0 127 255 2<br></blockquote><blockquote type="cite">0000010: 3535 0a2d 3330 2e31 2020 3139 3220 3235 55.-30.1 192 25<br></blockquote><blockquote type="cite">...<br></blockquote><blockquote type="cite">0000070: 320a 2d31 302e 3020 2020 3634 2020 3634 2.-10.0 64 64<br></blockquote><blockquote type="cite">0000080: 2020 3634 0a2d 302e 3120 2020 3132 3720 64.-0.1 127<br></blockquote><blockquote type="cite">0000090: 3132 3720 3132 3720 3235 350a 3020 2020 127 127 255.0<br></blockquote><blockquote type="cite">00000a0: 2020 2020 3634 2020 3634 2031 3237 2032 64 64 127 2<br></blockquote><blockquote type="cite">00000b0: 3535 0a30 2e31 2020 2020 2036 3420 2036 55.0.1 64 6<br></blockquote><blockquote type="cite">00000c0: 3420 3132 3720 3235 350a 392e 3920 2020 4 127 255.9.9<br></blockquote><blockquote type="cite">...<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">You ran it on a dataset with zeroes? Everything works properly for me<br></blockquote><blockquote type="cite">except the zero values in the source GeoTIFF--everything else is colored as<br></blockquote><blockquote type="cite">expected, with the correct alpha values.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">In fact (I probably should have mentioned this), when I first noticed the<br></blockquote><blockquote type="cite">problem, I did not have the 0.1 value line in there, and it was actually<br></blockquote><blockquote type="cite">interpolating the alpha from 0-255 between the values 0 and 9.9 (i.e. it<br></blockquote><blockquote type="cite">got progressively more opaque between those values).<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Also, FWIW, I encountered this issue under 1.7.0 and upgraded to 1.7.1 to<br></blockquote><blockquote type="cite">make sure it wasn't a bug fixed in .1, but no, it does it in both versions.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">-Matt<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">On Feb 23, 2010, at 1:50 PM, Even Rouault wrote:<br></blockquote><blockquote type="cite"><blockquote type="cite">I think the problem lies in you .clr file. I pasted the content from the<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">email into a file, and when looking with an hexadecimal editor, I see<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">that there are several instances of a strange hexadecimal sequence "0xc2<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">0xa0" that is used as a separator between the figures. If your original<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">.clr file has really those, and they are not an artifact of pasting into<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">the email, then this is the cause of your issue, as the parser only<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">supports spaces, tabulations, commas or colons. When fixing the clr file,<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">I get expected results.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Le Tuesday 23 February 2010 20:12:14 Matt Williamson, vous avez écrit :<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Hello List,<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">I may have encountered a bug in gdaldem color-relief. When I use it to<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">apply a color map to a GeoTIFF band that has positive and negative and<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">zero values, the zero pixels are always translated as having alpha 0,<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">even if the color map file explicitly states zero values should be<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">opaque.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">e.g., I'm using a command like this one:<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">gdaldem color-relief MinT_SFC.EPSG_900913.tif colortables/T_SFC.clr<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">pngs/test.png -alpha -b 1 -of PNG<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">and a segment of the color table file reads as follows:<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">-10.0 64 64 64<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">-0.1 127 127 127 255<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">0 64 64 127 255<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">0.1 64 64 127 255<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">9.9 127 127 192<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">I can provide a sample dataset that produces this problem, but I'm not<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">sure what the etiquette on attaching files in this list is.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Can anyone confirm they see the same behavior? I'm using 1.7.1, compiled<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">locally. The behavior appears whether my -of is PNG or GTiff, so I don't<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">think it's a driver issue.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">I know this has nothing to do with generating elevation maps, but it's<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">too convenient a way to apply a color map to float data--I had been<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">using mapserver just to make colorized PNGs, and gdaldem is so much<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">cleaner.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Thanks!<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">-Matt<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">_______________________________________________<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">gdal-dev mailing list<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><a href="http://lists.osgeo.org/mailman/listinfo/gdal-dev">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br></blockquote></blockquote></blockquote><br><br></div></blockquote></div><br></body></html>