[Gdal-dev] Resampling with gdalwarp

[Sandy Pyke]

Hi Frank,

I've also noticed the same thing in my application. Here are a few
sample images:

http://halibut.aquilamsl.com/~spyke/resampling 

I resampled the images with both GraphicsMagik and GDALWarp. The GDAL
result shows breaks in many of the small features and even the loss of
some data entirely. The resulting map is usable, but not ideal.

In my case I am only making a correction to the map's aspect ratio going
from a source image size of 3200 x 1600 to a destination image size of
2640 x 1879 which means downsampling (82.5%) in one direction and
upsampling (117.4%) in the other. This is so I can adjust the pixels
from being square in lon / lat values to being square in meters, which
falls closer into what you expected GDALWarp to do as I understand. Even
so, I am seeing a loss of data. Best case, I loose a bit of data, worst
case the data get mis-interpreted (ie: solid lines become dashed lines).

I would also like to see some improvement in this re-sampling algorithm.
There are a few algorithm switches available in the GDALWarp command
line options, but the documentation mentions that only the bilinear
re-sampling is available. Is this still the case in 1.2.0?

Sandy Pyke

> -----Original Message-----
> From: gdal-dev-admin at remotesensing.org 
> [mailto:gdal-dev-admin at remotesensing.org] On Behalf Of Frank Warmerdam
> Sent: Wednesday, March 17, 2004 1:41 AM
> To: gdal-dev at remotesensing.org
> Subject: Re: [Gdal-dev] Resampling with gdalwarp
> 
> 
> Mario Beauchamp wrote:
> > I don't know much about resampling algorithms... all I know 
> is to use 
> > bilinear when you reduce and cubic when you enlarge. Is 
> that correct?
> 
> Mario,
> 
> I am not familiar with that rule of thumb.
> 
> > I simply used: gdalwarp -tr 120 120 -rb
> > There is no special arguments for PSP, we simply select 
> "Bilinear" in 
> > the resize image dialog. The exact algorithm used is not documented.
> > 
> > Also, the OSSIM bilinear resampling looks about the same as the PSP 
> > image. But it has some other problems so I chose not to include it.
> 
> I have done some quick tests but they aren't exactly 
> conclusive.  There are definate differences.
> 
> I am including attached to this 3 smallish pngs of a small 
> area of the image. I picked this small area because it has a 
> linear feature appiximately 1 pixel across and the PSP and 
> GDAL results are substantially different in this area. The 
> regions of the swatches are appoximately the same, but not 
> exactly by any means.  The original data is 4 times the 
> resolution (in each direction) of the downsampled data.  I 
> ensured they all use the same simple linear stretch to 
> visualize the data, and I only show band 1 to simplify the situation.
> 
> 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.
> 
> Now while the GDAL result is unappealing, I would claim it is 
> doing what I would expect my concept of a 2x2 bilinear 
> resampling kernel should do in a 4x4 downsampling case.  In 
> the GDAL version, each output pixel is computed from a 2x2 
> neighbour of the input image but it is essentially 
> representing a 4x4 area of the input.  Very thin linear 
> features, such as a 1 pixel wide road will often be 
> completely missed by the 2x2 kernel, while at other times if 
> if the sample point falls dead on the line it make come 
> through at full brightness.
> 
> The PSP version is preserving the line well, though damped 
> down substantially as it is mixed with other non-road pixels.
> 
> I don't know what the formal definition of "bilinear 
> resampling" is.  I suspect that name can apply to a variety 
> of techniques.  Let me explain what GDAL does.
> 
> 1) It takes the center point of the output pixel, and 
> geometrically transforms it
>     to a location on the input pixel (with subpixel resolution).
> 
> 2) The four pixels closest to the input sampling location are 
> used in the kernel,
>     and the proximity of the sampling location to the center 
> of each input pixel
>     determines it's contribution in a bilinear fashion.
> 
> Some implications to note:
>   o Regardless of what amount of downsampling (or upsampling 
> for that matter) is being
>     done, each output pixel is determined from only 4 pixels.
>   o If the transformed sampling point happens to fall very 
> close to the center of an
>     input pixel, then the other 3 input pixels in the kernel 
> will have virtually no
>     contribution. This means, depending on the vagarities of 
> the resampling some output
>     pixels may be dominated by one or two input pixels while 
> others are a mix of all
>     four.
>   o In cases of integer decimation factors (such as exact 4x4 
> downsampling of images
>     that have a size that is a multiple of 4x4) the sampling 
> location should fall
>     in the center of the 4x4 input block and so the center 
> 2x2 pixels would make
>     a contribution.  If there are rounding or other slight 
> variations making the
>     downsampling not exactly 4x4 to 1 then various kinds of 
> odd sampling effects can
>     take place.
> 
> Frankly, I think that PSP is just doing some form of 
> averaging where all pixels from the source 4x4 rectangle are 
> giving equal contributions.  I *think* GDAL is doing what I 
> intended though it isn't a particularly good algorithm for 
> downsampling ... especially downsampling by more than 2x2.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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
> 
> 
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.596 / Virus Database: 379 - Release Date: 2/26/2004
>  
>       
> 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.596 / Virus Database: 379 - Release Date: 2/26/2004