GNOME Bugzilla – Bug 609094
ico loader should ignore the alpha channel for fully transparent icons
Last modified: 2014-10-22 15:33:26 UTC
Created attachment 153087 [details] A weird icon According to Wikipedia's explanations [1] on the structure of windows ICO files, "when displaying 32-bit images in 32-bit mode (Windows XP onwards), the AND mask is not used". I assume that means it should be ignored, whether present or not. However some ico files encoded with 32 bits per pixel seem to have this mask, and gdk-pixbuf's ICO loader doesn't seem to ignore it as it should. If for some reason this mask happens to be full of zeroes, the resulting pixbuf will be completely transparent. An example of such a weird ico file is at http://commons.wikimedia.org/favicon.ico. I'm attaching it as well in case it changes. Loading the icon with gdk_pixbuf_new_from_file, it can be easily verified that the resulting pixbuf is fully transparent. Epiphany will for example display a seemingly empty favicon for http://commons.wikimedia.org/ whereas the browser is actually able to display the icon. [1] http://en.wikipedia.org/wiki/ICO_%28file_format%29#Legacy_format
My initial investigation is incomplete: regardless of the AND mask, the attached icon file has the alpha component of all its pixels to 0. Whether the ico loader correctly ignores the AND mask, I didn't check. I looked into webkit's BMP image decoding code, and it implements a heuristic to ignore the transparency altogether. Here is the comment from the code in WebKit/WebCore/platform/image-decoders/bmp/BMPImageReader.cpp, in the processNonRLEData method (see http://trac.webkit.org/browser/trunk/WebCore/platform/image-decoders/bmp/BMPImageReader.cpp#L742): // Some BMPs specify an alpha channel but don't actually use it // (it contains all 0s). To avoid displaying these images as // fully-transparent, decode as if images are fully opaque // until we actually see a non-zero alpha value; at that point, // reset any previously-decoded pixels to fully transparent and // continue decoding based on the real alpha channel values. // As an optimization, avoid setting "hasAlpha" to true for // images where all alpha values are 255; opaque images are // faster to draw. I would also tend to think that some other simpler implementations may ignore transparency altogether, rendering all icons fully opaque (to be confirmed).
I don't think it makes sense to spend much more effort on heuristics games, when the image format is just not clearly defined or consistently used.
(In reply to comment #2) > I don't think it makes sense to spend much more effort on heuristics games, > when the image format is just not clearly defined or consistently used. I agree. Especially given that Epiphany displays the icon properly when going to commons.wikimedia.org now, and that GIMP has the same bug. This rather points to an ill-defined format. Let us know if you can replicate the problem nowadays in an application such as Epiphany.