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

[Craig de Stigter]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20100930/3c9fa75c/attachment-0001.html