Selon Belaid MOA <[email protected]>: > > 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: [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
