WebP saving options clarification

[HiKiyos]

To Pierre — thank you for your hard work! I’ve been using XnView for more than a decade now and it’s been great
I’ve recently switched to XnView MP, so my questions are gonna be about that.

Question 1. Do “Filter strength” and “Filter sharpness” values regulate the strength of the deblocking filter (-f and -sharpness options in cwebp), or some other filter? The answer might seem obvious, but I’ve decided to ask anyway, just to be sure.

Question 2. WebP format supports both lossless and lossy alpha channel compression. So when saving with alpha channel present in the source, will that channel be saved losslessly (alpha_q = 100) or with whatever compression factor I’ve chosen for RGB channels (alpha_q = q)?

[xnview]

Question 1. Do “Filter strength” and “Filter sharpness” values regulate the strength of the deblocking filter (-f and -sharpness options in cwebp), or some other filter? The answer might seem obvious, but I’ve decided to ask anyway, just to be sure.

yes, same as cwebp

Question 2. WebP format supports both lossless and lossy alpha channel compression. So when saving with alpha channel present in the source, will that channel be saved losslessly (alpha_q = 100) or with whatever compression factor I’ve chosen for RGB channels (alpha_q = q)?

Currently, same quality is used for RGB & alpha

[HiKiyos]

Thank you!

[Tapio]

yes, same as cwebp

BTW do you think with jpegli webp will become more or less obsolete?

[HiKiyos]

BTW do you think with jpegli webp will become more or less obsolete?

This is extremely off-topic, but I wanted to answer anyway. Mods, please forgive me

Jpegli does not give JPEG any magical powers like animation or alpha transparency support, or even lossless compression. So WebP is here to stay at least for those applications, I think.

In lossy comparisons that I did recently, WebP showed way less artifacts than JPEG (both libjpeg and Jpegli), but blurred out the details a lot. There is no clear winner here. JPEG, being 20 years older than WebP, is still going strong with all the enhancements it received.

[Kadet]

BTW do you think with jpegli webp will become more or less obsolete?

This is extremely off-topic, but I wanted to answer anyway. Mods, please forgive me

Jpegli does not give JPEG any magical powers like animation or alpha transparency support, or even lossless compression. So WebP is here to stay at least for those applications, I think.

In lossy comparisons that I did recently, WebP showed way less artifacts than JPEG (both libjpeg and Jpegli), but blurred out the details a lot. There is no clear winner here. JPEG, being 20 years older than WebP, is still going strong with all the enhancements it received.

WEBP, with its limitations, is a dead end. Currently, it is slowly being replaced by the AVIF format on websites. And just around the corner is the new, great JPEG XL format.

New libjpeg-turbo add new future and now can do lossless JPEG files
"We support 8-bit and 12-bit data precision in lossy mode and 2-bit through
16-bit data precision in lossless mode."

[HiKiyos]

WEBP, with its limitations, is a dead end. Currently, it is slowly being replaced by the AVIF format on websites.

AVIF is based on AV1 and destroys details even more than WebP (but can kinda bring former shadows of them back with grain synthesis), so I wouldn’t be so sure about the full replacement.

And just around the corner is the new, great JPEG XL format.

JPEG XL is already here and it’s good. However, Google Chrome’s market share is overwhelmingly large. And Google is against JPEG XL, for its own nefarious reasons, I’m sure. Only Apple has its full support in Safari, but Apple always thinks different. So the future is bleak, at least in the web space.

New libjpeg-turbo add new future and now can do lossless JPEG files
"We support 8-bit and 12-bit data precision in lossy mode and 2-bit through
16-bit data precision in lossless mode."

Where did you find this info?
The thing is, regular old JPEG’s internal structure is already set in stone and known by all decoders, and implementing something different will bring significant incompatibility. For example, lossless compression (1x1 DCT) was technically introduced in libjpeg v9 back in 2013 as a “proprietary incompatible extension”, and I’ve yet to see somebody actually using it.

[Kadet]

WEBP, with its limitations, is a dead end. Currently, it is slowly being replaced by the AVIF format on websites.

AVIF is based on AV1 and destroys details even more than WebP (but can kinda bring former shadows of them back with grain synthesis), so I wouldn’t be so sure about the full replacement.

Some websites want images so small as it's possible with accepted visual quality - for this you must set very low quality settings and as I read some tests AVIF is better not only from WEBP but from JPEG XL too. I personally for my website about some tv serial using big high fidelity images JPEG XL with JPEG(li) backup.

And just around the corner is the new, great JPEG XL format.

JPEG XL is already here and it’s good. However, Google Chrome’s market share is overwhelmingly large. And Google is against JPEG XL, for its own nefarious reasons, I’m sure. Only Apple has its full support in Safari, but Apple always thinks different. So the future is bleak, at least in the web space.

Precisely saying Google Chrome team is against JXL, but IMO not so long in the future they will be must add JXL to browser. Soon JXL will be in regular Firefox version. The Google Chrome team is just embarrassing itself by not adding this format to the browser. The voices of condemnation will only grow.

New libjpeg-turbo add new future and now can do lossless JPEG files
"We support 8-bit and 12-bit data precision in lossy mode and 2-bit through
16-bit data precision in lossless mode."

Where did you find this info?
The thing is, regular old JPEG’s internal structure is already set in stone and known by all decoders, and implementing something different will bring significant incompatibility. For example, lossless compression (1x1 DCT) was technically introduced in libjpeg v9 back in 2013 as a “proprietary incompatible extension”, and I’ve yet to see somebody actually using it.

https://github.com/libjpeg-turbo/libjpe ... ibjpeg.txt
Except it doesn't matter anymore. The JPEG format will not surpass what JXL offers, and its time is coming to an end. Probably no one will add either lossless or 12-bit encoding to decoders.