[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-kimageshop
Subject: Krita Colorspace and profiles
From: Stefano Bonicatti <smjert () gmail ! com>
Date: 2016-03-23 10:48:09
Message-ID: CAGMAV4_D1RXx05eWXZ7AzZrBpFt+mgYD_P+Mk10g5N1hxSz5bQ () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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.
[Attachment #5 (text/html)]
<div dir="ltr"><span style="font-size:16px">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.</span><div style="font-size:16px"><br></div><div \
style="font-size:16px">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.</div><div style="font-size:16px">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.</div><div style="font-size:16px"><br></div><div style="font-size:16px">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.</div><div \
style="font-size:16px">Though looking at the code of the colorSpace function, it \
supports an empty profile name and:</div><div style="font-size:16px"><br></div><div \
style="font-size:16px">1) If that's empty it tries to take the name using the \
specific KoColorSpaceFactory default profile.</div><div \
style="font-size:16px"><br></div><div style="font-size:16px">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.</div><div style="font-size:16px"><br></div><div \
style="font-size:16px">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).</div><div \
style="font-size:16px"><br></div><div style="font-size:16px">4a) If the profile is \
found, then the colorspace gets created.</div><div \
style="font-size:16px"><br></div><div style="font-size:16px">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.</div><div style="font-size:16px"><br></div><div style="font-size:16px">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.<br></div><div style="font-size:16px"><br></div><div \
style="font-size:16px">The other possible path, when the profile name is NOT empty, \
simply starts from point 2.</div><div style="font-size:16px"><br></div><div \
style="font-size:16px"><br></div><div style="font-size:16px">Now i want to understand \
if this roundabout is really needed or not.</div><div style="font-size:16px">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?</div><div \
style="font-size:16px"><br></div><div style="font-size:16px">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).</div><div \
style="font-size:16px"><br></div><div style="font-size:16px">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?).</div><div \
style="font-size:16px"><br></div><div style="font-size:16px">To add to the confusion \
then the function can be called with a profileName too, which can be \
whatever...</div><div style="font-size:16px"><br></div><div \
style="font-size:16px">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.</div><div style="font-size:16px"><br></div><div \
style="font-size:16px">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.</div><div style="font-size:16px">That way the function \
could lose flexibility but at the same time the "flexibility" it has now \
comes with some uncertain results.</div><div style="font-size:16px"><br></div><div \
style="font-size:16px">Signed, your most loved "wall of text" \
guy.</div></div>
[Attachment #6 (text/plain)]
_______________________________________________
Krita mailing list
kimageshop@kde.org
https://mail.kde.org/mailman/listinfo/kimageshop
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic