Using WEBP/JPEG 2000/JPEG-XR/APNG Now With Picturefill and Modernizr

January 14th, 2015 by zoltan · 11 Comments

Some of this demos require a browser that supports WEBP, JPEG 2000 or JPEG-XR in order to show the differences between these file formats and JPEG and PNG. At the time this blog post was written (Jan 2015) none of these formats are supported by Firefox. However, in the spirit of progressive enhancement, all the code samples have fallbacks to JPEG and PNG. This post also describes how to use mozjpeg to improve the appearance of JPEG images.

Drag the ball around or open demo in a new window

The demo on the left (which uses Claudia Romano’s amazing Image Comparison Slider) contains two alpha channeled images of dice placed on top of a multicolor background image. If you are looking at it in a browser that supports alternate image formats (i.e. IE9+, Chrome 9+ and modern versions of Safari and Opera 11+) you’ll see that the image on the left hand side is smaller byte-wise than the image on the right. This is because the left-hand image is using an image format that supports alpha channeling and lossy compression at the same time. Use the slider to compare the two images and you’ll see the visual differences between them are negligible. This demo is just one example of how you can use the HTML5 <picture> element to detect what kind of alternate image format (if any) your browser supports and serve the one that uses up the least amount of bandwidth. You’ll also notice that if you resize the iframe that, as the demo’s viewport grows, the browser will load larger versions of the image, which is another great feature of the <picture> element.

Although Blink based browsers like Chrome and Opera support <picture> natively, other browsers currently don’t. The excellent picturefill polyfill had up until recently only supported GIF, PNG, JPEG, WEBP and SVG, so I added JPEG-2000, JPEG-XR and APNG to the mix so that developers could take advantage of these alternate image formats today (thanks to the picturefill team for accepting my pull request!) This blog post will explain how to use picturefill or modernizr to use these formats, why you would want to use these image formats in your web projects, and what tools you can use to generate them.

More Image Formats? Why Should I Bother?

If you have been doing web development for a while, you have come across a few problems with the traditional image formats. Let’s go over them here and see how the new image formats address them:

Reducing Blocky Artifacts in Highly Compressed Images

JPEGs images have a lot of unacceptable blocky artifacting the more you compress the file, due to the limitations of the way the JPEG format compresses the images. WEBP, JPEG-2000 and JPEG-XR use different compression algorithms that (in general) look better the more the images are compressed. To illustrate this, move the slider on CN Tower demo below:

Drag the ball around or open demo in a new window

Here are some browser screenshots that to show the difference between the JPEG, JPEG 2000, JPEG-XR and WEBP:

JPEG (Firefox)
JPEG 2000
cn-tower-jpg cn-tower-jp2 cn-tower-jxr cn-tower-webp

(Note that since the HTML <picture> element supports different renditions of the image at different breakpoints, I created three different renditions for each of the file formats. You can open the demo in a new window in a desktop browser and resize the browser window to see them clearly, or just simply resize the above iframe)

If you are using Chrome, Safari, Opera or Internet Explorer 9+, you will see JPEG artifacts on the right-hand side of the demo (especially in the clouds), while the left hand side doesn’t have them. For this demo, I compressed the CN Tower JPEG using ImageMagick with a quality value of 20% and then compressed WEBP, JPEG-2000 and JPEG-XR images to the same file size as the JPEG image (or lower). If you resize the iframe (or open the demo in a new window and resize the browser window) you will note that there are different image renditions at different breakpoints, and that this artifacting appears in all of the JPEG renditions.

Unfortunately, Firefox doesn’t support any of the alternate image formats at the moment as have opted, in the short term, to create a more optimized JPEG compression library, mozjpeg (in the long term, they are apparently looking into supporting Daala but this has not been implemented at the time of I am writing this). To see how well mozjpeg works, I downloaded a precompiled binary of mozjpeg for my Mac (since I had a huge amount of trouble compiling it from the source) and although the results are better, there is still a little bit of artifacting that remains in the JPEG renditions:

JPEG (Firefox)
JPEG 2000
cn-tower-jpg cn-tower-jp2 cn-tower-jxr cn-tower-webp

Even though some artifacting remains, mozjpeg is pretty good, and the Mozilla team is still updating mozjpeg to see how they can further improve the look of JPEGs images. JPEG files created with mozjpeg can make a great fallback for WEBP/JPEG-2000/JPEG-XR.

So, is WEBP, JPEG 2000 or JPEG-XR the better lossy image compression format? The short answer is “it depends”. I find that each one compresses certain images better than others. Also, while these image formats tend to reduce the artifacting at lower compression ratios, JPEGs tend to keep more of the detail (although I believe that this would not be noticed by the casual user). In any event, the image compression wars have just started, and it will be interesting to see which on of these formats (if any) will come out on top.

To get an idea how some of these formats compress compared to each other, here are a few more examples to take a look at:

Reducing the File Size of Alpha Channeled Images

If your web page needs a lot large alpha-channeled images (i.e. image with a semi-transparent section), using PNGs will bloat the page due to the PNGs use of lossless compression. However, if you are using Chrome, Opera, IE9+ or Safari to look at the demo below, you will see that alternate formats can reduce this bloat:

Let’s compare the file sizes of the alternate image compared to the PNG original:

320×240 2060 22618 55162 11210
600×450 13464 48476 143355 26562
1024×768 19613 97979 333557 57388

As you can see, the numbers for JPEG-2000 are especially impressive. However, the file sizes of the alternate images will vary depending on the characteristics of the original image. Up until now, quantizing a PNG (using programs like pngquant) was the only way to get a smaller alpha channeled image from an original PNG (Pornel mentions it in his comment below). While alternative image formats may give better results, sometimes they don’t. Let’s take a look at this example of an alpha channeled image on top of an animated background:

If you look at this Saturn demo in Safari, you will see the JPEG 2000 is 20% the size of the quantized PNG, with little noticeable loss of detail. The WEBP and JPEG-XR versions are okay, but you can see they are “blurrier” than the PNG (and the WEBP and JPEG-XR versions are only around 70-80% of the original). This is not always the case — sometimes WEBP is better, sometimes JPEG-XR is better, sometimes a quantized PNG is better.

Producing Truecolor Animations

GIF animations only support 256 colors per frame, and can look blocky if they have a transparent background. However, WEBP and APNG (supported by Firefox and Safari) support full truecolor animations with alpha channels. For browsers that don’t support WEBP or APNG, you can use JPEG 2000 and JPEG XR files with CSS Animations (using the step property) to implement it for those browsers (thanks to Treehouse’s Guil Hernandez’s excellent tutorial on how to do this). Compare the animated GIF with the truecolor animation below and you’ll see the difference:

Drag the balls around or open demo in a new window

(Note: if you are using IE9, you’ll only see the animated GIF, since IE9 doesn’t support CSS3 Animations).

Let’s do another file size comparison:

Original APNG WEBP JPEG-2000 JPEG-XR Quantized APNG
65993 18396 25036 29534 39874

As you can see, WEBP, JPEG 2000 and JPEG-XR compress extremely well compared to the original animated PNG (a 27% to 44% savings in bandwidth!). Note, though, the quantized APNG: it is roughly 60% smaller than the original. Quantizing APNG’s can produce animations that are smaller in some cases, and I will discuss how to do this later.

Cool! How Can I Use Alternate Image Formats Today In All Browsers?

The Wrong Way

You can use a regular image tag to place any of these images into your pages just like any other page:

<img src="myimage.webp" />

The problem is this method is that support for each of these image formats is not universal in all browsers, so although embedding a WEBP using the <img> tag will work in Chrome and Opera, it won’t work in the other browsers. Here’s a table that illustrates browser support:

Internet Explorer 8+

So … how do we do this in a progressive-enhancement-like way?

Use <picture> For Still Images

In order to serve the right still (i.e. non-animated) image to the right browsers, developers should use the <picture> element. If you are familiar with <video> tag, the syntax is quite similar: it is contains a list of <source> elements that say which urls contain content of a specific MIME type:

  <source srcset='dice.jxr' type='image/'>
  <source srcset='dice.jp2' type='image/jp2'>
  <source srcset='dice.webp' type='image/webp'>
  <img srcset='dice-quant.png' alt='dice'>

(Side note: notice JPEG-XR’s unusual MIME type (image/ This is because JPEG-XR was originally a proprietary Microsoft image format called Windows Media Photo or HD Photo).

As I mentioned earlier, Chrome and Opera are the only browsers that currently support the <picture> element natively. Fortunately, the picturefill polyfill adds support to the browsers that need it: just download the script from the official GitHub site and put this one script tag into the <head>:

<script async=true src=/path/to/js/picturefill.js></script>

Picturefill out of the box supports WEBP and SVG. If you want to add support for any of the other file formats, you must do one of the following:

  1. Add support for the other formats by adding the supplementary scripts inside the src/includes directory of the git repo. They are conveniently called jxr.js, jp2.js and apng.js. If you wanted to add support for all three, you would put this inside the <head>, right after picturefill’s <script> tag:
    <script async=true src=/path/to/picturefill.js></script>
    <script async=true src=/path/to/jxr.js></script>
    <script async=true src=/path/to/jp2.js></script>
    <script async=true src=/path/to/apng.js></script>
  2. Alternatively, if you are familar with grunt, you could add support by running the grunt inside the picturefill git repo. For example, to support all these formats, build picturefill with this grunt task:
    grunt support-types:jxr:jp2:apng

    This will create a copy of picturefill.js in the git repo’s dist directory (as well as a minified version, picturefill.min.js).

Two important things to to keep in mind:

  1. If you want to ensure picturefill works correctly in IE9, you must put in some conditional comments inside your <picture> for it to work correctly:
      <!--[if IE 9]><video style='display: none;'><![endif]-->
      <source srcset='dice.jxr' type='image/'>
      <source srcset='dice.jp2' type='image/jp2'>
      <source srcset='dice.webp' type='image/webp'>
      <!--[if IE 9]></video><![endif]-->
      <img srcset='dice-quant.png' alt='dice'>

    This is due to an odd quirk in IE9 where it won’t recognize <source> unless wrapped in a <video> tag.

  2. If the images don’t show up correctly, make sure that all the mime types in the <source> elements above are set on your web server. I have only had this issue on one of the servers I have encountered, but it’s something to keep in mind (thanks to Cory Dowd for reminding me about this).

Download the latest version of Picturefill from GitHub

Use Modernizr For Animated Images

As I mentioned before, the WEBP and APNG file formats support animations out of the box. In order to give IE10+ animated goodness, I used CSS step animations to do the animation using a sprite sheet. Since Modernizr currently doesn’t detect JPEG 2000, I also included a small Javascript snippet to add JPEG 2000 support for it based on some code from Andreyka Lechev’s imgsupport.js script (I will send a merge request to the modernizr team in order to add JPEG-2000 support to it soon). For reference here is a link to the custom Modernizr script and the JPEG 2000 detection script. Here is the spritesheet I used to generate the CSS animation in the above demo:

I then converted this file to JPEG 2000 and JPEG-XR format. I then created a div with a class (in this case, ‘b’) …

<div class='b'>

… and then used the following CSS recipe to use CSS animations on only the JPEG-2000/JPEG-XR browsers:

 * The animated image in this case is 100x100, so make 
 * the container that size
.b {
  width: 100px;
  height: 100px;

/* WEBP supports animations .. no need for CSS */
html.webp .b {
  background: url('./b.webp');

/* APNG also supports animations ... no need for CSS */
html.apng .b {
  background: url('./b.png');

 * If the browser doesn't support APNG 
 * *but* supports CSS Animations, 
 * use the PNG version of the sprite and animate it using 
 * the "bplay" animation (coded at the bottom of the 
 * stylesheet).  The fallback for browsers that support
 * animations is the PNG spritesheet ... the JPEG-2000 and
 * JPEG-XR spritesheets will be defined in the CSS rules
 * that follow.
 */ .b {
    background: url('./b-stitched.png') left center;

     * the animation takes 1 second to play, there are 
     * 20 frames in the animation, and we loop the 
     * animation forever
    animation: bplay 1000ms steps(20) infinite;
    -webkit-animation: bplay 1000ms steps(20) infinite;

 * If the browser supports JPEGXR (IE10), then use the JXR 
 * version instead.  Note that this will *not* be used by
 * IE9 since it doesn't support CSS animations.
 */ .b {
    background: url('./b-stitched.jxr') left center;

 * Likewise, if the browser supports JPEG 2000, use
 * the .jp2 version of the sprite.
 */ .b {
    background: url('./b-stitched.jp2') left center;

 * For other browsers that don't support CSS animations
 * at all, we fallback to the animated GIF.
 */ .b {
    background: url('./b.gif') left center;

 * Here we describe the CSS animation itself. Note that
 * the background position is set to the negative value 
 * of the width of the sprite sheet
@keyframes bplay {
  100% { background-position: -2000px; }

/* Webkit variant for older WebKit browsers */
@-webkit-keyframes bplay {
  100% { background-position: -2000px; }

How to create WEBP/JPEG-XR and JPEG 2000 images

There are a few Photoshop and GIMP plugins you can use today to create these images, as well as a few command line tools. Here is a great list to get you started:

Command Line cwebp by the Google WebP Team JxrEncApp (part of jxrlib by Microsoft Research. You have to compile yourself — I have done so successfully on a Mac and Windows (using Cygwin) with no problems. You can also use nconvert, but it doesn’t compress as well as JxrEncApp in my opinion. kdu_compress by Kakadu Software (payware, free for non-commercial use) and OpenJPEG (open source, but I was unsuccessful using it for alpha channeled images) apngasm by Max Stepin. I also used apngdis to disassemble the frames of existing APNG files and pngquant to quantize these frames to make them smaller before assembling them back into a smaller APNG file. I finally used apng2gif to create a GIF fallback for older web browsers.
Photoshop Plug-ins WebP Format by Toby Thain JPEG XR File Format Plug-in for Photoshop by Microsoft Research j2k by fnord software. (Note that under OSX, you can also export JPEG-2000 images using the built in Preview tool). None yet, but a fellow named Rei Kagetsuki has promised that one will be available soon
GIMP Plug-ins GIMP Extensions (Windows only) JPEG XR plugin by Chrysler jp2/denoise/ihalf by Akkana Peck APNG Plug-In by daisuke

Note that for all the demos, I used the command line tools listed above as well as ImageMagick and mozjpeg for the JPEG images — I have not investigated the GIMP or Photoshop plugins yet so your milage may vary on those. To simplify things, I created a set of BASH shell script (which I call the HTML5 Image Converter), that uses the command line tools listed above to create all of the files quickly from a PNG source. One you install the above command line tools and the shell script on your system, you can do the conversion magic on still (non-animated) image using a command like this: --webp-quals=19.5 --jxr-quals=30 --jpg-quals=40 \
  --jp2-rates=0.2/0.4/0.2 --jpg-quals=40 --has-alpha image.png


  • --webp-quals is the compression quality of the WEBP image (1 – most compressed, 100 – most compressed). Default is 85.
  • --jxr-quals is the compression quality of the JXR image (again, 1 – most compressed, 100 – most compressed). Default is 85.
  • --jpg-quals is the compression quality of the JPG image (again, 1 – most compressed, 100 – most compressed). Default is 85.
  • --jp2-rates is the compression rate of the JP2 image. Default is 1.0. More information about this can be found on this page by the University of Michigan.
  • --has-alpha is optional and only be used if the image has an alpha channel.
  • --use-mozjpeg is optional if you want to create JPEG fallbacks compressed with mozjpeg instead of ImageMagick (it will give warnings if mozjpeg is not installed).
  • --jxr-ie9-fix fixes a sometimes unnoticable bug in IE9 where JPEG-XR image will have a small semi-opaque gray border around it.
  • --jxr-nconvert will convert JPEG-XR images with nconvert instead of JxrEncApp.

This command creates images in all the formats listed above, as well as giving you a handy HTML page that shows how the image looks compared to the JPEG (just like the examples in this blog post).

You can also create different renditions of the image you want using the <picture> element’s support of srcset using the --sizes parameter. Here is an example where we will create three renditions, one for the image scaled down to a width of 320 pixels, another with a width of 600 pixels, and a final one of 1024 pixels: --sizes=320/600/1024  --webp-quals=50 --jpg-quals=70 \
  --jp2-rates=0.1/0.1/0.4 --jxr-quals=15 image.png

The WEBP, JPG and JXR compression quality of the above example are 50%, 70% and 15% respectively — you have a different quality for each rendition if you like by separating this with slashes (like the --jp2-rates does).

Note that the HTML5 Image Converter will also embed what command-line switches that were used to generate the images inside a comment in the generated HTML file. This is useful if you want to try different values later or if you want to replicate my results. Hopefully this will assist others if they want to do more research on these image formats.

How About Creating Animated Images

Inside the HTML5 Image Converter’s git repository, there is another script (creatively called “The HTML5 Animated Image Converter”) that converts an APNG file to animated WEBP. It also makes image sprites using JPEG 2000, JPEG-XR and non-animated PNG as well as a CSS stylesheet that uses the CSS3 Animation trick above for browsers that support those formats and CSS3 animations. It finally creates an animated GIF using apng2gif as a fallback for browsers that don’t do CSS animations (e.g. IE9). In order to create the animated ball demo above, I used the following command:

html5AnimatedImageConverter --input-apng --output=b --ms=50 --jxr-quality=80 --jp2-rate=1.0 --webp-quality=50 --apng-quant ballanim.png


  • --input-apng denotes that the input is an animated PNG (note: using still images will be supported in a later release).
  • --output=b will create outfile files with the filenames beginning with “b.” (i.e. b.png, b.webp, b-stitched.jxr, b-stitched.jp2, b-stitched.png, b.gif, b.css and b.html)
  • --ms=50 tells the generator to create animations with each frame appearing for 50 milliseconds.
  • --jxr-quality, --webp-quality and --jp2-rate attributes set to the quality/rate values in the same way that the HTML5 Image Animator does.

Download the HTML5 Image Converter for GitHub

When I created this shell script, I found a few gotchas about using these command line tools:


JxrEncApp is quite difficult to understand to use at first, since it lacks documentation and it will fail silently sometimes without saying why (Microsoft: if you are reading this, please take positive steps to fix JxrEncApp so web developers can support this promising format!) (Update: Gary Sullivan from Microsoft was kind enough to speak to the issues I have discussed). However, I was fortunate that Christoph Hausner, who has been playing around with JPEG-XR files for a while now, was kind enough to give me quite a few pointers. Here is a summary of them:

  1. When you are converting an image using JxrEncApp, it is best doing so using an uncompressed TIFF. If you have a PNG, JPEG or other file that you need converted, you can do so using the following ImageMagick command:

    convert img.png -compress none img.tif

  2. IE9 has a known issue where it will render a light gray border around some JPEG-XR images (Nicholas Doyle has written this in his article about WEBP and JPEG-XR. I asked Christoph about this bug, and he suggested the following:

    You have a few options to work around this bug. You can either disable overlap filtering (jxrencapp option -l 0 … or encode all your images in 32bppPRGBA.

    Disabling the overlap filter is generally recommended only for losslessly compressed images but discouraged for lossy compression as it leads to visible block artifacts for higher compression ratios.

    The other option is to encode your alpha channel as pre-multiplied alpha. In your case you would pass -define tiff:alpha=associated to ImageMagick to create a PRGBA TIFF file, the options for jxrencapp stay the same.

    If your input image has no alpha channel, you can add a dummy (fully opaque) one, save again as PRGBA TIFF and then encode to JXR with alpha quantization -Q 2. This still encodes the dummy alpha channel losslessly and has very little overhead compared to a non-alpha image. The lossless default -Q 1 seems to unnecessarily bloat the file.

    Note that I have added support for the -l 0 fix to the HTML5 Image Converter via the --jxr-ie9-fix paramater. I was not successful doing implementing the -define tiff:alpha=associated fix (did I mention that JxrEncApp is hard to use?)

  3. You can use nconvert to convert to the JPEG-XR format (the HTML5 Image Converter will use it via the --jxr-nconvert paramater. In practice, however, I find that JxrEncApp does a better job at compressing JPEG-XR format than nconvert does (although it does get rid of the IE9 gray-border-bug).


When using kdu_compress, you’ll notice it does not have a flag for quality like the other image processing tools for the other image formats do. In order to work around this, I played around with the rate option in order to control the amount of compression.

I would have liked to compare kdu_compress with OpenJPEG, but unfortunately I could figure out how to make alpha channeled JPEG 2000 files with it. If anyone has any information on this, please let me know in the comments below.


APNG files can be quite large compared to the other file formats, due to its use of PNG’s lossless compression algorithm. In order to shrink them down a bit, I used apngdis to produce static PNGs of all the frames, used pngquant to quanitize each of the frames, and then assembled these frames into a new APNG using apngasm. This works for a lot use-cases, but keep in mind that a lot of times you won’t always get the same compression savings that you can with JPEG-XR, JPEG 2000 and WEBP.


By far, the WEBP tools that Google provides are the easiest of all the tools I used for the altenative image formats. I had no issues getting started, and I expect you will have no issues as well. Kudos to the WEBP team!


This is just the beginning. There will be a lot more blog posts comparing these image formats, and I believe it is only a matter of time before one wins out. Feel free to voice your opinion on these formats below (I’m sure that this debate will get heated at times).

Tags: Uncategorized

11 responses so far ↓
  • 1 Gary Sullivan (@ Microsoft) // Jan 14, 2015 at 6:45 pm

    (from a reader at Microsoft)

    I really like the Space Needle picture demo a lot (although it seems necessary to use the separate pop-up window to see the effect).

    You may be interested to hear that there is a movement toward establishing a new MIME media type code for JPEG XR. A provisional registration has been published at, and the JPEG committee plans to standardize that as part of the JPEG XR official specs in ISO/IEC and ITU-T.

    I’ll try to further read your post more carefully regarding other aspects. I noticed the “Microsoft: if you are reading this” remark, and I’m sorry to hear that you had some issues with the JxrEncApp package. I suppose that app’s really more of an SDK sample that is necessarily simple, rather than a ready-to-use application tool. I’ll pass that note on to someone more suitable than myself – I’m personally focused on design concepts and standardization rather than the software.

  • 2 zoltan // Jan 15, 2015 at 12:08 am

    @Gary: Wow .. that was fast! :-)

    Thanks for taking the time reading this and replying with this new information. The image/jxr MIME type described in the link you gave makes a lot of sense, and I will provide this information to the picturefill team so we can make an appropriate change. Any idea when this MIME type proposal becomes official?

    I also really appreciate you addressing the JxrEncApp comments I wrote. It’s really cool that Microsoft released JxrEncApp (and the rest of jxrlib) under an open source (New BSD) license to the web development community … hopefully someone can fix these small issues an be worked out so that it will be easier for web developers like me to batch encode a whole slew of JXR files from RAW or PNG sources.

  • 3 Kornel // Jan 15, 2015 at 10:14 am

    Comparing lossless PNG to lossy WebP/J2K is very unfair (see

    You should compare to lossy PNG from pngquant or mediancut-posterizer:

    or at least compare lossless PNG to lossless variants of WebP/J2K/JXR.

  • 4 zoltan // Jan 15, 2015 at 8:36 pm

    @Kornel: Good point. As I mentioned in the post, it is hard to compare which image format is better than which — it depends on the image. I was mostly interested in the lossy compression, and I had investigated the quantized PNG using pngquant on the dice example above. It gives some striping artifacts and dithering on the dice. Here it is FWIW:

    To show an extreme example of how one image format can beat another, here is an example with the planet that has JPEG2000 beating all the other formats:

    If you compare it with a quantized PNG so you can see that the artifacting of the shadowed part in the quantized PNG. If you look at the demo in Safari, the quantized .png is 583.8K, while the .jp2 file is 142.8K. The JPEG 2000 file also shows little loss of detail. The JPEG-XR and the WEBP, which smaller than the PNG, look a little blurrier.

    The problem is that in my research that which image format compressed better depended on the image, so I can’t say one file format is better than the other. It is definitely worth looking into further where each file format’s strengths and weaknesses lie. For alpha-channeled images, it seems that sometimes quantizing a PNG is better, and sometimes it is not.

  • 5 Max Stepin // Jan 16, 2015 at 9:32 am

    The idea of lossy PNG optimizations for Paeth filter is very promising. I remember experimenting with it too, but pushing it too far makes those “diagonal artifacts” too noticeable. I wonder if it’s possible to improve the algorithm so the artifacts would look more like general noise removal over smooth areas of the image, not favoring any particular direction.

    The article is very thorough and not browser-biased, I like that. :)

  • 6 zoltan // Jan 16, 2015 at 11:43 am

    @Max: Thanks! It is so hard to ensure everything is presented because there is so much information about these file formats and it does take a bit of time to investigate everything. I will be following up this post with others I am sure — there is so much here to cover.

    I hope more comments below cover optimizing the image formats as well as the older (GIF/PNG/JPG) ones as well. These tips can only help developers looking into this.

  • 7 zoltan // Jan 16, 2015 at 11:48 am

    @Max: (P.S. Thanks for all the great APNG command line tools. I wouldn’t have been able to do this blog post without them — they were quite easy to work with and I was able to use them on every OS I tried easily :-) )

  • 8 Xiteng Liu // Apr 24, 2015 at 10:42 am

    First, Nice work. But, it would be better if there is original image signal displayed so that distortion can be better indicated. In general, the 24 Kodak test images can be used as standard original data.

    I have some comparison between JPEG, JPEG2000, JPEG XR and WebP both in lossy and lossless compressions, see Maybe those results can supplement the comparisons reported here.

  • 9 zoltan // May 9, 2015 at 2:48 pm

    @Xiteng: Your site compares JPEG, JPEG2000, JPEGXR and WEBP with your other format, Lucid. Is this something that can be used in web browsers today? Just want to see if and how this can be used by web developers today.

  • 10 Jonathan Graham // Oct 29, 2015 at 5:25 pm

    I’d add that while still some distance off FLIF is a kind of interesting technology.

    It is lossless, superior to PNG – royalty and patent free and can decodes in a progressive way which gives you lossy compression “for free”.

  • 11 zoltan // Nov 1, 2015 at 3:00 pm

    @Jonathan: Looks interesting. Would be great to see it when the format has been finalized and if any of the browser manufacturers pick this up. Would like to see how it performs in the real world on the web compared to the other formats.

Give Feedback

Don't be shy! Give feedback and join the discussion.

Please Note: If you are asking for help using the information on this page or if you are reporting a bug with the code featured here, please include a URL that shows the problem you are experiencing along with the browser/version number/operating system combination where the issue manifests itself. Without this information, I may not be able to respond.

An orange star denotes a required field.