Digital BW, The Print

--- In DigitalBlackandWhiteThePrint@yahoogroups.com, "Ernst Dinkla" 
<E.Dinkla@c...> wrote:
> Where are actually the bottlenecks of a 16 bit workflow ?
> 
> True 16 bit scanning is possible on some scanners meanwhile, the
> difference with the ones that do a 14 bit A/D conversion will be
> hardly noticeable.
> Bitmap editors like PWP and PS now allow full 16 bit editing.
> At the end of the workflow the printer engine itself will be only
> available as 8 bit, if it actually produces 255 steps per colour
> on the paper we will already be very happy and probably we will
> never notice it when it produces only 230 steps or less. Are
> there 16 bit printengines ? Lightjets etc ? That it will only
> show in transparencies is another matter.
> 
> What is more of a question is what printer drivers actually do.
> The printer drivers usually work with a 16 bit conversion table
> internally to get better rounding off. That is always used
> whether it is getting 8 bit or 16 bit channel data as its source.
> Windows reduces all printerdriver output data to 8 bit when it
> uses the Windows spooling. There are ways to overcome that but
> when the printerengines don't take higher than 8 either it has no
> sense. Gimp-print used 16 bit conversion tables but I really do
> not know how much 16 bit it is throughout now, no 8 bit filter at
> the input ?, no 8 bit filter at the output?  Same questions for
> OS X. I also wonder whether the Epson drivers normally filter the
> input to 8 bit and only use 16 bit conversion tables internally
> to drop to 8 bit as soon as possible again. Speed is a factor in
> all that.
> 
> Roy must know the Gimp-print details .............
> 
> Ernst


It was interesting to read that Paul has seen real print evidence
of 8 bit versus 16 bit in the curves.  Gimp-print and I'd bet all
the Epson drivers use 16 bit internally.  In the realm where the
numbers represent "human" perceived values, 8 bit or 256 values
is plenty for all practical purposes.  But once you get into the
driver the values eventually have to represent quantities of ink
on the paper.  So while the ratio between 10%K and 100%K
in our PS files is a factor of 10x, when you get to ink on the page
this could easily be a factor of 1000x in ink volume, which is
why 16 bits are needed.  All the QuadToneRIP and Gimp-print
code starts with 8 bit from the image data files, converts to
16 bit first and then all curves, dithering, etc. stays with 16 bit.
(BTW, this is analogous to the need for 16 bit in scanning where
the raw values represent light energy values).

What Paul does with RGB separation curves is very much like
part of the driver conversion to ink volumes.  So it not too
surprising that he can get some improvement using 16bit.  I
don't know if the Windows print spooler chops down to 8bit
and if it does whether it does it "intellegently" like PS does.
(Maybe PS chops before sending?).   I haven't found a way so
far to get 16 bits throught the OS X printing system either.

Roy