Jump to content

SoK/2020/StatusReport/lsegovia

From KDE Community Wiki

Supporting Floating-Point Color Space Operations in Krita

Synopsis

Krita is a professional, free and open source painting suite that allows concept artists, texture and matte painters, as well as illustrators to deploy their full creativity towards production of high quality art pieces.

High bit depth color spaces are essential to feature-level production pipelines. The recent introduction of HDR, supported by Intel, is a great stride towards this objective. However, there remains a critical, unfixed issue: support of color space operation across all numeric representations.

In T4488 Wolthera van Hövell detailed how Krita assumes that all floating-point color spaces assume a range [0.0, 1.0]. This is correct for all cases except two: CIE’s 1976 La*b*, and CMYK. The first one is usually assumed to be in the range of L = [0.0-100.0], a, b = [-128.0, 127.0].

Currently, color spaces are defined in a multitude of files, notably subclasses of KoColorSpace and KoColorSpaceTraits; the latter contains the operations detailed above. This project proposes to unify all color space data and operations, while introducing support for custom value ranges, so as to properly support all color spaces through the same API. Additionally, we plan to allow unbounded operations so as to support HDR.

Testing would be implemented by checking known conversions between La*b*, CMYK and RGB.

Mentor

Weekly Progress

Week 0

  • Set up development environment in macOS
  • Reviewed old work I did on the subject

Week 1

  • Set up development environment in Manjaro Linux, my desktop has more oomph.
  • Finished day job's tasks prior to holiday

Week 2

  • Re-merged KoColorSpaceMaths work for current master
  • Changed KisSpinboxColorSelector to request channel bounds prior to processing the value. The spinbox receives values in the interval [0, 1] from the KisVisualRectangleSelectorShape, so KoChannelInfo needs to yield the interval length too.
  • IccProfile now uses INTENT_ABSOLUTE_COLORIMETRIC to calculate the profile bounds.
  • Changed lcms2engine's floating point colorspaces to map values like KisSpinboxColorSelector: colorTo/FromXML.
  • Submitted pull request to boud: https://invent.kde.org/kde/krita/merge_requests/231

Week 3

(waiting for review on the pull request)

Week 4

Feature was merged (!231), with a typo that needed a quick commit straight to master. After discussing it on IRC, we constrained the scope of this project to bugfixing the feature and listing which places in the codebase cause clamping in HDR.

Bug reports were addressed in !241, !242.

T12657 lists the functions that clamp colors in HDR. Enumerating all the lines turned out to be far too long, so I chose to write down just the necessary bits for a grep.

Contact details