Issue 646 in webp: "Canvas Assembly from Frames" in spec is incomplete and misleading
99 views
Skip to first unread message
tha… via monorail
Jul 12, 2024, 6:58:41 PMJul 12
to webp-d...@webmproject.org
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 646 by tha...@chromium.org: "Canvas Assembly from Frames" in spec is incomplete and misleading
https://bugs.chromium.org/p/webp/issues/detail?id=646
About https://developers.google.com/speed/webp/docs/riff_container#canvas_assembly_from_frames :
1. It says
"At the beginning of each loop iteration, the canvas is filled using the background color from the 'ANIM' Chunk or an application-defined color." in the free-form text but then
"""
canvas ← new image of size VP8X.canvasWidth x VP8X.canvasHeight with
background color ANIM.background_color.
"""
at the top of the pseudocode, and
"""
clear canvas to ANIM.background_color or application-defined color
"""
at the start of the loop.
libwebp uses 0 (transparent black) as background color instead of ANIM.background_color, so the prose part is probably the relevant bit.
What's more, allowing decoders two options here means that images won't be decoded consistently among decoders. This should say "must clear with background color transparent black".
This matters e.g. for the attached file, which stores opaque white as background color, contains a small animated in the middle and a big border. Depending on if the stored background color or 0 is used to clear, the output changes -- see https://github.com/SerenityOS/serenity/pull/24697#issuecomment-2226329067 for screenshots.
(This means that the background color stored in ANIM is no longer used for anything in the spec. That's weird, but it makes the spec match reality.)
1b. The attached file was written by Aseprite, which just uses libwebp for saving images. So libwebp's encoder does assume that decoders use libweb's "clear to transparent black" approach. This also suggests updating the spec.
1c. From what I can tell, libwebp only clears the now-previous's frame's rect with 0, instead of the whole frame as the pseudocode demands. (If clearing the whole canvas was correct, then the `new image of size...with background color` would be redundant. But if it's not redundant, it should also allow an application-specific color. Or, actually, demand 0 as background color instead of ANIM.background_color
2. It also says
"""
dispose_method = frame_params.disposeMethod
"""
in the very last line, but nothing in the pseudo code ever reads dispose_method
Attachments:
test.webp 154 bytes
--
You received this message because:
1. The project was configured to send all issue notifications to this address
You may adjust your notification preferences at:
https://bugs.chromium.org/hosting/settings
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 646 by tha...@chromium.org: "Canvas Assembly from Frames" in spec is incomplete and misleading
https://bugs.chromium.org/p/webp/issues/detail?id=646
About https://developers.google.com/speed/webp/docs/riff_container#canvas_assembly_from_frames :
1. It says
"At the beginning of each loop iteration, the canvas is filled using the background color from the 'ANIM' Chunk or an application-defined color." in the free-form text but then
"""
canvas ← new image of size VP8X.canvasWidth x VP8X.canvasHeight with
background color ANIM.background_color.
"""
at the top of the pseudocode, and
"""
clear canvas to ANIM.background_color or application-defined color
"""
at the start of the loop.
libwebp uses 0 (transparent black) as background color instead of ANIM.background_color, so the prose part is probably the relevant bit.
What's more, allowing decoders two options here means that images won't be decoded consistently among decoders. This should say "must clear with background color transparent black".
This matters e.g. for the attached file, which stores opaque white as background color, contains a small animated in the middle and a big border. Depending on if the stored background color or 0 is used to clear, the output changes -- see https://github.com/SerenityOS/serenity/pull/24697#issuecomment-2226329067 for screenshots.
(This means that the background color stored in ANIM is no longer used for anything in the spec. That's weird, but it makes the spec match reality.)
1b. The attached file was written by Aseprite, which just uses libwebp for saving images. So libwebp's encoder does assume that decoders use libweb's "clear to transparent black" approach. This also suggests updating the spec.
1c. From what I can tell, libwebp only clears the now-previous's frame's rect with 0, instead of the whole frame as the pseudocode demands. (If clearing the whole canvas was correct, then the `new image of size...with background color` would be redundant. But if it's not redundant, it should also allow an application-specific color. Or, actually, demand 0 as background color instead of ANIM.background_color
2. It also says
"""
dispose_method = frame_params.disposeMethod
"""
in the very last line, but nothing in the pseudo code ever reads dispose_method
Attachments:
test.webp 154 bytes
--
You received this message because:
1. The project was configured to send all issue notifications to this address
You may adjust your notification preferences at:
https://bugs.chromium.org/hosting/settings
tha… via monorail
Jul 12, 2024, 7:00:40 PMJul 12
to webp-d...@webmproject.org
Comment #1 on issue 646 by tha...@chromium.org: "Canvas Assembly from Frames" in spec is incomplete and misleading
https://bugs.chromium.org/p/webp/issues/detail?id=646#c1
(`/anim_dump ~/Documents/sprites/test.webp` does write a png with transparent black everywhere except for the black smiley face pixels, even though browsers paint the face on a white background, making it hard to see what I mean.)
jz… via monorail
Jul 16, 2024, 6:42:58 PMJul 16
to webp-d...@webmproject.org
Updates:
Cc: urv...@google.com
Owner: jz...@google.com
Status: Accepted
Comment #2 on issue 646 by jz...@google.com: "Canvas Assembly from Frames" in spec is incomplete and misleading
https://bugs.chromium.org/p/webp/issues/detail?id=646#c2
Cc: urv...@google.com
Owner: jz...@google.com
Status: Accepted
Comment #2 on issue 646 by jz...@google.com: "Canvas Assembly from Frames" in spec is incomplete and misleading
https://bugs.chromium.org/p/webp/issues/detail?id=646#c2
> libwebp uses 0 (transparent black) as background color instead of ANIM.background_color, so the prose part is probably the relevant bit.
Right, the text is meant to be normative, pseudocode isn't in the eyes of many. I'll normalize the pseudocode.
> 1b. The attached file was written by Aseprite, which just uses libwebp for saving images. So libwebp's encoder does assume that decoders use libweb's "clear to transparent black" approach. This also suggests updating the spec.
If `-exact` is set the fully transparent area shouldn't be changed. When it isn't (the default), the fully transparent area is modified [1]. Alpha is always encoded with `exact = 1` [2].
> 2. It also says
>
> """
> dispose_method = frame_params.disposeMethod
> """
jz… via monorail
Jul 16, 2024, 7:14:51 PMJul 16
to webp-d...@webmproject.org
Comment #3 on issue 646 by jz...@google.com: "Canvas Assembly from Frames" in spec is incomplete and misleading
https://bugs.chromium.org/p/webp/issues/detail?id=646#c3
The background mostly applies to transparent and mostly transparent pixels. In both cases, it's true that selecting white or black may affect what is visible. The application-defined option was added because an application may want to blend to its own layer rather than having a rectangle of forced color.
Reply all
Reply to author
Forward
0 new messages