Digital BW, The Print

> From: Paul Roark <paul.roark@...>

> 
> From Steve:
> 
>> It's not "compressed".
> 
> A Lab L* separation of 3.4 is clearly "compressed" relative to 8.2 in the
> way I use the language.
> 
>> It was closer to begin with.
> 
> No, the original file values were the same.  It was the same file.
> 
>> By saying it is
>> compressed you suggest that something in the printing narrowed the gap.
> 
> When I was comparing the difference between a color-managed and non-color
> managed workflow, that is true.
> 
>> What really happened is that when you assigned GG2.2 to the step wedge you
>> gave new definition to the 90 step.
> 
> I don't think we are disagreeing here.  It's just language.  When I used the
> ICC in the "Print with Preview," it utilized the GG2.2 definition of the
> file value.  When I used "No Color Management" it did not utilize the GG2.2
> definition.  The decision to use or not use the ICC/color managed approach
> was in the printing workflow.

Well yes but it's a bit misleading. Note that when you changed your
workspace the look of the (same) image changed on screen.  It's not really
the same image when you have colour management because the file is
interpreted together with its profile.  (Colour management is always
operating in what you see on display.)  The scale is not compressed.  You
simply jump to different observation points.  The confusion generated by
this is one argument for using QTR-Grey Lab as a workspace.  90K is 10 L*,
95K is 5 L* and 100K is 0 L*  -  and so the L* "fits" the steps and it's
easy to relate the step to the L*.  For an image tagged with GG2.2 the
colour associated with 90K is a much darker shade of grey - it has an L* of
6 (rather than 10).  So it will not only look darker on screen but will and
should print darker than 90K/GG1.8 (L*13) and 90K/GL (L*10).  The sense of
"compression" merely results from a choice of an observation point/number
without regard for its meaning.

In other words there is no magic in 90K or any other %K. 90K means no colour
in and of itself.  It is not relative to any colour space.  It's a pixel
value (8 bit 'inverted' and rebased to a scale of 0-100).  Only when we
ascribe a colour space to it does it have a colour.
> 
> On the other hand, what workspace is used is made before the file is
> printed, and this will affect how the image is printed in a color managed
> workflow.

Again this last statement is wrong.  With a colour managed workflow, it does
not matter in which workspace you edited the image to its final stage  -
whether you began in GG1.8, DG20 or GG2.2.  When you print it, a conversion
takes place such that the file values are altered for appropriate rendition
in the print - the print WON'T be affected by your choice of workspace.
This is a major benefit of the CM approach.  If, however, you did not use
colour management when printing then the workspace you used WILL affect the
print.  This is because the file values are sent as is and in each case for
each shade of grey those file values will be different in each file and
therefore print differently.