Digital BW, The Print

Bruce

I am sorry.  I shouldn't have blown you off so fast.  I also should have added a better 
explanation when I curtly replied to Roy's post by saying:

>So the
> existing QTR profiles should work just fine as long as the pixel values
> don't change, hence Assign-Profile.

This would work if the print space was LAB but it isn't.



Here is a fuller explanation and also, in effect, a summary of the other thread.  To explain 
things more easily, go to this page and download the one page pdf file:

http://homepage.mac.com/stevekale/stevekale2/FileSharing37.html

It saves me having to put a bunch of numbers in this post and also allows you to look at a 
couple of charts which will help.

A RIP like QTR is, in effect, a set of look up tables which tell the printer how much of each 
ink to put down for each possible image file pixel value.  Add the amounts of each ink 
together and you get total ink, and total ink determines the density printed.  QTR works in 
8 bit like many (most?) other printer drivers - although all computations are done in 16 bit 
- and so the possible range of image file values is 0-255.  Roy will correct me if I am 
wrong here but the final part of the calibration process for QTR is a "linearize" function.  
What this function does is to make sure that there is a nice linear progression in LAB's L 
value from dMin to dMax.  Note I said a progression in L and not density.  The density 
curve is not straight but L is.  This reflects the way the eye sees.  (In LAB space L goes 
from 0 (pixel value 0) to 100 (pixel value 255, 8 bit) in a straight line.)

Now look at the table in the pdf sheet.  There are 3 "input" columns.  These just show 
possible input values in 21 (5%) steps:  firstly 8 bit, then LAB and lastly % black.  The next 
column has the densities that the LAB space prescribes for each step of input.  The 
formula to get these figures has been tossed up a couple of times in recent posts so I 
won't repeat it here.  The first I whited out because it is really infinity and I had to plug a 
number to make the chart below the table print sensibly.

Now the output.  3 columns each for two paper types: first EEM and, secondly, a 
hypothetical glossy or semi-gloss paper.  For each paper there is L, density, and the 8 bit 
equivalent of the L figure.  For now just worry about the first two columns for each.

As I said above, I understand QTR is calibrated to get a smooth, straight line progression 
in LAB values from dMax at step 100 to dMin at step 0.  (Note all the figures you see are 
the derived by computing forecast values - I am sure there is some variance in 
implementation.  I used forecast values to avoid this variance clouding the concepts and 
because you can do this exercise without having to buy a densimeter!)   So if we look at 
EEM which with Eboni produces a dMax of around 1.68 and has a paper white or dMin of 
0.04, the progression in L is from 16 (the L value which gives a density of 1.68) to 96 (the 
L value which gives a density of 0.04) in equal steps of 4 L.  The densities associated with 
each step are in the column next to them.  Same process for the hypothetical glossy 
paper.

The chart immediately below the table plots these densities for each input step.  I have 
also overlaid a curve of the reference LAB densities for the same input values.  Remember 
we are using a Same as Source workflow and so the RIP is fed the raw pixel values from the 
file.  For each paper you can read off what density is printed for each pixel value input.  
You can also compare them to LAB.

To clarify my rebuttal to Roy, you can see how the print space for EEM, for example, is not 
the same as LAB (nor could it be - we can't print perfect black, nothing can!).  Almost all 
file pixel values will be rendered lighter than desired.  So even if you have your image on 
screen in LAB (or LAB-grey) and it looks just the way you'd like, it is not going to print like 
that.  

(One other thing to remember.  When you look at the file on screen you aren't looking at 
perfect LAB either - your display can't produce a perfect black!  You are looking at 
colorsync's rendition of the LAB file in your monitor space done according to whether you 
selected Relative Colormetric etc.  Because we print with Same as Source we don't have 
colorsync's help with managing the different shape of the workspace, LAB, to the print 
space as described in the chart.)  

Now for the remaining two columns in the table and the two screen grabs from Photoshop 
at the bottom of the page.  Look at the EEM 8 Bit Equiv column.  All this does is convert 
the EEM L value to its place in the 0-255 8 bit scale.  So 16 becomes 16/100 x 255 = 41.  
In 8 bit LAB space, the value 41 equates to LAB 16 which in turn has a density of 1.68.  
And so on for the other numbers (and the other paper).  Now you can get a sense for the 
"effective" pixel value remapping that the RIP is doing.  I say effective because the file 
values are not changed but you can see that an 8 bit value of 0 is printed at density 1.68 
which is actually  the density that would otherwise be associated with a pixel value of 41 in 
LAB space etc etc.

You can simulate this pixel transformation in Photoshop using the Curves function.  Bring 
up a 21 step wedge (or any other file), make sure it is tagged as LAB (either by converting 
or assigning it doesn't matter for this exercise) and look at it.  Now do a curves layer and 
input the co-ordinates that are listed for EEM - 8 bit input to 8 bit equiv output.  You can 
actually cut to the chase and do just the beginning and end - it is a straight line in the 
middle.  The two screen grabs at the bottom of the page show the "curves" for each paper.  
NOW, with Preview checked you can see how your image will be printed with QTR.  (Just 
don't print it with the curve in place else you will double the transformation!)

Remember this "curve" is buried in the RIP - you can't edit it.  It is also different for each 
paper.  It is also a straight line.  This, coupled with the general shift up in all values and 
hence lightening of most input values (look at the shift in all the midtones), is why we have 
to go back to our image with a soft proof methodology and reinstitute some rebalancing 
or curvature into the transformation.  Typically this is done with an "s curve" over the full 
range of image values (because all are sent to the printer as is).  After doing that, the total 
transformation at work is, obviously, the summation of the RIP curve (depicted in the 
screen grabs) and whatever s curve you applied.

Now for the debate on the other thread.  In essence, I have been arguing that we are better 
off doing the remapping with a curves layer in Photoshop and thereby transforming actual 
pixel values sent to the printer rather than doing the transformation in the RIP.  Why?  Two 
principal reasons:  

Firstly, by doing it in PS we can more easily round out the curve in a manner that balances 
the relative tones in a way that respects the image and our artistic eye - we might ensure 
for example that the mid point  and a bunch of the mid tone range is not moved, thereby 
leaving the coompression in tonal range more concentrated in the shadows and highlights.  
We can achieve the same end result with the current setup and two curves, an S curve and 
the embedded RIP curve, but it is not as easy to see what is really going on and the curve 
that you can edit is only half the story so-to-speak. 

Secondly, and this finally answers your soft proof question, we get to use Photoshop's 
built in Preview. When we have a transformation which alters pixel values the effect is 
rendered on screen for us to see.  Thus by having all of the remapping done to the image 
file (temporarily as a separate layer for printing only!!) in a layer we can see the results of 
our work - real time soft proofing!  

So in my proposed methodology, I would in essence edit the image to my liking on a well-
calibrated monitor (this is reason enough to own a photospectrometer) in a workspace 
that matches my print space.  Apply the "print curve" and check my on-screen perfect 
preview of the image (except for ink hue) and maybe tweak the curve for the specifics of 
the paper/ink tonal compression effects on this image, and then print.  I would make sure 
that the "print curve" is saved as a layer because if I then decide to print to glossy paper I 
don't need to compress the tonal range so much and hence I can use a broader curve.

I hope this helps 

Steve



--- In DigitalBlackandWhiteThePrint@yahoogroups.com, Steve Kale <stevekale@b...> 
wrote:
> 
> 
> 
> > From: bruce greene <bagreene@v...>
> 
>  
> > So am I correct now in assuming that the Linearize function in QTR
> > linearizes to LAB values?
> 
> Bruce I had to laugh when I read this. This thread started as a spur from a
> thread titled "Tonal range and linearization".  Your question is in essence
> the topic of that thread.  QTR "linearizes LAB values".  Whether that means
> linearizes to LAB is a whole different kettle of fish!!
> 
> 
> > So far, so good. My question: How does this approach deal with the
> > reduced density range of a print vs. the monitor w/o softproofing by
> > measured output?
> > IOW, I suspect that one still needs the softproof in addition to the
> > LAB/grey space and Linearized output curve for true WYSIWYG printing.
> > Still the LABgrey space combined with the LAB based Linearization seems
> > to be a great starting point to standardizing the printer behavior. So
> > now I'll have to find a densitometer?
> 
> Read the other thread.... And then come back.
> 
> ;-)