ayu-xcode-theme icon indicating copy to clipboard operation
ayu-xcode-theme copied to clipboard

Colors look very different to original

Open CodingMarkus opened this issue 4 years ago • 2 comments

See screenshot below. On the left are the correct Ayu theme colors, on the right are the colors from your theme. Those are clearly not the same colors.

Screen Shot 2020-08-10 at 02 28 49

CodingMarkus avatar Aug 10 '20 00:08 CodingMarkus

@CodingMarkus I've used the hex values that were available from the Ayu repo at that time. I'll try to find some time this year to adjust it again, but feel free to open a pull request with the updated color hex values in the meantime.

vburojevic avatar Jun 29 '21 12:06 vburojevic

I think the problem has to do with color space. See, RGB values on their own don't really define a color, the three values are just coordinates into a color space and only in combination with such a color space they define a color. Most apps just use hex tuples to define colors but to which color space do they refer to? A specific one? To a generic one? The native one of your current monitor?

The CSS standard defines that all hex colors used in CSS refer to sRGB color space. This alone will not lead to correct color reproduction, though. Only if your system knows the color space of your monitor, it can ensure that the correct color will appear on your screen by calculating how the color must be altered before display so that your monitor shows exactly the color that has been described in the sRGB color space.

This is what the color picker of Xcode shows me initially when I open it. Note the hex RGB values at the bottom. To what color space do they refer?

on_open

Well, you can open the ... menu to find out:

color_space

"Generic RGB". This is no exact color space at all. It just means to pass the values through to graphics adapter and monitor as they are. Which color will result of doing so is such different from monitor to monitor. These values don't describe any color at all, they just describe a mixture of lights with undefined, device specific outcome.

Now see what happens if I select sRGB instead:

srgb

Note how the hex values are entirely different? Well, yes, the values are, but the visible color on screen has not changed at all. So what Apple did here was to solve the question "Which coordinates would the visible color have in the sRGB color space?" and as you can see, it would have different coordinates.

As my monitor has been calibrated and profiled, my system has an exact profile that tells it how my monitor renders colors. Even if people don't do that, most monitors ship with a built-in profile today that tells the system how the monitor typically displays colors. With that knowledge, the system can modify colors in such a way, that they will appear correctly on your screen, e.g. exactly like the creator of art or a website intended it to look. But this will only work correctly if the system knows to which color space the input RGB values refer to.

If you enter sRGB values but macOS thinks those are Generic RGB values, then these colors become false when being displayed on a profiled monitor. How much they will deviate depends on how far you monitor display is away of Generic RGB. I think you need to ensure to select sRGB every time before you enter a color, at least when you take the values from an sRGB source like a website. This seems to work for example when taking the values of a VSCode theme since Electron apps are essentially just websites displayed inside an app window and so the CSS color rules will apply.

CodingMarkus avatar Jun 29 '21 13:06 CodingMarkus