[Openicc] [Gimp-print-devel] Looking ahead to 5.3

[edmund ronald]

The only easy one for *me* to explain here is #2. I have a printer (1)
which I used for profiling, I have another sample (2) of same model. I
want to make printer (2) look like (1) so that profiles made for (1)
can be used for (2). Epson provides a tool called Colorbase which does
this sort of thing, using spectro measurements (actually density
measurements, I believe.

Now regarding #1 and the rest, I think that a couple of weeks playing
with a spectro, and maybe a look at an industrial RIP, and maybe some
remarks by the author of Quadtone RIP, would inform the decisions by
the principal author of Gutenprint in a very helpful way. The issue
here is to determine how a *domain expert*  can use the information
provided by a spectro, driven by Grame Gil's open-source interfaces to
create ink curves and linearisation files.

However, I would like to restate that in my opinion, if settings and
curves are externally available as parameter files, then the work on
the *core* routines of Gutenprint is basically done as far as program
organization is concerned. It works ? Then leave good enough alone
until an absolute need arises to meddle with it. Adding new printers
must still be done and already seems enough work for the maintainer.
If the PDF crowd want more functionality, fine, let them add it to
their own equally byzantine levels of the Ziggurat.

If I may be allowed an obsolete example, a lot of scientific
typesetting was done with TeX for about 20 years. But the TeX work
itself was basically frozen since the early 80s to bugfixing, and
anyone wanting better or more worked on fonts or macro-packages like
LaTeX.

Edmund



On Mon, Oct 20, 2008 at 12:47 AM, Robert Krawitz <rlk at alum.mit.edu> wrote:
>   Date: Mon, 20 Oct 2008 00:30:01 +0200
>   From: "edmund ronald" <edmundronald at gmail.com>
>
>   I don't think Gutenprint itself should offer ANY embedded color management.
>
> I always like doing less work :-)
>
>   However, I believe Gutenprint should offer a good RGB photographer's
>   CM toolkit for using a spectro to
>   1. Help one linearize a printer for a given medium in order to get the
>   best gamut out of it.
>   2. Help one re-linearize a printer  the printer sample in line with a
>   known ideal sample that has been profiled.
>   3 Help one determine the ink curves
>   4 Provide a tool for printing profiling charts easily with no
>   sharpening or interpolation artefacts.
>   5 Provide standard one-click setting for printing color-managed images
>   in a profiled workflow, with the profile already applied.
>
>   Of course the members of these lists doubtless have better suggestions.
>
> Maybe, but that's a nice comprehensive set of high level suggestions
> to get started from.  Some questions/comments:
>
> 1) What kind of assistance do you envision us providing?  I presume
>   you mean that we should provide some kind of tool that would
>   produce the necessary linearization data, preferably in a way that
>   could be automatically applied to the printing system.
>
>   Note that linearization would have to also refer to a particular
>   resolution (or at least quality preset) and in some cases dither
>   algorithm.  The dither algorithm we can default.  The resolution we
>   can't default because it depends upon the user's desired tradeoff
>   between quality and printing time.
>
> 2) Can you explain #2 more specifically (in particular, how it differs
>   from #1)?
>
> 3) In what way do the ink curves differ from the linearization?
>
> 4) Gutenprint (at least the core library) never applies any sharpening
>   or interpolation.  It resamples if necessary by either skipping or
>   repeating input raster pixels, but it doesn't play games with the
>   input.
>
> 5) Would PhotoPrint qualify in this way?
>
> 6) What do you believe should be done with >4 color printers (either
>   with light inks or with extra colors, such as the Epson Stylus
>   Photo R800)?  Should higher levels do the RGB->DeviceN conversion,
>   or should Gutenprint?
>
>   On Sun, Oct 19, 2008 at 9:37 PM, Hal V. Engel <hvengel at astound.net> wrote:
>   > On Sunday 19 October 2008 07:50:03 Till Kamppeter wrote:
>   >> Robert Krawitz wrote:
>   >> >    From: "Hal V. Engel" <hvengel at astound.net>
>   >> >    Date: Sat, 18 Oct 2008 09:28:34 -0700
>   >> >
>   > snip
>   >
>   >> >    Also work is underway to add CM to the print work flow in a way
>   >> >    that makes it driver independent.  It will take a while for this to
>   >> >    appear and then more time for it to mature but it will eventually
>   >> >    be part of the new PDF based printing work flow.  Once that is in
>   >> >    place CM printing will become available to all applications running
>   >> >    on *nix platforms.
>   >> >
>   >> > I think it's time we determine exactly what role Gutenprint (or the
>   >> > driver, in general) should take in the overall color processing
>   >> > workflow -- what our responsibilities should be and what features we
>   >> > should offer.
>