[Printing-architecture] [Printing-japan] Last OP SC - Mon/Tue -2/3 February 2009 - The Recording

Petrie, Glen glen.petrie at eitc.epson.com
Thu Feb 5 08:41:07 PST 2009

Hello Hal,

Thanks for review of our printing "color management" discussion.  We are
all looking for inputs to help in this complex subject.

PLEASE, please, ... note that my only objective in my reply below is to
seek understanding and create general understanding by all interested

I have exactly the same understanding that you do in discussing document
applications.  That is applications like GIMP, Open Office, and so
forth.  Each of these document applications must work with different,
multiple, modified, enhanced and even user defined color spaces.

What about printing?

Let's define the print processes as starting with a document
application, moving to a print spooler/manager (i.e. CUPS) and
associated transforms (i.e. Ghostscript); and, finally, the print
drivers which produces the physical print.

As I stated above document application must handle "color management" in
its broad scope.

The print spooler/Manager, like CUPS, does not care about "color
management".  Yes, CUPS has a capability to produce "raster" output, but
as a generic spooler/manager it is does not get involved in the "color
management" aspects of a document. CUPS (spooler/manager) can manage
transforms for the print jobs.  Example would be PS-to-image or
PDF-to-image.  In this case, CUPS is using a transform application; but
CUPS itself does not get involved in the "color management" processing.

<< side note >>  Part of understanding is understand terms.  To me, but
not to all people, the term "raster" refers dithered, ink (not color,
but ink) output values that a printer actually prints.  A "raster" is
not RGB or any other color set of values; even if the image format is
not a standard; like CUPS "raster".  CUPS "raster" should be called CUPS

Back to transforms, like Ghostscript which, like CUPS above, is only
being used as an illustrative example.  Transform applications like
Ghostscript, to me, are document application; they are not print
application in the sense that it is not a printer driver.  Yes,
Ghostscripts contains, actually, it supports drivers; but actually,
Ghostscript transforms a document from one format to another.  Example,
it transforms a PDF or PS document to an image document (and not a
raster format).  And yes, I'll bet Ghostscript can actually produce
actually raster output; but, I am trying to make the point that most
transforms are document format transform.  Thus, Ghostscript follows
your description below and needs to support all aspects of color
management you describe.

If what I discussed above is the scope of the "color management"
discussion for the print summit; then I believe, the "color management"
group (you) need to continue your great support and creating
understanding to the document applications.  However, if the "color
management" is about color-to-ink, then .....

This is where I need your help on how to use and incorporate your "color
management" with printing at the driver level.   

1. Inks are not pure colors; 
	that is cyan ink is not real pure cyan color 
	and the same is true for all inks.

2. Inks can only be deposited in discrete units (i.e. a drop 
	and drops of different sizes).
	Thus, dithering is required in order to create the
	desired image color; but this is a tradeoff with 
	not creating undesirable artifacts or blurring the final
      print representation of the image.  And this is coupled
	with print intent; that is, dithering is different for line
	art/text than photos.

I don't think of "color management" is doing the dithering but only
concerned that the color value of an individual pixel (maybe an area)
meets the intent.

Color Management could "help" with "1." above if an ICC profile is
supplied for every print.  That is, a document is transformed from its
current color representation to the printer's gamut.  But this would
only be "helping" since dithering "2." Typical affects the details of
color-to-ink transformation.  Thus, this color-to-ink transform is
typically done in the driver which understand both the effects on color.

Depending upon the solution (embedded, mobile, desktop, office,
production) the creation of ICC profile may or not be practical.
Remember it is not just one ICC profile per printer but because of "2."
above it could mean many ICC profiles.

One solution is to give the "color management" system an ICC profile
which is the sRGB gamut; problem solved.

Changing subject slightly.  I believe the importance of printer ICC
profiles is so that, at least an approximation of, the final printed
document can be viewed on a display by the user and will show the final
printed colors.  In this case, then an average/representative ICC
profile for all of the printer modes could be supplied; at least this is
a reduction from N to 1.

Now the reality of creating ICC profiles.  Due to the open source nature
of Linux, not all contributing individuals will have the capability
(meaning equipment), time or desire to create ICC profiles for their
instantiation of their driver which needs to take into account "1." and
"2." above. This was the reason for suggesting sRGB as expected input
color space to driver.


> -----Original Message-----
> From: printing-japan-bounces at lists.linux-foundation.org
> japan-bounces at lists.linux-foundation.org] On Behalf Of Hal V. Engel
> Sent: Tuesday, February 03, 2009 5:12 PM
> To: Open Printing; Printing-japan
> Subject: Re: [Printing-japan] [Printing-architecture] Last OP SC -
> -2/3 February 2009 - The Recording
> On Tuesday 03 February 2009 02:46:16 pm you wrote:
> > Hal V. Engel wrote:
> > > Till,
> > >
> > > Just listened to the recording.  Thank you for making it
> There
> > > are apparently some misconceptions about how color management
> So
> > > here is some feedback.
> > >
> > > It is not acceptable to use sRGB or any single color space as the
> > > acceptable or required document color space.  It appears that this
> > > something that comes up every time a new application starts
looking at
> > > color management.  For example, this same thing was discussed at
> length
> > > when the GIMP developers started looking at CM and in the end they
> > > not use the "required color space" approach since the CM experts
> > > them not to (in very strong terms) and when they actually got into
> coding
> > > it they discovered that is was actually counter productive and not
> > > needed.
> > >
> > > User land applications should be able to send documents to the
> > > device (printer, monitor...) in any color space(s) it wants to
> In
> > > fact it is common for those doing color critical work to avoid
> since
> > > it has a very limited gamut and it is common for devices like
> > > and cameras to have much larger gamuts (in many cases almost twice
> > > big).   So friends do not let friends use sRGB.  Keep in mind that
> this
> > > is the document color space and it needs to have enough gamut for
> > > device that created the document and it's gamut has nothing to do
> > > the printers characteristics.
> > >
> > > The correct approach is allow the user land app to specify any
> document
> > > color space (actually compound documents like pdf can have more
> one
> > > color space since pdf allows for each individual object in the
> document
> > > to have it's own color space).  In fact there is no other
> > > approach.  In addition it is typical for documents to have the
> document
> > > color space(s) embedded in the document and since the document is
> passed
> > > to the printing subsystem the document color space(s) are
> by
> > > the *toraster filter.
> > >
> > > The consensus from discussions on the OpenICC list is that the
> time
> > > sRGB is used by default is when the user land application does not
> > > explicitly pass a document color space(s) and any document or, for
> > > compound documents, any object in the document that has an
> > > profile has passed an explicit color space that must be used.  In
> if
> > > the printing work flow is correctly designed there is no need to
> > > what document color space(s) are used as this will be handled by
> > > color management engine when the *toraster filter sets up the
> > > transforms that it needs for the document it is handling.
> > >
> > > On the "OS level" you do NOT need agreement on what color space
> be
> > > used but rather what needs to be agreed to is how the
> > > from the document color space(s) to the output device color spaces
> will
> > > be handled. There is work underway on this end of things by the
> OpenICC
> > > folks. Specifically Oyranos which is a system wide CM
> > > management back end that is being worked on my Kai-Uwe Behrmann
> for
> > > KDE the Kolor Manager System Setting applet which is a KDE4
> > > Oyranos front end that is now in the playground area of the KDE
> > > repository.  We hope to have Kolor Manager included in KDE 4.3.
> > > Currently Oyranos has no support for CM configuration of printers
> > > only devices that currently have full support are monitors) and
> is
> > > an area that needs to be addressed along with scanners and
> The
> > > KDE front end was written as part of GSoC 2008 and there were
> > > discussions during that effort about how all these other devices
> should
> > > be supported.  In particular printers generated lots of interest
> > > there is some preliminary code in Kolor Manager related to printer
> > > configuration along with similar code for scanners.  Our hope is
> > > introduce printer support into Oyranos and Kolor Manager as the CM
> parts
> > > of the printing work flow are being developed.
> > >
> > > Rendering intent in the color management context has a limited
> of
> > > options most of these are defined by the ICC and are to some
> > > standardized.  These are absolute colorimetric (no white point
> > > transformation), relative colorimetric (this causes a white point
> > > transformation), perceptual and saturation intent.  For relative
> > > colormetric intent users can also select black point compensation
> help
> > > reduce the loss of shadow details when the transform is going to a
> device
> > > with reduced gamut compared to the document color space.  So there
> > > actually 5 rendering intents and all of these are supported by
> So
> > > all that actually needs to happen is that users can select the
> and
> > > this gets passed through to the *toraster filter so the the
> > > uses the correct intent when it creates the raster that is passed
> the
> > > printer.   At present most document formats do not have a
> > > way of embedding this information.
> > >
> > > There is a need for user land applications to be able to discover
> > > printer color space(s) (IE. profiles) so that applications can do
> > > proofing.
> > >
> > > RAW is NOT a color space as that term is used in the color
> > > world.
> > >
> > > Hal
> >
> > Thank you for your mail. You have sent it to me in private, but I
> > to discuss it on the printing-architecture mailing list, could we
> > your mail there to start the discussion?
> Yes I can do that.  I was not too sure where I should send it so I
kept it
> private.
> >
> > So good to hear that the color correction
> Color Management types would say "color space transform" rather than
> "color
> correction" because this could also be doing things like taking an RGB
> or Lab) document and converting it into CMYK or even deviceN output
> the
> printer.
> > can be done completely on the
> > server side.
> Doing the transform on the server would be the preferred way to handle
> this.
> Right now we are limited to doing this client side in the user land
> that
> are sending output to the print server.  This means we only have color
> managed
> printing in those apps that know how to do color managed printing
> right
> now is a very limited set of apps (probably less then a dozen total
but I
> can
> only think of three off hand and one of those is a specialized front
> for
> gutenprint).  Having this functionality on the server side means that
> CM
> dumb apps benefit once things are properly configured.
> > A color-managed driver will then use an ICC profile in a
> > standardized directory on the server and functions of a CM library
> > execute the color correction.  The PPD will have a "Rendering
> > option with the choices mentioned in your mail, option and choices
> > standardized names for all printers. Option settings are passed to
> > as IPP attributes and this way also the rendering intent gets to the
> > driver. The driver will get all option settings by its command line.
> > Perhaps color correction has too be better done by the renderer
> > (Ghostscript or Poppler, Ghostscript preferred), as a raster image
> > have only one color space where as vector graphics, especially in
> > format, can have a separate color space for each object.
> I think this assessment is correct.  In fact having this happen in the
> *toraster rendering filter makes things much simpler for everyone
> doing
> this would eliminate the need to do any color management specific
> modifications to the individual drivers and it would also centralize
> functionality in one place.  For example once GhostScript has been
> to
> have an up to date CM implementation (I think we should have at least
> development versions with this capability soon) and the new
> filter
> is setup to handle CM the new pdf based printing work flow will have
> functional CM for all apps using it, including apps that are not CM
> no
> matter what printer/driver is being used.
> As a side note Poppler has now been patched with preliminary CM
> functionality
> and the testing I did with it seemed to work OK.  So it might make
> to
> continue to use Poppler for the common printing dialog since it's CM
> support
> might be "good enough" for this use.
> >
> > The ICC profile of each print queue also needs to be downloadable by
> > clients via CUPS' http server facility, so that apps (or the Common
> > Printing Dialog) can get them for soft proofing.
> Currently the CUPS API allows client side apps to get a list of
> that
> are in cupsICCProfile lines in the PPD.  But there were several open
> issues
> with the CUPS implementation the last time I checked.
> 1. If the CUPS server is not local there is no way to get the profile
> soft
> proofing.
> 2. CUPS only allows passing a user specified printer profile on the
> command
> line if the profile is installed in a specific directory on the CUPS
> server
> and there is no way in the general case for a client app to get a list
> these profiles or to get a copy of any of these profiles.
> >
> >     Till
> >
> >
> > P. S.: Thank you for registering for the OpenPrinting Summit. You
> > welcome to attend and I am looking forward for the Color Management
> > session.
> That is why I registered.  I live with in commuting distance of the
> conference
> which makes it fairly easy for me to attend.  So I guess that I will
> the
> OpenICC representative there and perhaps there will be others as well.
> > From the CM side not only you but also Michael	Vrhel
> > (Ghostscript) is attending.
> _______________________________________________
> Printing-japan mailing list
> Printing-japan at lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/printing-japan

More information about the Printing-architecture mailing list