Skip to content

Support for reading/writing JPEG XL images

Description of the feature

JPEG XL format specifications are closing and there's already a reference encoder/decoder published. It would be nice if GIMP can read/write this new image format, which supports HDR, wide color gamut, delta encoding of image bursts, animations, alpha channels, CYMK, RAW-file data, 360° images, high-resolution images (which doesn't necessarily fit into the memory to be viewed), lossy and lossless encoding while maintaining the ability to just partly read a file and render a lower quality/resolution.

It is also possible to transcode a Jpeg into a Jpeg XL while maintaining full backward compatibility (you can fully restore the Jpeg from the Jpeg XL). The Jpeg XL decoder is even capable to enhance the quality of an ordinary Jpeg file.

The compression ratios on lossless as well on lossy compressions exceed PNG/WebP/Gif/Jpeg/Jpeg 2000 etc. by a wide margin.

Jpeg XL is also able to dynamically switch between a good compression algorithm for photos and one for graphics, can handle multiple layers with names (like TIFF supports) and can also handle palettes for the data.

Jpeg XL can also handle additional channels, like for example a channel for depth information with a different resolution and different bit depth provided by a ToF camera.

Quotes:

jonsneyers:

It may not be the best name, but it sure is better than the names of the projects it was based on: PIK and FUIF. At least if you speak Dutch. A "pik" is a penis and a "fuif" is a party, so the combination would be the "penis party" image codec. I prefer "JPEG XL".The etymology of the name "XL" is as follows: JPEG has called all its new standards since j2k something that starts with an X: XR, XT, XS (S for speed, since it is very fast and ultra-low-latency), and now XL. The L is supposed to mean Long term, since the goal is to make something that can replace the legacy JPEG and last as long as it did.

FLIF doesn't parallelize well, but that's not really because of the MA trees, but just because the whole bitstream is inherently sequential.Modular mode in JPEG XL also has MA trees, but the bitstream is organized in a way that allows parallel decode (as well as efficient cropped decode).

FLIF author here. I have been working on FUIF and JPEG XL the past two years. FUIF is based on FLIF but is better at lossy. JPEG XL is a combination of Google's PIK (~VarDCT mode) and FUIF (~Modular mode). You'll be able to mix both codecs for a single image, e.g. VarDCT for the photo parts, Modular for the non-photo parts and to encode the DC (1:8 ) in a super-progressive way.I'm very excited about JPEG XL, it's a great codec that has all the technical ingredients to replace JPEG, PNG and GIF. We are close to finalizing the bitstream and standardizing it (ISO/IEC 18181). Now let's hope it will get adoption!

Modular mode JPEG XL has MAANS (meta-adaptive ANS). It's indeed faster to decode than MANIAC, though a bit trickier to encode.

TIFF is a very hairy animal, but I'm happy to report that JPEG XL will be able to offer most of the functionality TIFF is currently used for:- multi-layer (overlays), with named layers

  • high bit depth
  • metadata (the JXL file format will support not just Exif/XMP but also JUMBF, which gives you all kinds of already-standardized metadata, e.g. for 360)
  • arbitrary extra channels All that with state-of-the-art compression, both lossy and lossless.

janwas:

Good news: the reference software (http://gitlab.com/wg1/jpeg-xl) can decode about 50 Megapixels/s on a single Skylake core, with 3.1-3.7x speedup on 4 cores.Encoding throughput is configurable from ~1 MP/s to about 50 per core. That's somewhat slower than JPEG, but can be faster with multiple cores. Yes indeed, for the lossless mode (based on tech by the same author) we're seeing about 45-82% of GIF size, and 60-80% of (A)PNG depending on content.

Posted on: https://news.ycombinator.com/item?id=22261612

Use cases

all of them.