Implementation ideas for HDR colorspaces

[Stealthii]

I've been interested for a while in utilising HDR colorspaces on supported monitors within terminal emulators, and was reminded of such when noticing the macos_colorspace config option in kitty.

Questions around why this would be useful in an application already struggling with widespread SRGB adoption boils down to two use-cases:

• The ability to use actual dull/bright colors within colorschemes representing the same color
• The ability to use "brighter" rendering for bold as opposed to a differently weighted font

Kitty has quite a wide and well supported set of advanced terminal features already including ligatures, graphics, etc. and having a discussion around proposed ideas for how HDR support within Kitty should and could be used can help set Kitty even further apart in its feature set. I'm interested in other use-cases and configurations people might have as well!

[Stealthii]

Another thought: if we wanted to extend the use of perceived brightness rendering to terminal applications themselves (by further extending Kitty's changes to the xterm set), we could propose additional escape sequences to Bold/Italic such as Bright/Dim (allowing for the likes of "dim bold" and "bright italic".

Whilst I believe there are more use-cases where users would want to impact existing rendering (bright over bold, etc) due to a lack of any native support for this across the stack at present, I'd like to see options for this considered in implementation proposals.

[kovidgoyal]

bold as bright is never going to be in kitty, search the closed issues for why. You can already have dim versions of any colors and bright versions of the basic 8 colors. There is even a separate escape code for dim which can work with italic/bold independently. I suggest you read: https://en.wikipedia.org/wiki/ANSI_escape_code#SGR_(Select_Graphic_Rendition)_parameters

None of this has anything to do with HDR which is about representing colors with greater precision than 8bits per channel. I have yet to see any compelling use case for why we need this greater precision in a terminal.

[Stealthii]

I understand your stance on "bold as bright", which is why I posted this comment on extending escape codes with HDR equivalents for bright/dim - I apologise for not being clear on this being distinct from existing bright/dim codes.

Putting that aside for now, and considering only the existing implementation as it stands, I cannot define colors outside of the RGB space for my scheme for my display supporting HDR. If you consider that SDR colors within the sRGB colorspace are tone-mapped on displays supporting and showing a wider gamut, then there is a limit to options for perceived brightness. Kitty on macOS currently uses this, whilst other applications can display colours with higher variance in perceived lightness and intensity.

See Chrome's guide to HDR colorspaces in CSS, and Apple's guide to HDR content for examples on how this is implemented in comparison to SDR tone-mapping.

I agree with you that general requirements for "color precision" being extended are low or non-existent - this is a common argument used against even truecolor support in some terminal emulators. My point is that I would love to be able to define colors with a much wider perceived brightness than what SDR tone-mapping currently offers - if we assume for reference that an sRGB "Red" (255, 0, 0) has an intensity of 100%, well then I'd like my "bright" red to have an intensity of 150%.

Kitty has provided many features other emulators refuse like ligatures, graphics, etc. and with many displays now supporting wider gamuts by default, it would be nice to see support for this in Kitty's rendering pipeline so that higher levels of "perceived brightness" compared to SDR content can be achieved if so desired via config.