"libwebp" decoding seems to incorrectly handle Alpha cloaked parts

[MasterInQuestion]

    Which may lead to "-noalpha" alike (discarding Alpha outright) decoding:
    Unexpectedly include those pixels should be fully cloaked by Alpha (that originally invisible).

    E.g.
    [ Help: https://ffmpeg.org/ffmpeg-filters.html#pad etc. ]
    ffmpeg -y -v trace -hide_banner -nostdin -nostats -i "dazzle.webp" -lavfi "crop=oh:(( iw - 12 )),pad=(( iw + 12 )):(( ih + 12 )):-1:-1:#00000000,split=5[-][-][-][-]; [0][-]ssim,nullsink; [0][-]psnr,nullsink" -lossless 1 -q 100 -compression_level 6 "dazzle-re.webp" -map "[-]" "dazzle.png" -map "[-]" -pix_fmt rgb24 "dazzle-a.png"
# ^ Reported SSIM, PSNR differed meanwhile. "dazzle.png" maintains the same data; "dazzle-a.png" except Alpha.
    ffmpeg -hide_banner -nostdin -i "dazzle.webp" -i "dazzle-re.webp" -lavfi "ssim; [0][1]psnr" -f null -
# ^ "dazzle.webp", "dazzle-re.webp" shall be identical files.
    cwebp14 -mt -z 9 "dazzle.webp" -o "dazzle.x.webp"
    cwebp -mt -z 9 -noalpha "dazzle.x.webp" -o "dazzle-a.webp"
# ^ WebP 1.4.0 vs. 1.5.0 gave different image. (differed the border)

    "dazzle.webp" is fundamentally 500x500 opaque image, padded with 6px full-transparency each border.

    Bizarre thing is that the cropped version (without padding), would instead take more bytes to store..?
    cwebp -mt -z 9 -crop 6 6 500 500 "dazzle.webp" -o "dazzle-.webp"
    (174,816 B vs. 173,096 B)

    Plus a "-mt" anomaly:
    https://github.com/MasterInQuestion/talk/discussions/52

    @jzern, @vrabaud?

[vrabaud]

    Thx for reporting. Can you please open an official bug at [ https://g-issues.webmproject.org/issues/new?component=1615215 ]?
    I am not sure I understand the bug too. Is it:
    cwebp14 -mt -z 9 -noalpha "dazzle.webp" -o "dazzle-a.webp"
    cwebp -mt -z 9 -noalpha "dazzle.x.webp" -o "dazzle-a.webp"
    ; give different results?

    For the cropped version giving different results, well, that can happen unfortunately.
    Less data does not necessarily mean less data. (some symbols are sometimes easier to encode)

[MasterInQuestion]

    You copied the command wrong.
    It's a chain of "dazzle.x.webp" (mere passthrough output by 1.4.0 / 1.5.0): decoding which gave different image.

    Somewhat alike size anomaly:
    https://github.com/libjxl/libjxl/issues/3921#issuecomment-2513041874
    (I believe it's eventually the "compression strategies" cause)

    ----

    Pardon for confusion. I shall since detail more.

    It's a sequence of 2 commands, passing through "dazzle.x.webp".
    That demonstrates the same image data losslessly encoded by 1.4.0 / 1.5.0:
    Were strangely decoded to different images with "-noalpha".

    Direct example:
    cwebp14 -mt -z 9 "dazzle.webp" -o "dazzle.x.webp"
# Compare below:
    cwebp -mt -z 9 -noalpha "dazzle.x.webp" -o "dazzle-a.x14.webp"
    cwebp -mt -z 9 -noalpha "dazzle.webp" -o "dazzle-a.x15.webp"
# ^ Process with earlier WebP (pre-1.5.0) also gave alike.
# (same also reproducible with FFmpeg's alike handling)
    .
    Hence the primary description.

[vrabaud]

    Sorry again, I do not understand you comment:
    "WebP 1.4.0 vs. 1.5.0 gave different image. (differed the border)"
    According to which instruction?

    cwebp14 -mt -z 9 "dazzle.webp" -o "dazzle.x.webp"
    cwebp -mt -z 9 -noalpha "dazzle.x.webp" -o "dazzle-a.webp"
    .
    The 1st one keeps the Alpha, not the 2nd one.

    ----

    Thx, I was able to reproduce. It is actually an expected behavior.
    If you want to keep what is behind alpha == 0, you need to pass "-exact":
    cwebp14 -mt -z 9 "dazzle.webp" -o "dazzle.x.webp"
    .
    In which case, `cwebp` and `cwebp14` give the same result.

    There is an optimization done when alpha == 0: replacing the RGB values with whatever is best for compression.
    (it does not matter as they will never be seen)

    We talked about having "-exact" by default before. Right @jzern?

[jzern]

There is an optimization done when alpha==0, replacing the RGB values with whatever is best for compression (it does not matter as they will never be seen). We talked about having -exact by default before. Right @jzern ?

    Yes this was discussed when the flag was added.
    But the decision was that:
    Even though it might be surprising in some cases, it was better to default to modifying the alpha:
    To improve the size and performance for most web use cases.

[MasterInQuestion]

    It's primarily about decoding:
    If it's to be discarded, maybe it shouldn't be decoded randomly. After all.

    Probably default to using more regular handling on decoding such?
    (instead of copying garbage, just assert black?)

    Note:
    This specifically applies to decoding without "-exact".
    Otherwise, the current behavior seems sensible.

[vrabaud]

    Everything is deterministic.
    "-exact" is only for encoding: whether you keep the RGB values, when alpha == 0.

    Decoding is fine.
    What changed between 1.4 and 1.5 is which values are put in the image, when there is no "-exact" and alpha == 0.
    Setting RGB to black is one way of doing things.
    Setting the same line as above is a different strategy.

[MasterInQuestion]

    "random" primarily for the input part isn't really genuinely encoded. (image data unpredictably dropped)
    Nevertheless not much on-topic.

    I think "-exact" can be adapted to influence decoding:
    So to provide overall more consistent experience.
    .
    Actually just use the current behavior with "-exact" decoding.
    Without, all Alpha 0 pixels just be black.
    [ ^ Better idea might be pure white? RGB #FFF, yuv( 255, 127, 127 ) ]

    ----

    Probably `dwebp` would then need "-exact" added:
    https://chromium.googlesource.com/webm/libwebp/+/HEAD/doc/tools.md#decoding-tool

    Does "-exact" also affect the lossy VP8 handling?

[jzern]

I think "-exact" can be adapted to influence decoding:

The idea is to make the input more compressible at encode time to reduce the number of bytes to transfer. The process is destructive, there's no way to recover the original pixels after the change is made.

Does "-exact" also affect the lossy VP8 handling?

-exact affects the alpha plane. It will be used for both lossy and lossless encodes.

[MasterInQuestion]

    For such input isn't really genuinely encoded when.
    The decoding without "-exact" can be made to discard alike garbage.
    (therefore improves overall consistency)

    The existence of alike invisible pixels, in the first place:
    Doesn't make much sense after all.
    (practically no real use case, besides steganography)

[MasterInQuestion]

    @jzern, @vrabaud
    Would you like me to perform full-scale refactoring on all comments?
    For better readability and posterity purpose.

[vrabaud]

You mean in this discussion? Sure

[MasterInQuestion]

    OK.
    Pardon for late response.
    Caught by other tasks recently.
    Meanwhile I noted another bizarre thing:
    https://github.com/MasterInQuestion/talk/discussions/53