[Gimp-print-devel] CMS in gimp-print [was: Newcomer to Linux printing ....]

[Kai-Uwe B. <ku...@gm...>]

Am 30.08.04, 20:27 -0400 schrieb Robert L Krawitz:

>    From: "Alastair M. Robinson" <bla...@fa...>
>    Date: Mon, 30 Aug 2004 15:58:08 +0100

>    > I'd argue that - to some extent - it s monolithic thinking that
>    > has caused the delay in getting to grips with the problems. We
>    > need the solution to be modular and pluggable so as to allow for
>    > change and variety and user interventions etc. Observing from the
>    > outside and not
>
>    That's interesting - and I'd agree whole-heartedly, but it's a
>    little at odds with the goal of using ICC profiles end-to-end!
>
>    Hypothetically speaking, if you had a profile for gimp-print's
>    output, and a utility to print a picture from any working space to
>    gimp-print's output space, would that give you enough control, or
>    in the long term do you still see the need for micromanaging the
>    output?
>
> Sure, because there are always monitors, scanners, digital cameras,
> and so forth all of which have their own color issues.  I thought that
> the way this worked was by just using device profiles for everything,
> using a super wide gamut, high resolution color space (La*b*?) as the
> common currency.

Shure for most user control CIE*Lab is an good choice, allowing one to one
matching. Responsibility about inside gamut colors goes to the users as
well. This approach needs an information about the printers gamut. An
gamut holding profile somehow coming from the RIP or the spooler to the
application (bidirectional communication). The current way is to seperate
in the application, knowing about the certain printer. The
standardisation of profile sets in the print industry is an effort to
overcome complicated profile handling.

More an every days issue is to match the printers gamut blindly. Even
artists wish to having theyre images looking simply nice on an printer,
prefering an automated way of arts production.
There are as well issues open. The perceptual profile intent serves these
need today, knowing nothing about other devices than itself or the image.

The further discussion is about device to device mapping, needing two
device profiles. To consider the image gamut and start clamping smoothly
near the gamut borders will shurely be the way. These needs other ways of
handling color pipes than we have today. Software analysing the images
contents (motiv) and creating an appropriate profile will further minimise
the need of user intervention. This is something we have in todays cameras
to findout the correct exposure, in photographic image processing pipes
and in some advanced scan software.

Diversity will, behind all this different concepts, the common side.

With the capability of handly different color spaces in RIPs or spooler
filters, they will be able to serve most of these concepts. One very
interessting thing would it be to do color management in ghostscript,
allowing the pdf way. Scribus goes the internal handling way of controling
all and CinePaint everything ;)   To serve the highest quality for
gimp-print, an direct color management integration will helps at some
degree. Hopefully spooling of higher bit depths will be possible then too.


regards

Kai-Uwe Behrmann
                                + imaging development / panoramas
                                + color management
                                + email :ku...@gm...