2

I've put this demo from MDN, https://developer.mozilla.org/samples/canvas-tutorial/6_1_canvas_composite.html into a jsFiddle and made the colours 50% transparent. http://jsfiddle.net/eGAvb/

Now, according to Apple, source-in is supposed to "Display the source image wherever both the source image and destination image are opaque. Display a blend wherever the source and destination are both translucent. Display transparency wherever either the source or destination are transparent."

So you can see a problem when you look at how it displays. It is a very light pink, not purple at all. Please can somebody explain why none of the blue from the square has been blended in here? Why has it actually got lighter?

ADDITION: I've just actually noticed, a far more striking an obvious example. The xor is clearly showing a purple colour, when according to the official spec: "Exclusive OR of the source image and destination image.", it should be showing nothing! Nowhere does it mention that opacity should affect these rules.

Lars
  • 7,908
  • 11
  • 52
  • 70

1 Answers1

2

Its working exactly how it should in your example. Take a look at this which was taken directly from the spec

the source image, A, is the shape or image being rendered, and the destination image, B, is the current state of the bitmap.

Display the source image wherever both the source image and destination image are opaque. Display transparency elsewhere.

In that definition only the source image will be displayed. Since its drawing the destination image and then subtracting the source image, you get a lighter overall image.

Another example would be source-over, you would expect the transparencies to be added to eachother, likewise then using destination-in and source-in the transparency should be reduced due to the subtraction of the shape.

Thanks @simonsarris for finding this gem The Porter Duff Compositing Operators

Community
  • 1
  • 1
Loktar
  • 34,764
  • 7
  • 90
  • 104
  • But it has actually drawn it *lighter* than the source image. If you look at the source-over example to the left, that is red at alpha=0.5. The source-in red, looks to be at around alpha=0.25, which I haven't set anywhere. I wonder if the alphas have been multiplied - but I can't find anywhere on the net that describes this behaviour. – Lars Aug 09 '13 at 16:21
  • I imagine its due to subtracting its transparency from the destination transparency. After a quick test, its exactly half of the transparency even with global alpha set http://jsfiddle.net/loktar/eGAvb/7/ – Loktar Aug 09 '13 at 16:45
  • Weird, right? I can't believe there's no documentation on this out there. Thanks for your thoughts, I may actually put a bounty on this to raise awareness and see what others have to say. – Lars Aug 09 '13 at 16:56
  • eh, I still think its acting correctly, in cases of lighter for example, I would expect the transparency to affect how strong the effect is. However a mention of transparency effecting the strength of the operation methods would be helpful. – Loktar Aug 09 '13 at 16:58
  • 1
    This is correct. Only the source image should exist, and only where the destination had existed. Since the destination half-existed (halfway between nothing, aka fully transparent), the source image is half copied in, resulting in a 50% opaque circle becoming a 25% opaque (or 75% transparent) section of a red circle. – Simon Sarris Aug 09 '13 at 17:42
  • 1
    Specifically, see this part of the W3 specification. Alpha channels are multiplied in src-in: http://dev.w3.org/fxtf/compositing-1/#porterduffcompositingoperators_srcin – Simon Sarris Aug 09 '13 at 17:45