[Openicc] Workingsspace vs. late binding

[Graeme Gill]

Jan-Peter Homann wrote:
> 1) Central working spaces and consistent color
> -------------------------

> If you are being a webdesigner, you get used to the sRGB workingspace 
> and it would be very bad, if your known color numbers suddenly have a 
> very different appeareance.

That's the reality of different colorspaces. Someone used to working with
particular numbers should stick to their familiar color space. If they use
other colorspaces, they should (of course) expect to have different numbers
for the same color, or perhaps expect an interface that lets them deal
with colors in a more device independent way.

> The best way to serve this approach, is to force all imaging solutions 
> to convert color to the workingsspace

You are talking about policy, and you are not likely to get wide agreement
with such a policy. I don't actually think this is relevant to creating
a color infrastructure, since it should be aimed at providing mechanism
that can support a wide variety of policy (at the application level
for certain, and possibly at the system level as well).

> For most graphic designers, this is a fine working workflow:
> 
> RGB-workingspace: sRGB
> CMYK-workingspace: SWOP (America) Euscale / ISO (Europe) 

If you are referring to graphic professionals in general, I doubt
you will get agreement on this statement. Try suggesting this
on the Colorsync list for instance, and see what sort of reaction
you get !

Many Photographers are unhappy with the gamut of
sRGB, and uses something like Adobe RGB or other wide gamut RGB
as a working space.

In traditional print workflows, SWOP/Euro has been very popular,
but modern print workflows are moving to a device independent
format (where the printer does the separation), or shipping
the printing profile to the pre-press/graphic professional,
and separating to the particular press profile.

> 2) Late Binding ICC-workflow

> For shure, it is possible to write programmes, which are conform to this 
> approach and conform to the possibilities in PostScript, PDF etc...
> But the danger is, that we get an inflation of profiles. The profile 
> chain is breaking, if one object is opend in an applications which 
> ignore embedded profiles and can´t embed it.

Such an application is not compatible with a color managed workflow,
so can't be expected to function properly. The idea of providing a
standard color/graphics infrastructure is to make it as easy as possible
to write color aware applications.

> Also, working according numbers is not possible.

That's a user interface issue, not an infrastructure issue.

> Normal designers are often mixed up, with this workflow.

So they need a consistent set of tools, some improved interfaces for
dealing with color, and some education in the reality of device independent
and device dependent color. At the end of the day they will be better off,
and producing better work.

> To the last, we have yet no standards for perceptual gamutmapping in the 
> ICC

I don't see that this is relevant. Functional gamut mapping is available,
and doesn't have to be standardized to implement successful color managed
workflows.

> Result: Programmers should give the users the possibilty to  make the 
> choice:
> - consistent color, with conversion to the workingspace
> - late binding color, with individual profiles for every object.

Agreed. System color infrastructure and applications should allow
a variety of workflows, to suite the tasks and preferences that
different users face.

> Third Possibility: Smart CMMs with individual Gamutmapping per object.
> --------------------------------------------------------
> Such workflows are far away from ICC and a project for reasearch.

I don't see this as a distinct choice, but just a technical variation
on 2). A color space conversion can use the standard ICC gamut
mapping approach (using the pre-canned gamut mapping in the
B2A tables of the destination space ICC profile), or it can
compute a custom gamut mapping for that source/destination
colorspace, or even the particular objects gamut. It's just a flag
that is added to the object meta-data that is used to influence
color handling, and set a different quality/speed/space trade-off.

Graeme Gill.