Digital BW, The Print

Hi Austin,
 
> Hi Roy,
> 
> I know HDR files are low bit justified...and what you want to do with them
> is set the setpoints, and expand the range over the entire 16 bits before
> doing tonal manipulations...so in this case, clipping either bit doesn't
> work, unless when you expand it, you only expand it to the 15th bit...  Is
> that what it does, lop off the high bit?

You sure worry about the darnedest things.  I haven't any internal knowledge
of PS, I'm a user and just using it I can see that only 2^15 or 32768
levels of gray exist.  Why, how, where this is done, I can only speculate.
But I've written enough code to see the large performance benefit
from just using 15 bits.  Its clear and obvious to me, certainly it might
not be obvious to someone else.  If I was writing the code I'd make
the same recommendation.

> 
> > You don't really think PS is written in assembly language, do you?
> 
> Perhaps some routines are, but obviously, duh, Roy, the whole thing isn't.
> But that was not the point.  EVERYTHING that runs on a CPU is in machine
> language...of which the assembler is merely a mnemonic for.
> 
> > It's almost surely written in C.  Neither C nor any other high
> > level language
> > has direct access to CPU flags.
> 
> Actually, that is not true.  Any good C compiler will take advantage of
> things like that when they can.
> 
> > I've designed and written hundreds of
> > thousands of line of code, in lots of assembly languages and in C.  So
> > I know its much harder and slower using all 16 bits.
> 
> I disagree, and I've also written hundreds of thousands of lines of code.
> People can write good code, people can write bad code...people can
> intentionally write very good code.

I can't imagine what code you've written.  Have you ever used a
high level language?  What C construct are you going to use to
test the carry bit out of the last arithmetic add?  Write me the code.
If you prefer a different high level lang, use that.

> 
> 
> There are four inks.  The inks are CMYK, not RGB.  Why on earth would you
> convert grayscale to RGB for a four ink system?  Are you saying that's what
> the Rourke curves do?

Well the Epson drivers take RGB input.  You have to give it what it wants.

> 
> BTW, in PS, when reading the grayscale file in RGB, all three values R, G
> and B are the same as the grayscale value...

Yes, that's why there's only 256 possibilities.

> 
> > The idea is "partitioned" use of the inks.  There is actually
> > lots of overlap, but conceptually think of it like this:  The
> > darkest 25%
> > (100% to 75%) of the tones are all done by the 100% black ink.
> > The next 25%  (75% to 50%) is done by the 75% black ink, the next 25%
> > (50% to 25%) is done by the 50% black ink, and finally the lightest 25%
> > (25% to 0%) is done by the lightest 25% black ink.
> 
> I understand that is one way of doing it, I hadn't said otherwise.

Do you understand how it works and why it is so much better?

> 
> > The overlap and
> > smooth joining of the partitions is tricky -- this is where Paul Roark
> > has spent many, many hours designing curves to create this partitioning.
> 
> I would believe that.  I've never done any design work using quadtone inks,
> so this (thinking about dithering with quadtone inks) is all new to me.

If its new to you, how can you make such assured claims as:
      I still don't believe it prints "more than 1000" tones.

The quad inks give an exponentially better system.  Its huge.
First the 4 inks in any combo of overprint give a 2^4 multplier.
Plus it can be done in a much smaller area.  Droplet sizes multiply again.
Easily dozens or maybe a 100 times better.  Then didn't I calculate
576 pixels under the densitometer?  That's another 500 multiplier.

I'm actually beginning to think the 1000 might be so easy to do that
its not even a big deal.

> >
> > Have you ever seen the book, "Real World Scanning and Halftones" by
> > Blatner, Fleishman, and Roth?  I've found it to be very informative.
> > It doesn't go into this quadtone stuff but its a real good basis for
> > how to think about printing gray scale using halftones or dithering.
> 
> Yes, I have the book.  The halftone section is very basic, and nothing more

How about the stochastic screening.

> than a primer on the concept.  As I've been designing halftone algorithms
> for longer than the book has been out...for me, there are better books on
> theory than this book.  If you want very in-depth theory of standard
> halftone/dither methods, and perhaps the bible amongst people who design
> dithering algorithms, "Digital Halftoning" by Robert Ulichney, and another
> purely theory book, "Digital Color Halftoning" by Henry R. Kang.  Both are
> quite boring.  For a read, the book you mention is far better ;-)

One of the better tech books I've ever read.

> >
> > I was thinking of creating some of those step wedge and gradient files
> > that have been talked about -- and some others that may be useful.
> > I'm not running piezo lately and don't have access to a densitometer
> > more sensitive than 0.01D density units.  Would you be interested and
> > able to print some of these out and measure them?  I think it would
> > be useful information.
> 
> Of course.  You can simply email the files to me, and I'll be more than
> happy to print them out for you.

But can you get use of a densitometer better than 0.01D ?

> 
> Regards,
> 
> Austin

Roy