If you have any interest in raw shooting you must know by now that Microsoft has (finally!) delivered its own add-in enabling support for raw formats in Windows Explorer and Photo Gallery.
The first questions that come to mind are is it any good? Is my camera and my operating system both supported by this new package? How well does it run compared to other similar products?Immediately after the release of the Microsoft Camera Codec Pack we began receiving emails from our users asking for comparisons between our own FastPictureViewer Codec Pack, a mature product with 2.5+ years in the field, and Microsoft’s new offering.
First thing first, the Microsoft Camera Codec Pack is a free download from the Microsoft website. The FastPictureViewer Codec Pack, on the other hand, is a commercial product that can be licensed from us for a fee. That makes for our first point of comparison.
Microsoft pretends having “changed the game” regarding raw files handling in the Windows Operating System and achieved “GPU-like” performance by taking advantage of multicore CPUs, as well as covering all grounds regarding platform support and camera models, past and present. July 2011 YouTube video here.
So far so good, the commercials sound vibrant but conspicuously omit a couple of key facts:
Raw support in Windows is nothing new
On June 1, 2005, Microsoft officially announced their intention to deliver raw support to Windows Vista “that will enable consumers to easily work with RAW files” (press release).
Later the same year, the company released the Microsoft RAW Image Thumbnailer and Viewer for Windows XP, adding raw support for a number of digital cameras to their flagship operating system of the times.
Finally, Windows Imaging Component (WIC), the framework upon which WIC raw codecs rest, shipped as an integral part of the operating system with Windows Vista and XP SP3 in late 2006 and was part of every Windows releases since then.
Camera manufacturers and 3rd parties have been supplying codecs for years
Canon, Nikon, Sony, Olympus, Pentax, Panasonic and small independent software vendors like us FastPictureViewer and Ardfry Imaging have been supplying raw codecs for Windows for a number of years (as early as 2006 for some). It took Microsoft more than 6 years to come up with their own take, but partners and ISVs have been supplying Windows-compatible codecs based on the WIC infrastructure for a long time.
Back to our subject.
The first thing we’d like to mention is that, while raw support is indeed a very nice thing to have in any operating system, some basic features like automatic rotation of plain old JPEG files, according to camera orientation, are still not addressed by Microsoft as of today: portrait images are displayed sideways in Windows Explorer, Windows Photo Viewer, Windows Photo Gallery and Windows Media Center, unless manually rotated.
The FastPictureViewer Codec Pack addresses this shortcoming by providing a JPEG decoder with the intelligence needed to recognize the orientation data written within the files by digital cameras and the muscle to do the rotation when required.
When our JPEG codec detects that an image needs to be rotated it performs the necessary action on-the-fly, without ever modifying the original file, and Explorer, Photo Viewer, Photo Gallery and Media Center 6.1 auto-magically starts displaying images in the correct orientation!
JPEG Decoding Performances
This brings us to our first performance metric: JPEG has been around for a long time and JPEG decoding libraries have been optimized and re-optimized over the years. One can expect that the JPEG decoder created by Microsoft and shipping with every copy of Windows since 2006 (Vista and XP SP3) is very well optimized – and in fact it is.
Still, we managed to produce a JPEG codec that runs quicker than Microsoft’s, despite the additional work required to perform the rotations:
Time required to decompress (and rotate, in the FastPictureViewer Codec Pack case) an out-of-camera portrait-oriented 12.1MP JPEG image created by a Nikon D3 DSLR. Intel i7-970 processor, times in milliseconds, lower numbers means faster performances. Results averaged over 5 consecutive runs with the same image after 1 priming run to factor out disk performance.
That’s right: our auto-rotating JPEG decoder performs additional work and still runs 25% faster, rotating an image, than Microsoft’s which simply ignore the rotation information.
Now that the introductions are made, we can dig through the heart of our subject.
Supported Camera Models
Number of camera models supported by each codec pack. Higher number is obviously better.
While Microsoft pretends to have covered all grounds they are far from supporting all raw-capable cameras on the market. Perhaps more importantly, their support is frozen 18 months back (at the time of this writing, and counting), probably due to exceedingly long internal testing phases and sign-off procedures.
That means that all cameras released in the past year and a half are not supported by the Microsoft Camera Codec Pack, this includes cameras like the Canon 60D, Nikon D7000, Nikon D3100, Nikon D5100, Sony NEX-5 and many, many others that can be seen today on every retailer’s shelves.
The 18 months gap gives a glimpse at their release cycles, which are unlikely to get any shorter anytime soon (the original Microsoft RAW Thumbnailer and Viewer for Windows XP released back in 2006 was never updated with new models support in 6+ years).
By contrast, the FastPictureViewer Codec Pack gets refreshed about 6 times a year with raw compatibility updates, adding new features and timely support for all the latest models on the market: for example support for the Canon 60D and the Nikon D7000 – both missing from Microsoft’s offering – was added to the FastPictureViewer Codec Pack on November 11, 2010 already, and we have added more than 20 other new models since then including NEX-3, NEX-5, D5100, A230, A290, 600D, T3i, X5, 1100D, A390, X100 and more, raising our total to 379 387 supported models as of August October 2011 vs. 120 for Microsoft.
Microsoft has a long gap to fill regarding camera model support and will likely always be late to the game, due to their lengthily release cycles and everything else we don’t know about (such as changes in internal priorities). Writing imaging codecs requires a very specific skillset and chances are that the people able to actually do this efficiently are few and far apart, and likely have better (more important) things to do… Time will tell.
Platform Support
The Microsoft Camera Codec Pack does not support Windows XP nor Windows XP 64 nor Windows Server 2003. It does not support Windows Vista RTM nor Windows Vista SP1.
Windows XP alone still has about 50% global market share at the time of this writing, if we believe the operating system statistics supplied by specialized companies. That’s a lot of users left out of the “holistic story that covers all Windows platforms” recently touted by Microsoft.
By contrast, the FastPictureViewer Codec Pack supports all platforms onto which Windows Imaging Component can be (or is) installed. Our product can be installed on Windows version going as far back as Windows XP SP2 and Windows XP 64. Of course functionality is reduced on the old platforms (the XP Fax viewer will never display any raw files) but we provide extremely quick thumbnail support to Windows XP and XP-64 for all the camera models and file formats handled by our FastPictureViewer Codec Pack.
Raw Previewing and Full Raw Decoding Performances
When Microsoft originally introduced the Windows Imaging Component platform back in 2005, on which the codecs discussed here rests, it was told that capabilities would be added to the platform to allow for controlling the raw conversion in such a way that makes it possible to build raw converter applications on top of the new codec-based infrastructure.
As of today there are no (zero) known application that takes advantage of these features and as a matter of fact, the just released Microsoft Camera Codec Pack returns a “not implemented” error when queried about its raw conversion control abilities, via the QueryRawCapabilitiesInfo() call, which means that all the Microsoft codecs have to offer today is a default raw conversion using arbitrary internal parameters, with no user intervention possible.
If one compares this complete lack of “tunability” to the level of fine control exposed by, say, Adobe Camera Raw, Adobe Lightroom, RawTherapee or Bibble Pro, just to name a few serious raw converters available on the market today, or open source efforts like UFRaw or DCRaw, one readily understand that WIC raw codecs are not going to have any profound impact on the “real” raw conversion business landscape anytime soon, where users tweak every minute aspects of the raw conversion process using countless sliders, presets, camera profiles and even individual lens profiles.
As a matter of fact, Thomas Knoll (the original author and lead architect of Adobe Photoshop and Adobe Camera Raw, the raw conversion engine used by Adobe Lightroom and Photoshop) described WIC raw codecs as “basically useless for Camera Raw / Lightroom type of applications” (read his own words in Adobe’s forum).
If one is looking for full photographic control, “a WIC codec is likely to prove unsatisfying”, according to Zalman Stern, Tech Lead for Adobe Camera Raw and author of the Adobe DNG WIC Codec (read his post on DPReview).
This leaves us with one type of use for WIC raw codecs, albeit a very important one: help users visually organize their files in Windows Explorer by providing high quality thumbnails, fast previews as well as quick slideshows in Windows Photo Viewer and Photo Gallery.
Users of Windows Media Center on Windows 7 or later also benefit from having WIC raw codecs installed as they can project raw slideshows on their living room TV though a Media Center Extender, such as the Xbox 360: raw support at the platform level is great!
Most camera manufacturers had the good idea to include a ready-made preview image within their raw files. This image is usually stored in compressed JPEG format and reflects all camera settings such as sharpening, contrast, white balance, and manufacturer “secret sauce” like Nikon Picture Control or Canon’s Picture Style. In fact, all camera options available through the camera’s menus and modes are reflected on the preview image, which is made by the camera itself and stored in the raw files as the pictures are taken.
This preview image is perfect for the uses mentioned above: JPEG data can be unpacked very quickly (we showed above that we are pretty good at this) and the resulting image is faithful to what the photographer saw with its own eyes when the image was captured: if you like Canon’s skin tones then you are going to get them on the preview JPEG, if you like Nikon’s sunset colors you’ll get them on the previews too. In fact all the coveted image science of the camera manufacturers is reflected on these preview images, unlike raw conversion from non-manufacturer software which basically throws away all this goodness and starts over from scratch.
We realized this long time ago and the FastPictureViewer Codec Pack is optimized for the previewing, slideshow and thumbnail scenarios described above, probably covering 99.x% of all WIC raw codecs uses so far. Our codecs use the JPEG images by default and provide stellar previewing performances, letting applications display a high-quality previews far quickler than when converting the full raw data, with faithful colors and all camera settings applied. Edits made to the raw files with manufacturer software (such as Nikon’s Capture NX) are also reflected on the preview image and shown by our codecs on the thumbnails, Explorer’s preview pane and full-scale images.
On the contrary, Microsoft, probably pursuing different goals, elected to ignore the preview image entirely – it’s not even exposed by their codecs -and instead concentrated all its efforts to speed up the full raw conversions.
As a matter of fact they did an impressive job but without a doubt the resulting images invariably differs from the camera produced JPEGs, sometimes in subtle ways and some other times in not so subtle ways, with obvious color shifts or exposure errors (remember: there is no way to tweak the conversion process so you have to live with what they give you, and no camera effects are applied!)
As written above, manufacturer and 3rd-party applications like Capture NX or Adobe Lightroom update the preview image in NEFs and DNGs, respectively, after edits are made. The FastPictureViewer Codec Pack’s use of the preview image means that those edits will be visible on thumbnails and Explorer previews with our product, but the Microsoft package, always starting over from the original raw data, will not show any changes made by users.
As far as performance is concerned, we picked files from a couple of flagship camera models from Canon and Nikon, as well as a few mid-range models and timed both the full raw conversion performances of both packages, as well as the FastPictureViewer Codec Pack’s unique “fast previewing” optimized mode, which is active by default (our codec’s behavior regarding the use of the embedded JPEG preview can be adjusted from a supplied Control Panel applet, so if you insist for full raw conversion you can have it too).
Here is what we came up with (remember: the Microsoft product does not support any new camera, we had to stick to old models so no 60D or D7000 numbers, sorry).
Nikon NEF (D3X, D3, D300S, D2X, D70S)
Nikon NEF full raw decoding performance of both Codec Packs, as well as FastPictureViewer's unique "fast preview" optimized mode, shown in green with actual time on top. Intel i7-970 processor, times in milliseconds, lower numbers means faster performances. Results averaged over 5 consecutive runs with the same image after 1 priming run to factor out disk performance.
Canon CR2 (EOS 1D MkIV, 7D, 5DMkII, T2i, 1000D)
Canon CR2 full raw decoding performance of both Codec Packs, as well as FastPictureViewer's unique "fast preview" optimized mode, shown in green with actual time on top. Intel i7-970 processor, times in milliseconds, lower numbers means faster performances. Results averaged over 5 consecutive runs with the same image after 1 priming run to factor out disk performance.
As can be seen on the above graphs, Microsoft’s efforts so far regarding full raw conversion approximately matches the FastPictureViewer Codec Pack’s for the NEF and CR2 formats we tested when used in full conversion mode, within a few percentage points. Five times out of ten, the FastPictureViewer codec is slightly faster than Microsoft’s “Multicore, GPU-like performance”, and slightly slower the other five times.
What is striking, however, is how well our unique Fast Preview mode performs and how much quicker it is compared to both package’s full raw decoding scores.
In extreme cases, such as the current top Canon EOS 1D MkIV and EOS 7D models, the fast previewing – which creates a full-resolution 16MP image for these camera, is more than TEN TIMES quicker than the full raw conversion counterpart.
In the case of the lower-end Canon 1000D, which only stores a medium-resolution preview, the performance difference is even greater, from Microsoft’s 700ms best time (0.7s) down to 20ms (0.02s) for our Fast Preview time, a shockingly unreal THIRTY FIVE times (35x) quicker.
The performance gap is not as big with the Nikon NEF files we tested, still, we observed performance difference in the order of four to ten times faster in favor of our product when using the default Fast Previewing mode, and comparable performances in full raw mode.
All Nikon cameras since the D2 store a full-resolution preview image, so are new cameras from Canon and most other manufacturers, so there is little incentive to decode the full raw data just to produce a thumbnail or screen-size preview from it.
The images returned by the FastPictureViewer codecs in Fast Preview mode are probably not suitable for “darkroom quality” art gallery printing (neither are Microsoft’s full raw conversions anyway) but the point is no one is going to use this type of codecs for true art-quality work, if only for the lack of control over the conversion process.
The quality of images produced by the FastPictureViewer Codec Pack is undistinguishable from camera-produced JPEGs (in fact, we actually use a camera-produced JPEG in fast preview mode) and the resulting image quality and decoding performances are perfect for the codec’s most likely use today, which is mainly to provide thumbnails and instant previews to the user, to facilitate raw file management in Explorer.
To conclude the performance chapter, Microsoft’s full raw performance is indeed much higher than manufacturer-provided codecs but is basically on par with the FastPictureViewer Codec Pack in the tests we made, and then we provide an even faster Preview mode that effectively makes Microsoft’s and all manufacturer codecs appear dead-slow.
In all fairness, we must say that both the FastPictureViewer Codec Pack and the Microsoft Camera Codec Pack are in a completely different league than most manufacturer-produced codecs with regard to raw decoding performance, so Microsoft can rightfully claim that their package performs very well. So are we.
Of course, in real scenarios, factors such as disk speed and fragmentation and the fact that thumbnails, when created, are written to a database which often resides on the same disk as the one containing the images, as well as variable factors such as computer load, available CPU and memory resources etc will tend to limit the actual performance as observed from the end-user but still, waiting one or two seconds for a file to open, or one or two tenths of a second makes a tremendous difference in the user experience and in the perceived quality of the platform – Windows – compared to competing platforms such as the Apple Mac or – heaven forbids – Linux.
We believe we do a better job at this with our Codec Pack than Microsoft with theirs, and an even better job than camera manufacturers who apparently missed a thing or two in Programming 101, for the most part supplying codecs producing very good quality images but with abyssimal performances and sketchy features (check the level of user satisfaction on Canon’s forum, for example).
Keep in mind that we used one of the fastest CPU available for these tests: a six-cores Intel i7-970 with 12MB of cache and 12GB of memory. On a slower CPU all numbers should grow proportionally.
Metadata Exposed in Windows Explorer
One important aspect of being able to effectively organize file in Windows Explorer is the ability to examine annotations, rating, camera and exposure information and other data stored in the files, either by the camera itself or by manufacturer software such as Canon DPP or Nikon Capture NX. The FastPictureViewer Codec Pack goes through great lengths to expose as much of this data as possible, first to Windows Explorer but also to the Windows Search Indexer and all other interested parties.
See the result below:
Metadata surfaced by the Microsoft Camera Codec Pack
Metadata surfaced by the Microsoft Camera Codec Pack from and out-of-camera Canon 7D CR2 raw file.
Metadata surfaced by the FastPictureViewer Codec Pack:
Metadata surfaced by the FastPictureViewer Codec Pack from and out-of-camera Canon 7D CR2 raw file.
A picture is worth a thousand words regarding metadata: we just expose far more of it than Microsoft currently does (about 26 vs. about 10 elements).
How we Tested
Evaluating codecs is more difficult that testing normal applications. There is no user interface and it is actually difficult to be certain that a particular codec is in use and not another. To avoid any confusion, we always uninstalled a package then rebooted the computer then installed the other package and rebooted again.
This way, we made absolutely sure that only one of the two packages was installed at any given time, and we knew which one beyond any doubt.
We disabled the Search Indexer as it immediately starts crawling as soon as a new codec is installed, interfering with performance tests as it exercises the disk substantially. We also let the computer settle down for a few minutes as a lot of activity occurs after startup.
We used a tool from Microsoft called WIC Explorer to load the images. This tool displays the load time in milliseconds, then we repeatedly Unloaded then Loaded the test images, writing down the times we got for 6 consecutive runs, then we averaged the last five runs. The timing was exclusively provided by this tool, there is no human lag in the measurements.
The first run was never taken into account as file loading time (disk activity) is unpredictable. By skipping the first run we ensured that the disk cache was primed and that we tested the codecs and not the disk subsystem. Any overhead induced by the WIC Explorer tool itself is included all measurements made, so there is some constant ‘C’ added to all times shown.
We tried to use the Real Time Performance Test of another Microsoft-supplied tool called WIC Cop. As an anecdote, the “not implemented” error returned by the Microsoft Camera Codec Pack, when queried for its raw capabilities, caused the codec performance tool to crash. Yes, you got that right but please let us repeat slowly: Microsoft’s raw codecs causes Microsoft’s raw codec performance test tool to crash – go figure!
Wrapup and Conclusion
The FastPictureViewer Codec Pack supports more Windows platforms, far more camera models (3x more and counting) and more metadata elements than the Microsoft Camera Codec Pack. It also provides far better performance for the typical uses of this type of codecs, as well as comparably fast performances for popular raw formats in the rare occasions where full raw conversions are desired.
Our product is likely to be updated far more often than Microsoft’s (as a matter of fact, we made two small releases since they released their product already, with a 3rd refresh currently being tested as we write this).
Our turnaround is in days not years, and we’ll always be more agile than any huge corporation. We’re actually willing to bet a FastPictureViewer Codec Pack license that the folks appearing on the Microsoft videos and posting to corporate blogs about the greatness of the Microsoft Camera Codec Pack don’t even know who, inside the company, actually produced it. When you send us an email, it is read by the very person responsible for the architecture, design and implementation of the product. Check this story from one of our users, aptly titled Outstanding responsiveness from the FastPictureViewer codec team!
From a “big picture” perspective it can only be good that more people get their hands at raw codecs, enabling them to see their files as images at last. What is not so good is that Microsoft elected to not even mention the existence of first paty (manufacturer) as well as 3rd party codecs like the FastPictureViewer Codec Pack or other WIC codec providers such as Ardfry Imaging.
It is also regrettable that they removed the “Pro Photo” website where anyone could find out about available codecs, among other things. Instead they play it like “we added raw support to Windows just now” and made sure their “single-click” download process goes directly to their Download Center only, effectively making us and other suppliers invisible.
The end-result is less choices for consumers, Microsoft quickly establishing itself as the only game in town in yet another tiny segment, putting small partners at risk of going out of business for no good reason: it is not like we were competing against them, more like helping them quench the exodus of photographers to the Mac and Linux platforms…
Worth Mentioning
Our product does not stop at 379 camera models, we also provide very fast support for Adobe PSD documents, with thumbnails, metadata and previews, as well as support for about a dozen image formats used in the Computer Graphics and Computer Game industries (EXR, HDR, PIC, SGI, IFF, TGA, DDS and several more), support for 3D digital cameras (MPO, JPS), thumbnail and preview extraction from Encapsulated PostScript (EPS) files, Adobe InDesign INDD and Adobe Illustrator AI files, thumbnail extraction from PDF files containing an XMP metadata packet (i.e. PDFs created by Adobe Acrobat software, mainly), plus a few special formats like Adobe Lightroom’s preview files.
We support more than 45 file extensions in total in the Codec Pack (no bloat: all our codecs are user-selectable at installation time), with more formats and camera models being added all the time: check the release log on the Codec Pack’s web page!
Support us!
Like this page, tweet it and retweet it, link to it from your blog or website, +1 our web pages and tell all your friends: there is hope for timely and fast Camera Raw support in Windows, and it does not come only from Microsoft…
Every bit helps and every vote counts so act now! (and don’t forget to grab our free trial)
– Axel Rietschin (founder and author)
Great write-up and a solid comparison. Lots of extra meta data is shown with the FastPictureViewer Codec Pack. I think you even show more metadata than what I see from the Canon codec and they really should know their RAW format. I wanted to try WIC Cop myself and I noticed that there is a newer version on MSDN — http://archive.msdn.microsoft.com/wictools/Release/ProjectReleases.aspx?ReleaseId=2887 and with that version Microsoft codec does not crash WIC Cop but does show that they do not support IWICDevelopRaw. Since Lightroom does not support WIC do you know what programs would use the IWICDevelopeRaw interface?
>with that version Microsoft codec does not crash WIC Cop but does show that they do not support IWICDevelopRaw
Which is the key point: Microsoft Raw Codec does not support IWICDevelopRaw (as evidenced by the “not implemented” error code) which means the user has no control whatsoever over the conversion process. The tool crashing because of that error is anecdotal. Also anecdotal: the implementation of this interface always was a requirement for raw WIC codecs: double standards, two sets of rules?
>do you know what programs would use the IWICDevelopeRaw interface
None, as far as I know. As I wrote in the article, the primary use for WIC codecs as of today is to provide Explorer thumbnails and previews, and to surface metadata to Explorer and to the Search Indexer. Our codecs are optimized for this use case.
Incidentally, all our raw codecs do implement IWICDevelopRaw and thus would allow some level of control to an application using that interface (only exposure compensation is available at this time, but I could wire up more controls), when our codecs are set to full render mode.
Last time I checked, implementations of IWICDevelopRaw in manufacturer codecs (Nikon and Canon, not to mention them) was either missing or very bogus, going from black images to crashes.
Thomas Knoll may be right an no one bothered so far, not even Microsoft in their released codecs. All Photo Gallery does is a blind conversion, then it let the users work on the 8 bit RGB data, with all camera settings and effects lost in the process: the camera-made JPEGs are actually a better starting point!
Axel, thanks for this comparison. I must admit I found that video from Microsoft a bit disengenous, and, in places, very economical with the truth.
However, one thing intrigues me. They show that they are able to use WLPG to edit RAW files directly. I’m using your FastPictureViewer Codec pack, but WLPG insists that I need to make a JPEG copy first and edit that. Are Microsoft doing some tricksy things with their RAW codec that aren’t available to third parties, or have I simply not got WLPG set up correctly?
>They show that they are able to use WLPG to edit RAW files directly
The files are first converted to JPEG then the JPEG is edited, so it’s a convert-then-edit operation. There is a “Make a Copy” button in WLPG that is used for this purpose and that you must click before performing any change. They made it clear that the original raw file was never modified and this behavior is independent of the actual codec used, FPV’s, Ardfry’s, manufacturer’s or theirs.
“They made it clear that the original raw file was never modified” – Ah, yes, so they did in the closing seconds of the video.
I admit that I never got as far as that in the first viewing – I was so appalled at the (untrue) sweeping statements earlier such as Microsoft’s codec is “for 32 and 64 bit Windows” and “for all the cameras you may have had or may have now”, that I stopped the video the first time around in disgust.
Pingback: Using RAW Codecs in Windows | Geoff Coupe's Blog
Not even Microsoft’s Camera Codec Pack, Google’s Picasa Photo Viewer, or Nikon’s very own NEF Codec work with my camera (D3100) and operating system (Win 7 64-bit). How pathetic is that? Thank you for this incredible information. Your product has just beat down three major heavyweights.
Do your codecs implement ::GetPreview() or ::GetThumbnail() for RAW previews?
Of course.