Bug 1538686 (PIK)

Implement support for PIK image file format

NEW
Unassigned

Status

()

enhancement
P5
major
28 days ago
27 days ago

People

(Reporter: Virtual, Unassigned)

Tracking

({feature, nightly-community})

Trunk
Points:
---
Bug Flags:
firefox-backlog ?

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Has Regression Range: --- → irrelevant
Has STR: --- → irrelevant

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. :)

See Also: → AVIF

Comment 3

28 days ago

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.

Priority: -- → P5

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.

Comment 6

27 days ago

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).

Comment 7

27 days ago

(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.

Comment 8

27 days ago

(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.

You need to log in before you can comment on or make changes to this bug.