Some Krita colour selector and management bugs musings.

[Wolthera]

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.
-- 
Wolthera
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kimageshop/attachments/20150105/d9b062bf/attachment.html>