[gdal-dev] downsampling geotiff with a low-pass filter

[Joaquim Manuel Freire Luís]

You may also want to look at GMT's grdfilter:
https://gmt.soest.hawaii.edu/doc/5.4.4/grdfilter.html

and the notes on "Filtering of data in GMT"
https://gmt.soest.hawaii.edu/doc/5.4.4/GMT_Docs.html#filtering-of-data-in-gmt

Joaquim

|>-----Original Message-----
|>From: gdal-dev <gdal-dev-bounces at lists.osgeo.org> On Behalf Of Even Rouault
|>Sent: Friday, November 16, 2018 10:57 AM
|>To: Kay F. Jahnke <_kfj at yahoo.com>
|>Cc: gdal-dev at lists.osgeo.org
|>Subject: Re: [gdal-dev] downsampling geotiff with a low-pass filter
|>
|>> 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.
|>
|>There is no explicit code to do smoothing. For each target pixel, given the
|>radius of the filter and the resampling factor, it determines the index of the
|>first and last contributing source pixels and compute the associated weight
|>using a filter specific function.
|>
|>>
|>> 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.
|>
|>For gdal_translate/gdaladdo computation, the function is there:
|>https://github.com/OSGeo/gdal/blob/master/gdal/gcore/overview.cpp#L1859
|>
|>There is functionnaly equivalent code for gdalwarp in
|>https://github.com/OSGeo/gdal/blob/master/gdal/alg/gdalwarpkernel.cpp#L38
|>25
|>for example (we don't use the same code, as the code can be more optimized in
|>the gdal_translate/gdaladdo case as a source line gives a target line for
|>gdal_translate, whereas for gdalwarp given that coordinate reprojection may
|>occur, we cannot assume that, so must process each target pixel independently
|>of its neighbours)
|>
|>One of the function used to compute weights:
|>https://github.com/OSGeo/gdal/blob/master/gdal/alg/gdalwarpkernel.cpp#L31
|>63
|>
|>>
|>>  > They are for sure widely used
|>>
|>> This doesn't automatically make them correct.
|>
|>Indeed.
|>
|>--
|>Spatialys - Geospatial professional services
|>http://www.spatialys.com
|>_______________________________________________
|>gdal-dev mailing list
|>gdal-dev at lists.osgeo.org
|>https://lists.osgeo.org/mailman/listinfo/gdal-dev