[gdal-dev] cubic / bilinear resampling with gdalwarp looks similar to nearest neighbour

[Seth Price]

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.)
~Seth


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.
>
> Craig,
>
> 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
> resolution.
>
> 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  
> Rent
>