JPEG XR Photoshop Plugin and Source Code

Today we are making several JPEG XR announcements:

JPEG XR is an approved ISO/IEC International standard (its official designation is ISO/IEC 29199-2). See more information in the press release from the JPEG Committee. JPEG XR started its life in Microsoft Research. It publicly first appeared as the HD Photo format, 7 years ago in Windows Vista. Microsoft submitted HD Photo to the JPEG committee and it emerged 2 years later as a new standard. Thanks to the excellent work by the committee, the standardization process resulted in several changes to the original specification. This robust peer review has led to a better product for end users (compared with one entity defining a new format). JPEG XR support is included in many Microsoft products, most importantly Windows 7, Windows 8, and IE10.

For web developers, JPEG XR has a large number of interesting features, see the table below. Some of these are big advantages over other image formats like JPEG, PNG, OpenEXR, and TIFF.

Better Compression

On average the file size will be 40% smaller than JPEG for similar quality. In addition the compression artifacts in XR are less objectionable than JPEG so there is often more file size savings available.
Lossless Mode The lossless mode in XR achieves better compression than PNG (especially for natural images).
Alpha Channel XR supports an alpha channel, unlike JPEG. PNG does support alpha, but, unlike PNG, XR has the capability to compress color lossy and alpha losslessly. This capability results in much smaller file sizes.
Extended Bitdepth XR supports 8-, 16-, and 32-bit/channel, this means that it can store either RAW images or HDR images without losing precision. This coupled with sophisticated compression achieves smaller file sizes than other formats like TIFF, RAW, or OpenEXR.
Progressive Decode IE10 leverages the XR progressive download mode.
Advanced Decoding Features
  • XR images can be cropped, rotated, flipped, and resized all in the compressed domain.
  • The tile-based layout of an XR file allows for efficient region-of-interest access.

 

I’ll end with two simple demonstrations of how XR compares with JPEG.

P09

I compressed the picture above using both our Photoshop plugin and Photoshop “Save for Web & Devices …”  In each case I set the quality to a fairly low ‘20’ setting. Note that we have tuned the JPEG XR plugin quality sliders to match Photoshop’s JPEG encoder quality slider. This means that for a given setting you should get a comparable ‘quality’ but the JXR file size will always be smaller. In this case the original 32MB uncompressed image compressed to a 703KB JPEG file and a 453KB JXR file (36% savings).  Zooming in on an area of the ear we also see that the types of compression artifacts present in the JXR are less apparent than the familiar “blocking” artifacts of JPEG (the rightmost slice is the original).

image

For this same image, I plot a sweep of the quality slider from 100 to 0 for both JPEG and JPEG XR. The X axis is PSNR (a measure of quality) and the Y axis is the amount of compression. Several things to point out here – (1) JPEG XR consistently achieves higher compression (smaller files), and (2) notice the extreme right side of the graph; JPEG XR can achieve higher quality than JPEG. In fact, the quality slider represents a continuous scale of lossless compression at ‘100’ to progressively more lossy.

image

This post gives a very quick introduction to JPEG XR. For those who want to learn more, I encourage you to start with the Wikipedia page, and Bill Crow’s blog. Also, please do give us feedback on our new source code and Photoshop plugin releases in the comments below.

-Matt Uyttendaele

About these ads
This entry was posted in Uncategorized. Bookmark the permalink.

37 Responses to JPEG XR Photoshop Plugin and Source Code

  1. Xyz says:

    Are there any visual quality differences versus the ‘reference’ code? ( http://www.itu.int/rec/T-REC-T.835 )

  2. hdview says:

    @Xyz
    Decoders need to be bit for bit exact, so the decoder results are identical to the reference implementation.

    JPEGXR has many encoding parameters, these are all available for advanced users in both reference and this implementation. This implementation, unlike the reference, has a good ‘simple mode’ that allows users to set a quality and the sw picks a reasonable set of encoding parameters.

    Also, the reference is not suitable for shipping in a product. It is slow, memory in-efficient, and not robust to error conditions – but it is easier to read the code (as a ‘reference’ should be).

  3. Chrysler says:

    Excellent, although I have to say this comes pretty (too?) late. Anyway, let’s hope this gives the codec a second chance for a wider adoption. I’ll see if I can update my GIMP plugin to make use of this and remove the dependency on WIC so it works on non-Windows platforms, too.

  4. hdview says:

    @Chrysler I agree that this has taken too long. Thanks for adding support to GIMP. Please let us know if you have any problems. Also when the GIMP plugin is ready, I’d be happy to announce it here.

  5. battlebottle says:

    Great work guys :).

    I know Jpeg-XR has never been a roaringly popular format, but as far as I can see it fills certain demands that no other image format fills to date. namely:
    1) Fully free and open
    2) Fully standardised
    3) Can encode pretty much any pixel format you can think of lossy and losslessly with a reletively simple algorithm.
    Jpeg and PNG of course fill the first two points and many others can fill the third, but I don’t know of any that can fill all three. Although I don’t know would the format ever get widespread adoption on the web or in photography, I can definitely see a lot samller areas were it would the perfect format.

    I think a big barrier to it’s adoption the past few years has been the lack of a good open source library, with the reference implementation being neither performant nor GPL/MIT compatible. It’s great to see such a library finally appear :).

    I think an area MS could try harder to encourage adoption would be to do more to clarify the patent situation. Many open source people I’ve talked to about the format in the past seem hesitant to use it because it’s patented and many are unaware or untrusting about the fact that patent immunity is granted to anyone using the patent the implement the Jpeg-XR spec for any purpose. If the situation was made clearer to people I think that would help it’s adoption a lot in open source projects.

    • hdview says:

      @battlebottle Thanks for your feedback. We were very happy to finally release this. I agree with your assessment – JXR is the most versatile image format that I know of.

      You are probably aware that Microsoft has opened up the patents to this technology under the “community promise” terms: http://www.microsoft.com/openspecifications/en/us/programs/community-promise/default.aspx I’m curious what beyond this description would you like to see made clearer?

      • battlebottle says:

        I’m not sure exactly what I would recommend. But as with any legal jargon the “community promise” takes quite a while to read and understand clearly. It takes a while for a lone programmer to read and even then I think it’s difficult for someone to feel 100% certain they are doing something that leaves them open to being sued someday.

        For one the FSF don’t appear to trust the promise: http://www.fsf.org/news/2009-07-mscp-mono

        The impression I get from some people is they worry how they can be sure that Microsoft won’t find some legal loophole in the community promise that they can use 20 years from now to sue everyone after Jpeg-XR gets wide adoption. That may sound paranoid but I think the open source community by enlarge have a large and often justified fear of Microsoft’s legal department. Even word “promise” in the name “community promise” I find creates some uncertainty in people if the “promise” is truly legally binding.

        I think something that would help, ideally, would be a short, clear, legally binding statement that made it abundantly clear to anybody that implementing the complete jpeg-xr spec for any reason by any means would be completely immune to any patent infringement by Microsoft. I think any step like this big or small would help developers feel more “safe” when thinking about implementing a Microsoft standard themselves, and that includes other things like C# and .Net.

        That’s my two cents anyways.

  6. Ted says:

    I just downloaded and tried the plug-in, intending to compare it with Photoshop’s own JPEG 2000 plug-in (another proposed replacement for “legacy” JPEG that users have largely ignored). Using the 64-bit version in Photoshop CS5, I saved a 16-bit image with an alpha channel in lossless mode. When I opened the saved file, only the part of the image corresponding to the selection I had saved in the alpha channel was visible. Very strange. I saved another 16-bit image without an alpha channel. It opened correctly.

    The list of advantages in this blog post states that “XR supports an alpha channel.” Is that feature perhaps missing from the plug-in?

    As for the comparison with JPEG 2000, the XR plug-in is MUCH faster when reading and writing. The file size is very slightly larger than the JPEG 2000 version, but they’re pretty similar. Unfortunately, I mainly use JPEG 2000 to archive “working” files that usually contain alpha channels. If the plug-in doesn’t support alpha channels (by design or otherwise), it’s useless to me.

    • hdview says:

      Hi Ted,
      Alpha is supported. It is possible that there is a bug for 16bit images. I know that this doesn’t address your scenario, but could you try converting to an 8 bit image and see if the alpha is correct maintained in that case?

      • Ted says:

        I get the same result with 8 bits. Also, in both cases the image opens as “Layer 0″ rather than “Background” (an XR file without an alpha channel opens correctly as “Background”). I also forgot to mention that I’m using Windows 7.

      • hdview says:

        Hi Ted,
        I’m trying to repro the alpha channel bug. When I load a .png with alpha, it comes in as “layer 0″. Then I save it out lossless (or just alpha lossless; not sure which you meant) to a .jxr, When I read it in again it looks OK and is “layer 0″, as was the .png. So…can you point me at an image that triggers this? Or walk me through what you do besides “save” and “load”?
        Thanks!
        BTW I’m on Photoshop CS4 both x86 and x64 if that makes a difference

      • Ted says:

        I didn’t do anything other than “save” and “load.” I opened a TIFF file containing an alpha channel (originally a saved selection), and immediately saved it as JPEG XR. When the plug-in displayed its dialogue, I did nothing but tick the “lossless” box and hit OK. Then I closed the file in Photoshop, and reopened it. Got “Layer 0″ that contained only the part of the image corresponding to the selection I had saved as an alpha channel– but no alpha channel.

        The problem seems to be in saving the file. I tried opening the saved file in Windows Photo Viewer, and got the same partial image as in Photoshop. I also tried saving a different file that has two alpha channels. I got a warning message that the plug-in discards all but a single alpha channel. (So apparently the plug-in is designed to work with only one alpha channel. That makes it less than useful even if it worked.) That saved file also opened as a partial image in Photoshop and in Windows Photo Viewer.

        I’m using Photoshop CS5, but only the x64 version.

      • hdview says:

        Hi Ted,
        JPEG XR, like PNG, supports an alpha channel but not Photoshop “layers”. So if you save your TIFF out as either a .jxr or .png you will see the “File must be saved as a copy with this selection” warning. When you load either back in you will get the transparency matte but not a separate Alpha channel.
        As for the “partial image” problem could you point us to the file that causes the problem, and/or a screenshot of what it looks like?
        Thanks!

      • Ted says:

        This is the “original” PSD file containing one alpha channel (and no layers): http://www.tedsimages.com/test/Test_TRM.psd
        This is the JXR file I saved immediately after opening the PSD file. All I did was tick the “Lossless” box in the plug-in dialogue: http://www.tedsimages.com/test/Test_TRM.jxr
        This is a screen shot showing what I got when I opened the JXR file in Photoshop: http://www.tedsimages.com/test/Test_TRM_Screenshot.jpg
        This image file is reduced in size and to 8 bits to make the download manageable. But the result is the same as the full-sized 16 bit version.

      • hdview says:

        Hi Ted,
        Yes, currently alpha is always interpreted as transparency by the .jxr plugin. So you can either have your image (by unchecking AlphaChannels in the SaveAs… dialog), or your transparency (by checking AlphaChannels), but not both. We’ll fix that in the plugin and get it back out ASAP.
        –Howard

      • Ted says:

        Glad to help you squash bugs! Do you plan to support multiple alpha channels at some point?

  7. myutwo33 says:

    I was using the Photoshop plugin with Photoshop CS6 64-bit today and I’ve noticed when you save an image with an alpha channel, there is a grayness applied to any semi-transparent pixels. This shows up when I open it in Photoshop again and when viewed in Windows Photo Viewer, suggesting the problem occurs when the file is being saved. To me this suggests an error with pre-multiplied alpha and how it’s applied or not applied. I’m not sure where else to file bugs on this, so I’ll just leave this here for now.

    • hdview says:

      I think that’s expected. If you save your image out of Photoshop as a .png, and then open it in Photoshop again or view it in Windows Photo Viewer, you should see the same “grayness” right? At least I do when I modify the Opacity in Photoshop and save it out as either a .png or .jxr. Let me know if you’re doing something different, or point me to an image that demonstrates it, thanks.

      • myutwo33 says:

        weird. I now cannot reproduce this problem. Maybe I was doing something odd before but when I try to create images now with opacity and save them as .jxr and reopen them they have no greyness. Maybe I saved the .jxr in lossy mode or something silly like that before.

  8. Pingback: Has anyone worked with JPEG XR before | Jenn Grover

  9. Pingback: JPEG XR deployment to research.microsoft.com | frank martinez

  10. Pingback: JPEGXR updates | HD View

  11. Rezt says:

    It’s broken on Photoshop CC

  12. Test says:

    Not work on Adobe Photoshop CS

  13. Old issue says:

    Still broken on Photoshop CC

  14. CSMR says:

    I was waiting for a JPEG XR plugin for Photoshop but missed this news. I look forward to trying it. It looks like the best format for >8bpc images at reasonable sizes. This will save me a lot of disk space compared to TIFF files!

    • hdview says:

      Thanks for trying this out. I agree, JPEGXR is a great format for >8bpc.

    • CSMR says:

      Preliminary conclusions from testing with a single image, 13MPix 16bpc, and adjusting the quality slider. (Photograph of trees and clouds, processed from RAW image.)

      JXR lossless
      File size 40MB while TIFF with LZW compression is 84MB. That’s great.

      JXR quality .50 to .99:
      File sizes vary from 7.8MB to 36MB.
      I could not distinguish these from the original in any areas of the image, even when zoomed in. By contrast I could tell the difference from a maximum quality 6.7MB Photoshop jpeg (8bpc).
      So that’s good, although I’d like to test further with difficult images and amplifying dark areas to see how these files stand up to further edits.

      JXR quality .01 to .49.
      Here the quality slider resulted in bad settings. First, resulting images were larger than quality .50, with file sizes of at least 10MB. Second they were easily distinguishable in areas from the original in areas of contrasting colors. This seems to be because there is chroma subsampling which kicks in at quality 8bit images, and displaying a file size before saving.

    • CSMR says:

      Preliminary conclusions from testing with a single image, 13MPix 16bpc, and adjusting the quality slider. (From RAW photograph.)

      JXR lossless
      File size 40MB while TIFF with LZW compression is 84MB. That’s great.

      JXR quality .50 to .99:
      File sizes vary from 7.8MB to 36MB.
      I could not distinguish these from the original in any areas of the image, even when zoomed in. By contrast I could tell the difference from a maximum quality 6.7MB Photoshop jpeg (8bpc).
      So that’s good, although I’d like to test further with difficult images and amplifying dark areas to see how these files stand up to further edits.

      JXR quality .01 to .49.
      Here the quality slider resulted in bad settings. First, resulting images were larger than quality .50, with file sizes of at least 10MB. Second they were easily distinguishable in areas from the original in areas of contrasting colors. This seems to be because there is chroma subsampling which kicks in at quality 8bit images, and display a file size before saving.
      (Reposting as previous comment had missing text).

    • CSMR says:

      Preliminary conclusions from testing with a 13MPix 16bpc image (from RAW photo).

      JXR lossless: 40MB file while TIFF with LZW is 84MB. Good!

      JXR quality .50 to .99: File sizes from 7.8MB to 36MB. Indistinguishable from the original even with pixel-peeping. A maximum quality 6.7MB Photoshop jpeg (8bpc) was distinguishable. Good!

      JXR quality .01 to .49: Here the quality slider chose bad settings, namely chroma subsampling. Resulting files were larger than at .50 and with inaccurate color in areas of contrast.

      Overall JXR seems to work very well for 16bpc images at quality at least .50, including lossless.

      It would be nice to have the Photoshop plugin remember previous settings, disable chroma subsampling for >8bit images, and display a file size before saving.
      (Previous comment too long, reposting).

      • hdview says:

        The default quality slider makes a lot of decisions automatically (for example you discovered the chroma sub sampling at < 0.5). For the most part we tried to match what Photoshop does for JPEG – Photoshop also starts reducing chroma resolution below 0.5.

        Are you on Mac or Windows? On Windows you can drop into advanced settings and tweak the default quality behavior.

  15. Chrysler says:

    Any timeframe on when we can expect JPEG XR support in Firefox? Any other JPEG XR news coming?

  16. Sara says:

    Hi, are there any plans to support Photoshop CC? Thanks.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s