Before all the editing programs started implementing color management, life was easier in the digital darkroom. Ignorance was bliss, and I was blissfully unaware that the colors I saw on my monitor weren’t likely to match the colors that would be displayed on anyone else’s monitor. - Elle Stone, Nine Degrees Below
I had two minorly aggravating problems this weekend:
-
Colors didn’t match from monitor to monitor. I copied hex values (like
#RRGGBB) from my macbook to my Linux desktop but they were noticeably different. -
Looking at the output of my path tracer, I couldn’t tell if I was handling gamma correctly or if my display was inaccurate.
I ended up calibrating my monitors with a borrowed colorimeter. I didn’t really understand color management, so I thought “What a great opportunity to figure out what these color profiles sRGBs and things actually mean” but oh boy, color management is nuanced and hard. Here’s what I’ve been able to piece together so far.
All the colors
Here’s a visualization of ALL THE COLORS an average human can see.
All the colors (sort of, it’s a 2d plane of a 3d color space). Corresponding wavelengths around the edge. From Wikipedia on the CIE1931 color space
This is one of the CIE color spaces. I still haven’t internalized the different CIE spaces, but the gist is they are mathematical models of color.
Devices (e.g. cameras, displays, printers) aren’t able to represent the whole color space, they have a limited color range (gamut).
Here’s the sRGB gamut, and my profiled monitor gamut.
sRGB gamut shown by the dotted line compared to the gamut of my profiled gamut of my monitor.
Now importantly, CIE color spaces like CIELAB are absolute (device independent). Each color in the real world has exactly one value in CIELAB.
Other “color models” like RGB, HSX, CMYK are relative (device dependent). For example RGB(255,0,0) might be solid red… but which red? Just between sRGB and my monitor’s gamut you can see the most red corner is different.
There may also be color variations due to:
- different devices (e.g. monitor vs monitor, or print might be more limited than display )
- normal vs wide gamut
- manufacturing inconsistencies
- monitor age
The goal of color management is to achieve consistent color reproduction despite these variations.
What we really need is a frame of reference, a color space, when passing around these relative color values. Then you can not only say this is x% red, but also my reds go up to this ABSOLUTE red. Someone else could then translate your RGB with your color space into a reference color space (e.g. CIELAB) and then translate that CIELAB value into an appropriate RGB value in their color space.
Color Spaces and Profiles
ICC color profiles are a format for describing a color space. When you profile a device, you end up with an ICC profile for it. You might also find them by default on your computer or download them.
With the description of the color space, it is possible to determine the translation between a color space, an absolute reference color space, and then to another color space to get the same color. However, if the gamuts differ, one color may not exist in the target color space, so you have to approximate it (called rendering intents).
sRGB
If unspecified, the universally assumed default color space is sRGB. Notably it defines the specific red/green/blue primaries, the white point (how warm or cool the white is, D6500 for sRGB) and the gamma curve (2.2 - 2.4 for sRGB). sRGB was originally designed as an easily produced color space for CRT monitors. It’s not so great but it does the job.
If you don’t really care about color management, you can hope/assume your monitor color space is close enough to sRGB that translating from sRGB to your monitor color space isn’t significantly different, and just pretend color management isn’t necessary. I’m sure there are some people that are offended I even mention this though.
Profiling
Translating to your monitor’s color space is really only as useful as the monitor profile you have is accurate.
As an example, if a wide-gamut display is incorrectly treated as a normal (sRGB) gamut monitor, colors are much more saturated when displayed. Instead of translating a 100% red sRGB into a lesser relative value in a wide-gamut, it gets sent as 100%.
Profiling is the process of measuring your monitor’s color response to generate an accurate color profile for it. A hardware device, a colorimeter, measures the color output as known values are put on the screen.
Managed Vs Unmanaged applications
Finally, who uses the color profile?
To start off, color management is very OS dependent (for example, I’ve heard OSX handles wider gamuts at an OS level). In Linux, you can set your system color profile, but as from what I’ve heard this only sets a value in X. It is the responsibility of applications to manage color translations. This is common for image editing programs or browsers to support. OSX’s color picker now lets you select a color profile as well, which is pretty neat now that I understand the value of.
As for my original problems, the applications I was working with (alacritty and sxiv) are not color managed! So profiling my monitor did nothing for me? At least now I know it is important to use a color managed image viewer, and there is an sxiv fork.
Ubuntu mentions this in their docs about color management. With the provided test profile to swap red and green, you can see the difference between unmanaged sxiv and managed gnome image viewer.
Managed gnome image viewer (left) correctly uses the test profile, swapping red and green and creating an unpalatable looking coffee. sxiv is unmanaged and does not consider color profiles.
Calibrating
The other side of all this is “calibrating” your monitor, which I’ve been repeatedly told is distinctly separate from profiling. If you’ve noticed, profiling is just about measuring your monitor’s response.
Calibrating it is about modifying your display output, specifically adjusting:
- the white point
- the gamma (tonal response)
- RGB levels, getting “well-behaved” colors (0,0,0 is black, 1,1,1 is white, and if R=G=B it is a neutral gray)
This is done either (or both) by
- modifying the monitor itself (e.g. controls like the buttons on the monitor itself)
- modifying the videocard: basically loads a photoshop-curves-like function that modifies the signal going to the display
Purely for convenience, the videocard settings can be stored in an ICC profile (videocard gamma table (vcgt) tags), but calibration is separate from profiling. You don’t have to calibrate the monitor to profile it, but if you do you should do calibrate first because it will change the color response and you will need a new profile.
Summary
Recap time:
- Devices don’t have the ability to display the same range of colors
- Color models (e.g. RGB) are device dependent
- To be able to reproduce colors from one device to another, you need to be able to translate it between color spaces.
- This is done with ICC color profiles (which define a color space)
- This is only done by color managed applications
- Calibration is separate, it lets your correct some problems like your monitor is too red or has bad gamma
For my original problems, I think calibrating was what helped me, mainly because I had a really really poorly calibrated monitor, especially with gamma.
Because terminals are unmanaged applications, I thought I was out of luck with copying hex values. But I found out I can use OSX’s color picker to show hex values in my monitor color space instead of sRGB. Copying those hex values over to Alacritty was effectively precomputing the color translation.
It worked! The colors are perceptually the same and even if this is more than any sane person would do for a colorscheme, it did confirm my understanding of color spaces!
More
Hopefully that’s a useful starting point to color management. There’s so much more to learn!
Nine Degrees Below has been the most helpful resource I’ve found. It’s approachable, but very thorough and doesn’t hand wave over a lot of the details that some explanations do.