SoK/2020/StatusReport/lsegovia: Difference between revisions
(Initial status report) |
mNo edit summary |
||
| (2 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
== Supporting Floating-Point Color Space Operations in Krita == | == Supporting Floating-Point Color Space Operations in Krita == | ||
[[File:Color adjustment Lab a.png|x250px]] | |||
[[File:Colorpicker_CMYK.png|x250px]] | |||
[[File:Specific_color_selector_CMYK.png|x250px]] | |||
=== Synopsis === | === Synopsis === | ||
| Line 39: | Line 43: | ||
(waiting for review on the pull request) | (waiting for review on the pull request) | ||
==== Week 4 ==== | |||
Feature was merged ([https://invent.kde.org/kde/krita/merge_requests/231 !231]), with [https://invent.kde.org/kde/krita/commit/7c6c1cfa38a43550e5eed0b883aacee79d4e0464 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 [https://invent.kde.org/kde/krita/merge_requests/241 !241], [https://invent.kde.org/kde/krita/merge_requests/242 !242]. | |||
[https://phabricator.kde.org/T12657 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. | |||
==== Week 5 ==== | |||
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 [https://invent.kde.org/kde/krita/merge_requests/243?commit_id=f70937d285bf78495b09b7804109aaf83ecbfb99#note_30404 this comment]). | |||
The relevant pull request is [https://invent.kde.org/kde/krita/merge_requests/243 !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. | |||
=== Contact details === | === Contact details === | ||
Latest revision as of 22:24, 15 February 2020
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.
Week 5
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.
Contact details
- IRC: amyspark @ freenode
- https://invent.kde.org/amyspark
- There is a copy of the proposal at my portfolio (amyspark.me)