[Openicc] ookala-mcf

[Hal V. Engel]

On Friday 26 December 2008 01:50:16 Kai-Uwe Behrmann wrote:
> Am 25.12.08, 17:37 -0800 schrieb Hal V. Engel:
> > On Thursday 25 December 2008 07:38:48 Alexandre Prokoudine wrote:
> >> What do you guys know/think about
> >> http://sourceforge.net/projects/ookala-mcf/ ?
> >
> > There is also a LUT plug in but the current code only supports a single
> > monitor since it is currently hard coded to only use display 0 screen 0
> > even though the API has the ability to pass in the information needed to
> > specify a display device.  It does not have XRandR LUT support.  It does
> > have Windows and X11 code but no support for OS/X LUTs.
>
> Do you write about grafic card LUTs or monitor side ones?
> Given that the original intented displays are 10-bit it would be
> interessting whether the grafic card or the display device supports a
> higher bit depth to place the calibration curves.
> Did you see facilities to upload other colorimetric informations into the
> display, like primaries or even CLUT's? 

The LUT utilities in this frame work are for the OS supported graphic card 
LUTS.  All non-VESA standard DDC/CI adjustments like setting internal monitor 
LUTs or internal monitor matrices are located in monitor specific plug ins 
like the one for the HP DreamColor.  

The DreamColor plug in does not directly alter the internal monitor LUT as far 
as I could tell but I didn't dig very deep and the code for this plug in is 
extensive at about 6,500 line of code.  The plug in does have code to adjust 
the white point and brightness of the back light.  This plug in is by far the 
largest and most complex of the plug ins in the tarball.  The plug in frame 
work is very flexible but it also means that there is lots of work that needs 
to be done to make this frame work useful.

One other comment about the LUT code.  There are three significant flaws with 
the code as is.  

1. It does not support OS/X.

2. It lacks multi-monitor support in the back end code but the API should be 
OK at least on X11 and Windows multi-monitor systems.  So as it stands multi-
monitor support is intended but currently unimplemented.

3. It lacks XRandR support.

I have C++ code in the LProf LUT module that could be graphed into the LUT 
plug in for this frame work with out too much difficulty since the LUT code in 
the plug in looks very much like early versions of the LProf LUT modules.  
This would fix #1 and #2. 


> From the descriptions, the HP
> DreamColor's should allow for at least matrix trasnformations inside the
> display.

Yes it appears that the DreamColor plug in does allow for the creation of 
internal monitor calibration matrices (yes plural as it appears that you can 
specify and create more than one calibration target for each monitor).  
Information on calibration targets, installed sensor devices and the plug in 
chain are located in a set of configuration XML files that are located in /etc 
and $HOME/.<something>.  These work in the normal way and the docs said the 
example XML files have detailed in line documentation (I didn't look so I 
can't confirm this but I expect that this is the case).

>
> > I could not get the code to build on my machine and most of this appears
> > to be because of castings issues between wxString, *char and std::string.
> >  The number of places where this happens is extensive.  I suspect that
> > the development work was done using a build of wxWidgets with unicode
> > support turned off.
>
> Hmm, but probably with a request, this can be solved to something more
> portable by using macros?

From the documentation it appears that HP is expecting "the community" to 
continue the work on this frame work most likely in cooperation with HP.  I 
suspect that the code on SourceForge is a very early initial version since it 
appears that I was the first person to download the tarball and I am likely 
the first person outside of HP to try to build this code.  I expect that we 
will see them making more updates in the next weeks/months.   I will try to 
find an email address for someone there and/or contact the admin for the 
SourceForge project to ask them to join this list since we are a major part of 
"the community" and they may not realize this yet.

I was able to fix many of the compile errors with the standard wx conversion 
macros and functions but there were so many of them that I gave up.   I would 
have continued working on it if there were enough there to build a working 
system but because of the missing "sensor" libraries and SDK header files 
there was no reason to continue other than to perhaps use the "Example Sensor" 
(dummy code that returns fake values) plug in to have a look at the UI.   I 
should add that it appears that all of these string related issues will need 
to be fixed in order to make the GUI support more than English. 

Keep in mind that the GUI is a plug in and all of the code with these issues 
were in the GUI plug in and not the main frame work or any of the sensor, 
monitor or other plug ins.  So even if the GUI plug in does not get fixed it 
can be replaced without too much difficultly because of the high level of 
modularity.

FYI - The code is all C++, is object oriented and coded in a very C++ way 
using vectors and other C++ dynamic structures.   The code is also readable 
and not hard to understand.

>
> > Since this came out of HP I wonder if Marti Maria knows anything about
> > this?
>
> Some time ago, around the anounement of the 10-bit HP displays, where
> although rumors on the colorsync list about a open source project. I did
> not knew the name. Thanks Alexandre for spotting and Hal for your nice
> review.
>
> kind regards
> Kai-Uwe Behrmann