Ready for testing. SDR -> HDR with experimental:hdr = 1 should have correct colors but has some weird flickers. HDR -> SDR should work fine. Fullscreen apps should work the same.
Blur, fade animations, dimaround, custom screen shaders and external CM plugins might be broken.

Hi @UjinT34 , I tried to build from this branch but it crash on start up.

[ERR] Failed to link shader: Screen shader parser: Error compiling shader: 0:208(23): error: no matching function for call to `sqrt(int)'; candidates are:
0:208(23): error:    float sqrt(float)
0:208(23): error:    vec2 sqrt(vec2)
0:208(23): error:    vec3 sqrt(vec3)
0:208(23): error:    vec4 sqrt(vec4)
0:208(11): error: operands to arithmetic operators must be numeric
0:208(7): error: no matching function for call to `pow(error, vec3)'; candidates are:
0:208(7): error:    float pow(float, float)
0:208(7): error:    vec2 pow(vec2, vec2)
0:208(7): error:    vec3 pow(vec3, vec3)
0:208(7): error:    vec4 pow(vec4, vec4)

hyprlandCrashReport180489.txt

just curious question: why are you not using lcms2 like gamescope or weston?

just curious question: why are you not using lcms2 like gamescope or weston?

No idea how to use it in our case. Might be useful for some matrix calculations but most of the work is inside shaders

seems like this lib support icc, might be useful for next iteration.

Is it expected for non-HDR content to be really dim when HDR is active? The colors are still correct and look like they do when cm is set to wide, but wide is a bit brighter for SDR content. When cm is set to hdr, the cursor and window borders are very bright, but everything else (except for HDR games) is dim.

Is it expected for non-HDR content to be really dim when HDR is active? The colors are still correct and look like they do when cm is set to wide, but wide is a bit brighter for SDR content. When cm is set to hdr, the cursor and window borders are very bright, but everything else (except for HDR games) is dim.

Default white brightness is only 80. Seems to be low for most cases. Will add a configurable multiplier in the future. Borders, hw cursor, blur and some other stuff doesn't have a CM atm.
HDR content should look fine with every setting combination (sdr/hdr and windowed/fullscreen). With HDR output mode SDR content which goes through CM will be too dim and which doesn't will be too bright.
With the current state it is better to have non-hdr cm and render:cm_fs_passthrough = true.
For now cm,hdr or cm,hdredid can be used with render:cm_fs_passthrough = false to test conversion from content HDR settings to reported monitor HDR capabilities.

I replace 80 to 300 and it looks better. But I agree, configuration like sdrnit would be nice.

Hi,

I installed hyprland the other day for the first time and I've been testing this out for a bit.

Seems to be a lot better than the previous experimental:hdr = 1. Setting SDR luminance to 300-400 makes the image bright as it should be.

Should this map SDR programs correctly to BT2020? My browser (and possibly other SDR programs (?)) still seem too saturated. At least oranges seem too red. I don't know color management and color spaces well enough to figure out what exactly the problem is. What I've gathered:

• sourcePrimaries seem to be sRGB. targetPrimaries are BT2020.
  • Tried logging these before render.
• The shader code converting primaries seem to be running
  • Played around with the shader code and changing convertPrimaries does affect the image
• On chromium, forcing color profile to ITU-R BT.2020 seems to fix the colors (Quite sure sourcePrimaries still evaluates to sRGB).
• Alternatively, setting gamut on my TV manually to "Adobe RGB" (only other option the settings menu has), seems to fix the color (or at least it is much closer to what I think it should).

Is this just how it is supposed to work, or are the primaries not being mapped correctly? Maybe it is just the browser doing weird things (?). Though I do not really understand, how would a client outputting sRGB end up looking too saturated on a wider gamut monitor. If the colors are correctly mapped.

I've tried several simple SDR brightness modifications. The image becomes brighter but I don't like the resulting quality. Probably needs a more sophisticated approach than simple multiplication.

A client outputs an integer value. Maximum red in sRGB and maximum red in BT2020 will have the same value. But should look different. convertPrimaries should change an sRGB maximum red to closest similar looking value in BT2020 which is lower than maximum. Current implementation does that but the effect is very subtle for some reason. Might be some issues with drm properties which aren't touched by this PR.
Chromium with forced BT2020 probably does its own conversion reducing the values and then they are reduced again by HL.

@9oOzv primaries conversion should work better now

@9oOzv primaries conversion should work better now

Great. I think it looks closer now.

Though I do still notice some weird tint here and there compared to all my SDR monitor. Some pinks tint towards orange. Some skin tones towards green (I think... quite difficult to say actually other than it looks a bit off still). Different enough for me to believe it is not just calibration issues.

Nonetheless, I think with the addition of 'sdr brightness' setting, I think this would make Hyprland much more usable on HDR monitors.

iirc Plasma has values for sdr brightness and color intensity. This could (at least temporarily) take the burden of calibration away from the maintainers. Making strongly recommended defaults for calibration but letting them be configured could be an easy "out" in terms of figuring out details. But this is just my two cents, and I'm a total compositor/c++ noob

I think having color intensity config for SDR would be nice at some point, as sRGB colors, even if correctly mapped, can look disappointingly unsaturated compared to wide gamut content on the same screen,. Or compared to the regular SDR monitors, that we are used to and often are much more saturated.

But getting the primaries conversion correct should probably be the first step. I do not think it is correct quite yet, but I cannot tell for sure just by looking at the picture.

general/total brightness is very low, even if colors are improved since the last commit (at least on my monitor)

At this point I am pretty sure that conversion between primaries with the same white point is correct. No white point compensation for now. Other stuff which happens before and/or after the conversion might throw it off.
10bpc is not enough to map all 8bpc sRGB values to 10bpc BT2020. Some precision will be lost in favor of wider range.

Added two new monitor rules to control SDR -> HDR brightness and saturation. bitdepth,10,cm,hdr,sdrbrightness,1.2,sdrsaturation,1.0 works for me.

With the latest changes, the saturation when using auto or wide seems to have been greatly reduced. The colors are very vivid if I roll back to (58cb7e7).

Update:
Regressed by ecb62f2

With the latest changes, the saturation when using auto or wide seems to have been greatly reduced. The colors are very vivid if I roll back to (58cb7e7). I'll try to bisect in a bit.

Vivid colors are oversaturated. You might have some monitor settings that compensated that oversaturation and now they cause undersaturation.

I probably should have described the issue differently. Colors appear to have a yellow tint to them after that commit. For example, shades of pink tends to look like a peach color now.

Btw, I check my TV's color settings, and changed the color gamut and gamma curve values and they didn't have an effect on this.

Rebased on latest main with some cm proto fixes

@vaxerski I guess it's time to review this, it's getting too big and not that simple

sRGB colors look correct to me now. I don't see any other problems either.

I think sdrbrightness is affecting alpha as well. At least transparent windows seem to get less transparent with higher brightness.

I think sdrbrightness is affecting alpha as well. At least transparent windows seem to get less transparent with higher brightness.

Should be fixed in #9600

thank you!

Hi @UjinT34 I got some performance issues starting from these commits #9641. I hope I can get some insights. Thank you.

About the sdrbrightness, would it be possible to have it in nits instead? The factor makes it confusing and dependent of the default value.

Great work, I've really been looking forward to this feature. I just installed the new release and configured my monitor. Looks great, but I'm noticing an issue with the black levels.

#9716

Maybe I'm missing something simple, but I'm seeing window borders and cursors rendered much more brightly than other SDR content. For instance, with this rule:

general.col.active_border = rgba(33ccffee)

And a blank webpage with this style:

body {
  background-color: #33ccffee;
}

Here's a photo where you can see the difference between the border color and the webpage color.