The Flash Player Incubator builds on contain a capability which is the result of some of the Molehill work I have done. When we looked at how to support textures for Molehill I immediately faced the issue of having to deal with inadequate image formats.

Traditional JPEGs are simply not flexible enough. They lack transparency support and suffer from low quality. Most encoders use 4:2:0 chroma sampling and the most commonly used implementation is based on outdated reference source code which does not leverage modern compression techniques. PNGs tend to have their own share of issues, specifically they tend to be rather bad for photographic and noisy content.

JPEG XR to the rescue. JPEG XR is a completely free specification, provided by Microsoft with the Microsoft Open Specification Promise. It has been standardized as ITU T.283 and comes with fairly good reference source code. Why is JPEG XR so cool?

  • It supports lossy compression of alpha channels.
  • It supports true lossless compression when needed.
  • It has better quality than JPEG in most cases.
  • Computationally and complexity wise it is much lighter weight than JPEG-2000.
  • It supports floating point formats.
  • It only supports one color space, the only one which matters on the web: sRGB (in video terms that is BT.709).
  • It supports RGB555 and RGB565 color models which is important for block compressed Molehill textures.
  • It’s completely open as mentioned above.
  • etc.

Particularly the chroma sampling issues with most available JPEG encoders are a pretty big problem for me and certainly for many designers. Let me show what I mean, here is an image compressed with 4:2:0 on the left and one with 4:4:4 on the right, notice the washed out red (Did you know that in Fireworks 4:4:4 chroma sampling kicks in only around 86 in the JPEG compression quality settings?):

So what does that mean for the Flash Player? Though I added JPEG XR primarily for Molehill texture support you can load any JPEG XR image like you load PNG or JPEG files in the Flash Player today (if you mark your SWF as version 13).

IE9 also has native JPEG XR support. Here is a nice comparison of the quality improvements you can get with JPEG XR compared to JPEG.

Bandwidth is still important and reducing the size of assets is particularly key if you do something like games which rely on huge amounts of them. Does that mean that PNGs and JPEGs are obsolete? Not by any means. That’s especially the case for PNG. PNG does extremely well on synthetic/flat content and will beat both JPEG and JPEG XR at any time with that type of content.

Leave a comment


  1. Don’t be fooled by the primitive page appearance.
    The code provided by is NOT outdated,
    the latest update is release 8c of 16-Jan-2011.
    It has many new features, enhanced specification,
    including true lossless support.
    But you have to investigate yourself, not fall for the misleading Microsoft and ISO propaganda
    as you did.

    • “enhanced specification”. Yup, like the arithmetic coding which is incompatible with existing JPEG decoders. That does not really help for interoperability.

      The sad thing is once a standard like JPEG becomes so entrenched into pretty much everything from computers to cameras it becomes very hard to successfully promote extensions. It would probably have been a better approach to package new features under a new brand like JPEG2 or something like that.

      But it looks like you have own own little agenda you are trying to defend, JPEGClub :wink: .

      JPEG XR is not a replacement for JPEG but it is a very nice complement. It gets the job done and it is as open as JPEG. Everything else is political.

      • Hello Tinic,

        yes, arithmetic coding is one of the new features now introduced (with IJG JPEG 7).

        This was already in the original JPEG specification. With “enhanced specification” I mean this one:

        The “SmartScale” part of this document is now realized with IJG JPEG 8. This also brings the true lossless feature.

        For the “political” understanding:
        Original JPEG was first introduced in ITU, then taken over by ISO.
        JPEG 2000 and JPEG XR were first introduced by ISO, then taken over by ITU.
        ISO is by far the more corrupt body, that’s why the “bad” things were introduced there, while the “good” things were introduced by ITU. And that’s why my proposal was submitted to ITU with some support there, but not enough, so I now run my own company for the promotion (UC.AG).

        But I recognize it is hard for you NOT to fall for the huge propaganda – similar to the incorporation of JPEG 2000 in PDF by Adobe. I can assure you that both, JPEG 2000 and JPEG XR, are mistakes and won’t go far.

        Guido Vollbeding
        Organizer Independent JPEG Group

  2. It is not JPEG’s or IJG’s fault if an application
    messes up with the color subsampling setting.
    The option in JPEG and IJG library is there, see

    • I never said it was JPEGs fault. But fact remains and you state that in your article that many encoders get it wrong. Yes, every JPEG encoder ought to have a separate setting for this.

  3. Hi Tinic,

    i spent a lot of time to develope an jpegXR decoder with alchemy. Now, it comes to flash, cool. i think must of the people dont know what we can do with it..

    iam figuring things out for developing an texture streaming library, specially for games.

    for starting i tried to see if flash support jpegXR with alpha channel.

    i can encode a jpegxr with alpha, cause my source was a tiff i used these encoder line (based on the ITU T.283 specs):
    ./encoder -c -q 25 -b all -p t2a.tif out.jxr

    as far as i understand the -p flag is automatically defines alpha encoding from a tiff source.

    i also tried with the -a 2 flag.

    the lastest flashplayer (incubator on osx) shows me the alpha area black.

    for demo i setup a very ugly demo.

    background is jpg and over the jpg i load the xr alpha file.

    the original xr is stored here:

    if you find a minute, maybe you can give me a tip.

    thanks for this feature!!


    • Works fine :-)

      Make sure you publish as SWF13 (Fourth byte in the SWF should be 0x0D).

      Code I used:

      package {

      import flash.display.MovieClip;
      import flash.display.Loader;

      public class LoaderTest extends MovieClip {

      var imageLoader:Loader = new Loader();
      var theURL:String = “alphaTest.jxr”;
      var imageRequest = new URLRequest(theURL);

      public function onComplete(evt:Event) {

      public function LoaderTest() {
      imageLoader.contentLoaderInfo.addEventListener(Event.COMPLETE, onComplete);


    • Yup I see you published your SWF as version 10, fourth byte in your SWF is 0x0A:

      43 57 53 0A

      If you can’t publish to SWF13 open a hex editor and change it manually to 0x0D.

  4. thanks for your fast response..the xr loaded fine….i add in adt the -swf-version=13 (works!!)

    what i want to explain was the alpha channel area.

    this chots can explain it better:
    here you can see how i define some alpha channels in tif. convert the tif to jpeg xr (including the alpha)

    then i load this jpg in my class

    “over” the i1.jpg i loaded the jpeg xr:

    from the load and display side everything works fine in fp11:

    but the defined alpha area is shown in “black” in flash, i try to explain with this shot:


    i upload the tif with the alpha channel here:

    sorry for asking so much questions…you are the only one i can ask right now..


  5. Tinic,

    do you know if there will be a new tag introduced that supports JPEG XR? Something along the lines of DefineBitsJPEGXR maybe?