About transparency + alpha

[GoogleCodeExporter]

On the container specification it says "After disposing the current frame, 
render the next frame on the canvas using alpha-blending."

If I'm reading that right, it means some output values can't be achieved 
depending on the current canvas status.

For example, consider a fully opaque pixel on a frame, which we want to turn 
into a pixel with 25% opacity. We can't, since with the blending formula 
"blend.A = src.A + dst.A * (1 - src.A / 255)" we can only make things more 
opaque, never less.

Now this can be workarounded by marking the previous frame as "Dispose to 
background color". The problem with this approach is that we can't reuse the 
unchanging parts from the previous frame (we can't update a subrectangle since 
we dispose of everything).

Finally the alpha blending is described in terms of floating point operations 
(and isn't even mandatory), which could cause different decoders to 
significantly drift apart over several frames.

Is there anything I've misinterpreted here?

Looking at the APNG spec, it appears it offers two blend modes: 
"APNG_BLEND_OP_OVER" which is what I think WebP always does, and 
"APNG_BLEND_OP_SOURCE" which I consider more versatile. They also offer a 
"APNG_DISPOSE_OP_PREVIOUS" option which might help compression for flashing 
images, but which might require more decoder memory depending on implementation.

Original issue reported on code.google.com by palsto...@gmail.com on 11 Jun 2013 at 10:17

[GoogleCodeExporter]

Original comment by pascal.m...@gmail.com on 12 Jun 2013 at 8:21

[GoogleCodeExporter]

To answer your two questions:

(1) Your understanding about the alpha-blending is correct.
In fact, supporting two blend modes was suggested earlier too, and we are 
considering the same:
https://groups.google.com/a/webmproject.org/d/msg/webp-discuss/fD_nrJibs_4/rjNb9
wVpucoJ

Quoting from that email thread:
"We are seriously considering to add this option. It has good potential 
technically, and it can easily go into the ANMF chunk (which has 7 reserved 
bits right now).

At the same time, it would be good to have the spec, API and gif2webp all 
supporting and making use of that option. That would help to prove its 
practical usefulness too.
So, we are opting to defer the decision of adding this option to the next minor 
release based on evaluations. (Note that if we choose to add this option, 
backward compatibility will still be ensured with 0.3.0, as we could specify 
that value of '0' would mean 'blend' and '1' would mean 'no blend')."

(2) Alpha-blending is a floating-point operation, yes. However it's mandatory.

Original comment by urv...@google.com on 12 Jun 2013 at 9:53

[GoogleCodeExporter]

Hi,
This was implemented sometime back in the following patches:
Spec: https://gerrit.chromium.org/gerrit/#/c/65379/
Libraries: https://gerrit.chromium.org/gerrit/#/c/65381/
gif2webp: https://gerrit.chromium.org/gerrit/#/c/65386/
vwebp: https://gerrit.chromium.org/gerrit/#/c/65387/
webpmux: https://gerrit.chromium.org/gerrit/#/c/67008/

Original comment by urv...@google.com on 13 Sep 2013 at 9:45

• Changed state: Fixed