Coffeehouse Thread

8 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

The current state of Jpeg XR

Back to Forum: Coffeehouse
  • User profile image

    I think in the web today there's a demand for an image format that supports both lossy compression and alpha transparency and one that supports high colour depths. These have pretty obvious benefits in regards to graphically intensive web sites/web apps and games. This is the exact reason that adobe flash player now supports Jpeg-XR. I think there's a big opportunity for Jpeg-XR to be the format to fill this need for web developers. Web-P is being developed by google to support these features too, but at the moment that's a moving standard and is by no means complete. Jpeg-XR has an enormous benefit then by being an established ISO standard for 3 years now I think. So far though however, the only browser that supports Jpeg-XR is IE9. Why is this the case exactly? Mozilla seem pretty interested in the standard but among other things they are mostly put off by the huge amount of work it would take them to write a performant, stable and secure Jpeg-XR decoder from scratch.

    "I'm interested, but there's a lot of work that would need to be done.[...] If Microsoft is looking to help, I think releasing a high quality encoder/decoder under the same license as libjpeg would go along ways to improving adoption." -Jeff Muizelaar, Mozilla

    Microsoft do have an open source reference codec, but it's not performant or secured. Why then should Microsoft not take the lead (supposing they are interested) and release a performant, stable and secure Jpeg-XR codec of their own with a liberal (GPL Compatible) open source licence? If Microsoft is interested in getting the format more broadly adopted, especially in the web, then what better way then to do this? No new code would even need to be written, they could just open source the codec included with WIC.

    My thoughts are that if this format became broadly supported in web browsers it could make a significant improvement to the kinds of things possible in web development. Most people seem to agree the format is the right one for the job, and it seems like it could become broadly adopted if Microsoft made just that much easier for people to implement.

    I'm not sure how interested Microsoft is in promoting Jpeg-XR however. Seems like all the momentum behind it died the day they made the licencing free permanently and killed any means of making any real money off of it. Perhaps I'm wrong though and there's some people left in there who want to see this format adopted in more places. I'd love to hear someone from microsoft's two cents on this and whether or not this is a practical possibility.

  • User profile image
    Blue Ink

    @battlebottle: I believe that codecs shouldn't ship with browsers, especially when these are cross-platform. OS manufacturers are better equipped (and better funded) to provide the best implementation for the platform. I also believe that web content shouldn't be confined to the browser: if I save an image off a web page, I expect it to be visible on my computer as well, at least at a basic level. I know this isn't an explicit requirement anywhere, but it just something I've come to expect.

    So, I think that if Mozilla really wants to support the format, they should start by using the WIC coded on Windows and then wait for the other platforms to provide their best implementations (the MS open source implementation could be used as a stopgap). Unfortunately, Mozilla already had a similar choice with H.264 support, and turned that down, so I don't think it's going to happen.

  • User profile image

    @Blue Ink:

    I'd have to disagree with you on codecs being shipped with browsers. If there's a jpeg decoder for example that's faster, more memory effiecient and at least as stable and secure as the WIC jpeg decoder, then is there any reason at all why the former should not be used instead? I would also expect this exact scenario is the case as although the WIC codecs are not bad, I don't beleive they stand up well against the best open source image codec libraries. Also, although Windows does have WIC, I'm not so sure if mac osx or linux have similar libraries made easily available to third party applications. Even Windows XP doesn't have WIC, one reason why IE9 is not available of XP. Now even if osx, xp and most linux distros did have WIC counterparts, that would mean if a browser chose to use those different libraries on different platforms they'd all have to be individually tested for bugs, and of course if a bug is found internal to the imaging library it can't be fixed and a case specific work around must be worked out instead. It might be easier then just to use a performant open source library accross all platforms which only needs to be tested once. Now if firefox were to only use WIC on windows and nowhere else you then have fragmentation issues. A page that uses jpeg-xr on Windows will not render correctly on mac osx or linux. Browsers like firefox and chrome try to ensure they render identically across all platforms, web development is hard enough having to test a page in many browsers without having to test those same browsers across multiple os's aswell. This is the very reason I gather that firefox declined to support H264 on windows via the native OS codecs.

  • User profile image

    @battlebottle:  What exactly you mean as "Microsoft do have an open source reference codec, but it's not performant or secured"?

    Is there any benchmark, audit available?

    Months ago, I asked about codec recommendation and member of Microsoft team has suggested to use that one - see JPEG XR in native C++

    As far as I understand, current sitaution is this:

    - use the implementation of JPEG XR prepared for the FCD ballot (linked above)

    - use WIC which is Windows only solution.

    The JPEG-XR port of libjpeg discussed in the Mozilla list you linked seems to be no longer maintained. There is even no README available which outlines its status, so I'd not go for that one.

  • User profile image


    "Is there any benchmark, audit available?":

    Some basic ones here:

    "1. Performace. From my initial tests, it looks like the reference JPEG-XR implementation is about 10x slower to decode than libjpeg.
    2. Security. I don't know that the reference implementation has been hardened against malicious inputs and from my quick look it appears that it has not." -Jeff Muizelaar, Mozilla

    As opposed to the FCD ballot Jpeg XR reference software recommended in that linked thread I would recommend the final published version found here:

    I don't beleive I implied that the libjpeg based Jpeg XR codec discussed was being maintained.

  • User profile image

    It will be a long time before this catches on for the web. The web will be the last place to adopt this.

    The first step is for Adobe to adopt the format. It has started to in some products, but is not in the current version of Photoshop. Is it in Photoshop CS6 does anyone know?

    Once this happens, I think it will catch on quickly with photographers. For storing images at high quality (>8bit per pixel mainly, also good compression options).

  • User profile image


    Even if the web is the last place to adopt it I would still like to see an effort sooner than later simply to fill the gap in functionality left by jpeg/png/gif that jpeg xr nicely fills.

    From what I understand, there's relatively low interest to photographers in jpeg-xr at the moment. Camera memory has become so cheap in recent years it's now practical to shoot everything in RAW. Photoshop CS6 does not support JPEG XR. Though I do think Jpeg XR would be useful in this area, I don't think it's something camera manufacturers are rushing to adopt.

  • User profile image

    Not camera manufacturers, but photographers who don't want the large file sizes of 16bpc TIFF files.

    Cameras will not add support before photoshop does. If CS6 does not support JPEG XR, we can forget about the format for another 2 years.

    The web has more fundamental problems than image compression. Many browsers (including IE9, chrome) do not have working color management. I.e. these browsers cannot even display JPEG (or any image or colored object) yet.

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.