cwebp lossy VP8 sourced from same WebP Lossless vs. PNG gave different output?

[MasterInQuestion]

    cwebp -mt -z 9 "cwebp-lossy-in.png" -o "cwebp-lossy-in.webp"
# ^ Input WebP Lossless reference. Verified identical as the PNG.
    cwebp -mt -m 6 -q 92 "cwebp-lossy-in.webp" -o "q92x.webp"
    cwebp -mt -m 6 -q 92 "cwebp-lossy-in.png" -o "q92.webp"
    .
    The output differs.
    Using FFmpeg to output equivalently always gave "q92.webp".
    (FFmpeg decodes the input to raw data first)

    Additionally tested WebP 1.2.2, 1.3.2, 1.4.0, 1.5.0 (besides current 1.6.0):
    All gave identical result (of "q92").

    Another thing of interest might be:

> cwebp -mt -m 6 -q 92 "cwebp-lossy-in.png" -o "q92.webp"
Dimension: 720 x 576
Output:    40472 bytes Y-U-V-All-PSNR 48.78 49.91 49.54   49.07 dB
block count:  intra4:       1291  (79.69%)
              intra16:       329  (20.31%)
              skipped:         6  (0.37%)
bytes used:  header:            344  (0.8%)
             mode-partition:   5518  (13.6%)
 Residuals bytes  |segment 1|segment 2|segment 3|segment 4|  total
    macroblocks:  |       6%|      34%|      20%|      40%|    1620
      quantizer:  |      10 |       9 |       6 |       4 |
   filter level:  |       3 |       2 |       0 |       0 |
> cwebp -mt -m 6 -q 91.5 "cwebp-lossy-in.png" -o "q91.5.webp"
Output:    39798 bytes Y-U-V-All-PSNR 48.65 49.67 49.33   48.91 dB
block count:  intra4:       1327  (81.91%)
              intra16:       293  (18.09%)
              skipped:         5  (0.31%)
bytes used:  header:            344  (0.9%)
             mode-partition:   5899  (14.8%)
 Residuals bytes  |segment 1|segment 2|segment 3|segment 4|  total
    macroblocks:  |       6%|      34%|      20%|      40%|    1620
      quantizer:  |      10 |       9 |       7 |       5 |
   filter level:  |       3 |      57 |       0 |       0 |
> cwebp -mt -m 6 -q 91 "cwebp-lossy-in.png" -o "q91.webp"
Output:    39108 bytes Y-U-V-All-PSNR 48.36 49.37 49.12   48.63 dB
block count:  intra4:       1282  (79.14%)
              intra16:       338  (20.86%)
              skipped:         7  (0.43%)
bytes used:  header:            372  (1.0%)
             mode-partition:   5693  (14.6%)
 Residuals bytes  |segment 1|segment 2|segment 3|segment 4|  total
    macroblocks:  |       6%|      34%|      20%|      40%|    1620
      quantizer:  |      11 |      10 |       7 |       5 |
   filter level:  |       3 |      26 |       0 |       0 |

    .
    The "q91.5" though of higher PSNR: but visually apparently worse. (for blurriness)
    This also demonstrates that very subtle difference in quality factor:
    Can cause great visual difference in lossy VP8.

    Stepping the "-q" by 0.1, it's also noted that:
    Not every different "-q" would give different output.
    (e.g "-q" 91.5 .. 91.8 may output identically)
    .
    It would be sensible to reflect the effective "-q" range for every lossy encode:
    So to aid further quality fine-tune.

[MasterInQuestion]

    Unsure if the same issue is also the cause of:
    Lossless re-encoding of "-near_lossless" input, may occasionally give different output (size-wise).
    https://github.com/MasterInQuestion/attach/commit/401c58fc3a56d265feadda567f02d79de93ff10c#commitcomment-140288331

[MasterInQuestion]

    I wonder the exact procedure of "-near_lossless":
    Is it exactly mere pre-filter of input, before then Lossless encoding?
    Or somehow involved in the Lossless process self?

    For the 1st case, later Lossless re-encoding shouldn't cause any difference.

    ----

    Note I never meant to repeatedly apply "-near_lossless".
    The issue described is:
    Complete Lossless (no "-near_lossless", or "-near_lossless 100") re-encoding, of "-near_lossless" processed input:
    May at times output differently (size-wise).

[jzern]

    Near lossless is applied as quantization of the residual:
    https://chromium.googlesource.com/webm/libwebp/+/refs/tags/v1.6.0/src/enc/predictor_enc.c#168

    So applying it repeatedly can continue to degrade the source, if that was the question.

[MasterInQuestion]

    Seems like it's the 2nd case (involved in the Lossless process self).
    The "-near_lossless" also has another absurdity:
    Its output can at times be bigger than true complete Lossless.

    Would it be possible to address it without effectively encoding twice?

[vrabaud]

No. We have noticed it too and it affects less than 5% of the images in our benchmarks. It's unfortunate but it is hard to predict. Just like sometimes lossless can compress images better than lossy.

[MasterInQuestion]

    Maybe it's sensible to automate the double-compression attempt, for "-z 9" (maximum compression) at least.

    As for "lossless can compress images better than lossy":
    It's mostly about the compression strategy chosen.
    I find currently all lossy algorithms, seem to be designed in the wrong way:
    Unjustifiably creating noise in output, that actually went against the theoretical entropy.

    On predicting the near lossless:
    I believe when the processed result had more colors than original: it wouldn't be beneficial?
    (unverified wild guess)

[vrabaud]

    Your first instruction needs "-lossless -exact" to make sure "cwebp-lossy-in.webp" is the same.
    Still, after doing so; I can replicate your error.

    I created: https://g-issues.webmproject.org/issues/432241412
[[
= Lossy compression from WebP Lossless vs. PNG output differently =

[ vrabaud@google.com @ CE 2025-07-16 16:07:41 UTC:
https://issues.webmproject.org/issues/432241412#comment1
    First thought:
    Lossless compression uses its own logic to get YUV:
    https://chromium.googlesource.com/webm/libwebp/+/refs/tags/v1.6.0/src/dec/vp8l_dec.c#686 ("WebPConvertARGBToUV")
    .
    While "imageio" ends up calling:
    https://chromium.googlesource.com/webm/libwebp/+/refs/tags/v1.6.0/src/enc/picture_csp_enc.c#579 ("WebPConvertRGBA32ToUV")

    The averaging on 4 pixels seems to be more accurate in the lossy case.

    Pending changes:
    Have lossless use ImportYUVAFromRGB
    https://chromium-review.googlesource.com/c/webm/libwebp/+/6879823
    .
    There was a duplicated functionality with a lower quality, which could lead to:
    Decoded lossless WebP to YUV being different, from lossless WebP to PNG to YUV.
    The rescaler is not using it yet. ]

----

[ jzern@google.com @ CE 2025-07-16 23:50:29 UTC:
https://issues.webmproject.org/issues/432241412#comment3
    The approximation is documented:
    https://chromium.googlesource.com/webm/libwebp/+/refs/tags/v1.6.0/src/dsp/yuv.c#156
    ("Approximated average-of-four. But it's an acceptable diff.")
    ; came in with:
    @ 2012-08-03T22:41:01Z
    Add support for ARGB -> YUVA conversion for Lossless decoder
    https://github.com/webmproject/libwebp/commit/43b0d6107aef709b1db362d3641691b36e29a49a

    It's likely we can change this to "WebPConvertRGBA32ToUV", if that's the source of the difference. ]
]]

[jzern]

I created https://g-issues.webmproject.org/issues/432241412

That's https://issues.webmproject.org/432241412.

[MasterInQuestion]

    The canonical seems to be:
    https://issues.webmproject.org/issues/432241412
    (else 2 still redirect via HTTP 302)

    "-z" already implied "-lossless".
    "cwebp-lossy-in.png" is RGB (no Alpha), so "-exact" shouldn't differ.
    [ "-exact" related: https://github.com/MasterInQuestion/talk/discussions/51#discussioncomment-13547990 ]

[MasterInQuestion]

    Regarding YUV <-> RGB conversion.
    I also noted that `cwebp` on different architectures (e.g. "windows-x64" vs. "linux-aarch64"):
    May give different conversion result.
    E.g. cwebp -mt -z 9 "?.jpg" -o "_.webp"
    .
    The output image may visually differ. (typically subtly)

[jzern]

    Using JPEG as source introduces another variable: the decoding of that on each platform.
    If you have an example using PNG or PPM, it might be worth looking into.
    Also check whether "-noasm" differs on each.

[MasterInQuestion]

    Interesting view.
    I indeed noted that the decoding of the very JPEG, may subtly differ in different implementations.

[MasterInQuestion]

    One thing more that I wonder, what was the exact cause of this rather exceptional size difference?
    .
https://github.com/MasterInQuestion/attach/commit/401c58fc3a56d265feadda567f02d79de93ff10c#commitcomment-140288331
    “Actually there seems to be little difference, across various WebP versions recent years.
    Generally. But do caveat fringe cases alike:
    https://github.com/MasterInQuestion/attach/raw/main/community/community/147189/mandarin.webp
    .
    Where "-z 9" of which in WebP 1.4.0 / 1.5.0 had rather obvious difference:
    187,354 B vs. 136,892 B”

[vrabaud]

    I'm glad there was a big gain :)
    We've almost squeezed out everything we could from the lossless format as it is.
    Any change we bring can unfortunately worsen some images, but we are trying to have a better change overall.

    Here, the entropy image (which is used to compute the predictor and color transform images) had actually a size, that was a fixed subsample from the original size.
    Though the format allows for a range of subsampling:
    Trying them all was not tried, because it usually does not help much.

    But in the case of big images that are simple:
    A small entropy image can actually, contain almost the same information, as a higher definition one.
    So it is a big gain, in saving the later predictor and color transform images.

[MasterInQuestion]

    Seemingly related with these commits:
    https://github.com/webmproject/libwebp/commits?since=2024-09-17&until=2024-09-24&author=vrabaud
    .
    Is it this one specifically?
    @ 2024-09-24T08:44:22Z
    Search for best predictor transform bits - This is useful in cruncher mode.
    https://github.com/webmproject/libwebp/commit/220ee52967c121adf3c690fbd0605a7de6371943#diff-3561524ad1a2ce5e58a6a6008a8d7ccd45c2e11ec65cbe6708c663b32682d0d9R615
    ("GetBestPredictorsAndSubSampling")