[Openicc] [Printing-architecture] Colour

[Hal V. Engel]

On Wednesday 11 November 2009 01:28:24 am Kai-Uwe Behrmann wrote:
> The following text will merely describe what I would like to see as a
> user. Some comments are added to explain what is meant colour management
> wise. Please do not wonder when not even print device selection is
> mentioned in my text. I assume such all to be covered elsewhere.
> As Scribus and other projects have focus and a long experience with
> printing, it would shureley be great to read their thoughts or comments,
> what they would think are useful CM options for CPD.
> 
> 
> Starting the print button I would like to see in a colour management tab,
> offering following basic controls:
> 
> Colourmanage by System      (*)
> Colourmanage in Application ( )
> No Colourmanagement         ( )
> The first would be part of the CUPS *toraster system once its
> implemented.
> 
> 
> Colourmanage in Application (early colour binding):
> A print device profile is needed. So with this option enabled a
> selection for a "Separation profile" should appear showing the
> system installed profiles. The one ICC profile matching the actual print
> conditions the most should be preselected. The other matching and non
> matching profiles should follow in a descending order in the selection
> list. Once Oyranos is distribution ready and availabel it can help in
> preselection and device to profile association.
> The set of useful profiles is dependent to the print process. E.g. for a
> "Rgb" printer I would not like to select a Cmyk or nColour profile, for
> "Cmyk" not a Rgb one.
> 
> For application colour management the responsibility to match between
> options and ICC profile lays in the hand of the user with the help of a
> hopefully well designed application and its helpers.
> It is important to note that any print profile is useful only
> within a defined set of variables associated with print device, medium,
> ink set, driver and driver settings. The Oyranos CUPS module tries to
> cover these relations as they are programatically reachable.
> 
> Two ways to get profile to print condition matching UI wise I may outline.
> preserve - would mean the user selects a print queue.
>             Then a profile selection system can detect a list of
>             available and useful profile and they are presented to the
>             user. All colour related options, except the above and below
>             mentioned colour management options are not changeable. So e.g.
>             a user can change positioning but not the ink set. This is a
>             typical colour managed mode as many vendor drivers offer.
>             A UI, offering expert level control, may allow to prominently
>             breaking the profile to print settings relation as a special
>             option. Typical a warning dialog could popup to say "Hey, do'nt
>             change this setting or your profile does not match any more.
>             Cancel[x] Break[]". You may have an alternative to popups.
> sync     - a user can select whatever options are permitted by the other
>             UI components. The ICC device profile selection is updated
>             instantly (assuming its fast enough).
> 
> The rendering intent, blackpoint compensation would be needed as the
> minimum of options. Additionally a "Simulation profile" and further
> options of the selected CMM can be helpful to designers and prepress
> people. E.g. "Preserve Black" and the like for Cmyk2Cmyk conversions.
> 
> After that I would expect the document gets flattened and converted to the
> requested device colour space, which in turn is sent unaltered to the
> printer. The selected separation profile (must) be embedded and the whole
> thing marked as further not to be colourmanaged.
> Some PDF variants allow for that. But I am no PDF expert. So someone with
> certain knowledge in this field could hopefully tell more precisely, which
> exact PDF versions and attributes are needed to do this in a standard way.
> 

I am not sure that "Colourmanage in Application" is a good descriptive term 
for this option although "early binding" is somewhat descriptive.  What is 
being described is color management on the user machine (in user land) in the 
CPD (or perhaps a CPD color management add in of some sort).  The distinction 
is that some applications do their own CM (Scribus, CinePaint PhotoPrint...) 
and the print system has no way of knowing about this.  Doing color management 
in these apps the user would select the No Color Management option and calling 
this option color management in application could be confusing.

> 
> Colourmanage by System (late colour binding):
> Here is not much to say. The document needs all colour spaces be assigned
> properly, that a remote print host can make colourful sense of the
> content. A option for "Flatten Document Colour Spaces" would help in
> disambiguating the compositing colour space. That is useful for mixed
> colour space documents only. The resulting colour space of a
> colour space flattened document would be the compositing colour space,
> which is typical the default editing Rgb colour space, but can differ in
> some situations. The responsibility to correctly render the document is by
> the print system. Such documents are most portable, as they do not need a
> retargetting, and should therefore be the default setting.
> This approach is in colour terminology called late colour binding, because
> the colours get their final values in a rather later stage.

This should be the default once CUPS has CM aware *toraster filters (or at 
least a CM aware path).  Like the early binding setting it should have a way 
for users to select rendering intents, black point compensation and possibly 
preserve black.  Also these setting need to be passed to and used by the back 
end.

> 
> 
> No Colourmanagement:
> Omit all colour management related settings and enshure that the content
> is not altered during the spooling and printing. This option is important
> to print colour target, prematched files 

IE. output from apps that are CM aware.

> and for special applications,
> where altering of the content is undesireable. It preserves the state as
> is now.

That is all color values are assumed to be device values and should not be 
altered.

> 
> 
> A print preview with a check box to "Simulate on Monitor" would be great
> and many consider it a basic feature, as it will help users to predict the
> print results. To do the proofing, the selected print profile would work
> as the simulation or proofing profile. The target is the actual monitor
> profile for that screen region. 

Even without proofing the CPD should use any installed (IE. X11 _ICC_PROFILE 
atoms) profiles to color manage what is displayed on the screen.  This is a 
good starting point and adding proofing later will be much easier.

> Oyranos has code in the CUPS module to
> obtain certainly the locally stored user accessible ICC device profile.
> Any CUPS profiles, being them local or remote, need more details worked
> out to fit in seamless in a easy manageable workflow.
> 
> If you want to make a professional feature available the kind of on screen
> simulation can be selectable. This means to be able to alter the rendering
> intent for the proofing profile which is separate from the document to
> print rendering intent. The rendering intent for the proofing profile can
> be eigther relative colourimetric as a default and optional absolute
> colorimetric. The later would allow for a "Match to Light Booth",
> compensating for white point differences and do no compensation for the
> monitor white point. A further option would be to "Simulate Paper White"
> on screen, which is included in the previous option as well but without
> the absolute white point.

Currently the CPD only allows for a fairly small preview.  This limits it's 
usefulness for soft proofing.  Most users interested in having on screen soft 
proofs will be using applications that have the ability to do soft proofing and 
that allow these proofs to be displayed in a larger window.   GIMP, Scribus 
and I think CinePaint all support soft proofing. 

> 
> 
> Vendor ICC colour profile can be included by device dedicated PPDs and
> therein configured ICC profiles.
> 
> 
> A "Save to PDF" button with all settings applied would be welcome, but is
> shurely already covered by the requirement.
> 
> 
> kind regards
> Kai-Uwe Behrmann
> 
> > Cross-posting to the OpenICC and Gutenprint mailing list, to get more
> > input from the color experts.
> >
> > Anyone of the color printing/management experts can help Kate?
> >
> >    Till
> >
> > P. S.: OpenICC mailing list info page:
> > http://lists.freedesktop.org/mailman/listinfo/openicc
> >
> > Gutenprint mailing list info page:
> > https://lists.sourceforge.net/lists/listinfo/gimp-print-devel
> >
> > kate price wrote:
> >> I am working on the UI design of the CPD and  looking at the controls
> >> and parameters for colour, both as presets/profiles and as more
> >> detailed controls. Therefore, I'll need to get a good understanding of
> >> how this all works.
> >>
> >> Including:
> >> the workflow from application to printer
> >> colour profiles
> >> color management; in applications, and printer colour management.
> >> what happens where?
> >> detailed user interaction: what controls need to be there?
> >>
> >>
> >> Can someone point me in the right direction? Provide some useful
> >> information or sources of information?
> >>
> >> Thanks in anticipation,
> >>
> >>
> >> Kate
> >>
> >>      man + machine interface works
> 
> _______________________________________________
> openicc mailing list
> openicc at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/openicc
>