https://bugs.kde.org/show_bug.cgi?id=429871
Tiar <tamtamy.tym...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |tamtamy.tym...@gmail.com
--- Comment #2 from Tiar <tamtamy.tym...@gmail.com> ---
The reason for this is that Krita doesn't save the bit depth when saving the
last used color in preferences (kritarc). See KoColor::toXML and
KoColor::fromXML. Also see how kritarc saves the colors:
LastBackGroundColor=<!DOCTYPE LastBackGroundColor>\n<LastBackGroundColor>\n
<RGB space="sRGB-elle-V2-srgbtrc.icc" g="0.219607844948769"
b="0.219607844948769" r="0.219607844948769"/>\n</LastBackGroundColor>\n
LastForeGroundColor=<!DOCTYPE LastForeGroundColor>\n<LastForeGroundColor>\n
<RGB space="sRGB-elle-V2-srgbtrc.icc" g="0.439215689897537" b="0"
r="0.847058832645416"/>\n</LastForeGroundColor>\n
So it saves the color space and the profile, but then just assumes that the
color is in U16, I think (since that's the default). It kinda works but when
you open the palette docker and adds a new swatch, it detects that the current
KoColor is in U16 and shows the color correctly.
Interestingly, the DualColorButton kinda forces the image bit depth (and
possibly the color space as well).
In my opinion it would be good to fix the root issue. I don't have an opinion
what should happen if the KoColor was actually U16 from the previous image. I
think maybe it should be preserved, if the user uses multiple color spaces and
depths, they probably know what they're doing.
For the fixing the root issue, it's probably not difficult but I would like to
get @Wolthera's opinion first. I'm not sure if it was intentional or not.
--
You are receiving this mail because:
You are watching all bug changes.
