Fix hdr canvas decorations

This MR tackles #46 (closed)

For the opengl canvas, we convert to the display color space, then normalized channel values and get a qcolor from RGBAF. This latter one is important, because our default KoColor::toQColor assumes that we want to convert to sRGB first.

For the color sampler, similar, though we convert via the display color converter. This function is generalized in the display color converter, together with functions that process the HandlePainterHelper palette and the UI palette. These are then made available via KoColorDisplayRendererInterface, which in turn is funneled into every place where we draw onto the canvas. The result is that all canvas decorations are converted appropriately.

Some notes:

  • Reference Images are limited to sRGB right now, and it would probably make sense to tackle these after making our vector system color managed. This is outside of the scope of this MR, and this MR remains an improvement over the current situation.
  • The diffuse white problem, as identified by #95 is also extended to the canvas decorations, but because we cart around KoColorDisplayRendererInterface, there's now only a small amount of places we might need to modify once we figure out how we want to handle this.
  • When we have a preview of something directly on canvas, like the color picker colors or the transform tool preview, we also filter it through OCIO, so that matches. Other colors are not filtered, as it feels unintuitive.

Todo

  • OpenGL tool outlines
  • Color picker
  • Vector outlines (requires handle painter helper modifications)
  • transform
  • crop tool
  • selections
  • assistants
  • reference images (this is slow, though... we might need to find a better solution)
  • enclose-and-fill freehand.
  • smart-patch
  • oncanvas toolbars (requires handling QPalette better(?))
  • Grids and guides
  • All miscelaneous canvas decors like the infinity manager, fps decor, mirror axis, etc.

Test Plan

  • Open Krita with wayland/windows on an HDR enabled device.
  • Open a HDR image.
  • Then test...
    • Transparency checkers
    • Tool outlines (freehand brush, rectangle tool, etc)
    • Color sampler.
    • Check the commits for other things to test.
  • do the same on a non-HDR enabled krita.

Formalities Checklist

  • I confirmed this builds.
  • I confirmed Krita ran and the relevant functions work.
  • I tested the relevant unit tests and can confirm they are not broken. (If not possible, don't hesitate to ask for help!)
  • I made sure my commits build individually and have good descriptions as per KDE guidelines.
  • I made sure my code conforms to the standards set in the HACKING file.
  • I can confirm the code is licensed and attributed appropriately, and that unattributed code is mine, as per KDE Licensing Policy.
  • Does the patch add a user-visible feature? If yes, is there a documentation MR ready for it at Krita Documentation Repository?
Edited by Wolthera van Hövell

Merge request reports

Loading