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

[Even Rouault]

Martin,

I'm not sure to understand "I think it looks like a simple bug to fix". Do you 
mean in your code on in GDAL code ? I think that the GDAL new behaviour is 
more a feature than a bug. I agree that the 216 value is a bit artificial, 
but otherwise there's no way to handle empty squares. I displayed with OpenEV 
your attached CADRG frame and it looks great : a 256x256 non-empty square in 
the south-east corner of the image (with a black border on the west and north 
side), the rest of the image being marked as nodata. With the color table of 
that image, GDAL 1.4.0 would have displayed black areas instead of 
transparent ones.

Le Tuesday 19 February 2008 20:37:58, vous avez écrit :
> Even,
>
> This is what I sent Frank.  The reason I need the nodata value is because
> when I render images to the screen I like to set the nodata value as the
> transparent image filter on my image so the user only sees the image data
> and then I can tile many layers over each other to create a much better map
> view.
>
> I think it looks like a simple bug to fix.  Thank you very much for your
> help.  I really like the new improvements you guys have been doing on the
> library by the way.
>
> Best regards,
> Martin Chapman
>
>
>
> ...what I sent to Frank...
>
> Frank,
>
> No, the file is small and it is attached.  If you want more nitf files or
> rpf cadrg or cib I can also provide them for you.  They are all small and I
> have an ftp site as well for download.
>
> What I have discovered is that on line 667 of nitfimage.c the following if
> () code block does not get executed because the value of nTPXCDLNTH == 0.
>
> if( nTPXCDLNTH == 8 )
>         {
>             GByte byNodata;
>
>             psImage->bNoDataSet = TRUE;
>             VSIFReadL( &byNodata, 1, 1, psFile->fp );
>             psImage->nNoDataValue = byNodata;
>         }
>         else
>             VSIFSeekL( psFile->fp, (nTPXCDLNTH+7)/8, SEEK_CUR );
>
> Then on line line 809 the fix puts the nodata value as the number of color
> table entries, which is 216.  That seems wrong?
>
> /* -------------------------------------------------------------------- */
> /*      Bug #1751: Add a transparent color if there are none. Absent    */
> /*      subblocks will be then transparent.                             */
> /* -------------------------------------------------------------------- */
>     if( !psImage->bNoDataSet
>         && psImage->nBands == 1
>         && psImage->nBitsPerSample == 8 )
>     {
>         NITFBandInfo *psBandInfo = psImage->pasBandInfo;
>         if (psBandInfo->nSignificantLUTEntries < 256-1
>             && psBandInfo->pabyLUT != NULL )
>         {
>             psBandInfo->pabyLUT[0+psBandInfo->nSignificantLUTEntries] = 0;
>             psBandInfo->pabyLUT[256+psBandInfo->nSignificantLUTEntries] =
> 0; psBandInfo->pabyLUT[512+psBandInfo->nSignificantLUTEntries] = 0;
> psImage->bNoDataSet = TRUE;
>             psImage->nNoDataValue = psBandInfo->nSignificantLUTEntries;
>             psBandInfo->nSignificantLUTEntries ++;
>         }
>     }
>
>
>
> By the way, good job adding nitf rpc functionality.  Also the Warp API
> rocks house. :)
>
> Best regards,
> Martin Chapman
>
> Martin Chapman
>
>
> -----Original Message-----
> From: gdal-dev-bounces at lists.osgeo.org
> [mailto:gdal-dev-bounces at lists.osgeo.org] On Behalf Of Even Rouault Sent:
> Tuesday, February 19, 2008 12:29 PM
> To: gdal-dev at lists.osgeo.org
> Subject: Re: [gdal-dev] NITF 1.5.0 nodata value is wrong.
>
> 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
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev