GSoC CM collaboration

[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).

 > 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.

 > 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.

I don't see it as directly relevant. It doesn't really matter whether a
transform has been created by the linking part of a CMM, or is copied
from an ICC device link.

 >>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.

 > 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 written a few CMM's already.

 > 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).

 > 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.

Graeme Gill.