[Openicc] GSoC CM collaboration

[Kai-Uwe Behrmann]

Am 06.03.08, 13:49 +1100 schrieb Graeme Gill:
> Kai-Uwe Behrmann wrote:
> >>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?
> 
> I don't know what you mean. A serious system CMM will have to be
> able to cache such device link transforms. You can invent a new
> file format, or you could simply use an ICC device link.
> (That's certainly what I've done in the past).

Fine, so building upon the ICC DLs is accepted.
 
> > 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?
> 
> See above. The ICC format is a little short in some areas (color space
> labelling), but some simple extensions can overcome these problems.

You are talking about CmykOG and similiar?

> >>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.
> 
> It increases flexibility. Accessing the user is hard down at the low level -
> in fact, you don't want to do it. You need to make those decisions at a higher
> level, where interaction with the user is easily available.

With the low level code linking to the Oyranos CMS, all services 
are reachable at this level too, including user preferences.
Given the options are available, for X rendering it is the very same to do 
the profile linking at each system level. The composite manager or a 
application link profiles through a Oyranos CMM in the same way. The 
Oyranos CMS caches them all together.

> > 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.
> 
> Sorry, I don't see it as that complex, but then I've built a few CMM's already.

The CMS architecture has always new aspects for me as the implementation 
advances, but the picture becomes clearer.

> > 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.
> 
> If it is felt desirable to have such legacy applications color managed
> without changing them, then it is necessary to change the toolkit they use
> (ie. X11 xlib, xcb etc., or the lower layers those toolkints depend on).

Keith has rejected this in the past. I dont know if hooks will be accepted 
in Xorg.
 
> > Why must the pixel engine be implemented there, read in the composite 
> > manager? I there a technical reason? 
> 
> That's where we started. There is the possibility of efficiently implementing
> 3D color transforms using the GPU. In a system using a compositing
> rendering sub-system, this also takes care of the issue of graphics
> API's allowing read back of color values from pixemaps etc.
> 
> > I'd assumed a CMM deployed by the composite manager is independent. 
> > Probably a technical detail I miss, like direct framebuffer access?
> 
> A compositing manager doesn't need a fully fledged CMM, just the ability
> to implement a given device color to device color transform.

Traditionally CMMs contain profile linking and pixel conversion in one 
endity. This allows for CMM specific profile linking.

Just like lcms not being able to apply out of gamut marking to a device 
link. We have had to circumvent this problem with the CinePaint cache.

Eigther out of gamut marking is not covered by DL's or littleCMS is not 
being able to integrate it. It must be solved before we continue in this 
direction.

As well it is unclear to me, whether we want to expose two CMM selectors 
in the CMS configuration panel like:

Profile linking CMM:  [ArgyllCMM v]
Pixel rendering CMM:  [ShaderCMM v]

These selectors have indeed advantages, but at the same time they add new 
widgets to the UI.
What does the colour experts say about the two CMM selectors?


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