Krita Colorspace and profiles

[Boudewijn Rempt]

On Wed, 23 Mar 2016, Stefano Bonicatti wrote:

Some termininology to make sure we're on the same page:

Color model: a combination of channels of a certain depth

KoColorSpace: a combination of a color model and a profile

KoColorSpaceFactory: can create a KoColorSpace instance for its
model using a compatible profile. We try to not create more than one
KoColorSpace instance for each combination. So, all paint devices that
use 8 bits rgb with the default sRGB profile should use the same instance.

KoColorSpaceRegistry: the registgry that keeps track of the factories

KoColorSpaceEngine: an abstraction that was needed when we had dumb
colorspaces, ICC based colorspaces, painterly colorspaces and opengtl
based colorspaces.

> First of all, why an empty profile name can be passed?

Because you don't want to specify the profile name all the time if the 
default for a certain colorspace is fine.

> And why the user can
> accept whatever profileName has been found by the function?

I'm not sure what you mean here.

> 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).

I'm not sure if I understand your question, but yes, there should be one KoColorSpaceFactory per colorspace id; and as many instances of KoColorSpace as the user has used profiles for that colorspace id. We shouldn't pre-create KoColorSpace instances for every profile for every colorspace.

> 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...

If you suspect a bug here, we need to check that we indeed never create two colorspaces with the same physical profiles.

> 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.

Not sure what you mean here, either. We load profiles on startup, but we do not (and should not) create colorspaces for all profiles on startup.

> 
> 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.
>

I'm sure there are problems in KoColorSpaceRegistry, but I'm not sure that this is the real problem, actually. The profile alias code is old, but it's used all the time -- what actual problem are you trying to solve in the first place?

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