Apologies for the long delay. I've finally had opportunity to look into this again. <div><br></div><div>I'm still unsure why exactly the bilinear and bicubic resampling produces such second-rate output in GDAL. I have a few questions:</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div><div>What source pixels are used by the bilinear resampling in GDAL?</div>
<div><br></div><div><a href="http://en.wikipedia.org/wiki/Bilinear_interpolation">Wikipedia</a> 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) ?</div>
<div><br></div><div>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...</div>
<div><br></div><div>Thanks for your help</div><div>Craig de Stigter</div><div><br></div><div><div class="gmail_quote">On Thu, Sep 30, 2010 at 12:30 PM, Seth Price <span dir="ltr"><<a href="mailto:seth@pricepages.org">seth@pricepages.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">The only way to 'force' it is to use cubicspline or lanczos. Everything<br>
else has a hardcoded filter size. If those are too slow, I'd suggest using<br>
the OpenCL code I wrote over the summer. It's many times faster. (It<br>
should be in trunk soon if it isn't already.)<br>
<br>
<a href="http://github.com/mailseth/OpenCL-integration-for-GRASS---GDAL" target="_blank">http://github.com/mailseth/OpenCL-integration-for-GRASS---GDAL</a><br>
<br>
~Seth<br>
<div><div></div><div class="h5"><br>
<br>
<br>
On Wed, September 29, 2010 4:12 pm, Craig de Stigter wrote:<br>
> Thanks Even<br>
><br>
> However if I do the same thing with reprojection I get the same result.<br>
> gdalwarp output looks sharp and ugly, imagemagick output looks nice.<br>
><br>
> Is there any way to force the bilinear/cubic interpolation to notice more<br>
> pixels? The other interpolation methods are much slower, I imagine even<br>
> forcing cubic to notice all of the 5x5 pixels would still be faster.<br>
><br>
> Regards<br>
> Craig de Stigter<br>
><br>
> On Thu, Sep 30, 2010 at 10:34 AM, Even Rouault<br>
> <<a href="mailto:even.rouault@mines-paris.org">even.rouault@mines-paris.org</a><br>
>> wrote:<br>
><br>
>> Craig,<br>
>><br>
>> The main reason is that you are using gdalwarp to reduce an image by a<br>
>> large<br>
>> factor and not reproject it, which generally only involves image<br>
>> resizing<br>
>> by<br>
>> small factors. The implementation of the bilinear and cubic resampling<br>
>> algorithms is currently not designed for the pure resizing use case and<br>
>> takes<br>
>> only into account a few source pixels (basically if to compute a<br>
>> destination<br>
>> pixel you would need to take into account a 5x5 source window, they will<br>
>> only<br>
>> used the 4 corners of that square, which fine usually since those are<br>
>> just<br>
>> the<br>
>> immediate neighbours of the source pixel), whereas cubicspline and<br>
>> lancsoz<br>
>> take into account more pixels (all the pixels in the 5x5 square).<br>
>><br>
>> Best regards,<br>
>><br>
>> Even<br>
>><br>
>> Le mercredi 29 septembre 2010 22:27:01, Craig de Stigter a écrit :<br>
>> > Hi folks<br>
>> ><br>
>> > I filed this bug <<a href="http://trac.osgeo.org/gdal/ticket/3740" target="_blank">http://trac.osgeo.org/gdal/ticket/3740</a>> on gdal a<br>
>> few<br>
>> > weeks back and haven't heard anything since.<br>
>> ><br>
>> > Would someone mind taking a look at it?<br>
>> ><br>
>> > Thanks<br>
>> > Craig de Stigter<br>
>><br>
><br>
><br>
><br>
> --<br>
> Koordinates Ltd<br>
> PO Box 1604, Shortland St, Auckland, New Zealand<br>
> Phone +64-9-966 0433 Fax +64-9-969 0045<br>
> Web <a href="http://www.koordinates.com" target="_blank">http://www.koordinates.com</a><br>
</div></div>> _______________________________________________<br>
> gdal-dev mailing list<br>
> <a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><br>
> <a href="http://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
<br>
<br>
</blockquote></div><br><br clear="all"><br>-- <br>Koordinates Ltd<br>PO Box 1604, Shortland St, Auckland, New Zealand<br>Phone +64-9-966 0433 Fax +64-9-969 0045<br>Web <a href="http://www.koordinates.com">http://www.koordinates.com</a><br>
</div>