Krita Colorspace and profiles

[Stefano Bonicatti]

Hello there, these couple of days i'm making a refactor of
KoColorSpaceRegistry and KoColorSpaceFactory, due to them having some mixed
ownership between the registry and the factories plus some unnecessary work
done when having to get a colorspace from the registry and possible
threading issues.

Though i have some doubts about what is to be expected from the colorSpace
function, which either gets the colorspace from the registry or it creates
it.
Keep in mind that i removed the profile and color caches from the
factories, because those were partially duplicated with the registry, and
imho the registry should have everything and only it should be used as
cache.

When calling the colorSpace function, one has to pass a colorspace id, a
string formed by the colorspace model id (a string like "RGBA") and the
color depth id (a string like "U8"), and then pass a profile name.
Though looking at the code of the colorSpace function, it supports an empty
profile name and:

1) If that's empty it tries to take the name using the specific
KoColorSpaceFactory default profile.

2) If that exists then it tries to see if the colorspace is present in the
registy cache using the colorspace id + the profile name.

3) If it's not that profile name is searched between the profiles aliases
(profiles can be added separately, they have a profile name, maybe coming
from their file and the an alias to avoid duplicates, i suppose).

4a) If the profile is found, then the colorspace gets created.

4b) If the profile is NOT found, then, using the colorspace id, it takes
the respective color space factory and loops through all the profiles in
the registry cache, checking which profile could be compatible with the
factory, if it's found the colorspace gets created.

5) When that's created it gets added to the colorSpace cache BUT, not using
the default profile name; the actual profile name (the one that could
collide) is used instead.

The other possible path, when the profile name is NOT empty, simply starts
from point 2.


Now i want to understand if this roundabout is really needed or not.
First of all, why an empty profile name can be passed? And why the user can
accept whatever profileName has been found by the function?

Given that the colorspace id "RGBA U8" can be easily duplicated, the only
explanation is that at any time there should be one factory serving that
colorspace id (keep also in mind though that the factory list, is actually
a hashmap that removes duplicates and put them in a internal duplicate
list, so it permits the substitution of a certain colorspace id factory, so
the user might not get what he expects).

Then this default profile name is used to check if the colorspace is in the
cache, but as we saw in point 3 and 5, that profile name is never used to
save the colorspace in the cache (unless its alias it's the same of the
name it's aliasing?).

To add to the confusion then the function can be called with a profileName
too, which can be whatever...

Also i thought that profiles could be added only in a specific moment but
as i was looking around it seems they can come also when converting images
and doing other operations.

My objective here is to try to restrict the content of the arguments
passed, as in.. requesting that a profileName is always given AND that is
always a name known from the profile alias list, but... until i don't get
the full picture is difficult.
That way the function could lose flexibility but at the same time the
"flexibility" it has now comes with some uncertain results.

Signed, your most loved "wall of text" guy.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kimageshop/attachments/20160323/24a9eaf1/attachment.html>