Digital BW, The Print

snip:
=What we've done lately for soft proofing is just simulating the "look" of a
print in RGB that
=you can see on a calibrated monitor.  It has no knowledge, notion or
=whatever of how the ink got onto the paper.  In a sense that's the beauty
=of it -- you can simulate the look of any method of printing.

Ok I guess I am not fully understanding this.  Your ICC profile maps the
image from Gray Gamma 2.2 into the gray space of the particular QTR setup
and then visually displays the results of this mapping on the screen (when
soft proofing).  When doing the proofing (and forgive me if this is in the
stuff I have not had the chance to look at yet) which space are you in?
Still Gray Gamma 2.2? Or does the doc have to be converted to RGB?

In order to create this ICC profile you have determined how a known set of
inputs get rendered by the particular QTR setup.  (The full gray spectrum is
presumably derived from an interpolation of these measured points.)  The
soft proofing feature of PS uses this mapping and an understanding of the
profiled monitor¹s display characteristics to visually represent the final
output.

=ICC printing is a whole different thing.  An ICC profile can't do an
arbitrary
=mapping to N inks because the output has to feed into an RGB Epson driver.

In my layman¹s view of QTR ­ and I am stating this so that you can correct
this if I am way off base ­ is that it does two things.  Firstly it takes
control of the individual print heads and defines how they are used to drive
a gray scale spectrum (rather than using the Epson formula for determining a
gray scale).  BTW, can you help me understand linearization a bit better?
Specifically I think I understand what¹s going on with the ink limits and
you have indicated that there is a mathematical function that then smoothes
these choices.  What is it that linearization adds over and above this
mathematical smoothing?

Secondly it takes each pixel value coming in and determines where on the ink
curve it sits, ie how pixel x should be rendered.  Presumably this is a very
straightforward mapping.  The problem has been that there is no consistency
between how a screen renders the individual gray pixel values and how QTR
renders them.  Isn¹t this the conventional colour matching problem?  (Albeit
in a simpler space.)  The more I think about this I find myself thinking in
circles.  I guess if I can soft proof why fuss with the backend. But then I
can¹t see how this differs from the conventional colour problem which
requires a profile to soft proof and the use of the same profile for
conversion at print.  Why don¹t we tag the file going to print with this
mapping function, either letting PS or QTR do the mapping, a la the two
different methods for colour printing?

The reason why I am asking about linearization is because this is the point
where we first measure a step wedge.  Adopting this new soft proofing we do
so twice.  Once for linearization and then secondly for a soft proof
profile.  In the colour analogy (and I think of B&W as simply a very very
narrow colour space) I would do so once only and this would then be used for
both soft proofing and to define how colour or shade of gray x is mapped for
the printer so that WYSIWYG.

I don¹t see the Epson or any other driver that differently.  Somehow it has
a formula for driving the print heads to produce ³colour² x.  But pixel
value x may correspond to a different shade of gray by the printer than what
is displayed on screen and so we use an ICC profile to shift these so that x
on screen is the same as x on paper.  This mapping can either be done by the
driver or by PS before getting to the driver.

So, I guess I am wondering if an ICC profile constructed as you have done
can be used to simplify the front end curve design process by using it to
first map things to the display space for soft proofing and then mapping
things into the QTR space....perhaps an unlinearized one.

Sorry for the ramble but just trying to understand this better.....

Steve




[Non-text portions of this message have been removed]