[Gdal-dev] Resampling with gdalwarp

Mario Beauchamp starged at videotron.ca
Wed Mar 17 23:06:47 EST 2004


Hi Frank,

On Wed, 17 Mar 2004 01:40:39 -0500, Frank Warmerdam <warmerdam at pobox.com> wrote:

>> ... all I know is to use bilinear when you reduce and cubic when you enlarge. Is that correct?
>
>I am not familiar with that rule of thumb.

It comes from PSP help. Seems to work.

>The main thing to note is that the PSP downsampled image essentially preserves
>the thin linear features, especially the thin nearly horizonal road.  The GDAL
>image however "butchers" the road.  It is as if the road drops right out every
>couple of pixels, and then comes back a couple pixels later.  That effect is not
>seen in the PSP version.

Before GDAL, I used to reduce my images by 25% in PSP and then georeference them using the geotiffcp
utility. When I started using gdalwarp to resize my images and compared them to the ones previously
done with PSP, that "butchered" roads effect struck me. 

>Keep in mind that these resampling kernels are primarily intended for cases of
>non-linear geometric transformations (ie. reprojection) where the output image is
>appoximately the same resolution as the input.

It's true that they work well for reprojecting. I was impressed too by the Cubic Spline. Not sure
exactly which one to use in what circumstances but it's for me to find out...

I noticed that "problem" a few weeks ago and I didn't want to bother anyone with that while the GDAL
1.2.0 was about to be released. Now that you tell me it was not intended for resizing, I understand
better why I wasn't getting the expected results. 
 
>I am interested in others input on typical meanings of bilinear resampling in
>image processing.  However, I don't (so far) see any error in what GDAL's
>algorithm is doing.  It just may be insufficient clear to call it only
>bilinear resampling.

It may be just another example of confusing terminology (ImageMagick calls it "Triangle", for
instance). I myself have difficulties with some terms used on this list sometimes :)

>For the kind of downsampling you seem to want to do, I think the averaging is
>the best approach.  Unfortunately, that is not currently offered by gdalwarp,
>and because of the non-linear (in general) nature of the geometric
>transformations in gdalwarp, it would be hard to implement "averaging"
>appropriate.  It is however available in the overviewing building code and
>as an option in the virtual file driver.  Perhaps I should have a convenient
>way of downsampling images with averaging via a GDAL utility ... perhaps
>gdal_translate or a custom algorithm.

I was aware of the overviews approach however, most of my Landsat images are on CDs so I chose to
keep a 1/4 res copy of all images on disk instead of building overviews. But when you mentioned it,
I built overviews with gdaladdo -r average 4 and indeed, the resulting 1/4 res image looks much
better. But I didn't find how I could put the overview in another file... if for example, I want to
build overviews for all images on CDs and put the overview images on hard disk.

But don't lose any sleep on that, it's not that important. And maybe I can try to figure it all out
by myself and learn the GDAL API at the same time...

Thanks for your explanations.
--
Mario B.
My Landsat images:
http://pages.infinit.net/starged/landsat/home.html



More information about the Gdal-dev mailing list