More info here - https://github.com/google/pik/blob/master/README.md and https://github.com/google/pik
Some comparison to other formats here - https://wyohknott.github.io/image-formats-comparison/

Why Google added yet another image format when WebP is already available? To kick out non-Chromium browsers?

https://wyohknott.github.io/image-formats-comparison/

PIK looks terrible compared to WebP and AVIF. One should rather remove Google Analytics and other Javascript bloat to save power. :)

WebP > PIK for low bandwidth use.
Jpeg-XR > PIK for high res/high quality use. And it's ISO-standardized, too.

I doubt we will be spending time investigating this unless this is actually gains adoption by other browsers, and by web authors.

You should wait until the JPEG XL meetings have reached their course. AFAIK the PIK format joined hands with the FUIF format (by the creator of FLIF) for the selection process. Until the selection is concluded, it is premature to implement PIK only.

I have hopes that JPEG XL will include a lossless (and near-lossless) mode build by FLIF author Jon Sneyers and gralic-author, Hutter prize winner Alexander Rhatushnyak. The lossless mode has some inspiration from WebP lossless, too. The lossless mode likely includes a 2.5x faster than Lepton method for compressing and decompressing old school jpegs.

Compared to other methods (such as WebP or AV1) JEPG XL lossy compression performs better with HDR in general, and with SDR at preserving material qualities (wood, stone, fine textures, details in highly saturated color), and dark areas than previous methods. In last round of human rating experiments JPEG XL won over every other tested format and image at 1 BPP and above, and more improvements have been deployed since and some are still in the pipeline.

Lossy decompression is more than 20x faster to decompress than other modern methods (AV1).

(In reply to Jan Andre Ikenmeyer [:darkspirit] from comment #2)

https://wyohknott.github.io/image-formats-comparison/

PIK looks terrible compared to WebP and AVIF.

True for low bpp. However, wyohknott.github.io is comparing an outdated (perhaps 1.5 years old) version of jpeg xl, and should not be used for making actual comparisons.

JPEG XL's candidate lossy encoding from last summer performed well at 1.0 BPP and above. We have recently made it perform competitively down to 0.25 BPP. For some classes of images (particularly portraits and natural images) it is the technology leader at low BPP with a margin. For some other classes, such as screenshots, it is still not competitive.

Also, we made the default mode about 10x faster in compression, and greatly improved the quality of the fast mode.

Currently we are in the process to integrating FUIF and PIK in a useful way and deploying a couple of additional significant quality improvements.

(In reply to Jyrki Alakuijala from comment #6)

Compared to other methods (such as WebP or AV1) JEPG XL lossy compression performs better with HDR in general, and with SDR at preserving material qualities (wood, stone, fine textures, details in highly saturated color), and dark areas than previous methods. In last round of human rating experiments
Lossy decompression is more than 20x faster to decompress than other modern methods (AV1).

The stuff about AV1 is meaningless, it's a video codec, that isn't even properly optimized for video, much less it's still image branch-off (AVIF).

(In reply to Jyrki Alakuijala from comment #6)

I have hopes that JPEG XL will include a lossless (and near-lossless) mode build by FLIF author Jon Sneyers and gralic-author, Hutter prize winner Alexander Rhatushnyak. The lossless mode has some inspiration from WebP lossless, too. The lossless mode likely includes a 2.5x faster than Lepton method for compressing and decompressing old school jpegs.

It feels like it would be a big gobbledygook of a format (more like 3-4 in one) that no-one would want to support.

https://www.reddit.com/r/AV1/comments/cpwz1v/will_avif_be_superseded_by_jpeg_xl/ shows an independent comparison of current AVIF and PIK from the beginning of 2019.

JPEG XL candidate draft is available at: https://arxiv.org/abs/1908.03565

Design of JPEG XL and motivation behind the requirements for this codec can be better understood from this paper (with free pdf download): https://www.spiedigitallibrary.org/conference-proceedings-of-spie/11137/111370K/JPEG-XL-next-generation-image-compression-architecture-and-coding-tools/10.1117/12.2529237.full?SSO=1

The SPIE paper is not only about design and psychovisual results of JPEG XL, but discusses codec scoping topics like 'what bits-per-pixel target should we have for the next generation image codec?'

Added dev-doc-needed, as if this format ever gets implemented, documentation, BCD, and possibly other databases (hopefully by then we'll have a "file format compatibility" database) will need updating to recognize it.

Closing per bug #1240692 comment #21 & bug #1240692 comment #20 and combination of PIK with FUIF was subsumed in JPEG XL.