Re: Colormanagement
On 1 Feb, Martí María wrote: > So, any volunteers? This piece of code is highly interesting but since this won't make into GIMP before 1.2 because of the featurefreeze I really hope that all GIMP developers will concentrate on the project until we released the next stable version. -- Servus, Daniel
Re: Colormanagement
Hi, I'm Marti Maria, lcms author. I am glad my package is worth of your attention, so I would like to clarify some points. The library is under GNU Lesser license agreement, and it will remain under LGPL. There are some sentences in the web page about you can do whatsever you want, well these was from first release, when no license was required at all. I will remove those sentences when next revision, in a couple of days. I did choose LGPL, because it permits to incorporate the code in commercial projects, then, I guess, you can also incorporate it in any free project like GIMP if you like. About porting the engine, well, the code has conditional #defines for using assembler, fixed-point, or a more generic floating point implementations of key routines. Only a few functions like fixed to float and fixed mult/div must be provided. The fixed-point C-only version delivers 80% of asm speed, even more if the compiler is smart enough to optimize properly. Since a lot of people is interested in the engine, I have little time for now in porting to ANSI-C (wich code is definitively NOT) I belive an experienced programmer would finish the port in a couple of days, and I signup if my modest help is required, So, any volunteers? Regards, Marti Maria
Re: Colormanagement
On 30-Jan-00 Robert L Krawitz wrote: > We're looking into this stuff a bit on gimp-print. If anyone here has > real expertise in this area, we'd like to have you join the gimp-print > project if you'd like. Look on sourceforge.net; the project name is > gimp-print. There is another project: scarse, but I can't reache the web server any more... http://ohm.phys.ualberta/scarse/ --- [EMAIL PROTECTED] http://www.regix.com/
Re: Colormanagement
On Sun, 30 Jan 2000 21:53:25 +0100, Marc Lehmann <[EMAIL PROTECTED]> said: >As long as they do not claim that their code is ANSI-C. I can >remember my first (and last) patch to the KDE developers that >converted their code to real C++, and they told me "F*ck off! Get a >real c++ compiler!". Ever since I became sensitive with such claims >;) That's KDE for ya. :) Kelly
Re: Colormanagement
On Sun, Jan 30, 2000 at 10:42:27PM +0200, Tor Lillqvist <[EMAIL PROTECTED]> wrote: > Well, he does say it is intended for the Windows platform, so this is He also wrote that his code would be fine ANSI C ;) If he wrote "it's intended for the windows platform, I think the C parts are quite portable" I would be less offended. > Most of these types have obvious counterparts in GLib. (WORD = guint, > HANDLE = gpointer, LPVOID = gpointer) And I always wondered what purpose they might have... > And a corresponding Unix library would call the ansi function > "syslog"? unix does not have the ansi function "syslog". > GIMP certainly is better, but for instance much of GNOME was pretty > infested with non-ANSI gccisms or gnumakeisms still quite recently. As long as they do not claim that their code is ANSI-C. I can remember my first (and last) patch to the KDE developers that converted their code to real C++, and they told me "F*ck off! Get a real c++ compiler!". Ever since I became sensitive with such claims ;) -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Colormanagement
Marc Lehmann writes: > So much for ANSI-C: > ../include/lcms.h:38: windows.h: No such file or directory > typedef HANDLE cmsHPROFILE; > WORD GammaTable[1]; > cmsHPROFILE LCMSEXPORT cmsOpenProfileFromMem(LPVOID MemPtr, DWORD dwSize); Well, he does say it is intended for the Windows platform, so this is to be expected. Including is for a programmer on Windows as natural as including for C programmers in general. Of course it is sad that people write an inherently portable library using Windows-specific types etc, but that's life. (Note: I do *not* consider myself a Windows programmer, but I play one on this list ;-) Most of these types have obvious counterparts in GLib. (WORD = guint, HANDLE = gpointer, LPVOID = gpointer) The real challenge when/if porting this is if some Win32 feature that does not have a portable equivalent is used. > the c standard (double definitions, indented preprocessor constructs, nice > calls to the ansi function "MessageBox" etc..) And a corresponding Unix library would call the ansi function "syslog"? GIMP certainly is better, but for instance much of GNOME was pretty infested with non-ANSI gccisms or gnumakeisms still quite recently. --tml
Re: Colormanagement
Date: Sun, 30 Jan 2000 21:03:29 +0100 From: Marc Lehmann <[EMAIL PROTECTED]> On Sun, Jan 30, 2000 at 06:35:26PM +0100, Stanislav Brabec <[EMAIL PROTECTED]> wrote: > It should include "simple" way based on phospors chromaticity > and white point for CRT and on C, M, Y, CM, CY, MY and K > chromaticity for print. that's not very interesting... X11R6 already has very good support for that. For printing, things like using your printers & monitors icc profile while creating an image is important. We're looking into this stuff a bit on gimp-print. If anyone here has real expertise in this area, we'd like to have you join the gimp-print project if you'd like. Look on sourceforge.net; the project name is gimp-print. -- Robert Krawitz <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] 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
Re: Colormanagement
On Sun, Jan 30, 2000 at 06:35:26PM +0100, Stanislav Brabec <[EMAIL PROTECTED]> wrote: > It should include "simple" way based on phospors chromaticity > and white point for CRT and on C, M, Y, CM, CY, MY and K > chromaticity for print. that's not very interesting... X11R6 already has very good support for that. For printing, things like using your printers & monitors icc profile while creating an image is important. > Much worse is to obtain basic chromaticity data (i. e. data for different > monitors and inks). Jupp :( -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Colormanagement
On Sun, Jan 30, 2000 at 11:51:37AM +0200, Tor Lillqvist <[EMAIL PROTECTED]> wrote: > written in assembler. Anyway, the code is ANSI C except such routines, So much for ANSI-C: ../include/lcms.h:38: windows.h: No such file or directory typedef HANDLE cmsHPROFILE; WORD GammaTable[1]; cmsHPROFILE LCMSEXPORT cmsOpenProfileFromMem(LPVOID MemPtr, DWORD dwSize); > The portability problems are probably not large, I guess a few hours > of hacking could make the library portable to any generic This might still be true, but I doubt the result is worth it. The source really shows that the compiler used to develop is only slightly influenced by the c standard (double definitions, indented preprocessor constructs, nice calls to the ansi function "MessageBox" etc..) In any case, if anybody wants to get what I hacked so far (still does not compile)... -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Colormanagement
Few time ago I have found another colormanagement library. It's completely written in C and license seems to be BSD like. web.access.net.au/argyll/icc_readme.html web.access.net.au/argyll/icclib.zip Note: I think that colormanagement library should not include only ICC profiles. It should include "simple" way based on phospors chromaticity and white point for CRT and on C, M, Y, CM, CY, MY and K chromaticity for print. Ghostscript and PostScript Language Reference Manual is a good source for such coding. Much worse is to obtain basic chromaticity data (i. e. data for different monitors and inks). -- Stanislav Brabec
Re: Colormanagement
Kelly Lynn Martin writes: > Just a note: ambiguities in the terms or scope of a license are > resolved in favor of the licensee. Which I guess means that one should grab the sources *now* while they are under the LGPL, before he changes his mind ;-) ? --tml
Re: Colormanagement
On Sun, 30 Jan 2000 11:51:37 +0200 (FLE Standard Time), Tor Lillqvist <[EMAIL PROTECTED]> said: >Another thing is the licensing. The webpage says: "lcms is free and >source code is also provided, with only one limitation: you can do >whatsever you want with the code, except to sell it." However, it >also says: "I have now released lcms under GNU Lesser license >agreement" (and the actual source files also refer to the LGPL), >which seeems a bit confusing. Just a note: ambiguities in the terms or scope of a license are resolved in favor of the licensee. Kelly
Colormanagement
Martin Weber writes: > Here is an interesting colormanagement for future GIMP releases: > http://www.abaforum.es/martim/lcms.htm Yes, that seems very interesting. But it says: "lcms only works under windows/Intel platforms". The READ.ME says: "lcms has been written for Borland C++ 4.5 [...] Visual C++ will NOT compile since some parts are written in assembler. Anyway, the code is ANSI C except such routines, so porting to another compiler would be straightforward." The portability problems are probably not large, I guess a few hours of hacking could make the library portable to any generic GLib-supported platform. Except for the assembler snippets, but somebody with i86 assembler knowledge probably could translate them to C pretty easily. Another thing is the licensing. The webpage says: "lcms is free and source code is also provided, with only one limitation: you can do whatsever you want with the code, except to sell it." However, it also says: "I have now released lcms under GNU Lesser license agreement" (and the actual source files also refer to the LGPL), which seeems a bit confusing. --tml
Colormanagement II
http://www.efg2.com/Lab/Library/Color.htm
Colormanagement
Here is an interesting colormanagement for future GIMP releases: http://www.abaforum.es/martim/lcms.htm
