Colors not recreated perfectly due to color space

[IlanCosman]

A number of the builtin themes seem to be out of date.

For example, builtin dark theme in iterm2 has it's red set to c91b00, but that hex value does not appear anywhere in the builtin dark theme in this repository.

https://github.com/mbadolato/iTerm2-Color-Schemes/blob/master/xfce4terminal/colorschemes/Builtin%20Dark.theme:

#000000;#bb0000;#00bb00;#bbbb00;#0000bb;#bb00bb;#00bbbb;#bbbbbb;#555555;#ff5555;#55ff55;#ffff55;#5555ff;#ff55ff;#55ffff;#ffffff

[mbadolato]

It could be something with the translation scripts since they all use different formats. The conversions are done from the iterm version (which doesn't have hex values per se) to xrdb then a lot of the converters use though. It could be slight differences in formats etc.

The question is, does the xfce version you're referencing resemble the iterm version when each is in it's respective terminal?

[IlanCosman]

The question is, does the xfce version you're referencing resemble the iterm version when each is in it's respective terminal?

It's close, but independent color-picker gcolor2 shows that xfce terminal is in fact displaying the hexes it says it is.

Independent color-picker digital color meter on macos, in sRGB color space, shows that iterm2 is also displaying the colors it says it is. (almost, sometimes off by a few points, e.g. iterm2 says 2 red, color meter says 5 red).

I think we can conclude therefore that there is a problem somewhere in the pipeline. Not a major one though, the colors are quite similar, but still.

[mbadolato]

Interesting. Unfortunately, unless someone more knowledgeable than I is able to troubleshoot the conversion scripts, there's not a whole lot I can do. The conversion scripts are all user-provided by others and not my own product. And most are in Python I believe, which I don't speak well enough

[IlanCosman]

Oh, no, I was too quick to jump to conclusions. Your scripts are faithfully recreating the iterm2 specifications, it's that iterm2 doesn't do the same.

For example, the iterm2 specification for Dark Background can be found here: https://gitlab.com/gnachman/iterm2/-/blob/master/plists/ColorPresets.plist#L2993-3202

And it specifies colors that don't exist in the actual palette. For example:

<key>Ansi 1 Color</key>
        <dict>
            <key>Blue Component</key>
            <real>0.0</real>
            <key>Green Component</key>
            <real>0.0</real>
            <key>Red Component</key>
            <real>0.73333334922790527</real>
        </dict>

This implies an R value of 187, a G value of 0, and a B value of 0. If you go to iterm2 and enable the Dark Background color scheme, no such color can be found.

Perhaps it has something to do with color spaces, I'm not sure,

[IlanCosman]

@gnachman Sorry to ping, but could you shed any light on the above? 😄

[gnachman]

If I understand correctly the problem is that when you use the bulitin dark theme from this repo it doesn't indicate that the "Dark Background" color preset is selected in the prefs UI.

I don't know how https://github.com/mbadolato/iTerm2-Color-Schemes/blob/master/xfce4terminal/colorschemes/Builtin%20Dark.theme gets turned into an iTerm2-compatible file, but if it exactly matches the color presets at https://gitlab.com/gnachman/iterm2/-/blob/master/plists/ColorPresets.plist#L2993-3202 then it should work correctly.

But I have a feeling I've misunderstood the actual problem, perhaps because of my unfamiliarity with xfce and other tooling involved here.

[IlanCosman]

Thank for helping out @gnachman 😄

But I have a feeling I've misunderstood the actual problem

I think you did 😄

The current question is described here: #349 (comment)

Basically, how does iterm2 convert

<key>Ansi 1 Color</key>
        <dict>
            <key>Blue Component</key>
            <real>0.0</real>
            <key>Green Component</key>
            <real>0.0</real>
            <key>Red Component</key>
            <real>0.73333334922790527</real>
        </dict>

to a color. The naive approach is obviously to just multiply those values by 255.

But simply by clicking through the colors of Dark Background in iterm2, we can see that there is no color with Green and Blue values equal to 0 (that also has red != 0). The closest would be Dark Red, which iterm2 says has values of R: 201, G: 27, B: 0. So clearly something more complex than multiplying by 255 is going on.

[mbadolato]

I don't know how https://github.com/mbadolato/iTerm2-Color-Schemes/blob/master/xfce4terminal/colorschemes/Builtin%20Dark.theme gets turned into an iTerm2-compatible file

It doesn't. Other way around. One or two of the converters convert originally from the .itermcolors file, then the rest base off of one of those converted files (xrdb I believe but would have to check)

[gnachman]

Basically, how does iterm2 convert to a color. The naive approach is obviously to just multiply those values by 255.

Because no colorspace is given, that is interpreted in the "calibrated" rgb colorspace, which is device-specific. At the AppKit level, colors are in 0…1, not 0…255, so that is the native representation at the app level. Internally, macOS will apply gamma correction and give it to the GPU in whatever format it uses (so 0…255 is irrelevant, as it's either going to be floating point or 16 bit or whatever).

In iTerm2 version 3.4.x and earlier, the UI shows colors in the sRGB color space. These values will always be a little different than the calibrated colorspace, and sRGB may have a larger gamut.

In iTerm2 version 3.5.0 betas, the color space is indicated in the color picker and will use P3 when available.

I would advise you never to leave the colorspace unspecified. sRGB is a good choice, and P3 is also fine (it's only on the most saturated colors that P3 will get clipped on non-P3 displays).

Here's an example from the "Regular" color scheme that shows how to specify a color in sRGB:

        <key>Ansi 1 Color (Light)</key>
        <dict>
                <key>Alpha Component</key>
                <real>1</real>
                <key>Blue Component</key>
                <real>0.16300037503242493</real>
                <key>Color Space</key>
                <string>sRGB</string>
                <key>Green Component</key>
                <real>0.23660069704055786</real>
                <key>Red Component</key>
                <real>0.7074432373046875</real>
        </dict>

The values given are in sRGB but iTerm2 displays values in P3. As you can see, Digital Color Meter confirms they are the same (+/- rounding error of 1):

[gnachman]

And here's Digital Color Meter set to sRGB:

Dividing 180, 61, 42 by 255 gives 0.70, 0.23, 0.16 which is (within the margin of rounding error) what we had in the xml file I quoted above.