Opened 13 years ago

Closed 5 years ago

#3830 closed defect (wontfix)

Banding artifacts in gdal2tiles magnified (overzoom) output

Reported by: natevw Owned by: warmerdam
Priority: normal Milestone: closed_because_of_github_migration
Component: default Version: unspecified
Severity: normal Keywords:
Cc:

Description

When reprojecting and pyramiding imagery with gdal2tiles to a zoom level above that of the data, blocky artefacts are introduced into the output.

Background: Source imagery often has a resolution between tile "power-of-two" zoom levels. For example, source imagery may be more detailed than zoom level 12 but less detailed than zoom level 13. By default, gdal2tiles would round this down and generate zoom level 12. However, sometimes it is desirable to generate a slightly upscaled set of tiles by manually overriding, in this case by passing -z 13.

When this is done, the resulting tiles get blocky band artifacts that are not present in the source data. An example of tiles generated at base zoom level 12 versus base zoom level 13 is attached.

Attachments (3)

13-1210-5405.png (154.6 KB ) - added by natevw 13 years ago.
Blocky artefacts introduced when tiles generated with -z 13
12-605-2702.png (176.8 KB ) - added by natevw 13 years ago.
No unexpected banding when generated with -z 12
N-10-45_2000_01_02.png.aux.xml (298 bytes ) - added by natevw 13 years ago.
The world file for the sample source image

Download all attachments as: .zip

Change History (6)

by natevw, 13 years ago

Attachment: 13-1210-5405.png added

Blocky artefacts introduced when tiles generated with -z 13

by natevw, 13 years ago

Attachment: 12-605-2702.png added

No unexpected banding when generated with -z 12

comment:1 by natevw, 13 years ago

I wasn't able to attach this, but the source image (public domain; from NASA GeoCover 2000 mosaic) is available from http://andyet.couchone.com/share/gdalTicket3830/N-10-45_2000_01_02.png

To reproduce: gdal2tiles.py -z 13 -s "+proj=utm +zone=10 +datum=WGS84" N-10-45_2000_01_02.png outfolder

This happens on other imagery too, but this is a smaller public domain sample suitable for quick testing. Note that the artefacts are much more prominent in populated places where streets and roofs get noticeable misaligned bands through them.

by natevw, 13 years ago

The world file for the sample source image

comment:2 by Jukka Rahkonen, 9 years ago

I can confirm by a test I made with GDAL 1.10.0. Gdal2tiles does not seem to handle oversampling very well. However, I did not get much better result by oversampling the source image first with gdalwarp. The original image has also much artifacts itself and it does not make sense to use it for further trials. However, for me it looks like gdal2tiles is introducing artifacts which look like 8x8 pixel sized blocks.

Good news is that clients, like OpenLayers, can nowadays stretch the best resolution on the client side and there is less need for creating overzoomed tiles beforehand.

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.