Digital BW, The Print

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.

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

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

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

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

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

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

Austin