https://bugs.kde.org/show_bug.cgi?id=401154
--- Comment #16 from karolbienkow...@protonmail.com ---
I tried to understand what's going on and this is a lot of information so I
might have gotten some thing wrong.
There's a thing called "_ICC_PROFILE" X11 atom (simply a preference) that is
supposed to keep monitor ICC profile in X. It can be used by any app that wants
do to some color correction. If someone uses colord or oyranos then the profile
in X11 was set by it and it also makes sure that all programs that keep this
Window Property are color-corrected. So it seems to me, that maybe a window can
decide if it wants to be corrected? Food for thought.
Some apps want to do their own color correction. this is from cmsprofile.cpp
getMonitorProfile() function in gwenview:
```
static Atom icc_atom = XInternAtom(QX11Info::display(), "_ICC_PROFILE", True);
if (XGetWindowProperty(QX11Info::display(),
QX11Info::appRootWindow(screen),
icc_atom,
0,
INT_MAX,
False,
XA_CARDINAL,
&type,
&format,
&nitems,
&bytes_after,
(unsigned char **) &str) == Success
) {
hProfile = cmsOpenProfileFromMem((void*)str, nitems);
```
It checks if there's a profile on a window and if it is, then it is saved to
hProfile and, later, used. There's problem with that logic. If there's a
profile, then most likely the windows is already being color-corrected by
system-wide cms. I don't know if setting global "_ICC_PROFILE" X11 atom and
leaving it up to apps to actually correct themselves is a common workflow, but
I doubt it.
If there's no profile, the generic sRGB one is created. In rasterimageview.cpp
you can find that monitor and image profiles are merged (doesn't matter if
monitor actually has any profile, bc now it uses generic sRGB)
All in all, I think gwenview should not care about monitor profile, let it be
applied by system-wide cms and just apply image profile on top of it.
--
You are receiving this mail because:
You are watching all bug changes.
