It would help quite a bit for the discussion if you could come down off of your high horse Edmund. <br>There was no hint of 'we know best' -- only a proposed approach.<br><br>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.<br> <br>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 ...<br> <br>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.<br> <div> </div> <div>Best regards,</div> <div>Ann L McCarthy</div> <div>Imaging Systems R&D</div> <div>Lexmark International, Inc.</div><br> <br><br><div class="gmail_quote">On Tue, May 3, 2011 at 5:17 PM, edmund ronald <span dir="ltr"><<a href="mailto:edmundronald@gmail.com">edmundronald@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div class="im">On Tue, May 3, 2011 at 11:00 PM, Ann McCarthy <<a href="mailto:almccart@lexmark.com">almccart@lexmark.com</a>> wrote:<br> > Thanks for the good example Edmund.<br> ><br> > So the scenario you are describing is 'printer profile already applied -<br> > don't do it again'.<br> > In your experience, have you found sufficient workflow hooks are in place to<br> > handle avoiding applying the printer profile in the box when printing to a<br> > printer that has an in-box RIP/CMM? Or perhaps you have not tried it with<br> > that kind of system?<br> ><br> > Anyway -- this scenario should be handled under the basic rule of CM which<br> > is: "if the source profile of the content matches the profile of the<br> > destination THEN do not re-apply the destination profile." In my view an<br> > intelligent CMM should always apply that rule. So that is why I did not list<br> > it as a case of 'turn color management off'.<br> <br> </div>Ann,<br> <br> Not so. At the time of assembling a composite of profile tests, I am<br> working in devicespace, and do not have a profile in place on the<br> system for the device being tested.<br> <br> I am saddened by the fact that you are falling in the Apple trap of<br> "We know best". If I want to bypass the whole profiling mess, I want<br> to bypass it, and I probably know why, and once I say so I would like<br> to decisively bypass any second-guessing by the CMS or CMM, however<br> smart or brilliant the intergalactic CMM spaceship may be feeling on<br> that particular day :).<br> <br> And no, I am not a user of RIPs. But I used to be vendor-qualified by<br> a RIP manufacturer, and during training it was explained to me that<br> distributors for large-format production RIPS consider profiling to be<br> a tool for paper-vendor lockin, and therefore the distributors<br> explicitly want profiling and profile changing and indeed paper<br> configuration to be made as difficult as possible for the RIP end-user<br> (in the contract printing context.)<br> <font color="#888888"><br> Edmund<br> </font><div><div></div><div class="h5">_______________________________________________<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>