<div><div>Ann,</div><div><br></div><div>With all due respect, how come we spend so much time debating the number of angels that can fit on a metatag, and then we have a Mac print system which is for all practical purposes unusable for profiled printing? Something has gone seriously wrong here.</div> <div><br></div><div>Edmund<br><br><div class="gmail_quote">On Thu, Jan 20, 2011 at 2:57 AM, Ann L McCarthy <span dir="ltr"><<a href="mailto:almccart@lexmark.com">almccart@lexmark.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <br><font size="2" face="sans-serif">Chris,</font> <br> <br><tt><font size="2">Regarding "There is no requirement for the profile builder to populate these tags. There's no support in any package I'm aware of that populates these tags either, you'd have to use something like sampleicc or icctoxml to add the tags.</font></tt><font size="2" face="sans-serif">"</font> <br><font size="2" face="sans-serif">The motivation is there for printer vendors who sell printers with many profiles for various different settings and paper types. In this case the same supplier is providing the profiles, the RIP, the printer, and one or more host drivers. So to make it easier for their users -- to avoid choosing all of those redundant settings and encrypted profile names -- the metadataTag can be used.</font> <br> <br><font size="2" face="sans-serif">Marti has promised to put the metadataTag in littleCMS -- not sure if it is in there yet though.</font> <br><font size="2" face="sans-serif">SampleICC will have support as well.</font> <br> <br><font size="2" face="sans-serif">It is true it will be helpful if one or more of the general profile builder software vendors can add support. However -- to be fair to those vendors -- it seems reasonable for them to wait until a set of actual metadata content for printers etc has been defined by communities such as this.</font> <br> <br><font size="2" face="sans-serif">Best regards,<br> Ann McCarthy<br> Imaging Systems R&D<br> Lexmark International, Inc.<br> <br> <br> </font> <br> <br> <br> <p></p><table width="100%"> <tbody><tr valign="top"> <td width="40%"><div class="im"><font size="1" face="sans-serif"><b>Chris Murphy <<a href="mailto:lists@colorremedies.com" target="_blank">lists@colorremedies.com</a>></b> </font> <br></div><font size="1" face="sans-serif">Sent by: openicc-bounces+almccart=<a href="http://lexmark.com" target="_blank">lexmark.com</a>@<a href="http://lists.freedesktop.org" target="_blank">lists.freedesktop.org</a></font> <p><font size="1" face="sans-serif">01/19/2011 07:08 PM</font> </p></td><td width="59%"> <table width="100%"> <tbody><tr valign="top"> <td> <div align="right"><font size="1" face="sans-serif">To</font></div> </td><td><font size="1" face="sans-serif">openicc Liste <<a href="mailto:openicc@lists.freedesktop.org" target="_blank">openicc@lists.freedesktop.org</a>></font> </td></tr><tr valign="top"> <td> <div align="right"><font size="1" face="sans-serif">cc</font></div> </td><td> </td></tr><tr valign="top"> <td> <div align="right"><font size="1" face="sans-serif">Subject</font></div> </td><td><font size="1" face="sans-serif">Re: [Openicc] colord 0.1.0 released!</font></td></tr></tbody></table> <br> <table> <tbody><tr valign="top"> <td> </td><td></td></tr></tbody></table> <br></td></tr></tbody></table> <br> <br><div><div></div><div class="h5"> <br><tt><font size="2">Comment 1:<br> This is something I've long advocated for both Microsoft and Apple: to the degree that we totally abstract the choosing of the ICC profile itself away from the user, because that really is just another setting, at present. I still find it rather ridiculous that we have to choose "ESP9880_PremiumLuster_2880_PK" and then in another dialog have to choose: a.) the printer model, b.) the media type, c.) the resolution, d.) the inkset, if applicable, all over again.<br> <br> One idea behind the optional tags in ICC profiles was to allow for such settings to be included in the ICC profile itself, so that upon choosing a profile, driver specific metadata in that profile could be used to autopopulate the driver settings so that the printing conditions for that profile were reproduced. So there's that paradigm.<br> <br> And another would be for the user to choose driver settings (or a preset containing them), and then for an ICC profile to be chosen automatically based on those settings.<br> <br> I think depending on ICC profiles containing metadata to do this is completely dead in the water. There is no requirement for the profile builder to populate these tags. There's no support in any package I'm aware of that populates these tags either, you'd have to use something like sampleicc or icctoxml to add the tags. I could be wrong but I think that will go nowhere for the larger ICC market.<br> <br> So it seems that the ICC profile is just another setting in the driver. But still, in the case of application prematching, if the application could pass to the system that chosen profile, the system could look in its database of presets for that profile and choose a default preset of driver settings that calls for that profile. This avoids end user error and is quite elegant.<br> <br> Comment 2:<br> What is "CMS off" isn't always the same for every printer. Many consumer printers are increasingly only accepting/assuming sRGB input, there is no "wider gamut RGB/CMYK" path, let alone DeviceN. So is this CMS off? Well...not really. Can we profile over this behavior? Maybe. I think it's a problem to propose these are all the same thing to users.<br> <br> Chris Murphy<br> <br> On Jan 17, 2011, at 6:49 AM, edmund ronald wrote:<br> <br> > Hi folks, I'm a color consultant providing some input to Robert re.<br> > Gutenprint color management.<br> > <br> > My feeling is that it is very important not only to be able to turn<br> > all CMS off for a printer, but also to be able to cleanly save and<br> > recall complete print setting configurations - and serialize them. In<br> > other words, if I determine a bunch of settings that I want to use for<br> > printing profiled on BizarreBoardPaper with an Epson 9880, I want to<br> > be able to cleanly export this, and ship it to someone who needs this<br> > paper/ink/profile knowledge and who may then choose to reprofile or<br> > relinearize on his own machine when he gets it. Profiles are useful<br> > for consumers but pros often do them upstream, however ink settings<br> > are fundamental for consumer and pro alike.<br> > <br> > Edmund<br> > <br> > On Mon, Jan 17, 2011 at 10:38 AM, Richard Hughes <<a href="mailto:hughsient@gmail.com" target="_blank">hughsient@gmail.com</a>> wrote:<br> >> On 17 January 2011 02:48, Robert Krawitz <<a href="mailto:rlk@alum.mit.edu" target="_blank">rlk@alum.mit.edu</a>> wrote:<br> >>> 1) From the Gutenprint perspective, it's very important to be able to<br> >>> turn this off selectively (for the purposes of profiling, if<br> >>> nothing else). The inability to turn off ColorSync has been a<br> >>> major thorn in the side of a lot of our Mac users, and is actually<br> >>> impeding progress in regards creating a color managed workflow with<br> >>> Gutenprint on that platform.<br> >> <br> >> Yes agreed. gnome-color-manager will have to be able to turn this off<br> >> for profiling too, and I admit there isn't a dedicated method for<br> >> doing this just yet. It's pretty easy to remove all the profiles for a<br> >> device, but then you have to trust the profiler to add them all back<br> >> again after profiling :-)<br> >> <br> >> There'll likely be some sort of inhibit interface for the<br> >> GetProfilesForQualifier method call. Ideas welcome.<br> >> <br> >>> 2) High bit depth capability is essential, at least downstream of<br> >>> colord. Both CUPS and Gutenprint can handle 16 bits just fine, but<br> >>> it's important that the transformation not lose information from<br> >>> the data provided by the user.<br> >> <br> >> I'm quite keen on having colord stay away from pixel manipulation. I<br> >> think that's much better placed in the driver itself, using something<br> >> like lcms. Colord should concentrate on being a smart storage unit<br> >> that can be queried by CUPS for specific bits of data.<br> >> <br> > _______________________________________________<br> > openicc mailing list<br> > <a href="mailto:openicc@lists.freedesktop.org" target="_blank">openicc@lists.freedesktop.org</a><br> > </font></tt><a href="http://lists.freedesktop.org/mailman/listinfo/openicc" target="_blank"><tt><font size="2">http://lists.freedesktop.org/mailman/listinfo/openicc<br> <br> _______________________________________________<br> openicc mailing list<br> openicc@lists.freedesktop.org<br> </font></tt></a><a href="http://lists.freedesktop.org/mailman/listinfo/openicc" target="_blank"><tt><font size="2">http://lists.freedesktop.org/mailman/listinfo/openicc<br> </font></tt></a> <br></div></div><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></blockquote></div><br></div></div>