ICO: Use bit count from BMP header for alpha mask#3047
Open
RunDevelopment wants to merge 1 commit into
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Turns out, ICON dir entries can just lie and we shouldn't trust them. We previously used the ICON dir entry's bit count to determine whether to apply the AND mask. This is wrong, because the this bit count may mismatch with the bit count of the encoded BMP.
I added a test image that is reported as 8 bpp in the ICON dir entry, but the BMP is actually 32 bpp. With the AND mask set to completely transparent (all 1), the output is determined by which bit count value is used. For 8 bpp, the AND mask would be applied, giving us a completely transparent image. For 32 bpp, the AND mask is ignored. Of course, Windows Explorer (and most other ICO decoders) correctly decode the test image, and now we do too.