Hacker News Reader

Comment by jiggawatts | Hacker News Reader

This never made sense to me in the LCD era, and I suspect it's a rule-of-thumb that has been inherited from older CRT technology.

CRTs use distinct phosphors for each color, which slowly fade over time, and at different rates.

LCDs typically use color filters, which in most cases tend not to fade. In fact, most LCDs are so consistent that you can use the calibration done by someone else with the same panel model and use it yourself just fine. (The rare exception to this would be LCDs exposed to direct sunlight. Strong UV light can make just about anything fade)

OLEDs fade, much like CRTs, but are very rarely used as PC monitors.

This is why it annoys me that LCD panels don't simply report their ICC profile to the operating system. It would be 99% accurate 99% of the time. This is a vast improvement over the current status quo, where color reproduction outside of premium televisions is basically random.

View on HN

My experience here is that the OSes are the problem. They provide an API that looks like "please display the following (r, g, b) tuple". Unfortunately, that isn't enough information to accurately display a color. To turn an (r, g, b) tuple into a color, you have to assign it a colorspace, and that's where everything is broken.

For example, when I last punished myself by using a better-than-sRGB monitor, I learned that browsers will properly color correct images that have a colorspace tag, but they do not do it to CSS. So if you have an image with color #abcdef and then you set a CSS color to #abcdef, they will be different colors!

Applications that want to properly display color have to hack around things. They need to ask the OS for the display's colorspace, then they have to figure out the image's color space, then compute a transformation that will yield an (r, g, b) tuple that when transformed by the OS (using the monitor's profile) will display the right color. This is horrifying but does work; so at least things like Photoshop can typically show you the right color.

It would be nice if we could use more than 24 bits for color and just stored everything as a CIExyz color. People have known that that is the right solution for decades but nothing has happened, so I'm not holding my breath. Realistically, I think we have to agree on a new set of primaries and gamma, and start assuming that a (r, g, b) tuple is in that colorspace. I guess this is what DCI-P3 is. It is the same problem all over again, but might at least get people better colors soon.

Throw "rendering intent" into the mix then it all gets pretty messy.

>LCDs typically use color filters, which in most cases tend not to fade.

The older LCDs were backlit with (cold cathode) fluorescent lamps, and those lamps do fade out and shift in color over time. With those you do want to adjust calibration once in a while. No idea how modern LCD backlit ones fare in longer run.

At one point I've had two decent quality CCFL LCDs set side-by-side; one had about 10'000 hours, the other 40'000 hours. The difference in color (and in brightness) was notable, and not quite possible to get right with the basic RGB calibration provided.

Color filters may not fade, but backlighting uses white LEDs that do use phosphors that fade over time, except perhaps the quantum dot variety.

The panel may have consistent color, but the backlight does not, whether it is led or the older cold cathode.

Reply on news.ycombinator.com