[Openicc] [argyllcms] Re: CC Profiles In X Specification and dispwin

[Frédéric Crozat]

On Jan 14, 2008 11:23 PM, Kai-Uwe Behrmann <ku.b at gmx.de> wrote:
> Am 14.01.08, 12:10 +0100 schrieb Frédéric Crozat:
> > On Jan 13, 2008 10:34 PM, Kai-Uwe Behrmann <ku.b at gmx.de> wrote:
> > > Am 13.01.08, 21:46 +0100 schrieb Frédéric Crozat:
> > > > On Jan 13, 2008 9:20 PM, Kai-Uwe Behrmann <ku.b at gmx.de> wrote:
> > > > > Am 12.01.08, 14:14 +0100 schrieb Frédéric Crozat:
> > > > > > On Jan 12, 2008 12:35 PM, Lars Tore Gustavsen <lars.tore at mulebakken.net> wrote:
> > > > > > > On Jan 12, 2008 11:09 AM, Frédéric Crozat <> wrote:
> > > > > > > > I have plans to integrate the xicc and LUT calibration data loading
> > > > > > > > into GNOME directly (into gnome-settings-daemon).
> > > > > > > >
> > > > > > >
> > > > > > > That sound nice.
> > > > > > > I wonder if have you looked at oyranos?
> > > > > >
> > > > > > No.  applying LUT and a X atom is not something worth adding a new
> > > > > > dependency on gnome-control-center. For now, I plan to do the applying
> > > > > > part. UI will come later.
> > > > >
> > > > > At a first glace this seems right. Just calibration and device profile
> > > > > selection highly depends each on the other. One monitor profile may be
> > > > > completely useless with not belonging calibration settings. Therefore some
> > > > > profilers pack the VCGT (VideoCardGammaTable) tag into the profile itself.
> > > > > But thats not enough.
> > > >
> > > > That is a start, which is still missing right now.
> > >
> > > What does you refer to with the word 'start'? The stuff added to Gnome?
> > > Work in this direction is done long time already in Oyranos. As a Co
> > > author of the ICC in X spec and Oyranos, this makes no wonder.
> >
> > I may have been done in Oyranos but it has still not landed in any
> > desktop environment or merged in any distribution.
>
> Yes, the non distributed and not ready Oyranos library is an unfortunate
> situation. Still my point of view was/is to dig not too deep into specific
> stuff with a Gnome only thing. For a intermediate solution, with exposing
> a non final or experimental marked GUI, it might have some use.

As I wrote earlier, I'm not interested (yet) in designing nor
implement a full CMS system in GNOME. What I want for now
is for GNOME to be able to load LUT and set XICC atom, using standard
GNOME infrastructure (not distro specific) and
GNOME configuration. For now, I don't even plan to write a UI to
specify the profile to use (it will be only accessible through gconf
) and only later, we could add a file selector in the display
properties dialog of GNOME.

> > > > > In the long run such stuff would be less work do be programmed once and
> > > > > consistence across desktops to make colour management for Linux (or
> > > > > more specifically for X11), and not just Gnome. The spot should be on the
> > > > > user of a computer, even if it seems harder to go beyond a operating
> > > > > system. As a analogy, after switching the desktop I would expect to use
> > > > > the same Xorg or printer configurations.
> > > >
> > > > Except that people are not switching desktop as they are switching applications.
> > >
> > > What has switching desktops to do with switching of applications?
> > > A user expects consistence and ease of use. This includes settings across
> > > desktops. The need for a user to set in KDE other than Gnome is
> > > complicated and a waste of time and resources. Please dont take me wrong;
> > > Gnome and KDE should expose a common structured CM tab in eaches
> > > configuration panel. To have such a tab a common logic or common device
> > > settings database is needed.
> >
> > Since xicc and lut loading are not session persistent and desktop
> > dependent (they can be compared to Xsettings), once a desktop user has
> > configured his desktop, it won't matter if he switchs applications
> > (either KDE based, GNOME based or non desktop dependant ), they will
> > work as expected.
>
> ... and the setup should be similiar not different.
> Colour management is often experienced as difficult and complicated.
> Observing a exclusive GUI for only on desktop/distribution to setup a
> monitor profile on Linux, shurely increases the complains. To build a
> hopefully shiny open source CMS we should avoid confusing situations as
> good as possible. Configuring Gnome other than KDE, twm or within
> different distributions is IMHO not helpful. As user I would expect to do
> just a search for the desktop specific location of the colour management
> panel and then find the same logic as everywhere. (Of course we will not
> join WCS and ColourSync on this list ;)

Creating a non-integrated UI in each desktop UI, not using the same widgets and
logic than all other tools will confuse users much more.

What you could do is to specify an UI (using mockup) which is agreed
by the various desktop
environment, let them implement it in their desktop and, if you could
implement your own
version if you wish.

> A tab in the sample implement of the Oyranos configuration panel is missed
> for monitor profile setup. Still if there present it would work in most
> situations. Then the Gnome panel exposing the same logic and behaviour, of
> course with its own GUI look and feel, would remain as the only wish.

See, we are converging :)

> > > > Moreover, taking Xorg or printer configuration as a example is not
> > > > really pertinent. Almost all desktop-neutral and non-distribution
> > > > configuration software for these points have failed (if they ever
> > > > existed) and are handled mostly by distributions (I have
> > > > a good experience of this at Mandriva). I don't want the same thing
> > > > for color management support.
> > >
> > > Well, I can not speak about print or X configuration. But for Oyranos, is
> > > works on all tested desktops for _ICC_PROFILE and vcgt setup. Whats the
> > > problem with such functionality?
> >
> > I've just did a extremely fast review on Oyranos and so far, I see the
> > following problems :
> > -Not integrated in any desktop environment yet (not your fault ;)
> > -pull UI relying on uncommon toolkit (FLTK) => you should split the UI
> > dependant part to a separate package
>
> The Oyranos library should build even with a non installed FLTK. But
> I'd take your suggestion for RPM packaging and will provide something like
> oyranos-ui.

For the record, it is not only for packaging, but for better
acceptance by other projects. I'm not
sure KDE (or GNOME) guys would be happy to have to install FLTK just
to build one of their software :)

> > -not autotools based
>
> You did you see problems? I did not notice such on Novells build server.
> Ok, there are not that many architectures available (x86+x86_64). I can
> put a autotool request on the TODO list.

Trust me, once people start building it on something else than Linux
(*bsd, solaris, etc), you won't say the same
thing :)

> > -use elektra configuration "abstraction" => this kind of stuff is nice
> > on the paper but I think it is plain wrong (you can't expect desktop
> > environment to accept this kind of dependency). For this particular
> > problem, I only see two solutions : the fontconfig way ( you create
> > your own configuration file format (.xml based probably) and it will
> > be the only one supported) or adding configuration hook in the library
> > and desktop environment will plug their own configuration backend in
> > Oyranos (or maybe just ship the different configuration backends as
> > dlopened modules but it adds again dependency issues). But the more I
> > think about it, the more I prefer the fontconfig way.
>
> Should not be that difficult. Even though at least the Feodra
> project signaled to include Elektra.

The fact Elektra might be available in one distribution is not
relevant. Just like the FLTK objection,
if you expect projects to use Oryanos, it shouldn't pull uneeded
dependencies. And I see Elektra
as such.

> > > But this is an other pice of short argument. So would you mind in
> > > elaborating in naming the differences of the examples (CM/Xorg/printing)
> > > or why "desktop-neutral and non-distribution configuration software for
> > > these points" have failed. If Xorg and CM is not comparable why do you
> > > expect the same to CM? You might understand, as I work on this CM stuff I
> > > would like to know about general hard to resolve proplems in more detail.
> >
> > Because configuration for such things (Xorg / printing) is
> > uninteresting for 99% of unpaid hackers, extremely hard to do without
>
> The engagement of many of the Colour Management project leads is very
> continuous. I dont feel like a unpaid hacker with short goals only. Of
> course the situation regarding payment could be improved ;)

Playing devil advocate : well, I fail to see deployed results in
either GNOME or KDE ;)

> > access to hardware. So far, only distributions have taken burden of
> > doing such tools and for historical reasons, each distribution has
> > done its own tool and no sharing has happen (and I don't see it
> > happening anytime soon). Xorg is slowly moving to autoconfiguration
> > but this stuff takes a lot of time and I don't really expect it to
> > work or 100% of graphic cards and monitors (due to uncompliant DCC
> > monitors for instance).
>
> Of course detection of hardware, calibration state and selecting a good
> profile is still in question. There is quite some interesst in the CM
> community to get hardware information. A general approach would help here.
> At least reading your lines I am afraid a pure Gnome logic would not
> easily behave like other Desktops. Ok, as a prototype for the monitor
> panel it might have its own value. Probably your suggestion can be taken
> or we might discuss on it to get Desktop independent behaviour and
> apearance.

I didn't wrote about hardware calibration, calibration state nor
profile selection.

> To continue more on distribution specific versus non specific topics:
> Regarding device profile creation; Currently the resources to create such
> are limited. A profiling service to obtain profiles for our drivers could
> be done on different places including a distributor running a spectro
> colorimeter. But then a packaging distribution specific profiles would
> look not so good.
> Vendors providing different profiles or drivers in different regions have
> experienced negative feedback several times in the past.

I've never wrote about this nor intended to discuss about profile creation. My
example on distribution specific development was to empathise about
lack of integration of low level cross-distro tools (remember
linuxconf) which have
to be handle by distributions.

-- 
Frederic Crozat