1

I want to warp Geotiff image of shaded relief (RGBA) in projection EPSG:8353 to the projection EPSG:3857 to use it in Mapnik web tiled map. I want to use lanczos resampling, but the result image looks "jagged", like nearest resampling has been used. I am using this command:

gdalwarp \
  -of GTiff -overwrite -r lanczos  \
  -tr 1.194328566968441 1.194328566968441 -tap \
  -t_srs EPSG:3857 shading-sjtsk.tif shading-web.tif

The target resolution in georeferenced units is set to be the same as zoom level 17 in web mercator projection of tiled map.

Please could you advise me, why the lanczos resampling is not used? I tried also other methods (like cubic), but image always seems to be indistinguishable from nearest.

Input image:

Input image

Output image:

Output image

Original tif images are shared here.

Improve this question
2
  • Do you zoom in so much that the image is shown on screen at about native resolution (one raster pixel - on screen pixel)? Otherwise the viewer must also resample the image and it may hide the differences between the resampling methods of gdalwarp.
    – user30184
    Nov 6, 2020 at 21:33
  • The image was displayed at 1:1 zoom with correct projection set in QGis.
    – Jakub Rusnák
    Nov 6, 2020 at 21:47

1 Answer 1

Reset to default
1

The problem was with alpha band, which was not warped correctly. We need to prevent the alpha band of the source image to be considered as such with -nosrcalpha parameter. Then it will be warped as regular band. Following command yields nice smooth image:

gdalwarp \
  -of GTiff -overwrite -r lanczos -nosrcalpha \
  -tr 1.194328566968441 1.194328566968441 -tap \
  -t_srs EPSG:3857 shading-sjtsk.tif shading-web.tif

Result image:

Result image with lanczos resampling

Improve this answer
7
  • The source image has both alpha channel and nodata value Band 1 Block=303x6 Type=Byte, ColorInterp=Red NoData Value=255 Band 2 Block=303x6 Type=Byte, ColorInterp=Green NoData Value=255 Band 3 Block=303x6 Type=Byte, ColorInterp=Blue NoData Value=255 Band 4 Block=303x6 Type=Byte, ColorInterp=Alpha NoData Value=255. Thus nodata is set two times. I am not sure if it is valid but at least it is uncommon. How the source image is created?
    – user30184
    Nov 7, 2020 at 12:55
  • I made a test with GDAL 3.2 by unsetting nodata with gdal_edit. The result with your original command does not look good still. Would you mind to write a mail into gdal-dev because this feels like a bug? You could also edit the title of your question to describe the issue better.
    – user30184
    Nov 7, 2020 at 13:02
  • Thank you for ideas, I changed the title, hopefully it is more clear now. The image is result of stacking separate channels with gdalbuildvrt and gdal_translate and is transparent in flat areas, because it is used as hill shading overlay. I think this warping behavior is not a bug, but the intended behavior as described in gdalwarp documentation here. But why the alpha band is handled differently in gdalwarp by default, I don't know...
    – Jakub Rusnák
    Nov 7, 2020 at 19:53
  • Do separate channels mean that the stack is really 4-band image and RGB+alpha is wrong interpretation? It would be interesting to know more about the source images and exact gdalbuildvrt and gdal_translate commands that you used.
    – user30184
    Nov 8, 2020 at 21:20
  • No, the image is meant to be RGBA, the color interpretation in source is correct. The script that generated the shading is here, I'm using just different projection. I'm not the author, just using this shading technique.
    – Jakub Rusnák
    Nov 9, 2020 at 14:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.