Why does the same colour appear different in different apps?

Question

I've configured VSCode and iTerm2 to use the Solarized Dark colour scheme.

As far as I can tell, they are both using the same RGB colour specification for the background colour, but to my eye they appear slightly different.

I used Digital Colour Meter to inspect both windows, and found that in sRGB they both report (0,44,55), while in "native values" VSCode reports (0,43,54), while iTerm2 reports (13,43,54). See pictures below.

• Why does this discrepancy exist?
• What are "native values"?
• Can I get these apps to look the same?

Answer 1

The discrepancy exists because something/someone messed up handling of color spaces and/or color profiles.

A very short and crude explanation:

Colors on computers are expressed as numbers - for example here as RGB with each color ranging from 0 to 255 (i.e. 24 bit color).

Computer displays are not all alike - they can display different ranges of colors. This doesn't mean that some displays do not display anything when asked to show certain combinations of R, G and B. Instead a different color will be displayed. These are called "native values".

If you choose a certain color on your computer display and send that color code to your neighbour - you would ideally want him to be able to see the same exact color on his computer. If he has a different type of display, chances are that he would see a completely different color (here we're not even taking into account calibrating individual displays of the same type).

In order to solve this problem, you have the concept of color spaces and mappings between them:

When you create the original color codes, you have to specify in which colour space you have defined them. I.e. for example define that the background color of this theme needs to be RGB (0,43,54) in sRGB. This is exactly what the Solarized Dark theme does.

When you create a program to load in color codes, you'll need to take into account the color space of the color codes you read from an external source. I.e. the program needs to convert or map the color code from the colour space of the original file into an internal representation.

Furthermore when that program wants to display the color on screen, it needs to map it to the color space of the connected monitor.

To show an example: Imagine you're using a MacBook Pro with a color space of Display P3 and load in the color RGB (0,43,54) in the sRGB color space.

If you look at an illustration of color spaces, you'll see that Display P3 is "larger than" (i.e. fully includes) sRGB. Therefore if something is defined as having a red value of 255 (max) in sRGB, it needs to have a lower value when mapped to Display P3 in order to leave room for those extra colors that Display P3 can display that aren't included in sRGB.

This means that (0,43,54) will need to be sent out to the display as a "darker" color code in order to achieve the same physical color when viewed by a human.

In addition to this color space management, there is the variation between individual displays of the same type. It is simply not possible to produce displays at the costs consumers are used to that are exactly alike in color reproduction.

Therefore the displays are "calibrated" - meaning that their actual displayed colours are measured and compared against what they were supposed to be displaying - and a mapping to compensate for that discrepancy is made. That is stored as a "color profile" on your computer.

If a program doesn't support color spaces when reading in colours or when displaying them, or it doesn't support color profiles correctly - then you can end up with situations like this where the same color is displayed differently in different applications.