> Pixels with RGB values of (128, 128, 128) emit about half as much light as pixels with RGB values of (255, 255, 255).
Technically, this is not always incorrect, if your working color space is linear and 0 is no light. The problem only comes if you hand that same data to routines or surfaces expecting sRGB or another nonlinear color space (or one where 0 is not no light).
Perceptual color accuracy is usually handled at the display manager or operating system level; wherever monitor color calibration is applied. You don't usually have to worry about it, unless your target audience puts you especially in charge of it. (Certain applications on Windows and Linux do this for color-grading workflows.)
> unless your target audience puts you especially in charge of it.
In which case the color space you would work with would have "no emission" that's not at 0, accurately answering the original question. I don't expect a tech forum like this to be limited to the application layer.
After doing a bit of digging, ambient light correction, on higher end monitors (like MacBooks) do seem to mix ambient reflectance in! Neat!
> In which case the color space you would work with would have "no emission" that's not at 0, accurately answering the original question. I don't expect a tech forum like this to be limited to the application layer.
That depends on whether your idea of pixels is as emitted by the application or as transmitted to the display.
Since the latter is hardly relevant to the majority of cases, I left it out. Maybe on simplistic platforms like Windows you'd have to care. But if you're a run-of-the-mill application developer making a game or web app or something... in no world do you have awareness of nor control over what's transmitted to the display.
So bringing up analog signals or OS-level color management as a 'gotcha' is being unnecessarily pedantic.
Oh, I was just listing the constraints. I'm not directly aware of a color space where value 0 is not no light. It would however mean that even if linear, doubling a value relative to 0 wouldn't necessarily double the amount of light.
Technically, this is not always incorrect, if your working color space is linear and 0 is no light. The problem only comes if you hand that same data to routines or surfaces expecting sRGB or another nonlinear color space (or one where 0 is not no light).