Digital BW, The Print

Hi Austin,

--- In DigitalBlackandWhiteThePrint@y..., "Austin Franklin" <darkroom@i...> wrote:
> Hi Roy,
> 
> > 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??

> 
> > Computers in general use signed arithmetic so a 16 bit number actually
> > goes from -2^15 to +2^15-1  or -32768 to 32767.   I suspect that they
> > just use the positive numbers.
> 
> 16 bits IS 16 bits.  What it represents is entirely different though.  There
> is hardware (specifically in the ALU) that can set flags and do arithmetic
> based on signed numbers as well as unsigned numbers...and obviously software
> does what it does, but because a number is 16 bits, that does not mean it
> has to be treated as a signed number.
> 
> > It would also have a very significant
> > performance benefit --- like 20% faster or even more.   Why?  With
> > every single operation on a pixel value you need to check for overflow
> > or underflow of the value.  Using just 15 bits means that the top bit
> > should always be 0, overflow or underflow would be characterized by
> > the top bit being a 1.
> 
> CPUs have overflow flags (as does the x86 architecture)...and a bit (not
> part of the 16 bits) gets set when the result of an arithmetic operation
> creates an overflow condition.  This bit can be tested in a single assembly
> instruction and cause a branch.
> 
> > This is very easy and FAST to check.  In order
> > to do 16 bit unsigned arithmetic, one would actually have to perform
> > every operation in 32 bit mode so the over/under flow info wouldn't
> > be lost.
> 
> Using the overflow is equally as fast, if not even faster...as I don't have
> my x86 instruction cycle book handy, just from the CPUs I've designed, it
> should take less cycles to check and branch on a flag, then it should to
> check the high bit and branch from it.
> 
> I believe the x86 has a JO and JNO instruction, jump on overflow, and jump
> if no overflow...I believe there is also a JS, jump on sign...but I don't
> remember the cycle times on each.  I haven't done any x86 assembly in
> probably 10 years.  Anyway, I don't know that I believe it actually saves
> any time...

You don't really think PS is written in assembly language, do you? 
It's almost surely written in C.  Neither C nor any other high level language
has direct access to CPU flags.  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.

Example: a and b are pixel values, let's add them and put result in c.

For 15 bits stuff it would be -- with all arithmetic 16 bit:
  c = a + b;
  if (c<0) c = 32767;

For 16 bit, all values must be converted to 32 bits;
  tempa = a;
  tempb = b;
  tempc = tempa + tempb;
  if (tempc > 32767) tempc = 32767
  c = tempc;

It could be written more compactly but all the operations must be there.
Anyway this will take a lot more time -- probably more than double.

> 
> > There's nothing wrong with dithering upon dithering.
> 
> I guess that depends on what you mean by wrong...but you may very well be
> right, I just don't know what it'll do.
> 
> > > > Its just that PS limits how accurate you can specify the
> > adjustment curve.
> > >
> > > Understood.  I still don't know how the printer driver etc. handles the
> > > Rourke output methodology though...
> >
> > There's nothing particularly special about it.
> 
> Well, then, what, exactly, does it do?
> 
> > > > > still sent to the printer driver, which only handles 8 bits
> > > > anyway...but I
> > > > > guess if it is in fact printing 8 bits/channel (and in this case, it
> > > > > actually is), you could theoretically get the additional tones
> > > > (though it
> > > > > isn't 256 x 4 BTW, since you can't print all the way to %100
> > > > with three of
> > > > > the inks...and some tones would be duplicated etc....which,
> > > > this argument,
> > > > > in and of it self, also brings me to question Cone's
> > claim...since you'd
> > > > > have to get 512 of the tones from the black ink only etc.).
> > >
> > > 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.

> 
> > likewise you adjust curves, you still have only 256 values.
> > Sure there's lots more bits but only 256 combinations will be used.
> > The 4 shades of ink doesn't increase the number of grays either.
> > It just makes it do a better job of getting 256 levels.
> 
> The number of inks has nothing to do with the number of levels.  It makes
> the area required to get N levels smaller.

Right.
> 
> > So I don't
> > buy any 256*4 calculation for ONE pixel.  Its the averaging of
> > MULTIPLE pixels that gives you more gray values -- that's the
> > only way you can get more grays.
> 
> You can get infinite grays from one color given an infinite area with which
> to dither...for one pixel.

The point is if you only give the driver 256 different values it can only
do 256 different things.

> 
> > Note that the averaging can
> > happen in many ways, explicitly in the driver, ink bleed on the
> > paper, limited resolution of our eyes, or measuring area of the
> > densitometer.
> 
> 
> > 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.  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.  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.
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.

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

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

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

Roy