Color theory between LCD and LED

goodsignal

Does anyone understand how color and brightness is processed for display monitors working in RGB space? For this conversation, I'm assuming colorMode(RGB,255).

Analyzing readings for brightness(rgb) has me wondering why brightness(color(200,200,0)) == brightness(color(200,0,0))

I've worked with LEDs quite a bit and by experience and knowledge of additive light theory, rgb(200,200,0) generally produces twice the lumen output as rgb(200,0,0). In other words it's twice as bright because two color dies are illuminated instead of one. I'm pretty sure most modern color monitors also produce color with additive light theory.

My assumption when calling brightness(rgb) would have been

brightness(color(255,255,255)) = 255.0
brightness(color(255,255,0)) = 170.0
brightness(color(255,0,0)) = 85.0

Obviously I'm wrong with respect to working with Processing since all three of those = 255.0

So what's going on here? Is my confusion due to a misunderstanding of what brightness() represents? Or, are there behind the scene rules that Processing is accounting for to produce balanced output for LCD monitors? If so, what are they? And how are others managing color and brightness output when we intend to use LED displays for graphical output?

kfrajer

colorMode() defines what the function brightness() will output.

https://processing.org/reference/colorMode_.html

When working with HSB, then you need to interpret color as color(H,S,B) where the letters stands for hue, saturation and brightness. However, if you use any of the HSB functions when working in RGB mode, the results would depend on how those functions were implemented in Processing. You could have a look at the source code in github. Try running this code and see for yourself:

//Different interpretation
colorMode(RGB,255,255,255);
println(brightness(color(255,255,255)));
println(brightness(color(255,255,0)));
println(brightness(color(255,0,0)));

//Expected interpretation
colorMode(HSB,255,255,255);
println(brightness(color(255,255,255)));
println(brightness(color(255,255,0)));
println(brightness(color(255,0,0)));

generally produces twice the lumen output

Functions working with color return color parameters and they do not intend to measure actual energy output.

Kf

goodsignal

Functions working with color return color parameters and they do not intend to measure actual energy output.

I'll take that. Thanks. It matches how color pickers in image editing software like photoshop work. Altering the Hue or Saturation never affects the Brightness slider, no matter what combination of RGB is lit with respect to monitor pixels.

However, the answer to your guess about how HSB function work in RGB mode are spelled out in the Processing Language Documentation. They are conversion functions so that while you are in one color mode you can extract values from the other color mode for a given color. The only weird thing that I wish was clearer in the documentation is that the output value range is always defined by the current color mode value ranges. Consider the code,

colorMode(RGB,255,255,255);
color a = color(255,255,255);

colorMode(HSB,100,300,500);
println("Red:",red(a));
println("Green:",green(a));
println("Blue",blue(a));

Gives an output,

Red: 100.0
Green: 300.0
Blue 500.0

It's probably better like this for robust programming. I just would have assumed that the output would follow the default range of a color mode or in the range it was originally assigned, rather than the parameters of the opposing color mode currently in use.

colouredmirrorball

rgb(200,200,0) generally produces twice the lumen output as rgb(200,0,0).

No. Lumen is a vague way of defining the visibility or apparent brightness of light. It's based on the wavelength (colour) dependent response of the eye. A red pixel/LED will have a much lower lumen value than a green one even though it has the same optical output power. To get the optical power of a lumen value, you need to know the wavelength of the light source and the luminosity curve. All of this is complicated because light sources usually produce multiple wavelengths at once.

Lord_of_the_Galaxy

Why even go through so much math?
Anyone can notice that yellow (rgb(200,200,0)) does not seem twice as bright as red (rgb(200,0,0)).

goodsignal

Stepping outside of the technicalities of power and flux along the color spectrum, most RGB LEDs are designed to produce similar perceived brightness for each die at full power. For practical purposes we don't have to indulge in the deeper physics and optical biology.

On a computer screen, yellow (rgb(200,200,0)) will not seem brighter than red (rgb(200,0,0)). However, An RGB LED (which some of us are using Processing to drive) will certainly appear and actually be brighter. Maybe not twice as bright as I originally stated because we see brightness on a logarithmic scale, but definitely brighter i.e. more luminous. Two dies are being powered at (200/255)*(full power) instead of one die.

colouredmirrorball

May I ask what you are trying to achieve? Do you need the apparent brightness or optical power? What is your application?

Brightness is just a vector in the HSB color space (like red is a vector in the RGB color space). It has nothing to do with apparent brightness or how much power a color has in a pixel.

Converting RGB or HSB color spaces to "real world" color space is a whole area of research. There are a plethora of definitions, standards and practices. It's impossible to implement all of that mess in Processing.

most RGB LEDs are designed to produce similar perceived brightness for each die at full power

Not in my experience. Color balance is hard and usually just swept under the rug for cheaper devices, to favor raw power.

Lord_of_the_Galaxy

most RGB LEDs are designed to produce similar perceived brightness for each die at full power.

Not in my experience. Color balance is hard and usually just swept under the rug for cheaper devices, to favor raw power.

Precisely, very few LEDs actually take all that into account.

goodsignal

I got the clarification I currently need from kfrajer's first post, thanks! And, concluded that, as colouredmirrorball suggested, I'll find an appropriate hardware forum to explore color brightness and power balancing for LEDs.