Hi, If a low-pass filter is needed before passing data to downsampling, I wonder if it could be done by utilizing a VRT with KernelFilteredSource https://www.gdal.org/gdal_vrttut.html. May well be that it is not relevant at all, my understanding of mathematics coming from agricultural background.
-Jukka Rahkonen- kfj wrote > On 16.11.18 10:07, Even Rouault wrote: >>> Upsampling is well >>> covered: cubicspline and lanczos are reasonably sophisticated upsampling >>> filters, >> >> Did you actually try them for downsampling ? They are for sure widely >> used in >> that case already, for example when using gdaladdo to create overviews. >> For >> example cubicspline has a filter radius of 2. If you downsample by a >> factor of >> X, the effective radius will be 2 X. > > I did try them, and the result looks 'okay', but I have reservations. I > come from a DSP background. If my understanding of the mathematics > involved is correct, evaluating a spline over a data set will produce > values which are appropriate at a given resolution. If you use these > values at a lower resolution, you may get aliasing if the initial signal > has high frequency content. Aliasing always happens if there is high > frequency content and you resample with a lower sampling rate. You can > only avoid it by using a low-pass filter before resampling. So I'm > trying to find out if this does happen here. > > If I understand this correctly, the effective radius signifies the > number of spline coefficients contributing to the interpolated value, it > does not imply a low-pass filter. If the spline (and I suspect it's a > B-spline) is created by first prefiltering the data and then evaluating > the spline at the desired target locations, the interpolation criterion > is fulfilled and there is no smoothing. > > Omitting the prefiltering and using the original data as spline > coefficients does some smoothing, but from a cubic spline the effect is > small and does not vary with the scale of the downsampling, so it would > not work equally well for different scale changes. > > Maybe you can point me to the place in the source code where the > relevant math happens? I had a look but it's very complex and I did not > find my way in easily. > > > They are for sure widely used > > This doesn't automatically make them correct. If my suspicions are > founded, then there may be room for improvement. > > Kay > > > > _______________________________________________ > gdal-dev mailing list > gdal-dev@.osgeo > https://lists.osgeo.org/mailman/listinfo/gdal-dev -- Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev