-
-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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 our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Method to test if image has transparency/alpha #7384
Comments
A side comment that I'm not sure how to phrase - you mention two StackOverflow posts, a 2016 StackOverflow post referencing a StackOverflow post from 2009. If the problem is that old, I have to imagine the awkward solutions are also well-ingrained in the behaviour of users by now, and that whatever happens here, posts from 2009 (which is actually before Pillow even existed) will still be there, offering a different way of doing things. This is just part of dealing with a library that has been around for a long time. Given that you can have RGBA images that are fully solid, the method you're describing is sort of not describing whether an image has transparency, but whether it might have transparency. I presume you're not interested in a method that checks each pixel to see if it has transparency or not, because you correctly think that would be slower? |
Thanks for the comment! Yeah I agree about the legacy here. But it's a bit of "the best time to act was in 2009, the second best time to act is now" sort of situation IMO. My point was that those well-ingrained solutions are actually incorrect, hence the huge benefit in a library-approved correct method (as opposed to just leaving people to use a commonly accepted workaround, which would be more okay if it was correct). I found those Stack Overflow posts through searching for sensible terms, and it's not uncommon to see a post on SO get a new solution many years later when a library gets updated, and that solution slowly gets upvoted. Regarding solid RGBA images – that's why I left the door open for a semantic difference between "has alpha" and "has transparency". When it comes to my own use case, I was interested in not just removing transparency but removing the alpha channel (even if it was opaque). Though I can see utility in both features, and while checking for transparency would be slower, I'm not sure if it would be too slow to be useful. I figured it was something that could come out in a discussion, anyway. For clarity on terms: we're agreed that alpha does not imply transparency, does transparency imply alpha? Are there any ways to achieve transparency in Pillow that do not use an alpha channel? Genuine question as to whether this is a subset or a Venn diagram...! |
A colleague just sent me this post, which seems like a nicely well-researched https://stackoverflow.com/a/58567453/5506429 though an answer by another author seems to check for different cases again |
Though both of those answers rely on img = Image.new("RGBA", (100, 100), (128, 128, 128, 128)).quantize()
print(img.info) # {} perhaps that's actually a bug in |
If the behaviour of
Speaking for myself, I wouldn't have naturally understood a difference between those two method names.
I think you've already posted an example of this, that P mode images can have a transparency index?
So this is the same as https://stackoverflow.com/questions/35859140/remove-transparency-alpha-from-any-image-using-pil/35859141#35859141. Would it be simpler to cut out the middleman of checking for transparency, and just have a method that removes transparency? |
Sorry,
Good point :)
It does seem that removing transparency is the most common request here and I'd definitely make use of such a method, but I think it'd be complicated. I specifically wanted to do something like: if has_alpha:
composite with a specific colour background
remove_alpha but in that case, after I do also have a use case where I just want to check for particular images that actually have transparent pixels – not to remove the transparency, but to determine an output format (since jpg doesn't support it for example). The examples from SO handle every file I've seen so far, I just can't help but notice I can construct an image where they'd fail. |
Ok, I've created PR #7420. See what you think, and let us know if that resolves this. I've put it in draft mode because I would like to try and address this in one go. |
I've commented on the PR, it looks great, thanks. |
[2023/09/11 edit] adding a tl;dr:
Original post:
I found myself wanting to check if an image had an alpha channel/transparency (I'm allowing for a distinction between those, perhaps there isn't a meaningful one). I was trying to convert some optimised images that didn't contain any transparency, so wanted to do something different in that case.
Checking for this is slightly tricky though, and I've seen incorrect logic posted elsewhere, e.g. this stackoverflow post references this stackoverflow post which states to use:
But palette-mode images can store their transparency in at least two ways, in
img.info
, or the palette itself might beRGBA
. If you run the followingthe result is
False
, but clearly it has alpha values in the palette:Would it be possible to add something like
img.has_alpha()
orimg.has_transparency()
to help here?I'm not familiar enough with Pillow's image formats to say whether checking the mode of the palette in addition to the checks above would be exhaustive. Perhaps someone can clarify? Is it sufficient to check
img.palette.mode == 'RGBA'
?.quantize()
does not seem to like anLA
image, but if I manually set the palette mode and colors, it works withshow()
. Then there are other esoteric modes with alpha channels. So perhaps something like this will work?but I very easily could have missed something due to inexperience with the unusual image formats.
(Happy to have a go at the implementation if that would be of assistance!)
The text was updated successfully, but these errors were encountered: