[SFF Network] RGB - An Epiphany

confusis

John Morrison. Founder and Head writer SFF.N
Original poster
SFF Workshop
Editorial Staff
Moderator
Jun 19, 2015
3,609
6,216
sff.network
This is one of a series of mini-rants by your faithful correspondent, John Morrison. These are part of a series focusing on issues in the SFF niche. All content is entirely opinion of John, not of SmallFormFactor.net, and should not be taken as fact.

Everybody likes to be unique. This desire manifests itself everywhere - clothing, cars, and even our computers. People mod their systems, making them more to their own personal tastes. Lighting forms a large part of this. From illuminating your components, to providing a visual representation of system status, to flashing to the beat of your favourite music, case lighting adds that extra touch of individuality.

Read more here.
 

LocoMoto

DEVOURER OF BAKED POTATOES
Jul 19, 2015
287
334
Solid rant, RGB and any light really, should not take the "spotlight" of your build but be an accent that brings out your build, your components, features of a case etc.
A means to guide someones eyes to where you want, to let them take in the details in peace.
 

Kooki

SFF Lingo Aficionado
Mar 30, 2016
129
56
Some of the recent LED hardwares sound insane but actually are quite discrete and just adds to the overall build without taking the "spotlight".

The first time I heard of RGB fittings for custom loops I was like "o_O", but I've seen some very subtle implementations of it which weren't horse crazy on the light effects.

But yeah, as you pointed out in the article, there are discrete ways to use them, but it will totally depend on the end-user.
 

|||

King of Cable Management
Sep 26, 2015
774
758
I predict RGB m.2 drives will be next.

 

iFreilicht

FlexATX Authority
Feb 28, 2015
3,243
2,357
freilite.com
Yeah I totally agree, subtlety is the name of the game here. I think mainboard manufacturers are starting to move toward that direction. In general, RGB LEDs just make it easier to choose exactly the colour you want and change that in the future without replacing LEDs, so they offer a lot of value over regular single-colour LEDs.

The second thing that has to change is the existence of a myriad of in-house, non-documented lighting protocols. ASUS, MSI, Cooler Master, Thermaltake, Corsair, Razer, Roccat, Alienware, everyone and their dog have custom software for controlling lighting on their products, and most of them integrate into obnoxiously large software suites that take minutes to load, slow down your boot time and look horrific in general.

Lighting in PC parts an peripherals has to be seen as a separate entity from the product itself. An advent of an open standard would greatly simplify this sort of thing, but I don't claim I would know how to implement such a thing, and it would be a lot of work to write a piece of simple software that retroactively included all or even just the most popular of RGB lit (cue air horns) product lines.
 

EdZ

Virtual Realist
Gold Supporter
May 11, 2015
1,578
2,107
RGB lighting in and of itself isn't a problem, but more often than not it's bad lighting, and integrated into a bad product (a literal Shiny Thing distraction), so everything RGB gets tarred by the same brush.

If you're going to implement RGB lighting though, at the very least do it properly! Pick suitable LED primaries to get a good gamut, make sure your controller can mix with sufficient bit-depth for good selection fidelity and to avoid 'jumps' during fades, and don't do silly things like failing to account for perceptual luminance (e.g. ending up with 50 indistinguishable levels of 'too bright', and about 3 levels of useful dimming between 'off' and 'bright', because you used linear colour). If you can't achieve sRGB with a D65 white point, characterise your colourspace so it can be mapped correctly to match the on-screen picker (and to other lightsources).
 

Phuncz

Lord of the Boards
Editorial Staff
Moderator
Gold Supporter
May 9, 2015
5,374
4,662
I share the sentiment that RGB LED lighting is not the problem but poor implementation (software and hardware) is. It needs easy to use software, yet allow deep functionality. It needs to be lightweight and preferrably open-source software. It needs the correct hardware implementation so it's not just a LED strip taped to some parts from the sale bin that allow you to activate it.


Also this soft glow and gradual gradient:



Looks 3416 times better than this laser retina burning gamerz design:



And please manufacturers, figure out a way to do it wireless. I don't like a USB cable per device or proprietary systems thay you'll abandon in 6 months.
 
  • Like
Reactions: WadeAK78

iFreilicht

FlexATX Authority
Feb 28, 2015
3,243
2,357
freilite.com
If you're going to implement RGB lighting though, at the very least do it properly! Pick suitable LED primaries to get a good gamut, make sure your controller can mix with sufficient bit-depth for good selection fidelity and to avoid 'jumps' during fades, and don't do silly things like failing to account for perceptual luminance (e.g. ending up with 50 indistinguishable levels of 'too bright', and about 3 levels of useful dimming between 'off' and 'bright', because you used linear colour). If you can't achieve sRGB with a D65 white point, characterise your colourspace so it can be mapped correctly to match the on-screen picker (and to other lightsources).

Clearly I still have to learn a little to make my button look good :D At least I know about logarithmic colour fading, so that's a start. You know any good resources I could use to read up on this?

And please manufacturers, figure out a way to do it wireless. I don't like a USB cable per device or proprietary systems thay you'll abandon in 6 months.

That could be quite a challenge though. You can't really expect every PC to have internal bluetooth connectivity.
 
  • Like
Reactions: ricochet

|||

King of Cable Management
Sep 26, 2015
774
758
If you're going to implement RGB lighting though, at the very least do it properly! Pick suitable LED primaries to get a good gamut, make sure your controller can mix with sufficient bit-depth for good selection fidelity and to avoid 'jumps' during fades, and don't do silly things like failing to account for perceptual luminance (e.g. ending up with 50 indistinguishable levels of 'too bright', and about 3 levels of useful dimming between 'off' and 'bright', because you used linear colour). If you can't achieve sRGB with a D65 white point, characterise your colourspace so it can be mapped correctly to match the on-screen picker (and to other lightsources).

Clearly I still have to learn a little to make my button look good :D At least I know about logarithmic colour fading, so that's a start. You know any good resources I could use to read up on this?

@EdZ is talking about professional color calibration; same as is used on professional monitors used for color grading. It is becoming more relevant in the consumer space with High Dynamic Range displays that have some level of factory calibration. I have never seen this level of rigor being applied to vanity lighting. I would focus the design effort on finding high quality LED's and incorporate modularity of a Look-Up Table (LUT; found on professional monitors) so they can be adjusted later on.

Best case application of something like this would be to incorporate it into a quality assessment check of the LED's. Set up a rig with a generic colorimeter, insert the button into a custom shroud, and have an automated test that not only checks for the LEDs to be working, but simultaneously determines offsets for the LUT and applies them.

Personally, my highest priority for LEDs on components is having control. I'm good if they are just a single setting of "on" like this:



And please manufacturers, figure out a way to do it wireless. I don't like a USB cable per device or proprietary systems thay you'll abandon in 6 months.

That could be quite a challenge though. You can't really expect every PC to have internal bluetooth connectivity.

Daisy-chaining would probably be optimal for this...no need to high bandwidth or nano-second response rates.
 
  • Like
Reactions: ricochet

zovc

King of Cable Management
Jan 5, 2017
852
602
I'm liking that RGB is starting to be included on components because it in practice avoids the hassle of mounting strips and figuring out how you want to power them. I'm sure that stuff isn't all that hard, but it's another step and it's one I haven't personally taken the dive into.

All the criticism in here seems fair and I absolutely feel @EdZ complaints about the "50 levels of too bright" and three usable ones between those and off. It makes so much sense for there to be a suite of universal software that's got very fine control and hopefully this fairly flexible lighting that tends to keep showing up on components is 'intelligent and/or responsive' to be managed by something like that in the future.

I think complex and flashy patterns are pretty cool looking, but not something I'd want sitting on my desk next to me while I'm gaming or being productive. Probably not even as a decoration in the house while I'm doing other stuff. I like the idea of more tasteful/subtle profiles like a system getting brighter and/or changing to a warmer color as thermals and usage increase.

All that said, I think I've decided to aim for RGB components for my S4 Mini build when the time comes. The very open design case seems like it's begging to have 'visible' and distinguishable hardware in it.
 
  • Like
Reactions: ricochet

|||

King of Cable Management
Sep 26, 2015
774
758
http://www.eizo.com/library/basics/maximum_display_colors/

Your use case may be slightly different from those of monitors. If you're directly controlling the levels by the PWM duty cycle, it may just be a modifier to the frequency. I'm not sure if this could be linear, logarithmic, or something completely else, as it was mentioned that our eyes perceive non-linearly, but the colorimeter may be linear or otherwise (this is strictly for color calibration, not intensity).

P.S. Let's take further discussion to your thread on the RGB Vandal button.
 
  • Like
Reactions: ricochet

EdZ

Virtual Realist
Gold Supporter
May 11, 2015
1,578
2,107
I'm not expecting professional levels of delta-error, but even just knowing the primaries of your LEDs and their voltage/current/PWM (depending on driving mode) response would be enough to get a rough map of the available colourspace. Once you have even a good estimate of the colourspace you can now translate between colourspaces which would greatly ease in matching multiple systems to the same colour.

The short (ish) version is:
The range of possible colours an RGB light can produce is determined by the 'primaries' (the colours of the R, G and B sources). You can think of that range as a 'volume', roughly cuboid, whose corners consist of: pure R, pure G, pure B, white (R G and B at max, AKA your 'white point') and black (R G and B at minimum). Put the black point at the 'bottom', the white point at the 'top', and that shape is the 'colourspace'.
If you imagine the most pure red possible, the most pure blue possible, and the most pure green possible, then you can make a space of all possible colours. This cannot be achieved in reality, because no physical object could produce these theoretically pure colours. We're mapping colour as perceived by the human eye, which doesn't directly correspond to a spectrograph of a given light source.
If you have different coloured primaries, then this cuboid will change shape and move about within that 'full' colourspace.
TV, cinema, desktop monitors, and HDR all have one or more specifically defined colourspaces they are expected to conform to. sRGB is the common one for desktop monitors though sometimes you'll find AdobeRGB, rec.709 for HDTV, DCI P3 for cinema, rec.2020 for UHD, rec.2100 for HDR, etc.
The problem is, the way colour data is stored is not 'here is the exact colour I want to represent with this pixel', but instead 'here is a mix of R, G and B for this pixel'. Notice how we just handed over three numbers without bothering to define colour primaries, or absolute brightness, or whitepoint? This is why it's so hard to get an image on any given screen to look the same as on another: a colourspace is just assumed, and if you assume the wrong one the image is not displayed as intended.
Some displays even deliberately use a 'wrong' colourspace to have punchy saturated colours, or are just unable to actually match any specific colourspace due to poor choice of backlight and/or colour filters and.or phosphors etc.
The generally accepted standard for describing the 'space of all possible colours' is 'Lab colour space. If you know how your system fits into Lab space, then you can use that as a go-between to know your it maps to every other colour space.
If you know what colourspace a colour is stored as (for PC use, assuming sRGB is almost always correct), and know what the colourspace your light source can achieve, you can map one onto another. The actual mapping can either be just a simple intersection (i.e. limited to choosing colours both spaces have in common), or you can clip out any colours that go outside your achievable colour volume, or even 'squeeze' in colours that fall near and outside the edge of the volume. The last option seems initially attractive because it means no sharp transitions if you;re trying to do a fade, but overall it means trying to actually match any given colour is nearly impossible. Think of it like trying to solve the problem of being to tall to fit your entire view in a mirror by bending the mirror and viewing a funhouse reflection: technically solves the problem of fitting everything in, but gives a useless result.

Now, a full Lab representation of an RGB lighting system would be massive overkill. For the forseeable future (any use of non-sRGB colour is still a clusterfuck on PC, let alone HDR), even a rough translation between sRGB and what your LEDs can achieve would but it well beyond the capabilities of any RGB lighting system.

As for how to measure this, my first idea would be to grab the cheapest tristimulus colorimeter* (or spectrophotometer* if one turns up) off of ebay, which will be sold as a monitor calibrator. Pair this with DisplayCal. Because we're only trying to get a relationship with sRGB, we can ignore most of Displaycal's capabilities, and just pretend the LED is a single-pixel monitor.
The way DisplayCal works is to draw a box of a certain colour on your screen. You stick the calibrator over that box, and DisplayCal reads the measurements to tell how far off your display is from the colour it should be showing. The 'hacky' way to make this work to calibrate an LED would be to stick the calibrator on the LED, and 'sniff' that box for the onscreen colour, then set the LED to that colour for the sensor to read. DisplayCal will iterate through a bunch of different colours, then spit out a LUT (Look Up Table) that tells you how to get a desired colour from the actual range the LED can show. Depending on how the LED driver is set up, you could even correct how it drives the LED and recalibrate to get a more refined LUT.

*Tristimulus colorimeter = looks for how much red, green and blue light it can see using filters. Only gives truly correct results for a single colourspace and if the display primaries match those of that colourspace. Great for calibrating an sRGB display to sRGB, won't give quite the right answers in other cases
*Spectrophotometer = compact spectrograph. measures the spectrum of a lightsource. More broadly applicable than a tristrimulus colorimeter, but less accurate.
 

Aibohphobia

aka James
Gold Supporter
Feb 22, 2015
4,956
4,728
So would you guys rather we move the RGB technical details to the RGB button thread or just leave it here?