[Openicc] printing GUI vs. printerdriver, LINUX colorinfrastructure

[Hal V Engel]

On Wednesday 20 April 2005 08:37 pm, Graeme Gill wrote:
> Coming back to color profiles, in practice (particularly with
> inkjet printers), it's not reasonable to insist on a hard coded
> one to one relationship between mode combination (ie. paper type,
> resolution, print modes etc.) and profiles. There is too much
> of a combinatorial explosion. For example, a typical inkjet
> may have a dozen paper stocks from the manufacturer, plus countless
> others from 3rd party suppliers. There are very often several
> resolutions and print modes (ie. dot sizes, interleave modes)
> available. Multiply all this together and you start needing
> several hundred different profiles to cover every combination.
> [If any of you have looked at a lot of the profiles provided
>   with some of the inkjets, you might notice that the profile
>   coverage is patchy, and many of the profiles are duplicates.]

I agree totally with this in the context of the standard canned profiles that 
will need to be available at some point.  It should be possible to have a 
handfull of canned profiles that will cover most of the printer mode/media 
combinations well enough to satisfy most users and for draft work for those 
who are doing color critical work.

For color critical work my personal experience indicates that profiles will 
only give me the results I want with a very narrow range of mode/media 
combinations.  In color critical work the biggest variable is the paper.  In 
general if I custom profile the Ilford Galoria Gloss paper I use at say 
1440DPI that profile will still work well enough for color critical work at 
2880DPI and 720DPI with the same paper.  But not at 360DPI or lower.  And I 
would not expect that same profile to work as well with say Epson Premium 
Glossy paper.  But this likely would be close enough for less critical uses.

In most cases users that are doing color critical work will use a limited 
number of printer mode/paper combinations for color critical work and create 
custom profiles for each of these combinations.  I typically have 5 or 6 of 
these per printer at any given time.  Like I do those users will likely use 
the default printer CM for other uses and for draft work since there is a 
significant amount of effort involved in creating custom profiles.  A 
printing system that automatically selected profiles that are "close enough" 
for these other printing tasks would be a huge improvement over what we 
currently have. 

>
> The best idea I came up with to tackle this issue was to use
> the power of a calibration system (which partly compensates for
> many of the major variables caused by resolution, dot size and
> interleave modes), with a "fuzzy" profile matching scheme.
> Each profile is labelled with the print parameters it was
> created for (private ICC tags), and this is used in a weighted
> difference sum to compute a match factor with the desired
> operating mode. The profile with the best match is chosen
> as a default. This would mean that a "profile not available"
> type error is avoided, hidden duplication of profiles is unnecessary,
> and the user gets the best possible profile available under the
> circumstances. Of course they can be warned about an imperfect
> match, so that they have the option (given tools) of creating
> a profile for a specific paper+print mode.
>

Of course this assumes the existence of profiling tools that will create the 
needed tags either at the time the profile is created or that will add the 
tags later.  None of the tools that I use currently have this capability.  
But it should not be hard to implement a tool that adds these tags to a 
profile.  In the long run we will need to implement open source profilers for 
printers as at present the only open source tools I know of are the command 
line tools in Argyllcms and I don't know how close these are to being usable 
in a production environment.

It might even be possible to use these tags to help out the "fuzzy" profile 
matching by including additional information beyond the specific printer mode 
involved such as allowing the profile creator to indicate a range of settings 
that should work "good enough" and perhaps also the specific paper that the 
profile was intended for.  So the "fuzzy" algorithm would then know that this 
profile is best if used at 1440DPI but will also give satisfactory results at 
any resolution 720DPI and up for example.   The user would also be told that 
this particular profile was intended for say Epson Premium Glossy paper to 
help the user decide if this profile is good enough.  So it appears to me 
that using the private ICC tags could be a very powerful tool to help users 
get the best possible results from canned profiles.