Honouring the alpha attribute when creating composite images. #1955
Conversation
|
👍 I agree we can save the Cairo fix for later. It looks as it the test images were perhaps not committed. |
|
I've rebased/squashed this (with the formerly forgotten test images) and the Travis build is passing now. |
|
👍 |
| @@ -823,6 +825,16 @@ | |||
| Image* thisim = static_cast<Image*>(tup[0].ptr()); | |||
| ox = (long)Py::Int(tup[1]); | |||
| oy = (long)Py::Int(tup[2]); | |||
| if (tup[3].ptr() == Py_None) | |||
There was a problem hiding this comment.
I'm not sure about this - does it not set an IndexError? (http://docs.python.org/2/c-api/tuple.html#PyTuple_GetItem)
I wonder if we'd be better checking the tuple's size?
There was a problem hiding this comment.
Yeah, I think I agree. To maintain backward compatibility, maybe do:
if (tup.size() <= 2 || tup[3].ptr() == Py_None)
There was a problem hiding this comment.
OK. Everything that calls this in the codebase (all … 2 instances) was updated with the added parameter, but I'd forgotten the possibility that user code might call this.
Honouring the alpha attribute when creating composite images.
|
Another fantastic piece of work @Westacular. Cheers! |
I noticed some problems with the drawing of Images onto axes. Specifically, when
option_image_nocomposite()is False and a single composite image is created (which seems to be the default for most backends), the alpha attribute of the Image objects was being ignored in the compositing process.I've fixed that by multiplying the alpha component of each pixel with the attribute of the image, if set, during the process of compositing/blending the images together.
I've set up a test for this, as well, but getting the correct results from it depends on the changes from #1868.
In the process of testing this, I discovered that for output formats other than PNG, the Cairo backend was entirely failing to render images. I fixed that issue, however, a problem still remains: the Cairo image blending algorithms assume that pixel values are premultiplied by their alpha components, which is not currently being done in the process of converting image buffers for use by Cairo. For non-opaque images where rgb values exceed the alpha value, the result can be pretty weird and psychedelic. I can take a crack at fixing this, but it's a more involved change, and given that previously images weren't working at all for Cairo, it's perhaps better saved for a separate pull request.