<div>Edmund,</div><div> </div><div>In general the sRGB capture to sRGB print image paths across the industry do work reasonably well because printers that take RGB input are by default tuned to do a good job with sRGB inputs. This default scenario uses the ICC v2 approach which assumes the gamut mapping and preference rendering will be done in the output side transform.</div> <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 7:17 PM, edmund ronald <span dir="ltr"><<a href="mailto:edmundronald@gmail.com" target="_blank">edmundronald@gmail.com</a>></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"> Ann,<br> <div><br> <br> On 5/4/11, Ann McCarthy <<a href="mailto:almccart@lexmark.com" target="_blank">almccart@lexmark.com</a>> wrote:<br> > It would help quite a bit for the discussion if you could come down off of<br> > 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<br> > profile in place on the system for the device being tested." is curious.<br> <br> </div> I think you understand very well that I may have one or several<br> profile(s) available in my filesystem for conversion without one being<br> having one placed in the printpath. This is typical of what happens<br> when printing intending to print on the same sheet composite files<br> assembled using multiple profiles.<br> <div><br> ><br> > Please explain how you can be "working in device space" in which I gather<br> > you are viewing some kind of print representation on a display - yet you do<br> > not have a profile for the print system which would be necessary for<br> > rendering the print space content to a display? Perhaps if you described<br> > more of your workflow ...<br> <br> </div>As above.<br> <div><br> ><br> > I am not surprised that you have direct experience with vendors who<br> > expressly intend to make color management and profile use hard. My intention<br> > is that color management should be clear and simple, as complicated as<br> > necessary and not one stitch more. In order to get there, users such as<br> > yourself have to be willing to describe their abstracted workflow<br> > requirements, not mired in the muck of workarounds they have previously been<br> > forced into by current system limitations.<br> ><br> </div>Seamless workflow certainly interests you, I believe you fully<br> represent it as you founded an ICC WG which would like to achieve<br> this.<br> <br> Maybe you could explain to us on list how come PictBridge works, as it<br> seems to produce very good straight-from-camera images?<br> <font color="#888888"><br> Edmund<br> </font><div><div></div><div><br> > Best regards,<br> > Ann L McCarthy<br> > Imaging Systems R&D<br> > Lexmark International, Inc.<br> ><br> ><br> ><br> > On Tue, May 3, 2011 at 5:17 PM, edmund ronald <<a href="mailto:edmundronald@gmail.com" target="_blank">edmundronald@gmail.com</a>>wrote:<br> ><br> >> On Tue, May 3, 2011 at 11:00 PM, Ann McCarthy <<a href="mailto:almccart@lexmark.com" target="_blank">almccart@lexmark.com</a>><br> >> 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<br> >> > place<br> >> to<br> >> > handle avoiding applying the printer profile in the box when printing to<br> >> a<br> >> > printer that has an in-box RIP/CMM? Or perhaps you have not tried it<br> >> with<br> >> > that kind of system?<br> >> ><br> >> > Anyway -- this scenario should be handled under the basic rule of CM<br> >> 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<br> >> list<br> >> > it as a case of 'turn color management off'.<br> >><br> >> 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> >><br> >> Edmund<br> >> _______________________________________________<br> >> openicc mailing list<br> >> <a href="mailto:openicc@lists.freedesktop.org" target="_blank">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> >><br> ><br> _______________________________________________<br> openicc mailing list<br> <a href="mailto:openicc@lists.freedesktop.org" target="_blank">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>