Blog Post Updates (Jan 30, 2019):
- On January 30, 2019, we updated this article to reflect WEBP support for both Firefox and Microsoft Edge.
- On August 22, 2019, we updated this article to reflect Microsoft Edge > 18 will not support JPEG-XR anymore, due to it switching to the Blink rendering engine.
- At the original time of this writing, Modernizr was important to implement
<picture>
element for many browsers due to spotty support. Today, IE11 is the only browser in use that doesn’t support it natively. For this reason, and depending on your use-case, you may want to forgo using picturefill and have IE11 use the<img>
tag fallback instead.
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, Firefox 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 modern browsers support <picture>
natively, IE11- doesn’t, so I added JPEG-2000, JPEG-XR and APNG to the mix so that developers could take advantage of these alternate image formats in IE (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:
ImageMagick encoded JPEG (Firefox) |
JPEG 2000 (Safari) |
JPEG-XR (IE9 – IE11, Edge < 18) |
WEBP (Chrome, Firefox 65+, Edge 18+) |
---|
(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+, Edge or Firefox 65+ 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.
In 2015, Firefox didn’t support any of the alternate image formats and opted, in the short term, to create a more optimized JPEG compression library, mozjpeg (in the long term, they were apparently looking into supporting Daala, but given their adoption of WEBP in Firefox 65, I assume they abandoned that format). 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:
mozjpeg encoded JPEG (Firefox) |
JPEG 2000 (Safari) |
JPEG-XR (IE9) |
WEBP (Chrome) |
---|
Even though some artifacting remains, mozjpeg is pretty good, so it is worth investigating when creating fallbacks for alternative image formats.
One Image Format To Rule Them All?
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 ImageMagick (quality=20) and mozjpeg (quality=24) JPEG files.
- Saturn: compared with ImageMagick (quality=30) and mozjpeg (quality=38) JPEG files.
When this article was originally written, WEBP was not supported by Microsoft or Mozilla. We now have support on modern builds of Edge and Firefox. The only holdout on WEBP is Apple, who as of 2019 still does not support this format.
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, using a modern web broser, 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:
JPEG 2000 | JPEG-XR | PNG | WEBP | |
---|---|---|---|---|
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:
WEBP | JPEG-2000 | JPEG-XR | APNG | |
---|---|---|---|---|
Chrome | ✔ | |||
Safari | ✔ | ✔ | ||
Internet Explorer 8+ | ✔ | |||
Microsoft Edge | ✔ | ✔ | ||
Firefox | ✔ | ✔ |
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:
<picture> <source srcset='dice.webp' type='image/webp'> <source srcset='dice.jxr' type='image/vnd.ms-photo'> <source srcset='dice.jp2' type='image/jp2'> <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 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:
- 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:
<picture> <!--[if IE 9]><video style='display: none;'><![endif]--> <source srcset='dice.webp' type='image/webp'> <source srcset='dice.jxr' type='image/vnd.ms-photo'> <source srcset='dice.jp2' type='image/jp2'> <!--[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 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'> </div>
… 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. */ html.no-apng.no-webp.cssanimations .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. */ html.no-apng.no-webp.jpegxr.cssanimations .b { background: url('./b-stitched.jxr') left center; } /* * 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') left center; } /* * 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') 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:
WEBP | JPEG-XR | JPEG 2000 | APNG | |
---|---|---|---|---|
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:
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
where:
--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:
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 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
where:
--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:
JPEG-XR
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:
- 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 (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?) - 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).
JPEG-2000
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
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.
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).
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 http://www.iana.org/assignments/provisional-standard-media-types/provisional-standard-media-types.xhtml, 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 https://pornel.net/faircomparison).
You should compare to lossy PNG from pngquant or mediancut-posterizer:
https://speakerdeck.com/pornel/lossy-png-for-true-color-images-velocity-conf-eu-2014
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: http://useragentman.com/tests/html5ImageConverter/examples/dice-compare-quant/dice.html
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:
http://useragentman.com/tests/html5ImageConverter/examples/saturn-alpha/saturn.html
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 http://qualvisual.net. 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. http://petapixel.com/2015/10/02/flif-is-a-new-free-lossless-image-format-that-raises-the-compression-bar/
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.
denotes a required field.