[Openicc] Colormanagement in Gutenprint
Kai-Uwe Behrmann
ku.b at gmx.de
Wed Apr 20 22:39:39 EST 2005
Am 20.04.05, 11:42 +0200 schrieb Jan-Peter Homann:
Jan-Peter,
thanks for wading though all the details with us.
Here comes my thoughts.
> I will try to describe, how may colormanagement could be implemented in
> Gutenprint without a lot of steps to do.
>
> The goals of the concept:
> - Open for high-end user, which do individual profiling
> - Use of cannend profiles for standard-usage
> - Use of logical printers as standard printing UI
> - Easy creation of special installation packages with standard-sets of logical
> printers
>
> Later the concept also describes the process of setting up a
> colormanagement-workflow from the application to the printer.
>
> But first, what should be done in Gutenprint ?
>
> 1. Integration of littleCMS into Gutenprint
> --------------------------------------------
> - The input of Gutenprint is always a RGB or CMYK Rasterimage with 8 or 16
> Bit color depth.
Why this limit? The specified input document colour space should allways
be honored.
> - The user can specify source-profile, printer-profile, rendering-intent,
> blackpoint-compensation-flag
> (or as alternative a devicelink-profile, which converts directly from source
> to destination)
> 2. Inkliniting and linearization
> --------------------------------
> Making a good linearization, as basis for good ICC-transformtions needs to
> steps:
> 2a. individual linearization of the pure CMYK channels
> 2b. Inklimiting for a maximum amount of color (GCR)
Does you imaging a on the fly inklimiting profile?
> The user should be first able to print a testchart for making 2a. "individual
> linearization". If this is done, he prints a testchart using the individual
> linearization curves for step 2b. "Inklimit/GCR"
> In the last step he prints the testchart for profiling with active GCR and
> active individual inklinearization.
This is a multi step preparation. Alternatively she/he can use the inbuild
Gutenprint linearisations. They are allready of good quality for a lot of
standard printers.
> 3. Colorworkflow in Gutenprint
> -------------------------------
> After the calculation of the printer-profile, the colorworkflow in Gutenprint
> is as follow:
>
> Image to print
>
> source profile
not needed, this profiles are allways known by the imaging application.
With a different workflow profile, the system should allready know about.
> destination profile
> Inklimit with GCR
> individual channel-linearization
>
> printout
>
>
>
> 3. Configuring logical printers
> --------------------------------
> A logigal printer consists of:
>
> - settings for littleCMS
> - GCR and individual Ink-linearization files
Would'nt it suffice to have one linearisation file? The GCR can be
specified as an option. Maybe you meant it otherwise. Please let
us know.
> - printer-specific-settings (resolution, dithering, mediatype...)
> - name of setting (source-profile, printer, mediatype, resolution)
> (e.g. AdobeRGB_Eps2100_photpap_720)
My suggestion is to include all these setting in one profile. It is, from
a technical point of view, no problem to embedd all setting in one mother
profile. Later the settings can be extracted without any installation
hassles. Simply copy a profile into a standard profile path and select it
in the gui. No locical printer is needed.
Of course a logical printer can be installed if one needs it. For instance
to have a colour managed queue. Which does by default a relevant settings.
For Gutenprint this means; there is logic needed to tell the colour system
about colour options to include into the profile - the final options used
during calibration. These options can result in a text snippet describing
all settings in a configuration format of choice.
Gutenprintgui needs further to read the same data format in (text, xml
...) . All colour relevant settings change to the colour options settings
extracted from the profile and become frozen (grayed out or unavailable).
Later Gutenprint gets the same data again and uses them as options.
The described procedure is easy implementable for the two print plug-ins.
For a general workflow there are two decissions to make. Is it possible
with the PPD approach to set up all Gutenprint settings? Integrate
Gutenprint PPDs into these workflow - generate a PPD from one profile or
leave the options unsplit and dont embedd into a profile. The PPD file can
contains all sorts of geometric options (papertray selection, positioning,
margins ...). The complex colour options are specified together with the
destination profile.
> 4. Export and Import for logical printers
> -------------------------------------------
> If somebody is making linearization-curves, profiles and a logical printer, he
> should be able to export this to one package wich contains all files. Such
> files could be imported from other users, and they can instantly use the
> logical printer without any need for special configurations.
With a all in one profile approach it would become a on file transaction.
Even though the installation into a system directory may need a dedicated
gui.
> Who makes the profiles ?
> -------------
> There are several people available, which would do the work of profiling and
> building logical printers. First there are the opensource minded people, which
> just say, if I made profiles for my printer/media setting, I want to share it
> with other people.
> But the biggest source would be resellers of media and ink-sets. If they
> deliver profiles and a logical printer, they make it easy for their customers
> to use their media.
>
> The user perspective
> --------------------
> So e.G. Carol is making photo-retouche with the new GIMP 2.5, which supports
> AdobeRGB as working-space and she also has a monitor-profile for her monitor.
>
> She has an Epson 2100 and uses Epson Photopaper
> She goes to the Gutenprint homepage an finds a download for a logical
> printer-package with all profiles.
>
> After the download, she just pushes the installer, is happy when she find the
> name of the logical printer in her printing dialogue and likes the results,
> which are coming ou now.
>
> But what about the prints of her webdesign ?
>
> Carol learned, that webdesign should be done in sRGB. So, she has converted
> the high-res AdobeRGB photos to lowRes sRGB jpgs.
>
> She also learned, that the logical printer is always made for one special
> working-space. But no matter, she opens the
Thats completely avoidable. If a system is able to make a difference
between sRGB and AdobeRGB there is no need to express it with special
printing queues "logical printer". It will cause irritation to have one
the one side a colour managed printing system and on the other side the
applications are not able to specify the source or document
profile/profiles .
The simple rule to tread everything which is not specified as sRGB is the
most common acepted.
> "Gutenprint-configuration-assistant", which allows her to duplicate an
> existing logical printer and change only the RGB-workingspace.
> She saves the new logical printer with the name "sRGB_Eps2100_photopap_720"
> and has now two logical printers in her printing dialogue.
> One for her photo-retouching in AdobeRGB and one for her webwork in sRGB.
>
> Printing in a network environment
> ---------------------------------
> The concept of the logical printer makes it easy to use a server with
> GhostScript / Gutenprint in a network.
>
> Imagine a system administrator in a design agency. He is not able to make his
> own profiles, but he can ask the graphic designers what working-spaces they
> are using. He gots the answer
> - AdobeRGB for photos
> - sRGB for web
> - SWOP for printing
> As he is familiar with CUPS, GhostScript and The Gutenprint-Installer, he sets
> up following virtual CUPS-printer in the network:
>
> sRGB-standardpaper
> SWOP-standardpaper
> AdobeRGB-photopaper
> SWOP-photopaper
>
> From the view of the designers, these are normal printers. Internally, the
> printing-data from the designers are ripped with GhostScript to hiRes Bitmaps
> without colormanagement. According the installation, the HiRes Bitmaps from
> different virtual CUPS/GhostScript-Printers are colormanaged with different
> logical-printers, which the administrator downloaded from the Gutenprint-side.
>
> The Graphic-Designers are happy with the print-results, but the virtual
> printer "SWOP-photopaper" should deliver real proofing-quality.
> So, the systemadministrator calls a colormanagement-specialist, which is doing
> an individual linearization and profiling for printing on photopaper with the
> already installed logical printers
> - AdobeRGB-photopaper
> - SWOP-photopaper
I have the same doubt as above.
> Now the design-agency can make their own digital proofs.
> ---
>
> After reading the mails on this list, it should possible, to build such
> workflows without big changes in the architecture of actual design
> applications, CUPS, GhostScript and Gutenprint.
>
Maybe I did not completely understand the goal of all these queues with
different source colour spaces. One thing I like to mention.
The price for a simplistic and easy setup today - user tells via print
queue what source colour space is used - is a lot of confusion in the
future. If the application is dumb regarding colour profiles, it will be a
hassle and a source of uncertainty to use named queues for source profile
specification.
As well there is no way for such a fundamental convenient thing like a
monitor profile with a CM unaware application. With Scribus or CinePaint
the document colour space is defined by default. Automatic watching the
image through a monitor profile is possible only there (hope more
applications will do soon). And of cource these applications can easily
embedd a source profile into a print document.
If someone has the desire to use more than plain old sRGB she/he will use
allways a qualified application.
Transmission of the source/document profile should be no problem.
thanks
Kai-Uwe Behrmann
+ development for color management
+ imaging / panoramas
+ email: ku.b at gmx.de
+ http://www.behrmann.name
More information about the openicc
mailing list