Menu
▾
▴
gimp-print-devel
|
From: Raph L. <arc...@db...> - 2000-03-06 14:16:57
|
This message was sent from Geocrawler.com by "Raph Levien" <ra...@ac...> Be sure to reply to that address. Hi gimp print people, I've done quite a bit of work over the years on screening algorithms. I'm trying to push some of them for commercial licensing, see http://www.artofcode.com/eventone/ for details. To this end, I've been building a testbed that includes RGB->CMYK conversion and actual device driving. Thus, this work duplicates driver work in both GhostScript and gimp-print. So far, I have drivers for Epson Stylus Color Pro and Stylus Color 600. The code pushes both of these printers to the limit, achieving full 1440 x 720 resolution in the latter case. Not to overstate things, but the quality is incredible. It is dramatically better than the gs and gimp-print drivers, and, while I haven't done serious comparison yet with the bundled windows drivers, my guess is that it's comparable or slightly better. I want to do the right thing in terms of releasing this code as open source, but I'm moving cautiously on that right now. There are a number of companies who have stated that they're working on improving print quality (the VA - HP alliance and Corel come to mind), and I'd like to see if they can fund the project. In the meantime, I want to keep you guys in the loop. I am happy to give you guys the code to play around with, with the understanding that it is not yet free software, but will be at some date in the not too distant future. I talked to Peter Deutsch a few days ago, so he's up to speed as well. I've learned a lot by reading the gimp-print code. I think you might enjoy reading through my code. Among other things, I have _much_ simpler code for microweaving. At the moment, the code is specialized for the stc600 and needs to be parameterized a bit, but the entire Epson driver is 236 lines of code. Raph Geocrawler.com - The Knowledge Archive |
|
From: Thomas T. <tt...@bi...> - 2000-03-15 20:45:31
|
I have recently been thinking about how Ghostscript dither quality could
be improved. I came up with two major ideas.
My most recent idea was to use Floyd-Steinberg on the brightness of the
image. Instead of deciding per color when to print, decide on the basis
of total accumulated error. When that exceeds threshold, print the color
with the darkest error and distribute errors accordingly. In light tints
colors will not overlap any more, hopefully leading to smoother and
brighter results.
Example pseudocode:
For x,y in image:
While (Cyan[x,y]+Magenta[x,y]+Yellow[x,y]+Black[x,y]) > Threshold
Find the largest of Cyan[x,y] Magenta[x,y] Yellow[x,y] Black[x,y]
Print a dot in this color
ThisColor[x,y] -= dotsize # so we can exit the while loop
# the value is the error; it is
distributed over the neighboring pizels
ThisColor[x+1,y] += ThisColor[x,y] * 7/16
ThisColor[x-1,y-1] += ThisColor[x,y] * 3/16
ThisColor[x,y-1] += Thiscolor[x,y] * 5/16
ThisColor[x+1,y-1] += Thiscolor[x,y] * 1/16
I think this will give 3 times as many effective pixels for greyscale
images. Color is printed a bit less accurately, but the human eye
notices color variations less than variations in brightness. Manual
execution with a spreadsheet showed color dots not being printed on top
of each other, unless the total ink amount was so high that overlap was
needed. With per-color Floyd-Steinberg, the occasional 2 or 3 color
pixel shows up, and the interference patterns between the different ink
colors can show up as coarseness.
An older idea was to take dot overlap into account. If two dots are
printed adjacent to each other, they overlap. As a result the two dots
are not as dark as when they would have been printed a bit apart from
each other. I do not know if this is something that must be taken into
account: overlapping will only happen near full density and I doubt if
this modification does anything except change the tone curve somewhat.
Thomas Tonino
|
|
From: Robert L K. <rl...@al...> - 2000-03-16 00:40:13
|
I'm not sure if Thomas Tonino is on the list...I'm reading his message on geocrawler and I have comments on it. If he's not, could someone forward him the message? His email address doesn't appear in the archived message. It's an interesting approach. We're already suppressing color dots if any black dots are printed, and taking overall density into account when deciding whether to print light or dark inks (in darker areas we use less of the dark ink rather than more of the light ink). The grayscale transitions still have some problems, though. Actually, for grayscale we get something like 8 times as many dots, since C+M+Y is less than K. I once experimented with only allowing one dot to be printed if the density at that point was less than one. It didn't help too much. Any approach of this kind has to be very careful to avoid instability, as I learned to my sorrow a couple of releases ago. It wasn't showing up in any of my tests, but someone ran across a bug in one of the indexed modes where density wasn't being done, and the result was that there were a lot of full-strength pixels. The problem was that not enough ink was getting printed to discharge all of the error, and the built-up error got printed out in white areas very strangely. I wound up having to cap the accumulated error to avoid this. Even that's not perfect, which is why the line art mode uses much less color ink to print black (it's grainier but sharper -- that's not a contradiction, just ask any photographer who shoots Tri-X). BTW, something else that I've done, which seems to have done a lot to eliminate the diagonals so common with error diffusion, is to distribute the error over a variable number of pixels. Specifically, the lighter the tone, the broader the region over which the error is distributed. This seems counterintuitive, but consider that the inter-dot spacing is greater in pale areas, and we don't want the adjacent dots to wind up too close to the largest accumulated error (which will be just before a dot is printed in the current row). In darker areas, though, the dots are spaced closely together, so there's no need to worry about that, and we'd lose sharpness by spreading the error out too much. This is the other trick of line art vs. smooth tone vs. photograph mode that I play. Line art mode uses no spread at all on the assumption that sharpness is important and everything's going to be dark enough so that the squiggles won't show up. Smooth tone uses more spread, which reduces sharpness a little but results in smoother texture in pale areas. For photographs, ultimate sharpness of edges is normally less important, but good texture is more important. I've been experimenting with a few other dither variations. What we're doing right now is technically incorrect for anything but monochrome and four color. It works very well for six color single dot size (although the two-pass modes are somewhat ugly), but it's all wrong (in principle, maybe not in practice) for variable dot size. It also changes the dark/light mix at different density levels. However, the technically correct variants I came up with (one a relatively minor change and one not so minor) look pretty ugly. Go figure. The other oddity is that for light midtones the line art mode is smoother than photographic mode. That's because the line art mode is less random. The problem with it is that it simply doesn't deposit any ink at all in very light areas, so it's not very good for real continuous tones. So I tried experimenting with changing the randomness based on the -- 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: Robert L K. <rl...@al...> - 2000-03-06 23:52:00
|
Date: Mon, 6 Mar 2000 06:12:53 -0800
From: "Raph Levien" <arc...@db...>
I've done quite a bit of work over the years on screening
algorithms. I'm trying to push some of them for commercial
licensing, see http://www.artofcode.com/eventone/ for details.
Interesting.
Not to overstate things, but the quality is incredible. It is
dramatically better than the gs and gimp-print drivers, and, while
I haven't done serious comparison yet with the bundled windows
drivers, my guess is that it's comparable or slightly better.
Did you try 1440x720 highest quality? That gives markedly better
results than any of the other choices. It's still a randomized error
diffusion, though, so it still creates wormy artifacts. However, I'm
quite certain that it's not the last word in dithering algorithms :-)
In the meantime, I want to keep you guys in the loop. I am happy
to give you guys the code to play around with, with the
understanding that it is not yet free software, but will be at some
date in the not too distant future. I talked to Peter Deutsch a few
days ago, so he's up to speed as well.
For us to be able to use it it will have to be GPL. I notice that you
have a patent on some of this stuff, so that would have to be worked
out. However, this would certainly be very interesting to look at.
I've learned a lot by reading the gimp-print code. I think you
might enjoy reading through my code. Among other things, I have
_much_ simpler code for microweaving. At the moment, the code is
specialized for the stc600 and needs to be parameterized a bit, but
the entire Epson driver is 236 lines of code.
Well, this code is trying to support all of the different Epson
printers, so there's a good bit more complexity involved, particularly
with the quirky command sets different output modes we support...
--
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: Karl H. K. <kh...@kh...> - 2000-03-07 01:21:15
|
On Mon, Mar 06, 2000 at 06:12:53AM -0800, Raph Levien wrote: > This message was sent from Geocrawler.com by "Raph Levien" <ra...@ac...> =2E.. wait a minute, I know you! ... or at least I know what you did last summer :-) You were involved in gcmm, is this correct? I downloaded the last snapshot this week to see if I can use it in SANE. The print plugin could also benefit from some ICC routines to do the RGB->CMYK=20 transformation. I noticed that the project is pretty dormant since last year, is anybody using it? Are you planning to work on it any time soon? But now back to our actual subject: > I've done quite a bit of work over the years on > screening algorithms. I'm trying to push some of > them for commercial licensing, see > http://www.artofcode.com/eventone/ for details. This looks very interesting. You are however talking about multiple algorithms and you want to push some of them... Are there any good ones left that are=20 and will stay free? :-) >=20 > To this end, I've been building a testbed that > includes RGB->CMYK conversion and actual device I was looking into doing teh RGB->CMYK conversion based on ICC profiles. I just started reading about all things related to CMS systems. Can you either provide some=20 input or direct me to good literature. I was thinking about getting the Giorgianni/Madden book.=20 > Not to overstate things, but the quality is > incredible. It is dramatically better than the gs > and gimp-print drivers, and, while I haven't done > serious comparison yet with the bundled windows > drivers, my guess is that it's comparable or > slightly better. I did some one to one comparison of the print plugin and the Windows driver on the weekend, and even though the quality of Robert's code is quite good, it's still far=20 from what I can get under Windows. (Can I admit here=20 that I have vmware running just to print stuff?) > I want to do the right thing in terms of > releasing this code as open source, but I'm moving > cautiously on that right now. There are a number > of companies who have stated that they're working > on improving print quality (the VA - HP alliance > and Corel come to mind), and I'd like to see if > they can fund the project. You hold the patent to the algorighms (at least that's what I understand from reading your page), so you=20 should be free to license the stuff to open source projects free of charge, but still charge for other licensees. As Eric already mentioned, there is no better resumee for you than to put the code out in the open and use a project like Gimp or GhostScript as "bill board" for the algorithm. >=20 > In the meantime, I want to keep you guys in the > loop. I am happy to give you guys the code to play > around with, with the understanding that it is not > yet free software, but will be at some date in the > not too distant future. I talked to Peter Deutsch > a few days ago, so he's up to speed as well. I am with Eric here: Don't make it available until it's really free. If somebody walks up to you=20 tomorrow and offeres you a deal that's just too good to resist for the exclusive rights we would have a=20 problem.=20 >=20 > I've learned a lot by reading the gimp-print > code. I think you might enjoy reading through my > code. Among other things, I have _much_ simpler > code for microweaving. At the moment, the code is > specialized for the stc600 and needs to be > parameterized a bit, but the entire Epson driver > is 236 lines of code. The weaving code is IMHO not the problem. It is now stable enough to even work on my STC740 :-) So I would not tamper with it. If you can offer something in regards to the=20 error diffusion algorighm, this would help the quality of=20 the plugin more than anything else.=20 I hope we can work something out together. I'm looking forward to hearing some great news from you, Karl Heinz --=20 Karl Heinz Kremer kh...@kh... http://www.khk.net |
|
From: Raph L. <ra...@ac...> - 2000-03-07 02:49:35
|
Karl Heinz Kremer wrote: > > On Mon, Mar 06, 2000 at 06:12:53AM -0800, Raph Levien wrote: > > This message was sent from Geocrawler.com by "Raph Levien" <ra...@ac...> > > ... wait a minute, I know you! ... or at least I know what you > did last summer :-) > > You were involved in gcmm, is this correct? I downloaded the last > snapshot this week to see if I can use it in SANE. The print plugin > could also benefit from some ICC routines to do the RGB->CMYK > transformation. I noticed that the project is pretty dormant since > last year, is anybody using it? Are you planning to work on it any > time soon? Yep, that's the same me. I'm not working on the gcmm code any more because Graeme Gill's libicc is a lot farther along and would appear to kick ass. Of course I've thought about using ICC to do the RGB->CMYK. Let me present a few arguments against that: 1. The patent situation with ICC is murky at best. EFI owns a large stable of patents on "color management" and is eagerly enforcing them. 2. There are no free tools for creating ICC profiles. Creating good ICC profiles is hard. 3. ICC is a tad underspecified. It doesn't really address the issue of gamut compression at all, particularly the black point. Common usage is for there to be multiple cubes - the "absolute" one gives results with absolute colorimetry, and if you specify a shade darker than the actual black point of the output device, it clips. The "perceptual" one maps [0..1] to the actual gamut of the printer, but the amount and type of compression of hue and saturation is left unspecified. Grame talks about this a bit more in his "the trouble with ICC" page. 4. ICC is not very robust. If you carefully create a profile for a printer, then move that profile to a different unit of the same model, or change paper, you basically get the positive effects of the new printer plus the negative effects of the corrections for the old one. Thus, it's quite easy to misapply ICC and get poor results. Basically, the way I'd do it (and will do it if I get any bites) is to do it the way big prepress color scanners did it in the '70s, which is a big bunch of knobs. You have some global controls for dot gain, highlight/midtone/shadow +/- for gray balance (so the CMY overprint gets calibrated to the same hue as K), then highlight/midtone/shadow +/- for each of RYGCBM colors. The idea is that any reasonably skilled person could calibrate a printer pretty well by getting a Kodak Q60 card and fiddling with the knobs until it looks pretty close. (See http://www.halftone.co.uk/tech/filmscan/overview.htm for a bit more info on the Q60). > But now back to our actual subject: Indeed. > > I've done quite a bit of work over the years on > > screening algorithms. I'm trying to push some of > > them for commercial licensing, see > > http://www.artofcode.com/eventone/ for details. > > This looks very interesting. You are however talking > about multiple algorithms and you want to push some > of them... Are there any good ones left that are > and will stay free? :-) > > To this end, I've been building a testbed that > > includes RGB->CMYK conversion and actual device > > I was looking into doing teh RGB->CMYK conversion based > on ICC profiles. I just started reading about all things > related to CMS systems. Can you either provide some > input or direct me to good literature. I was thinking > about getting the Giorgianni/Madden book. I haven't found any really good references. I don't have the G/M book, but from the Amazon description, it looks like it would be worth getting. > > Not to overstate things, but the quality is > > incredible. It is dramatically better than the gs > > and gimp-print drivers, and, while I haven't done > > serious comparison yet with the bundled windows > > drivers, my guess is that it's comparable or > > slightly better. > > I did some one to one comparison of the print plugin and > the Windows driver on the weekend, and even though the > quality of Robert's code is quite good, it's still far > from what I can get under Windows. (Can I admit here > that I have vmware running just to print stuff?) Right. Incidentally, I have been running the stc600 in 1440x720 highest quality. > > I want to do the right thing in terms of > > releasing this code as open source, but I'm moving > > cautiously on that right now. There are a number > > of companies who have stated that they're working > > on improving print quality (the VA - HP alliance > > and Corel come to mind), and I'd like to see if > > they can fund the project. > > You hold the patent to the algorighms (at least that's > what I understand from reading your page), so you > should be free to license the stuff to open source > projects free of charge, but still charge for other > licensees. As Eric already mentioned, there is no > better resumee for you than to put the code out in > the open and use a project like Gimp or GhostScript > as "bill board" for the algorithm. Right. And I plan to release the code under GPL and the patent under a license that allows all GPL software to use it freely. The only question is the timing. If I can get somebody to fund development as GPL software, it will happen quickly. Otherwise, it will happen more slowly. > > In the meantime, I want to keep you guys in the > > loop. I am happy to give you guys the code to play > > around with, with the understanding that it is not > > yet free software, but will be at some date in the > > not too distant future. I talked to Peter Deutsch > > a few days ago, so he's up to speed as well. > > I am with Eric here: Don't make it available until > it's really free. If somebody walks up to you > tomorrow and offeres you a deal that's just too good > to resist for the exclusive rights we would have a > problem. I think this is a very reasonable approach for you guys, actually. > > I've learned a lot by reading the gimp-print > > code. I think you might enjoy reading through my > > code. Among other things, I have _much_ simpler > > code for microweaving. At the moment, the code is > > specialized for the stc600 and needs to be > > parameterized a bit, but the entire Epson driver > > is 236 lines of code. > > The weaving code is IMHO not the problem. It is now stable > enough to even work on my STC740 :-) So I would not tamper > with it. If you can offer something in regards to the > error diffusion algorighm, this would help the quality of > the plugin more than anything else. Right. If it ain't broke, don't fix it :) > I hope we can work something out together. I'm looking > forward to hearing some great news from you, Me too. I'm going to do what I can to get the GPL licensing issue resolved quickly. I'm eager to get the cool stuff out there in the field! Raph |
|
From: Robert L K. <rl...@al...> - 2000-03-07 04:13:15
|
Date: Mon, 06 Mar 2000 18:43:47 -0800 From: Raph Levien <ra...@ac...> Basically, the way I'd do it (and will do it if I get any bites) is to do it the way big prepress color scanners did it in the '70s, which is a big bunch of knobs. You have some global controls for dot gain, highlight/midtone/shadow +/- for gray balance (so the CMY overprint gets calibrated to the same hue as K), then highlight/midtone/shadow +/- for each of RYGCBM colors. That's more or less what's going on with us -- there are a whole bunch of knobs (at least internal to the dither engine -- none of them are brought out to the end user, although there is an API). The particular controls that are in there are different, but this kind of "cut & try" seems like the right thing. There are so many different kinds of paper, so many different kinds of ink, so many different cloggednesses of print heads, that trying to get too scientific is going to be difficult. > I did some one to one comparison of the print plugin and > the Windows driver on the weekend, and even though the > quality of Robert's code is quite good, it's still far > from what I can get under Windows. (Can I admit here > that I have vmware running just to print stuff?) Right. Incidentally, I have been running the stc600 in 1440x720 highest quality. That's what you get from someone who buys a Photo EX from a friend and then realizes that he has to somehow get it working under Linux, and then finds some code floating around and h4X0rz away on it :-) :-) :-) I've never even seen a 600. However, the EX has a sufficiently compatible printhead that I can use the 600 driver, and it certainly does leave something to be desired. The EX output is, I daresay, somewhat better. Big surprise. > You hold the patent to the algorighms (at least that's what I > understand from reading your page), so you should be free to > license the stuff to open source projects free of charge, but > still charge for other licensees. As Eric already mentioned, > there is no better resumee for you than to put the code out in > the open and use a project like Gimp or GhostScript as "bill > board" for the algorithm. Right. And I plan to release the code under GPL and the patent under a license that allows all GPL software to use it freely. The only question is the timing. If I can get somebody to fund development as GPL software, it will happen quickly. Otherwise, it will happen more slowly. The flip side is that people like VA and Red Hat want to actually see something before they're going to fund it. Feeding code into the Gimp plugin that's significantly better than anything else out there, and having it just plug into Ghostscript, and working towards a real free print system (Ghostscript isn't enough -- it's a decent back end, but there needs to be a front end and middleware) is something that might catch people's attention. > The weaving code is IMHO not the problem. It is now stable > enough to even work on my STC740 :-) So I would not tamper > with it. If you can offer something in regards to the > error diffusion algorighm, this would help the quality of > the plugin more than anything else. Right. If it ain't broke, don't fix it :) Yeah, except when I get some damn fool idea to clean it up and usually break something in the process. Nobody's complained since my last round of commits, so it's possible that I got most of the stuff right, except for the handful of obscure bugs I found and fixed tonight. Although it's at the point where I'm dead scared to actually touch anything in the weave calculation per se :-( There is a unit test for it, though. > I hope we can work something out together. I'm looking > forward to hearing some great news from you, Me too. I'm going to do what I can to get the GPL licensing issue resolved quickly. I'm eager to get the cool stuff out there in the field! I'd definitely like to help you out somehow, as long as the end result is that we have something we can put in our GPL'ed stuff. -- 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