Great timing Edmund. I will share this information in the AWWG meeting this afternoon. Best regards, Ann McCarthy Imaging Systems R&D Lexmark International, Inc. <table width=100%> <tr valign=top> <td width=40%>edmund ronald <edmundronald@gmail.com> Sent by: openicc-bounces+almccart=lexmark.com@lists.freedesktop.org 02/15/2011 06:03 AM <table border> <tr valign=top> <td bgcolor=white> <div align=center>Please respond to Open ICC Color Managment <openicc@lists.freedesktop.org></div></table> <td width=59%> <table width=100%> <tr valign=top> <td> <div align=right>To</div> <td>OpenICC Liste <openicc@lists.freedesktop.org>, argyllcms@freelists.org <tr valign=top> <td> <div align=right>cc</div> <td> <tr valign=top> <td> <div align=right>Subject</div> <td>[Openicc] Fwd: Settings bundles (Robert Krawitz, Edmund Ronald)</table> <table> <tr valign=top> <td> <td></table> </table> <tt>Please find below a post by Robert on the gimp-print list, and my own expansion on the topic. Comments are welcome. Please excuse the crosspost. Subject: Re: Settings bundles To: Robert Krawitz <rlk@alum.mit.edu> Cc: gimp-print-devel@lists.sourceforge.net My short explanation: There is a movement to system-wide ICC color management on the Linux platform, which of necessity impacts printing. The aim is that default settings of the color management machinery should present seamless display and printing color to the naive user. Also, fully color managed workflows should be facilitated for photography enthusiasts and the graphics arts community. To coordinate the system color there will be some sort of central registry which associates color behavior (ICC profiles) for a given display or printer/media combination, and provides the user interface for modifying these associations when necessary. So Gutenprint needs to provide an interface to this color registry. For the printer, inking settings and ICC profiles are indissociable. A profile is only valid under the conditions it was made.  At this point we have concluded that serializing the inking settings and exporting them to the system profile registry is the way to go. This serialized settings model will allow users to download inking settings and profile bundles for non-vendor media from the Internet. It also substantially simplifies the development of new printer drivers because it allows non-developers to tune inking parameters for third party use, allowing us to crowdsource media settings. As developers or color management  specialists who interact with Gutenprint, we will be the first stakeholders in this serialized settings format, especially when we create new printer drivers. We can expect to work with this format extensively when fine-tuning a printer/media combination, and so we expect that some graphics tools for ink-curves, linearisation etc will need to be written to facilitate work which was up to now done more painfully. Some of these tools will also build in Graeme Gill's Argyll package that allows access to measurement instrumentation. So, we should be choosing a format that allows non-C++ and non-C developers, people who are not professionally programmers, to play around with creating tools. I don't really have an opinion about the XML and JSON debate, but I think the format we choose should be easily interpreted by graphics tools eg. Javascript code which runs inside a browser window rather than by compiled software. I envisage that something akin to the current CUPS web interface might allow a color specialist to bring up the settings for a queue, tune a curve, and then  write the settings back before running another test job to help tune a new printer. This is going to be a major change in that substantially more of the functionality of Gutenprint will be exposed. But first it needs to be packaged properly for access. The request here is that people assess what form of software they might be using *in the future* to access the added functionality, and help choose a format based on the future functionalities. Edmund On Mon, Feb 14, 2011 at 4:19 AM, Robert Krawitz <rlk@alum.mit.edu> wrote: > There has been a fair amount of discussion on the openicc mailing list > about color management in general and color managing printing > specifically.  Edmund Ronald can say more about the details and > correct any errors I make here, but one of the big issues is choosing > the correct output profile for the job.  That means picking the > correct profile based on the printer and user settings.  Once the > correct profile is selected, applying it sounds like a fairly > straightforward operation. > > If the user's using a color managed workflow, we don't want the user > to use color settings within Gutenprint.  However, we don't > necessarily want those to simply default to the Gutenprint defaults. > The settings involved will certainly include resolution and media type > (which don't have useful defaults), but will also include things such > as color correction and possibly also channel curves and even GCR > curves. > > One issue here is encoding those settings and providing tools for > power users (including ourselves) to generate those encoded settings. > We currently have XML representation for curves, but Edmund suggests > that JSON might be better for this purpose.  The GIMP plugin uses its > own format to store settings, and PhotoPrint uses something else, and > of course the CUPS driver uses PPD files.  There hasn't been any need > for a shared representation, but if we want all Gutenprint clients to > use the same mechanism, we probably want a common representation. > > If we agree on a common representation for serialized settings, we > could use it across Gutenprint applications. > > Thoughts on the general issue, anyone? > _______________________________________________ openicc mailing list openicc@lists.freedesktop.org </tt><a href=http://lists.freedesktop.org/mailman/listinfo/openicc><tt>http://lists.freedesktop.org/mailman/listinfo/openicc</tt></a><tt> </tt>