On Thu, 15 Dec 2016 20:26:30 +0100
Post by Kai-UwePost by Mattias AndréeOn Thu, 15 Dec 2016 17:51:48 +0100
Post by Kai-UwePost by Mattias AndréeOn Thu, 15 Dec 2016 13:18:17 +0100
Post by Kai-Uwelibcoopgamma is GPL. A really unacceptable choice
for a API, which shall be used by everyone to reach
the goal of a more structured / disciplined gamma
access.
libcoopgamma is just one implementation, anyone can
choose make there library with whatever license they
want.
more importantly, all programs that
use libcoopgamma can change the gamma ramps
without overriding each others changes
Nice statement. However the chance is high, that your
code path will be ignored by other color configuration
systems and thus the user experience is irritating at
best.
I'm not sure I understand what you are trying to say.
Your above expressed intention from the README is likely
to fail. If a different system tries to bring effects
into the desktop appearance and uses ramps like your
library does or simply restores the calibration state
(gamma ramps) of a given ICC monitor profile, the
libcoopgamma effects are likely to be destroyed.
Yes, if a program uses e.g. libgamma instead of libcoopgamma
it override what all libcoopgamma-applications have done.
I didn't think this is necessary to clarify, it should be
obvious. However, programs do not need to use libcoopgamma,
the can talk directly with coopgammad or, if the display
server implements cooperative gamma, the directly with the
display server.
Post by Kai-UwePost by Mattias AndréePost by Kai-UweMaybe a configuration scheme is a better path then.
Different programs can then implement that scheme.
Can you give an example of what you mean.
Writing the effects into a easily parseable (say JSON)
configuration file in a XDG config path along with a
signaling mechanism about the change would certainly help.
I don't think it's a good idea to have the display server
using files for this, but I would not object to a cg-file
and a cg-filed in cg-tools. An advantage with having this
as separate daemon is that it could be suspended while
editing the files if the daemon uses inotify.
I do not think using just the file system is enough because
it complicates support for running two display servers at
the same time.
I assume that you with âsignaling mechanismâ mean a way
to signal the daemon to reload the files.
Post by Kai-UwePost by Mattias AndréeDo you mean
support for arbitrary colour mapping (a large lookup
table of all colours) and multiplication with
matrices?
ICC abstract profiles can be much more expressive and can
easily be integrated into other systems too. The gamma
ramps can be computed from the profiles by a CMM like
lcms. The advantage would be that it might easily
integrate into the wayland way of color management, which
so far offers no gamma access. At the same time can
profiling tools temporarily disable the effects in order
to measure device behaviour. Support for more use cases
becomes possible.
I have not addressed temporarily disabling add effects,
but it's possible to do by sending a signal to coopgammad
to disconnect from the display, use libgamma to reset the
ramps, and when done, send a signal to coopgammad to
reconnect to the display.
When implementing this in Wayland, it have to be solved
by the compositor, or Wayland can choose to add a protocol
for it. In my display server, there isn't really a need
for this, because the profiler can read and block all
communication between the coopgamma server and the gamma
server, read the current ramps, reset the ramps, and
when done, restore the ramps, or the last change the
coopgamma server tried to send to the gamma server, and
then exit. (The display server doesn't really need that
many protocols when given a multi-server architecture.)
Post by Kai-UweICC color correction works with CLUT tables in display
servers or color servers in some traditional GL enabled
window managers. ICC abstract profiles can be easily
chained during CLUT creation.
Post by Mattias AndréePost by Kai-Uwebest regards
Kai-Uwe
PS: please feel invited to the [OpenICC list][1] round
the corner. I really would like to see a convergence of
desktop color configuration, as it makes much sense to
users. Redshift and friends are certainly welcome.
https://lists.freedesktop.org/mailman/listinfo/openicc