search

OSGeo / gdal

GDAL is an open source MIT licensed translator library for raster and vector geospatial data formats.
https://gdal.org
Other
4.8k stars 2.51k forks source link

gdal2tiles.py generates incorrect tiles with non-Byte input #1956

Closed alexbruy closed 4 years ago

alexbruy commented 4 years ago

Expected behavior and actual behavior.

gdal2tiles.py generated tiles with "corrupted" content (image looks very noisy/blurry) from a some single-band TIFF files. TIles itself located in the correct positions but their content is messy.

Expected result — tiles with readable content.

Steps to reproduce the problem.

  1. Use attached file and create tiles with the following command gdal2tiles.py -z 14 test.tif /tmp/tiles
  2. Open any generated tile in QGIS or other viewer and compare it with the original raster. For example, here is a portion of the original raster (at the top) and the same area in the tile 14/15073/6549.png (at the bottom) screen

Operating system

GDAL version and provenance

test.zip

jratike80 commented 4 years ago

The source image is of type UInt16 and gdal2tiles seems to have some problem with it. This gives a better looking result 1) Convert image to 8 bit and scale. I used "cumulative count cut 2-98%" where I took the values from QGIS. gdal_translate -of GTiff -ot byte test.tif test8.tif -scale 0 518

2) Tile the 8 bit version gdal2tiles -z 15 test8.tif

Try if it works for you too.

alexbruy commented 4 years ago

But it should work with any data type, no? Converting to byte causes data loss in some cases.

Looking at the gdal2tiles code I can not find any limitations about data type.

jratike80 commented 4 years ago

Gdal2tiles is made for creating tiles for web viewers like Leaflet or OpenLayers and it saves the tiles as 8 bit pngs or jpegs in any case. I can't directly find from the code where the .png output is set to be 8 bit. Png does support also 16 bit while jpeg does not so with jpeg is not only lossy by the compression but the change in bit depth also happens for sure.

If gdal2tiles could process your image right and create data and web viewers for 16 bit tiles they would look very dark for the users because all the data are in the dark end of the histogram (maximum 2047 and 98% cut point at 518).

Perhaps this in not exactly a bug in gdal2tiles but rather a missing feature. Documentation could be better and emphasize that sript creates tiles with 8 bits per channel. You can see "Edit on GitHub" button in https://gdal.org/programs/gdal2tiles.html#gdal2tiles. I encourage you to press the button but let's wait a while for comments from GDAL developers. I am not totally sure how gdal2tiles is supposed to work when input data is not 8 bit per channel.

If 16 bit tiles are what you need and web viewer is not important you may consider to use gdal_translate and save data into GeoPackage.

rouault commented 4 years ago

I concur with @jratike80 analysis. GDAL2Tiles only handle properly Byte datatype, and will clamp to Byte all inputs. Potential improvements could be to:

GaroleAtharva commented 1 month ago

has this issue been resolved? Is there any way to create tiles using 16bit input? I have tried using gdal translate but it causes loss in data loss