[Openicc] Fwd: Settings bundles (Robert Krawitz, Edmund Ronald)

[Ann L McCarthy]

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.






edmund ronald <edmundronald at gmail.com> 
Sent by: openicc-bounces+almccart=lexmark.com at lists.freedesktop.org
02/15/2011 06:03 AM
Please respond to
Open ICC Color Managment <openicc at lists.freedesktop.org>


To
OpenICC Liste <openicc at lists.freedesktop.org>, argyllcms at freelists.org
cc

Subject
[Openicc] Fwd: Settings bundles (Robert Krawitz, Edmund Ronald)






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 at alum.mit.edu>
Cc: gimp-print-devel at 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 at 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 at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/openicc

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/openicc/attachments/20110215/0db7808b/attachment.htm>