Digital BW, The Print

--- In DigitalBlackandWhiteThePrint@yahoogroups.com, "Antonis 
Ricos" <antonisphoto@y...> wrote:
> Paul,
> 
> everything you say regarding the effect of the high bits on the 
actual image 
> are undisputable, and certainly something that all bw 
printmakers should be 
> aware of  (much more so than color where you can hide 
behind 3x or 4x the 
> digital information). 
> 
> The thing with OPM is that it was built  on (or came from) a 
16bit engine,  with 
> 8bit support only added very recently. Any decent driver needs 
to work in 16 
> bits internally anyway to avoid quantization errors. However, 
there may be 
> weaknesses in the 8-to16 bit internal conversion with OPM, 
that make it a 
> "safer bet" to give it a 16 bit file.  The latter bypasses an extra 
step in the driver 
> and takes out some variables (that only Joe would know to tell 
you about).

8 bit  to 16 bit conversion is so straightforward it's hard to
imagine why it would be better to do it before sending data to
OPM.   The only possibility I can think of is doing some of
the processing in 8 bit before converting to 16.  The conversion
should be the very first thing that happens in the driver.
(At least that's what I do in my code).

Roy

> 
> I personally haven't seen a good reason to bumb up the file to 
16 bits or to 
> even hit 720 dpi unless the initial res is too close to 360 or the 
file has a lot of 
> sharp diagonals etc. But if I ran into any questionable output, 
those would be 
> the first things I would try.
> 
> In short, I just wanted to point out that the issue of 8 vs 16bits 
in this scase is 
> solely for the purpose of helping out the driver and has nothing 
to do with our 
> usual concerns of preserving the gray steps in a monochrome 
image file.
> 
> Antonis
> 
> 
> 
> 
> 
> 
> 
> --- In DigitalBlackandWhiteThePrint@yahoogroups.com, "Paul 
Roark" 
> <paul.roark@v...> wrote:
> > 
> > >... at Bowhaus (the guy behind OPM/IJC) he
> > >would work on the photo in 8-bit, and only convert it back
> > >into 16-bit for the actual printing. ...
> > 
> > This must be the reflection of a strange driver/RIP.  It makes 
no sense to
> > me otherwise.
> > 
> > Once you convert to 8 bit you've lost the additional 
information/grayscale
> > steps 16 bit can hold.  Conversion back to 16 bits from 8 bits 
does not
> > restore those lost steps; it does not add information.  You 
have the same
> > number of grayscale steps you had in the 8 bit image, but 
with a file that
> > is twice as big.  Why would one do this?
> > 
> > I agree that 8 bits is all that is needed for a fine B&W print, 
but it is in
> > the manipulation stage where there is a major loss of 
information.  When 
> you
> > apply curves, etc., you lose grayscale steps.  The purpose for 
keeping the
> > file in 16 bit as long as possible is usually to have enough 
extra
> > steps/information so that when you're done you have at least 
close to the
> > 256 gray levels that 8 bits can hold.
> > 
> > If you drop much below 256 levels, the quality of the image 
may suffer.
> > Take a look at a print of the 100-step test file.  You can clearly 
see those
> > steps.  That means that 100 levels is not sufficient for a very 
fine grain,
> > clear sky.  (Grain will help to mask this problem if it surfaces 
-- but that
> > is not a very attractive remedy.)
> > 
> > Paul
> > http://www.PaulRoark.com