Robert A. Wlodarczyk's Blog (MSFT) : Windows Longhorn

Implementing a Custom CODEC for the WindowsCodecs Extensibility System

RWlodarczyk — Thu, 11 Aug 2005 04:41:00 GMT

As the name implies, a CODEC is a enCOder and DECoder. In the case of WindowsCodecs, Microsoft provides a set of APIs that allow our customers to implement their own CODEC for their custom image file format. Like this anyone who utilizes the WindowsCodecs APIs will be able to take advantage of all of the built-in CODECs as well as any custom CODECs installed on the machine. The WinFX Beta 1 SDK (with some minor modifications) provides the necessary headers and libs for taking the first steps in building your own CODEC.

Implementing a Decoder
There are 2 interfaces that you must implement:

IWICBitmapFrameDecode
IWICBitmapDecoder

Implementation is found in AitDecoder.h|cpp

Implementing an Encoder
There are 2 interfaces that you must implement:

IWICBitmapFrameEncode
IWICBitmapEncoder

Implementation is found in AitEncoder.h|cpp

Miscellaneous Glue
In addition to implementing the 4 interfaces, you must setup the registry in order for WindowsCodecs to know about the custom CODEC. Ideally, these can be added as part of your CODEC's MSI package or as part of the DllRegisterServer() so that when you register the DLL on the machine these registry entries get set.

Implementation is found in Main.cpp as well as some helpers in ClassFactory.h, RegistryValueManager.h, UnknownImpl.h

About the sample "AIT" CODEC
When my team and I were designing the "AIT" (Avalon Imaging Test) CODEC, we wanted to keep it as simple as possible. It doesn't utilize any compression methods. It's pretty much a straight "dump" of the pixel data to a persistent format. Also, we wanted to represent data as if this were a "production" CODEC, so concepts such as image blocks are similar to other formats, such as PNG. Within the AIT CODEC, a block takes the form of:

struct AIT_BLOCK
{
    uint8_t name[4];      // used to distinguish the type of block
                           // (first 3 bytes are ASCII, last byte must be 0)
    uint32_t frame_number; // specifies which frame in the
                           // image this data should be applied to
    uint32_t size;         // gives the number of bytes in
                           // the data section of the block
    uint8_t data[size];   // gives the raw data of the block
                           // (must be interprested based upon
                           // the name of the block)
};

There are 6 types of blocks that the AIT CODEC support -- AIT, COL, FRA, PAL, PRE, THU

AIT Block
This block must be the first block in the file and must be specified only once. It may be regarded as the header of AIT files.
The data section of this block takes the form:

struct AIT_BLOCK_DATA
{
Uint32_t num_frames; // number of frames in the images (permitted to be 0)
};

COL Block
This block specifies a color context to be applied either globally to the image (when AIT_BLOCK.frame_number == 0xFFFFFFFF) or to a frame (when AIT_BLOCK.frame_number != 0xFFFFFFFF).
The field AIT_BLOCK.size specifies the size in bytes of the ICM profile to be used in this color context.
The data section is the value of those bytes.

FRA Block
This block specifies the bitmap data of a frame. The AIT_BLOCK.frame_number must be a value in the range [0, N) where N is the number of frames in the image (as specified in the AIT block).
The data section of this block takes the form:

struct FRA_BLOCK_DATA
{
BITMAP_SOURCE_DATA bitmap_source;
};

where BITMAP_SOURCE_DATA takes the form:

struct BITMAP_SOURCE_DATA
{
    uint32_t width;                        // width dimension of the image
    uint32_t height;                       // height dimension of the image
    double   dpi_x;                        // resolution (pixels/inch) of image in X direction
    double   dpi_y;                        // resolution (pixels/inch) of image in Y direction
    uint32_t stride;                       // the number of bytes needed to
                                           // encode one scanline of the bitmap
    GUID     pixel_format;                 // the GUID of the pixel format of this bitmap
                                           // valid values include those recognized
                                           // in wincodec.h (GUID_WICPixelFormat*)
    uint8_t bitmap_data[stride * height]; // all data values one scanline at a time beginning
                                           // at the top-most scanline and continuing
                                           // to the bottom-most scanline
};

(Here, a double is an IEEE 64-bit floating-point number and GUID is 16 bytes used to uniquely identify an object.)
A FRA block, therefore, is simply the BITMAP_SOURCE_DATA needed to represent that frame.
BITMAP_SOURCE_DATA contains a variety of fields.

PAL Block
This block specifies a palette to be either applied to the image as a whole or to an individual frame (using the same logic as outlined in the COL block).
The data section of this block takes the form:

struct PAL_BLOCK_DATA
{
uint32_t num_colors; // number of colors in this palette (must be > 0)
WICColor colors[num_colors]; // gives those colors as WICColors (defined in wincodec.h)
};

PRE Block
This block specifies a preview bitmap that may be applied to the image as a whole (AIT_BLOCK.frame_number must equal 0xFFFFFFFF).
Its data section is simply a BITMAP_SOURCE_DATA (similar to a FRA block).

THU Block
This block specifies a thumbnail bitmap the may be applied to the entire image or a single frame (as specified in the save rules as COL’s).
Its data section is simply a BITMAP_SOURCE_DATA (similar to a FRA block).

Acknowledgements
This CODEC was originally written by one of the testers on my team, Frank Krueger (but has since left Microsoft). Also, the code was reviewed by our development leads, Rajat Goel and Thomas Olsen. Many thanks to all of them for their help and effort in getting this sample posted.

CODE (Beta 1): AitCodec.zip

BETA 1 SDK work around: UpdatedInclude.zip

Working on implementing a CODEC

RWlodarczyk — Thu, 11 Aug 2005 01:16:00 GMT

As I mentioned last week, I would be sharing a test implementation of a CODEC built for the WindowsCodecs extensibility system. This work is progressing along nicely... the CODEC is full written and working. However, there were a few snags that I hit... which, unfortunately, are snags that will be hit by others as well. Here are the work-arounds for the two issues:

WINCODEC_SDK_VERSION is incorrect. In the wincodec.h that is shipped with the WinFX Beta 1 SDK, this version is set to 0x0228. The correct version is 0x0229.

On line 213 of wincodec.h, replace:

#define WINCODEC_SDK_VERSION 0x0228
with
#define WINCODEC_SDK_VERSION 0x0229
If you #include <wincodec.h> you'll get build errors:

.
.
.
c:\program files\microsoft sdks\winfx\include\wincodec.h(463) : error C2061: syntax error : identifier '__RPC__in'
c:\program files\microsoft sdks\winfx\include\wincodec.h(466) : error C2061: syntax error : identifier '__RPC__inout'
c:\program files\microsoft sdks\winfx\include\wincodec.h(473) : error C2061: syntax error : identifier '__RPC__out'
.
.
.
In order to work-around this, please download the rpcsal.h and on line 32 of wincodec.h add:
#include "rpcsal.h"

Alternatively, you can get the updated wincodec.h and rpcsal.h from here.

As for the CODEC itself, I should have it up here by the end of the week. It's code complete, I just need to write it up a bit before I post it.

Introducing WindowsCodecs!

RWlodarczyk — Thu, 04 Aug 2005 21:44:00 GMT

Last night, Pablo made a post to the Avalon newsgroups about WindowsCodecs... To quote him directly:

We are pleased to announce that the documentation for Avalon's Windows CODECs is now posted on MSDN.

http://winfx.msdn.microsoft.com/library/default.asp?url=/library/en-us/wic/wiclh/imagingcodec/overviews/aboutwindowsimagingcodec.asp

This component of Avalon/Windows Presentation Foundation provides an extensible mechanism for supporting different imaging formats. An application that uses these APIs can open/save images in multiple formats, both provided by Microsoft and third parties. The individual CODECs are implemented in unmanaged code. The imaging infrastructure can be used both from unmanaged or managed code.
http://winfx.msdn.microsoft.com/library/default.asp?url=/library/en-us/wcp_conceptual/html/4b9264c8-44ca-4f8b-b9b0-3b52ff106d35.asp

Along with an extensible image format infrastructure (including registration, discovery, and arbitration), the architecture includes extensibility for metadata formats.

An excellent overview was given at the WinHEC conference earlier in the year.
http://download.microsoft.com/download/9/8/f/98f3fe47-dfc3-4e74-92a3-088782200fe7/TWPR05004_WinHEC05.ppt

This architecture provides the basis for RAW support by different companies
http://www.microsoft.com/presspass/press/2005/jun05/06-01RAWWindowsPR.mspx

In addition to imaging extensibility, the additional functionality in other areas provided by Avalon , such as text and graphics, makes Avalon the ideal platform for imaging applications, including for web based Windows applications. A couple of additional components that complement this functionality are Longhorn/Windows Vista's Next Generation Print Path, which enables higher color fidelity for the print path, and Avalon's use of Direct3D to accelerate operations with images.

We welcome your feedback and questions, and hope to have the opportunity to chat with you about this and other Avalon/Windows Presentation Foundation technologies at the Professional Developer Conference next month in Los Angeles (http://msdn.microsoft.com/events/pdc/).

Additionally, once you install the WinFx SDK, you'll find:

wincodec.h and wincodecsdk.h in C:\Program Files\Microsoft SDKs\WinFX\Include
windowscodecs.lib in C:\Program Files\Microsoft SDKs\WinFX\Lib
- for x64 version of this lib, use: C:\Program Files\Microsoft SDKs\WinFX\Lib\AMD64
- for ia64 version of this libe, use C:\Program Files\Microsoft SDKs\WinFX\Lib\ia64

Stay tuned for a bunch of samples... those will be coming within the next week.

My next Avalon Imaging sample...

RWlodarczyk — Sat, 17 Jan 2004 04:23:00 GMT

I just posted my next Avalon Imaging sample. This one is an entire one devoted to ImageEffectGlow.

More samples coming next week!

Avalon Imaging Samples

RWlodarczyk — Fri, 16 Jan 2004 05:07:00 GMT

Recently I've been playing around with the PDC build of Longhorn at home along with the PDC build of VS.net Whidbey. I figured that I would write up some samples using both of these. In particular, I wanted to write some samples of how to use some Avalon Imaging APIs.

I just posted the first in a series of samples that I will be writing. All of these posts will be placed on my LonghornBlogs blog since I'd like to keep a collection of those sample there.

The first sample is an example of how to use some of the Avalon Imaging ImageEffects. This covers some of the classes starting with the name of: MSAvalon.Windows.Media.ImageEffect*.

Please leave me feedback on the sample in the comments section. I'd love to hear what people think...

Enjoy :)

Interesting read...

RWlodarczyk — Thu, 16 Oct 2003 06:33:00 GMT

DonXML discusses some interesting viewpoints on SVG and Avalon... SVG is definitely a very hot standard. I'm very excite about it as I wrote about it back in July.

Longhorn Blogs!

RWlodarczyk — Tue, 30 Sep 2003 07:03:00 GMT

Scoble points to his new Longhorn specific blog... I've got one too courtesy of Robert McLaws. Here's the Cowboy Wlodarczyk Longhorn Blog.

Also check out www.longhornblogs.com.

Longhorn, MSBuild...

RWlodarczyk — Wed, 17 Sep 2003 03:28:00 GMT

Two things to watch out for:

Longhorn Developer Center

MSBuild talks at PDC

Developers 37 times!!!

RWlodarczyk — Sat, 13 Sep 2003 07:23:00 GMT

Don Box points to this very funny PDC spoof video. Go check it out.

WS's and Longhorn

RWlodarczyk — Mon, 08 Sep 2003 05:41:00 GMT

Charles Cooper of CNET has an interesting take on Longhorn and Web Services.

Ok, so he says that big companies aren't abandoning ship on J2EE just because Ballmer says .NET is better... But in fact, if you look at the toolset provided by VS.net, developing Web Services with .NET is far easier than anything in the Java world. I suppose that Java developers don't realize that. Also, Charles says that everything that Java has Microsoft's gradually reinvented... I personally wouldn't say that that is accurate. Ok, from the naive look you can say that .NET and Java “are the same”, but fundamentally they aren't. Performance wise .NET is better. GC is handled differently in .NET than in Java. Creating Windows (or windowed) applications is different (ie: they actually look like real MFC Windows Applications, unlike Swing). .NET has this ubiquoty about it, where even if you look at mobile devices, you can create applications on a Toshiba Pocket PC and not have to worry whether it will run on an iPaq. This is simply not the case with J2ME. I won't even get started about development for .NET on the SmartPhone compared to development of applications for Java cell phones.

In terms of Web Services, show me another platform (eh em, Java) where you have fantstic things like the Web Services Enhancement SDK (that is for .NET!) (v2 TP, v1). This SDK implements not-yet-standards or some proof-of-concept things. Show me something like this for Java developers. Ok, ok, IBM has something supporting some of the things in WSE, but not as innovative or “risk-ey“ as WSE. As Don Box pointed out a while ago, WSE is for the Web Service enthusiasts out there. There is simply nothing like this for Java.

So simply put, yes .NET is better. Looking into the future, the future looks very bright for .NET support. Look for more insanely awesome stuff to come. If you're going to the PDC, you'll love it. For those who aren't going, I'm sure plenty of bloggers will be blogging about the insanely awesome stuff.