Let's look at the formulas for the screen and add blend modes. Add is really simple, it just adds the values:
f(a,b) = a + b
Where "a" "b" are our inputs. Easy, just combines things and makes them brighter. Now let's look at screen:
f(a,b) = 1 - (1 - a) * (1 - b)
More complicated. We subtract both values from 1, multiply them, and subtract the rest from 1. You might be asking "what's the significance of 1 in all this". That's where the problem comes from, there isn't any. Screen is inherently a "display referred" blend mode, meaning it was meant for use on values that describe the relative intensity of a screen pixel. Screen values cannot be over 100% intensity (because 100% is as bright as the pixel can go) so display referred values are bound at 100%, which for simplicity reasons is calculated using the value of "1".
When you have a display referred value (or any other value that's always in a 0-1 range) you can invert it by subtracting from 1. So screen inverts both layers, multiplies them, then inverts again. It's designed to prevent clipping when you try and make a brighter combo of two already bright values. Let's try with a bright but display-safe value of 0.9 for both layers:
f(0.9, 0.9) = 1 - (1 - 0.9) * (1 - 0.9)
f(0.9, 0.9) = 1 - 0.1 * 0.1
f(0.9, 0.9) = 1 - 0.001
f(0.9, 0.9) = 0.999
Hooray, it doesn't clip! Whereas add does:
f(0.9, 0.9) = 0.9 + 0.9
f(0.9, 0.9) = 1.8
Our pixels don't go to 180% power, so we have to clamp it all to 1.0. Gross.
Here's the problem though: renders are scene referred, not display referred. The pixel values do not represent relative intensities of a monitor pixel, they represent the absolute amount of light that struck a virtual "sensor". Thus, it's completely ok for them to exceed 1.0. 1.0 isn't any particularly meaningful value at all, it just the number that gets mapped to 100% by default when converting to display values for final output.
So given that we can have values > 1 and that 1.0 is not special in any way, we cannot safely invert values using it. And if we try, weird shit begins to happen. Let's run that again with layer 1 having a value of 1.5
f(1.5, 0.9) = 1 - (1 - 1.5) * (1 - 0.9)
f(1.5, 0.9) = 1 - -0.5 * 0.1
f(1.5, 0.9) = 1 - -0.05
f(1.5, 0.9) = 1.05
Ok, a little weird. But it's still larger than layer b, right? Let's go again, but with much bigger values:
f(5, 2) = 1 - (1 - 5) * (1 - 2)
f(5, 2) = 1 - -4 * -1
f(5, 2) = 1 - 4
f(5, 2) = -3
WTF? -3 is not brighter than 5 or 2. In fact, it's lower than our black point. So screen gets very unreliable once values go above the otherwise arbitrary point of 1.0. Input too big of a number, and the result goes DOWN, not up. If there's a big difference in brightness between color channels, this can result in wild color shifts. Imagine if your red channel is the 5 and 2 example, and your blue channel is the 0.9 and 0.9 example. Where do you think your hue is going to end up when (5, 1.0, 0.9) becomes (-3, 1.0, 0.999)? Somewhere very different from where you started, that's where.
As you found, the add blend mode still works because it doesn't try to invert by an arbitrary max:
f(5, 2) = 5 + 2
f(5, 2) = 7
f(1.5, 0.9) = 1.5 + 0.9
f(1.5, 0.9) = 2.4
So the takeaway is whenever using scene-referred/HDR values, stay clear of screen or any other modes that try and use 1.0 as a max (like overlay, useful as it is with 0-1 values).
Blue and pink hotspots abound!
I'm not looking for a fix, seeing as the fix of switching to "add" seems to work just fine. However, if anyone can explain to me why "screen" is producing this trippy result, I would greatly appreciate it.
