[Openicc] colord 0.1.0 released!

[Max Derhak]

Two thoughts,

1. There are lots of things that go into defining a print mode besides
colorspace, media, and resolution.  The halftoning algorithm (AKA dot
pattern), and printer specific settings like ink set, print head speed,
number of passes, pass interleave (microweave) settings, temperature
settings all can affect the color.  In some cases these are determined
by resolution.  In other cases they are not.  If these things can be
controlled then they should be included with the profile since a profile
is based upon the color that is determined by how these things are set
up.

2. Anyone who thinks they are turning off color management and sending
RGB values to a printer is deluding themselves.  Inks/toners in a
printer use a subtractive color model.  RGB values imply an additive
color model.  Color management is being performed somewhere to convert
RGB values to ink/toner values.  In building a profile for such a system
you are characterizing a color management system on top of the printing
system.  The hope is that the color management system is predictable.
If image based (location dependent) color management is performed you
loose that predictability.  I think what people are asking for when they
desire to "turn off color management" is really they want predictable
color at the point in the color pipeline that they want to build and use
a profile.

Max Derhak
Senior Software Architect
max.derhak at onyxgfx.com


-----Original Message-----
From: openicc-bounces+max.derhak=onyxgfx.com at lists.freedesktop.org
[mailto:openicc-bounces+max.derhak=onyxgfx.com at lists.freedesktop.org] On
Behalf Of Robert Krawitz
Sent: Tuesday, January 18, 2011 7:41 AM
To: Kai-Uwe Behrmann
Cc: twaugh at redhat.com; openicc at lists.freedesktop.org
Subject: Re: [Openicc] colord 0.1.0 released!

On Tue, 18 Jan 2011 09:53:42 +0100 (MET), Kai-Uwe Behrmann wrote:
> Am 17.01.11, 10:49 -0000 schrieb Tim Waugh:
>> On Mon, 2011-01-17 at 09:43 +0000, Richard Hughes wrote:
>>> Sure, which is why the profile qualifier is free text. We're only
>>> suggesting people use the same three dotted nomenclature that
>>> ColorSync uses, but since we can send a simple regular expression to
>>> colord it's quite possible to support random things like
>>> "RGB.Plain.300dpi.RandomFeature|LengthE0"
>>
>> In fact the dotted notation comes from CUPS, specifically the "Color
>> Profiles" PPD extension:
>> http://www.cups.org/documentation.php/spec-ppd.html#PROFILES
>
> If existing specs would be sufficient for Linux, things would very
> likely have already been solved. I think it was much more work on
> the Ghostscript and Poppler cores and pdftoraster filters, than what
> was brought up recently on the CUPS side. We are still in the
> specification stage.
>
> As an example, why the three qualifiers are not enough, think of a
> print queue with the following ICC profile qualifiers:
> RGB.300dpi.plain_paper
>
> Now move the gamma slider somewhere, by accident or what ever
> reason. Each system, which solely relies on the above three
> qualidiers, will horribly fail. A user can print lots of photos with
> that settings without getting a hint from the system that here/his
> profile is pretty useless.

Another example is computers with multiple types of ink (e. g. matte
and photo black ink).  Or linearization curves (not just gamma values).

> Users should not be able to mess up the ICC profile settings. That
> is plain usability logic.
>
> If a PPD is stripped down to just three colour related options + a
> valid ICC profile then we arrive in PPD vendor land, which is appart
> from user settings.

Three color related options aren't enough, *period*.  Let's stop even
considering that as a starting point, and let's make sure we avoid any
ad hoc limits like that.  The PPD limitations (such as 40 byte
selectors) are bad enough, but at least at that time a lot of things
were running 16 bit DOS.

What we really want is a way to tie a particular profile to an entire
bundle of settings, some of which (such as linearization curves) might
not even be scalar values at all.

Something else that would be useful would be the ability to install
entire blobs of settings.  For example, expert users may carefully
linearize and profile a new paper on a particular printer.  This
process may require changing some Gutenprint options (such as density)
from their defaults in addition to setting things like resolution and
paper size.  If these could be conveniently packaged up and
distributed, and installed into the color system, this would be of
great assistance.
_______________________________________________
openicc mailing list
openicc at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/openicc