Commit 59a59e5
committed
Handle almost-transparent and transparent pixels better
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.1 parent 809bb90 commit 59a59e5
2 files changed
+22
-1
lines changed| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
33 | 33 | | |
34 | 34 | | |
35 | 35 | | |
| 36 | + | |
| 37 | + | |
| 38 | + | |
| 39 | + | |
| 40 | + | |
| 41 | + | |
| 42 | + | |
| 43 | + | |
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
17 | 17 | | |
18 | 18 | | |
19 | 19 | | |
| 20 | + | |
| 21 | + | |
| 22 | + | |
| 23 | + | |
| 24 | + | |
| 25 | + | |
| 26 | + | |
| 27 | + | |
| 28 | + | |
| 29 | + | |
20 | 30 | | |
21 | 31 | | |
22 | 32 | | |
| |||
30 | 40 | | |
31 | 41 | | |
32 | 42 | | |
33 | | - | |
| 43 | + | |
| 44 | + | |
| 45 | + | |
| 46 | + | |
34 | 47 | | |
35 | 48 | | |
36 | 49 | | |
| |||
0 commit comments