Digital BW, The Print

Hi Tony,

> What I am saying is that prior to the driver doing its own
> conversion from pixels to dots it may first do its own conversion to
> resample the image to a fixed pixel resolution.

It COULD work that way...but there is no reason it has to.

> Let's say the code routine in the driver which perfroms the pixels->dots
> conversion has been written so that it can only accept an input resolution
> of 360ppi. There will be a routine in the driver which would then first
> check to see whether the image resolution passed to it by the imaging
> application/print spooler is at the correct resolution to be passed to the
> pixels->dots function, and if not, it will do this resampling.

Understood, but again, that's an assumption that it works that way.

> Note there
> are two separate things happening here in the print driver:

In this hypothetical print driver, yes.

> 1. Resampling to a fixed PPI.
> 2. Conversion from PPI to whatever dpi/dither algorithm is used by the
> printer and generation of the printer commands for the actual print.
>
> It is this first step which I am contending could be sidestepped simply by
> sending the correct PPI image to the printer.

Yes.

> I do understand pixel to dot conversion and dithering to a certain extent.

I now get that impression.

> Of course if you do have any detailed URLs I'd be happy to earn more.

Check the Adobe web site, under PhotoShop.  They have a very good halftoning
tutorial.

> My question really was "where does the PPI resampling of an image
> happen, if
> indeed it happens at all"? I'm not talking about the conversion
> of the pixel
> data into the cmyk dots that go down as a dither pattern, just the pixel
> resampling of the image.

But dither algorithms don't have to do pixel resampling at all.  They can
just convert from what ever pixels/inch you send to dots.  You are assuming
a particular implementation.  Also, not all printers that print B&W use CMYK
dots, some use a single ink.

> I am, above all asking whether it is an atomic
> transformation which happens at exactly the same time that the pixel-dot
> conversion is done, whether is it a step which occurs before the pixel to
> dot transformation although still within the driver, or whether there is
> actually no resampling of the image data by the print driver prior to the
> conversion to actual printer dots.

That solely depends on what algorithm was implemented in the driver, there
are no hard fast requirements for any of this.  There are dozens of
different dithering techniques.

> please let me know what, if
> any of it, is correct.

I understand what you are getting at, and again, it could be implemented as
you suggest, but how it actually "works" we may never know, the printer
drivers are typically black boxes.  The only one we have any substantial
information on is the Piezo driver, which does not do as you suggest,
according to Jon Cone, and I'd have to agree.

I've implemented dither algorithms, and I've never resampled as you suggest.
My initial impression would be that it would give inferior results, since
there is yet a second resampling that has to take place when converting
pixels to dots...so why not do it only once, and minimize degradation.  Some
printers have not only multiple inks, and multiple resolutions, and multiple
dot sizes.  I'm hard pressed to believe that simply resampling up to where
pixels/inch = dots/inch is optimal for all printers.  It may be OK for
printers with fixed dot sizes, and/or single inks...

As I always say, simply try it out and see if you believe the results are
any "better".  I know that with the Piezo driver, I have tried fixed
multiples vs most any weird resolution you can imagine, like 531.2, and I
simply find the more resolution I send the driver, the better the image gets
printed.  And, like Jerry as said, it is visually notable up to 460 or so,
and beyond that, it's notable with a loupe up to 720, and anything beyond
that isn't noticeable.

Regards,

Austin