Opened 14 years ago

Closed 9 years ago

Last modified 9 years ago

#3740 closed defect (fixed)

cubic / bilinear resampling with gdalwarp looks similar to nearest neighbour

Reported by: cdestigter Owned by: warmerdam
Priority: normal Milestone: 2.0.0
Component: GDAL_Raster Version: svn-trunk
Severity: normal Keywords: warp cubic bilinear
Cc:

Description

cubic/bilinear resampled output from gdalwarp looks very rough, visually very similar to nearest neighbour. The same happens for bilinear, though cubicspline looks good.

My test:

# using gdalwarp
gdalwarp -ts 256 256 -r cubic -of GTiff original.png resampled.tif

# using ImageMagick
convert -resize 256x256 original.png magick-resampled.png

ImageMagick output looks far superior. I'll attach a few images to show you what I mean.

I spotted this in gdal 1.6.1 but I've tested with trunk and the same behavior occurs.

Attachments (1)

test-gdal-resampling.zip (948.0 KB ) - added by cdestigter 14 years ago.

Download all attachments as: .zip

Change History (7)

by cdestigter, 14 years ago

Attachment: test-gdal-resampling.zip added

comment:1 by cdestigter, 13 years ago

some discussion on gdal-dev

comment:2 by cdestigter, 11 years ago

nobody likes a bumper, but just pointing out that this is still an issue in latest gdal trunk.

gdalwarp/gdaladdo with bilinear/cubic/gauss doesn't seem to work, has output which looks very similar to nearest neighbor. gdaladdo -r average` works, and so does lanczos etc, so it's not an issue with resampling in general. And as noted, imagemagick produces nice bilinear/cubic output, so it's not a limitation of the algorithms themselves.

comment:3 by cdestigter, 10 years ago

a better test case for this is https://mega.co.nz/#F!pEZnEZIS!7010-zPdf8eefvgeaI257Q , because the original test case was a bit rubbish due to me trying to squeeze it into the 1MB trac allows.

rm -f resampled.tif ; gdalwarp -ts 256 256 -r cubic -of GTiff -co COMPRESS=DEFLATE original.tif resampled.tif

convert -resize 256x256 original.tif magick-resampled.tif

comment:4 by cdestigter, 10 years ago

From discussion on IRC with EvenR:

GDAL doesn't take into account the scaling factor, so only use a 4x4 kernel, whereas it should take a 8x8 kernel with 50% scaling, etc.

comment:5 by Even Rouault, 9 years ago

Keywords: warp cubic bilinear added
Milestone: 2.0
Resolution: fixed
Status: newclosed

trunk r27812 "Warp: fix Cubic and Bilinear resampling to work correctly with downsizing (#3740)"

comment:6 by Even Rouault, 9 years ago

Milestone: 2.02.0.0

Milestone renamed

Note: See TracTickets for help on using tickets.