The sources of this article can be found at the end of this page. Thanks to all the high value content that has resulted in this FAQ!
This next-generation image codec, called JPEG XL, is being developed by the JPEG Committee. JPEG XL promises to offer significantly better compression efficiency than existing formats and other features fit for web distribution, exceptionally high-quality images.
With billions of images captured, created, uploaded, and shared every day, the need for efficient image compression is evident. Websites and user interfaces are increasingly image-rich, with images used for sharing experiences, visualizing information, and creating appealing designs.
Devices with a strict network connection and power consumption constraints can benefit from better compression. Due to the smaller file size, businesses can utilize images with higher resolutions, wider color gamuts, and higher dynamic ranges without worrying about overwhelming datasets.
The most common coding formats are JPEG, PNG, and WebP for most applications. The described applications will benefit from more efficient compression, shorter network transmission times, and more interactive applications.
The bit count of images is relatively low when compared with video data. In any case, websites and interfaces generally can contain hundreds of photos, or at least several high-resolution images, adding up to megabytes of data. Unlike video streams, which can be buffered before playback, image-based UIs need to be responsive and interactive, without stalling and taking several seconds to download or be interactive.
Recently, new image formats with more efficient compression capabilities than JPEG have been developed. However, these formats have some shortcomings concerning the use cases discussed below. Several evidence-based compression algorithms have recently been presented that outperform the currently used standards for image coding.
While these technological advances have been made, no widely accepted standard exists that can support state-of-the-art compression performance and is widely accepted by consumer devices and browsers alike.
The JPEG XL format aims to become this widespread format for images. It is a standard for capturing, archiving, transmitting, and distributing images and graphics, illustrations, mixed content (e.g., screenshots), and even animations.
JPEG XL is perfect for web applications requiring responsiveness, a wide color gamut, or a high dynamic range. It combines legacy transition features with effective compression, resulting in excellent image quality. This FAQ describes JPEG XL in detail.
With JPEG XL, you can choose between lossy and lossless compression of raster graphics files. This format aims to outperform existing raster formats and become a universal replacement.
With JPEG XL, you can distribute high-quality photos over the web and compress them efficiently with a practical, royalty-free codec. As well as previews, progressiveness, animation, transparency, wide color gamut, and high bit depth, it offers high dynamic range and high bit depth.
The user expects accurate reproduction of images of ever-higher resolutions. The experiments performed during the standardization process have demonstrated the feasibility of economically storing images without perceptible quality loss, decoding existing JPEG files without quality loss, and developing fast software encoders and decoders.
For several years, new codecs must coexist with their predecessors. JPEG XL offers value to users of both existing JPEGs and new JPEGs. With its coding tools, it can reduce the transmission and storage costs of JPEG by 22% and allow exact byte-for-byte reproduction of the original file.
The decoding process must be fast and low-power. JPEG XL takes advantage of multicore and SIMD and decodes faster than JPEG as soon as you have at least four cores to work with.
In addition to having a file extension of JXL, JPEG XL has the internet media type image/jxl. JXL files are images saved in the JPEG XL file format developed by JPEG (Joint Photographic Experts Group). Files contain a photo, illustration, screenshot, or other raster image data that has been compressed using the JPEG XL compression algorithm.
Compared with existing codecs, the JPEG XL format offers several advantages:
- Over and above the common coding standards at the same subjective quality, significant improvement in compression efficiency, e.g.,>60% over JPEG
- Support for alpha-channel coding and animated images, among other features
- Designed with high fidelity in mind (unlike any video-derived format). Compression of high-quality images with high resolution, high bit depth, high dynamic range, and wide color gamut coding is supported
- Progressive decoding for automatic low-quality image placeholders, including saliency progression to prioritize more critical parts of the image first (like face details)
- A reference encoder with fully automatic encoding based on a visual target, not on technical parameters like with JPEG
- A royalty-free baseline to encourage widespread adoption
- Unique legacy-friendliness allows to transcode JPEG losslessly
XL shares the same disadvantage as any new format that needs to be established: It lacks support. In addition, few operating systems support JPEG XL. There is a lack of browsers and image viewers that support it even though many browsers added support for JPEG XL behind a flag.
- JPEG has been hitting its limits for an extended period:
- JPEG can only do 8-bit color depth, no HDR.
- JPEG can only do lossy, with no lossless support
- JPEG lacks good compression for graphics images
- JPEG cannot do alpha transparency
- JPEG cannot do animations
- JPEG does not support multiple layers
- JPEG compression efficiency is 30 years old and not as good
- JPEG comes with annoying compression artifacts we all love
- Banding, Noise, Blockiness, and more banding.
WebP has been a relief, but it does not support HDR, and compression could be better. AVIF has been a significant step into the future, but it lacks efficiency in encoding images. Both WebP and AVIF have been derived from video formats, while JPEG XL has an image architecture from the start in mind.
Historically, image data quality has been reduced for the sake of quantity. Images and videos delivered to users suffered from block artifacts.
The goal of JPEG XL is to provide solutions to deliver images faster, more economically, more robustly, without surprises, and generally with better-perceived quality.
The JPEG XL format is well suited to handling high-quality images. It aims to serve the needs of today's and tomorrow's increasingly rich media experiences. The ideal compression level for an image is one where there is no discernible loss of quality from the original.
JPEG XL is a practical solution for scalable web distribution and efficient, high-quality image compression. Its main benefits are the following:
- Significantly smaller size at the same subjective quality
- Fast and parallelized encoding and decoding configurations
- Features such as progressive decoding
- Lossless compression and no generation loss
- High-quality applications (wide color gamut, bit depth, dynamic range)
As a bonus, a royalty-free baseline encourages adaptation.
The JPEG committee has developed JPEG XL, the next-generation image compression codec. Google's Pik proposal and Cloudinary's FUIF proposal served as the foundation. All three companies have authors and developers responsible for creating JPEG XL.
Google has an experienced team partially responsible for Brotli, Woff 2.0, Butteraugli, Brunsli, or Pik.
Influential authors and developers include Jyrki Alakuijala, Sami Boukortt, Martin Bruse, Iulia-Maria Comsa, Alex Deymo, Moritz Firsching, Thomas Fischbacher, Sebastian Gomez, Renata Khasanova, Evgenii Kliuchnikov, Jeffrey Lim, Robert Obryk, Krzysztof Potempa, Alexander Rhatushnyak, Zoltan Szabadka, Lode Vandevenne, Luca Versari and Jan Wassenberg.
Cloudinary's team members, partially responsible for FLIF / FUIF, include Jon Sneyers, Eric Portis, Tal Lev-Ami, and Colin Bendell.
Other JPEG experts include Touradj Ebrahimi, Walt Husak, Andy Kuzma, Fernando Pereira, Antonio Pinheiro, Thomas Richter and Peter Schelkens. Please note that this list may or may not be complete.
The name is easily understood. Joint Photographic Experts Group (JPEG) designed the format. Since 2000, the letter X has been part of more than one JPEG standard: JPEG XT, JPEG XR, JPEG XS. L means Long-term because it will replace the legacy JPEG and last as long.
A Call for Proposals for JPEG XL, a next-generation image compression standard, was issued in 2017 by JTC1/SC29/WG1. On December 25, 2020, the bitstream format (file format) was frozen, ensuring that it will be decodable by future releases.
- Oct 2018: 7 submissions to JPEG XL CfP investigated
- Jan 2019: Combination of Pik+FUIF selected
- April 2019: New Project (NP) started
- July 2019: Committee Draft (CD)
- Jan 2020: Draft International Standard (DIS)
- July 2020: DIS approved, with 181 ballot comments (!)
- October 2020: all DIS ballot comments addressed
- November 2020: final validation experiments
- December 2020: bitstream frozen
- January 2021: Part 1 (codestream) FDIS submitted
- April 2021: Part 2 (file format) FDIS submitted;
- Draft Amendment to Part 1 (Profile & Levels)
- Continue integration & adoption!
- International Standard (IS): before the end of 2021?
- Finalize Part 3 (conformance)
Source: Google Docs Slide
Both Google and Cloudinary developed a combination of the PIK and FUIF formats to create JPEG XL. But JPEG XL can't be considered a combination of these two formats. After several years of joint development, PIK and FUIF were combined, and many improvements were made.
It shares similarities with JPEG, as it preserves features such as DCT, progressive decoding, and 4:4:4 or optional chroma subsampling. However, several additional features have been added along the way:
- VarDCT (4x4, 32x32, 8x16, ...)+
- Adaptive quantization
- Better entropy coding
- Better progressive
- XYB color space
- Parallel Decoding
- High bit depth (up to 32-bit)
- Channels, Alpha Transparency, Depth Map
- Multi-frame, layers
A reference implementation of JPEG XL has been licensed under the Apache 2.0 license by the creators of JPEG XL. Therefore, JPEG XL is free and open-source software (FOSS) and patent-free. Additionally, they offer an open-source, royalty-free implementation of JPEG XL, also available on Gitlab.
A large part of their success has been due to contributors' royalty-free patent licensing commitments to past standards. Similar commitments will be helpful to the adoption of the next-generation image coding standard.
JPEG XL is a multi-part specification, like most other JPEG standards. Currently, the following parts are being developed or released:
- ISO/IEC 18181-1. Part 1, Core coding system: Defines the JPEG XL codestream and decoder, which can be used for lossy encoding, lossless encoding, and lossless recompression of existing JPEG images. (released)
- ISO/IEC 18181-2. Part 2, File format: Specifies an extensible box-based file format that supports metadata (e.g., EXIF and JUMBF) and legacy JPEG bitstream reconstruction data. (released)
- ISO/IEC 18181-3. Part 3, Conformance testing: Provides test material and procedures to validate proprietary solutions against the standard specification. (development, WD Stage)
- ISO/IEC 18181-4. Part 4, Reference software: Provides a free and open-source, royalty-free JPEG XL reference implementation, also available on Gitlab. (development, WD Stage)
Usually, once the process reaches the FDIS stage, the specification is "frozen," and JPEG XL can be used. In the meantime, software support for JPEG XL in applications and platforms will still take time and effort.
In the past, several attempts at dethroning the old JPEG have failed. JPEG XL's creators are hopeful that they have succeeded this time and have created a worthy successor to a 30-year-old image format that is as old as the internet.
The JPEG XL format allows users to balance three primary criteria:
- High fidelity to the source image (matches human perception)
- High-speed encoding and decoding
- High compression ratio (20:1 to 50:1)
The JPEG XL codec has the following key features:
- Improved functionality and efficiency over traditional formats
- Progressive decoding (by resolution and precision)
- Lossless JPEG transcoding
- Support for both photographic and synthetic imagery
- Graceful quality degradation across an extensive range of bitrates
- Perceptually optimized reference encoder
- Support for wide gamut and HDR
- Support for animated content
- Efficient encoding and decoding without requiring specialized hardware
Unlike the usual method of configuring encoders based on bitrate or quantization settings, which results in image-dependent visual quality, the reference software configures encoders by perceptual target, reliably reaching a desired visual quality.
These key results pertain to compression performance:
- Lossless JPEG transcoding reduces JPEG size by around 16% to 22%.
- About 35% smaller than PNG (50% smaller for HDR)
- JPEG XL is visually lossless at about 40% of the bitrate required by JPEG.
Since JPEG XL supports alpha transparency, it can be used in place of WebP, PNG, and AVIF with transparency. Even after lossless transcoding existing JPEG images to JPEG XL, you can add alpha to them.
Among the features of JPEG XL are animation, alpha channels, layers, thumbnails, lossless coding, and progressive coding. "Multi-frame" is a feature intended to emulate photo bursts or animations. It is important to remember that a video codec will achieve much better compression because JPEG XL does not provide inter-prediction.
- Features of JPEG XL multi-frame are:
- Can subtract the previous frame
- The frame can be smaller than the canvas
- Blend and dispose modes like in APNG/GIF/AWebP
- Use patches for moving sprites
- Zero-delay frames are allowed
Some image codecs can decode even partially loaded images, resulting in a lower-quality (or lower-resolution) preview. With progressive decoding, no bytes are wasted on separate previews: the first bytes of the high-quality image is the preview image. JPEG XL provides progressive decoding based on resolution and precision.
To generate the first preview more quickly, you can progressively encode the DC itself in JPEG XL. The DC, or the first full-image preview for a progressive JPEG file, typically takes 15 to 20 percent of the total file size. Using progressive DC, a feature of JPEG XL, you can create a first placeholder image when only 1 percent of the total file size is available.
There are two more advanced progressive encoding options in JPEG XL: Middle-out scans: In JPEG, scans are top to bottom. In JPEG XL, where encoding occurs in groups of 256x256 pixels, you can reorder the groups. As a result, you should start all scans with the groups in the middle, likely to contain the most exciting parts of the image. Progression of saliency: In progressive scans of JPEGs, each image part is given the same amount of detail. This is not the case for JPEG XL. That means you can encode images progressively based on saliency, such as encoding faces or foreground objects in more detail first, followed by the background.
Did you know? Multiple passes of AC coefficients can be contained in the JPEG XL bitstream. This allows images to be encoded progressively by sending low-frequency coefficients first and later high-frequency coefficients. During a given pass, the quality of selected regions of the image can also be refined, allowing progressive decoding of area-of-interest.
- JPEG XL is intended to be a format that offers high fidelity and a small file size. Therefore, it can support many high-quality applications, including wide gamut / HDR, visually lossy 4:4:4 up to 32 bits of depth, dynamic range, and generation loss resilience.
- Lossless up to 32 bits per channel (float or int)
- Compatible with HDR & wide gamut
- Not for end-user image delivery but also authoring workflows
Image dimensions of over a billion (230-1) pixels on each side.
The reference encoder in JPEG XL is perceptually optimized. By focusing on perceptual targets, the reference software consistently achieves a desired visual quality, as opposed to the usual strategy of configuring utilizing bitrate or quantization, which results in a highly image-dependent visual quality. End users will also benefit from this since they no longer need to guess what quality to give an image, like the 1-100 scale for JPEG, but rather specify what quality they want.
The JPEG XL format supports lossless compression, with around 35% better compression than PNG. In addition, existing JPEG files can be losslessly converted to JPEG XL, significantly reducing their size.
JPEG XL is incredibly efficient at compressing images at perceptual qualities ranging from visually nearly lossless (in a side-by-side comparison) to visually lossless (in a flicker test, which is more rigorous than a side-by-side comparison).
For the same quality, lossy is about 60% smaller than JPEG. Adaptive quantization allows adjusting quality locally as needed.
JPEG XL is excellent for low-fidelity images, even though AVIF offers better compression in terms of file size.
JPEG XL offers the same compression as AVIF images and better compression than WebP images, and it's an excellent choice for medium-fidelity images.
JPEG XL focuses on offering high fidelity images while keeping file sizes small. JPEG XL was designed with this in mind, making it an ideal candidate for high-fidelity images.
In addition to photos, JPEG XL can compress non-photographic images efficiently, including icons and sprites.
Transcoding JPEGs without loss reduces their size by approximately 16% to 22%. Lossy is even more robust, between 20 and 60%. This will vary according to the compression effort and quality of the image.
JPEG XL is visually lossless at about half the bitrate required by JPEG. JPEG XL is visually lossless in side-by-side comparisons, typically at similar bitrates as HEVC-HM-Y444.
- Compared to other formats, JPEG XL has the tiniest header of them all:
- PNG: 67 bytes
- GIF: 35 bytes
- JPEG: 107 bytes
- WebP: 26 bytes
- JPEG XL: 12 bytes
- AVIF: 298 bytes
In a presentation about JPEG XL, I've found a funny example that displays how efficient JPEG XL is:
117-byte AVIF file: "Hi, there! I am an AVIF image, with the brands avif, mif1, miaf, MA1A, encoded with libavif, and you should handle me as a picture, and my dimensions are —"
117 byte JPEG XL file:
JPEG XL offers a fast single-core encode speed, but of course, not as fast as the fancy JPEG encoders.
- libjpeg-turbo: 100 MP/s
- Mozjpeg: 10 MP/s
- AVIF: 0.8 MP/s
- JPEG XL: 15 MP/s
JPEG XL offers a fast single-core encode speed, but not as fast as the fancy JPEG decoders.
- libjpeg-turbo: 180 MP/s
- Mozjpeg: 100 MP/s
- AVIF: 25 MP/s
- JPEG XL: 30 MP/s
To encode a large image (more than 256 pixels on any axis), it is split into subrectangles 256 * 256 in size, and each is encoded independently. An index of the bitstream positions of the rectangles allows decoders to seek the beginning of each rectangle.
Four benefits follow: the decoder can process each rectangle independently, it can process only selected regions of large images, it can rearrange rectangles (e.g., in saliency order), and it can restart decoding if a previous rectangle is corrupted.
The JPEG format is a single-core format. On multicore platforms, JPEG XL is faster to encode and decode. Hardware is not necessary; software encodes and decodes are fast enough. libjpeg turbo has a decoding speed of 200 MP/s, and mozjpeg has 100 MP/s. JPEG XL has a decoding speed of 30 MP/s, but with eight cores, that results in 240 MP/s.
A JPEG XL bitstream may contain multiple passes of AC coefficients that are summed together. Gradually encoding images is possible by sending low-frequency coefficients first and higher frequency coefficients later. A particular section of the image can also be refined in a given pass, allowing for area-of-interest progressive decoding.
Since DC coefficients are sent first, an eight* downsampled image can be obtained without reading the entire file from the JPEG XL bitstream.
Using JPEG recompression, legacy JPEG files can be converted losslessly to the more compact JPEG XL format: existing JPEG files can be transferred seamlessly. These can be restored into the same JPEG file to maintain backward compatibility with existing JPEG applications.
Previous attempts to develop "next-generation" image formats, including JPEG 2000, JPEG XR, and HEIC and AVIF, didn't achieve this. A JPEG image must be decoded into pixels and then re-encoded with one of those other formats. This irreversible process results in generation losses.
In the JPEG XL Project, those challenges were considered from the start. The format was designed to overcome them as much as possible.
The JPEG XL format is a superset of the JPEG format. In addition, JPEG XL developers did not change any of the JPEG coding tools, even with its numerous under-the-hood coding tools that achieve superior compression. Therefore, all JPEG image data is represented as JPEG XL.
In part, this is due to:
The JPEG image is based on the discrete cosine transform (DCT) of 8x8 with fixed quantization tables. JPEG XL offers a much more robust approach, including variable DCT sizes ranging from 2x2 to 256x256 as well as adaptive quantization, of which the simple JPEG DCT is merely a particular case.
For high-fidelity, perceptually optimized image encoding, JPEG XL uses a novel internal color space called XYB. It can also process simple YCbCr color transformations applied by JPEG.
As a result, you do not need to decode JPEGs to pixels to convert them to JPEG XLs. Rather than relying on the JPEG internal representation (DCT coefficients), utilize JPEG XL directly. Even though only the subset of JPEG XL that corresponds to JPEG is used, the converted images would be 20 percent smaller.
The JPEG XL files, on the other hand, are exact copies of the original JPEG files. Additionally, the conversion is reversible: you can convert JPEG XL files back to JPEGs with minimal computation - so fast that you can do it right on the fly.
JPEG XL's legacy-friendly feature is essential. You can also save both storage and bandwidth by preserving legacy images with lossless compression at the same time. Hence, JPEG XL offers immediate benefits, whereas other approaches require sacrifices in storage to reduce bandwidth.
In terms of image compression, JPEG XL has a high perceptual quality that ranges from visually near-lossless (in a side-by-side comparison) to visually lossless (in a flicker test, which is stricter than a side-by-side evaluation) to mathematically lossless.
There has been a great deal of effort to preserve the images' subtle texture and other fine details. While it is possible to use the codec at lower bitrates, where the degradation becomes more evident, it excels at the relatively high bitrates.
A video codec-based image format, on the other hand, tends to do well at low bitrates: it can produce an excellent image in a few bytes. The picture looks good at first but, on closer inspection, often seems washed out. Usually, that won't be a problem for video codecs: low bitrates keep the file size or bandwidth low, and frames are typically shown for less than 40 milliseconds, so the audience won't notice such artifacts. Still images, however, are often of higher quality.
With JPEG XL, you can achieve the highest bit depth and express values of up to 32-bit floats. This is a significant increase from JPEG and WebP's 8 bits or AVIF's 12 bits.
JPEG XL supports RGB, YCgCo, and XYB.
A color space inspired by the human visual system, XYB facilitates perceptually uniform quantization. For computation-efficient decoding, gamma is set at 3.
Human visual system based color space:
- Y: luma
- X: difference L-M
- B: S
JPEG XL uses a color space derived from LMS called XYB. Based on the lower spatial density of S cones, this is interpreted as a hybrid color theory where L and M oppose each other while S is handled trichromatically. As a result, less data is needed for storing blue signals without losing much quality. JPEG XL's colorspace was derived from Guetzli's butteraugli metric and is based on Google's Pik project.
The typical transcoding process decodes JPEG images into pixels and then encodes them into another format. Unfortunately, this is a risky approach because it causes generation loss.
Additionally, you must determine the optimal quality setting. In this case, the already lossy image would become even lossier, potentially ruining the shot. A too high setting will result in a larger file than the original JPEG.
The new codec can expend large amounts of data to preserve JPEG artifacts, potentially leading to bigger files than the original JPEG. Converting a lossy image collection to a new lossy codec can be daunting because of the task of preserving fidelity, reducing storage, and automating it.
The JPEG XL Project took into account those transition problems and designed the format as best as possible to overcome them. The JPEG XL format is a superset of the JPEG format. In addition, JPEG XL developers did not change any of the JPEG coding tools, even with its numerous under-the-hood coding tools that achieve superior compression. Therefore, all JPEG image data is represented as JPEG XL.
The JPEG XL reference offers an entire automatic decoding process in addition to losslessly transcoding images from JPEG to JPEG XL. Instead of specifying a number on a technical scale, JPEG XL lets you specify a visual target.
It is common for noise to be lost when compressed images, even if it is present in the original image. It is possible to add noise to JPEG XL images to achieve more realistic-looking images. Using a pseudorandom procedure, JPEG XL generates the noise added to the image using an intensity-dependent noise model.
- Synthetic noise generation, intensity-modulated
- Useful to replicate capture noise/grain or to make surfaces look more realistic
- cjxl --photon_noise=ISO3200
JPEG XL supports up to 4100 channels, i.e., grayscale or RGB, optional alpha, and up to 4096 "extra" channels.
JPEG XL supports a depth map.
JPEG XL supports overlays.
Input images can be compressed using lossless or lossy compression to create a compressed JPEG XL codestream. The output images can be identical or perceptually similar when decoded. An input JPEG bitstream can be encoded into a JPEG XL file, which contains an image representation codestream and reconstruction data, which can then be decoded back into the original bitstream.
There are two coding modes in JPEG XL:
VarDCT: lossy encoding of photos, emphasizing human vision; it can also be applied to lossless transcoding of JPEG images.
Modular: mathematically lossless encoding or generic lossy encoding. When using VariDCT mode, modulated sub-images such as DC, control fields, and extracted image features are stored as described further below.
Suppose you wish to perform lossless transcoding of JPEG bitstreams (reconstructing both image data and the bit-exact file). In that case, you can also store optional JPEG bitstream reconstruction data.
One or more frames may be present in a JPEG XL file, for example, for animation or overlays. A frame can be subtracted from a previous frame without motion compensation and having smaller bounding boxes, blend mode, and dispose mode. They may also refer to regions from prior frames that have been designated as reference frames, which can serve as a simple interframe coding function and as a tool for coding the content of a screen for still images.
Each frame is divided into parallel encoding and decoding groups for efficient decoding of cropped regions of interest (regions of interest). For VarDCT mode, the group size is 256x256 pixels (with special border handling), whereas, for Modular mode, it ranges from 128x128 to 1024x1024 pixels. Aside from thread-parallelism, the JPEG XL codec has also been designed with SIMD (single instruction, multiple data) features, which makes it suitable for efficient CPU encoders and decoders on today's desktop and mobile processors. An emphasis has been placed on reducing header and metadata overhead, including the compression of color profiles and Exif/XMP metadata, which is particularly important to delivering smaller images via the web.
JPEG XL uses variable block sizes.
- Square: DCT8x8, DCT16x16, DCT32x32, DCT64x64, DCT128x128, DCT256x256
- Rectangular: DCT8x16, DCT16x8, DCT16x32, DCT32x16, DCT8x32, DCT32x8, DCT32x64, DCT64x32, DCT64x128, DCT128x64, DCT128x256, DCT256x128
- Subdivided 8x8: DCT4x4, DCT2x2, DCT4x8, DCT8x4, "Corner" 8x8 DCT: AFV1 - AFV4, "Hornuss" transform (8x8, not DCT)
There can be a "reference frame" that can be used as a basis for working with other frames. This makes it possible to encode repeating elements only once and reuse them repeatedly.
JPEG XL lets you add patches to images. Patches consist of small pixel patterns. There is some benefit in storing those patches and the positions where they appear in an image, only once when they appear multiple times in the picture. In a DCT-based codec, it is challenging to represent compressed printed text, such as compressed printed text in an image.
Quality can be adjusted locally as necessary with adaptive quantization. With the help of advanced math algorithms, it attempts to choose the best quantizer for each macroblock.
JPEG only allows a single quantization matrix to be selected (per channel) for a whole image. As a result, quantization is applied uniformly across the board, even if some areas have more detail and might benefit from more quantization.
JPEG XL still uses a global quantization matrix for each integral transformation; however, it allows this matrix to be scaled locally to decrease artifacts in more complex areas without affecting other parts of the image.
Encoders can target a roughly uniform amount of loss across the image, avoiding significant variations by combining this with a measure of loss.
Legacy JPEG increases the compression ratio by subtracting the DC coefficient from the DC coefficient for the currently encoded block. The local similarities in typical images allow for substantial savings in compression ratio.
However, the prediction mode is rather primitive and does not account for the two-dimensional nature of images. Adaptive prediction in JPEG XL uses eight different modes based on the behavior of nearby pixels to address this issue. DC encoding, as well as encoding of various control fields, are all handled by this predictor.
When predicting the value of a pixel in position (x,y), the adaptive predictor identifies the prediction mode that is most likely to produce the least amount of error by calculating the maximum error expected for pixels (x-1, y), (x,y, -1) and (-1, y -1). An adaptive predictor that computes the expected error in this way also keeps track of the number of prediction modes expected to reach the level of accuracy calculated.
Multiple distributions are created based on the expected error and the number of "correct" prediction modes. This technique detects flat areas in an image, uses specific distributions, and achieves significant size savings.
In lossless mode, this predictor is modified. Lossless predictors use fewer prediction modes (four instead of eight), but the weighted average is calculated instead of choosing one.
A notable artifact of JPEG compression at lower quality is banding, a phenomenon in which an area of an image that contains a slowly varying color (such as the sky at sunset) transforms into one that consists of a few bands of the same color.
As a result, glaring artifacts are at the boundaries between the two bands. DC quantization is the cause of banding in JPEG. With JPEG XL, residuals close to zero in the original image can be encoded with finer quantization steps to avoid this effect. The result is the same as using finer quantization steps for slowly-varying areas, but without sacrificing compression ratio to the extent that finer quantization would be used on the whole image.
Furthermore, JPEG XL smooths the DC image selectively to reduce banding in areas with steep gradients. The algorithm is only allowed to change values within the quantization boundaries. A smoothed value that would fall outside the quantization boundaries would be discarded. Its original value would be used instead.
The low-frequency coefficients of each X * Y transform (top-left corner of the size excluding the corner) are estimated from the DC image by JPEG XL to reduce banding further.
As the known coefficients are extended to have size, the missing coefficients are filled with zeros, starting with a known coefficient. Then it applies the inverse procedure described in Lemma 4.1 to each block so that the DC image is 2* upsampled.
The smoothed DC image is converted back into DCT coefficients using a smoothing algorithm similar to the one used on the DC image; the produced low-frequency values are then added to the encoded low-frequency coefficients.
Although JPEG XL delivers substantial improvements in artifact reduction, block boundaries and ringing can still be seen, particularly at lower qualities. Ringing artifacts are spurious signals that occur in sharp edges when high-frequency components are quantized or truncated. JPEG XL uses two loop filters to reduce their impact following the decompression process.
First, we have a smoothing convolution loop filter. During the DCT step, a sharpening filter is applied before the smoothing process to compensate for the inherent sharpness loss when smoothing an image. As a result, block boundaries are reduced in visual impact while sharp details from the original image are preserved.
By using the second loop filter, ringing can be reduced while the texture is still preserved. A non-local smoothing algorithm is applied to achieve this effect, but with enhancements to speed up the processing.
Moreover, the JPEG XL format allows the decoder to add a quantization constraint to the output of this filter to improve the detail preservation of the image: The DCT step is repeated, and the decoder ensures that the resulting coefficients do not exceed the value from the bitstream which was quantized by clamping. After applying an IDCT step, the decoder produces the final output of the filter.
In JPEG, AC coefficients are encoded in zig-zag order, which increases the sum of coordinates within the block in increasing order.
Its zig-zag order is generalized to those cases since JPEG XL has different transform sizes. Furthermore, since this order may not be optimal for a particular image, a custom order may be encoded. A Lehmer15-like code is employed to encode efficient identification permutations for this custom order, which encrypts the zig-zag order as a permutation of the zig-zag order.
In the encoding of AC coefficients, the order of encoding is followed; it keeps track of the number of non-zero coefficients in the current block, and uses this value, along with the position in the current block, to split the coefficients into multiple distributions. Whenever there are no non-zero coefficients left in the bitstream, no further values are present.
For entropy coding, legacy JPEG formats support either Huffman coding12 or Arithmetic Coding13. There are some drawbacks to both of these methods: Huffman coding is suboptimal when symbol probabilities are not exact powers of two, and Arithmetic Coding implementations are typically slow.
JPEG XL uses ANS (also called Asymmetric Numeral Systems14). This recently introduced entropy coder achieves compression ratios similar to Arithmetic Coding, while decoding is significantly faster.
ANS symbols drawn from multiple probability distributions are encoded as JPEG XL. We provide encoders with more flexibility using two techniques: distribution clustering and variable-precision distribution encoding.
Many different distributions of symbols can be included in an ANS stream. The amount of data that would have to be encoded for each of these distributions would be significant, making this a sub-optimal choice except for the longest streams. As a result, JPEG XL allows defining clusters of similar distributions, with only one histogram encoded for the whole cluster. With this method, clustering can be set up per-file instead of a fixed setting, allowing for more flexibility than fewer distributions. A move-to-front transformation is used to encode the clusters. Run-length encoding is used to minimize bitstream overhead.
User interfaces and websites are becoming increasingly image-driven. Imagery plays a vital role in user interaction, selecting topics, stories, movies, articles, etc. We create, upload, download, and reupload millions of images each day, such as on social media. With JPEG XL, providers can reduce bandwidth usage, increase download speed, and eliminate generation loss.
E-commerce websites can present higher resolution images of their products and services. A correlation has been observed between catalog image quality and sales. As a result, JPEG XL delivers high-quality images while retaining performance, vital for conversion purposes.
Many users upload their images to cloud storage applications. Depending on how they are uploaded, the images are stored either as a copy or after transcoding, either lossless or lossy. You can transcode images to more efficient formats and lower resolutions when browsing and creating timeline-style thumbnails. It is helpful to convert pictures to more efficient formats for storing and browsing.
News agencies, journalists, and users capture images, which are then published on media sites. Images can be high-resolution or thumbnail-sized, resulting in web pages containing multiple megabyte images. Webmasters with extensive collections of JPEG images should benefit from a new format to facilitate its adoption.
Animations are often used to convey emotions and increase interactivity. The vast majority of animated image sequences are encoded using the GIF file format, with a limited color palette and inefficient compression. Animations of this type are brief and play in a loop, and they can often be stored in memory. Existing aPNG, WebP, and GIF files can be used as examples of existing animations. All animations need to support transparency to be used as overlays. In browsers, users can use seeking when switching between tabs. As soon as the user returns to the tab, the animation should resume where it was.
A user's decision to download or remove a mobile application or game often depends on the download and installation size. Typically, images take up most of the total file size, and effective compression can help reduce the file size. A fast decoding rate is essential for quick loading.
Users often collect dozens of images in albums, such as vacation pictures. Photos of this type have a large resolution, such as 20-30 Megapixels. Users expect fast response times and faithful reproduction on tablets at full-screen resolution (currently around 2 Megapixels).
HDR/WCG images are needed in many applications, such as on-demand video services and gaming, to support HDR/WCG videos or enhance the user experience. For example, a user may want to store single frames (stills) from movies. There are currently no formats that can display HDR/WCG content. Such applications require a new HDR/WCG coding standard. ICC defines the format as enabling content creators to specify the rendering intent.
Cameras (medium-format) currently produce images with 100-400 MPixels. These should be opened to be viewed (at full resolution) or processed immediately. Raw (color-filter array) images can also be stored as lossless/near-lossless encodings. Images may later be 'cooked' using more advanced processing algorithms.
The printing industry widely uses CMYK color models. In addition, spot colors can be applied in additional channels. To distribute images intended for printing, high-resolution and lossless or high quality are required, as is the capability to show CMYK and possibly additional channels (for spot colors/OGV). As CMYK is generally used for interchange rather than storage or delivery, its storage will typically be lossless or near-lossless.
For now, you're free to use JPEG XL however you'd like. Due to the format's newness, support is minimal.
If you do not have enough hard drive space, you can utilize JPEG XL to store your images. JPEG XL can be used to test the performance. Await more support before going full commit!
Not yet. No browser support is enabled by default. Expect support in Summer 2022.
With JPEG XL, images are significantly better quality, compressed more efficiently, and have shorter specifications. Using software implementations, this encoding and decoding technology is designed to be computationally efficient, even on mobile devices, without additional hardware acceleration.
- Use the reference software cjxl/djxl available on GitLab
- Or convert images on jpegxl.io
JPEG recompression allows seamless migration from legacy JPEG to JPEG XL. Existing JPEG files can be converted to the newer, more compact format while saving up to 20% of their original size. The format supports the transcoding of progressive JPEGs, but the reference software has yet to implement it.
Many image viewers support JPEG XL:
Many browsers support JPEG XL behind a flag:
Not many CDNs support JPEG XL:
Some OS support JPEG XL natively, others with help:
No mobile Operating System supports JPEG XL. Chrome Canary and Firefox Nightly support viewing JPEG XL images after enabling support in the flags.
Over the years, the legacy JPEG format has been thoroughly examined, with most of its drawbacks being addressed in JPEG XL:
- DC coefficients are predicted more robustly.
- The coefficients of AC0x and AC0x are predicted using neighboring blocks.
- ANS and Binary Arithmetic Coding replace Huffman Entropy Coding
- Most commonly used ICC profiles, Huffman code tables, and quantization tables are encoded as template parameters.
- Using context modeling, we can separate entropy sources.
- In the DCT, coefficients are reordered so that more blocks have longer series of zeros at the end. In contrast to limited RLE, the index of the last non-zero coefficient is encoded explicitly.
According to research, those improvements enable sizes to be reduced by 16% on average in a corpus of 100 000 random web images. Depending on the JPEG encoder and quality settings, the savings range from 13% to 22% for larger photographic images.