sway/commands/output: Add command to set color profile

[mstoeckl]

This PR matches the very WIP wlroots MR 4280.

This requires the Vulkan renderer to be useful. (Use WLR_RENDERER=vulkan ; setting VK_INSTANCE_LAYERS=VK_LAYER_KHRONOS_validation to enable validation layers may be useful for testing.)

Example usage:

swaymsg output '*' color_profile icc /usr/share/color/icc/colord/ProPhotoRGB.icc

Known issues:

• some race condition in which only some frames render correctly; causes flickering (fixed)
• Only applies with bit depth 10, at the moment (fixed)
• Having to copy the struct wlr_color_transform a number of times is awkward (now using reference counting)

[emersion]

Mostly minor comments, overall looks good

[emersion]

How does this interact with HDR? I would assume that ICC is incompatible with HDR.

[mstoeckl]

I don't know; I made this PR mainly to test the wlroots MR, and do not know what a good command interface for the long term would look like. Marking this PR as draft until this gets figured out; maybe the answer will be that, like render_bit_depth, this is a short-term approach to be replaced later.

[mstoeckl]

I've added a warning that setting a color profile may have odd effects in conjunction with HDR.

Color profiles probably still have a meaningful interpretation even when when the HDR metadata is being sent to a display -- I believe the main difference is that the monitor handles pixel data differently in HDR mode, using absolute luminance, and uses PQ EOTF instead of approximate-sRGB. For example, it should still be possible to use color profiles to correct for monitor miscalibration; or just to apply general color transforms (e.g.: adjusting contrast, making everything brighter, rendering in grayscale, applying hue shifts -- although it might be cleaner to have such color changes be handled with a separate command, using 'Abstract' instead of 'Display' ICC profiles.) Of course, due to the difffering EOTFs being applied by the monitor, any profile used for SDR would produce invalid output for HDR.

[emersion]

CI is unhappy it seems like, I think we need to add #ifs (that's a bit cumbersome) and missing deps in CI manifests?

[emersion]

Can we #undef _POSIX_C_SOURCE if we need _XOPEN_SOURCE? Otherwise we provide two feature test macros and they potentially conflict (in which case what we get is implementation-defined).

[mstoeckl]

I don't think _XOPEN_SOURCE is needed at all -- this code has been edited a lot since its original version -- so I just dropped this.

[emersion]

Style nit: stray newline it seems?

[mstoeckl]

Yes, fixed.

[emersion]

Typo: "it only works with the Vulkan renderer."

[mstoeckl]

Fixed.

[mstoeckl]

I think we need to add #ifs (that's a bit cumbersome) and missing deps in CI manifests?

I've added missing dependencies for lcms2, so that the wlroots build (and by extension the sway build) uses color management features.

I have not yet made it possible to build this without lcms2 support, and will update this PR eventually to do that.

[GreyXor]

Tested it on my Framework 13 AMD. Seems to work as expected 👍

Just an idea, would it be reasonable to be able to unset a profile as well? By unset, I mean returning to the same state as if I'd never called the color_profile command.

Maybe something like: swaymsg output '*' color_profile unset

[mstoeckl]

Just an idea, would it be reasonable to be able to unset a profile as well? By unset, I mean returning to the same state as if I'd never called the color_profile command.

The default profile is srgb, and one can go back to it with:

swaymsg output '*' color_profile srgb

[Riptils]

Hi, I correctly set my icc profile but when swaylock is triggered from swayidle (via killall -USR1 swayidle or when the swayidle timetout's reached). I see a little square:

this not happening if I directly start swaylock from terminal (or if i'm not setting the icc profile).
Thanks AMA if I can help with this issue

[emersion]

I have not yet made it possible to build this without lcms2 support, and will update this PR eventually to do that.

I've been wondering whether we should always make wlr_color_transform available regardless of LCMS availability. I think it depends if we want to base all of our color pipeline on LCMS (Weston-style), or if we want to implement this ourselves.

when I launch swaylock through swayidle I have a smal square around the circle

Weird, the ICC profile should only affect the final post-blending image. Maybe there is a small difference not noticable without the ICC profile applied, which becomes visible once the ICC profile is applied?

[mstoeckl]

I've been wondering whether we should always make wlr_color_transform available regardless of LCMS availability. I think it depends if we want to base all of our color pipeline on LCMS (Weston-style), or if we want to implement this ourselves.

I've also been considering this: 1) one might want to use CICP tags to pick output color profiles (e.g. to work with HDR10) in which case one can do color management without LCMS 2) the use of LCMS in wlroots is already confined to converting ICC file data to wlr_color_transform, and may be a more natural boundary.

[emersion]

Right. AFAIU, Weston plans to translate the CICP stuff into LCMS pipelines (with the float point number transforms that nobody uses in ICC). Other compositors seem to do math in shaders.

[GreyXor]

Hi, I correctly set my icc profile but when swaylock is triggered from swayidle (via killall -USR1 swayidle or when the swayidle timetout's reached). I see a little square:

this not happening if I directly start swaylock from terminal (or if i'm not setting the icc profile). Thanks AMA if I can help with this issue

I have the same issue :

recording.webm

and also, it's as if every time I write on the keyboard (i.e. when the circle is modified) the ICC profile is deactivated/activated. Or something like that

[kennylevinsen]

@GreyXor, @Riptils, do you see the issue if you run sway with WLR_SCENE_DISABLE_DIRECT_SCANOUT=1? The color transformation does not apply to direct scanout.

[GreyXor]

@GreyXor, @Riptils, do you see the issue if you run sway with WLR_SCENE_DISABLE_DIRECT_SCANOUT=1? The color transformation does not apply to direct scanout.

Thanks, yes I still have the same issue

[Riptils]

I still have the issue, even with the env var

[emersion]

Ref https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/4692

[emersion]

Now that the wlroots patch has been merged, just need to guard wlr_color_transform_init_linear_to_icc().

[mstoeckl]

just need to guard wlr_color_transform_init_linear_to_icc().

This is already done: wlroots compiles it to a NULL-returning stub, and the code checks for an returns an error on a NULL return value.

[emersion]

Oh right, didn't even remember about the patch I wrote.

[emersion]

LGTM

Is there a reason this is still marked as a draft?

[mstoeckl]

Is there a reason this is still marked as a draft?

No; as this is no longer waiting on wlroots changes I have marked it as ready.

[emersion]

Thanks!