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