[Openicc] Linux CM ideology, was: meta data in test chart

[Max Derhak]

Hi,

As I'm on the ICC AWG working with others on ICC.2 at the moment I'd
like to pipe in a bit here.  We are definitely open to outside input.
Before I say anything else though, let me make it perfectly clear that
ICC.2 is not meant as a replacement for ICC.1.  If you are happy with
ICC.1 then stick with it.  If you are unhappy, then we can talk about
ICC.2 which is really meant to address areas (though not all) that ICC.1
does not address well.

At this point I think it is a little early to say exactly all that ICC.2
is or is not. We have general guiding principles and areas that we want
to work on.  We are still putting together preliminary specifications
and there are several different aspects to it that are open for input.
Once we have things basically specified then we will work on an open
source reference implementation.  We are open to have others help in
this endeavor.  

However, I don't think that ICC.2 will end up being a one size fits all
sort of thing.  Different workflows will have different needs which will
take different parts out of what is going into ICC.2. (I think of ICC.2
as addressing various vertical markets).

With the concept of reference profiles in ICC.2, the idea is to be able
to convey what the data is (rather than how to operate on it).  However,
at this point how the transformation is performed by the CMM is yet to
be decided.  It could simply be that the reference simply becomes a hash
to a full fledged profile used by the CMM.  Alternatively, the CMM could
have an internal implementation that converts device values to/from
colorimetry.  (Whatever it is - I would prefer to keep it simple).

However, other aspects of ICC.2 are not based upon Measurement only data
with the transform in the CMM.  Measurement data is usually sampled.
However, for color management to work you really need a model
(preferably an invertible one) that allows you to predict any device
value combination (not just your data samples). Going from sampled data
to a model isn't always straight forward (for example an RGBW projector
with only RGB addressing).  Having different CMM/profile requirements
for all possible device nuances makes the prospect of defining a CMM
daunting.

For predictability purposes it is easier to have programmability of the
device model defined by the profile itself (since that is what is being
conveyed with the color image data).  Things otherwise get complicated
(as Chris alluded to).  A key goal of ICC.2 is to provide for enough
direct programmability in the profile so the best model can be
implemented (rather than just a sampled/interpolated lookup table).
This allows the CMM to be much simpler and portable.  However the CMM
does need to be more complicated than what is in ICC.1 to allow for some
extended programmability in a profile.  Since models are generally
compact, you may also end up with simpler profiles as well.

There are other aspects to ICC.2, but I won't bore you with them now. 

Max Derhak
Senior Software Architect
max.derhak at onyxgfx.com

-----Original Message-----
[mailto:openicc-bounces+max.derhak=onyxgfx.com at lists.freedesktop.org] On
Behalf Of Chris Murphy
Sent: Wednesday, February 02, 2011 12:47 PM

On Feb 2, 2011, at 2:36 AM, Kai-Uwe Behrmann wrote:

> Am 01.02.11, 21:51 -0700 schrieb Chris Murphy:
>> What I really meant to say is that I don't know what their interest
is in supporting a new direction, e.g. a derivative ICC specification,
or whatever it would be. Whatever new direction would seem to require
their involvement. And if they are involved in it, but not involved in
Linux, I think open source still needs a say in the direction. I don't
think getting a collection of companies who ultimately compete against
each other is exactly the best collection of people to create a
committee because it's a conflict of interest. We've already had that.
> 
> What could be the corner stones of a new or derived CMS?
> 
> * measurement based colour conversions

Well ICC.2, which may produce a v5 spec, is exactly about measurement
based profiles and transformations being in the CMM. I do not know how
clear the line is drawn, or where the line is drawn. But such effort
requires substantially updated CMMs to support a major version change.
And a big shift in responsibilities of where things go: right now we
choose all sorts of profile building options in profile building
software to define that transform at the time the profile is built; but
in a new paradigm with transforms in CMMs, how do we communicate options
to the CMM?

And in the case of Apple, they prevent any CMM except the Apple CMM from
being used in the print pipeline. So if I'm using a hypothetical Argyll
CMM and really like the results I'm getting on-screen and want to print,
well I'm screwed unless I have a 100% reliable means to have Argyll
prematch the data for print, and then submit the job to be untouched by
the Apple CMM.

And this would be necessary in the CUPS, pdftoraster through GhostScript
through lcms pipeline too. I'm pretty sure GhostScript 9 makes it
possible (maybe even easy) to insert other CMMs into the pipeline. But
this is a big shift to create software that works right in the guts of
display and print pipelines, rather than as separate applications that
build profiles and then step out of the way and aren't directly involved
in the course of actual transforms.

Anyway, ICC v4 has taken a very long time to produce results and we're
still not there yet. A very tiny percentage of workflows are v4, and IMO
that is mostly incidental not by design. So any new or derived CMS has a
very tall hill to climb to be adopted.



Chris Murphy
_______________________________________________
openicc mailing list
openicc at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/openicc