Fix TkCairo bug when displaying images with partially transparent pixels - #32315
Conversation
|
I'll note that |
| (2, 1, 0, 3) if sys.byteorder == "little" else (1, 2, 3, 0)) | ||
| premult_argb = np.reshape(surface.get_data(), (height, width, 4)) | ||
| unmult_rgba = cbook._premultiplied_argb32_to_unmultiplied_rgba8888(premult_argb) | ||
| _backend_tk.blit(self._tkphoto, unmult_rgba, (0, 1, 2, 3)) |
There was a problem hiding this comment.
The removal of byteorder confused me until I realized that _premultiplied_argb32_to_unmultiplied_rgba8888 was handling it.
I don't think we need a comment in the code about this, as it only applies to the diff.
iccir
left a comment
There was a problem hiding this comment.
Looks good to me!
I'm wondering if there are performance wins if we moved the premultiply conversion functions into C++, but we can investigate that in the future if it shows up in a profile.
On my machine, the wx issues are related to color space conversion between sRGB and the device profile. I can get the correct colors by telling macOS that the device profile is sRGB. |
…315-on-v3.11.x Backport PR #32315 on branch v3.11.x (Fix TkCairo bug when displaying images with partially transparent pixels)
PR summary
For the
TkCairoGUI backend, the Cairo image buffer uses premultiplied alpha, and is currently passed directly to Tk for blitting, but Tk (PhotoImage) expects unmultiplied alpha. Thus, partially transparent pixels – which usually requires making the Figure and Axes patches transparent – are not displayed correctly. This bug is only in the GUI; saving the image produces the correct output.This PR uses an existing
cbookfunction to convert from premultiplied-space alpha to unmultiplied-alpha space, and also adds a fast bailout path to that function when the image is fully opaque.Example
Before this PR
After this PR
AI Disclosure
No AI was used
PR quality check