JPEG XL vs. AVIF

[fabiorug]

yes, it's good at preserving faces (not at lower modular modes), but art, body this type of pictures isn't very optimized.
Others than that it has many settings that produce similar images:
JPEG XL
d 0.021, d 0.164, d 3.164, d. 9.6, modular N (near lossless)

[DZgas]

It's a pity that JpegXL has the same problems as the any Jpeg.

Original | JpegXL 10 Kb | AVIF 10 Kb.

[spaceship9876]

Do we know whether camera manufacturers and smartphones manufacturers plan on releasing new models that can take photos natively in Jpeg XL?

[Jyrki Alakuijala]

Which version of JPEG XL you use? Do you compile it from gitlab before running experiments, or do you use an older version? We had non-optimal integral transform selection in the encoder that I fixed very recently. The most recent code should give less DCT artefacts.

[DZgas]

"Everyone should switch to JpegXL" - Well said... I don't know who will support JpegXL.
AVIF supported from The Alliance for Open Media.

In the last post I write my JpegXL version, is code from gitlab.
I don't want to compile it, heh... I get cjpegXL here https://forum.doom9.org/showthread.php?t=174300&page=15

[fabiorug]

Honestly I like -d 4.1 -s 9 version 7a2f362a Jpeg XL.
Someone compiled in a discord server the build.
I wouldn't use lower values and I'd prefer if the same quality as -d 4.1 -s 9 could be achieved with more speed, less effort.
I understood modular is better to encode text and objects and
whatever settings you use to re encode jpeg the quality would be serious damaged.
There is also the jpeg xl recompressor (is it the right term ? ) who is the default option to convert jpeg.
Even d 0.616 speed 3 produces better quality than modular near lossless in some cases with false png.
Also jpeg xl sometimes whitens photo to mantain the visual quality that also because Jpeg XL includes XYZ color space.

[Jyrki Alakuijala]

Honestly I like -d 4.1 -s 9 version 7a2f362a Jpeg XL.
Someone compiled in a discord server the build.
I wouldn't use lower values and I'd prefer if the same quality as -d 4.1 -s 9 could be achieved with more speed, less effort.

-d 4.1 means that you accept errors that are 4.1x what I consider just-noticeable-error.

at -d 1.0 you would get exactly what I consider just-noticeable-errors.

I understood modular is better to encode text and objects and
whatever settings you use to re encode jpeg the quality would be serious damaged.
There is also the jpeg xl recompressor (is it the right term ? ) who is the default option to convert jpeg.

Yes, three main modes: VarDCT, Modular and lossless JPEG recompression. Unlike every other modern codec, all of these modes support progressive decoding.

Even d 0.616 speed 3 produces better quality than modular near lossless in some cases with false png.
Also jpeg xl sometimes whitens photo to mantain the visual quality that also because Jpeg XL includes XYZ color space.

We use a colorspace similar to XYZ and Lab, but not strictly similar. We call it XYB.

The whitening issues seems like it needs debugging. Could you file an issue to JPEG XL repo?

(It could be because some image viewers use both the gamma and the ICC value of the image, some ignore the gamma value when the ICC profile is there.)

[fabiorug]

ok thanks for your answer. I didn't know about the color space. Speed 3 -d 3.99 is amazing for compression, don't know how to explain, it estimates not only noise but also the blocking of the noise. Speed 6 -d 3.75 is probably better.

[dado023]

fyi, GIMP now supports working with AVIF, import/export:

https://www.gimp.org/news/2020/10/07/gimp-2-10-22-released/

[Jarek]

If everybody switch to AVIF, convincing to switch again to JPEG XL might be impossible task ... will JPEG XL be frozen this year?

Jpeg XL is not frozen yet. (Other than the jpeg repacking part of it.) Our freezing schedule is end of August 2020. Before that it is not a good idea to integrate for other than testing use.

[Jarek]

ps. Entertaining AVIF vs JPEG XL fight: https://www.reddit.com/r/AV1/comment..._image_format/
Recent Jon Sneyers slides (from 3rd October writing "Next week: hopefully FDIS stage (Final DIS)"...?): https://docs.google.com/presentation...b4791a110_0_20

[Jyrki Alakuijala]

If everybody switch to AVIF, convincing to switch again to JPEG XL might be impossible task ... will JPEG XL be frozen this year?

The authors will announce a bit stream freeze very soon now.

The completed ISO process need more time -- just like it did for the original JPEG.

[Jyrki Alakuijala]

​

Next week: hopefully FDIS stage

FDIS will happen in January 2021. We had delivered a too big last minute simplification to proceed right now to FDIS.

Particularly, we had replaced brunsli with a similar system that relies on the internals of JPEG XL VarDCT mode. This reduces decoder size by 20 %, reflected also in the specification size -- allowing it to be just below 100 pages right now.

[fabiorug]

I have a few doubts about the reference encoder.
To reencode jpeg with lossy vardct is there a better metric than
https://live.ece.utexas.edu/research/Quality/VIF.htm
To me, VIF looks very interesting. But is there a way to know if people can distinguish VIF other than butteraugli d 1.0, improvements of encoders, finalization of ISO bitstream and subjective testings?
for PNG is better and there are far better methods like for example butteraugli, JPG is recommended to use brunsli?

[fabiorug]

Sorry for the secure shield png icons, I didn't add it, maybe grammarly attached it.
My photo even at -d 4.83 -s 3 has horrible artifacts. Signs that jpeg xl is working good. It looks like aliasing masked by some ringing plus stretching of some faces.
Seeing -d 4.83 -s 3 I can notice at -d 1 some things are removed like
contours.

[Jyrki Alakuijala]

Is there a method to predict the quality of a jpeg better than VIF, that does similar things?

My understanding is that DSSIM in general is the best metric (according to TID2013 Spearman rank-order correlation coefficient).

butteraugli is not far. Butteraugli 3rd norm is terrible in explaining the 'exotic' category of TID2013 errors. (...but VIF is even worse there.)

Butteraugli '3rd norm' correlates best in the 'New' and 'Color' categories of TID2013. The 'Simple', 'New' and 'Color' categories likely respond closest to the degradations that happen in image compression.

I suspect DSSIM may be originally fitted to TID2008 or TID2013, and that origin may explain its good results on TID2013. Butteraugli was fitted to an independent reference corpus of degradations mostly like TID2013 degradations in Simple/New/Color categories.

​

[fabiorug]

Jon sneyers mentioned it at image ready (auto encoding). Only a person works on these features or there is a team?

[fabiorug]

Why -g -q 50 -s 7 doesn't use lossy modular but lossless modular? The answer is below.

[fabiorug]

Personally I would put good looking image at -s 4 -d 1.79 and file size smaller than the original as good image.
But with limits flags jxl the auto encoding won't work and it won't re-encode anything, it would return NULL.
Maybe is bit too extreme as a setting. -s 6 -q 55.4 Until -s 7 -q 77.6 I cannot see a difference, it looks transparent.
But to look good it needs at least -s 3 -q 99.6

[fabiorug]

What q equivalent is for -d 6.138 -s 3?

[Jyrki Alakuijala]

But I want to ask a question. What q is -d 6.138 -s 3?

We will change the encoder so that -d and -q are just ways to control the quality of the resulting image, and one will need to choose with a separate flag between VarDCT and Modular modes.

[fabiorug]

And also how auto encoder if it works with jpg can establish if it the case to re encode less as possible because the image was compressed more than one time, or can be re encode with -d 6.138 -s 3 or it looks good even with more filtering (patches, loop filter etc.) for example recompressed at good quality -d 1 -s 9 ?
Do you need to establish/set a speed? for example auto encoder default speed 7.
Does it establish/computer a custom butteraugli distance for the photo?
Does it work for jpg?
I know we need to wait next year to have those things working properly.
But at least how is the accuracy, Jon Sneyers is sure to implement auto encoder? Will work only on default (7° speed)? Will have a flag or be present in the reference encoder? Does it adds more size to the cjpeg binary, it needs more dependencies or metrics?

[fabiorug]

TWO SETTINGS
-q 74.59 -s 7
(d 2.387)
Now I understand why jpg encoding isn't enabled by default, it greatly reduces image quality especialy with these settings,
it makes image looking like a older VHS. This is about FLIF size
Or speed 8 -q 79.19 -s 8 d 1.973

[Jyrki Alakuijala]

-q 74.59 -s 7
(d 2.387)
Now I understand why jpg encoding isn't enabled by default, it greatly reduces image quality especialy with these settings, it makes image looking like a older VHS.
This is FLIF size settings.
Or speed 8
-q 79.19 -s 8
d 1.973

What is your viewing distance (in pixels of the image) ?

I consider d1.0 a good level from a viewing distance of 1000 pixels.

[fabiorug]

if I compress in this way it will make things more beautiful/less stiffy, even at -d 1 I can see women looking more sportive like a basketball player and something at s 9 is worse so even me, I like more s 7.

[DZgas]

The few months have passed...
If you look from far - jpegxl is looks better. Good progress.

12 Kb
Original | JpegXL | AVIF

[Jyrki Alakuijala]

The few months have passed...
If you look from far - jpegxl is looks better. Good progress.

12 Kb
Original | JpegXL | AVIF

What command line do you use to get these results? (It doesn't look like the results I see. It looks like gaborish and adaptive reconstruction might be off.)

You'll get slightly better results if you use the latest encoder that creates also 64x64, 32x64, and 64x32 DCTs.

[dado023]

The few months have passed...
If you look from far - jpegxl is looks better. Good progress.

12 Kb
Original | JpegXL | AVIF

In the png you attached, AVIF(far right) looks better to me, even the word is readable.

[Jyrki Alakuijala]

In the png you attached, AVIF(far right) looks better to me, even the word is readable.

I agree with that. Currently AVIF tends to look better when compressing an image down to 10-20 kB. At normal compression rates however JPEG XL tends to win. The next update will improve the filtering in JPEG XL and add the 64x64 DCT, which both improve performance at low bitrates. Still it will be worse than AVIF there, but less.

AVIF is willing to compromise the middle frequencies but keep high frequencies. JPEG XL spends a lot of bits on low and middle frequencies, but then there is less left for high frequencies.

In this example the post-processing filtering of AVIF is left on, but for some reason all the filtering for JPEG XL's is turned off. I consider it is better to compare both with filtering off or filtering on, not some mixture.

If you turn off gaborish, you will get less high frequencies than normally. Things get blurry or more quantized as the stock quantization matrices are optimized with gaborish on. Turning off gaborish increases block artefacts. Turning off gaborish reduces efficiency of further filtering.

If you turn of the rest of the filtering, you will see more ringing and more block artefacts.

Consider running cjpegxl without additional flags, only --distance.

[DZgas]

What command line do you use to get these results? (It doesn't look like the results I see. It looks like gaborish and adaptive reconstruction might be off.)

Consider running cjpegxl without additional flags, only --distance.

I used cjpegXL 0.0.1-c8ce59f8 (13 Oct) and commands only: --distance 7 --speed 9

I think it's good that "JPEG XL spends a lot of bits on low and middle frequencies, but then there is less left for high frequencies."
This is best for archiving photos, because AVIF just erases very large details.