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)
Change History (6)
by , 13 years ago
Attachment: | 13-1210-5405.png added |
---|
by , 13 years ago
Attachment: | 12-605-2702.png added |
---|
No unexpected banding when generated with -z 12
comment:1 by , 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 , 13 years ago
Attachment: | N-10-45_2000_01_02.png.aux.xml added |
---|
The world file for the sample source image
comment:2 by , 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 , 5 years ago
Milestone: | → closed_because_of_github_migration |
---|---|
Resolution: | → wontfix |
Status: | new → closed |
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.
Blocky artefacts introduced when tiles generated with -z 13