Handle almost-transparent and transparent pixels better #37
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
I came across a case where one pixel is almost transparent and the other is fully transparent. Consider these pixels: [ 1, 46, 250, 0 ] [ 1, 42, 250, 4 ] With our old logic, there was a color-delta of `1` between these pixels. If we blend them both with white, we instead get a very low color-delta value. At first I was going to always blend with white, but I realized we are using fully transparent as a signal that there is a gap/missing pixels in either the before or after image. So I instead changed it to "intentional transparency" where something like [255, 255, 255, 0] [0, 0, 0, 0] [100, 100, 100, 0] would be considered "intentional transparency". Of course, this assumption can't always be made. But for us I think we can use it to get rid of the edge-case that I present here. There's still a risk that we'll encounter "wild" transparency with r===g===b but at least this is better than what we have.
lencioni
reviewed
Aug 26, 2024
|
I thought we used fully transparent when constructing the "gaps" in the image. But I was wrong, it looks like we use a semi-transparent pixel. I'll change to blending with white and see what happens. |
|
Okay, seems like commit d4ecfac is relevant here. Basically the avoidance of blending with white for fully transparent pixels was to make diffs that are different in width better. The missing area to the right for one of the images will be represented as fully transparent. If we blend it with white and then run color-delta there would be no difference. |
Some code we had was assuming that everything fully transparent was intentionally added by us as filler for missing content on the right of either the before or after image. To make things more explicit, I'm using the term "filler pixel" here and setting it to always be 1,1,1,1. This way the intentions in the code become clearer and at the same time we have less risk of collisions with a transparent pixel that we do not control.
|
Pushed another commit to clarify some intentions. While this isn't great, it's slightly better than what we currently have. |
This diff image looks slightly different now that we've made some changes to the filler pixel.
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.
I came across a case where one pixel is almost transparent and the other is fully transparent. Consider these pixels:
[ 1, 46, 250, 0 ]
[ 1, 42, 250, 4 ]
With our old logic, there was a color-delta of
1between these pixels. If we blend them both with white, we instead get a very low color-delta value.At first I was going to always blend with white, but I realized we are using fully transparent as a signal that there is a gap/missing pixels in either the before or after image. So I instead changed it to "intentional transparency" where something like
[255, 255, 255, 0]
[0, 0, 0, 0]
[100, 100, 100, 0]
would be considered "intentional transparency". Of course, this assumption can't always be made. But for us I think we can use it to get rid of the edge-case that I present here. There's still a risk that we'll encounter "wild" transparency with r===g===b but at least this is better than what we have.