[Printing-architecture] Questions, Concern, Disscusion on CPD

[Hal V. Engel]

On Monday 13 July 2009 06:25:45 am Petrie, Glen wrote:
> I am not going to argue with you; you simply missed the point.

I don't think I missed the point.  Perhaps I didn't communicate my points 
effectively and if so I apologize.  Let me try again.  

In a round about way Glen asked how media characteristics and color management 
were related and if color management was (or could be) used to tailor how 
colorants were applied to the media based on media characteristics.  

Referring how "color-to-ink processing" could/should be tailored to a specific 
media Glen wrote: 

"Note, I have not seen this kind of processing done in color-management 
processing software." 

I pointed out that this is in fact exactly what color management of printers 
does and is designed to do.  And that using profiles and color management was 
very specific about tailoring the colorant output to the media characteristics 
(including the specific device and the device settings) since it did this 
based on detailed media/device/device settings specific measurements.  How 
could it possibly be more tailored then that?

Looking at the CUPS PPD extension documentation about the cupsICCProfile 
keyword CUPS uses various bits of information including the media type and 
resolution to select which output profile to use for a particular print job.  
Unfortunately CUPS restricts this to three values that are used for this 
selection process which is probably too restrictive to be as flexible as we 
would like in actual practice.  But the current CUPS design, with in these 
limits, does exactly the thing that Glen has "not seen done in color-
management processing software" by selecting different profiles, which means 
different "color-to-ink processing", based on printer queue, color model, 
media type and resolution settings.  To be clear my point is that using the 
existing CUPS design users can set up color management in CUPS (once color 
management aware *toraster filters are available) to do exactly the type of 
processing Glen was talking about.  CUPS, in fact, does this on OS/X systems 
using the OS/X proprietary color management aware *toraster filters and has 
for a long time so we know it can work. 

I also tried to point out some incorrect assumptions and terminology.  I did 
this to try to clarify the subject since fuzzy terminology and incorrect 
assumptions make for bad design.   I did not intend to be confrontational and 
if I appeared to be let me apologize.    

The incorrect assumptions and fuzzy terminology include:

1. Users could "easily find" paper "brightness" and "color" (media white 
point?) "information on the cover of the media".  This is at best true in only 
a limited number of cases and then only for "brightness" information.   I have 
never seen a paper package or product sheet with  "color" information of any 
kind. 

In fairness to Genn, unlike most paper manufacturers, Epson papers do have 
published ISO brightness specifications so I think the disagreement here is 
over how common this is and how useful this information is.

2. There is an apparent assumption that this information is colorimetricaly 
meaningful.  Some papers come with a stated brightness number but I have 
measured some of these papers with a spectrophotometer and the stated 
"brightness" does not appear to correspond to the measured colorimentric 
values.  The stated "brightness" is usually significantly higher than the 
measured L* value probably because of FWA enhancers. I found a research paper 
about this on-line and these "brightness" values are in fact not colorimentric 
and in it's Conclusion section it stated:

"Brightness is not a parameter related to color of substrate; actually it is 
not even connected to its appearance. It is a number related to the color of 
substrate viewed under a blue stained glass. Brightness is related to 
reflectance values in a narrow region of the total visible spectra around 460 
nm. Due to this limitation, values of brightness cannot be connected or 
correlated to (white) appearance of pulp or manufactured paper, not even in 
those cases where no FWAs are applied."*  

* See www.axiphos.com/BrightnessReview.pdf

So these "brightness" numbers are in fact a measurement of the blue spectrum 
(457 nm +- 44nm) reflectivity of the paper plus blue region florescence caused 
by UV interaction with the FWA.

3. The assumption that the "brightness" and "color" information for these 
media is of some use to the driver.  

Even if colorimentricly meaningful white point and brightness information was 
available on the media box or product specification sheet how would this be 
used in a non-color managed work flow?   

Would there be a place for users to enter this information so the driver would 
know about it?  

Are there any existing drivers that make use of this information on any 
platform?  

How would the driver use this information since it does not have access to 
characterization data about how it's colorants interact with the media unless 
there is an ICC profile available?   IE. unless detailed measurements had been 
done.

If there is an ICC profile the media white point and "brightness" information 
is already part of the profile and there is no reason for users to get this 
information from the box even if this were available. 

4. Use of the term "color" when Glen probably should have used a term like 
"media white point" or "white point".  For color people the term color is not 
very useful or even meaningful but white point has a very specific meaning.  
Using the term color is like calling something a printer.  It tells us that 
the device is a printer but it does not tell us anything specific about the 
device where as calling something an Epson R2400 tells us a lot about the 
device.

The problem Glen was describing in item E: is exactly the problem that color 
management was designed to solve.  Why not use a tool set that is designed to 
solve that problem rather than reinventing the wheel if the existing tool set 
is not badly broken?  Admittedly there are currently issues with how this is 
handled by CUPS on non-OS/X systems because of the lack of open source CM 
aware *toraster filters.  But this issue is being worked on and will 
eventually be resolved.  

Hal

>
> > -----Original Message-----
> > From: printing-architecture-bounces at lists.linux-foundation.org
> > [mailto:printing-architecture-bounces at lists.linux-foundation.org] On
> > Behalf Of Hal V. Engel
> > Sent: Friday, July 10, 2009 4:01 PM
> > To: printing-architecture at lists.linux-foundation.org
> > Subject: Re: [Printing-architecture] Questions, Concern, Disscusion on
>
> CPD
>
> > On Thursday 09 July 2009 09:39:14 am Petrie, Glen wrote:
> > >  E: Another "option" to consider for this section is an advanced
>
> button.
>
> > > The key to printing a specific print-quality (actually, better
>
> stated as
>
> > > a specific print-intent) is to know more about the media being
>
> printed
>
> > > to.   That is, for example using paper; what is brightness, the
>
> weight,
>
> > > the finish (rough, smooth, polished), color, etc.  From these facts,
>
> the
>
> > > printer driver can tune its color-to-ink processing and other
>
> factors to
>
> > > achieve the best output for the user print intent.  Typically, a
>
> user
>
> > > can easily find this information on the cover of the media being
>
> used in
>
> > > the printer.  Note, I have not seen this kind of processing done in
> > > color-management processing software.
> >
> > You are incorrect.  This is exactly what should happen in a proper
>
> color
>
> > managed work flow and this is exactly what color management is for.
> > Proper
> > profiles are media (as well as device and device settings) specific.
>
> They
>
> > are
> > created by measuring the media white point (you called this color) and
> > brightness (these are actually the same thing) as well as the
>
> resulting
>
> > absolute (meaning CIE XYZ or CIE L*a*b*) colors/tones of various
>
> amounts
>
> > and
> > combinations of inks/colorants on that media (we usually measure 1,000
>
> to
>
> > 3,000 color patches when creating a printer profile).
> >
> > The correct use of a printer ICC profile should optimize how the
> > inks/colorants are put down on the paper to match the paper white
>
> point to
>
> > the
> > grays/blacks created by the inks/colorants (I have assumed relative
> > colorimentric intent) as well as to optimize the gamut/dynamic range
>
> of
>
> > the
> > resulting prints without over inking.
> >
> > I am not sure if I have ever seen a paper package that had the media
>
> white
>
> > point listed at least not in a form that would have colorimetric
>
> meaning.
>
> > Although these may exist I have NEVER seen a printer driver that had
>
> the
>
> > ability to accept this data (paper white point) as user input other
>
> than
>
> > by
> > using an ICC profile.  I just looked at the box and the product sheet
>
> from
>
> > the
> > box of the Ilford paper that I use and it did NOT list the paper white
> > point
> > or brightness of the paper.  If it did I would expect to find
>
> something
>
> > like:
> >
> > White point: XYZ: 84.550000 88.240000 74.960000, D50 Lab: 95.261904 -
> > 0.999796
> > -1.888369
> >
> > (The above is the measured white point of a sample of Ilford Galerie
> > Smooth
> > Gloss paper - note the first Lab value is also the "brightness" -
>
> actually
>
> > Luminosity - of the paper).
> >
> > Isn't the media type setting what is used to denote the general
> > characteristics of the media such as finish and weight....
> >
> > Hal
> > _______________________________________________
> > Printing-architecture mailing list
> > Printing-architecture at lists.linux-foundation.org
>
> https://lists.linux-foundation.org/mailman/listinfo/printing-architectur
> e

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux-foundation.org/pipermail/printing-architecture/attachments/20090713/e53a8cef/attachment.htm