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?
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: [email protected]
> To: [email protected]
> CC: [email protected]
> Subject: Re: [gdal-dev] VRT KernelFilteredSource and NoDataValue
>
> Selon Belaid MOA <[email protected]>:
>
> 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_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
