This reminds me that you should frequently calibrate your display’s color profile if you ever work with photos or video. There are commercial products that help you do this essentially by the process that the OP uses. They don’t do a whole screen, just a section of it. And it seems that the new MacBooks have some kind of calibration thing that responds to ambient light. But it would be nice to be able to do this as a standard thing on all displays.
Eizo sells monitors for color sensitive work which contain built in calibration probes that pop out of a hidden compartment. They can be set to recalibrate on a schedule. They are pretty neat.
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.
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.
>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.
My fairly modern (2017) Thinkpad P71 has a place for one (unfortunately no module in it though, a con of buying used). The latest versions of the same line have it as well.
