[Bug 24301] New: ICO parsing improvements

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: [e-mail]
        ReportedBy: [e-mail]

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.