Yahoo Groups archive

Digital BW, The Print

Index last updated: 2026-04-28 22:56 UTC

Message

Re: [Digital BW] Combing cure -- change size after the curves are applied

2002-03-21 by Bob Frost

Austin & Keith,

Posting 2

 "I have not read the article, but it sounds as if you are reading the 
article correctly because that is exactly what the Epson driver does - 
however your concerns are not particularly sound, since this upsampling 
is merely one stage in several which together make up the half-toning 
algorithms which Epson use to convert from the pixels per inch that you 
choose to send it and the dots per inch which it requires to print.

You can find the resampling resolution which Epson use by a simple test, 
printing blocks of single pixel wide lines with single pixel gaps 
between them at different ppi.  As the ppi increases, the lines become 
finer and the blocks become smaller, as you would expect.  As you get to 
higher ppi figures you will need a loupe to see the lines distinctly, 
since the resolution of the printer exceeds that of the naked eye. 
However, as you approach 720ppi you will find that not only do you see 
the original lines on the printed page, but you see faint images of 
broader lines at resolutions which correspond to the difference between 
720ppi and the input resolution you are printing at.  These are alias 
images - false lines caused by the resampling of the input data.  So if 
you print lines at, say 650ppi, then you will not only see lines that 
are on average 325line pairss per inch (you need one pixel width for the 
line and one for the gap, so that the number of line pairs is always 
half the ppi) but also "ghost" lines at 35line pairs per inch, since 
720-650=70ppi, which is the aliased image.

Eventually, at exactly 720ppi, the block will print either completely 
solid colour or completely white and shifting the image by a single 
pixel will change between these two states.  What has happened is that 
the line pattern has aliased to 0 line pairs per inch, so each "ghost" 
line is infinitely wide (clearly limited in size by the input size of 
the test image.

This in itself is a clear indication of resampling to 720ppi or an 
integer multiple thereof, but increasing the ppi of the test image even 
further will result in "ghost" lines which reduce in width.  So that if 
you print your test image at 790ppi you will find the lines look 
identical to the test image printed at 650ppi - the only difference 
being that the test patch itself is smaller.  Once again, the "ghost" 
lines are at 35line pairs per inch with fine detail at, on average, 
325line pairs per inch.

It is the existence of these two "mirror" images centred around 720ppi 
which proves that the Epson driver is resampling to 720ppi.  What is 
also worth noting is that this 720ppi resampling occurs in both axes 
whether the printer is set to print at 720ppi, 1440ppi or 2880ppi - 
720ppi is the MAXIMUM resolution that the printer can reproduce on the 
page.  I haven't checked to see if the resampling resolution is reduced 
when printing at, say, 360dpi - but I suspect it is.

After resampling to 720ppi, the Epson driver then applies a stochastic 
dither to reduce the bit depth of the image to match the tonal 
capability of the particular printer, which is defined in terms of the 
number of ink colours, the dot sizes which is capable of depositing on 
the page and the dot resolution.  A 6 colour, 2880dpi, 6 dot size 
printer is capable of finer tonal reproduction than a 4 colour, 720dpi, 
1 dot size printer for example, and so the 720ppi image requires a 
coarser dither with the latter than the former.  The actual algorithm 
used is quite complex, however it has the property of spreading the 
dither over several pixels of the original image where smooth tone 
variations occur and also printing individual pixels at reduced colour 
accuracy where fine detail occurs in the image.  Generally this yields 
good results on the page, with near photographic tonal range and fine 
detail reproduction, but occasionally (as with some cases of low level 
film grain) results in the contrast of fine detail being exaggerated 
when high resolution input files are used.

I suspect that the author of the page you are reading has some 
alternative algorithm for both the resampling and the dither which 
outperform the standard Epson algorithms in some, perhaps all, 
situations.  It could, for example, be possible to resample at the 
native resolution of the printer itself - eg. 1440ppi or 2880ppi - and 
obtain some marginal improvements over the standard Epson algorithm, but 
I would not like to guess at how significant the difference would be. 
Certainly the difference would be detectable in specific test images, 
such as that discussed above, but for general photographic images I am 
not entirely convinced the difference would be worthwhile.

I don't think you should be overly concerned about the resampling issue. 
As above, using highly synthetic test images, it is possible to 
determine that resampling has occurred and what the frequency of that 
resampling is.  However, for general images of less than 360ppi this is 
usually imperceptible.

Why should you be worried about resampling on a printer, whether by 
pixel replication or some interpolation algorithm, when the resampled 
pixels are beyond the resolution of your eye?  This is not the same 
thing as resampling on a scanner - where the image can be printed out at 
any size and, hence, the effect of resampling can be clearly visible. 
Effectively, your eye is resampling every image you see by the structure 
of the rods and cones on your retina - whilst more random than the 
orthogonal matrix used in the Epson printer the resampling in your eye 
is significantly coarser, which is why the images from these printers 
look acceptable at all!       :-)

In short:
Do Epson printer drivers resample to 720ppi? : Yes.
Is the resampling perceptible? : In around 99.99% of cases, no.
How much should you be concerned? : Around 0.01%.        ;-)
-- 
Kennedy"

Bob Frost

Attachments

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.