MSDN Magazine - June 2008 - (Page 113)

Kenny Kerr WindoWs With C++ Decoding Windows Vista Icons With WIC In the April issue of MSDN® Magazine I introduced the Windows® Imaging Component (WIC), showing you how you can use it to encode and decode different image formats. This month I’m going to show you how you can extend WIC by writing your own codecs. In particular, I’ll walk through the initial steps for developing an alternative decoder for the Windows icon format. First, however, let me discuss the process of writing a codec. For the most part, writing a codec is quite straightforward. A codec supporting the encoding of a particular image format must provide a COM class that implements the IWICBitmapEncoder interface. Similarly, a codec supporting the decoding of a particular image format must provide a COM class that implements the IWICBitmapDecoder interface. These are the same interfaces used by developers using WIC for image processing. In fact, the codec’s COM classes are loaded in-process and accessed directly by the developer’s application code. This provides a very efficient abstraction, allowing consumers to achieve high-performance image processing. An encoder must also provide an implementation of the IWICBitmapFrameEncode interface, which supplies methods for encoding the individual frames of an image. Even image formats that don’t support multiple frames still use the IWICBitmapFrameEncode interface to represent the image pixels. Similarly, a decoder must also supply an implementation of the IWICBitmapFrameDecode interface, which has methods for decoding the individual frames of an image. Once the codec is written, it can be created directly by a consumer using the CoCreateInstance function, but that is not very interesting. To truly integrate the codec with WIC, a few more steps are required. In particular, the encoder and decoder must include additional metadata in the registry describing their capabilities. Any DLLs containing encoders or decoders must also be signed. The metadata allows WIC to identify whether or not the codec provides the necessary features when WIC attempts to find an appropriate encoder for a particular image format or a decoder for a particular image file. Since the particular implementation that a consumer receives may be determined at run time, WIC attempts to provide a certain degree of assurance to the consumer by only allowing signed codecs to participate in the discovery and arbitration process. With the general concepts in place, I want to now take a look at a concrete example. I’ll focus on the implementation of an alternative decoder of the Windows icon format. I chose the icon format for two reasons. Firstly, Windows Vista® introduced an update to the icon format, which is notable in itself; I’ll explore the changes in a moment. Secondly, the built-in decoder that ships with Windows Vista does not actually support the updated icon format. The History of Windows Icons As with many facets of Windows, the icon format is steeped in history. In the early days of the 16-bit Windows operating system only the device-dependent bitmap (DDB) format was supported. Such a bitmap specified a width and height in pixels as well as a table that mapped pixels to entries in a particular device’s color palette. Because different devices naturally supported different Windows Vista uses PnG icons to create the illusion of vector images that scale. resolutions and had different color capabilities, these bitmaps were not easily moved from one device to another. DDBs were, however, very efficient and are in fact still used today for certain operations. A device-independent bitmap (DIB) format was introduced to correct all of the problems inherent in DDBs. Such a bitmap included its own color table independent of any particular device. The bitmap’s pixels then mapped to the bitmap’s color table, which unambiguously defined the pixel colors using red, green, and blue (RGB) color values. Naturally, it made sense for the icon format to make use of the DIB format, but there was a problem. DIB predated the use of alpha channels for representing transparency. The hardware of the time also did not permit the extravagance of an extra byte per pixel that would have been required by an alpha channel. A different solution was required. The DIB would carry an extra bitmap following the color bitmap that was effectively a bitmask identifying the transparent and opaque pixels in the color bitmap. The bits in the Send your questions and comments to mmwincpp@microsoft.com. June 2008 113

Table of Contents Feed for the Digital Edition of MSDN Magazine - June 2008

MSDN Magazine - June 2008 Contents Toolbox CLR Inside Out Cutting Edge Patterns In Practice SAAS Concurrency Robotics Form Filler GUI Library Service Station Foundations Windows With C++ Concurrent Affairs Going Places { End Bracket }

MSDN Magazine - June 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.