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

[edmund ronald]

Max,

 Thank you for this clarification.  I think everyone here appreciates
the work you are doing, and the fact that you release your code as
open source.

 After reading and posting here for a while, It seems to me that even
if the various specialists who post here manage to assemble a
functional framework for Linux, OS-leve integration and support will
remain haphazard as CMS is not really a priority for X, and
application-level color management will also probably be incomplete
and buggy because apps haven't got it now, and their authors are going
to be faced with an over-difficult programming problem.

 To me it seems that the situation with ICC1 and maybe now ICC2 is
that it works reasonably for vertical markets, but does not offer a
unified conceptual and programming model that is sufficiently simple
as that non-specialised developers find themselves motivated to
implement CMS, and capable of doing so.

 If some other model would be offered that might be much simpler and
unified even though less powerful, then maybe OS-level adoption would
be easier to achieve. To put it bluntly, I believe that the idea of
profiles and renderings which served as the foundation for Colorsync
doesn't cut it in a general-purpose environment. It assumes too much
understanding on the part of non-specialist developers.

I would suggest that writing an "absolute" (colorimetric) color to a
window or a printer might make more sense because it would then be the
responsibility of the OS to make sure that the write-through to the
physical device actually has some acceptable semantics; This would be
a simplification which both the graphics systems designers and
applications designers could relate to.

Edmund

On Wed, Feb 2, 2011 at 9:11 PM, Max Derhak <max.derhak at onyxgfx.com> wrote:
> 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.
>