Difference between native codecs and WIC

[andreas-eriksson]

Is there a difference in performance or quality when using the default WIC versus the native codecs for jpeg or png?

[saucecontrol]

It's complicated. I meant to document some of this better, but it's kind of a moving target. I'll go ahead and leave some notes here, but this is subject to change.

JPEG

libjpeg-turbo is faster and has very slightly improved accuracy over WIC's JPEG. The performance improvement is quite pronounced on progressive JPEG decode.

The native plugin also supports optimized huffman tables and progressive encoding, both of which improve compression over WIC's encoding (but at the cost of speed). The enhanced compression is available when using JpegOptimizedEncoderOptions from the plugin package.

PNG

WIC's PNG is, at this moment, faster than the libpng plugin, mostly due to its use of Intel's commercial IPP zlib. Compression may differ slightly because of the different zlib implementations. I haven't profiled extensively.

There are also a couple of small differences in capability between the two codecs. The native plugin supports decoding animated PNG, while WIC supports decoding the weird PNG variant created by the iOS PNG optimizer.

Quality is largely the same since PNG is lossless, but WIC's codec doesn't handle greyscale images with a gAMA tag properly, while the plugin does.

GIF

WIC's GIF is slightly faster than GIFLIB. Compression is a near match between the two. The only capability the native codec has that WIC doesn't is support for ICC profiles, which is not a common thing in GIF.

WebP

WIC's WebP is delivered as a Store app, so it's not available everywhere, and it is less complete than the plugin version (animated support, planar decode, and advanced compression settings). Otherwise, they're both based on libwebp so should have the same quality and performance in the codec itself.

[andreas-eriksson]

Thank you for the very detailed explanation.