Menu
▾
▴
gimp-print-devel
|
From: Andy T. <th...@ph...> - 2000-02-07 17:18:50
|
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 ;-) 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... Andy. |
|
From: Robert L K. <rl...@al...> - 2000-02-08 00:19:52
|
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 |
|
From: S. M. <sm...@rn...> - 2000-02-08 01:59:18
|
Robert L Krawitz wrote: > 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. > Taking the last part first, I found a very brief reference to it in Pennington's "GTK+/Gnome Application Development". But there was no discussion of it's features or interface. If someone can point me in the right direction, this would definitely go great in an 'advanced settings' type window. I can also add individual color gamma correction widgets while I'm redoing that part. Should this be for all printers, or just cannon? I haven't got far enough for anything to be even set in mud yet, so if anyone has any suggestions or requests, I'm all ears. Steve -- ----------------------------------------- Just because I have a short attention span doesn't mean I ------------------------------------------ |
|
From: Karl H. K. <kh...@kh...> - 2000-02-08 03:40:50
|
On Mon, Feb 07, 2000 at 07:00:20PM -0700, S. Miller wrote:
> Taking the last part first, I found a very brief reference to it in
> Pennington's "GTK+/Gnome Application Development". But there was no
> discussion of it's features or interface. If someone can point me in
> the right direction, this would definitely go great in an 'advanced
> settings' type window.
The only think I know about it is that xscanimage from Sane uses it.
This is also the only place I've ever seen the widget.
Karl Heinz
--=20
Karl Heinz Kremer kh...@kh...
http://www.khk.net
ICQ: 41190739
|
|
From: S. M. <sm...@rn...> - 2000-02-08 04:47:43
|
Karl Heinz Kremer wrote: > > The only think I know about it is that xscanimage from Sane uses it. > This is also the only place I've ever seen the widget. > > Karl Heinz > > -- OK, I'll hunt down the source for it (I only downloaded the binary distro). For now its probably low priority anyway. I looked at it in glade, and couldn't figure out what it is supposed to do, as it had some sort of spline fitted curves. I thought gamma was the exponent for a nonlinear remap. Steve -- ----------------------------------------- Just because I have a short attention span doesn't mean I ------------------------------------------ |
|
From: Robert L K. <rl...@al...> - 2000-02-08 11:56:55
|
Date: Mon, 07 Feb 2000 19:00:20 -0700 From: "S. Miller" <sm...@rn...> I can also add individual color gamma correction widgets while I'm redoing that part. Should this be for all printers, or just cannon? I haven't got far enough for anything to be even set in mud yet, so if anyone has any suggestions or requests, I'm all ears. That should be for everything. -- 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 |
|
From: Andy T. <th...@ph...> - 2000-02-08 12:03:07
|
Ok, I tried it.. To check things out I'm not yet folding the output but leaving things as they are. this should give me two pictures the left being the lsb and the right the msb. however, only the first line of the dithering output actually contains any pixels. To illustrate this, I've put the input and output on http://www.ph.tum.de/~thaller/gimp-print/ Can you imagine, what's wrong? Andy. |
|
From: Robert L K. <rl...@al...> - 2000-02-08 12:12:26
|
Date: Tue, 08 Feb 2000 13:01:01 +0100 From: Andy Thaller <th...@ph...> Ok, I tried it.. To check things out I'm not yet folding the output but leaving things as they are. this should give me two pictures the left being the lsb and the right the msb. however, only the first line of the dithering output actually contains any pixels. To illustrate this, I've put the input and output on http://www.ph.tum.de/~thaller/gimp-print/ Can you imagine, what's wrong? Don't have any idea offhand; I'd need to see your code. |
|
From: Andy T. <th...@ph...> - 2000-02-08 14:10:40
|
Andy Thaller wrote: > Ok, I tried it.. To check things out I'm not yet folding the output but > leaving things as they are. this should give me two pictures the left being > the lsb and the right the msb. however, only the first line of the dithering > output actually contains any pixels. To illustrate this, I've put the input > and output on http://www.ph.tum.de/~thaller/gimp-print/ Ok, found it - dither_black is the wrong function, dither_black4 does the right thing. However, dither_cmyk also doesn't use more than 2 levels, right? Anyway, I'm happy it works for 4 black levels - I've put the output on the page mentioned above so you can have a look :-) Andy. |
|
From: Robert L K. <rl...@al...> - 2000-02-08 17:29:52
|
Date: Tue, 08 Feb 2000 15:08:38 +0100 From: Andy Thaller <th...@ph...> Andy Thaller wrote: > Ok, I tried it.. To check things out I'm not yet folding the output but > leaving things as they are. this should give me two pictures the left being > the lsb and the right the msb. however, only the first line of the dithering > output actually contains any pixels. To illustrate this, I've put the input > and output on http://www.ph.tum.de/~thaller/gimp-print/ Ok, found it - dither_black is the wrong function, dither_black4 does the right thing. However, dither_cmyk also doesn't use more than 2 levels, right? Anyway, I'm happy it works for 4 black levels - I've put the output on the page mentioned above so you can have a look :-) Right, use dither_cmyk4. |
|
From: Robert L K. <rl...@al...> - 2000-02-08 23:16:26
|
Date: Tue, 08 Feb 2000 18:54:06 +0100 From: Andy Thaller <th...@ph...> Robert L Krawitz wrote: > Right, use dither_cmyk4. mmm - right :-) Guess I'm too tired today. Anyway, checked in new drop size stuff code ready for testing (can't expect to test it myself tonight). dither_cmyk4() doesn't produce more than one level per component, though. Think I've got everything right this time, but I've erred before ;-) Hmm, I just tested it, and dither_cmyk4() produced multiple levels just fine for me. PS: I've got a canon-unprint tool but it's written in (quick'n'dirty) C++ -- if anyone is interested I can add it to the repository or maybe port it to C first. Go right ahead and add it. There's nothing wrong with this kind of thing being in C++. -- 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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X