Opened 12 years ago

Closed 5 years ago

#4813 closed defect (wontfix)

Pixel displacement/offset from gdalwarp bilinear interpolation

Reported by: highlatitude Owned by: warmerdam
Priority: normal Milestone: closed_because_of_github_migration
Component: default Version: svn-trunk
Severity: normal Keywords:
Cc:

Description (last modified by highlatitude)

I am trying to warp an essentially unprojected dataset based on a full set of GCPs. Each pixel in the unprojected image has been assigned its own GCP that specifies the EPSG:3031 (WGS84 Antarctic Polar Stereographic) coordinates of that pixel. I am then trying to use gdalwarp to create a projected and interpolated dataset based on these GCPs.

In this process, I have discovered what I believe to be a bug in the bilinear 3rd order transformation implementation in gdalwarp. Using this method, two areas around the continent have a strange pixel displacement. These offsets are apparent at -90 and 90 longitude (see attached images).

This offset appears to be specific to the 3rd order bilinear interpolation. Also, the source dataset type does not appear to be related -- I've reproduced this using GTiff as a source as well.

Example command to produce the error:

gdalwarp -t_srs EPSG:3031 -r bilinear -order 3 -tr 4450 4450 melt_allGCP.png melt_allGCP_warped.tif

Data used to produce the error: http://dl.dropbox.com/u/26194961/data.tar.gz

GDAL versions tested: svn trunk and 1.9.0.

Attachments (1)

gdalwarp_antarctic_pixeloffset.png (47.5 KB ) - added by highlatitude 12 years ago.
Example of the offset produced using gdalwarp.

Download all attachments as: .zip

Change History (4)

by highlatitude, 12 years ago

Example of the offset produced using gdalwarp.

comment:1 by highlatitude, 12 years ago

Description: modified (diff)
Version: unspecifiedsvn-trunk

comment:2 by Even Rouault, 12 years ago

I presume (but haven't actually checked on your particular sample) that you are running into a "well-known" issue with 3rd order polynomial interpolation that has some (presumably numerical instability) problem that nobody has unfortunately yet solved.

comment:3 by Even Rouault, 5 years ago

Milestone: closed_because_of_github_migration
Resolution: wontfix
Status: newclosed

This ticket has been automatically closed because Trac is no longer used for GDAL bug tracking, since the project has migrated to GitHub. If you believe this ticket is still valid, you may file it to https://github.com/OSGeo/gdal/issues if it is not already reported there.

Note: See TracTickets for help on using tickets.