<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
On 15/07/15 19:02, Even Rouault wrote:<br>
<span style="white-space: pre;">><br>
>> Thanks Even,<br>
>><br>
>> I have submitted
<a class="moz-txt-link-rfc2396E" href="https://trac.osgeo.org/gdal/ticket/6036"><https://trac.osgeo.org/gdal/ticket/6036></a> with an<br>
>> attached TIFF<br>
>> infested with `-nan` values.<br>
>><br>
>> While researching this I cam across this question<br>
>> <a class="moz-txt-link-rfc2396E" href="http://stackoverflow.com/q/3772835"><http://stackoverflow.com/q/3772835></a> which might
contain some information of<br>
>> interest.<br>
><br>
> Hum looking more closely at representation of nan values in
IEEE754, there is <br>
> at least 12 million different ways of representing nan for a
32bit floating <br>
> point value. And you can indeed have signed NaN... But I'm
not sure it is <br>
> really useful to set "-nan" as the declared nodata value (it
is stored as a <br>
> string in GeoTIFF) since even 2 NaN values that could be
printed in text form <br>
> as "-nan" could have a different binary representation.<br>
><br>
> The parts of GDAL that test pixel values against nodata have
normally a <br>
> special behaviour to test the pixel values against nodata,
when the nodata <br>
> value is one of the NaN values, so I wouldn't expect this
apparent <br>
> inconsistency to cause problems<br>
><br>
> For example when running gdalinfo -stats on your file, I get
:<br>
><br>
> ERROR 1: negative-nan-example.tif, band 1: Failed to compute
statistics, no <br>
> valid pixels found in sampling.<br>
><br>
> Which is expected since all pixels are set to nan (-nan
yeah...), so <br>
> ComputeStatistics() actually managed to match the declared
nan with the -nan <br>
> as pixel values. (which is quite ironical since a property of
nan is that nan <br>
> != nan, but here nan ~= -nan ;-) )</span><br>
<br>
Firstly thanks for looking into this. Secondly, wow - 12 million
different ways<br>
to say that's not a number and still not be completely convincing.
From a<br>
practical point of view that all seems fairly crazy!<br>
<br>
<span style="white-space: pre;">><br>
><br>
> Did you run into particular problems beyond this apparent
mismatch ?</span><br>
<br>
Yes, the issue that brought this to light was that I am trying to
convert the<br>
single band TIFF containing -nan values to a colour relief along the
following<br>
lines:<br>
<br>
gdaldem color-relief single-band.tif colour-relief.ramp
colour-relief.tif -alpha -of GTiff -co COMPRESS=DEFLATE -co
PREDICTOR=1 -co ZLEVEL=9 -co TILED=YES<br>
<br>
colour-relief.ramp is as follows:<br>
<br>
382 0 1 36<br>
171 12 15 118<br>
114 33 109 158<br>
57 63 184 105<br>
5 120 234 50<br>
0 254 255 125 <br>
nv 0 0 0 0<br>
<br>
I was expecting the -nan values to be interpreted as nv and
therefore made<br>
transparent in colour-relief.tif. However, they were assigned the
RGB value<br>
0,1,36 i.e. the maximum value in the ramp!<br>
<br>
I can provide a bite sized example of the dataset that contains some
real values<br>
if that is helpful.<br>
<br>
Best regards,<br>
<br>
Homme<br>
<br>
<span style="white-space: pre;">><br>
> Even<br>
></span><br>
<br>
<br>
</body>
</html>