Using WEBP/JPEG 2000/JPEG-XR/APNG Now With Picturefill and Modernizr
January 14th, 2015 by zoltan &
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
The demo on the left (which uses ) 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
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
Here are some browser screenshots that to show the difference between the JPEG, JPEG 2000, JPEG-XR and WEBP:
ImageMagickencodedJPEG (Firefox)
JPEG 2000(Safari)
JPEG-XR(IE9)
WEBP(Chrome)
(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.
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
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,
(in the long term, they are apparently looking into supporting
but this has not been implemented at the time of I am writing this).
To see how well mozjpeg works, I downloaded a
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:
mozjpegencodedJPEG (Firefox)
JPEG 2000(Safari)
JPEG-XR(IE9)
WEBP(Chrome)
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:
Lana Del Ray: compared with
JPEG files.
Saturn: compared with
JPEG files.
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
600×450
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 ) was the only way to get a smaller alpha channeled image from an original PNG ( 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
(using the step property) to implement it for those browsers (thanks to ). Compare the animated GIF with the truecolor animation below and you’ll see the difference:
Drag the balls around or
(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
Quantized APNG
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/vnd.ms-photo'&
&source srcset='dice.jp2' type='image/jp2'&
&source srcset='dice.webp' type='image/webp'&
&img srcset='dice-quant.png' alt='dice'&
&/picture&
(Side note: notice JPEG-XR’s unusual MIME type (image/vnd.ms-photo).
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
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:
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&
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:
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:'&&![endif]--&
&source srcset='dice.jxr' type='image/vnd.ms-photo'&
&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'&
&/picture&
This is due to an odd quirk in IE9 where it won’t recognize &source& unless wrapped in a &video& tag.
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
for reminding me about this).
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
(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 .
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
width: 100
height: 100
/* 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.
html.no-apng.no-webp.cssanimations .b {
background: url('./b-stitched.png')
* 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)
-webkit-animation: bplay 1000ms steps(20)
* 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.
html.no-apng.no-webp.jpegxr.cssanimations .b {
background: url('./b-stitched.jxr')
* Likewise, if the browser supports JPEG 2000, use
* the .jp2 version of the sprite.
html.no-apng.no-webp.jpeg2000.cssanimations .b {
background: url('./b-stitched.jp2')
* For other browsers that don't support CSS animations
* at all, we fallback to the animated GIF.
html.no-apng.no-webp.no-cssanimations .b {
background: url('./b.gif')
* 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: -2000 }
/* Webkit variant for older WebKit browsers */
@-webkit-keyframes bplay {
100% { background-position: -2000 }
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
by the Google WebP Team
JxrEncApp (part of
by Microsoft Research.
You have to compile yourself & I have done so successfully on a Mac and Windows (using ) with no problems.
You can also use , but it doesn’t compress as well as JxrEncApp in my opinion.
(payware, free for non-commercial use) and
(open source, but I was unsuccessful using it for alpha channeled images)
by Max Stepin.
I also used
to disassemble the frames of existing APNG files and
to quantize these frames to make them smaller before assembling them back into a smaller APNG file.
I finally used
to create a GIF fallback for older web browsers.
Photoshop Plug-ins
by Toby Thain
by Microsoft Research
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
GIMP Plug-ins
(Windows only)
by Chrysler
by Akkana Peck
by daisuke
Note that for all the demos, I used the command line tools listed above as well as
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 ), 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:
html5ImageConverter.sh --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 .
--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
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
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:
html5ImageConverter.sh --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
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.
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 ).
However, I was fortunate that , 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:
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
IE9 has a known issue where it will render a light gray border around some JPEG-XR images ( has .
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?)
You can use
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 , 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 , 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!
Conclusions
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).
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.
denotes a required field.