Digital BW, The Print

Hi Oliver

Here's my attempt to answer your questions.  I understand where you are
coming from and hope this helps somewhat.

> From: odesmais <odesmais@...>

> 
> Steve,
> 
> You have been of great help in your below reply and I am very
> thankful for it. Please allow me to try to further understand the
> subject since I am still confused...sorry.
> 
> In B&W you do not face the color value conversion, you just re-map
> the L* value from L* 0-100 to a printer-paper-ink space say L*17-95.

If all you do is send a file Same as Source then yes file pixel value=0 gets
printed as L*17 and file pixel value=255 gets printed as L*95.  If the
greyscale has been linearised then there is a straight line, in terms of L*,
for points in between.  So a middle grey value of PV=118 gets printed at
around L*56 (instead of L* 50).  This direct mapping into a linear L* space
where the black isn't great is why prints can look a lot lighter than on
screen (you can work out for yourself where the cross-over point is between
the image printing lighter than intended and the highlight point from which
it is printed darker than intended).  Not also that it has a different slope
and hence completely different "contrast" or "gamma".  It has a lower gamma.

The question then becomes "given the print space is different from my file
space how best can I manage the compression/mapping from one to the other?".

In the past we did this with an arbitrary s curve to punch a little more
contrast into the image.  We, in effect, compressed the shadows and
highlights a little so the midtones had more contrast - this is inherent in
the shape of the curve: a stretched "s".

A long time ago Roy and I had a lengthy debate about this.  I was in effect,
on the one hand, explaining that this was why QTR prints came out looking a
little "flat" and "light" and, on the other hand, complaining that this
mapping was not explicit to the user.  We agreed as to what was going on and
Roy made what I think is a quantum leap in terms of managing the
compression/mapping by turning to colour management techniques and using
Adobe's CMM (colour management module).

The issue exists in the colour world of course and nicely linear (or not so
linear) devices are then handled by the CMM with either Perceptual, Relcol,
AbCol or Sat intents.  We profile these devices and then use the CMM to
manage the compression from one space to another.  For B&W, Roy's idea was
to try to use the Perceptual intent to handle the luminance range
compression (the L* axis) and not worry about the a and b axes because that
then required stepping into the colour management world fully which is a
step beyond us for nor as it requires tight control over gamut and requires
a driver that thinks in colour terms.  Remember that QTR is essentially
colour blind.  Your "greyscale" could be made up of just magenta ink and yet
QTR doesn't care.  We linearize the luminance axis and just do a/b by eye
(or with indirect help from a spectrophotometer).

 
> But this is done at the curve creation stage and at the printing one
> when you call for the curve in QTR :
 
You create the greyscale at this point and without colour management you
simply map one for one to this printer output "space".  In the colour world
this is analogous to having a nicely linear printer but not profiling the
printer output space and not using colour management to control the mapping
from, say, Adobe RGB to the printer gamut space.

>doesn't this curve apply what we
> can extrapolate as an icm profile (to make it simple in the wording).
> So to convert your file with the grey icm and send the converted file
> to QTR applying the linearized curve should somehow either :
> 
> 1. double profile : a source L*50 would become L*56 (with a 17-95
> linearized grayscale) converting the file with the icm. And once the
> QTR curve applies it would to re-processed to become about L*61. It
> would be like printing with a destination profile in PS and having
> the EOM driver applying color managment.
> This of course can not be.
> 

Nope.  The CMM looks at the printer space and adjusts file values according
to the intent selected.  You are much more likely to have your midpoint
printed closer to L* 50.  If Roy was not doing the BPC in the profile and
you did not ask PS to do it then file blacks exceeding the best black of the
printer would get clipped.  (Note as I have explained before Roy is doing
the BPC in the ICC profile and so this can't happen but the downside is you
can't softproof for the printer black.  He is still looking at this.)

Think colour for a second.  Epson linearized the printer for us but we still
PROFILE the printer with an ICC profile and use colour management to manage
the movement from our workspace to the printer output space.  Same here with
just one change - we are only bothering to focus on luminance/density (or in
other words, we only care about/mange one axis rather than 3).


> 2. have no effect on the output: the file is well converted but the
> icm interpret the source L50 to a L50 output (only the display values
> but not the output values are converted thus allowing soft proofing)
> and send it to QTR as such that will do the conversion with the curve.

I can't find the tests I did to give the numbers but you should print a 21
step with Same as Source and then using the ICC profile and note the
difference.  You should, I believe, see that the second gives an "s curve
like" fit rather than a straight line. In essence, and Roy can give more
detail to the maths behind this, the image file values are scaled for two
things the lower white point and the weaker black point according to their
XYZ_Y values.
> 
> So in terms of purely improving the output, the grey icc is not a
> must. It is only great help in terms of editing your file in PS so
> you get a perfect match between displayed image and printed one with
> from my understanding the limitation of BP (which I understood is not
> the true paper Black but a perfect one).

No.  First you don't HAVE to use it and you can do things the old "Same as
Source" way and get the 1:1 straight line mapping of L*.  I would argue this
is a loss.

If you do choose to use it then you have access to a tool which nicely and
easily (ie automatically) scales all the image pixel values for the output
space's black and white points and any blips in between.  This I think is a
major step forward.  We can profile the luminance of the greyscale produced
by any workflow (QTR, IJC/OPM, BO, Roark or whatever) and use CM to manage
the mapping.

The one pity with the current beta is in the soft proof department.  As I
have said, because Roy is doing the BPC (ie scaling of image values for the
weaker printer black point) for you/Adobe in the ICC profile, when you ask
PS to do BPC in the softproof it looks at the ICC profile and sees that the
printer can print perfect black and hence does not adjust the on screen look
of the image for the weaker black.  This is something that Roy continues to
look at.  My personal view, and remember this stuff is difficult because no
matter how many questions you ask of a colour engineer about this stuff it
is hard to get straight clear answers to the very simplified B&W case - they
are simply not used to thinking in B&W, is that the ICC profile should show
the weaker black point in the kTRC and not have the kTRC scaled to run to
perfect black (ie have embedded BPC).  I might well be wrong though!!  If
this were the case then I think when you do a soft proof and check BPC then
PS will see the imperfect black in the profile and adjust the display
accordingly.  But like I said I could be completely wrong and only a test
will tell.  It's a pity we just can't get a straight simple answer to what
would seem to be a very simple question.

I hope this helps and I am sure Roy will step in if I am off-base.

:-)

Steve