[gdal-dev] VRT KernelFilteredSource and NoDataValue

[Belaid MOA]

Thank you very much Even. I will try it then and confirm our understanding!

With best regards.
~Belaid Moa.

> Date: Sun, 30 Aug 2009 22:29:33 +0200
> From: even.rouault at mines-paris.org
> To: belaid_moa at hotmail.com
> CC: even.rouault at mines-paris.org; gdal-dev at lists.osgeo.org
> Subject: RE: [gdal-dev] VRT KernelFilteredSource and NoDataValue
> 
> Selon Belaid MOA <belaid_moa at hotmail.com>:
> 
> >
> > As always, thank you very ... very much Even. Just to make sure I understood
> > your reply correctly,
> > I do the following to set the source_0 and the nodatavalue (passed as
> > argument)
> > after creating the XML for the VRTKernelFilteredSource and set it in the
> > papszMetadata array.
> > The poBand is the RasterBand I get from the VRT dataset.
> >
> >       poBand->SetNoDataValue(noDataValue);
> >       poBand->SetMetadata( papszMetadata, "vrt_sources" );
> >
> > Is this right place to set the NoDataValue of the VRTRasterBand?
> >
> > For the normalization effect (normalized=1), does it mean that:
> > 1- The no data value pixels are ignored AND
> > 2- The coefficients of valid pixels only are adjusted so that their sum  is
> > equal to 1?
> 
> Yes, correct. Well, that's my understanding of the code : no warranty expressed
> or implied ;-) I guess you just have now to try
> 
> > If this is the case, then it is exactly the behavior I want!
> >
> > With best regards.
> > ~Belaid.
> >
> > > Date: Sun, 30 Aug 2009 10:12:04 +0200
> > > From: even.rouault at mines-paris.org
> > > To: belaid_moa at hotmail.com
> > > CC: gdal-dev at lists.osgeo.org
> > > Subject: Re: [gdal-dev] VRT KernelFilteredSource and NoDataValue
> > >
> > > Selon Belaid MOA <belaid_moa at hotmail.com>:
> > >
> > > Belaid,
> > >
> > > First, the VRTKernelFilteredSource will only recognize the nodata value if
> > you
> > > set it on the VRTRasterBand (it will not fetch it directly from the
> > > <SourceFilename>)
> > >
> > > When a nodata value is set and found in one of the values in a NxN square,
> > the
> > > value will be ignored. The effect of this depends whether normalized="1" is
> > set
> > > on <Kernel> or not. If normalized=1, the sum of the coefficients is not
> > > incremented for that nodata value, so the normalization will operate only
> > on
> > > valid pixel values. If normalized=0, the nodata value is just ignored
> > >
> > > As far as what happens in the borders is concerned, the code says that :
> > "Fill
> > > in missing areas.  Note that we replicate the edge valid values out.  We
> > don't
> > > using "mirroring" which might be more suitable for some times of filters.
> > We
> > > also don't mark these pixels as "nodata" though perhaps we should."
> > >
> > > Best regards,
> > >
> > > Even
> > >
> > > >
> > > > Hi everyone,
> > > >     I am using VRT KernelFilteredSource to implement an average filter as
> > > > done in the VRT tutorial. However, I am still unclear on how it handles
> > the
> > > > NoDataValue pixels. Are they too averaged or does it leave them as they
> > are?
> > > > If they are masked,  does do an adjustment for the kernel coefficients to
> > > > compensate for their absence? Another related question, is how does it
> > handle
> > > > the pixels on the borders and the kernel coefficients for those pixels?
> > > >
> > > >    Thank you very very much in advance for any help on these issues.
> > > >
> > > >    With best regards.
> > > > ~Belaid.
> > > >
> > > > _________________________________________________________________
> > > > Stay on top of things, check email from other accounts!
> > > > http://go.microsoft.com/?linkid=9671355
> > >
> > >
> >
> > _________________________________________________________________
> > Click less, chat more: Messenger on MSN.ca
> > http://go.microsoft.com/?linkid=9677404
> 
> 

_________________________________________________________________
New! Get to Messenger faster: Sign-in here now!
http://go.microsoft.com/?linkid=9677407
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090830/1d033838/attachment.html