Re: [Gimp-print-devel] Black generation, continued

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

   Date: Sat, 20 May 2000 18:11:57 +0200
   From: Thomas Tonino <tt...@bi...>

   > It isn't enough.  Not only do we need matrices to dither the output
   > dots, we also need to dither different dot sizes and colors.  That
   > matrix *must* be just as good as the others, and it *must* be
   > uncorrelated.

   If it must be really uncorrelated, I guess the only thing to do is to
   generate a number of them. But I feel that the only correlation problem
   we might run into is the initial few points of the matrix against the
   same initial points. If these are displaced for every use, the rest will
   be practically uncorrelated.

The requirements for the dot selection matrices are different from the
ones that decide whether to print ink.  Extremely even sparse behavior
is less of an issue; complete lack of correlation with the matrix that
governs whether to print at all is crucial.  I'd actually prefer that
a matrix of different size be used for that purpose, although I'm not
certain that that's critical.  I'm afraid that simply shifting the
matrix will generate low-frequency patterning.

I'm not too concerned about having more matrices; it does mean more
space will be consumed (although we could use unsigned shorts to store
the matrices), but if the quality improves enough, it's well worth
it.

   In any case, the 'problem' was my stupidity. In any case, I like to use
   the autocorrelation properties of the matrix for very low density. It
   makes sure that a very light grey gets printed with C and M dots far
   apart. As density increases dots are filled in more or less at random
   and correlation between different sections of the matrix gets extremely
   low.

What you want in that case is actually negative correlation.

   I hope the second independent matrix works out for the light vs dark ink
   decisions. Let me know how you fare: I'm really happy with the extra
   black I put in, so seeing it appear in cvs would be great - but I don't
   feel like doing that myself yet: it is a quick hack, I haven't tested
   with other printers, etc.

If you want to put it in, please do so.  If it elicits too many
screams, somebody will just back it out.  That's the nice thing about
source control.

   I think I oversimplified that bit of code by taking out those ifs to
   check inputs and instead checking results. How does it work on the EX
   anyway? I see now that the driver really reacts to the black limits that
   are set and that a greay wedge is nicely monotonous.

Make sure it works well with colors.tif
(http://www.tiac.net/users/rlk/colors.tif).  That's a pretty good test
for finding discontinuous behavior.

As for black level, it's very important that it start at zero and
smoothly increase for the variable dot size printers, to allow a range
that uses small black dots.  If you really want a lot of black to hit
fast, you can handle that by having the density argument to
print_color start at zero and increase smoothly (that's what's used to
decide what tone to print).

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