WARNING: Windows Live Essentials 2011

Started Oct 3, 2010 | Discussions thread
AxelR Senior Member • Posts: 1,169
Re: WARNING: Windows Live Essentials 2011

Sean Nelson wrote:

AxelR wrote:

Clearly if you subtract the 'after' image from the 'before' image and normalize the result, magnifying any differences a couple of hundred times, you are going to see something as the pixels definitely are slightly different. They could mitigate this by using 100% quality when transcoding in a lossy manner, as to limit any damage done.

IMHO there's no excuse for changing ANY bits in the image in ANY way when you're just changing metadata. It's a sloppy, sloppy thing to do and speaks very poorly of the implementation.

I'm 100% on malch's side here - after hearing this I wouldn't go near this software with a 10 foot pole.

I guess lots of people - including me - will readily side with you, but for lossless medatada insertion to work as it should, there should be a way to deconstruct and reconstruct a file block by block in order to make the necessary room at the front.

For lossless or uncompressed formats a round-trip through RGB (or RGBA) pixels does not impact IQ at all, but with lossy formats you need direct access to the file's content in order to copy the compressed data as an opaque binary block, and the current WIC codec interface does not let you do that.

Just to clarify: Microsoft worked around the limitation of the(ir own) API by implementing a private interface in their JPEG codec that presumably let them read/write the pixel data without decompressing it, and as a result both Windows and WLPG are able to perform lossless metadata updates and rotations on JPEG files when using the stock codec.

The problem starts only when replacing the default codec with a 3rd-party one which cannot possibly implement the internal (and undocumented) interface they use privately. In case you wonder how I know that, I first ran into this issue with my own image viewer's XMP rating function, which supports lossless metadata editing for JPEG since 2008. I observed that my files were recompressed as soon as I replaced the stock codec with my own. Everything was working perfectly (no errors of any kind) but the files clearly were re-compressed. My codec was used perfectly normally to unpack the pixels so it was clear that the lossless behavior had been lost somehow. Some debugging hours later I uncovered the existence of an interface called IMILCJpegDecoderFrame which WIC queries for and which is not documented anywhere. The name is real and comes from Window's public debugging symbols so I'm sure of what I'm saying here. Apparently if the decoder does not implement this interface the WIC framework reverts to decompressing the pixels and simply goes on.

Everything gets back to normal if the 3rd party JPEG codec is uninstalled. Now one may ask why one would replace the default codec? In my case my implementation provides EXIF-based JPEG auto-rotation to Explorer, Photo Gallery, Photo Viewer and Media Center - a feature welcome by many users - but there are other reasons, for example Intel has a JPEG codec for WIC claimed to be up to 6x faster (than their current industry-fastest JPEG library) on multicore CPUs. Sure enough, installing it effectively speeds up JPEG display in Windows built-in viewers, but Explorer and WLPG also lose their lossless metadata editing and rotation abilities.

So once more: out-of-the-box, metadata editing and rotation from Explorer and WLPG are lossless as it should and everything is fine. Installing a 3rd party JPEG codec cause those operations to become lossy, unless the codec in question disables itself at the appropriate moments, which I’m trying to do with some success in my own replacement codec (who's installation and use is entirely optionnal). I don't know if there is a better solution, short of sticking with the stock codec of course.

Post (hide subjects) Posted by
Keyboard shortcuts:
FForum PPrevious NNext WNext unread UUpvote SSubscribe RReply QQuote BBookmark MMy threads
Color scheme? Blue / Yellow