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

[Craig de Stigter]

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.

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) ?

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...

Thanks for your help
Craig de Stigter

On Thu, Sep 30, 2010 at 12:30 PM, Seth Price <seth at pricepages.org> wrote:

> The only way to 'force' it is to use cubicspline or lanczos. Everything
> else has a hardcoded filter size. If those are too slow, I'd suggest using
> the OpenCL code I wrote over the summer. It's many times faster. (It
> should be in trunk soon if it isn't already.)
>
> http://github.com/mailseth/OpenCL-integration-for-GRASS---GDAL
>
> ~Seth
>
>
>
> On Wed, September 29, 2010 4:12 pm, Craig de Stigter wrote:
> > Thanks Even
> >
> > However if I do the same thing with reprojection I get the same result.
> > gdalwarp output looks sharp and ugly, imagemagick output looks nice.
> >
> > Is there any way to force the bilinear/cubic interpolation to notice more
> > pixels? The other interpolation methods are much slower, I imagine even
> > forcing cubic to notice all of the 5x5 pixels would still be faster.
> >
> > Regards
> > Craig de Stigter
> >
> > On Thu, Sep 30, 2010 at 10:34 AM, Even Rouault
> > <even.rouault at mines-paris.org
> >> wrote:
> >
> >> Craig,
> >>
> >> The main reason is that you are using gdalwarp to reduce an image by a
> >> large
> >> factor and not reproject it, which generally only involves image
> >> resizing
> >> by
> >> small factors. The implementation of the bilinear and cubic resampling
> >> algorithms is currently not designed for the pure resizing use case and
> >> takes
> >> only into account a few source pixels (basically if to compute a
> >> destination
> >> pixel you would need to take into account a 5x5 source window, they will
> >> only
> >> used the 4 corners of that square, which fine usually since those are
> >> just
> >> the
> >> immediate neighbours of the source pixel), whereas cubicspline and
> >> lancsoz
> >> take into account more pixels (all the pixels in the 5x5 square).
> >>
> >> Best regards,
> >>
> >> Even
> >>
> >> Le mercredi 29 septembre 2010 22:27:01, Craig de Stigter a écrit :
> >> > Hi folks
> >> >
> >> > I filed this bug <http://trac.osgeo.org/gdal/ticket/3740> on gdal a
> >> few
> >> > weeks back and haven't heard anything since.
> >> >
> >> > Would someone mind taking a look at it?
> >> >
> >> > Thanks
> >> > Craig de Stigter
> >>
> >
> >
> >
> > --
> > Koordinates Ltd
> > PO Box 1604, Shortland St, Auckland, New Zealand
> > Phone +64-9-966 0433 Fax +64-9-969 0045
> > Web http://www.koordinates.com
> > _______________________________________________
> > gdal-dev mailing list
> > gdal-dev at lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>
>


-- 
Koordinates Ltd
PO Box 1604, Shortland St, Auckland, New Zealand
Phone +64-9-966 0433 Fax +64-9-969 0045
Web http://www.koordinates.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20101014/464d335c/attachment.html