gdal2tiles visible tile borders

[alacst]

Hey,

I've noticed a possible error in gdal2tiles. I'm trying to create png tiles from a png base. It's a small area but I need high zoom level (21-22). Using the generated viewer pages, some of the tile borders are visible. When comparing to the base image, the differences are more salient. The covered area is located in the UK. gdal_translate: gdal_translate -of vrt -a_srs EPSG:32630 -gcp /*adding 3 gcps here*/ base.png base.vrt and then gdal2tiles: gdal2tiles --xyz -r near -z 9-21 base.vrt targetdir

Pic from openlayers: Vertical tile border visible (~middle).

Base compared to the created tile: Tile Base

Not all tiles affected, I'd say around 20%.

Operating system

Win 10 Pro

GDAL version and provenance

3.1.4.

[jratike80]

By looking at the bright pixel in the middle of the samples it seems like the tile on the righ side is pushed one pixel row to the left so that on column of pixels get clipped. The blue arrows show columns which look similar to me.

Is the image labeled as "base" base.png or the georeferenced file base.vrt? Setting QGIS project into EPSG:3857 and opening base.vrt with it should show the effect of warping with the GCPs but without clipping into tiles.

[alacst]

the image is the base.png. I've opened the vrt in QGIS, and the rendered picture is identical to the base png here.

[jratike80]

Good. Just to be sure, did you also configure QGIS project into EPSG:3857 to force it to warp from 32630 into 3857 just like gdal2tiles is warping with your command?

[alacst]

Honestly, I'm kinda unsure. These things are pretty new to me. I've added the vrt to QGIS and then in the right bottom corner I switched to 3857

[jratike80]

That's exactly the way to make it to warp into 3857.

[DFyson]

I have the same problem. I'm using version 3.1.3. This issue has been brought up in #3162 and #1087. I tried different resampling methods (default, antialias, cubic) and also tried the --config GDAL_PDF_DPI 1200 mentioned in #3162 with different resampling methods but nothing seems to improve it. I also tried pre-warping the input file to EPSG:4326 but also no luck. Here's an example of what I get:

[jcary741]

I think I'm having the same problem here, it appears that the resampling around tile edges is doing something odd. Here's one example using -r near which causes one or more lines of pixels to be repeated. Note that the process I'm using here is:

1. gdalwarp to reproject my original raster to web mercator with some oversampling, using -r cubic. Output tif looks as expected.
2. gdaldem to colorize. Output tif looks as expected.
3. gdal2tiles with -r near

I'm using GDAL 3.7.0.

[jcary741]

With some experimentation, I was able to determine the issue was due to the first gdalwarp reprojection not using the same origin / resolution as was later used by gdal2tiles. I ended up importing the GlobalMercator class from gdal2tiles.py to compute the extent of the base zoom level tiles, then using that to compute the final resolution and passing that to gdalwarp via -ts {width_in_px} {height_in_px} -te {...bounds_in_meters}. In combination with using -r near for both gdalwarp and gdal2tiles.

I wish gdal2tiles just supported colorization as part of the tiling process, as that would really simplify this type of workflow.

[timgilbertson-os]

@jcary741 I'm running into the same issue. Do you have any code you could share?

[jcary741]

Unfortunately, I can't share any more than I already have. Sorry.