Feature request: -q 100 option for Lossless WebP

[abobong]

Note: This is not a bug report. This is a request.

Hi,

This is a follow-up to my old post: viewtopic.php?t=48782

As I noted in my correction there, that old size difference was caused by metadata, not a bug. But while testing that, one separate thing still stands out to me.

Test image: 220x228 pixels, a photo. (File attached: test.jpg)

Tool: cwebp version 1.6.0. Only one version used in this test.

I changed only the -q value. Nothing else changed.

test.jpg

Command Result size Transform used
cwebp -lossless -m 6 -q 100 81,378 bytes Predictor
cwebp -lossless -m 6 -q 75 82,904 bytes Subtract Green
cwebp -lossless -m 6 (no -q) 82,904 bytes Subtract Green
XnView MP, "Lossless, Effort 6 , Strip Metadata" 82,904 bytes Subtract Green

All results have the same pixels. No quality loss in any case.

My conclusion: Only -q 100 picks the Predictor transform here, which is smaller. Below 100, cwebp always picks Subtract Green instead, which is 1.9% larger. XnView MP's output matches -q 75 exactly, byte for byte. XnView MP's "Effort" setting changes only -m. It never changes -q. So XnView MP never reaches the best result — even on an ordinary photo, not just edge cases.

My request: Please add an option to send -q 100 in Lossless mode. This should bring the compression ratio close to what XnView MP 1.5.5 achieved. In Lossless mode, -q does not affect image quality or pixel data — it only affects encode time. So this should be a safe change that only makes files smaller.

Attached: XnView MP, Lossless, Effort 6 , Strip Metadata.webp
(The actual XnView MP output file referenced in the table above, 82,904 bytes, metadata stripped.)

Capu038.png

Reference:
[-q] default is documented here: https://developers.google.com/speed/webp/docs/cwebp
("The default is 75... In case of lossless compression, maximum compression is achieved by using a value of 100.")