Bug report #1533
WMS raster transparency problem
| Status: | Closed | ||
|---|---|---|---|
| Priority: | Low | ||
| Assignee: |  ersts - | ||
| Category: | Map Canvas | ||
| Affected QGIS version: | Regression?: | No | |
| Operating System: | OS X | Easy fix?: | No |
| Pull Request or Patch supplied: | Resolution: | fixed | |
| Crashes QGIS or corrupts data: | Copied to github as #: | 11593 |
Description
It appears that a WMS raster layer with transparency set in the layer properties will increase transparency with every screen refresh until it becomes invisible. To replicate, try the NED shaded relief layer from:
History
#1
Updated by John Tull almost 16 years ago
I realize now that the link can be shortened to:
http://toposervices.cr.usgs.gov/wmsconnector/com.esri.wms.Esrimap/USGS_EDNA_geo?
#2
Updated by ersts - almost 16 years ago
- Status changed from Open to In Progress
This is a known issue. If you keep repeatedly hitting apply, the transparency it is additive. Likewise, if you decrease the transparency, it is still additive. However, if you pan the map canvas a little and cause a new fetch request, your layer will be at the correct/expected transparency level.
It seems to be a bug in Qt with setting the alpha value for an image more than once. Each apply causes a refresh and thus a reapplication of the alpha value. Too speed things up, the WMS provider does not request a new version of the image if the extent has not changed, it uses a cached version.
I am going to downgrade this a little, while it needs to get fixed but it does not cause a crash or a damage of data
#3
Updated by John Tull almost 16 years ago
Peter: Thanks for the detailed explanation. I did not see a bug filed, so added it this weekend. It sounds like I need to be filing bugs against Qt instead... Also, it's good to know that forcing a wms refresh works around the problem.
#4
Updated by ersts - almost 16 years ago
I think it is more just that setAlphaChannel() does not work quite a expected. When you use that method it changes the image format to QImage::Format_ARGB32_Premultiplied
The image is stored using a premultiplied 32-bit ARGB format (0xAARRGGBB), i.e. the red, green, and blue channels are multiplied by the alpha component divided by 255. (If RR, GG, or BB has a higher value than the alpha channel, the results are undefined.) Certain operations (such as image composition using alpha blending) are faster using premultiplied ARGB32 than with plain ARGB32.
So I changed it around a little have had the WMS Provider store a QImage::Format_ARGB32 then just adjusted the pixel values on each refresh. WMS images should be small enough to not see any performance hit.
The mods were made to the trunk r:10146. If you can take it for a spin and make sure it works more as expected. If it does I will close the ticket and add it to the Version-1_0 branch for inclusion in the next release.
#5
Updated by John Tull almost 16 years ago
- Status changed from In Progress to Closed
- Resolution set to fixed
It does appear to be working now. Great! I closed the ticket.
#6 Updated by Anonymous over 15 years ago
Milestone Version 1.0.1 deleted