[gdal-dev] NITF 1.5.0 nodata value is wrong.

[Even Rouault]

Martin,

yes, there have been a few changes to improve the handling of NITF frames from 
CADRG products that might probably explain what you observe.
In fact if you look at NITFRasterBand::GetNoDataValue, you'll see that the 
value -1e10 means "nodata value not set". So -1e10 is (and was) definitely 
not a "correct value". You should first look at the value of  *pbSuccess to 
see if the return value of the method is valid or not.
That said, the value 216 was necessary to introduce so that CADRG files can 
handle transparency well. The empty 256 x 256 tiles are filled with the value 
216, so that we can know that it's nodata. Previous behaviour was to fill 
with indice 0, which is generally for the black color (0,0,0 RGB triplet).
Does this really cause a problem for you ? If you think so and can describe 
what is wrong (apart from the change in the result of GetNoDataValue), 
sending the result of gdalinfo on it, or best the whole file, could help to 
understand what happens.

Best regards,
Even

Le Tuesday 19 February 2008 20:06:50 Martin Chapman, vous avez écrit :
> All,
>
>
>
> In an older version of GDAL the NITF driver reports the no data value of my
> .ntf image as -10000000000.0.  The 1.5.0 NITF driver reports the no data
> value on the same .ntf file as 216.0.  The correct value is -10000000000.0.
> Does anyone have any idea why this is occuring? I will debug in the
> meantime and share the fix if I find one.
>
>
>
> Best regards,
>
> Martin Chapman