Some Krita colour selector and management bugs musings.

[Boudewijn Rempt]

I think we're going to need a bug to track this. It's extremely related to the problems Elle Stone has been discussing with me. Color managed color selectors seem to be much more difficult than it seems...

On Monday 05 January 2015 Jan 19:04:20 Wolthera wrote:
> This is not of extremely high importance, but I had time to muse on it past
> week.
> 
> The main issue is that Krita can not select colours outside of sRGB.
> 
> Whenever you have a large image or 'working' profile, such as Adobe
> Compatible, on an image, Krita can not actually select it's extremes.
> 
> If you look at the specific colour selector, you can observe that it
> understands colours outside the screen profile, especially in XYZ. However,
> any attempt at selecting these results in a colour inside sRGB being
> selected.
> 
> I suspect this happens due to the recursive nature of all selectors:
> If Selector picks a colour, resource manager colour is updated.
> If Resource manager colour is updated, update the selector colour.
> This can result in a few colour conversions too many being made, if not
> imprecision in the colour. My first patch even consisted of disallowing the
> advanced colour selector to update itself if it were the one updating the
> main colour.
> However, all colour selectors participate in this(except artistic because
> that one can't update itself), even if they are not active as dockers.
> 
> Second issue is that in managing HDR, there's some puzzling to get to
> colour converted to the right QColors for display. This is related to the
> following.
> 
> If a colour selector however only can select QColors, like, I suspect, all
> HSX based colours selectors: advanced, simple and sliders, it of course
> means that they force sRGB colours to be selected in the recursive update
> scheme.
> This is because all of those selectors are designed with the assumption
> that the end user wants to select the colour displayed under the cursor,
> rather than the colour that is represented by the position on the selector
> under the cursor.
> The selectors need to be rewritten to deal with new needs, and we need to
> make sure the order of conversions is correct with QColor coming last for
> display.
> 
> Idea for plan to fix:
> 1. Disable all selectors. Having all selectors available affects the
> selectors you're working on.
> 2. Start with the specific colour selector and get it to work, as this is
> the only selector that shows out of screen space colours.
> 3. Figure out how to get the (sRGB) simple colour selector to work in this
> situation, and what to do if it encounters the resource manager to have an
> out of sRGB space colour. Prevent it from telling the resource manager 'oh,
> hey, that colour doesn't exist in my space, let me give you a proper
> colour!', ruining our out of sRGB space colour.
> 4. Get the advanced colour selector to work with this.
> 4b. Wonder whether we would like to have the advanced colour selector to
> show the full working space, or only sRGB. The former requires more rewrite
> and hard thinking, but would be pretty cool considering advanced's ability
> to have it's own colour space.
> 5. Find a solution to working spaces that are smaller than the screen
> space(unlikely to happen, but let's be system complete)
> 6. Let me completely refactor the color sliders, because it's system is
> terriblah.
> 
> Anyway, the reasons we would like this fixed include such wonderful ideas
> such as:
> 1. Thanks to this bug it's completely pointless to even allow image/working
> colour spaces larger than the screen space.
> 2. Having this bug fixed would allow for neat colour number crunching stuff
> to happen in Krita.
> 3. The reason it took this long to find this is because most of our users
> don't understand colour management, and this is not encouraging.
> 
> Other big issues that are related:
> 1. Both lab and cmyk don't have a 16 bit float and their 32 bit float is
> borked. Just select any colour, and you'll see the values, which in float
> should not go above 1.0, are wrong.
> 2. sRGB built-in is generated on the spot by lcms, and has been proven to
> be generated incorrect on certain devices(if not all). We need to get it to
> generate proper or have a new default.
> 
> I am not sure when we should look into this. The question is whether or not
> this problem is new to 2.9(because of the color display converter, AKA HDR
> colour pickers), and whether we can leave it to 3.0 or 3.1.
> 

-- 
Boudewijn Rempt
http://www.valdyas.org, http://www.krita.org