WebP Browser Support

Browser support for WebP extends primarily to Google- and Blink-based browsers: Chrome, Android Browser, and Opera. The current support matrix is shown in Table 5-1.

Google suggests using the Accept HTTP request header and checking if it contains image/webp to determine if a server should serve a WebP image to a client. While this works for many cases, it has problems relating to the evolving nature of WebP. If a client sends an Accept: image/webp header, you can assume it supports up to the extended variation of WebP, but it is impossible to know (with the Accept header alone) if the client supports WebP animation. If new features are added to WebP (like improved VP9 coding), then this problem compounds and it will be impossible to determine support by Accept header alone.

Because of this deficiency with the Accept header and because most other browser-specific formats don’t use the Accept header, the most robust solution generally is to, unfortunately, parse User-Agent strings to determine image support in addition to the Accept header. The Accept header is discussed in more detail in Chapter 13.

WebP Details

The most interesting variation of WebP when talking about optimizing for the Web is the extended variation. This variation is important because it supports both lossy encoding and full transparency. With these two features, WebP becomes a great format to replace both JPEG and PNG. You get the byte savings of JPEG (and then some) and the transparency support previously only available in the byte-heavy PNG format. The lossless compression modes are useful in many contexts, but web performance isn’t particularly one of them. WebP offers good byte savings for its lossless encoding when compared to other lossless encodings, but the image weight is usually impractical for normal web use. The lossless encoding features of WebP are more interesting and relevant for image archiving purposes.

At its core, lossy WebP is encoded very similarly to how JPEG is encoded with some important differences. As in JPEG encoding, the Discrete Cosine Transform (DCT) is also used in WebP encoding. Instead of JPEG’s 8×8-pixel blocks, WebP uses 4×4-pixel blocks for performing the DCT. WebP also allows for a variety of zig-zag patterns to traverse the pixels in a block compared to JPEG’s single zig-zag pattern. The biggest improvement over JPEG is that WebP will try to predict the pixels in a block using pixels above and to the left of the block and a number of predetermined prediction algorithms. After WebP makes a prediction of a particular block, that block can be precisely described as a difference from this prediction. While JPEG applies the DCT to the raw pixels, WebP applies the DCT to this prediction difference. WebP’s approach means that the coefficients produced by the DCT are generally much smaller and contain more zeros than JPEG’s approach. This is one of the primary compression improvements of WebP over JPEG.

The second major difference between WebP and JPEG is the compression algorithm used to encode all of these DCT coefficients. JPEG uses Huffman encoding, whereas WebP uses the superior arithmetic encoding. The JPEG specification allows for JPEGs to be encoded using arithmetic encoding, but this capability was never implemented by anything other than very specialized encoders and decoders. The reason arithmetic encoding never caught on with JPEG is because, at the time, there were a number of patents protecting the algorithm and licensing the technology would have been costly. Because of this, virtually all JPEGs are encoded using Huffman encoding, and changing that would involve an almost impossible shift in JPEG compatibility and legacy JPEG code. By the time WebP hit the scene, patents surrounding arithmetic encoding had expired, allowing for a fresh start.

WebP isn’t perfect, though: there are two important features of JPEG that are missing with (lossy) WebP. The first missing feature is configurable chroma subsampling. VP8 encoding specifies that a chroma subsampling of 4:2:0 will always be used; this means that all WebP images are also encoded using 4:2:0 chroma subsampling. For the vast majority of images this is a great choice and, among other benefits, provides very sizeable byte savings with minimal visual degradation. There are a number of image types, though, that don’t lend themselves well to this aggressive chroma subsampling. Images with hard edges between black or white and solid color often have noticeable artifacts along these edges. With this chroma subsampling, there’s often a dark ring in the colored edge that is unacceptable to many people. This is most commonly seen with solid colored text in images.

The inability to configure chroma subsampling in WebP means that either you have to live with this degradation or you have to use another image format for them. Thankfully, there’s been recent work toward improving WebP’s chroma subsampling. The latest version of the cwebp tool offers a -pre 4 option that uses a new chroma subsampling algorithm that dramatically reduces this degradation at the expense of longer image encoding time.

The second important feature that JPEG has that is missing from WebP is progressive loading. Instead of loading the image in full fidelity in a single pass, JPEG can load progressively, starting with an entire low-quality image that gradually improves in quality as data is received. This ability to show an early, full, low-quality image is great for the perception of fast loading; it makes people think the image has loaded much sooner than it really does. This feature is entirely absent from WebP. It can be argued that WebP images load faster than a comparable JPEG simply because WebP images are much lighter weight, bytewise. This argument doesn’t necessarily hold up for large images, though, where it is more important to get a quicker sense of completeness at the expense of lower fidelity (which will later be improved) than it is to display the full-fidelity final image line-by-line as the data comes in.

The absence of progressive loading also makes some more interesting optimizations impossible. For example, with HTTP/2 it is possible to be clever about how image resources are prioritized and multiplexed. A smart HTTP/2 server might give a higher priority to the beginning of an image that can be progressively loaded and a lower priority to the remaining bytes. This allows the low-quality portion of the image to load quickly while also reducing bandwidth contention for other resources. This is, unfortunately, impossible with WebP.

WebP Tools

The tooling for working with WebP images is pretty good—better than all of the other tools for working with browser-specific image formats. The two main tools are libwebp and ImageMagick. libwebp is a C library for encoding and decoding WebP images but has useful standalone tools bundled with it. These tools are cwebp and dwebp for encoding and decoding WebP images, respectively. If you’re familiar with cjpeg for creating JPEG images, then cwebp will feel very familiar. ImageMagick actually uses libwebp internally to provide WebP support. If you are already using ImageMagick for some of your image processing, then using it to take advantage of WebP is very convenient.

JPEG XR Browser Support

The only browsers that support JPEG XR today are Microsoft’s browsers, specifically Internet Explorer 10 and higher and the new Edge browser. While Internet Explorer 9 does support JPEG XR partially, there were rendering bugs that made the format unusable for most purposes. Internet Explorer 9 would display an unsightly grey border around all JPEG XR images; this was fixed in Internet Explorer 10. The current support matrix is shown in Table 5-2.

Internet Explorer and the Edge browser will send an Accept: image/jxr header with HTTP requests for images. This header could be used by a server to decide if a JPEG XR image should be served to a client. Unfortunately, Internet Explorer 10 and earlier don’t send this header, so, in general, it’s more practical to parse User-Agent strings if you want to cover the widest supported user base.

JPEG XR Details

JPEG XR supports all of the important features of JPEG while improving lossy encoding byte savings and adding support for full transparency. Unlike WebP, JPEG XR does support a full range of chroma subsampling options as well as progressive loading.

A number of new approaches are taken to compress images using JPEG XR, many of which are designed to enable—but not force—lossless encoding. Firstly, while JPEG uses YCbCr to describe pixel data, JPEG XR uses a similar but slightly different color space: YCgCo. Just as Cb is blueness and Cr is redness, Cg is greenness and Co is orangeness. YCgCo accomplishes a lot of the same goals as YCbCr but is able to do so in a completely lossless way.

Secondly, instead of using the Discrete Cosine Transform like JPEG, JPEG XR uses a modified version called Photo Core Transform (PCT). PCT is similar to DCT except that the process is entirely lossless as well. All lossiness in JPEG XR is entirely due to PCT coefficient quantization. A lossless JPEG XR image is the special case where all quantizations are set to 1—no quantization. JPEG XR improves on JPEG by allowing a certain amount of overlap when working with blocks of pixels. This overlap helps reduce the infamous blocking effect in low-quality JPEG images.

To improve compression, JPEG XR allows for different PCT coefficient ordering patterns instead of JPEG’s single zig-zag pattern. JPEG XR also has a certain amount of block prediction to help reduce the magnitude of the PCT coefficients. Both of these techniques, if even at just a conceptual level, are mirrored in WebP. JPEG XR does not mirror WebP with the final entropy encoding, though. JPEG XR, like JPEG, still uses Huffman coding to compress the final PCT coefficient data instead of using the superior arithmetic encoding.

JPEG XR Tools

JPEG XR’s tools are its biggest downfall. They are definitely the most difficult tools to use among all the browser-specific formats. Microsoft provides software called jxrlib with bundled tools called JxrEncApp and JxrDecApp to encode and decode JPEG XR images, respectively. The software is very rarely updated and is provided as source code only. Anyone who wants to use these tools will have to go through the process of building the software themselves for their own system.

ImageMagick advertises JPEG XR support, but it isn’t particularly useful. ImageMagick supports only lossless encoding, so it isn’t useful for web performance. ImageMagick actually just delegates all encoding and decoding work to the JxrEncApp and JxrDecApp tools if it’s able to find them. This delegation seems to work inconsistently, however. It’s often worth the effort to use the JxrEncApp and JxrDecApp tools directly even though they are rather difficult to use.

JPEG 2000 Browser Support

Support for JPEG 2000 is available in all of Apple’s recent browsers. Support has been available in desktop and mobile Safari since version 5. An interesting side effect of this Safari support is that Chrome for iOS also supports JPEG 2000. This is because Chrome for iOS is built on top of Safari instead of Blink, which means it’s the only browser that supports more than one browser-specific format: JPEG 2000 and WebP. The current support matrix is shown in Table 5-3.

Safari doesn’t send any hints in HTTP headers about what image formats it will accept. Unlike recent versions of Chrome and Edge, Safari doesn’t send any Accept header with image requests. This means that the most practical way for a server to determine whether or not it should send a JPEG 2000 image is by parsing the User-Agent string.

JPEG 2000 Details

JPEG 2000 maintains all of the important features of JPEG, including configuration options for chroma subsampling and progressive loading, which are absent from WebP. Support for full transparency has been added, which, as with WebP and JPEG XR, makes JPEG 2000 another great alternative to JPEG and PNG.

While the feature set of JPEG 2000 is similar to the other browser-specific formats, under the hood it is the most different format as far as encoding of the actual image is concerned. JPEG 2000 doesn’t use DCT or any variation of DCT; instead, JPEG 2000 uses a Discrete Wavelet Transform (DWT) at the core of its encoding. It’s best to think of DWT as a transform that takes an image (like the one shown in Figure 5-1) and divides it into four parts (Figure 5-2). The first part is the original image at one-half the width and one-half the height. The other three parts are all also individually one-half the height and one-half the width of the original image, but, combined, contain the details necessary to exactly construct the full-size image from the first part. One part has horizontal details, one part has vertical details, and the last part has diagonal details.

Figure 5-1. Original image before Discrete Wavelet Transform

Figure 5-2. Image after Discrete Wavelet Transform (details enhanced for demonstration purposes)

You can see in Figure 5-2 that the three detail parts are mostly empty and black. This emptiness allows for a lot of opportunities for compression. To extract even more sparse details, we can repeat this DWT process recursively on the first newly scaled image part. After we’ve recursively applied DWT a number of times, the detail parts are quantized much like DCT coefficients are quantized in JPEG. After quantization, arithmetic encoding is used for final compression.

JPEG 2000 Tools

The tools for encoding JPEG 2000 are in the middle of the road as far as ease of use and features go. The OpenJPEG project provides a C library and the opj_compress and opj_decompress tools for encoding and decoding images, respectively. These tools don’t abstract the concept of “quality” to a simple 1–100 scale like most image encoders; instead, quality is described using compression ratios or PSNR values. The current release is also missing important features like transparency and chroma subsampling support, although transparency support is available if you build the latest unreleased version from the project’s source control repository.

ImageMagick has decent JPEG 2000 support and, in fact, uses the OpenJPEG C library behind the scenes. This means that ImageMagick has the same limitations as OpenJPEG when working with JPEG 2000 images but provides a simpler interface if you’re already familiar with ImageMagick.

Finally, Kakadu Software makes a popular full-featured JPEG 2000 encoder that people and businesses can license for a fee. While features like chroma subsampling are available, learning how to use them is difficult. This encoder is also much faster for encoding than OpenJPEG.