Introduction
Introduction
- Subject: Introduction
- From: Robert L Krawitz <email@hidden>
- Date: Mon, 12 May 2003 21:02:23 -0400
I've been discussing color management with Ryan for a bit, and Ryan
suggested that I join this list. As Ryan said, I'm the project lead
for Gimp-print. I hope I'm not breaking protocol by making my first
post long and opinionated. Ryan sent me a few posts, and I wrote up
some comments, and now I'm on the list I'll post 'em. This isn't
*directly* related to ColorSync, so I apologize if this is off topic.
For those folks not familiar with Gimp-print, our site is
http://gimp-print.sourceforge.net. The project itself is of a
collection of printer drivers for UNIX operating systems; in addition
to the core driver library, there is a CUPS driver, and some other
things.
Gimp-Print 4.2, the current stable release series, has been around for
about 18 months (we're currently at 4.2.5). The big weakness with
this release series is color fidelity. Development is currently
taking place in the 4.3 series (currently at 4.3.14); when this work
is complete, it will be released as 4.4 or 5.0. So while we're
working on both 4.2 and 4.3 in parallel, there won't be any major new
functionality added to 4.2, because we don't want to destabilize it.
This pretty much means that there won't be any serious color
management added to 4.2, although there is a 16-bit CMYK input
available to it that someone could add color management to.
In contrast, 4.3 is in active development, and it's going to be a
while before it reaches stable release status. We don't want to rush
it along too quickly; we want to make the next stable release very
good, both in quality and in architecture (indeed, architecture is a
more important focus of this release -- the quality of 4.2 is already
good enough for a lot of purposes, but the architecture's very
limiting). It won't be perfect, but the architecture needs to be able
to accommodate some key capabilities. Probably the most important
open issue is color management.
A few basics about Gimp-print: internally all data paths are 16 bits
wide. While most people input 8 bit color (RGB, CMYK, or K),
everything is immediately converted to 16-bit linear resolution. The
internal color space is K, RGB, or CMYK; the externally supported
color spaces are K, RGB, 8-bit CMYK, 16-bit raw (i. e. assumed to
already be linearized) CMYK, and 16-bit printer-specific raw
(i. e. one input channel per output ink). Conversion from CMYK to
printer-specific is currently done in the dither (screening) code, but
this is clunky, requires a lot of extra code, and very limiting. It
uses the concept of a "virtual dot size", which is the product of the
actual drop size and the darkness of the ink. I'm designing another
layer to fit between the color conversion/adjustment/linearization and
the screening code.
This will have several advantages:
1) It separates the ink drop size from the darkness of the ink. This
allows us to do ink limiting in the color transformation code (in
this new layer), which currently cannot be done (it's very hard to
do it in the dither code, and really hard to get right).
2) It will let us make adjustment of the ink balance be externally
parameterized rather than coded into the ink drop size
description. This makes it accessible for profiling.
3) It will simplify the dither code. Currently, the CMYK dither
routines use the black value as part of the decision process into
whether to print with dark or light ink. We do this partly for
implicit ink limiting, partly because the light inks won't
contribute much to darkness in the presence of a lot of black ink,
and partly because the dark dots won't stand out in the presence of
black ink. This is special cased for CMYK dithering; K, CMY, and
printer-specific dithering don't need this.
4) It will simplify the ink descriptions for the printer drivers
themselves.
5) It should improve quality by letting us usefully use the smallest
dark ink drops.
It won't require color conversion modules to actually produce
printer-specific data; color modules that don't want to do that will
have this step automatically added by the core.
I am not a color expert, which is why I'd like to get as much input as
possible. I'm trying to focus right now on the internal constructs
needed to support color management, and then encourage people who are
experts to write the code to implement specific color management
facilities.
I think of color management as feedback. The color management
techniques that I'm most familiar with involve creating a profile that
maps the input color space to the output color space. The feedback
part is that typically you print something out and then compare it in
some way to the input, and then the software creating the profile
computes the adjustments needed to make a good map. From what I read,
current technology in this area leaves a lot to be desired. It's my
opinion -- and this is admittedly not based on direct measurement, so
take it for what it's worth -- is that good color management needs to
be based on these principles:
* The color management should not assume that the printer's or
driver's linearization and channel splitting (C => Cc) algorithms
are any good. If they were that good, we wouldn't need printer
profiles, so for best accuracy the output of the CM should represent
something close to the printer's capabilities.
* Corollary 1: The output space should be high resolution (e. g. for
inkjet printers 16 bits -- significantly higher tonal resolution
than the output device is usefully capable of representing). This
allows the mapping function to have more precise outputs.
Output that I've seen from Epson's own drivers always looks very
blown out in the highlights. If the difference between an input of
0 and an input of 1 is too great, nothing the color management can
do will help -- it just can't represent the values it needs to.
* Corollary 2: The color management should be done in a color space
matching the desired output device (at least for printers). This
again is to allow the mapping function more precision.
This is more complex: in addition to the fact that the dark and
light inks might not match perfectly between batches and paper
types, it becomes impossible to do ink limiting in the color
management because the color management doesn't know how much ink
will actually be deposited.
This also means that RGB color management isn't too interesting for
Gimp-print, since we don't support any native RGB printers. What
would make more sense is for the GIMP to pass us data in a specified
high resolution gamut, and for Gimp-print color management to work
in high resolution CMYK, CMY, CcMmYK, or whatever the appropriate
printer-specific space is. CinePaint (previously known as FilmGimp)
is a better model in this regard.
* The gray ramp is critical. Ryan mentioned a 33x33x33 profile to me,
indicating a color cube of axis length 33, with interpolation
between points. The problem with this is that this only gives 33
points along the diagonal; even slight errors introduced by the
interpolation will likely yield noticeable color shifts. While a
256x256x256 color cube isn't too practical, and 64Kx64Kx64K isn't
even worth thinking about, it's probably worth the effort to create
a really dense sampling on the gray diagonal, because even slight
offsets from true gray are so noticeable.
Again, what I want to do personally is devise the right abstraction to
allow people who really does know what they're doing to plug into our
core. My opinions on this might be all wrong, but even so it's
important to support the right abstractions.
--
Robert Krawitz <email@hidden>
Tall Clubs International --
http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail email@hidden
Project lead for Gimp Print --
http://gimp-print.sourceforge.net
"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton
_______________________________________________
colorsync-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/colorsync-users
Do not post admin requests to the list. They will be ignored.