http://bugs.winehq.org/show_bug.cgi?id=24301
Summary: ICO parsing improvements Product: Wine Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: windowscodecs AssignedTo: wine-bugs@winehq.org ReportedBy: damjan.jov@gmail.com
Created an attachment (id=30625) --> (http://bugs.winehq.org/attachment.cgi?id=30625) Sample icons
While doing some research on ICO files for another open source project, I uncovered quite a few problems and missing features in Wine's windowscodecs implementation:
* ICONDIRENTRY is not meant to be used for parsing the image data, only the BITMAPINFOHEADER is used. In fact, the ICONDIRENTRY can contain total rubbish, and Windows still parses the ICO file fine (as determined by Windows Explorer's thumbnail). Chances are Windows only uses ICONDIRENTRY when selecting the "best" icon for a particular screen bit depth, and further decoding is only done via the BITMAPINFOHEADER. * BITMAPINFOHEADER only exists for BMP images, there is also (starting with Windows Vista) PNG instead. * Only BITMAPINFOHEADER of size 40 bytes seems supported, neither BITMAPV4HEADER nor the OS/2 bitmap header work in its place. * Contrary to Microsoft's documentation, compressed bitmaps are supported. At least BI_BITFIELDS compression works. It wouldn't surprise me if all other compressions worked. The best way to implement ICO bitmap decoding thus seems to be to defer to the BMP decoder. * ICO files with right-way-up bitmaps (negative biHeight), which Wine's windowscodecs goes to great lengths to support, seem not to work on Windows in my limited testing. * 16 BPP bitmaps, which Wine's windowscodecs doesn't support, are valid in ICO files. * The trailing AND mask is optional for 32 BPP bitmaps. * As a special gotcha, If the bitmap is 32 BPP, and the AND mask is present, and the alpha channel would make every pixel completely transparent, Windows ignores the alpha channel and uses only the AND mask to determine transparency. Real world icons exist that need this (https://bugzilla.gnome.org/show_bug.cgi?id=609094). * A palette of size biClrUsed can exist even for > 8 BPP, and specifies the "optimal viewing palette". It needs to be skipped when decoding such an image.
I am attaching some sample icons that highlight some of these problems.
Most open source ICO parsers (GIMP, Imagemagick, gdk-pixbuf) suffer from many of these problems, so test only against Windows.
http://bugs.winehq.org/show_bug.cgi?id=24301
--- Comment #1 from Vincent Povirk madewokherd@gmail.com 2010-09-07 14:21:37 CDT --- When you say ICONDIRENTRY can contain total rubbish, does this include the PNG case? I.e. should we be checking for the PNG magic number in the image data, rather than a special depth in an ICONDIRENTRY?
http://bugs.winehq.org/show_bug.cgi?id=24301
--- Comment #2 from Damjan Jovanovic damjan.jov@gmail.com 2010-09-07 14:24:33 CDT --- Yes, PNG has to be checked by the first few bytes in the resource data instead of by any ICONDIRENTRY values.
http://bugs.winehq.org/show_bug.cgi?id=24301
--- Comment #3 from Vincent Povirk madewokherd@gmail.com 2010-09-07 14:37:08 CDT --- Grr, it's just sinking in how complicated this is.
Sharing code with the BMP decoder would be really nice. I've been wanting to add a packed DIB variation to it for a while, and this sort of thing could be similar. I'll have to take another look at it and see if I can't move the ICO frame decoding in with the bmp code (or png code as the case may be).
http://bugs.winehq.org/show_bug.cgi?id=24301
--- Comment #4 from Vincent Povirk madewokherd@gmail.com 2010-09-07 14:40:49 CDT --- Created an attachment (id=30626) --> (http://bugs.winehq.org/attachment.cgi?id=30626) WIC image decoding test program
In case it's useful, here's a test program I've used for WIC decoders in the past. It decodes the first frame of an image and draws it using gdiplus. It could be easily extended for frame selection, but I haven't needed that yet.
http://bugs.winehq.org/show_bug.cgi?id=24301
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Platform|All |Other Version|unspecified |1.3.2 Summary|ICO parsing improvements |ICO parsing needs an | |improvement OS/Version|All |other Severity|normal |enhancement
http://bugs.winehq.org/show_bug.cgi?id=24301
--- Comment #5 from Vincent Povirk madewokherd@gmail.com 2010-09-11 19:19:04 CDT --- The icon in your test has a height of 32 in the BITMAPINFOHEADER, not 16. How am I supposed to tell the difference between a 16x16 icon with a mask and a 16x32 icon without one?
http://bugs.winehq.org/show_bug.cgi?id=24301
--- Comment #6 from Damjan Jovanovic damjan.jov@gmail.com 2010-09-12 02:07:50 CDT --- IIRC the rows for the AND mask are always included in the height, even if the AND mask is absent.
The absence of the AND mask is detected by the dwBytesInRes being too short to hold the AND mask data.
This may need some more testing.
http://bugs.winehq.org/show_bug.cgi?id=24301
--- Comment #7 from Vincent Povirk madewokherd@gmail.com 2010-09-16 14:07:29 CDT --- I've sent patches for this: http://www.winehq.org/pipermail/wine-patches/2010-September/093322.html http://www.winehq.org/pipermail/wine-patches/2010-September/093323.html
Remaining possible issues after these patches: * No PNG support, but it should now be easy to add. * Compressed bitmaps are supported, but if RLE4 or RLE8 bitmaps are combined with a mask, we won't find the mask. I don't know if Windows can accept that combination, or even RLE-compressed icons. * Negative biHeight is still given no special treatment for icons, i.e. it is treated as top-down. * The trailing AND mask is ignored for all 32-bit bitmaps.
http://bugs.winehq.org/show_bug.cgi?id=24301
--- Comment #8 from Vincent Povirk madewokherd@gmail.com 2011-01-10 15:40:10 CST --- The zero-colorplanes icons load in Wine's WIC but not on Windows. Do we care about those?
I plan to send some patches that make the other sample icons work today. Is there anything else left to be done?
http://bugs.winehq.org/show_bug.cgi?id=24301
--- Comment #9 from Damjan Jovanovic damjan.jov@gmail.com 2011-01-11 02:45:59 CST --- (In reply to comment #8)
The zero-colorplanes icons load in Wine's WIC but not on Windows. Do we care about those?
I plan to send some patches that make the other sample icons work today. Is there anything else left to be done?
Zero colorplanes doesn't concern me, but > 1 colorplanes might mean something special (wasn't the colorplane value used for something back in the CGA/EGA days?). Either way it would be a BMP decoder issue, not part of this bug.
Otherwise I am happy, you can close this bug. Thank you for working on it :-).
http://bugs.winehq.org/show_bug.cgi?id=24301
Vincent Povirk madewokherd@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #10 from Vincent Povirk madewokherd@gmail.com 2011-03-25 13:58:54 CDT --- Fix't.
http://bugs.winehq.org/show_bug.cgi?id=24301
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #11 from Alexandre Julliard julliard@winehq.org 2011-04-01 12:40:36 CDT --- Closing bugs fixed in 1.3.17.