Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork7.9k
Honouring the alpha attribute when creating composite images.#1955
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
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 workingat all for Cairo, it's perhaps better saved for a separate pull request.