For those who just wanna know: cards at the time performed math on brightness values assuming a linear brightness scale when it should be logarithmic.
…ish
The maths was right, except it was all being done on colour values than already had the CRTs response curve baked into them. You may have heard of “gamma correction”. Well, this is when you correct an images colour values for the display you’ll view it on.
Blending before gamma correction and after gamma correction produce very different results. The cards were doing it after. This story is about doing it before.
Paul Debevec had similar observations around the same time. His work at the time was all about HDRI and that was put into Source a few years later.
“It’s a bit technical,” begins Birdwell, "but the simple version is that graphics cards at the time always stored RGB textures and even displayed everything as non linear intensities, meaning that an 8 bit RGB value of 128 encodes a pixel that’s about 22% as bright as a value of 255, but the graphics hardware was doing lighting calculations as though everything was linear.
Jesus Christ, I knew this was a problem with image editing software back then, but I never knew, that GPU manufacturers fucked it up as well. How did this happen?
I have a good guess on how this would actually happen:
PM: We need this
Specialist: makes this (doesn’t check results)
QC: Looks good (but doesn’t actually check)
Some updates later may further break the functionality. And as long as numbers aren’t blatantly wrong (think 0s everywhere, for example) and nobody checks thoroughly enough, the issue will remain.
I have unfortunate experience of being a part of such a story, haha. There are ways to counter it. Mainly, their project documentation either wasn’t up to par or wasn’t used as a reference during creation and tests. Either way, it’s negligence.
