GSOC 2016: Make Krita ready for wide-gamut editing.
Open, WishlistPublic


Most consumer screens can only show a limited amount of colour, this we generally refer to as the sRGB space. Wide gamut editing is about editing values in larger spaces of colour(such as Adobe RGB or the ACES colour space) and emulating how that looks on the screen.

Currently, Krita’s architecture has all the bells and whistles for wide-gamut editing. Two big items are missing: Softproofing and a good internal colour selector dialogue for selecting colours that are outside of the sRGB colour space.


Softproofing is a method where we use our colour management library to emulate how the colours would look in a different colour space. It is primarily used for showing CMYK prints. Technically, this is already possible, but it is inconvenient: While by transforming an image to a different colour space we get an idea of how it would look, this operation is 1) destructive, and 2) doesn’t allow for so called ‘out-of-gamut’ warnings. These latter are odd coloured overlays to show where the transformation is clipping bright colours, which is useful feedback to an artist working for print.

((Above: softproofing in Digikam, which also uses LCMS. The bright cyan colour represents the colours that are outside of the CMYK gamut given)

LCMS thankfully offers functionality for softproofing. What needs to be done is extend the current display colour correction to use this functionality, and to make a nice user interface for it.

The prime reason why this is important for Krita to have is because Artists need to be able to draw with Krita giving feedback of how the image would look in a CMYK space. However, drawing your image in a CMYK colour space is typically a bad idea, because the irregularities of any given CMYK profile doesn’t make for good colour maths, and thus less pretty mixtures. Furthermore, an image made in a wide gamut RGB space would be easier to convert to multiple CMYK profiles, while a CMYK profile is unique for the printer and paper it was made for. Thus, the best solution for artist’s needing such feedback is to allow this soft proofing emulation of colours

Internal Colour Selector:

All of Krita’s existing selector docker are ways of selecting colour, so they represent a visualisation for the artist. Furthermore, they are all plugins. Which means that for filters, fill layers, and many other areas of Krita which don’t have direct access to these colours, we use the default Qt colour picker, which is limited to sRGB. This is extremely limiting and a bit disappointing for those hoping to use these filters for wide-gamut editing.

This project is quite a bit bigger than soft proofing. Even if we only limit ourselves to making the simplest selector possible, there’s still conversion between values, as well as integrating the screen colour picker, as well as dealing with other useful features that the existing qt selector tool has, such as:

  • Colour picking from screen (colour managed)
  • Colour picking from a different Krita window should be colour managed
  • Hex code conversion
  • Numerical input(that can handle HDR values)
  • Palettes

Left-over time:

Further I would like to work on improving open raster file format support if time allows me. The main thing that needs to happen here is that two blending modes need to be added to Krita, and Krita needs to save and load these.

  • ‘Destination/Source out’ needs to be mapped to erase.(This is badly named in mypaint)
  • ‘Destination in’ is new and is a sort of inverse XOR mode.
  • Pass-through mode needs to be loaded and saved.
  • ‘Destination atop’ needs to be mapped to alpha-inheritance.
  • ‘Source atop’ is new and functions as an inverse alpha-inheritance.

Furthermore, we could really improve other minor areas like the background colour and pattern loading.


Week 1:
Figure out how to use LCMS’s functionality to do soft-proofing.
Week 1-2:
Make User-interface so that users can control toggles and the like.
Merge if possible.
Week 3-4:
Start on new selector widget. First focus is getting one that can select based on channels inside the colour space.
Then add the numerical input.
Investigate alternative colour models.
Investigate hex-code conversion
Place into gui.
Week 5-6:
Add palettes.
Port onscreen colour picker in it’s most basic form
Work further on making the onscreen colour picker to be colour managed.
Week 7-8:
Work on bugs.
Work on Openraster support if time permits.


R37:93ef7c8ef97e: Merge in new internal color picker dialog!
R37:e4b42d286eea: Fix non-painting space deformation
R37:0246b4ba3d7d: Enable High range color picking for the visual selector.
R37:62a4f7c6aea2: Fix spinbox updating float.
R37:a5c0408ae52c: Make the display color converter of the dualcolor button get updated.
R37:ca0a03338f47: Add HSI and HSY support to the visual color selector.
R37:00b8d54f9faf: Attempt to further add displayconverter integration...
R37:9c39f81cc1f2: Fix rounding-error wiggles.
R37:c52ca3f46c8b: Make moving the cursor around more pleasant
R37:9acd7f1558a3: Fix HSL and HSV
R37:31931e3a522e: Add visual selector shapes.
R37:273dd04a1cd9: Add screen color picking widget.
R37:ea0867829348: Give spinboxes names, fix order spinboxes, do cleanup.
R37:37d1a1cc9f20: Change spinboxes to numerical spinboxes.
R37:6f18c4c3272a: Make internal color selector dialog possible to do modal mode.
R37:38398393973f: Remove signal compressor, use block signals instead.
R37:55350f021cb5: Move KoDualColorButton, attach internal color selector.
R37:0807eeb01d02: Merge in softproofing and ocio looks.
R37:54776118b78a: Add rant why per-shot looks won't work after wasting afternoon on it.
R37:a3b224b6958d: Fix loading of default gamut warning color.
R37:652405d3acd6: Add adaptation state slider.
R37:519f9c1fbe43: Add option to set default Proofing Options.
R37:2e057e7a5339: Clean up all the debug messages.
R37:604efc8ddb21: Not sure if this isn't the correct code instead...
R37:7c669703ff0c: Load embedded proofing profiles if they exist, and add them to the profile…
R37:119906b23bf0: Add embedding of the proofing profile.
R37:9ef1dad77360: Load Warning Colors properly from file.
R37:6a57cf08fb17: Fix naming conventions.
R37:91d7da8c41c4: Make views smart enough to track softproof/gamutcheck-state.
R37:6bacfcda6005: Add attempt at saving color to xml.
R37:1f733e28cb7f: Refactor the proofing transform system for better caching.
R37:9d9ce38079c6: Add softproofing section to image properties menu.

I made a test file for Ora's new blending modes and vector functionality.

This is the current state in Krita:

Deevad added a subscriber: Deevad.Apr 26 2016, 9:59 PM

rKRITA4faa8b574da039d9dc86f099841bb901495e19a9 is pretty important too :/

Okay, so this gsoc I got the following done:

  • softproofing, per image, per view.
  • gamut-warnings.
  • adaptation state slider.
  • Configuration is stored within the kra file.
  • a default setup in the settings, but the actual configuration is in image properties.
  • OCIO look support.
  • a spinbox selector that can select HDR and wide gamut values without hassle.
  • an onscreen color picker
  • a fancy wide-gamut color selector.
  • a dialog that combines these things into a nice little UI file. Working both modally and non-modally.


  • The HSV and HSL modes do something weird with grayscale values. The result seems to give actual colors, but I have no clue what is causing either error.
  • I can't seem to get the display renderer updating to work properly.

Other priority todos:

  • Figure out inheritance mess, and then stick this/these widgets everywhere.

Missing elements:

  • Hex code input.
  • Palette input. I wasn't too sure how to tackle this one yet.
    • It seems QColorDialog has a public function to access it's custom colors, might be useful to pull that from the system into s KoColorSet sometime.
  • OCIO widget: I need more time for this.


  • The visual color selector has a class named 'visual color selector shape' which deals with all the painting and that is then subclasses by the rectangle shape. We can thus extend this easily to other shapes.
  • That would mean we could replace the pop-up triangle with a wide-gamut variant too.
  • The visual color selector is capable of a lot of things, but there's no gui for configuring this yet, and I think we'd need to sit down and think a bit about this.