Re: [Gimp-print-devel] First experiences with an 870

[Robert L K. <rl...@al...>]

Nice stuff.  BTW, you can generate diffs with 'cvs diff -u'.

BTW, since you're a Debian developer and there are a number of people
here interested in how to package this up for Debian, how would you
like to become a developer on this project?  If you'd like to, just
get yourself an account on sourceforge.net and drop me a note.  We
need someone to create .deb's (as well as rpm's).

   Date: Tue, 9 May 2000 00:03:54 +0100
   From: Charles Briscoe-Smith <cp...@de...>

   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.

That should be pretty good, although the 3.1.4 release might be
slightly better (or it might not).

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

Yup.  BTW, that's one major difference between the version you pulled
and the current source.  The current source uses .999 as black_upper.
That means that pure black will be printed using only black ink.  1.0
allows some color ink to mix in.

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

I've also found that 1.5~1.6 works well with these printers.  I'd like
to find out exactly what printers work well at that setting, and then
change them in the printer parameter list (printers.xml).

   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.

Jean-Marc has been doing some work in this area.  Unfortunately, I
bollixed him well and truly by changing all the dither stuff between
3.1.2 and 3.1.3.

		  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.

The microweave modes are almost useless with this printer.  They're
also evidently done incorrectly.  You might find that a density of 1.0
will work well in the microweave modes (if it matters, which it really
doesn't, since those modes really don't offer anything of interest).

1440x720 enhanced renders at 1440x1440.  On my Photo EX, that improves
things quite a lot.  Maybe it doesn't matter on the 870, which has
such tiny dots to begin with.

   720DPI high quality:    30sec      2min 14sec

I would expect that that would render much faster than 1440x720, since
it only generates half as many dots.  You might like to try 720 softweave.

   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!)

See above about the tiny dots.  It might also be (barely) noticeably
different in things with very sharp transitions or very fine lines.

   1"x1.6":
   360DPI:                 3sec       7sec
       Dark, grainy, too magenta, but fast.

Try a density of 1.0 here.

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

Again, try a density of 1.0 here, and don't bother using this mode.

   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.

I have the same problem (kernel 2.2.10).  What kernel are you running?

   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.

That's an attempt to correct for the starting vertical position thing
you noted below.  I don't have that quite right.

   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.

The difficulty is that in some of the high resolution modes that
assumption is incorrect (in some cases, it advances by as little as
one row sometimes -- the actual advance varies).  If you want to play
with this, check out the test program 'escp2-weavetest'.  This (in
combination with run-weavetest) is a regression test for the weave
code, that checks a whole bunch of invariants very carefully.  It's
really hard to get it all right, but if you want to take a crack at
it, please do (it would be a really worthwhile contribution).  Right
now it does something that works correctly, at the cost of losing the
top and bottom of the sheet.

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

That's interesting.

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

It's not possible to reverse feed.  At least, it isn't documented, and
I've never seen a Windows print file that suggested that it is.

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

The problem is that the Gimp hits plugins with a SIGKILL (kill -9)
whenever you hit cancel, so there's no opportunity to clean up (Sven,
are you listening?)

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

Did that seem specific to the camera?

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

Hmm.  Maybe I should use genuine Epson paper :-)

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

That seems to be a common theme.  It's much less than it is on the
Photo EX, and the driver is much better tuned for the EX.

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

Huh.  That's interesting.  Look at dark yellows carefully.

   Well, I've probably bored you for long enough now.  Thanks for reading
   this far.  ;)

Certainly not (the former).  That's how we get new ideas.

   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!

The driver is very well tuned for the 700 (I previously had an EX).
It's not a bad printer, even if the dots are a bit coarse and it's
hard to balance the colors precisely.

-- 
Robert Krawitz <rl...@al...>      http://www.tiac.net/users/rlk/

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lp...@uu...
Project lead for The Gimp Print --  http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton