-
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
gdal2tiles ignores alpha channel of the input #3953
Comments
May be unrelated, but why do you have both NoData value and alpha? |
|
Ok. Developers will give you better answer, but as far as I know alpha for GDAL is often acting like a binary mask "zeros vs anything else than zero". For some other use case I would have a test by changing the interpretation of band 4 into undefined before processing and then back to alpha, but with thousands of tiles that is unpractical. |
BTW I can generate png tiles with correct alpha using mapnik-based server (it is just more work to set it up). Also QGIS has no problem interpreting alpha channel correctly. |
Please attach a small input file demonstrating the issue |
Attached a sample. |
Hello everybody, i encounter the same issue. Any news ? |
I also experience the same issue. I assume there has been no progress on this? |
Expected behavior and actual behavior.
I expect gdal2tiles to copy alpha-channel from the input tif (or vrt) to the output png files. It actually generates pngs where output alpha channel is always 100% for non-nodata pixels and 0% for nodata pixels. I would expect it to have alpha=0% for notada and alpha=value_from_alpha_channel for non-nodata pixels.
Steps to reproduce the problem.
My input file bands:
Command for generating tiles:
Operating system
Linux 5.10.0-6-amd64 #1 SMP Debian 5.10.28-1 (2021-04-09) x86_64 GNU/Linux
GDAL version and provenance
3.2.1
The text was updated successfully, but these errors were encountered: