[Openicc] Color Management for Ubuntu

[Ann McCarthy]

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

Actually the enriched metadataTag in the profiles will make that
determination more straightforward. When you apply the printer profile to do
your work ahead of printing and then send the job intending that no further
profile be applied, the CMM will be able to use the metadataTag information
to understand that case more clearly and avoid re-applying the destination
profile.

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



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

> Oh, and by the way, I have a really neat example, which is assembling
> composite images for profile comparison:
> Usually I convert the same file using profiles A, B, C etc, and then
> assemble the composite side by side and print "without CM".
>
> But as I said, I see no reason why people like me should use Linux,
> maybe graphics specialists or photographers should just be told
> clearly to use a PC and proprietary drivers.
>
> Edmund
>
> On Tue, May 3, 2011 at 10:39 PM, edmund ronald <edmundronald at gmail.com>
> wrote:
> > On Tue, May 3, 2011 at 7:13 PM, Ann McCarthy <almccart at lexmark.com>
> wrote:
> > When adjusting the inking, as a Gutenprint developer, I need an
> > uncorrected workflow.
> > When retouching an image, I often do so after explicitly doing a
> > conversion to the target workspace, and therefore need an uncorrected
> > print-path.
> >
> > I am really sorry if I am the only person on earth who has these
> > needs, and maybe people like me should not use Linux.
> >
> > Edmund
> >
> >> When not building profiles, are there scenarios when users want to see
> >> uncorrected uncontrolled device behavior?  I cannot think of such
> scenarios.
> >> Please provide examples of such situations.
> >>
> >> Best regards,
> >> Ann L McCarthy
> >> Imaging Systems R&D
> >> Lexmark International, Inc.
> >>
> >>
> >> On Mon, May 2, 2011 at 3:26 AM, Kai-Uwe Behrmann <ku.b at gmx.de> wrote:
> >>>
> >>> Am 29.04.11, 15:20 -0600 schrieb Chris Murphy:
> >>>>
> >>>> I thought we were discussing this "how to" in the context of the CPD
> (I
> >>>> think I have that right-the common print dialog). And also within
> >>>> GhostScript.
> >>>>
> >>>> And also still unresolved is whether this is an opt-in color
> management
> >>>> in the print pipeline or opt-out. And I think to answer that we need
> to know
> >>>> the same thing for dispay compensation sonwe don't have a disconnect
> between
> >>>> display and print by default.
> >>>
> >>> We want to go with a explicite opt-out approach. All content shall be
> >>> colour managed by default (typical sRGB). A robust mechanism
> >>> for disabling system colour management is a pre condition for that
> scheme
> >>> to work.
> >>>
> >>> kind regards
> >>> Kai-Uwe Behrmann
> >>> --
> >>> developing for colour management www.behrmann.name + www.oyranos.org
> >>>
> >>> _______________________________________________
> >>> openicc mailing list
> >>> openicc at lists.freedesktop.org
> >>> http://lists.freedesktop.org/mailman/listinfo/openicc
> >>
> >>
> >> _______________________________________________
> >> openicc mailing list
> >> openicc at lists.freedesktop.org
> >> http://lists.freedesktop.org/mailman/listinfo/openicc
> >>
> >
> _______________________________________________
> 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/8c3ffb1a/attachment.htm>