True Color and Display P3 colorspace #2665
Replies: 1 comment
-
It might be useful to add this to #2125. I think this feedback belongs there and is close enough to a dupe. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Ghostty has an option to change the window colorspace from sRGB to Display P3 (on macOS). This is neat, but it does have a drawback, which is that it breaks the notion of truecolor. The point of truecolor is that by specifying RGB values, the colors look the same everywhere. But when you set
window-colorspace = display-p3
, truecolor colors are now interpreted as Display P3 colors instead. The simple answer is to always interpret truecolor colors in sRGB even when the window colorspace is Display P3, but then the question arises of how to then use Display P3 colors, when the terminal application doesn't know what the palette is set to.I don't think there's any particularly good answer here, and I don't know what to suggest for how to handle this. We could just ignore it and say anyone who sets their colorspace to display-p3 gets the wrong truecolors, but that is a bit weird. Unfortunately there's no room to smuggle colorspace info into the truecolor escape. We could propose a brand new escape that includes colorspace information, but that wouldn't be compatible with any other terminal and feature detection would suck (I imagine most code testing
$COLORTERM
is looking for the exact value"truecolor"
). We could propose another escape that simply changes the colorspace for subsequent truecolor escapes, though that would be another piece of state to forget to unset. I'd suggest that it just affects colors within the current CSI sequence except I'd have to assume other terminals bail on the whole sequence if they don't recognize the parameter.Perhaps the best option I can think of is to say that if you use the truecolor escape and simply specify values outside of the 0–255 range then those values get converted into Display P3. The problem with this approach is extra range goes in both directions,
rgb(0, 127, 127)
in Display P3 is actuallyrgb(-62, 130, 129)
in sRGB, and I expect most terminals to bail on the color escape if it sees a hyphen, so it's not portable. But it's better than nothing, and it has the strong benefit of being entirely compatible with the idea of "treat the truecolor escape as sRGB" because all it does is say you can specify components as being outside of the 0–255 range as well, and the conversion from sRGB to Display P3 using those extra values will simply work. A downside is that today both Ghostty and iTerm simply truncate extra components to 8 bits so colors that appear to work today will change behavior, but nobody should be emitting colors outside of the 0–255 range anyway. Another downside here is this hardcodes the assumption that Display P3 is the only RGB colorspace outside of sRGB that we care about.Tip: macOS ships with a tool called ColorSync Utility that you can use to explore this kind of colorspace conversion. Here's a screenshot of the calculation it did for the above colorspace conversion:
Beta Was this translation helpful? Give feedback.
All reactions