JPEG XR

~ the obit ~

Microsoft showed the format at WinHEC in May 2006 under the name Windows Media Photo, renamed it HD Photo that November, and spent the next three years turning it into a standard with somebody else's name on it. It was a good codec. It handled lossy and lossless work in one design, carried high dynamic range at a time when JPEG could not, and decoded with integer arithmetic so that a cheap camera chip could run it. Against baseline JPEG it was worth roughly a halving of file size at the same quality. The extensions were .wdp, then .hdp, then .jxr, one per rebrand.

The standardization worked exactly as intended. In July 2007 the Joint Photographic Experts Group announced it was considering HD Photo for a JPEG standard under the name JPEG XR, for extended range. On 16 March 2009 it was approved as ITU-T Recommendation T.832, and on 19 June 2009 it passed the ISO final ballot as ISO/IEC 29199-2. Microsoft put the patents under its Open Specification Promise, then under the broader Community Promise in August 2010, and in April 2013 released jxrlib under a BSD license so that GPL software could link against it without needing a lawyer. Every objection a rival vendor could reasonably raise had been answered in advance.

None of the rivals shipped a decoder anyway. Mozilla at least logged the request, as bug 500500, and left it open until the question stopped mattering. The only engines that read a .jxr on the open web were Internet Explorer 9 through 11 and the EdgeHTML versions of Edge, from 12 to 18. When Microsoft shipped the Chromium rebuild of Edge on 15 January 2020, the new browser inherited Chromium's decoders, and Chromium had never had one.

~ the rap sheet ~

~ the standards tour ~

The strange part is how completely the paperwork succeeded. JPEG XR has an ITU recommendation and an ISO standard and both are still maintained. The ITU text was revised in June 2019 and ISO issued a 2020 edition, years after the last browser that implemented it had already been replaced.

I have never knowingly opened one, and the reason has nothing to do with being in Turkey, because nothing about JPEG XR was regional. The only way a .wdp reached you was if somebody on Windows had deliberately exported one, and the people with Windows photo pipelines had little reason to when whoever received it could not open it. In fourteen years I have seen the extension in a file dialog's format dropdown and never once in an actual file.

~ mozilla bug 500500 ~

The request to add JPEG XR to Firefox was filed in 2009 and titled plainly: add support for JPEG-XR/HD Photo. It stayed open for years while people worked through the usual circle, that nobody uses a format because no browser supports it and no browser supports a format because nobody uses it. Microsoft had tried to break that circle with the patent promise and the open source library, and the circle held anyway. The bug is the clearest artifact of the failure, because it shows the format did not lose a technical argument. It lost a waiting game.

~ what is still alive ~

The decoder still exists everywhere except in a browser. Windows reads JPEG XR through its imaging stack, and so do Affinity's applications and ImageMagick. The Nvidia app writes HDR screenshots in it, which is probably the largest volume of JPEG XR being produced anywhere today. Anyone who wants a decoder can still clone jxrlib and build one this afternoon.

What it lost was the only thing a web image format can have, which is a browser willing to render it without being asked twice. JPEG XL, confusingly similar in name and unrelated in design, has spent the 2020s losing the same fight with Chrome in public.

@}-->--

              )
             (_)
            .-'-.
            |   |
            |   |
            |   |
            |   |
          __|   |__   .-.
       .-'  |   |  `-:   :
      :     `---'     :-'
       `-._       _.-'
           '""""""

« previous  ·  random  ·  next »