Test image for (sRGB) gamma calibration: http://imagezero.maxiom.de/files/sRGB-gamma.png

If you see squares in the squares, gamma is not correct. Needs to be displayed unscaled, or upscaled with box filter.

In T4465#129202, @cfeck wrote:

Test image for (sRGB) gamma calibration: http://imagezero.maxiom.de/files/sRGB-gamma.png

How is this supposed to work? I see inside squares all the time (trying different Gamma values with KGamma on X session).

I use a 33 point custom curve loaded via XF86VidModeSetGammaRamp, not a single value. Today's displays need some 'S' shaped curve, but unfortunately needs fine tuning for each display.

After much research my current plan looks like this:

• add color intensity ramps to outputmanagement Wayland interface [1],
• libkscreen using above interface to exchange values,
• KScreen for saving these values,
• libcolorcorrect via libkscreen providing means to change output color ramps via gamma value setting and curve interpolation similar to how graphics editors do it (for example Krita [1]),
• separate KCM to do this in gui or integrate into the Displays KCM.

[1] https://cgit.kde.org/kwayland.git/tree/src/client/protocols/output-management.xml
[2] https://docs.krita.org/Adjust#Color_Adjustment_Curves

The patch to KWayland D12388 for arbitrary color curve manipulation has a problem from the start: Wayland protocol messages can only be max 4KB. Sending an array of 256 16bit colors is this. But what if a hardware supports finer curves?

It might make more sense to support wlroot's wlr_gamma_control_unstable_v1 protocol, which hands over the color curves via file descriptor.

Mistakenly moved the task to Done on Plasma on Wayland board? The task is not yet fully done.

Besides night mode and color correction this can also help test how something looks for different types of colorblindness, it can make it easy to make sure everything looks nice in those cases.