[Openicc] Color Management for Ubuntu

[Ann McCarthy]

It would help quite a bit for the discussion if you could come down off of
your high horse Edmund.
There was no hint of 'we know best' -- only a proposed approach.

Your statement that you are "working in devicespace, and do not have a
profile in place on the system for the device being tested." is curious.

Please explain how you can be "working in device space" in which I gather
you are viewing some kind of print representation on a display - yet you do
not have a profile for the print system which would be necessary for
rendering the print space content to a display? Perhaps if you described
more of your workflow ...

I am not surprised that you have direct experience with vendors who
expressly intend to make color management and profile use hard. My intention
is that color management should be clear and simple, as complicated as
necessary and not one stitch more. In order to get there, users such as
yourself have to be willing to describe their abstracted workflow
requirements, not mired in the muck of workarounds they have previously been
forced into by current system limitations.

Best regards,
Ann L McCarthy
Imaging Systems R&D
Lexmark International, Inc.



On Tue, May 3, 2011 at 5:17 PM, edmund ronald <edmundronald at gmail.com>wrote:

> On Tue, May 3, 2011 at 11:00 PM, Ann McCarthy <almccart at lexmark.com>
> wrote:
> > Thanks for the good example Edmund.
> >
> > So the scenario you are describing is 'printer profile already applied -
> > don't do it again'.
> > In your experience, have you found sufficient workflow hooks are in place
> to
> > handle avoiding applying the printer profile in the box when printing to
> a
> > printer that has an in-box RIP/CMM?  Or perhaps you have not tried it
> with
> > that kind of system?
> >
> > Anyway -- this scenario should be handled under the basic rule of CM
> which
> > is: "if the source profile of the content matches the profile of the
> > destination THEN do not re-apply the destination profile." In my view an
> > intelligent CMM should always apply that rule. So that is why I did not
> list
> > it as a case of 'turn color management off'.
>
> Ann,
>
> Not so. At the time of assembling a composite of profile tests, I am
> working in devicespace, and do not have a profile in place on the
> system for the device being tested.
>
> I am saddened by the fact that you are falling in the Apple trap of
> "We know best". If I want to bypass the whole profiling mess, I want
> to bypass it, and I probably know why, and once I say so I would like
> to decisively bypass any second-guessing by the CMS or CMM, however
> smart or brilliant the intergalactic CMM spaceship may be feeling on
> that particular day :).
>
> And no, I am not a user of RIPs. But I used to be vendor-qualified by
> a RIP manufacturer, and during training it was explained to me that
> distributors for large-format production RIPS consider profiling to be
> a tool for paper-vendor lockin, and therefore the distributors
> explicitly want profiling and profile changing and indeed paper
> configuration to be made as difficult as possible for the RIP end-user
> (in the contract printing context.)
>
> Edmund
> _______________________________________________
> openicc mailing list
> openicc at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/openicc
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/openicc/attachments/20110503/cdbcf598/attachment.htm>