I wrote a JPEG XR codec for one PowerPoint feature

If you apply an artistic effect to a picture in PowerPoint (blur, pencil sketch, a colour correction), PowerPoint does two things. It saves the edited picture, which is what you see. And it quietly keeps the original next to it, so you can undo the effect later.

That original is saved as hdphoto1.wdp. HD Photo, also known as JPEG XR. A format Microsoft designed in the late 2000s that almost nothing else supports. Browsers don't. Most image tools don't.

For viewing a deck you mostly don't need it. But I need it for two things: making big decks smaller by re-compressing their pictures, and keeping a deck intact when it's edited and saved again. If you can't read or write the original, you either throw it away or leave it untouched and bloated.

Writing it from the reference

Microsoft published its reference implementation, jxrlib, under the BSD licence. So the job is clear: port it, step by step, to plain JavaScript. No WebAssembly, running in a worker so the page doesn't freeze.

I only did the parts real decks actually use: 8-bit colour with and without transparency, the main colour layout, tiles, and the overlap filters. Anything else gets refused cleanly instead of decoded wrong.

Checking it like a codec

A codec is either exact or broken, so I checked it against Microsoft's own command-line tools:

• 61 out of 61 real pictures from real decks decode pixel for pixel identical to Microsoft's decoder.
• 129 out of 129 encodes (43 pictures at 3 quality levels) produce byte for byte the same file as Microsoft's encoder.

129 / 129

Byte for byte is a much stronger test than "looks the same". It means every rounding step, every bit of entropy coding, every quirk matches.

Is it worth it?

For one feature in one program, probably not, on its own. But these things add up. Every format I can actually read and write is one less place where a file goes in and comes out different. That's the whole point.