lcms-user Mailing List for Little cms color engine (Page 170)
An ICC-based CMM for color management
Brought to you by:
mm2
You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
(15) |
Jun
(24) |
Jul
(9) |
Aug
(14) |
Sep
|
Oct
(12) |
Nov
(17) |
Dec
(31) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(34) |
Feb
(7) |
Mar
(7) |
Apr
(16) |
May
(4) |
Jun
(14) |
Jul
(34) |
Aug
(54) |
Sep
(11) |
Oct
(25) |
Nov
(1) |
Dec
(6) |
2003 |
Jan
(27) |
Feb
(54) |
Mar
(23) |
Apr
(68) |
May
(82) |
Jun
(36) |
Jul
(45) |
Aug
(45) |
Sep
(49) |
Oct
(30) |
Nov
(65) |
Dec
(23) |
2004 |
Jan
(52) |
Feb
(52) |
Mar
(35) |
Apr
(38) |
May
(93) |
Jun
(22) |
Jul
(51) |
Aug
(50) |
Sep
(73) |
Oct
(28) |
Nov
(30) |
Dec
(51) |
2005 |
Jan
(22) |
Feb
(79) |
Mar
(38) |
Apr
(51) |
May
(95) |
Jun
(60) |
Jul
(56) |
Aug
(49) |
Sep
(22) |
Oct
(43) |
Nov
(15) |
Dec
(40) |
2006 |
Jan
(51) |
Feb
(31) |
Mar
(37) |
Apr
(25) |
May
(9) |
Jun
(13) |
Jul
(17) |
Aug
(66) |
Sep
(7) |
Oct
(12) |
Nov
(14) |
Dec
(31) |
2007 |
Jan
(18) |
Feb
(9) |
Mar
(22) |
Apr
(18) |
May
(5) |
Jun
(25) |
Jul
(2) |
Aug
(15) |
Sep
(12) |
Oct
(40) |
Nov
(10) |
Dec
(23) |
2008 |
Jan
(21) |
Feb
(56) |
Mar
(12) |
Apr
(23) |
May
(47) |
Jun
(75) |
Jul
(24) |
Aug
(2) |
Sep
(7) |
Oct
(26) |
Nov
(20) |
Dec
(16) |
2009 |
Jan
(14) |
Feb
(1) |
Mar
(29) |
Apr
(54) |
May
(18) |
Jun
(16) |
Jul
(5) |
Aug
(3) |
Sep
(38) |
Oct
(6) |
Nov
(25) |
Dec
(28) |
2010 |
Jan
(11) |
Feb
(26) |
Mar
(2) |
Apr
(10) |
May
(45) |
Jun
(94) |
Jul
(11) |
Aug
(32) |
Sep
(18) |
Oct
(37) |
Nov
(19) |
Dec
(34) |
2011 |
Jan
(21) |
Feb
(16) |
Mar
(16) |
Apr
(29) |
May
(17) |
Jun
(18) |
Jul
(7) |
Aug
(21) |
Sep
(10) |
Oct
(7) |
Nov
(15) |
Dec
(6) |
2012 |
Jan
(13) |
Feb
(16) |
Mar
(15) |
Apr
(12) |
May
(15) |
Jun
(31) |
Jul
(22) |
Aug
(15) |
Sep
(46) |
Oct
(21) |
Nov
(15) |
Dec
(33) |
2013 |
Jan
(19) |
Feb
(17) |
Mar
(31) |
Apr
(17) |
May
(27) |
Jun
(24) |
Jul
(26) |
Aug
(11) |
Sep
(9) |
Oct
(22) |
Nov
(14) |
Dec
(16) |
2014 |
Jan
(20) |
Feb
(66) |
Mar
(29) |
Apr
(13) |
May
(9) |
Jun
|
Jul
(11) |
Aug
(21) |
Sep
(15) |
Oct
(5) |
Nov
(5) |
Dec
(10) |
2015 |
Jan
(6) |
Feb
(26) |
Mar
(26) |
Apr
|
May
(9) |
Jun
(5) |
Jul
(5) |
Aug
(11) |
Sep
(8) |
Oct
|
Nov
|
Dec
|
2016 |
Jan
(3) |
Feb
|
Mar
(9) |
Apr
(3) |
May
(16) |
Jun
(26) |
Jul
(32) |
Aug
(27) |
Sep
(9) |
Oct
|
Nov
(4) |
Dec
(10) |
2017 |
Jan
(11) |
Feb
(44) |
Mar
(6) |
Apr
(8) |
May
(1) |
Jun
(2) |
Jul
(34) |
Aug
(28) |
Sep
(3) |
Oct
(9) |
Nov
(3) |
Dec
|
2018 |
Jan
(1) |
Feb
(5) |
Mar
(6) |
Apr
(1) |
May
(1) |
Jun
(2) |
Jul
|
Aug
(1) |
Sep
(6) |
Oct
|
Nov
(6) |
Dec
|
2019 |
Jan
(18) |
Feb
(16) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(7) |
Sep
(3) |
Oct
(10) |
Nov
(1) |
Dec
(3) |
2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(17) |
Jun
(23) |
Jul
|
Aug
(4) |
Sep
|
Oct
|
Nov
|
Dec
|
2021 |
Jan
(10) |
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(5) |
Oct
|
Nov
(1) |
Dec
|
2022 |
Jan
(8) |
Feb
|
Mar
(9) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(13) |
Nov
(12) |
Dec
|
2023 |
Jan
|
Feb
(1) |
Mar
(9) |
Apr
|
May
(3) |
Jun
(5) |
Jul
(3) |
Aug
(8) |
Sep
|
Oct
|
Nov
(1) |
Dec
(9) |
2024 |
Jan
(8) |
Feb
|
Mar
(14) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Marti M. <ma...@li...> - 2003-08-29 10:22:12
|
Hi, This hardly depends on the encoding used by the profile. Anyway, for these rare formats not supported directly by lcms, you have cmsSetUserFormatters() function. See cmmpack.c for samples on how to build these formatters. At the end, the "native" range is 0...0xFFFF since lcms always operates internally at 16 bits. Regards, Marti. ----- Original Message ----- From: "Daniel Rogers" <da...@ph...> To: <lcm...@li...> Sent: Friday, August 29, 2003 5:21 AM Subject: [Lcms-user] determining the normalized range > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > hi- > > Is there a way to use lcms to determine the min and max normalized > double values of a color component? In otherwords, suppose I want to > use a pixel representation not supported by lcms, and I want to use > doubles as a fallback representation. How do I determine how to > normalize my representation so that lcms can correctly convert the data > as doubles? > > An slightly useless example would be, suppose lcms could only convert > doubles, and I wanted to convert 8 bit RBG data. In order to pass the > data into lcms, I would need to divide each sample by 255 in order to > get a value between 0.0 and 1.0, otherwise lcms would not be correctly > converting the data. > > - -- > Daniel S. Rogers > da...@ph... > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.2 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQE/Tsayad4P1+ZAZk0RAgRuAJwOgXG5kiIXy7AKpRoGLQFVkMHwnACfXtQm > 196LDvI61fJtKZ+/UOdTQAY= > =ZXYC > -----END PGP SIGNATURE----- > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Lcms-user mailing list > Lcm...@li... > https://lists.sourceforge.net/lists/listinfo/lcms-user > > |
From: Daniel R. <da...@ph...> - 2003-08-29 03:04:37
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hi- Is there a way to use lcms to determine the min and max normalized double values of a color component? In otherwords, suppose I want to use a pixel representation not supported by lcms, and I want to use doubles as a fallback representation. How do I determine how to normalize my representation so that lcms can correctly convert the data as doubles? An slightly useless example would be, suppose lcms could only convert doubles, and I wanted to convert 8 bit RBG data. In order to pass the data into lcms, I would need to divide each sample by 255 in order to get a value between 0.0 and 1.0, otherwise lcms would not be correctly converting the data. - -- Daniel S. Rogers da...@ph... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/Tsayad4P1+ZAZk0RAgRuAJwOgXG5kiIXy7AKpRoGLQFVkMHwnACfXtQm 196LDvI61fJtKZ+/UOdTQAY= =ZXYC -----END PGP SIGNATURE----- |
From: <ph...@ph...> - 2003-08-28 23:48:54
|
Hi Folks: I have a process involving raterising PDF document into JPEG preview for browser viewing. In most cases, the JPEG images tend to be too bright. I mean it is brighter than the PDF document in Adobe Acrobat. I think Adobe is doing some profiling on PDF document to get a perfect look. I am thinking whether or not it is possible to apply a profile on the JPEG to produce a closer to Acrobat for image. I know there is "jpegicc" which applies profile to JPEG image. But I do not know what profile I can apply to image so that image can have a closer look to Acrobat Viewer. Any ideas? I can supply some comparable images if you need. -- With regards Phillip Pan ----------- |
From: Dave W. <dwi...@mi...> - 2003-08-28 15:49:10
|
I tried to go to www.littlecms.com and it appears to be down. -- Dave Williss ------ Meddle not in the affairs of dragons, for you are crunchy and taste good with catsup |
From: Jeff H. <jh...@co...> - 2003-08-27 05:34:38
|
<<< I post the following for Don Hutcheson, creator of the HCT, in response to some recent posts by Wolf Faust>>> ....................................................................... I don't know where Wolf Faust gets his data from but there is overwhelming evidence from real-world, high-end scanner and digital camera users that the HCT does a better job than the IT8. As for his claims that I'm just creating extra patches for marketing value, he's sorely mistaken. The current HCT design is the product of about eight year's research and experimentation, with all available profiling packages and dozens of different scanners. In fact I started out with a 250-patch design where I simply re-occupied the IT8 patches with different colors. (Didn't produce enough improvement). Interestingly, I never planned to commercialize the HCT. I created it just for my own use and for my own consulting clients. I was forced to go public with it through word-of-mouth testimonials and strong user-demand. As for Faust's claims that only 170 patches are necessary to create a good scanner profile, that's a theoretical dream. It's like saying a 300-patch printer target can do the same job as a 1400-patch target. (I wish!) Sure, if you already know the basic characteristics of a particular scanner model and if that scanner applies absolutely no color transform except the normal 1-D curve functions, you would (theoretically) only need a few 'hinting' patches (less than 170, by the way) to create a good profile. But in reality, all scanners work differently, often with annoying little non-linearities in unexpected places. And individual scanners within a family are usually different enough that most modeling theories can only make an approximate prediction, not an exact analysis, of a certain scanner's characteristics. Multiply this by the enormous number of variables in the typical user interface and you can see why many more than 170, 250 (or even 500, for that matter) patches may be needed to successfully decode the performance of any particular scanner for which you do NOT already know the basic characteristics. An even worse case is if a scanner applies any color transformation like a 3xn matrix, a 3-D LUT or an ICC profile (which many do). In that case even 500 patches will probably be too few to successfully analyze that scanner's RGB color space accurately. In spite of all this, I am happy to say that I have achieved quite good results with some IT8s on some scanners (using my 'extended profile' trick) and, as I have always said, casual users should be quite satisfied with the IT8. But high-end users continually tell me the HCT blows the IT8 away for critical matching to the original. The differences they notice are usually in deep colors and shadow tones and the reasons are pretty obvious when you compare the IT8 to the HCT. The bottom line is that to do the best possible job you have to start with the best possible tools. Any way you look at it, a hand-measured 500 patch target is quite obviously a better tool than a hand-measured 250 patch target. Period. I'm copying this to Dr. Chris Edge (KPG-Imation) - one of the world's most experienced and respected color scientists. Chris tells me his tests show the HCT clearly improves the quality of scanner profiles compared to profiles from the IT8. That, along with many unsolicited letters of thanks and congratulation from demanding color separators and photographers over the last two years is good enough for me. Regards, Don ****************************** Don Hutcheson Hutcheson Consulting (Color Management Solutions) 11 Turnburry Rd Washington, NJ 07882 Phone: (908) 689 7403 Mobile: (908) 500 0341 Fax: (908) 689 5305 E-mail: do...@hu... ****************************** |
From: Wolf F. <mai...@wf...> - 2003-08-26 23:21:13
|
On 24 Aug 2003 at 20:19, lcm...@li...urc wrote: > >For instance, have a look > >at the IEC 61966-8:2001 standard ("Multimedia colour scanners"). > > > I'd really like to read the IEC 61966-xx, unfortunately it is nowhere > available for free download. And all sites which do have the document > available, appearently want money for it. And CHF 125,-- for 38 pages > (-> IEC 61966-8) is IMO really an extortionate price. So I guess the > complete IEC 61966 series would cost a 4-digit amount :-( Instead of > spending so much mony for paper, I think I would rather buy a > spectrophotometer, and/or a few more of your targets ;-) Yes... color stuff is not cheap. I bought some of the DIN 5033-x standards (basicly matches CIE 15.2). Some of these 5033 standards only consist of one page. Costs: ~23.50 Euro plus shipping. Not bad for a single page without much content. The IEC standard prices at NPES seem rather low. Still my bank account is hurting :-) But than, some standard organisations do rely on the income from these papers and sure you do not only pay for the plain paper the text is printed on... Please do not get a wrong impression and expect too much from the IEC standard: The IEC standard seems mainly good for determine the spectral characteristics of the scanner wich than should help adjusting the colors of the scanner for certain materials. The standard does not deliver you spectral images. So the solution seems somewhere in the middle between old RGB based solutions and full spectral imaging. The best step surely would be spectral imaging of some sort. But I disagree that this has to be expensive. Some methods seem to be based on normal hardware taking several shots of the same object using different rather normal filters. Everything else is software... In neither case I know of any cheap working easy solutions you could use right now. Would be interesting to hear from one... -- Wolf Faust Tel: +49-69-5486556 mailto:wf...@wf... Fax: +49-69-95409598 http://www.coloraid.de Mobile: +49-179-6924769 |
From: Gerhard F. <nos...@gm...> - 2003-08-24 20:59:55
|
Wolf Faust schrieb: > > Therefore a profile created from a reflective IT8 target (which is > > printed photochemically on photo paper) is more or less only valid for > > scanning photos. >You can either get a spectrometer to measure the various materials >scanned. Or you could use spectral imaging. > Wolf, these alternatives are more or less obvious - though I guess multispectral devices are currently rather not affordable for the consumer sector, are they? However, I also don't understand why scanner manufacturers don't attempt to develop and use sensors with (approximately) colorimetric sensivities, and why they always must use those evil CCFL lamps (with their bizarre spectrum) in virtually all scanners, instead of using a reasonable light source e.g. with a spectrum close to daylight (I guess, wrt scanner metamerism, the light source is even the worse evil than the sensors). Basically I think, a proper light source and proper sensor sensivities could solve/reduce many scanner metamerism issues which occur in practice, without need to move to spectral imaging. I'm wondering, whether one reason might be, that most scanners are maybe rather optimized for scanning photograhic material, than for being (colorimetric) general purpose scanners? >For instance, have a look >at the IEC 61966-8:2001 standard ("Multimedia colour scanners"). > I'd really like to read the IEC 61966-xx, unfortunately it is nowhere available for free download. And all sites which do have the document available, appearently want money for it. And CHF 125,-- for 38 pages (-> IEC 61966-8) is IMO really an extortionate price. So I guess the complete IEC 61966 series would cost a 4-digit amount :-( Instead of spending so much mony for paper, I think I would rather buy a spectrophotometer, and/or a few more of your targets ;-) Best Regards, Gerhard |
From: Wolf F. <mai...@wf...> - 2003-08-22 18:15:18
|
On 21 Aug 2003 at 20:28, lcm...@li...urc wrote: > A profile is basically ony valid for scanning the same media type (with > the same spectral characteristics) which was used to create the profile. > Therefore a profile created from a reflective IT8 target (which is > printed photochemically on photo paper) is more or less only valid for > scanning photos. You can either get a spectrometer to measure the various materials scanned. Or you could use spectral imaging. For instance, have a look at the IEC 61966-8:2001 standard ("Multimedia colour scanners"). There is even a test-software available for this standard freely somewhere online. I am eager to hear from practical results as I am thinking about adding support for this standard.... -- Wolf Faust Tel: +49-69-5486556 mailto:wf...@wf... Fax: +49-69-95409598 http://www.coloraid.de Mobile: +49-179-6924769 |
From: Wolf F. <mai...@wf...> - 2003-08-22 18:15:16
|
On 20 Aug 2003 at 20:25, lcm...@li...urc wrote: > Hutcheson claims that "the transparent IT8 target has a lower D-max than > typical slide film. And hence the scanner profile made from that target > will fail to see very dark shadow details". > What is your comment on that? The claims made by Hutcheson about IT 8 targets are really just plain wrong and the IT 8 standard is pretty clear on the dmax (and other) field(s): "The minimum transmittance factor that a photographic film can achive". Now he claims to produce an targets with a bigger gamut/density range than IT 8 targets offer. But compare the reference files for the HCT targets with those of the cheap IT 8 targets sold on coloraid.de and you will see a different story ;-) > Also, could you provide links to the above publications? I would recommend a nice book from Henry R Kang: "Color Technology for electronic imaging devices". Very easy to read and contains lot's of figures/test regarding scanner color correction. Definitly a starting point and the widely used method in this book is pretty much on the level of various commercial tools :-( Lcms surely is much better ;-9 In this book you also find a table linking the number of patches used for calibration and the error limit achived. And from my exerience with my freeware scanner profiling software the figures given are correct in real-life. But you also find other papers on this issue from the sources below: Many usefull info can be found on http://www.spie.org. They also publish the Kang books. Just use their nice search engine. For instance the "Color Imaging: Device Independent Color, Color Hard Copy and Graphics Arts" series has lot's of usefull info and they now offer the series and other usefull info on a relativly cheap single CDROM ;-) (hurts a bit after buying the much more expensive books... but CD does allow searching the articles.. so bought it twice :-) Being a SPIE member since years, I can really only recommend them to any developer and I am still surpised to often find commercial color software developers not knowing this (and other) organisation... And I think there are some scanner profiling articles in the IEEE image processing journal... again, use their search engine... Also check IS&T... -- Wolf Faust Tel: +49-69-5486556 mailto:wf...@wf... Fax: +49-69-95409598 http://www.coloraid.de Mobile: +49-179-6924769 |
From: Gerhard F. <nos...@gm...> - 2003-08-21 07:17:38
|
Hi Robert, robert bergs wrote: > they say does not do any processing. I have been experimenting with all of them > - so far 'raw' has given the best result's, although the gamma is 1.0 which is > too low IMO not generally, if 16bpp are used. Basically gamma=1 does reflect the native characterists of most scanner's sensors and A/D converters (at least approximately). However both, the LCMS measurement tool (which can handle 8bpp only), and the current qtscannerprofiler version do have an accuracy problem when they create profiles from gamma 1.0 scans. >The piece that caused the problems was a glossy promotional flyer that was >predominantly bright red. > When I wrote my question I did not have the time to explain closer. I've been asking this, because I also notice large color deviations when I attempt to scan for instance colored plastic objects like plastic cards, etc. with my scanner profile generated from an IT8 target - which otherwise works pretty well for scanning photos. Depending on the scanned object, I get cyan instead of green, or red instead of orange, or purple instead of blue, ... However - though undesired - this is nomal and is a limitation of scanners in general. This effect is called scanner metamerism. A profile is basically ony valid for scanning the same media type (with the same spectral characteristics) which was used to create the profile. Therefore a profile created from a reflective IT8 target (which is printed photochemically on photo paper) is more or less only valid for scanning photos. If other media types are scanned with this profile, the reproduced colors may no longer be correct, and for very specific dyes/inks the error can become quite large - as a mentioned in the examples above. Even if I scan inkjet prints with my IT8 generated profile, I do get clearly visible, non-neglectible color casts in the images after applying the profile. Depending on the scanner's light source and the spectral sensivities of the scanner's sensors, these metamerism effects may be stronger or weaker, so it largely depends on the scanner used. IMO there also seems to be no reasonable way to compensate for these metamerism effects, except to generate a profile from a target which was printed on the same media type which needs to be scanned. Unfortunately targets on arbitrary media types are usually not available. At least I don't know a source where I could get non-photographic IT8 targets, e.g. printed with a Canon printer and Canon inks on a specific brand of paper, or printed with a HP printer and HP inks, or Epson, etc. Anyway, as a new profile generated by Marti did improve your colors significantly, your major problem (fortunately) appears to have been a different one. Regards, Gerhard |
From: gerard k. <ge...@gk...> - 2003-08-20 20:08:20
|
On Wed, 2003-08-06 at 00:38, Karl Heinz Kremer wrote: > I had to change the "-lqt" linker parameter to "-lqt-mt" in order to > get working > profilers. The Makefiles do use the environment variable QTDIR, so as > long as this variable is set correctly, everything should compile > without > any problems. > > What error messages are you getting? > > Karl Heinz > > > On Tuesday, August 5, 2003, at 02:15 PM, gerard klaver wrote: > > > > > > > From: gerard klaver <ge...@gk...> > > Date: Tue Aug 5, 2003 2:10:35 PM America/New_York > > To: kh...@kh... > > Subject: Re: [sane-devel] ICC Profiler Comparison > > Reply-To: ge...@gk... > > > > > > On Tue, 2003-08-05 at 15:02, kh...@kh... wrote: > >> FYI: > >> > >> This link was just posted to the LCMS mailing list: > >> > >> http://www.tkupfer.de/imaging/Scan_Profiling.html > >> > >> It compares different profiler that can create ICC profiles for > >> scanners. > >> LCMS looks pretty good. > >> _______________________________________________ > >> Sane-devel mailing list > >> San...@ww... > >> http://www.mostang.com/mailman/listinfo/sane-devel > > > > > > Nice report, the LCMS windows version also works with Wine on linux. > > > > The linux version not yet used/compiled, some qt dependency/path > > problems. If somebody has it working i am interesting when > > modifications > > are made in the source especially when it are modifications for Debian > > (i use testing/unstable) > > > > -- > > ---------- > > m.vr.gr. > > Gerard Klaver > > > > Thanks, Problems solved with the following: lqt added -mt /usr path added where needed (QTDIR) solved dependency problems: mix up from qt3, qt2 files qt changed to qt3 in path names For whom are interested on http://www.bearteam.org/debian/unstable/ there are some .deb files from lprof-1.08 package difference with lprof-1.09? -- ---------- m.vr.gr. Gerard Klaver |
From: Tarlika E. S. <ma...@nu...> - 2003-08-20 19:13:32
|
Hello Wolf, Hutcheson claims that "the transparent IT8 target has a lower D-max than typical slide film. And hence the scanner profile made from that target will fail to see very dark shadow details". What is your comment on that? > More patches are mainly a good selling point. But than, they hardly > help either and actually might harm if the profiling software was not > designed for it. As several scientific publications do show, the > fault pretty much bottoms out with >170 patches. So with the usual > 288 patches of the IT 8.7/2 target there is little to no gain in > adding more patches. Also, could you provide links to the above publications? Best regards, Tarlika Elisabeth Schmitz |
From: Wolf F. <mai...@wf...> - 2003-08-20 14:45:05
|
On 19 Aug 2003 at 20:18, lcm...@li...urc wrote: > At the end of The Computer Darkroom article that Geoff (thanks Geoff) referred > me to was a link to the HutchColor HCT - a target with more patches than the > Kodak IT8. Has anyone had any experience with one of these? More patches are mainly a good selling point. But than, they hardly help either and actually might harm if the profiling software was not designed for it. As several scientific publications do show, the fault pretty much bottoms out with >170 patches. So with the usual 288 patches of the IT 8.7/2 target there is little to no gain in adding more patches. As someone else here just suggested, certain automatics or color adjustments inside the scanner driver can cause these problems. Try getting the raw unprocessed scanner data (only with a gamma correction if you can). If possible, check the "integration" or "exposure" time of the scanner. And make sure the problem is not caused by the output profile used with TIFFICC... What output profile did you use and how did you verify exactly that the color was wrong? I mean, are you sure it is not the output profile/device/viewing conditions causing the problem? > I am currently investigating the editing facilities in MonacoProfiler to see if > I can correct the profile. Anything else I can try? Lcms is usualy really very good. But for other suggestions see http://www.tkupfer.de/imaging/Scan_Profiling.html for a good comparison of various profilers. > I suggest you try one of Wolf Faust's targets before you lay out the big > bucks for HCT. Thanks ;-) But I think this time the problem is not with the Kodak target. He should rather use the money and get drunk. A widely accepted temporary solution to any computer problem ;-) -- Wolf Faust Tel: +49-69-5486556 mailto:wf...@wf... Fax: +49-69-95409598 http://www.coloraid.de Mobile: +49-179-6924769 |
From: robert b. <lit...@be...> - 2003-08-20 09:17:09
|
Thanks for the comments to Hugh and Gerhard. In answer to your questions: The Kodak i260's settings are all done through selecting a color table from a choice of 'photo', 'text', 'mixed' and 'mixed2'. I believe that all of these do some processing on the image. Kodak have also sent us a 'raw' colour table which they say does not do any processing. I have been experimenting with all of them - so far 'raw' has given the best result's, although the gamma is 1.0 which is too low - we are currently trying to obtain a table which is 'raw + gamma 2.2' from Kodak. I'll try Hugh's test to check that the scanner is not trying to balance the image when we get the new table. The piece that caused the problems was a glossy promotional flyer that was predominantly bright red. Yesterday Marti very kindly created a profile for me using my .it8 file and his latest version of the profiler. The results were very good indeed - the reds are now handled properly. Hopefully we'll be able to improve further when we can increase the gamma. Rob. |
From: Gerhard F. <nos...@gm...> - 2003-08-20 04:20:50
|
robert bergs schrieb: >I am using Little CMS to profile a Kodak i260 scanner using the Kodak IT >8.7/2-1993 target. In use LCMS is brilliant - I found it very easy to create and >use the colour profiles. On the whole the results are great, but for one problem: > >I have found that areas of bright red on the original piece are being converted >to a bright orange after they have had my profile applied. > Robert, I'm wondering, what is your "original piece"? Did you scan a photo (on Kodak photo paper) or did you place some object on your scanner? Regards, Gerhard |
From: Hugh B. <ebr...@ci...> - 2003-08-20 00:11:56
|
I suggest you try one of Wolf Faust's targets before you lay out the big bucks for HCT. Make sure the preset you are using on your scanner isn't doing automatic adjustments. If you can't tell from the documentation, try scanning a portion of your target along with other subjects (that comprise most of the scan) which have very different contrast and color properties. If the IT8 patches come out different, you'll know the scanner is trying to balance the image. > -----Original Message----- > From: lcm...@li... > [mailto:lcm...@li...]On Behalf Of robert bergs > Sent: Tuesday, August 19, 2003 7:15 AM > To: lcm...@li... > Subject: Fwd: Re: [Lcms-user] Some colours appear wrong > > > Thanks Marti, > > I created a new profile without the local convergence analysis. > The dE rose from > 2.08 to 2.99. I ran the same input image through tifficc using > both profiles. > The resultant images are virtually identical - it is hard to tell > any difference > between them. > > At the end of The Computer Darkroom article that Geoff (thanks > Geoff) referred > me to was a link to the HutchColor HCT - a target with more > patches than the > Kodak IT8. Has anyone had any experience with one of these? > > I am currently investigating the editing facilities in > MonacoProfiler to see if > I can correct the profile. Anything else I can try? > > Thanks, > > Robert. > > > Hi, > > Assuming you are using the lprof profiler for generating the > profile, turn off > the local convergence analysis. This will rise a few the dE, but > eliminate > those false colors on gamut boundaries. This will be solved in > new profilers. > > Regards, > Marti. > > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072 > 303_01/01 > _______________________________________________ > Lcms-user mailing list > Lcm...@li... > https://lists.sourceforge.net/lists/listinfo/lcms-user > |
From: robert b. <lit...@be...> - 2003-08-19 11:15:18
|
Thanks Marti, I created a new profile without the local convergence analysis. The dE rose from 2.08 to 2.99. I ran the same input image through tifficc using both profiles. The resultant images are virtually identical - it is hard to tell any difference between them. At the end of The Computer Darkroom article that Geoff (thanks Geoff) referred me to was a link to the HutchColor HCT - a target with more patches than the Kodak IT8. Has anyone had any experience with one of these? I am currently investigating the editing facilities in MonacoProfiler to see if I can correct the profile. Anything else I can try? Thanks, Robert. Hi, Assuming you are using the lprof profiler for generating the profile, turn off the local convergence analysis. This will rise a few the dE, but eliminate those false colors on gamut boundaries. This will be solved in new profilers. Regards, Marti. |
From: Marti M. <ma...@li...> - 2003-08-19 09:03:42
|
Hi, Well, your best move would be to save the original block of memory and = embed back to the destination image. And there are very good reasons to do it in such way instead of = openprofile and savetomem: At first, there is no one-to-one correspondence between a serialized = profile (stored in file) and the image in memory cmsOpenProfileXXX does = create. Some examples: LUT tables can be stored in 8 or 16 bits of = precision. lcms does _always_ expand the 8 bits ones to 16 bits in = memory. Thus, if you open a 8 bits profile and the save it, you will end = with a different representation of LUT, but otherwise equivalent.=20 Curves can be stored in file as algorithm instead of value. Ver 2 holds = only simple gamma, but ver 4 can have complex math expressions, with = conditionals. lcms does expand such expressions in tables, using proper = resolution. So, the original math expression is lost. More, private tags = are (as spec states) ignored, thereby they are not in memory and cannot = be saved. Other no so evident reasons is the on-demand loading of AToB/BToA lcms = has This makes saving of profile more complex, too.=20 So, right now, _cmsSaveProfile and cmsSaveProfileToMem should be used = only to save profiles created by: cmsCreateRGBProfile,=20 cmsCreateGrayProfile,=20 cmsTransform2Devicelink, =20 cmsCreateLinearizationDeviceLink,=20 cmsCreateInkLimitingDeviceLink,=20 cmsCreateLabProfile,=20 cmsCreateXYZProfile,=20 cmsCreate_sRGBProfile Which are the profile creation functions. There is another method for creating profiles, which involves opening = NEW profile with "w" cmsOpenProfileFromFile(cProfile, "w") cmsAddTag() cmsCloseProfile() Anyway, editing of profiles is a very desirable feature, and I do not = discard to add it in future versions. Regards, Marti Maria The little cms project http://www.littlecms.com ma...@li... ----- Original Message -----=20 From: Bryan Flamig=20 To: Marti Maria=20 Sent: Monday, August 18, 2003 6:27 PM Subject: Re: [Lcms-user] Problems with cmsSaveProfile and = cmsSaveProfileToMem() Thanks Marti for your reply. I wasn't trying to edit the profile, but merely use it, and then embed = it back into the tif file. Here's what I mean: (1) Open a tif (or jpeg) (2) Read the raw bytes of the profile into a memory buffer. (3) "Open" the profile using cmsOpenProfileFromMem(). (4) Use the profile to translate file colors into screen colors via a = transform with a monitor profile. (5) Do whatever editing to the image. (6) Save the tif file, along with the embedded profile again, using = cmsSaveProfileToMem() followed by writing the raw bytes generated to the = tif (or jpeg) file. This seems like a very common thing to want to do, so I was surprised = when it didn't work. It doesn't involve any editing of the profile, just = merely using it for color transformations. The work-around I figured out was to keep the original memory buffer I = had read in (2), and then write that memory buffer back out, that is, never calling cmsSaveProfileToMem(). This of course = means I have to keep that memory buffer around along with the "working" = version of the profile, resulting in some redundancy. What I wasn't able to work around so easily was the scenario where you = want to save the profile, but continue using it. (Perhaps you are = sharing a copy across multiple images being edited.) This can't be done, = because the mere saving of the profile renders the tags unusable. Or are = the tags not really used for transformations? I can't say I tried that, = because once I saw the tags were being corrupted, I didn't look any = further. Other than these problems, so far the package has been working great! Bryan ----- Original Message -----=20 From: Marti Maria=20 To: Bryan Flamig ; Lcms-User=20 Sent: Monday, August 18, 2003 1:38 AM Subject: Re: [Lcms-user] Problems with cmsSaveProfile and = cmsSaveProfileToMem() Hi Bryan, Your are right, however, this is not a bug but an area to improve. Currently, lcms does *not* support editing of profiles.=20 That is, you can open a profile and use it in transforms. You can = also CREATE a profile and save it to memory or disk. But currently, you = cannot open a profile, touch some tags and then save it. This would = imply a wider understanding of all tags, and some are still not used by = lcms. Take for example sRGB, it has luminance tag and viewing condition = tags. lcms does not use these, so there is no code to write them. Also, = many profiles has custom tags. Opening in edit mode would imply a = handling of these and this is not supported right now. It happens that in the design of lcms API, long time ago, I belived = this would be a nice feature, and as such the API gives the possibility = of this combination. Yes, this is how it wuld work (with perhaps an = additional "r+" in open profile function) But this part is still just = planned. I'm adding a error message to prevent such corruption. Regards, Marti Maria The little cms project http://www.littlecms.com ma...@li... ----- Original Message -----=20 From: Bryan Flamig=20 To: lcm...@li...=20 Sent: Sunday, August 17, 2003 6:58 PM Subject: [Lcms-user] Problems with cmsSaveProfile and = cmsSaveProfileToMem() Hi, I've recently started experimenting with the littlecms package for = possible use in an image-editing program I've been writing. This package = is much appreciated, and would appear to be just what I need. However, = I've noticed three "features" so far, in the day and a half I've been = using it. These problems have to do with tags, and the opening and = saving of profiles for embedded use: (1) It seems the _cmsSaveProfile() and _cmsSaveProfileToMem() = functions have some issues. If you call these functions, the profile is = corrupted, because the tag directory gets damaged. More specifically, = the TagSizes[] array internal to the lcms profile structure gets = modified during the save operations, (specifically in the SaveTags() = function), rendering the tags unusable. It seems to me that saving a profile should not render it unusable = for further operations. (2) Also, another problem I've encountered when using embedded = profiles: A profile created with _cmsOpenProfileFromMem() cannot be = saved properly with _cmsSaveProfile() or _cmsSaveProfileToMem(). = Basically, the tags created with _cmsOpenProfileFromMem() are not in the = right form for saving, so they get dropped, resulting in a corrupt = profile. So, for example, if I want to "copy" a profile from a tiff file = I've opened, back to the tiff file after editing, I have to copy the raw = buffer I obtained from _cmsOpenProfileFromMem(), rather than try to save = the profile using the handle created from _cmsOpenProfileFromMem(). (3) There appears to be no way to copy a profile in memory, at = least with a convenient function call. So if you wish to save a profile = to a memory buffer (for embedding in tiff and jpeg files) or to a file, = but still continue to use that profile for internal color conversions, = you can't, because the profile gets corrupted, and you can't even make a = copy of it beforehand. One workaround I've come up with is to follow any call to = _cmsSaveProfileToMem() with a call to _cmsOpenProfileFromMem(), using = the same buffer. Then the profile is usable --- to a point. You can use = it alright, you just can't ever save it again! (Due to issues #1 and = #2.) Am I doing something wrong, or are these legitimate bugs? Otherwise, the package seems to be working smoothly, and is very = much appreciated. It's some of the cleanest open source code I've = encountered, as far as readability is concerned. And it compiles with no = errors or warnings, which is always a good sign. Thanks, Bryan Flamig |
From: Marti M. <ma...@li...> - 2003-08-19 08:35:48
|
Hi, Assuming you are using the lprof profiler for generating the profile, turn off the local convergence analysis. This will rise a few the dE, but eliminate those false colors on gamut boundaries. This will be solved in new profilers. Regards, Marti. ----- Original Message ----- From: "robert bergs" <lit...@be...> To: <lcm...@li...> Sent: Monday, August 18, 2003 3:57 PM Subject: [Lcms-user] Some colours appear wrong > I am using Little CMS to profile a Kodak i260 scanner using the Kodak IT > 8.7/2-1993 target. In use LCMS is brilliant - I found it very easy to create and > use the colour profiles. On the whole the results are great, but for one problem: > > I have found that areas of bright red on the original piece are being converted > to a bright orange after they have had my profile applied. I am using the sRGB > space as the output profile. > > I followed the advice that Hugh Brackett posted to this list a few days back > (thanks, Hugh) - but the scanner's interface is very poor and does not allow me > to alter the Gamma, shadow, highlight or even brightness and contrast. All I can > do is select one from 5 'color tables' geared up for photo or text scans. The > setting named 'Mixed2' gave the most even histogram and a dE of 2.08. Applying > the profile to the original IT8 scan does give visually pleasing results, and > most images come out fine. It's just the bright reds that are wrong. > > Has anyone else experienced a similar problem? Is it possible to 'tweak' the > profile to fix this? Could it be a bug in lcms? Or am I just doing something wrong? > > Any advice would be greatly appreciated, > > Robert Bergs > > |
From: robert b. <lit...@be...> - 2003-08-18 21:35:08
|
Thanks Kevin, One of our next steps was to look at an alternative CMS, so knowing it affects commercial ones as well is very useful. I'd prefer to continue using LCMS anyway! How did you edit the red curve? Is there an easy way or do I need to rapidly learn the ICC specification? Do you know of any software that might help? Rob. |
From: Robert B. <ro...@be...> - 2003-08-18 19:18:24
|
Thanks Kevin, One of our next steps was to look at an alternative CMS, so knowing it affects commercial ones as well is very useful. I'd prefer to continue using LCMS anyway! How did you edit the red curve? Is there an easy way or do I need to rapidly learn the ICC specification? Do you know of any software that might help? Rob. kev...@ho... wrote: > I had the same experience using several commercial ICC packages too... > > A color scientist at my last company explained that it was a failing of the > ICC specification itself (in the way transforms were calculated), but I > dont' know if that's 100% correct. > > Our solution was to hand-edit the red curve... not a scientific process as > much as an artistic one, sorry! > > Kevin. > > > ----- Original Message ----- > From: "robert bergs" <lit...@be...> > To: <lcm...@li...> > Sent: Monday, August 18, 2003 6:57 AM > Subject: [Lcms-user] Some colours appear wrong > > > >>I am using Little CMS to profile a Kodak i260 scanner using the Kodak IT >>8.7/2-1993 target. In use LCMS is brilliant - I found it very easy to > > create and > >>use the colour profiles. On the whole the results are great, but for one > > problem: > >>I have found that areas of bright red on the original piece are being > > converted > >>to a bright orange after they have had my profile applied. I am using the > > sRGB > >>space as the output profile. >> >>I followed the advice that Hugh Brackett posted to this list a few days > > back > >>(thanks, Hugh) - but the scanner's interface is very poor and does not > > allow me > >>to alter the Gamma, shadow, highlight or even brightness and contrast. All > > I can > >>do is select one from 5 'color tables' geared up for photo or text scans. > > The > >>setting named 'Mixed2' gave the most even histogram and a dE of 2.08. > > Applying > >>the profile to the original IT8 scan does give visually pleasing results, > > and > >>most images come out fine. It's just the bright reds that are wrong. >> >>Has anyone else experienced a similar problem? Is it possible to 'tweak' > > the > >>profile to fix this? Could it be a bug in lcms? Or am I just doing > > something wrong? > >>Any advice would be greatly appreciated, >> >>Robert Bergs >> >> >>------------------------------------------------------- >>This SF.Net email sponsored by: Free pre-built ASP.NET sites including >>Data Reports, E-commerce, Portals, and Forums are available now. >>Download today and enter to win an XBOX or Visual Studio .NET. >> > > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 > >>_______________________________________________ >>Lcms-user mailing list >>Lcm...@li... >>https://lists.sourceforge.net/lists/listinfo/lcms-user >> >> > > |
From: <kev...@ho...> - 2003-08-18 17:56:53
|
I had the same experience using several commercial ICC packages too... A color scientist at my last company explained that it was a failing of the ICC specification itself (in the way transforms were calculated), but I dont' know if that's 100% correct. Our solution was to hand-edit the red curve... not a scientific process as much as an artistic one, sorry! Kevin. ----- Original Message ----- From: "robert bergs" <lit...@be...> To: <lcm...@li...> Sent: Monday, August 18, 2003 6:57 AM Subject: [Lcms-user] Some colours appear wrong > I am using Little CMS to profile a Kodak i260 scanner using the Kodak IT > 8.7/2-1993 target. In use LCMS is brilliant - I found it very easy to create and > use the colour profiles. On the whole the results are great, but for one problem: > > I have found that areas of bright red on the original piece are being converted > to a bright orange after they have had my profile applied. I am using the sRGB > space as the output profile. > > I followed the advice that Hugh Brackett posted to this list a few days back > (thanks, Hugh) - but the scanner's interface is very poor and does not allow me > to alter the Gamma, shadow, highlight or even brightness and contrast. All I can > do is select one from 5 'color tables' geared up for photo or text scans. The > setting named 'Mixed2' gave the most even histogram and a dE of 2.08. Applying > the profile to the original IT8 scan does give visually pleasing results, and > most images come out fine. It's just the bright reds that are wrong. > > Has anyone else experienced a similar problem? Is it possible to 'tweak' the > profile to fix this? Could it be a bug in lcms? Or am I just doing something wrong? > > Any advice would be greatly appreciated, > > Robert Bergs > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 > _______________________________________________ > Lcms-user mailing list > Lcm...@li... > https://lists.sourceforge.net/lists/listinfo/lcms-user > > |
From: robert b. <lit...@be...> - 2003-08-18 14:47:13
|
I am using Little CMS to profile a Kodak i260 scanner using the Kodak IT 8.7/2-1993 target. In use LCMS is brilliant - I found it very easy to create and use the colour profiles. On the whole the results are great, but for one problem: I have found that areas of bright red on the original piece are being converted to a bright orange after they have had my profile applied. I am using the sRGB space as the output profile. I followed the advice that Hugh Brackett posted to this list a few days back (thanks, Hugh) - but the scanner's interface is very poor and does not allow me to alter the Gamma, shadow, highlight or even brightness and contrast. All I can do is select one from 5 'color tables' geared up for photo or text scans. The setting named 'Mixed2' gave the most even histogram and a dE of 2.08. Applying the profile to the original IT8 scan does give visually pleasing results, and most images come out fine. It's just the bright reds that are wrong. Has anyone else experienced a similar problem? Is it possible to 'tweak' the profile to fix this? Could it be a bug in lcms? Or am I just doing something wrong? Any advice would be greatly appreciated, Robert Bergs |
From: Marti M. <ma...@li...> - 2003-08-18 08:35:35
|
Hi Bryan, Your are right, however, this is not a bug but an area to improve. Currently, lcms does *not* support editing of profiles.=20 That is, you can open a profile and use it in transforms. You can also = CREATE a profile and save it to memory or disk. But currently, you = cannot open a profile, touch some tags and then save it. This would = imply a wider understanding of all tags, and some are still not used by = lcms. Take for example sRGB, it has luminance tag and viewing condition tags. = lcms does not use these, so there is no code to write them. Also, many = profiles has custom tags. Opening in edit mode would imply a handling of = these and this is not supported right now. It happens that in the design of lcms API, long time ago, I belived this = would be a nice feature, and as such the API gives the possibility of = this combination. Yes, this is how it wuld work (with perhaps an = additional "r+" in open profile function) But this part is still just = planned. I'm adding a error message to prevent such corruption. Regards, Marti Maria The little cms project http://www.littlecms.com ma...@li... ----- Original Message -----=20 From: Bryan Flamig=20 To: lcm...@li...=20 Sent: Sunday, August 17, 2003 6:58 PM Subject: [Lcms-user] Problems with cmsSaveProfile and = cmsSaveProfileToMem() Hi, I've recently started experimenting with the littlecms package for = possible use in an image-editing program I've been writing. This package = is much appreciated, and would appear to be just what I need. However, = I've noticed three "features" so far, in the day and a half I've been = using it. These problems have to do with tags, and the opening and = saving of profiles for embedded use: (1) It seems the _cmsSaveProfile() and _cmsSaveProfileToMem() = functions have some issues. If you call these functions, the profile is = corrupted, because the tag directory gets damaged. More specifically, = the TagSizes[] array internal to the lcms profile structure gets = modified during the save operations, (specifically in the SaveTags() = function), rendering the tags unusable. It seems to me that saving a profile should not render it unusable for = further operations. (2) Also, another problem I've encountered when using embedded = profiles: A profile created with _cmsOpenProfileFromMem() cannot be = saved properly with _cmsSaveProfile() or _cmsSaveProfileToMem(). = Basically, the tags created with _cmsOpenProfileFromMem() are not in the = right form for saving, so they get dropped, resulting in a corrupt = profile. So, for example, if I want to "copy" a profile from a tiff file = I've opened, back to the tiff file after editing, I have to copy the raw = buffer I obtained from _cmsOpenProfileFromMem(), rather than try to save = the profile using the handle created from _cmsOpenProfileFromMem(). (3) There appears to be no way to copy a profile in memory, at least = with a convenient function call. So if you wish to save a profile to a = memory buffer (for embedding in tiff and jpeg files) or to a file, but = still continue to use that profile for internal color conversions, you = can't, because the profile gets corrupted, and you can't even make a = copy of it beforehand. One workaround I've come up with is to follow any call to = _cmsSaveProfileToMem() with a call to _cmsOpenProfileFromMem(), using = the same buffer. Then the profile is usable --- to a point. You can use = it alright, you just can't ever save it again! (Due to issues #1 and = #2.) Am I doing something wrong, or are these legitimate bugs? Otherwise, the package seems to be working smoothly, and is very much = appreciated. It's some of the cleanest open source code I've = encountered, as far as readability is concerned. And it compiles with no = errors or warnings, which is always a good sign. Thanks, Bryan Flamig |
From: Bryan F. <br...@co...> - 2003-08-17 16:58:47
|
Hi, I've recently started experimenting with the littlecms package for = possible use in an image-editing program I've been writing. This package = is much appreciated, and would appear to be just what I need. However, = I've noticed three "features" so far, in the day and a half I've been = using it. These problems have to do with tags, and the opening and = saving of profiles for embedded use: (1) It seems the _cmsSaveProfile() and _cmsSaveProfileToMem() functions = have some issues. If you call these functions, the profile is corrupted, = because the tag directory gets damaged. More specifically, the = TagSizes[] array internal to the lcms profile structure gets modified = during the save operations, (specifically in the SaveTags() function), = rendering the tags unusable. It seems to me that saving a profile should not render it unusable for = further operations. (2) Also, another problem I've encountered when using embedded profiles: = A profile created with _cmsOpenProfileFromMem() cannot be saved properly = with _cmsSaveProfile() or _cmsSaveProfileToMem(). Basically, the tags = created with _cmsOpenProfileFromMem() are not in the right form for = saving, so they get dropped, resulting in a corrupt profile. So, for = example, if I want to "copy" a profile from a tiff file I've opened, = back to the tiff file after editing, I have to copy the raw buffer I = obtained from _cmsOpenProfileFromMem(), rather than try to save the = profile using the handle created from _cmsOpenProfileFromMem(). (3) There appears to be no way to copy a profile in memory, at least = with a convenient function call. So if you wish to save a profile to a = memory buffer (for embedding in tiff and jpeg files) or to a file, but = still continue to use that profile for internal color conversions, you = can't, because the profile gets corrupted, and you can't even make a = copy of it beforehand. One workaround I've come up with is to follow any call to = _cmsSaveProfileToMem() with a call to _cmsOpenProfileFromMem(), using = the same buffer. Then the profile is usable --- to a point. You can use = it alright, you just can't ever save it again! (Due to issues #1 and = #2.) Am I doing something wrong, or are these legitimate bugs? Otherwise, the package seems to be working smoothly, and is very much = appreciated. It's some of the cleanest open source code I've = encountered, as far as readability is concerned. And it compiles with no = errors or warnings, which is always a good sign. Thanks, Bryan Flamig |