Bug 9949

Created attachment 8665 [details]
First test program

17 objects are drawn to see colorimetrics spaces. TEKHVC, CIELuv, CIELab spaces
are wrong. There are trigonometry errors in xc/lib/X11/Xcmsint.h. Definitions of CIELab and CIELuv must be rewritten (xc/lib/X11/Lab.c and xc/lib/X11/Luv.c). See patch below.

Created attachment 8666 [details] [review]
Patch to fix first example.

Created attachment 8667 [details]
Second test program

5 graphics are draw to see limits of CIELab space. Dark limits of the
space are not perfect. A color must move in CIELab space not in RGBi space.

Created attachment 8668 [details]
Patch to fix second example.

Created attachment 8669 [details]
First example

Use an image (anyone jpeg, png, gif, eps...). Convert this image to
plain ppm with 2^48 colours:
   
   anytopnm image.anyone | pndepth 65535 | pnmtoplainpnm > image.ppm

Here, it is better to install the colour characteristics of your monitor with 
xcmsdb program, ICCM convention or with xc/lib/X11/LRGB.c and
xc/lib/X11/Xcms.txt (optional).

The script palette.c reduce the number of colours in CIELab space.
Here, the step between two colours is 2.0 CIELab units:
   
   gcc -ansi -Wall -o palette -L /usr/X11R6/lib -lX11 palette.c
   ./palette -display $DISPLAY -delta 2.0 image.ppm > image_delta2.ppm

Convert now image_delta2.ppm to pixmap:
   
   ppmtoxpm image_delta2.ppm > image_delta2.xpm

With ./palette, it is possible to convert any photography to pixmap. Sometimes
you can use -delta 3.0, sometimes you must use -delta 1.0.

To see any pixmap image:

   gcc -ansi -Wall -o view_xpm -L /usr/X11R6/lib -lX11 view_xpm.c
   ./view_xpm -display $DISPLAY -zoom 3 image_delta2.xpm
   ./view_xpm -display $DISPLAY -zoom 1 image_delta2.xpm

view_xpm.c attached below.

Created attachment 8670 [details]
view_xpm.c to go with previous example program.

Created attachment 8671 [details]
Second example.

The script xpmcielab.c convert the pixmap with RGB colormap to pixmap with
CIELab colormap and write the new image in a file controle.xpm.
   
   gcc -ansi -Wall -o xpmcielab -L /usr/X11R6/lib/ -lX11 -lm xpmcielab.c
   ./xpmcielab -display $DISPLAY image_delta2.xpm
   mv controle.xpm example.xpm

The image is now OEM independent with absolute colourimetry.
   
   head example.xpm
   ./view_xpm -display $DISPLAY -zoom 1 example.xpm

Created attachment 8672 [details]
Third example.

For this example DRI must work.

   gcc -ansi -Wall -o 65536 65536.c
   ./65536 > 65536.xpm
   head 65536.xpm

This pixmap image has 256x256 pixels, 65536 colours.
   
   ./view_xpm -display $DISPLAY -zoom 1 65536.xpm

glx_cms.c show xcms space in 3D.

   gcc -ansi -Wall -o glx_cms -L /usr/X11R6/lib  -lGL -lm glx_cms.c
   ./glx_cms -display $DISPLAY -type xyY 65536.xpm
   ./glx_cms -display $DISPLAY -type CIELab 65536.xpm
   ./glx_cms -display $DISPLAY -type CIELuv 65536.xpm
   ./glx_cms -display $DISPLAY -type CIELab example.xpm
   (few seconds with CPU 650 MHz).
 
   Use up key, down key, left key or right key, ESC key for exit.
   
   ./glx_cms -display $DISPLAY -type TEK 65536.xpm
   (ten minutes with CPU 650 MHz).

Created attachment 8673 [details]
glx_cms.c to go with previous example.

Sorry about the phenomenal bug spam, guys.  Adding xorg-team@ to the QA contact so bugs don't get lost in future.

The OpenICC [1] compiz plug-in project aims at providing colour 
transforms with ICC [2] profiles.

Lcms is a C library, which can transform colours through ICC profiles.

The Oyranos project aims at providing the glue between the above projects
and normal desktop applications.

The elder Xcms seems obsoletet by the widely adapted ICC specification.

Eighter of the OpenICC and the xorg mailing lists are good places
to discuss this toppic.

[1] http://www.freedesktop.org/wiki/OpenIcc
[2] http://www.color.org

Every attachment to be compiled thus far shows a large number of warnings in valgrind. Some of them even have over a hundred warnings. I'm probably not seeing the complete spectrum with some of the glx examples, but I cannot say what is at fault. Almost all of the valgrind examples have two levels of backtrace (meaning that the problems are almost certainly within the application, instead of the library).

I'm going to close this bug as being invalid. Reopen this if you have some examples that don't have a lot of valgrind warnings in them. I'm not saying this to dismiss your bug report, just that I want to make sure that these problems are not a result of numerous invalid reads.

* Additionally, one of the examples -- I can't remember which -- yielded a nasty 'glibc detected...double free' message. You may be onto something.