Re: [Gimp-print-devel] Latest results

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

   Date: Fri, 19 May 2000 00:26:17 +0200
   From: Thomas Tonino <tt...@bi...>

   Thomas Tonino wrote:

   > > Thomas, could you play around with your new matrix some more?  It's
   > > not in, because having only one matrix caused problems, but it does
   > > look promising.  It really bloats the executable, though.
   > 
   > I have a number of things I'm trying.

   It turns out the things that I'm trying don't work. While CMY dither
   works fine the transition to K just doesn't work out - even if I use
   rand() instead of a matrix.

Really?  I've been wondering if black should always be printed with
ordered rather than error diffusion (at least for reasonably high
values of k_lower).  It hasn't worked well thus far, but I wonder if
the thing I fixed last night might help it do better.

   This led me to believe that the current K generation needs error
   diffusion to give a decent result. I changed the following piece:

		 else if (kdarkness < ub) /* Probabilistic */
		   {
		    /*
		     * Calculate how much black we are going to shuffle away
		     */
		     if ( kdarkness >= lb )
		       rk = (kdarkness - lb) * ( ok / rb);
kdarkness will always be > lb here

   I have to set density a bit lower (to 0.9) and still the density of
   black seems too high.  I tried first with dither_set_black_lower(dither,
   .1 / bits) in print-escp2.c because that shows problems rather clearly,
   but with the above changes, the 'green problem' is fixed.

Interesting.  I've had a lot of trouble getting enough black most of
the time.  Could you send me a diff?

   Going back to .4 for dither_set_black_lower shows a problem: from light
   to dark, first CMY builds up. At higher density, K also starts to build
   p. Suddenly, CMY drops off to 0 while K is not up to maximum yet. So
   there definitely is a problem with the value of rk: maybe it's off by a
   factor of 65536?

More likely you're multiplying two ints, and when the product exceeds
2 GB you're flipping over into negative territory.  Switching to long
long arithmetic will show that up quickly.

   I do not have good insight currently in what kdarkness, ok, and others
   exactly do. I do know that what I see for dither_set_black_lower = 0.4
   demonstrates my code is wrong. I'd like to achieve something along the
   following lines:

kdarkness is supposed to represent the perceived "darkness" of the
point.  We don't want to use black in light areas.  "ok" means
"original k" (same for oc, om, and oy) -- the base values before any
error diffusion is done.

   /* if c + m + y is more than the paper can absorb, we determine which
...

This approach looks reasonable to me.  Let's think about it some
more.  I'm too wiped right now.

   It may even be possible to make this work with the right combination of
   the current variables. It just seems that using the binary dither result
   to adjust analogue input values is not a good idea for ordered dither,
   and it may not be a good idea at all.

Hmm.  It occurs to me that you might not have picked up my commit this
morning?  I changed it from an on/off result to a smoothly scaled
value.  Note this:

#if 0
		  if ((d->dither_type & ~D_ADAPTIVE_BASE) == D_FLOYD)
		    ditherbit = ((xrand() & 0xffff000) >> 12);
		  else
		    ditherbit = (DITHERPOINT(d, row, x, 1) ^
				 (DITHERPOINT(d, row, x, 3) >> 2));
		  ditherbit = ditherbit * rb / 65536;
		  if (rb == 0 || (ditherbit < (kdarkness - lb)))
		    bk = ok;
		  else
		    bk = 0;
#else
		  bk = (ok - lb) * (ok - lb) / (ub - lb);
#endif

The code that's in use is that last line, which scales bk smoothly
between 0 and ub as kdarkness goes from lb to ub.

   It's late now. The new matrixc will be ready tomorrow morning, but I
   doubt it will make a significant difference if rand() causes the same
   problems as re-using the matrix. Maybe K doesn't register exactly with
   CMY or so - in any case, K buildup in the old code looks very clustery.

I think I understand now.  I'm going to try to reprint from my EX onto
a piece of Epson photo paper, rather than the third party stuff that
has problems with the Epson ink.

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