Re: [Gimp-print-devel] dithering for variable drop size, color adjustments

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

   Date: Mon, 07 Feb 2000 18:16:53 +0100
   From: Andy Thaller <th...@ph...>

   In case I'll ever find out how to utilize my bjc-6000's ink drop
   modulation functionality: how will I tell the dithering algorithm
   to produce suitable output? I'll propably need 2-3 levels of
   dropsizes (can their size-ratios be accounted for?) in a yet to be
   ascertained bit order. I'm just curious -- don't start hacking away
   immediately if the code isn't there already ;-)

I actually checked this stuff in last night.  There's a real API for
this, and it should be fully supported.  Look in print.h for the
various dither_set_* functions.  In particular, you want the functions

dither_set_c_levels(void *, int, double *)

and their equivalents for the other inks.  These functions take the
following arguments:

	void *vd is the handle you're given by init_dither().

	int levels is the number of levels (it will be interesting to
	see if anything not a power of 2 works).

	double *levels is a vector of levels (levels[0] should equal
	0.0).  Each value should be between 0 and 1 inclusive.  They
	should increase monotonically.

The output bit array is treated as a vector of bit arrays numbering
ceil(log2 levels).  So if there are two levels (the normal situation,
in which case you should use the dither_cmyk function), there is one
bit array; if there are four levels there are two arrays, and so
forth.  Bytes 0..length-1 are the lowest order bits, bytes 
length..2 * length - 1 are the next bits, and so forth.  There's a
function escp2_fold in print_escp2.c that folds these bits into a more
normal packing order.  You should be fully set here.

The reason for this seemingly baroque ordering is that PCL printers
actually take these vectors of bits, rather than folding them.  But it
actually makes sense, since different printers will handle this stuff
differently, and it's a fairly easy ordering to deal with (unpacking
bits is a lot messier, particularly with an arbitrary number of bit
planes).

   Something else I'd like to know is how I can set gamma and
   intensity levels for each of the color components seperately. Of
   course, color correction is something a color management system
   should do but until that is available I'd like to have a
   quick'n'dirty way...

About the best thing you could do is recompute the lookup table when
your print function is called.  In fact, calling compute_lut() from
inside print.c is really silly; it should be called from inside the
print function, and I may just change this.  There are already
intensity controls for each of the colors; adding gamma controls isn't
hard, but it is tedious.

It would really make sense to put the LUT in the variables block,
actually, and save it in the printrc.  The LUT (unlike the color map)
is really part of the printer definition, not of the image.  In fact,
it would arguably make sense to put the color mapping stuff in the
image code, rather than the print functions, so that the image code
does the translation to RGB or RGBA.

If you want to expose them, you'll have to hack the UI code in
print.c, which is ugly.  You should probably discuss this with Steve
Miller <sm...@rn...>, who's working on the GUI.

I'm beginning to think that we should consider redoing the printrc
file format some time during this development cycle.  We've already
added stuff to it, and it's rather ugly.  The "obvious" thing to do is
to come up with an XML definition here; we can then easily add stuff
later, and people can edit printer definitions with their favorite
browser (hint: transfer functions!).

I think GTK actually has a pretty nice gamma curve widget.  It's not
really documented anywhere, but I think SANE uses this (hint hint,
somebody :-) ).  This would be a real win for us.

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