[Openicc] colord 0.1.0 released!

[Hal V. Engel]

On Sunday, January 16, 2011 12:18:18 pm Jan-Peter Homann wrote:
> Hello Richard,
> I´m not a developer, so may be my questions are in some cases a little
> bit simple:
> 
> What is a device ?
> for colormanagement in the printing chain, the printer profile has to be
> assigned to combination of device/ink, paper and driver settings. How do
> you solve this with colord / CUPS ? (predifined CUPS queues for every
> combination of (device/ink, paper and driver settings?)

This is a good question.  When I looked at the colord admin interface screen 
shot I didn't see anyway to specify these things and was going to ask about 
it.  Oyranos has had a lot of work done on this part of the printing work flow 
and I think that whatever is being done should leverage that work.

In the CUPS ppd it is possible to specify one or more ICC profile to printer 
mappings that allows for specifying three things.  By default these are:

Media type (IE. paper type)
Resolution
Color Model (RGB, CYMK...)

Color model is mandatory but the other two can be changed to reflect other 
things like specific driver settings (IE. ink settings for example).  I am not 
sure why Color Model is mandatory or even needed since this can be determined 
by looking at the profile.

Clearly being able to specify three things is not enough and I don't see where 
this issue is addressed with colord.  Would it be possible to give us more 
information on this?

> 
> Where to apply the color transformation from source profile to printer
> profile ?
> - colord ?

No

> - CUPS ?

This is the current direction and the printing folks are working toward this.  
When this is in place it will happen in the CUPS *toraster filters.  The 
pdftoraster filter will be the first one with this capability.

This is how things on OS/X are handled.  The main difference is that on OS/X 
there is a proprietary pdftoraster filter that is CM aware.  As a result there 
is a need to implement an open source CM aware pdftoraster filter.  This is 
being worked on at this time. 

> - OS ?

No

> - Printer driver ?

No 

One other possibility is that this could be handled in the CPD on the client 
side (IE. early binding).  But there has not been any work done on this since 
the current focus is to make the whole CUPS back end CM aware.

> 
> Where is the rendering intent from source to printer profile specified ?
> - colord ?
> - CUPS ?
> - OS ?
> - Printer driver ?

Since the CUPS work flow is moving to a PDF based system this can be specified 
in the PDF file that is passed to CUPS.   This allows for this to be user 
configurable.  Rendering intents will then be applied when the pdftoraster 
filter rasterizes the print job.

> 
> What kind of data format is supported to be colormanaged in the printing
> stream ?
> - raster only
> - PDF ?

PDF

Raster based workflows (photos for example) can be embedded into a PDF on the 
client side before sending them to the print server.  This is simple to do and 
all of the needed hooks are in place on *nix systems now days.

> 
> If PDF, where are the color transformations for all PDF content parts
> applied ?

In the CUPS pdftoraster filter.  Currently there are versions of this filter 
that use poppler and ghostscript to handle PDF rasterization.  Poppler has had 
CM support (using lcms 1) since version 0.12.0 (0.18.0 is about to be 
released) but it is not a very mature implementation yet although it works OK.  
Ghostscript has had CM support for some time based on the ArgyllCMS code base 
and is being worked on to make this more complete and more flexible.  When this 
work is complete it will have very advanced CM support that will allow for 
high levels of concurrency and will allow for pluggable CM back ends (IE. it 
should be possible to create a plugin for any CM like ArgyllCMS or ACE for 
example).  The current work on Ghostscript is based on an LCMS plugin which 
will be the default CM.   

> 
> Control slug possible ?
> Is there any way to read, the current colord settings for a CUPS queue,
> to create a control slug on the print out, to document the settings from
> which the print has been created ?

Good questions.

> 
> Best regards
> Jan-Peter
> 
> Am 13.01.11 13:29, schrieb Richard Hughes:
> > First, some background: colord is a project I've been working on since
> > Christmas.
> > 
> > It is a simple system daemon that will be used by GCM and CUPS to
> > manage per-system device-profile mapping.
> > 
> > If you want to try it out with CUPS right now, you'll have to use our
> > development tree http://gitorious.org/cups-colord and be sure to
> > switch to the 'icc' branch. When we've got all the different options
> > and overrides worked out we'll of course push the patchset back to
> > CUPS upstream. Tim Waugh has been doing most of the CUPS work, whilst
> > I've been working on the colord project.
> > 
> > colord works a lot like colorsync on OSX, so the CUPS changes are
> > really quite small.
> > 
> > Checkout the code from http://gitorious.org/colord -- test it, and try
> > to break it. The included cd-self-test program gives you some examples
> > of what we're testing already. Tim has also built the cups-icc patch
> > into Fedora rawhide, which might be an easier way for some people
> > rather than to build the whole of CUPS.
> > 
> > If you're only interested in pretty things, there's a screenshot of
> > the admin tool here:
> > http://gitorious.org/colord/master/blobs/master/doc/screenshot-devices.pn
> > g -- note the admin tool is designed for developers and programmers,
> > *not* end users :-)
> > 
> > Comments (and patches!) welcome, thanks.
> > 
> > Richard.
> > 
> > Version 0.1.0
> > ~~~~~~~~~~~~~
> > Released: 2011-01-13
> > 
> > Notes:
> >   - Colord is a simple system activated daemon that maps devices to color
> >   
> >     profiles.
> >   
> >   - It is used by gnome-color-manager for CUPS integration and is also
> >   
> >     used when there are no users logged in.
> >   
> >   - The only real user at the moment is CUPS, but GNOME Color Manager
> >   
> >     will start depending on colord when it is included in most mainstream
> >     distributions.
> >   
> >   - The DBus interface is not set in stone, and the libcolord library
> >   
> >     will have new API added to it as required. If colord needs to break
> >     public API at this stage for a specific use case, it will.
> >   
> >   - The persistent storage code is not written yet, but that will come
> >   
> >     with the next colord version.
> > 
> > New Features:
> >   - Add a 'Kind' attribute to the device objects (Richard Hughes)
> >   - Add a libcolord shared library that can be used in the client tools
> > 
> > (Richard Hughes)
> > 
> >   - Add an example spec file (Richard Hughes)
> >   - Add a simple colormgr man page (Richard Hughes)
> >   - Add a simple GTK test GUI for testing the DBus interfaces (Richard
> >   Hughes) - Add a simple script to create a test device (Richard Hughes)
> >   - Add basic DBus interface (Richard Hughes)
> >   - Add code for the DeleteDevice method (Richard Hughes)
> >   - Add DeleteProfile() on the main interface (Richard Hughes)
> >   - Add GetProfileForQualifier() code (Richard Hughes)
> >   - Add MakeProfileDefault() implementation to CdDevice (Richard Hughes)
> >   - Add qualifiers to profiles (Richard Hughes)
> >   - Allow clients to set properties on the objects using SetProperty
> > 
> > (Richard Hughes)
> > 
> >   - Expose the device created time (Richard Hughes)
> >   - Fixed typo in ColorManager API description (Tim Waugh)
> >   - Open the profile using lcms2 after we set the profile filename
> > 
> > (Richard Hughes)
> > 
> >   - Provide a method to assign an ICC profile to a profile object
> > 
> > (Richard Hughes)
> > 
> >   - Provide methods for mapping the device ID to the object path (Richard
> >   Hughes) - Use seporate PolicyKit authorisations for each action type
> >   (Richard Hughes)
> > 
> > Richard.
> > _______________________________________________
> > openicc mailing list
> > openicc at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/openicc