<div>Thanks for the good example Edmund.</div><div> </div><div>So the scenario you are describing is &#39;printer profile already applied - don&#39;t do it again&#39;. </div><div>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?</div>
<div> </div><div>Anyway -- this scenario should be handled under the basic rule of CM which is: &quot;if the source profile of the content matches the profile of the destination THEN do not re-apply the destination profile.&quot; In my view an intelligent CMM should always apply that rule. So that is why I did not list it as a case of &#39;turn color management off&#39;.</div>
<div> </div><div>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.<br clear="all">
</div><div> </div>
<div>Best regards,</div>
<div>Ann L McCarthy</div>
<div>Imaging Systems R&amp;D</div>
<div>Lexmark International, Inc.</div><br>
<br><br><div class="gmail_quote">On Tue, May 3, 2011 at 4:44 PM, edmund ronald <span dir="ltr">&lt;<a href="mailto:edmundronald@gmail.com">edmundronald@gmail.com</a>&gt;</span> wrote:<br><blockquote style="margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;" class="gmail_quote">
Oh, and by the way, I have a really neat example, which is assembling<br>
composite images for profile comparison:<br>
Usually I convert the same file using profiles A, B, C etc, and then<br>
assemble the composite side by side and print &quot;without CM&quot;.<br>
<br>
But as I said, I see no reason why people like me should use Linux,<br>
maybe graphics specialists or photographers should just be told<br>
clearly to use a PC and proprietary drivers.<br>
<font color="#888888"><br>
Edmund<br>
</font><div><div></div><div class="h5"><br>
On Tue, May 3, 2011 at 10:39 PM, edmund ronald &lt;<a href="mailto:edmundronald@gmail.com">edmundronald@gmail.com</a>&gt; wrote:<br>
&gt; On Tue, May 3, 2011 at 7:13 PM, Ann McCarthy &lt;<a href="mailto:almccart@lexmark.com">almccart@lexmark.com</a>&gt; wrote:<br>
&gt; When adjusting the inking, as a Gutenprint developer, I need an<br>
&gt; uncorrected workflow.<br>
&gt; When retouching an image, I often do so after explicitly doing a<br>
&gt; conversion to the target workspace, and therefore need an uncorrected<br>
&gt; print-path.<br>
&gt;<br>
&gt; I am really sorry if I am the only person on earth who has these<br>
&gt; needs, and maybe people like me should not use Linux.<br>
&gt;<br>
&gt; Edmund<br>
&gt;<br>
&gt;&gt; When not building profiles, are there scenarios when users want to see<br>
&gt;&gt; uncorrected uncontrolled device behavior?  I cannot think of such scenarios.<br>
&gt;&gt; Please provide examples of such situations.<br>
&gt;&gt;<br>
&gt;&gt; Best regards,<br>
&gt;&gt; Ann L McCarthy<br>
&gt;&gt; Imaging Systems R&amp;D<br>
&gt;&gt; Lexmark International, Inc.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; On Mon, May 2, 2011 at 3:26 AM, Kai-Uwe Behrmann &lt;<a href="mailto:ku.b@gmx.de">ku.b@gmx.de</a>&gt; wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Am 29.04.11, 15:20 -0600 schrieb Chris Murphy:<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; I thought we were discussing this &quot;how to&quot; in the context of the CPD (I<br>
&gt;&gt;&gt;&gt; think I have that right-the common print dialog). And also within<br>
&gt;&gt;&gt;&gt; GhostScript.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; And also still unresolved is whether this is an opt-in color management<br>
&gt;&gt;&gt;&gt; in the print pipeline or opt-out. And I think to answer that we need to know<br>
&gt;&gt;&gt;&gt; the same thing for dispay compensation sonwe don&#39;t have a disconnect between<br>
&gt;&gt;&gt;&gt; display and print by default.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; We want to go with a explicite opt-out approach. All content shall be<br>
&gt;&gt;&gt; colour managed by default (typical sRGB). A robust mechanism<br>
&gt;&gt;&gt; for disabling system colour management is a pre condition for that scheme<br>
&gt;&gt;&gt; to work.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; kind regards<br>
&gt;&gt;&gt; Kai-Uwe Behrmann<br>
&gt;&gt;&gt; --<br>
&gt;&gt;&gt; developing for colour management <a href="http://www.behrmann.name" target="_blank">www.behrmann.name</a> + <a href="http://www.oyranos.org" target="_blank">www.oyranos.org</a><br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; _______________________________________________<br>
&gt;&gt;&gt; openicc mailing list<br>
&gt;&gt;&gt; <a href="mailto:openicc@lists.freedesktop.org">openicc@lists.freedesktop.org</a><br>
&gt;&gt;&gt; <a href="http://lists.freedesktop.org/mailman/listinfo/openicc" target="_blank">http://lists.freedesktop.org/mailman/listinfo/openicc</a><br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; openicc mailing list<br>
&gt;&gt; <a href="mailto:openicc@lists.freedesktop.org">openicc@lists.freedesktop.org</a><br>
&gt;&gt; <a href="http://lists.freedesktop.org/mailman/listinfo/openicc" target="_blank">http://lists.freedesktop.org/mailman/listinfo/openicc</a><br>
&gt;&gt;<br>
&gt;<br>
_______________________________________________<br>
openicc mailing list<br>
<a href="mailto:openicc@lists.freedesktop.org">openicc@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/openicc" target="_blank">http://lists.freedesktop.org/mailman/listinfo/openicc</a><br>
</div></div></blockquote></div><br>