[Gdal-dev] Resampling with gdalwarp

[Frank Warmerdam]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: orig.png
Type: image/png
Size: 16371 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/gdal-dev/attachments/20040317/5d0994a5/orig.png
-------------- next part --------------
A non-text attachment was scrubbed...
Name: psp.png
Type: image/png
Size: 3053 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/gdal-dev/attachments/20040317/5d0994a5/psp.png
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gdal.png
Type: image/png
Size: 3311 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/gdal-dev/attachments/20040317/5d0994a5/gdal.png