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 > [email protected] > http://lists.osgeo.org/mailman/listinfo/gdal-dev > _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
