Menu
▾
▴
gimp-print-devel
|
From: <sh...@al...> - 2000-01-25 13:59:48
|
> The good news is that I just checked in preliminary support for the > 750 last night. It probably won't actually work, but it's not > impossible that it will "just work" out of the can. It generates > lexically correct commands, but it's possible that the arguments > aren't entirely correct or that the mixture of old (700/EX vintage) > and new commands will not work either. But give it a try. I'll see what I can do. There's one small hitch that I didn't mention in my past message. The printer is at home and I'm currently at work. (That may sound like a strange thing to call a hitch, but, in high energy physics these two are often quite distant. About 7000 miles in my case.) There's a lot I can do remotely, but, it has some limitations. My wife is home and she uses the printer (actually, I bought the printer for her, I'm just trying to get her to use Linux more) so I'll be doing most of my testing through her. I was figuring that it would take me some time to get a lot of the details of color space conversions correct, so I was starting now in the hopes of having a working but untuned version by the time I got home. > Henryk Richter (whom I hope subscribes to the list shortly) ported the > 3.0.5 version of the plugin (or at least the Epson piece) to > Ghostscript. Gee you guys work fast. According to your home page that hasn't been done yet! > It doesn't entirely work yet; there are some problems > with static variables (mine, not his) with more than one output page, > but we should be able to fix that fairly quickly. When that's fixed > up Henryk or I will post it to the project. Ok, so, what's left to do? Since you guys obviously have a huge lead on me, at this point I think I should drop back and put what resources I have under your disposal. I'm primarily a coder (sorry, I'm not really interested in improving the web page) so if there's anything that you want coded or debugged please let me know. Eric |
|
From: Karl H. K. <kh...@kh...> - 2000-01-25 14:15:35
|
sh...@al... said: [ ... ] > my past message. The printer is at home and I'm currently at work. (That > may sound like a strange thing to call a hitch, but, in high energy physics > these two are often quite distant. About 7000 miles in my case.) There's > a lot I can do remotely, but, it has some limitations. My wife is That's no problem, just get yourself an Epson scanner and hook it up to the printer so that you can view every page the printer produces. Did I mention that I maintain the Sane Epson backend :-) Karl Heinz |
|
From: <sh...@al...> - 2000-01-25 14:44:35
|
> That's no problem, just get yourself an Epson scanner and hook it > up to the printer so that you can view every page the printer > produces. Did I mention that I maintain the Sane Epson backend :-) Unfortunately our current scanner is unsupported as well. :( I guess I'll have to have her put the digital camera in front of the printer and run the serial line from the camera to the server. I can snap photos remotely using gphoto. :) Eric |
|
From: <sh...@al...> - 2000-01-25 15:15:44
|
> 4) If you know dithering or color space theory, and you're eager to do > some gnarly low level stuff, that's also useful. I do gnarly low level stuff best. I'll look into it, but I have to be up early tomorrow, so, not tonight. I don't have a lot of experience here, but I've read up on the publicly available documentation on the web and I have the CIElab coordinate measurements of the inks used in the ESP750. I don't know if these are used in the current print plugin or not. Eric |
|
From: Robert L K. <rl...@al...> - 2000-01-25 15:27:08
|
From: sh...@al... Date: Wed, 26 Jan 2000 00:14:49 +0900 > 4) If you know dithering or color space theory, and you're eager to do > some gnarly low level stuff, that's also useful. I do gnarly low level stuff best. I'll look into it, but I have to be up early tomorrow, so, not tonight. OK. I don't have a lot of experience here, but I've read up on the publicly available documentation on the web and I have the CIElab coordinate measurements of the inks used in the ESP750. I don't know if these are used in the current print plugin or not. They're not, but that would be useful information. Currently there's some weird ratio stuff going on. That would best be replaced by actual data. The other thing that's wrong is that those ratios are hardcoded, so printers with different inks won't do the right thing. The right thing is for there to be an initialization/free routine for each dithering routine that is called by the printer driver. That would go a long way to fixing the static variable problem. The init routine should return an opaque handle (i. e. pointer) to an object specific to each class of dither routine that contains all the information required by that routine (including the error rows and all that). Another change I would like to see done is in the dataflow between the driver and the dither routine. Currently the driver presents the dither routine a line of input and an output line that must be filled in. I would prefer that the dither routine initialization routine take a callback from the driver, so that the dither routine can process as many lines as it likes before actually outputting anything. This would allow us to use more sophisticated dithering routines. Interested in this 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... "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton |
|
From: <sh...@al...> - 2000-01-26 04:43:13
|
> I don't have a lot of experience here, but I've read up on the
> publicly available documentation on the web and I have the CIElab
> coordinate measurements of the inks used in the ESP750. I don't
> know if these are used in the current print plugin or not.
>
> They're not, but that would be useful information. Currently there's
> some weird ratio stuff going on. That would best be replaced by
> actual data.
I won't mention how I got this information since it's not available in
Epson level 1 programming documents. I normally like to give credit where
credit is due, but, in this case, it may be better not to.
Here are the numbers:
(for 720 DPI on plain paper)
Color L A B
------------- ------ ------ ------
White 90.71 1.12 -4.37
Cyan 52.40 -26.85 -39.29
Magenta 55.56 61.60 -3.79
Yellow 84.35 2.77 68.90
Black 27.67 1.30 -0.76
Light Cyan 67.69 -28.57 -31.96
Light Magenta 66.63 46.71 -11.90
(Note to Epson Corporate types trolling the net: The message I wrote
earlier listing the people I had contacted on this topic was *not* a
complete list. (Ok, this DVD case is making me a little paranoid...))
It remains to be seen whether the "correct" color transforms will actually
improve results over more trial and error methods. Reading the documents
on color transforms, it seems that there is still a lot of trial and
error involved in color science.
> The other thing that's wrong is that those ratios are hardcoded, so
> printers with different inks won't do the right thing. The right
> thing is for there to be an initialization/free routine for each
> dithering routine that is called by the printer driver.
That doesn't sound hard to fix.
> Interested in this stuff?
Yes. I'll take a crack at it later this evening.
Do you have any guidelines for CVS commissions? I gather that since I'm now
a registered developer, I have commission privileges, but some project
leaders I know prefer to approve each patch individually before commission.
Eric
|
|
From: Karl H. K. <kh...@kh...> - 2000-01-26 12:10:06
|
On Wed, Jan 26, 2000 at 01:41:13PM +0900, sh...@al... wr=
ote:
>=20
> (for 720 DPI on plain paper)
>=20
> Color L A B
> ------------- ------ ------ ------
> White 90.71 1.12 -4.37
> Cyan 52.40 -26.85 -39.29
> Magenta 55.56 61.60 -3.79
> Yellow 84.35 2.77 68.90
> Black 27.67 1.30 -0.76
> Light Cyan 67.69 -28.57 -31.96
> Light Magenta 66.63 46.71 -11.90
>=20
> (Note to Epson Corporate types trolling the net: The message I wrote
> earlier listing the people I had contacted on this topic was *not* a
> complete list. (Ok, this DVD case is making me a little paranoid...))
>=20
Isn't this information that could also be gathered using a spectrometer?
If I just print certain color and meassure, this should give me all
the tables for all the printers that I have access to.
In gerneral: Did you see the news regarding HP and VA working together
to improve the printing under Linux. This is good news, and maybe this
could also be the trigger to get Epson and other manufacturers on board.
Does anybody know any addresses (email or snailmail) where we could
complain/suggest about Linux support.
Karl Heinz
--=20
Karl Heinz Kremer kh...@kh...
http://www.khk.net
ICQ: 41190739
|
|
From: Robert L K. <rl...@al...> - 2000-01-26 13:24:43
|
Date: Wed, 26 Jan 2000 07:09:03 -0500 From: Karl Heinz Kremer <kh...@kh...> In gerneral: Did you see the news regarding HP and VA working together to improve the printing under Linux. This is good news, and maybe this could also be the trigger to get Epson and other manufacturers on board. That's very interesting. I know SuSE is also working with one of the major printer vendors, but its name escapes me (either Lexmark or Canon, I think). So maybe we should see if anyone at Red Hat or Caldera might have contacts at Epson. Does anybody know any addresses (email or snailmail) where we could complain/suggest about Linux support. I've tried contacting Epson tech support; thus far it's dropped into a black hole. Is anyone here any good at web site development? Having a more professional-looking web site would help when contacting vendors. -- 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... "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton |
|
From: Robert L K. <rl...@al...> - 2000-01-26 13:15:38
|
From: sh...@al... Date: Wed, 26 Jan 2000 13:41:13 +0900 It remains to be seen whether the "correct" color transforms will actually improve results over more trial and error methods. Reading the documents on color transforms, it seems that there is still a lot of trial and error involved in color science. Then there's the whole matter of paper types, and third party inks, and all that. 720 DPI on plain paper isn't what I consider a terribly interesting case for the Gimp (it's a very interesting case for *business* graphics, and since we're looking at generalizing this, we do have to take that into account). Even proofing from the Gimp will normally be on higher quality paper. I think. > The other thing that's wrong is that those ratios are hardcoded, so > printers with different inks won't do the right thing. The right > thing is for there to be an initialization/free routine for each > dithering routine that is called by the printer driver. That doesn't sound hard to fix. It shouldn't be too bad; what's a bit tricky is the sheer number of ratios there are and finding all of the places where they're implicitly hidden (such as the conversion between CMY and K). > Interested in this stuff? Yes. I'll take a crack at it later this evening. Do you have any guidelines for CVS commissions? I gather that since I'm now a registered developer, I have commission privileges, but some project leaders I know prefer to approve each patch individually before commission. Yes, all the registered developers do have write access to the repository. At this point in time I'd like to be fairly free about it. It's an absolute given that it must compile without any new warnings. If you have a printer that you can test on, please conduct some kind of sanity test. When we get closer to a release I'd like to tighten things up a bit (each commit should be reviewed by at least one other developer), but it's too early for that yet. I do have significant release engineering experience, and I'm not worried about keeping this sane. Late in the release cycle, normal policy would be that each commit should be preceded by a full test run. For obvious reasons, that's not practical here, so we'll have to improvise. Right now there are only about five of us, and I think we can keep things under control. -- 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... "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton |
|
From: Robert L K. <rl...@al...> - 2000-01-26 14:08:22
|
From: sh...@al... Date: Wed, 26 Jan 2000 13:41:13 +0900 > I don't have a lot of experience here, but I've read up on the > publicly available documentation on the web and I have the CIElab > coordinate measurements of the inks used in the ESP750. I don't > know if these are used in the current print plugin or not. > > They're not, but that would be useful information. Currently there's > some weird ratio stuff going on. That would best be replaced by > actual data. I won't mention how I got this information since it's not available in Epson level 1 programming documents. I normally like to give credit where credit is due, but, in this case, it may be better not to. I want to be very careful about information obtained from questionable sources, particularly this kind of very specific info. I don't have a problem with people using information reverse engineered out of print files. For example, if you print a uniform color patch from Windows, and then disassemble the generated output to determine how much of each color was used, that's fine by me. Likewise, the spectrometer idea. If someone under NDA (who you had good reason to believe was under NDA) told you something that you had good reason to believe was under NDA (e. g. he or she told you), then stay away from it. -- 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... "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton |
|
From: Andy T. <th...@ph...> - 2000-01-26 15:16:29
|
Robert L Krawitz wrote: > I want to be very careful about information obtained from questionable > sources, particularly this kind of very specific info. I don't have a > problem with people using information reverse engineered out of print > files. For example, if you print a uniform color patch from Windows, > and then disassemble the generated output to determine how much of > each color was used, that's fine by me. Likewise, the spectrometer > idea. If someone under NDA (who you had good reason to believe was > under NDA) told you something that you had good reason to believe was > under NDA (e. g. he or she told you), then stay away from it. I'm currently disassembling a bunch of canon-print files to get the canon part of the print plugin working. The color pattern I'm printing contains 8 intensity levels each for CMYKRGB. Is this amount of colors sufficient for producing color-transfer information or would we need more? Are there any standard methods for reverse engineering color-management data? Any tools for extracting the data from the print files? I've started to work on one for the canon stuff but would happily use an existing one ;-) Andy |
|
From: Robert L K. <rl...@al...> - 2000-01-27 01:35:39
|
Date: Wed, 26 Jan 2000 16:18:53 +0100 From: Andy Thaller <th...@ph...> The color pattern I'm printing contains 8 intensity levels each for CMYKRGB. Is this amount of colors sufficient for producing color-transfer information or would we need more? Are there any standard methods for reverse engineering color-management data? Any tools for extracting the data from the print files? I've started to work on one for the canon stuff but would happily use an existing one ;-) Try grabbing http://www.tiac.net/users/rlk/colors.tif. This is a color sweep pattern that I found extremely useful. -- 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... "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton |
|
From: Karl H. K. <kh...@kh...> - 2000-01-26 13:32:54
|
Robert L Krawitz <rl...@al...> said: [ ... ] > I've tried contacting Epson tech support; thus far it's dropped into a > black hole. I'm also still waiting for a response from Epson. I just hope that this HP/VA announcement is a wakeup call for the rest of the manufacturers. By now they should now that if you advertise Linux support your stock price goes through the roof :-) Karl Heinz |
|
From: <sh...@al...> - 2000-01-26 16:31:03
|
> I won't mention how I got this information since it's not available in > Epson level 1 programming documents. I normally like to give credit where > credit is due, but, in this case, it may be better not to. > > I want to be very careful about information obtained from questionable > sources, particularly this kind of very specific info. I don't have a > problem with people using information reverse engineered out of print > files. For example, if you print a uniform color patch from Windows, > and then disassemble the generated output to determine how much of > each color was used, that's fine by me. What's fine by you is largely irrelevant, however. What matters is what's fine by Epson (which determines if a suit gets filed) and what's fine by the courts (which decide who wins the suit). I downloaded their current W95 driver a few days ago, and I read the click license before downloading it. It specifically states that reverse engineering is not allowed. Although I did download it, I have not installed it, specifically because of this very problem. > Likewise, the spectrometer > idea. If someone under NDA (who you had good reason to believe was > under NDA) told you something that you had good reason to believe was > under NDA (e. g. he or she told you), then stay away from it. Why? If someone is under NDA and tells someone else who is not under NDA, then those people under NDA are not liable for anything. It's the same issue as was raised in the DVD case when the MPAA tried to claim CSS was a trade secret. They could get the guy who cracked it, but, once it was given to "an innocent" it was no longer protected. The MPAA quickly changed their position, saying that the code would promote further copyright violations. I can't see how Epson could claim that about the ink colors. Anyway, his or her words justifying this release were "you can get these yourself with the right equipment, so they aren't strictly covered by the NDA", but it's enough of a grey area that I don't feel comfortable mentioning just who he or she is. But, I think using this information is legally safer than printing color blocks with the windows driver. I'm not a lawyer, though. Two days ago I sent a message to Epson tech support asking for clarifications on what activities would likely result in legal retaliation. Other than the auto-responder, I have not heard back from them yet. Eric |
|
From: Robert L K. <rl...@al...> - 2000-01-27 01:30:42
|
From: sh...@al... Date: Thu, 27 Jan 2000 01:30:03 +0900 > I want to be very careful about information obtained from > questionable sources, particularly this kind of very specific > info. I don't have a problem with people using information > reverse engineered out of print files. For example, if you print > a uniform color patch from Windows, and then disassemble the > generated output to determine how much of each color was used, > that's fine by me. What's fine by you is largely irrelevant, however. What matters is what's fine by Epson (which determines if a suit gets filed) and what's fine by the courts (which decide who wins the suit). That's quite true. I should think that unless they claim copyright over the output files, or that someone is not allowed to give someone else an output file, that it would be a bit harder for them to go after someone for disassembling the output file. I downloaded their current W95 driver a few days ago, and I read the click license before downloading it. It specifically states that reverse engineering is not allowed. Although I did download it, I have not installed it, specifically because of this very problem. I don't want to touch the Epson drivers for exactly this reason. I haven't downloaded it or looked at any license. > Likewise, the spectrometer idea. If someone under NDA (who you > had good reason to believe was under NDA) told you something that > you had good reason to believe was under NDA (e. g. he or she > told you), then stay away from it. Why? If someone is under NDA and tells someone else who is not under NDA, then those people under NDA are not liable for anything. It's the same issue as was raised in the DVD case when the MPAA tried to claim CSS was a trade secret. They could get the guy who cracked it, but, once it was given to "an innocent" it was no longer protected. The MPAA quickly changed their position, saying that the code would promote further copyright violations. I can't see how Epson could claim that about the ink colors. The MPAA still seems to be trying to claim trade secret violation, last I checked. -- 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... "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton |
|
From: <sh...@al...> - 2000-01-27 01:54:11
|
> That's quite true. I should think that unless they claim copyright > over the output files, or that someone is not allowed to give someone > else an output file, that it would be a bit harder for them to go > after someone for disassembling the output file. I don't think so. Although you are disassembling the output, and not disassembling the driver, you are reverse engineering the driver not the output. The output is already understood. Since the driver is licensed to you under a license which forbids reverse engineering the driver (a much more broad term than disassembly or decompilation), such activity terminates the license. At this point you no longer have a license for the driver, so any further use of the driver is a violation of copyright. At least, that's what Epson might say. I suppose, in theory you could print out a whole bunch of test patterns, delete the driver, and then begin the reverse engineering. Since you've legally downloaded the driver, used the driver to produce output files, and then terminated your license by deleting the copyrighted software, you can't be held for copyright violation, since at the time you possessed the software you had a valid license, and at the time you reverse engineered it you did not have a copy. There may be a loophole in that loophole, though. Eric |
|
From: Robert L K. <rl...@al...> - 2000-01-27 02:36:20
|
From: sh...@al... Date: Thu, 27 Jan 2000 10:53:04 +0900 > That's quite true. I should think that unless they claim copyright > over the output files, or that someone is not allowed to give someone > else an output file, that it would be a bit harder for them to go > after someone for disassembling the output file. I don't think so. Although you are disassembling the output, and not disassembling the driver, you are reverse engineering the driver not the output. The output is already understood. No, the output isn't understood yet. You don't care how the driver operates; it's a matter of how the printer operates. Consider that there are free programs around that can read Word or Excel files and nobody has gone after them. Until and unless someone consults a competent lawyer in the US, I would like everyone to observe the following principles: 1) Any specific information obtained from someone you have reason to believe has signed a relevant NDA, and that that information is likely to be covered by the NDA, should not be used here. That definitely includes CIE values, which are about as important a trade secret as a printer manufacturer would have. If the information is merely of the form "Page X of the publicly available programming manual covers this" that's fine. If it's a gray area, stay away. In the particular case, I do not want the CIE values for the Epson inks used in the program. Whether you're legally in the clear or not notwithstanding (and I don't think you are, necessarily), violating an NDA is simply a dishonorable thing to do. 2) Any such information obtained by independent methods (e. g. by means of a spectrometer, or if someone who you have no reason to believe is under NDA gives you values that s/he says are obtained by independent means) is legitimate. But don't try to cut corners here. 3) Information obtained by examination of output (either output files or actual printed output) can be used as freely as you consider appropriate. If you want to try to reverse engineer the dithering algorithms (beyond just the command sequences required), and a friend gives you a printout, and you use a loupe to inspect the paper, that's completely kosher (I'd have real trouble believing that your friend is violating any agreement by giving you a printed photo that s/he has rights to, and so ordinary copyright applies: if you own the photo, you can do as you please; if someone else owns the rights to the photo, you need permission from that person). 4) Information obtained by disassembling code or any files supplied by the manufacturer is out of bounds. If someone can document that disassembling output files generated from data that you legally possess for purposes of interoperability has been found in violation of anything, I will reconsider (3). Beyond that, it's not a matter of legalities or not, it's a matter of what I consider an honorable thing to do. I will discuss this in personal email, but I do not want further debate on it on the list unless someone has actual expert legal opinion to offer. I want to concentrate on the driver, not on the law. -- 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... "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton |
|
From: <sh...@al...> - 2000-01-27 02:47:13
|
> > Color L A B > > ------------- ------ ------ ------ > > White 90.71 1.12 -4.37 > > Cyan 52.40 -26.85 -39.29 > > Magenta 55.56 61.60 -3.79 > > Yellow 84.35 2.77 68.90 > > Black 27.67 1.30 -0.76 > > Light Cyan 67.69 -28.57 -31.96 > > Light Magenta 66.63 46.71 -11.90 > > > > Isn't this information that could also be gathered using a spectrometer? Actually a spectrometer, if I had one, would give much more information. Unfortunately, with subtractive color systems it's not possible to know, given the colors of the inks, what the colors of the mixtures will be. You need the whole spectrograph in order to accurately predict this. I don't have that information. Eric |
|
From: Andy T. <th...@ph...> - 2000-01-27 08:41:07
|
sh...@al... wrote: > Actually a spectrometer, if I had one, would give much more information. > > Unfortunately, with subtractive color systems it's not possible to know, > given the colors of the inks, what the colors of the mixtures will be. > You need the whole spectrograph in order to accurately predict this. I don't > have that information. Is a spectrometer really needed? Wouldn't a (more or less) calibrated scanner do? Of course it wouldn't yield full spectral information but how much of it is really needed for color management? Could someone please post some URLs where to get basic information? Andy. |
|
From: <sh...@al...> - 2000-01-27 13:03:56
|
> Is a spectrometer really needed? Wouldn't a (more or less) calibrated scanner > do? The short answer is no. This is from the Color FAQ: 13. DOES MY SCANNER USE THE CIE SPECTRAL CURVES? Probably not. Scanners are most often used to scan images such as color photographs and color offset prints that are already "records" of three components of color information. The usual task of a scanner is not spectral analysis but extraction of the values of the three components that have already been recorded. Narrowband filters are more suited to this task than filters that adhere to the principles of colorimetry. If you place on your scanner an original colored object that has "original" SPDs that are not already a record of three components, chances are your scanner will not very report accurate RGB values. This is because most scanners do not conform very closely to CIE standards. > Of course it wouldn't yield full spectral information but how much of it is > really needed for color management? Excerpted from question 24: Practical photographic dyes and offset printing inks have spectral absorption curves that overlap significantly. Most magenta dyes absorb mediumwave (green) light as expected, but incidentally absorb about half that amount of shortwave (blue) light. If reproduction of a color, say brown, requires absorption of all shortwave light then the incidental absorption from the magenta dye is not noticed. But for other colors, the "one minus RGB" formula produces mixtures with much less blue than expected, and therefore produce pictures that have a yellow cast in the mid tones. Similar but less severe interactions are evident for the other pairs of practical inks and dyes. Due to the spectral overlap among the colorants, converting CMY using the "one-minus-RGB" method works for applications such as business graphics where accurate color need not be preserved, but the method fails to produce acceptable color images. Multiplicative mixture in a CMY system is mathematically nonlinear, and the effect of the unwanted absorptions cannot be easily analyzed or compensated. The colors that can be mixed from a particular set of CMY primaries cannot be determined from the colors of the primaries themselves, but are also a function of the colors of the sets of combinations of the primaries. > Could someone please post some URLs where to > get basic information? Start here: http://www.inforamp.net/~poynton/ColorFAQ.html Eric |
|
From: Robert L K. <rl...@al...> - 2000-01-25 14:18:34
|
From: sh...@al... Date: Tue, 25 Jan 2000 22:58:50 +0900 I was figuring that it would take me some time to get a lot of the details of color space conversions correct, so I was starting now in the hopes of having a working but untuned version by the time I got home. Tuning the color and dithering stuff in general is a real pain in the patooie. Anyone else who wants to have a crack at it is welcome :-) > Henryk Richter (whom I hope subscribes to the list shortly) ported the > 3.0.5 version of the plugin (or at least the Epson piece) to > Ghostscript. Gee you guys work fast. According to your home page that hasn't been done yet! Well, partly I don't update my home page very often, and partly it isn't complete yet... > It doesn't entirely work yet; there are some problems > with static variables (mine, not his) with more than one output page, > but we should be able to fix that fairly quickly. When that's fixed > up Henryk or I will post it to the project. Ok, so, what's left to do? Since you guys obviously have a huge lead on me, at this point I think I should drop back and put what resources I have under your disposal. I'm primarily a coder (sorry, I'm not really interested in improving the web page) so if there's anything that you want coded or debugged please let me know. Check out the development roadmap on the project page (it's in the News section in the bottom right). There are a number of things that I think would be useful: 1) Do a proper Configure script, so that it can be built standalone. 2) The UI and gimp interface (print.c) is a real mess, and desperately needs a cleanup. 3) It sounds like you're an Epson type, so I won't mention support for other vendors' printers, but that's always useful. 4) If you know dithering or color space theory, and you're eager to do some gnarly low level stuff, that's also useful. -- 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... "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