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

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

   Date: Sat, 20 May 2000 12:09:41 +0200
   From: Thomas Tonino <tt...@bi...>

   >    I reinstated the old kdarkness generation:
   > 
   > I think that that's the wrong approach.  I'm trying to remember
   > exactly why I got rid of it, but it behaved very strangely.  Maybe we
   > need that to be configurable.

   I decided to take out everything I didn't fully understand, and did a
   little cleaning up. It reacts properly now to set_black_upper and
   -_lower and colors look good. It also seems faster. This is what is
   left:

	 oc = c;
	 om = m;
	 oy = y;
	 k = MIN(c, MIN(m, y));

	 if (black != NULL)
	   {
	     ok = k;
	     ak = k;
	     ub = d->k_upper;	/* Upper bound *
	     lb = d->k_lower;	/* Lower bound */
	     rb = ub - lb;	/* Range */

You really want to use an appropriate set of if's around what's
below.  There's no sense in performing the extra multiply and divide
when you know you're going to throw away the result, and it also leads
to the risk of range problems.

	     bk = (ok - lb) * d->density / (ub - lb);
	     if ( bk < 0)
	       bk = 0;
	     if ( bk > d->density )
	       bk = d->density;
	     k = bk;
		   y = 0;
	       }

   I'm doubting what to do with the matrices. On one hand, a matrix that
   performs very well when shifted halfway right and halfway down sounds
   like the way to go. This allows the two darkest colors to mix well.
   Other stuff can be mixed in in less optimal positions.

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.  I have a fix in hand that improves output on my EX, and
in some places it improves output on the 870.  Unfortunately, in other
places it also makes the 870 output worse, because I don't have a good
enough dither there.

   I guess I first have to find out what broke the use of the first matrix.
   So far for organized working on my side.

Don't worry about it.  If you knew how many times I've busted the
dither code myself, you'd want to toss me off the project.  In fact,
the fix that I'm going to check in (and it IS, overall, a fix) is only
the latest flip-flop in that regard (what value to subtract from the
error when printing a dot that may be one of two strengths).

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