[gdal-dev] cubic / bilinear resampling with gdalwarp looks
similar to nearest neighbour
seth at pricepages.org
Thu Oct 14 00:24:49 EDT 2010
Bilinear uses the nearest four pixels, bicubic uses the nearest 16
pixels. That's what makes them linear and cubic. Do you have a source
for another way to do it?
It would be possible to do averaging, *then* resample, but I'm not
sure that's worth it here. (Weighted averaging would be better anyway.)
On Oct 13, 2010, at 9:48 PM, Frank Warmerdam wrote:
> Craig de Stigter wrote:
>> Apologies for the long delay. I've finally had opportunity to look
>> into this again. I'm still unsure why exactly the bilinear and
>> bicubic resampling produces such second-rate output in GDAL. I have
>> a few questions:
>> 1. Is there a fundamental reason why the bilinear resampling
>> couldn't use all the pixels from the source region, rather than
>> just the 4 corner pixels? A destination pixel would then be the
>> weighted average of all the source pixels for each band.
> Well, it would no longer be bilinear. It would be averaged.
>> 2. Suppose a 1/6 sampling ratio, i.e. a 6x6 region (0, 0)-->(6, 6)
>> in the source image corresponds to a 1x1 region in the output.
>> What source pixels are used by the bilinear resampling in GDAL?
>> Wikipedia <http://en.wikipedia.org/wiki/Bilinear_interpolation>
>> suggests it should be the 'nearest' four pixels to the desired
>> destination pixel, i.e. (2, 2), (2, 3), (3, 2), (3, 3). Is that
>> what GDAL is doing, or is it using (0, 0), (0, 5), (5, 0), (5, 5) ?
> It will use (2, 2), (2, 3), (3, 2), (3, 3).
>> 3. Assuming a 'no' answer to (1), if I were to contribute a patch
>> to make bilinear/bicubic resampling take all the source pixels into
>> account, would it meet much opposition? It would probably make
>> large-scale downsampling using these methods much slower, though
>> its questionable whether anyone would complain given that the
>> quality of current output is so poor...
> I'm not adverse to your preparing a patch that implements an
> "averaged" resampling kernel, but it doesn't replace bilinear.
> Generally speaking the warper is not intended for dramatic changes
> of resolution - it is intended for changes of geometry at roughly the
> same resolution - for instance reprojection.
> Average was already implemented as a resampling kernel in the
> "build overviews" tool because it is aimed at dramatic changes of
> Best regards,
> I set the clouds in motion - turn up | Frank Warmerdam, warmerdam at pobox.com
> light and sound - activate the windows | http://pobox.com/~warmerdam
> and watch the world go round - Rush | Geospatial Programmer for
More information about the gdal-dev