[Openicc] Promoting colormanagement for LINUX

[Hal V. Engel]

On Wednesday 13 February 2008 01:33:44 Jan-Peter Homann wrote:
> Hello list,
>
> Following the discussion on this list the last years, I see that
> colormanagement under LINUX is now entering the mass market:
>
> - LCMS is established as standard CMM for LINUX applications
> - The first mass market applications like e.g. Firefox are now
> colormanagement aware
> - monitor profiling solutions like e.g. Argyll / LProf are available by
> reverse engineering of the measurement device drivers
> - Big players like e.g. Apple integrate OSS solutions into Mac OSX /
> Apple applications e.g:
>     - CUPS
>     - Gutenprint
>     - Parts of the Safari engine
>     - (and several more...)
>
> What could be the next steps:
>
> 1) Making the openICC wiki the first adress for best practice in OSS
> colormanagement
> -----------------------------------
> - OSS developers should find all necessary informations at the openICC
> wiki to know what steps they have to go in general to make their
> application CM aware
> - developers of applicatios, which are already CM aware should describe
> how they have implemented it in general, and which libraries, code
> snippets are available for other developers
> - testfiles and test procedures for validating CM functionality in apps
> should be available via the open ICC-wiki
>
> 2) Influencing KDE and trolltech
> -------------------------------------
> (Please correct me, if i´m technically wrong in the following statement...)
> KDE and trolltech/QT are very important organisations / companies for
> the LINUX community. If colormanagement is good integrated into their
> libraries / apps, it will make it much easier for other OSS developers
> to use just this libraries / apps to make their own projects
> colormanagement aware.
>
> As the firefox team has managed to implement colormanagement, also KDE
> will have to do this for Konqueror and KParts in future. Especially if
> KParts will be colormanagement aware, this will be a real big step for
> all OSS vendors reusing KParts into their applications.
>
> As more or less all the KDE projects based on QT, a good colormanagement
> implementation in KDE projects will automatically enhance the
> colormanagement capatibilities of QT and so all OSS projects, which are
> using QT.

There are other desktop environments besides KDE.  One example is Gnome which, 
like KDE, is very widely used but there are many others as well.  In 
addition, these DEs use different widget sets.  KDE uses the Qt widget set 
and Gnome uses GTK+.  Other DEs and window managers use other widget sets.  
Firefox is also a GTK+ application as are GIMP,  CinePaint, XSane and UFRAW 
among others.  LProf, uses Qt and Krita is a KDE app which means it uses both 
Qt and KDE.

KDE is built on top of and extends Qt.  Therefore features implemented in KDE 
will not provide much benefit to non KDE Qt applications other than perhaps 
providing code examples.  But I think there are KDE specific things that need 
to be done to better support color management.  On example is that KDE 
Control Center  => Peripherals => Display functionality needs to stop 
clobering the video card LUTs (is this fixed in KDE 4?).  I am sure that 
there are examples like this for Gnome and other DEs as well.

I think that we need to keep in mind that all of these DEs and widget sets are 
built on top of X11 and that X11 is the software layer that is common to all 
DEs and window managers in the open source arena.  Anything that is done to 
improve CM in X11 benefits all of these tools where as improvements made in 
KDE or Gnome or QT or GTK... only benefit a subset of users/applications.

For those here who do not have a technical background we tend to think of 
these systems as being made up of a stack of components that are layered on 
top of each other like a layer cake.  Perhaps being overly simplistic at the 
bottom sits the hardware.  The next layer is the OS kernel which provides 
basic services like memory and process management and the device drivers 
which provide an abstraction of the hardware for the layers above.  For X11 
systems the third layer contains X11 and the other system level libraries.  
The next layer up is the DE or window manager (like KDE) and the various 
libraries that applications use (like Qt) and the last layer is the actual 
applications.  The icing in between these layers and between pieces in the 
same layer is the applications programming interfaces (APIs) that are used to 
allow the pieces that make up these layers to interact with each other.  Here 
is a simplified diagram.

------------- applications -------------------
--- KDE ---- Qt --- other libraries ------
---- X11 ---- system libraries -----------
---- kernel --- hardware drivers -------
---------------- hardware ------------------- 

Interaction can happen in any direction but generally components at higher 
levels request services from components at lower levels.  Interaction can 
also occur between components at the same level (IE. KDE makes calls to Qt) 
and Interaction can occur that crosses several levels.  For example LProf 
does most of is Interaction with X11 (or other Windowing systems on other 
platforms) through Qt but makes direct calls to X11 when doing video card LUT 
manipulations (Qt has no video card LUT API and I don't expect that it ever 
will) and LProf does the same thing for Windows and OS/X by making system 
specific calls for this on each platform.

Although Windows and OS/X hide it from users by presenting the middle three 
layers as a single component in reality these platforms have basically the 
same structure although the pieces have different names and unlike open 
systems it is very difficult to replace specific components in the stack.

>
> Proposal:
> Using the OpenICC wiki to make the usage of color in QT and some
> representative KDE projects transparent. I would recommend to
> concentrate on Konqueror as file browser and Krita as one of the leading
> CM aware applications in the KDE universe.
> The goal of this actions should be a good integration of LCMS into QT,
> support for embedded profiles in QT pixmaps and vector objects, getting
> the monitor profile from X11 / Oyranos in QT and the colormanagement of
> pixmaps and vector objects from the embedded profile to the
> monitor-profile into QT.
>
> To make the OpenICC and this mailinglist more public, we can reference
> in the next steps in wikipedia in the KDE, QT, colormanagement etc.
> topics to the openICC wiki and the mailinglist.
>
>
> -----
>
> What do the others in this list think about this proposal ?
>
> Regards
> Jan-Peter

I agree that we should leverage the OpenICC Wiki to provide specifications and 
requirements for various parts of the open source CM puzzle.  One of the 
issues we face is that implementing system wide color management impacts a 
wide range of projects such as X.Org, Qt, GTK, KDE and Gnome.  This is only a 
few of the many that will need to participate if we are to achieve the vision 
that is being laid out here.   Our issue is how do we get these projects to 
start doing what needs to be done?  

I think that if we were to first document an over all phased implementation 
plan (IE. a series of small sub projects) that lays out at a high level a set 
of steps and what each step will accomplish.  We would also need to document 
a detailed set of specifications and requirements for the first set of steps 
and as progress is made for all steps.  This, I think, would result in 
developers working on the affected systems to start laying the ground work 
and to eventually implement the needed functionality.   Ideally these steps 
should be small and there should be many of them each with goals that are 
fairly easy to accomplish.  For example, a doable sub project would be to 
implement video card LUT management in X11.  This would be fairly easy to 
write a set of specifications for and could be implemented without too much 
difficultly over the next few months and could conceivably appear in a stable 
release of X11 later this year.  Other sub projects could be things like 
cleaning up code in KDE, Gnome, and various applications like screen savers 
that currently clobber the video cards LUTs.   Some of these sub projects 
could/should be worked on concurrently. 

Lets not fool ourselves this is a large complex undertaking and there is no 
way that this is going to happen other than by taking a series of small steps 
that each lead toward the desired end result.  Unless we (IE. the color 
people) can lay out what those steps are it will likely not happen at all or 
at best will take much longer to happen.

I think X11 is the critical piece at this point since it sits at the center of 
almost everything on the desktop.  Until it provides some base level of CM 
functionality there is little reason for a tool set like Qt to provide 
features like the ability to tag pixmaps with a profile.  In addition, tool 
sets like Qt,  FLTK, GTK+... are cross platform tools meaning that 
applications that use these tool sets can and often are built to run on all 
of the available operating systems and hardware architectures.  For example 
LProf uses the Qt widget set and runs on the various *nix operating systems 
as well as Windows and OS/X.  It is clear that at this point Windows and OS/X 
do not provide any incentive for tools sets like Qt to provide features like 
profile tagged image formats so at least initially this will be an X11 only 
feature.  But again this in an area were we can provide leadership if we 
choose to do so.

Hal