[gdal-dev] resampling techniques in GDAL

[Seth Price]

The reason that what you are suggesting isn't done is mainly speed and
simplicity. GDAL makes the assumption that you are warping from one
resolution to another, similar, resolution. The current scheme works well
for that.

However, I believe that Cubic Spline and Lanczos resampling both do what
you are referring to. They use variable kernel sizes depending on the
input/output image sizes.

In conclusion, if you want quality image resampling across large scales,
use a image manipulation package such as imagemagick. Their algorithms
incorporate your concerns and more. But GDAL's method works pretty well
for what it's used for.
~Seth


On Tue, June 16, 2009 5:52 pm, Gregory, Matthew wrote:
> Hi all,
>
> A recent post got me thinking about resampling techniques.  I've posted
> a graphic to help illustrate my question.
>
>   http://www.fsl.orst.edu/lemma/sandbox/resample.png
>
> In the graphic, assume the input image is the 3x3 grid with black
> outlines and blue and yellow dot centers.  Assume the red outlined
> pixels represent three different output resolutions of a single pixel
> each having its center at the black dot.
>
> Using bilinear interpolation, each of these three output resolutions get
> the same value (tested using gdalwarp) based on the four yellow cell
> centers.  I understand why this is happening and realize this is the
> expected behavior.
>
> My question, however, is whether or not there is a resampling technique
> (inside or outside GDAL) that uses the proportional weights and values
> of *all* input pixels touched by the output pixel.  At the finest
> resolution in the illustration, this would be equivalent a nearest
> neighbor resampling (ie. the output pixel is wholly contained within the
> input pixel) and at the coarsest resolution, all nine input pixels would
> contribute to the output value based on proportional area.
>
> This falls outside the traditional { nearest neighbor | bilinear
> interpolation | cubic convolution } resampling techniques and there may
> be a reason why this is a bad idea.  I can see that it might be
> prohibitively slow for large output pixel resolutions but, to my way of
> thinking, a potentially more accurate representation of the underlying
> (finer-resolution) data.
>
> matt
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>