Re: [Gimp-print-devel] Article: adaptive methods for dithering color images

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

   Date: Wed, 26 Apr 2000 16:15:21 +0200
   From: Thomas Tonino <tt...@bi...>

   What Riemersma dither does is look back at (say) the errors of the last
   100 pixels printed, weigh each with a scale factor, and use this as
   error when deciding to print the current pixel.

The problem is in the definition of "last 100 pixels".  The last 100
pixels actually generated are in a line, but I suspect it would work
better with 100 pixels in a semicircle centered on the point printed
(a two-dimensional Riemersma).

   I did make a suggestion to Robert that it might be possible to do
   something with the error buffer. Before using the value in the error
   buffer, distribute it partially away. The result is a very large
   distribution area.

Ah, the joys of open source.  Anyone can do anything.  Particularly
when I get around to writing documentation :-)

   Another suggestion I had was to use the required gray value (of error +
   input) to decide whether to print, and when it is decided to print, lay
   down color dot of the color that needs to be printed most from a color
   error perspective. Keep laying down different color dots in this
   position until the gray value is as it should be. This has the advantage
   of following the human eye sensitivity better than working per color.
   But it probably is very difficult to integrate with variable dot size
   and other clever rastering support.

Actually, what is currently done isn't too different.  It looks at the
value of the input to decide what one or two dot sizes (or tones) are
eligible for printing, and then decides from the input+error whether
to print based upon the scaled size of the dot.  It then decides which
dot to actually print based on a matrix or a random number, depending
upon the dither mode.

   The problem with the above is that for every dot to be printed, one has
   to build a perception model and compare this with the perception model
   of the original image. This is very slow compared to the few shifts and
   adds that make up error distribution (although the implememntation as it
   is now also has quite some decisionmaking built in).

There's a lot of decision making, but I've tried to cut down on the
amount of branching actually going on.  It's the combination of
various decisions that make print_color so ugly.

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