[Openicc] ALL YOU NEED IS A PROFILE, THE MYTH. (WAS CC Profiles In X Specification and dispwin)

[Gerhard Fuernkranz]

edmund ronald wrote:
> I think I need to put out a new topic explaining why PROFILES COME LAST.
>
> Profiles allow softproofing on screen. They allow simulation. They
> allow gamut mapping. BUT THEY COME LAST.
>
> The inkjet industry has been exposing "visible" profiles because they
> allow the above (softproofing, simulation, gamut mapping) when used
> with Photoshop. However in practice, the profile will only get decent
> results if the press or inkjet driver are already pretty well tuned to
> put down the right amount of ink on paper.
>
> The inkjet native drivers do this, in a "secret" way. Which is why
> using third party papers or inks is complicated. No surprise here,
> inkjet manufacturers make their profit from paper and ink sales.
>
> What the inkjet guys and RIP resellers really guarantee in exchange of
> their excessive profits is perfect stability. A print run today and in
> one year with new inks, a new batch of paper,  and maybe with a
> different OS and maybe with a PC instead of a Mac, and maybe even a
> new printer of the same brand and model etc etc will usually still
> yield results that are usably close. This is why canned profiles are
> useful, why third party profiling makes sense, and why end-users don't
> need spectros.
>
> Before open-source people start to worry their heads about profiles
> they should first turn their attention to obtaing the same degree of
> cross-platform cross-application and time-invariant stability
> guaranteed by the native printer drivers.
>
> PROFILES COME LAST, folks, really..Just like Gutenprint is already
> pretty useful, Argyll is also very good; Lots of people own spectros,
> and they're getting cheaper. Profiles themselves are easy to make.
> Creyating the preconditions for a good profile is hard.
>
> 1. If your printer drivers have a block the shadows or have an
> insufficient gamut because of bad linearisation, color consultants
> will advise users to use native drivers because  it's very hard to
> compensate for bad linearisation.
>
> 2. If your system keeps varying its output each time you update then
> your end-users will get VERY unhappy and will ditch your apps presto.
>
> In summary: Profiles are the last link in the printing chain, and
> probably the most trivial step for well-equipped domain experts to
> achieve, even if this appears counter-intuitive to programmers.
>   

But I also would not renounce profiles! Actually I find the way how
gimp-print performs color conversion/correction too complicated. There
are a bunch of controls, but the effect of the controls to the resulting
colors, and the side-effects are not really clear and hard to predict.
IMHO, for instance the color workflow for a CMYK printer driver can be
fairly simple, if it is based on color profiles:

    * driver's CMYK input -> four 1D-curves which do the linearization
      and the per channel ink limiting -> halftoning engine -> raster
      data -> done

      (the 1D curves should IMO support at least 10 or 12 bits/channel
      on input, and 16 bits on output. The halftoning engine should work
      with 16 bits/channel)

and if the driver also wants to offer inputs for other color spaces,
then the flow in the driver could look like

    * CIELAB input (is already PCS) -> CMYK profile for the printer ->
      feed to driver's CMYK input

    * sRGB input -> sRGB profile -> PCS -> CMYK profile for the printer
      -> feed to CMYK input
      (this could even be optimized by using a sRGB -> printer CMYK
      device link profile)

    * SWOP emulation input (CMYK) -> SWOP profile -> PCS -> CMYK profile
      for the printer -> feed to CMYK input

    * etc.

This way there are no hand-crafted color conversions are required.

If additional user-defined color corrections should be supported (e.g.
enhancing/reducing contrast or saturation), they could be applied in the
PCS in a generic way (one could for instance build an abstract profile
for the correction on the fly, and link it into the conversion chain;
LCMS for instance provides the function cmsCreateBCHSWabstractProfile()
for such a purpose).

For CcMmYKk printers we would basically just need to extend the above
CMYK model by three additional 1D curves, such that the Cyan, Magenta an
Black channel of the CMYK input can be split into the corresponding
light and dark ink components. For multicolor printers (with orange,
green, red or blue inks in addition to CMYK), I admit that the model
will become a bit more complicated...

I don't want to go deeper into details now. However, the important issue
is IMHO that driver models like above should be well-defined,
well-documented and fixed, i.e. the behaviour should not change
incompatibly from version to version. Also the halftoning algorithm
should not change, since this would have an effect on the color
reproduction (new halftoning algorithms could of course be introduced
additionally in new versions, but the old ones should be retained too).

Stable driver models would IMHO be a prerequisite in order that a
repository of calibration curves and ICC profiles for various
printer/ink/paper combinations could be established by the community.
The driver would just implement the bare model(s), and the
parametrization of the model(s) would come from the repository.
Additionally there should be tools, which aid in the establisment of the
calibration curves for the different driver models (CMYK, CcMmYKk,
multicolor,...) from measurements. Tools to create ICC profiles are
already available, e.g. Argyll and commercial ones.

Regards,
Gerhard