[gdal-dev] NITF 1.5.0 nodata value is wrong.
Martin Chapman
mchapman at texelinc.com
Tue Feb 19 16:47:43 EST 2008
Even,
You did...see my last email. You answered my question. Thank you very much!
Best regards,
Martin Chapman
-----Original Message-----
From: Even Rouault [mailto:even.rouault at mines-paris.org]
Sent: Tuesday, February 19, 2008 2:27 PM
To: Martin Chapman
Cc: gdal-dev at lists.osgeo.org
Subject: Re: [gdal-dev] NITF 1.5.0 nodata value is wrong.
Hum, I think I had already answered this question...
-10000000000.0 *is not* the correct no data value. It means that there was not
any nodata value. I don't understand why your application needs that precise
value. This value is not the value of any pixel in the image (the data type
is byte). When you read each pixel of the image, the pixels whose value is
216 are transparent, for sure.
It can also happen that some non-empty blocks have padding (this is the case
in your example CADRG frame). In general, the pixel value will be 0 (black),
but it's not obvious in those cases that this black is really transparent.
Le Tuesday 19 February 2008 21:51:23 Martin Chapman, vous avez écrit :
> Even,
>
> My question is how do get the nodata value of -10000000000.0 from the nitf
> file. Is it in the ColorTable? In 1.4.0 you could get it from calling
> pRasterBand->GetNoDataValue(). That function now returns 216. The correct
> no data value is -10000000000.0. I need the value so I can display the
> image without the black borders in my application. I need it so I can tell
> the graphics API how to render the DIB section to the screen.
>
> Thanks you for your help!
>
> Best regards,
> Martin Chapman
>
>
> -----Original Message-----
> From: Even Rouault [mailto:even.rouault at mines-paris.org]
> Sent: Tuesday, February 19, 2008 12:56 PM
> To: Martin Chapman
> Cc: gdal-dev at lists.osgeo.org
> Subject: Re: [gdal-dev] NITF 1.5.0 nodata value is wrong.
>
> 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
More information about the gdal-dev
mailing list