Menu
▾
▴
Re: [Gimp-print-devel] First experiences with an 870
|
From: Charles Briscoe-S. <cp...@de...> - 2000-05-08 23:10:03
|
Hello all,
I'd better introduce myself. I'm Charles Briscoe-Smith. I recently
finished a PhD thesis in computer science, and am waiting to do my exam.
In the mean time, I'm helping my sisters turn their photography business
into a digital photography business. I built them a PC, installed Debian
on it (well I'd have to, wouldn't I? I'm a Debian developer!), advised
them on buying a digital camera, and have finally got them a printer.
When we have a UPS, we should be ready to rip the minilab out of their van
and replace it with the PC and printer. Then, when they go to photograph
at horse shows, they won't have a delay of half an hour between getting
the film back to the van and being able to show people their pictures,
and this should result in more sales.
About 1.5 weeks ago, we ordered an ESP870. It arrived on Friday,
since when I've been testing it with gimp-print, (and testing gimp-print
with it), and I've just come up for air. ;) (In the meantime, it seems
everyone else on this list has also acquired an 870... Hello Jean-Marc!
Hello Robert!)
The results are pretty impressive. I'll go through what I've done and
what I've found; let me know if this is of any use.
I used the CVS version of gimp-print as of late evening UK time Thursday
(4th May). I did try 3.1.2 first of all, since I already had it
installed, but the results weren't much good. gimp-print has improved
a lot since then.
My main tests were all on Epson A4 Photo Paper (not the "Premium Glossy
Photo Paper" that came in the sample pack supplied with the printer)
and with the Epson "Intellidge" ink that came with the printer. I used
quite a few different images, mostly taken with a Nikon D1 digital
camera on "normal" quality. (All the images that that camera produces
are 2000x1312; the quality setting adjusts the degree of compression.
"Normal" gives JPEG files of about 600KB.)
I started with gimp-print's default settings, changing paper type
to "glossy film", ink type to "variable dot size" and resolution to
"1440x720DPI Softweave". This gave prints that were not too bad, but
were rather light and desaturated.
(Incidentally, I can't see anywhere in the ESC/P2 code path where the
"glossy film" setting actually affects anything... print-escp2.c sets
use_glossy_film=3D1, but the only place that it's used says:
if (use_glossy_film)
dither_set_black_upper(dither, 1.0);
else
dither_set_black_upper(dither, 1.0);
Was there once some difference here?)
The first thing I did was to increase the density, since black areas
were showing flecks of white paper. Density of 1.5 seemed enough to
fill in the gaps, and brought the overall image brightness down to
about the right level. (I was using a scan of a Kodak colour test card
at this point. I also printed a set of CMYK fountain fills, and the
results were fairly even. The test card scan and the fountain fills
were the only images I've used so far that did not come from the D1.)
At this point, I went outside and photographed some plants (we had nice
sunny weather in London that day, for a change). I printed these at about
2"x3", with good results. The prints really look (to me) like standard
optical/chemical prints from any viewing distance more than about 4
inches, although looking back at those prints now, I can see that they
are not the correct colour (somewhat too yellow). I've spent quite some
time twiddling the colour balance, but I haven't got it right yet.
I tested the various resolution/weave settings for both rendering time,
printing time and appearance. Rendering time is for a 400MHz K6-II.
Printing a 2"x3" photo from a 2000x1312 jpeg:
Time to Render Print
------ -----
1440x720DPI softweave: 34sec 2min 14sec
1440x720DPI enhanced: 50sec 4min 20sec
1440x720DPI microweave: 34sec 25min (that's not a typo!)
As well as taking 25min to print, this one looked awful. Too dark,
grainy and fuzzy, and looking as if the image had been quantised
to just a few levels of intensity before printing. There are also
diagonal lines visible in the dark areas. A softweave print of the
same picture was excellent, with every vein in the leaves clearly
defined and good colour tones. Looking at the highlights with an
eyepiece, I think maybe the wrong dot size is being used. It looks
like normal size dots are being printed where small dots should be.
720DPI high quality: 30sec 2min 14sec
4"x6":
1440x720DPI softweave: 1min 50sec 5min
Full A4 (with my clipping patch (see later)):
1440x720DPI softweave: 5.5min 13.5min
(This was before I discovered that 720 softweave gave virtually
indistinguishable results in less than a third of the time!)
1"x1.6":
360DPI: 3sec 7sec
Dark, grainy, too magenta, but fast.
720DPI microweave: 6sec 34sec
Much, much too dark. The printer dumped so much ink on this one
that the photo paper actually went slightly soggy, something I
never expected to see (although it didn't actually soak through to
the back).
720DPI softweave: 6sec 24sec
Good. Bidirectional printing, so it was pretty fast, and I'm
surprised this didn't affect the print quality. When I print a
more complex full A4-width image in this mode, the printer pauses
at the end of each pass, presumably waiting for more data. It looks
like the parallel protocol is the bottleneck in this mode. I tried
setting the parport to ECP and EPP mode, and giving Linux the DMA
channel for this one, but wasn't able to speed it up any.
720DPI high quality: 6sec 1min 15sec
Good.
1440x720DPI microweave: 8sec 11min 55sec
Slow, dark, grainy and much too magenta.
1440x720DPI softweave: 9sec 1min 15sec
Good.
1440x720DPI enhanced: 19sec 2min 25sec
Good.
The four marked "good" are practically indistinguishable from one another.
Guess which one I'll be using for now? ;)
2.5"x3.8":
720DPI softweave: 23sec 55sec
720DPI high quality: 25sec 2min 52sec
1440x720DPI softweave: 39sec 3min 5sec
1440x720DPI enhanced: 1min 20sec 5min 35sec
In summary, the softweaves, high quality and enhanced were all equal best,
while 360DPI and the microweave modes were each pretty awful. Oddly,
the two microweaves and the 360dpi each printed half a millimetre lower
on the page than the other four modes.
I mentioned my clipping patch: I tried printing a image at full A4 size.
I switched "scaling" to PPI, then reduced the PPI just until the left
and top margins both became negative. This way, I reasoned, the image
should fill the entire printable area of the page, but would be clipped
somewhat at the top. It didn't work; the printer just sat and flashed
its power light...
Looking in the print file, I found that the driver was trying to
make the printer print outside its imagable area (in particular, it
had an odd-looking parameter for the first "ESC ( v"), so I patched
print-escp2.c to clip the image appropriately before passing the data
to the dithering routine. I don't use CVS very much, so I'm not sure
how to generate a diff against the repository; I'll read up on it and
make a patch sometime. (I also made a few other changes, like adding an
"A5 landscape-way" paper definition and maybe other stuff I've forgotten,
so I wouldn't want to commit the changes myself.)
After making the changes, I realised that what I did was probably not
the best way to fix the problem. Better would be clipping at a higher
level, before the printer command language-specific code is called.
And it's probably already done when the driver's used in ghostscript mode.
But it fixed things for me, and made me somewhat familiar with the code.
I've found that when printing at 360DPI, the top margin seems to be almost
nonexistent (perhaps 0.2mm), but with 720 softweave or 1440x720 softweave
it's just under 0.4 inches. If I read the definition in print-escp2.c
right, 0.4 inches is the distance between the top and bottom nozzles on
the 870 (at least as far as gimp-print is concerned). I think this means
that the weave algorithm must start by printing with the bottom-most jet,
then allow the weave pattern to move up until it reaches the top jet.
I've watched the way our ESC3000 (driven by the windows driver) prints
close to the bottom margin, and it appears to "compress" the weave
pattern to get closer to the trailing edge of the paper. As a result,
I'd like to suggest the following.
I guess the weave normally starts printing with the bottom nozzle.
Assume we're advancing the paper by x each pass, the nozzle separation
is s, and assume that x > s. We can instead start printing with the top
nozzle and advance the paper by (x - s) until the weave has expanded to
use all nozzles, then start advancing by x as before.
This could also be done in reverse at the bottom margin, as I've seen
the Windows ESC3000 driver do; at the moment, printing a full A4 page
with gimp-print results in the paper coming out from under the 870's push
rollers and being held only by those "trademark" Epson spiky metal wheels,
resulting in inaccurate paper positioning and a fuzzy bottom edge to
the print. The 750/1200 programming guide talks about margin expansion
using "ESC ( S"; I think this is what is supposed to allow the paper to
feed that far, but it gives bad results because of the paper misalignment.
(In the 870's Windows driver, selecting "maximum printable area" instead
of "standard printable area" results in a little pop-up box warning:
"This setting allows you to extend the printable area, but print quality
may decline in the expanded areas. Do not select this setting if you are
printing on Premium Glossy Photo Paper.") If we could adjust the weave
pattern to give the same margins without advancing the paper so far,
it should improve print quality near the trailing edge of the page.
If the weave was started from the top nozzle as described, that might give
banding near the top of the print (as the comments above the softweave
code in print-escp2.c describe), so here's another idea: start the weave
from the middle of the print head, and feed by (x - s) alternately with x,
expanding the weave towards the bottom of the print head when feeding
by (x - s) and towards the top of the print head when feeding by x.
(And vice-versa and in reverse at the bottom margin, of course.)
(Of course, if it's possible to reverse-feed the paper before starting
to print at the top margin, it might not be necessary to do this weave
compression at the leading edge, but it would probably still be desirable
at the trailing edge of the paper.)
One other thing: If I press the "Cancel" button during rendering,
the data that has already been piped into lpr gets printed anyway.
This should not happen. However, I'm not sure how it should be fixed
short of writing to a temp file and then passing this to lpr later,
and that would be bad because a full A4 print can produce a spool file
of up to 90MB. Perhaps gimp-print should send a signal to lpr to kill
it if the user hits "cancel"?
On Sat, May 06, 2000 at 08:16:55PM -0400, Robert L Krawitz wrote:
> Well, I hooked up the 870 today. Here's the first things I noticed:
>=20
> 1) The standard Epson density (.6'ish) is all wrong for this printer.
> I had to scale it to 1.3 (which really means 1.3 * .6, or about .8)
> to get anything that looked even remotely reasonable. Even that's
> a bit too low (I'm using photo glossy paper). I also had to knock
> down both gamma and brightness a bit (.9 gamma and 80 brightness;
> that gamma might be just a bit too low). Ron van Ostayen suggested
> a value of 1.6 for his ESC 900; that creates solid blacks, but it
> definitely drops too much ink (see below).
>=20
> This might explain why people with 900's are complaining that
> output is too light. Maybe all the variable dot size printers need
> adjustment.
I think this depends on the source image really. A friend asked for
four images to be printed today, and we used a brightness of about 75,
red=3Dblue=3Dgreen=3D100 and density=3D1.5. For images from our camera, th=
at
seems to be too yellow, and the brightness doesn't need to be reduced...
> 2) The ink dries very slowly.
I didn't find this. I used the ink that came with the printer, and Epson
A4 Photo Paper. I haven't yet managed to smudge a print. In fact,
I put one print through upside down to try a black and white print on
the back, and the print on the front seems unaffected. I didn't manage
to smudge the printing on either side.
> 3) Pale tones are very good indeed. Gray is very neutral. However,
I agree. The fountain fills I printed are very smooth. Looking again,
the grey goes very slightly green between about 35% and 75% black.
> 4) Mid and dark tones are grainy. It's less obvious when I push the
> density up. It might be a sign that the dither algorithm has
> problems here; it might also simply be a sign that the density is
> too low. The grain looks a little bit like "shadowing" from large
> dots, but not entirely.
I'm not sure I've seen this. Very dark areas occasionally "black out",
but gimp-print does this far less than the Windows driver does when
printing to our ESC3000.
> 6) The printer is nearly silent -- a nice change after the noisy EX.
Nice, isn't it? I'm not sure about the way it "tweets" when it's
turned on. ;)
> 7) I think the high density results in too much ink being dropped
Hmm... I appear to have already used up half a colour cartridge.
The black cartridge is nearly full, though. I suppose black carts have
far more black ink in them than the colour carts have of each colour.
> 8) Printing multiple images on the same page by means of multiple
> print runs is troublesome. Think slow-drying ink. Also, even
> after having dried for over 5 hours, the rollers still managed to
> pick some ink off the paper. This is less than thrilling from a
> development standpoint; I like to print very small images 25 to a
> page.
I do something very similar, but have had no problems with the ink.
The little metal rollers do make dents in the paper, and the cumulative
effect is kind of ugly after the paper has been through the printer a
dozen times. I haven't had problems with ink coming off, though.
Well, I've probably bored you for long enough now. Thanks for reading
this far. ;)
And thanks for all the work you (all) have already done on gimp-print!
I mentioned above that a friend (a newspaper photographer) had asked
for some images printed. He has a Photo 700 (and no ink at present) and
uses Windows (NT I think). After seeing the prints gimp-print produced,
he said he wanted a new printer. Congratulations!
Cheers,
--=20
Charles Briscoe-Smith <URL:http://www.debian.org/%7Ecpbs/>
PGP2: 1024/B35EE811 74 68 AB 2E 1C 60 22 94 B8 21 2D 01 DE 66 13 E2
|
