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
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.
By fixing this, Krita will be able to faithfully execute mathematical operations across all supported color spaces, both floating as well as fixed-point.
- Set up development environment in macOS
- Reviewed old work I did on the subject
- Set up development environment in Manjaro Linux, my desktop has more oomph.
- Finished day job’s tasks prior to holiday
KoColorSpaceMathswork for current master
KisSpinboxColorSelectorto request channel bounds prior to processing the value. The spinbox receives values in the interval [0, 1] from the
KoChannelInfoneeds to yield the interval length too.
INTENT_ABSOLUTE_COLORIMETRICto calculate the profile bounds.
lcms2engine’s floating point colorspaces to map values like
- Submitted pull request to boud: !231
(waiting for review on the pull request)
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.
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.
Project was successfully completed!
Matthias Wein found a bug in the normalization code, where it assumed the wrong range for the channels. Additionally, they realised Krita uses ICC v4 for the Lab color space profile, which has a lopsided range for the a* and b* channels (see this comment).
The relevant pull request is !243: I fixed the normalization code, deleted a whole chunk of unnecessary overrides, implemented ICC v4 for the channel boundaries, and made them usable by the UI controls.