Image format comparison

This page presents image format features and compares image codecs.

What are image formats?

A digital image is a two-dimensional grid of pixels and can be stored in a file, using an image format. There are three main categories of image formats:

• Lossless (compressed without loss): the pixel values are encoded to reduce the file size needed to store typical images without altering them. While this is often useful in formats dedicated to editing workflows, for the transmission use case typically "lossy" compression provides a better experience.
  Example: PNG
• Lossy (compressed with loss): the pixel values are encoded to reduce the file size needed to store typical images. The encoder usually has a quality setting that allows pixel values to be changed in order to further reduce the encoded file size, increasing the visual distortion of the image once decoded.
  Examples: JPEG
• Raw (uncompressed): the pixel values are stored without compression and without loss, one after another. This usually leads to huge files that are impractical for storage and transmission but are fast to read and especially to write.
  Example: uncompressed BMP

Further reading: Image file format, Lossless compression, Lossy compression (Wikipedia)

Codec

A codec is the piece of software, called library, that is used to encode or decode images of a given format. There may exist multiple codecs for the same image format.
Example: libpng for PNG

Note that some repacking tools exist to further compress already encoded image files or mixed media without loss. They are not presented further here because they are seen as transport-level compression schemes rather than image formats.
Examples: brunsli, brotli

Features of image formats

On top of the basic capacity of storing pixels in a universally specified way, image formats may possess other features:

• Transparency ("alpha"): each pixel is either fully transparent of fully opaque. Partial transparency is called translucency.
  Example: GIF (supports transparency), PNG (supports translucency)
• Animation: the image moves over time.
  Example: GIF
• Progressive: the image is encoded in a way that at least one lower resolution of the image can be decoded and displayed before the full image file is available. This can be used to render a blurry preview of a large image before it is fully received from a distant server, or to show an icon of a local image without decoding the full file, saving resources. Some drawbacks are potentially worse compression rate, increased processing, memory and battery usage due to the multiple renders and buffers. Storing and serving a scaled down version of the image next to the original one are alternatives to that feature.
  Example: JPEG
• Incremental: parts of the image can be decoded and displayed before the full image file is available. This is usually in row scan order. Some drawbacks are potentially increased processing, memory and battery usage.
  Example: WebP
• Chroma subsampling (4:2:2, 4:2:0): in some color spaces such as JPEG's YCbCr, dropping some pixel values in the chroma planes allows for a better compression ratio with minimal visual distortion, because the human eye gives more importance to the luma plane (the "greyscale" version of an image).
  • No chroma subsampling (4:4:4): there are as many values in each chroma plane as in the luma plane.
• High bit depth: RGB pixels traditionnally have a depth of 8 bits, meaning the value in each plane among red, green and blue is between 0 and 255 inclusive. Some formats offer a higher resolution per pixel.
  Example: PNG (up to 16-bit)
• Multithreading: using multiple threads at encoding and/or at decoding can speed the process up. While this is more related to software implementations, some image formats may have been designed to permit or facilitate it.

Further reading: Image file format, Transparency, Chroma subsampling (Wikipedia), Image file type and format guide (Mozilla), Progressive and incremental image decoding demo

How to compare image formats?

There are multiple domains where image file formats and software implementations compete:

• File size (compression ratio): for the same image, the encoded file size may vary. When divided by the number of pixels, it is referred to as the compression ratio or bits-per-pixel.
• Visual distortion: lossy compression generates artifacts. The quality setting of an encoder will tune the trade-off between the fidelity of the decoded image compared to the original and the file size reduction. This is irrelevant for lossless formats.
• Encoding duration: the time spent compressing the original image into an encoded file size is often controlled by the effort setting of an encoder. It is sometimes called speed, preset or method. It is a trade-off between encoding latency and file size reduction. It makes sense to compare codecs on their default effort value because most users do not tune that setting.
• Decoding duration: the time spent decompressing the encoded file into pixels that can be directly rendered.
• Feature completeness: depending on the use case, the need for specific features may orientate the choice of a format.

Over the internet, there could be several "best" formats: servers may choose to send images in different formats depending on the end device. The decision is based on whether the format is supported by the user's operating system, browser or app, the bandwidth, the screen resolution etc.

Estimating visual distortion

There are two main ways of getting a sense on how distorted is a decoded image compared to the original asset (for lossy compression only):

• Subjective evaluation: people look at images and rate them. This is a lengthy and tedious process. The results are non-deterministic because they depend on the precise viewing conditions and device, the person rating, their distance to the screen, their mental state at that time etc. This process can only be used if a statistically large enough sample is evaluated.
• Objective evaluation: an algorithm called distortion metric grades the loss between the original image and the decoded one. Our default view matches images based on SSIM, which is the most widely used metric in the scientific community. To try and be more fair, when JPEG XL images are included in the comparison we include Butteraugli metric, which JPEG XL codec is based on.

Choice of dataset

Even if distortion evaluation of lossy compression was a settled matter, the open question of the corpus choice remains for both lossy and lossless compression. A lot of image datasets exist out there but assuming its license is permissive enough, there is no guarantee that a dataset:

• exhaustively represents the use case, meaning it contains at least one image of each kind that the use case covers (image dimensions, bit depth, content etc.),
• shares the same distribution, meaning it contains the same proportion of each image kind as the use case.

With all that said, one can still get an approximation of the overall performance of a codec compared to another. See the dedicated section "Comparison of image codecs".

Comparison of image codecs

Comparisons of multiple image codecs are linked below. The presets in the left navigation bar contain more codecs, more effort encoding settings for the same codecs, or different comparison criteria.
The Codec-Compare framework matches pairs of encoded images based on some criteria, for example the same source image and a similar amount of compression artifacts. It then aggregates the ratios given by each pair on some other dimensions such as file size, compression and decompression timings. Matching pairs ensures the selected data makes sense before aggregation. Unmatched data may be hidden by this selection process but should not be compared anyway.
See the section "How to compare image formats?" above for an explanation on the chosen comparison criteria.

All encodes and decodes are single-threaded. All metadata was stripped from the original images to only compare the compression rate of pixel values and mandatory format header sizes.

Verification: Verification is probably the MOST important part of any codec comparison when evaluating quality and performance. You, the reader, should be able to reproduce all of the results. All of the matched pairs in the Codec-Compare framework have the version of the codec and the command line, so you can independently verify the results.

Latest comparisons

• 2025/02/18 - lossy: AVIF, JPEG XL, WebP (photo CLIC dataset)
  2025/02/18 - lossy: AVIF, AVIF_AVM, JPEG 2000, JPEG XL, MozJPEG, WebP (photo CLIC dataset)
  2025/02/18 - lossy: AVIF, AVIF_AVM, JPEG 2000, JPEG XL, MozJPEG, WebP (photo CLIC dataset, Web bits-per-pixel range)
• 2025/02/17 - lossless: JPEG XL, WebP, WebP 2 (4:4:4, web-images dataset)
  2025/02/17 - lossless: AVIF, AVIF^YCgCo-Re, AVIF_AVM^YCgCo-Re, FFV1, JPEG 2000, JPEG XL, WebP, WebP 2 (4:4:4, web-images dataset)
  2025/02/17 - lossless: AVIF, AVIF^YCgCo-Re, AVIF_AVM^YCgCo-Re, FFV1, JPEG 2000, JPEG XL, WebP, WebP 2 (4:4:4, camera-captured assets from the web-images dataset)
• 2024/11/26 - lossy: AVIF^TUNE_SSIM vs AVIF^{TUNE_SSIMULACRA2} (4:4:4, photo CLIC dataset)
  2024/11/26 - lossy: AVIF_{AOM 3.10}, AVIF_{AOM 3.11}^TUNE_SSIM, AVIF_{AOM 3.11}^{TUNE_SSIMULACRA2}, MozJPEG, WebP (4:2:0, photo CLIC dataset)
  2024/11/26 - lossy: AVIF_{AOM 3.10}, AVIF_{AOM 3.11}^TUNE_SSIM, AVIF_{AOM 3.11}^{TUNE_SSIMULACRA2}, JPEG XL, MozJPEG (4:4:4, photo CLIC dataset)
• 2024/09/04 - lossy: AVIF, JPEG XL (default effort, 4:4:4, photo CLIC dataset)
• 2024/09/03 - lossy: jpegli, MozJPEG, sJPEG, TurboJPEG, WebP (4:2:0, photo CLIC dataset)
  2024/09/03 - lossy: jpegli, MozJPEG, sJPEG, TurboJPEG (4:4:4, photo CLIC dataset)
• 2024/08/29 - lossless: AVIF, JPEG XL, WebP, WebP 2 (all 4:4:4, web-images dataset)