Digital BW, The Print

> > > I guess you weren't one the 16-bit only users.  Well 15 bits is
> > > way overkill
> > > anyway
> >
> > Well, that depends on what PS removes!  If the file is high bit
> justified,
> > and it removes the low bit, that's OK.  If it's high bit
> justified and it
> > removes the high bit, that's bad.  And converse for low bit
> justification.
>
> Photoshop is in its 7th version, its Adobe's flagship product,
> thousands of
> people use and make there living using it, so let me ask you:
> What do you think PS does??  The right thing or the wrong thing??

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

> > > > What did you think of the above paragraph?
> > >
> > > I not really sure I understand what's really being said or
> asked, but I'll
> > > try.   It you start out with an 8 bit grayscale you have 256 possible
> > > values.  When you convert to RGB you still have only 256 values,
> >
> > How's that?
>
> Well each of the 256 possible gray values converts into a particular
> combination of R,G,and B values.  Every time a certain gray value comes
> along it'll convert to the same RGB combo.  So there's still only going
> to be 256 RGB combinations actually present.  This is also true after
> applying curves -- again each of the 256 RGB combos will convert into
> a new combo but there can only be 256.

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?

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

> > > The 4 inks are a big help in making the averaging
> > > work better i.e. on a smaller area.
> > >
> > > I can't make sense of either:
> > > "you can't print all the way to %100 with three of the inks"
> >
> > It's simple.  If one ink is %100 black,  next is %75, next is
> %50, next is
> > %25, then you simply can't get the full range of tones from any
> of the inks
> > but the %100 ink.
>
> Ok, I see what your saying. Actually you don't use any individual
> ink for the
> full range.

I never said that you do.  I said that the only ink that is CAPABLE of
producing the full range is the %100 ink.

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

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

> The Piezo software does the same thing, but of course its "canned" and
> we can't see the details.  Jon Cone likes to call it magic but its really
> quite simple in concept.  I think he feels that keeping a little mystery
> helps maintain the "value" of his system.

Yes, I agree.

> >
> > I believe the tones you get from the other inks are merely duplicate
> > tones...but because you can now intermix the four inks, your dither can
> > occupy a smaller area.  I don't believe it gives you more tones, simply
>
> 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
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 ;-)

> > smaller area...now you could increase the area used now, and that would
> > increase the number of tones.  I'd have to think about this a bit.
> > Certainly multiple graytone ink printing is a new thing to me,
> which is why
> > I'm trying to understand it a bit more.  I don't believe it's
> as "obvious"
> > how it works as some people think it is.
>
> Well like many things, when you don't understand it its mysterious and
> complicated, but once you figure it out its easy and maybe even obvious.

Yeah, but I still don't believe it prints "more than 1000" tones ;-)

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

Regards,

Austin