[hpoj-devel] Ghostscript, Gamma, Color Management

[Gerhard F. <ger...@fu...>]

"Robert G. Brown" wrote:

> I'm going to spend some time trying to fix the printer resolution and
> gamma problem next.  When I print photos, the gamma is without exception
> too dark (which isn't the printer per se, which works "perfectly" on a
> color copy process).  Pictures come out looking muddy and dark.  Even at
> 300dpi, the printer should be able to do much better, especially on the
> more expensive smooth finish inkjet photo paper.  I don't know if this
> is just an incongruity between the cdj550 postscript translator and this
> printer or if it is a real problem with the printer itself, but I assume
> the former.

I could obtain reasonable result for printing sRGB (see below) color
images

- by using the cdj550.upp ghostscript driver
  (uniprint driver parametrized for cdj550) and

- by applying a gamma correction (with a gamma in the range 1.0-1.5)
  before sending the image to my OfficeJet 500.
  (Please note, that the the cdj550.upp driver already has a built
  in gamma correction of ca. gamma=2.0)

E.g. "pnmgamma 1.2 <image>.ppm | pnmtops | lpr ..."
               ^^^
               gamma

For me these prints look reasonably, but of course the reproduced colors
are still not exact.

With the cdj550 driver (with no additional gamma correction at all)
printed images will definitely look too dark. I'd try a gamma somewhere
in the range 1.5-3.0 for this driver. Subjectively I think that the
cdj550.upp driver prints somewhat nicer, than the cdj550.

In gs6.01 there also exist new uniprint drivers "cdj690.upp" and
"cdj690ec.upp" (econo fast), but I've never tried them.


But actually you wanted to know some backgrounds:

You will see below, that it is actually neither a problem of ghostscript
nor the printer (except your printer is defective).

Generally the problem is the missing color management. Images you scan
with your scanner are delivered by the scanner in the (device dependent)
color space of the scanner. The printer (in your case ghostscript in
conjunction with the printer) expects, that you send color images to gs,
which are in the (again device and ghostscript dependent) printer color
space.
So in order to reproduce the colors of a scanned image corretly on a
printer you just have to convert the image from the scanner color space 
to the color space of the printer, before you send the image to the
printer.
This is called color management. It converts a device dependent input
color space to a different device dependent output color space by a set
of (sometimes very complex) transformations. It also has to map the
gamut (i.e. the set of reproducible colors) between the devices, because
the printer usually is not able to reproduce all the colors which the
scanner is able to "see".

And even if you simply want to print an image file you have received
from somewhere, then you have to convert the color space of the image to
the printer's color space in order to reproduce the colors correctly on
the printer.  So the resulting colors will not only depend on the
printer's color profile, but in the same way also on the color profile
of the image itself.

This implies that if you want to print an image file, but you don't know
the color profile of this image, then you will never be able reproduce
the original image correctly on the printer, even if you have a
calibrated professional color printer, whose color profile has been
individually measured and calibrated.

The conclution is, that if you directly send an image file to the
printer (without any color transformations) and it does not print as
expected, then this is not necessarily the fault of the printer. The
reason is just that the color profile of the image and the profile of
the printer simply don't match. You can't say, that either the one or
the other profile is wrong, they just don't match and require
transformation.

The Internatioal Color Consortium has established a standardized way and
file format to represent color profiles of devices. These are the so
called ICC profiles (see http://www.color.org).

In order to overcome the problem that each image file requires an
attached color profile specifying the color space of the image, HP and
Microsoft have created a standardized color profile called sRGB.
sRBG is an ICC color profile, which describes a virtual output device,
which properties are close to a common, avarage CRT monitor. The W3C
consortium, for example, also has adapted sRBG as standard color profile
for storing images in the world wide web. This means, that images you
find on web pages are usually assumed to be in the sRGB color space
(except otherwise specified, which is rarely the case).

BTW: You may ask, why the colors of images scanned and/or printed with
Windows often look better than on Linux. Microsoft Windows does have a
color management system integrated into the operating system.
Windows does know how to deal with ICC color profiles and Windows
printer or scanner drivers often also include a color profile
specification for the printer (in conjunction with the supplied driver),
e.g. the profile "\windows\system\color\hpdesk.icm" for HP's ColorSmart
driver for HP deskjets. So even though hpdesk.icm is not calibrated for
each individual printer but only for the "average" printer of the same
model this is still better than having no profile at all.


Here just a few links where you can find more info and more links:

http://www.scarse.org
http://www.scarse.org/links.html
http://www.color.org
http://www.freecolormanagement.com/color/links.html
http://www.littlecms.com
http://www.srgb.com

If you follow all the links (and indirect links and so on) then you will
find out, that color management is actually an extreme complex topic and
that it is much more complex than just setting a single gamma value
correctly. A simple gamma adjustment is only one of the possible color
management transformations, but there exist also other, much more
complicated transformations (matrix, 1D lookup tables, 3D lookup tables,
etc.). And there are so many things to take care of to get the colors
right ...


BTW:
When I think about SANE, then probably I'd appreciate, if I could
specify a (calibrated) ICC profile of the scanner and the ICC profile of
the working space (-> the colorspace in which the scanned image will be
stored or delivered to the SANE application, e.g. typically sRGB)
instead of the three curves, which I will never get right so that all
colors are reproduced correctly.
This would require the inclusion of e.g. scarse/icclib or lcms (see
links above) in SANE and could IMHO be useful.


Gerhard