Re: [Gimp-print-devel] Matrix results

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

   Date: Fri, 28 Apr 2000 08:38:53 +0200
   From: Thomas Tonino <tt...@bi...>

   > I noticed that too.  Dark tans did even worse, with nasty green
   > splotches.  I don't understand that at all; I would expect ordered
   > dither to do very well on such regions, and I certainly wouldn't
   > expect splotches.

   Maybe it has to do with the way the matrices interleave: only a single
   matrix is used. If we would use a different matrix per color, or maybe
   nu use 65535-matrixvalue, results would be different.

It's using a different variation on the matrix for each color, but the
matrices aren't random enough so that there's no correlation.  We
probably really do need different matrices for each color.

   Green might work well because cyan and magenta use matrixvalue and
   65535-matrixvalue. Cyan and black use both matrixvalue - is this matrix
   shifted in some place, or rotated perhaps? It could be worthwhile trying
   the same matrix for all colors, or use something simple like a shift of
   half the matrix width. I'll try that.

It's both shifted and rotated.

   > I suggest using 1440 highest quality.  720 softweave is fast, but it
   > shows a lot of banding.  We need 720 to work well (and 360, for that
   > matter), but for absolute highest quality there's no substitute for
   > 1440.

   It definitely does bad a little. I was a bit disappointed with 1440, but
   that may well have been my choice of dither and not a problem with the
   resolution.

All of these printers band a little, especially at high ink density.
I have test shots I've picked up at the Epson booth at the Hunt's
camera show in Boston, made on a 1200, that show banding.  It's worst
in moderately dark areas.  I think it's due to too much ink being
dropped, and pooling up in some cases.  The iterated-2 matrix, when
not used very carefully, is particularly prone to banding at 1440 (and
even at 720 on some of the newer printers) because of its tendency to
print every other dot.  This gives alternate halves of the interleave
very different amounts of ink.  Another reason to avoid that matrix.

The weave algorithm won't currently support an 8-pass solution with 32
jets and a separation of 8 (i. e. the EX and the 600).  It would work
on a 1200 or 1270 (48/6).  If I can fix that (and if you think the
dither code is bad, try reading the weave computation -- I don't even
understand that, and it's my code!) it should result in even smoother
output than the 4 passes used by 1440x720 highest quality (of course,
it will print even slower than it does now).  There might also be a
way to fake it.

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