#1533 closed bug (fixed)
WMS raster transparency problem
Reported by: | jctull | Owned by: | ersts |
---|---|---|---|
Priority: | minor: annoyance | Milestone: | |
Component: | MapCanvas | Version: | Trunk |
Keywords: | wms raster transparency refresh | Cc: | |
Must Fix for Release: | Yes | Platform: | OS X |
Platform Version: | 10.5.6 | Awaiting user input: | no |
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:
Change History (6)
comment:1 by , 15 years ago
comment:2 by , 15 years ago
Owner: | changed from | to
---|---|
Priority: | major: does not work as expected → minor: annoyance or enhancement |
Status: | new → assigned |
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
comment:3 by , 15 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.
comment:4 by , 15 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 [[BR]] ARGB format (0xAARRGGBB), i.e. the red, green,[[BR]] and blue channels are multiplied by the alpha component [[BR]] divided by 255. (If RR, GG, or BB has a[[BR]] higher value than the alpha channel, the results [[BR]] are undefined.) Certain operations (such as [[BR]] image composition using alpha blending) are faster [[BR]] 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.
comment:5 by , 15 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
It does appear to be working now. Great! I closed the ticket.
I realize now that the link can be shortened to:
http://toposervices.cr.usgs.gov/wmsconnector/com.esri.wms.Esrimap/USGS_EDNA_geo?