Is it possible to change pixel brightness programmatically?

Question

So, I've been learning 3D rendering for more than a year now, and I've read a lot about various rendering techniques and theories, such as PBR, deferred shading, real-time raytracing, BRDF, all that stuff. As far as I know, these topics are either trying to solve the rendering equation, or reduce the computation overhead to boost performance, it's almost always on the side of software, and it seems that shading only cares about finding the color for each pixel. Whatever smart algorithms we use, the most bright pixel on the screen can only be white, we can't have a pixel brighter than RGB(255,255,255), which is not realistic.

In the real world, human eyes can see much more than just RGBA colors, so I wonder if we can change the pixel brightness in a shader program. To clarify, I'm talking about the screen brightness, brightness of the monitor that we can adjust in hardware settings. For example, each pixel could not only have a color, but also a different brightness value depending on the shader code, is this possible? Just like how we have the depth Z-buffer, I wonder if there's any hardware that supports a B-buffer (brightness buffer).

Answer 1

I doubt that per-pixel PHYSICAL brightness control is possible. Many computers still use LCD, which uses a single backlight which is spread by optical planes, so there is no per-pixel brightness. Even on LED computers it would be a nightmare to implement variable brightness in hardware.

One important thing to remember is that when you increase pixel brightness, the blacks will also get brighter. Therefore, gains in contrast due to per-pixel PHYSICAL brightness control may not be predictable.

If you somehow find any hardware that provides a win32 or similar API for per-pixel PHYSICAL brightness, I doubt it will port to any commonly used devices. There is no standard OpenGL API for this, since I can't even name a device that can do this.

What you SHOULD LOOK INTO is color transforms. Basically, color is relative. For instance, the black on your computer screen is not PHYSICAL darkness, it is just darker than the other colors. OpenGL will accept RGB values in the range of 0.0 to 1.0 (or 0 to 255), and the hardware determines how they will appear to humans. What a color transform can do is modify the RGB values you feed into OpenGL before it reaches the screen, so it has the appearance of a different color space. For instance, Blender and Unreal Engine both have filmic color transforms that can allow for extremely bright whites (RGB >> 1.0 or 255) without washing out (using a sort of logarithmic scaling). The simplest way to implement a color transform would be in your fragment shader. I do not think OpenGL has in-built color transform pipelines.

Blender's filmic color transform as well as other color management code uses OpenColorIO: If you are interested, you can google further: https://docs.blender.org/manual/en/latest/render/color_management.html

NOTE Most monitors support sRGB, which is a standard describing a mapping between the 0.0-1.0 range RGB values to physical colors (i.e. red/green/blue sub-pixel physical brightnesses). However, many monitors boast expanded physical color-spaces, with their own transforms. If you are extremely concerned with color fidelity, you may want to look into the color mappings for the monitors you wish to support.

Answer 2

sRGB does have luminance (perceived brightness), and the limitations you express concern about are a display hardware limitation, not a limitation of the underlying algorithms we use. PBR algorithms are not limited in there ability to compute brightness and color, but display hardware does have limitations, and after computing a value with both luminance and color, it can then be converted to a format that the display hardware is capable of displaying. And there is hardware that has extended brightness, which allows graphics programs to show a wider range of color, and brightness.

Many new graphics programmers make the mistake of thinking a color space only describes color. This is naïve as a color space encodes both color and luminance (the perceived brightness of a light) the sRGB color space was designed many years ago to fit the hardware of the time and its luminance range reflects that. The international standard color space CIE XYZ encodes luminance directly in the Y value, and all standardized color spaces including sRGB have conversion functions that allow them to be converted to and from the CIE XYZ color space. If you want to compute the luminance of any given sRGB value then convert it to CIE XYZ and look at the Y value, you will find that there are many different luminance values that the various sRGB values convert to.