Hi Austin, --- In DigitalBlackandWhiteThePrint@y..., "Austin Franklin" <darkroom@i...> wrote: > > Hi Roy, > ... > > > > Yes, using the gradient tool without dithering will make squares, > > with dithering > > it will actually smooth between transition. > > Oh, you mean PS dithering, not Piezo driver dithering...right? Yes, correct. > > > > Recently someone mentioned that PS only uses > > 15 bits in high bit mode, I was able to confirm this using this method. > > I've never done anything in PS in 16 bit mode, but using 15 bits is just not > kosher in my book. I guess you weren't one the 16-bit only users. Well 15 bits is way overkill anyway -- the storage and work is all done with 16 bit quantities. 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. 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. 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. Well worth it in my opinion. > > > > > It not labeled > > > > as such but it does have all 256 levels (some do appear to be > > doubled) and > > > > far as I can tell there's no dithering between levels. > > > > > > But if there's no dithering between the levels...then doesn't > > that refute > > > the 1000 tone claim...and support the less than 256 claim? > > > > As I said above, the dithering/no-dithering gives you the steps versus > > smooth transition. I'd hope you could try both and see the results. > > Hum...if it's PS that's dithering...I wonder what the driver will do with it > already dithered... There's nothing wrong with dithering upon dithering. > > > > > 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. > > > > 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, 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. 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. 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" "you'd have to get 512 of the tones from the black ink only" > > Regards, > > Austin Roy
Message
[Digital BW] Number of tones was Re: Do inkjets dither or not?
2002-08-06 by royvharrington
Attachments
- No local attachments were found for this message.