Digital BW, The Print

----- Original Message ----- 
From: "Roy Harrington" <roy@...>
To: <DigitalBlackandWhiteThePrint@yahoogroups.com>
Sent: Saturday, November 29, 2003 7:47 PM
Subject: Re: [Digital BW] 16 bit printing


> --- 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

Some months ago I asked Mike Chaney (Qimage fame) some
information on that subject and got the following answers:

> On the colorsync list the question is asked whether the Epson
> driver itself accepts 8 or 16 bit files. Internally it will
work
> in 16 bit (or higher) calculations somewhere like the
Gimp-print
> driver does. I wonder whether the output to the driver of
> PhotoShop itself isn't limited to 8 bit, printing with PS
> Elements with the same settings delivers the same quality while
> it is only 8 bits. Does Qimage deliver 16 bit to the driver and
> have you any idea whether the Epson driver keeps it at that
level
> throughout the calculations till it drops to the 8 bit level
data
> for the printer ?

It is impossible to pass 48 bit image data (16 bits/channel) to
*any*
Windows print driver.  The Windows API commands that all printing
software uses to send data to the driver are all based in 24 bit
(8
bit/channel).  Since Windows itself does not provide a means to
pass
anything but 24 bit images to the driver, all software must use
the 24 bit
methods.  If the Epson driver does anything in 48 bit mode, it is
doing it
after it receives the initial image in 24 bits.

Mike


> That tells a lot. So if there are drivers that have 48 bit
input
> they have to bypass the API side of things. I have the Wasatch
> SoftRip too and it tries to stay away from much Windows
> interference but I haven't found a way of 48 bit input in that
> RIP either so there the bottleneck is at the frontside at
least.
> Whether it actually is a bottleneck is another matter.
>
> Wonder what Macs do in the process.
>
> Any objection that I quote your reply in the colorsync list ?

No objection at all.  As far as I know, all Windows print drivers
are
designed to accept data "the Windows way" via 24 bit "bitmaps" so
even if
you had a third party RIP that could somehow do 48 bit, it is
unlikely that
you'd be able to send data to it at 48 bit anyway unless you had
a special
plugin that knew how that particular driver supported 48 bit.
The bottom
line is that you'll never get 48 bit data to a printer using the
Windows
standard "File", "Print" command in any software because "File",
"Print"
uses the Windows standard of 24 bit.

I'm only telling you this because manufacturers could probably
figure out
a way to send 48 bit data through the normal Windows API print
driver
calls (such as sending two 24 bit images that overlay) but to do
that, you'd
have to have software that also used the same [clever] method of
getting
48 bits to the driver which still amounts to specialized printing
software to
get the job done.

Mike

(end of quotes)

Ernst