GSoC CM collaboration

[Kai-Uwe Behrmann]

Am 05.03.08, 12:55 +1100 schrieb Graeme Gill:
> Kai-Uwe Behrmann wrote:
> > Am 04.03.08, 12:35 +1100 schrieb Graeme Gill:
> >>Kai-Uwe Behrmann wrote:

> > Hmm, with device links we enter a difficult field. They should be 
> > supportable without problems in each CMM. Only it is needed to prepare 
> > that on application side, read create the DL and attach it to the plane. 
> 
> The device link information is already there. It's what is
> communicated between the link code and the pixel engine code.
> Note that what I'm talking about here is not anything
> directly to do with ICC device link files.

To avoid confusion I'd like to refer to the data blob resulting 
from profile linking as a colour transform. I know it is sometimes used as 
a abstract endity. Just in our context it helps in making the difference 
to a ICC style device link profile.

To clearer understand, do you think the CMM colour transforms should be 
serialisable or not at all?
Is there a need for a special or individual format to each CMM in opposite 
to the ICC DL format? What are the differences or do you have general 
concerns?

In the Oyranos CMM framework is currently a requirement for CMMs to accept 
ICC DL profiles. This would mean each CMM must write DL's and accept them 
later again to apply to the pixel engine.
 
> > Oyranos shall provide the means to customise individual approaches at 
> > least on the application side.
> > For late binding, read system level, we have to discuss how usefull are 
> > advanced options appear. Do we need special CMM options to apply for the 
> > whole desktop or do we stay on common ground of ICC with standard options?
> 
> But there is no need for late binding at the low system level. Doing the
> binding (== device profile linking) at the high system/graphics API
> level is fine.

It reduces flexibility as pointed out already. I see the consitency in 
danger.

Can we simply write down your ideas in the style of abstract and concrete 
requirements? My feeling is we much too quickly come with ready made 
solutions. Such solutions tend to build walls around the ideas to support 
that idea. With such walls its then much harder to combine the different 
aspects. Exposing of requirements can apply to the innerst circle of 
affected components. Later we see what fits together and what not. The 
toppic is somewhat complex with many components and possibilities and the 
sometimes, at least to me, unclear abstractions we use here.

ColourWiki is original created to collect and discuss CMS ideas. There are 
many pages doing just this for general concepts, GUI, architecture, 
devices and X. 
I wrote about some conceptual thoughts related to this thread here:
http://www.oyranos.org/wiki/index.php?title=Concepts#Consistency
http://www.oyranos.org/wiki/index.php?title=Concepts#Flexibility
http://www.oyranos.org/wiki/index.php?title=Concepts#Late_and_Early_colour_binding
It's all on one page.

Of course there are other places possible to write down like for 
instance the OpenICC wiki at fd.o.

> > Oyranos should support advanced technics at least on application level as 
> > outlined above. Technically there should be not much difference to 
> > system level CM.
> 
> There's no need for low level system level CM, just support of 3D color transformation.
> Even default color space transformation can be handled this way,
> by the higher level system sending the default device link transform
> data down to the low level system, if that is where the color transformation
> is implemented.

I see some problems with spreading the CMMs framework functions and soften 
the late versus early binding concept. But probably one is more free to do 
so if it is explicitely requested on applciation or toolkit level.

My concerns about a pure mixed colour binding concept without a late 
binding fallback:
The fallback, as mentioned now rather often, can not any longer happen to 
the desktop as a whole. It is dependend to a special toolkit or even 
application. For instance Xterm would come in deed implement CM as it is 
likely not bound to a toolkit. twm would never be colour manageable 
provided its goal is to stay apart from further dependencies.
Perhaps a colour transform format must be specified. Not shure what this 
all implies.

You wrote,
> data down to the low level system, if that is where the color transformation
> is implemented.

Why must the pixel engine be implemented there, read in the composite 
manager? I there a technical reason? 
I'd assumed a CMM deployed by the composite manager is independent. 
Probably a technical detail I miss, like direct framebuffer access?

> > But the later is better discussed on OpenICC.
> 
> I'm thinking that it's useful to expose some of the X11 implementation
> community to color management considerations, since it seems that
> such knowledge isn't very wide spread.

Yes, thats much appreciated, as at least I have not too much an overview 
of X. Nethertheless OpenICC has expressed its interesst and we are talking 
here about the architectural base.

I will post this email separately to OpenICC.


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