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

[Kai-Uwe Behrmann]

Thanks for going into this discussion on the OpenICC list.

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.

> > What does you think about switching this discussion to the OpenICC email
> > list? I think there are more people concered in operating systems and
> > colour management.
> 
> I'm apologising for readers of this list for hijacking this thread, it
> is not my intention of discussing
> what should be done on Linux desktop regarding CMS. I'm cc this reply
> to openicc mailing list and I think we should remove argyllcms mailing
> list from future replys (cross list discussions is usually a bad idea
> ;).

Fine, we are arrived on here.
 
> > > > 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 ;)

> > What do you plan to other desktops in Mandriva than Gnome?
> 
> Nothing, I'm not doing this work as part of my Mandriva job but as
> purely personnal project. I'm interested into improving my user
> experience and by extension, GNOME user experience. I might try to
> discuss with our Mandriva KDE hackers but I can understand they might
> not have interest in this.

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.

> > > 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.

> -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.

> -no versioning control system for source management (maybe you should
> move your project to freedesktop.org ?)
Agreed.

> -license problem (should be LGPL or MIT for maximum usage, but it
> appears you are changing this for next release)
> -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.

> -I don't like CamelCase (I'm half joking, I'm used to lower casing,
> like glib/glibc and so on ;)

Hmm, I am afraid there are as many opinions as projects. 
At least, I hope the symbol naming is consistent in itself. The symbol 
naming will be documented in the next release.

> > 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 ;)

> 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.



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. 

My guess is, that Robert Krawitz could do the measuring for his 
devices/driver combinations and publishing the CGATS files and profile. 
I'd think someone will assist in setting up profiling. 
The same could happen for Sane and Gphoto or dcraw. 
The profiles can be collected eighter centralised or driver dependent.
Till Kampeter offered some time ago hosting of such a ICC device profile 
database. But we did not reach a point to make use of it.

Once the discussed device profiles are available and installed, the 
profile selection should occure automatically. User intervention, as for 
selecting alternatives or change settings should be almost distribution 
independent.

Splitting the profiles into packages and provide a way to automatically 
load profiles as needed by a particular connected device seems the 
remaining part, which I think could typically be handled by a distributor. 
In the end the device profiles, including their setup, should be the 
same.


kind regards
Kai-Uwe Behrmann
--
developing for colour management 
www.behrmann.name + www.oyranos.org