Re: [Gimp-developer] CVS updates?

2004-07-08 Thread Raphaƫl Quinet
On Wed, 07 Jul 2004 18:55:14 -0700, Brion Vibber [EMAIL PROTECTED] wrote: Is Gimp anonymous CVS on a delayed copy? I'm assuming so based on the fact that I can't seem to get at the most recent commits through a cvs up -dP or cvs log. If there's something in the developer FAQ which is

Re: [Gimp-developer] color management

2004-07-08 Thread Dave Neary
Hi Alastair, I'm no colourspace expert (far from it), but there were a couple of things which I spotted in this which prompted questions. Quoting Alastair M. Robinson [EMAIL PROTECTED]: In the first method, is what I believe is what PhotoShop uses (and what I think Sven proposed): When an

Re: [Gimp-developer] what's required to develop GIMP

2004-07-08 Thread Dave Neary
Hi Chamal, Quoting Chamal De Silva [EMAIL PROTECTED]: 1. What is the programming language used to develop gimp. The GIMP is almost entirely coded in C. There are plug-ins in python, perl and scheme too, and there are some hardware specific routines in assembler, designed to speed up rendering

Re: [Gimp-developer] CVS updates?

2004-07-08 Thread Dave Neary
Hi Brion, Quoting Brion Vibber [EMAIL PROTECTED]: Is Gimp anonymous CVS on a delayed copy? Yes. The delay shouldn't be any more than about 12 to 24 hours, though. Although I have memories of anoncvs being up to 48 hours out of date. Would it be possible to fix the RSS changelog to point at

Re: [Gimp-developer] CVS updates?

2004-07-08 Thread Sven Neumann
Hi, Brion Vibber [EMAIL PROTECTED] writes: Also, the RSS changelog (http://wilber.gimp.org/~rss/gimp-cvs.rdf) has links to the GNOME bonsai on cvs.gnome.org which are all dead links. The only thing running on cvs.gnome.org seems to be viewcvs, which does at least seem to be more up to date

Re: [Gimp-developer] color management

2004-07-08 Thread Sven Neumann
Hi, Alastair M. Robinson [EMAIL PROTECTED] writes: There are as I understand it, two possible ways of dealing with colour profiles. In the first method, is what I believe is what PhotoShop uses (and what I think Sven proposed): When an image is loaded, scanned or whatever, it is

Re: [Gimp-developer] color management

2004-07-08 Thread Steve Stavropoulos
On Wed, 7 Jul 2004, Alastair M. Robinson wrote: Sven Neumann wrote: Well, we have only one internal color space. We just need to agree on what we want to call it... In the first method, is what I believe is what PhotoShop uses (and what I think Sven proposed): When an image is loaded,

Re: [Gimp-developer] color management

2004-07-08 Thread Jean-Christophe Dubacq
On Thu, Jul 08, 2004 at 05:47:56PM +0300, Steve Stavropoulos wrote: As for the proposed conversion on save to the starting colorspace, I completely dissagree. I don't see any reason to introduce more errors coming from a less than optimal conversion. What I think best is: Image (Any space)

Re: [Gimp-developer] color management

2004-07-08 Thread William Skaggs
Alastair M. Robinson wrote: In short, though, if we use this method, we don't need to agree on what to call our working space, because it will simply be whatever is appropriate for the image being edited! Dave Neary wrote: I think this is probably a very bad idea. I agree with Dave on

Re: [Gimp-developer] color management

2004-07-08 Thread Steve Stavropoulos
On Thu, 8 Jul 2004, Jean-Christophe Dubacq wrote: But one could want to make operations using specific profiles. I mean, addition is clearly not the same in CMYK or in sRGB, and marginally different in other color spaces. Gimp uses only one internal colorspace, 8bit RGB and I don't see that

Re: [Gimp-developer] color management

2004-07-08 Thread Sven Neumann
Hi, William Skaggs [EMAIL PROTECTED] writes: I agree with Dave on this one. Here is just one example of the sort of nasty thing that can happen if different images use different color spaces, with corresponding display filters: You could have two two-layer images, A and B, such that:

Re: Lists, Arrays and Vectors [was Re: [Gimp-developer] Re: Tiny-Fu: A new plug-in for GIMP]

2004-07-08 Thread Kevin Cozens
At 08:09 PM 07/07/2004, Markus Triska wrote: I also opt for vector because apart from being the natural Scheme equivalent to PDB's one-dimensional arrays, it makes writing plug-ins easier for people that have no to little practice in converting common for/while loops using tail-recursion, and

Re: [Gimp-developer] color management

2004-07-08 Thread Alastair M. Robinson
Hi Sven, Sven Neumann wrote: This is also what I originally proposed at GIMPCon. I have then been told that this would be the wrong thing to do and that we should convert the image on load. Now that you backed up my original proposal I tend to agree with you that converting the image data is not

Re: [Gimp-developer] color management

2004-07-08 Thread Alastair M. Robinson
Hi Dave, Dave Neary wrote: Yes, this is what was discussed at the conference, with one important difference. We don't convert back to AdobeRGB or whatever at save time, we simply save the working image data, with the sRGB color profile. OK - I agree that converting back to the original space is in

Re: [Gimp-developer] color management

2004-07-08 Thread Alastair M. Robinson
Hi Steve, Steve Stavropoulos wrote: Whatever you do, you will have to make a compromise. The question is, There we are in full agreement :) You are worried about quantization errors during the conversion, but if you do the conversion in 16 bit or more I think you will not have much problems.

Re: [Gimp-developer] color management

2004-07-08 Thread Alastair M. Robinson
Hi William, William Skaggs wrote: (1) Layer A1 is visually identical to layer B1. (2) Layer A2 is visually identical to layer B2. (3) When layers 1 and 2 are composited in Add mode, the two images look different. This can happen because of the nonlinearity in color profiles. I can see that this

Re: [Gimp-developer] color management

2004-07-08 Thread William Skaggs
Alastair M. Robinson writes: I beg to differ! A silently applied destructive change to the image data is in my opinion a very important factor! It should definitely not be silently applied. When you open an image that uses a different colorspace from the standard one, you should get a

Re: [Gimp-developer] color management

2004-07-08 Thread David Neary
Hi Alastair, Alastair M. Robinson wrote: Dave Neary wrote: Assuming we're using lcms, the internal conversion will be applied in full precision - the problem is that the destination data, by necessity of the GIMP's current limitations, must be 8-bit RGB. Converting 8-bit RGB data from

Re: [Gimp-developer] color management

2004-07-08 Thread Alastair M. Robinson
Hi, David Neary wrote: I may be misunderstanding things, but if the conversion from the source colourspace to sRGB is done in lcms losslessly, then all we're losing is the out-of-gamut colours from the colourspace conversion. And, of course, the cost of discarding precision in the data we get

Re: [Gimp-developer] color management

2004-07-08 Thread Sven Neumann
Hi, Alastair M. Robinson [EMAIL PROTECTED] writes: The colour selectors are perhaps one of the trickier aspects of my proposal; for their RGB values to be meaningful, the transform applied to the colour selector would need to change to reflect the current image's profile. I am afraid that

Re: [Gimp-developer] color management

2004-07-08 Thread Steve Stavropoulos
On Thu, 8 Jul 2004, Alastair M. Robinson wrote: I'm not worried about the conversion so much as the fact that the limited precision of the destination data (8-bit RGB) will cause us to lose colour information. A conversion of 8-bit data between two RGB profiles will not be a 1:1 mapping, so

Re: [Gimp-developer] easy questions

2004-07-08 Thread Tor Lillqvist
The second is, I haven't looked at the code at all, but is the GIMP multithreaded and/or does it absolutely require a multitasking OS? You won't be able to use any plugin without a multitasking OS... I think what the OP really meant to ask whether GIMP requires a *pre-emptively*

Re: [Gimp-developer] color management

2004-07-08 Thread Alastair M. Robinson
Hi Steve, Steve Stavropoulos wrote: That's exactly why we need the internal 8bit RGB colorspace used by gimp to be the widest possible. If the internal colorspace is wide enough then you won't notice any lost colors during the conversion. I don't know how I'm not actually talking about gamut

Re: [Gimp-developer] color management

2004-07-08 Thread Tor Lillqvist
I am afraid that this is not possible simply because the color selector is not associated with an image. All we can do is to correct the color selector using the monitor profile. You mean that the colour selector would implicitly always be sRGB? I'm afraid that's not a good idea. Assume

Re: [Gimp-developer] easy questions

2004-07-08 Thread Sven Neumann
Hi, Tor Lillqvist [EMAIL PROTECTED] writes: I think what the OP really meant to ask whether GIMP requires a *pre-emptively* multitasking OS. I.e. one that can interrupt a running process that has exceeded its timeslice, even if it doesn't do any system calls (or similar) that gives the

Re: [Gimp-developer] easy questions

2004-07-08 Thread Nathan Carl Summers
On 9 Jul 2004, Sven Neumann wrote: Hi, Tor Lillqvist [EMAIL PROTECTED] writes: I think what the OP really meant to ask whether GIMP requires a *pre-emptively* multitasking OS. I.e. one that can interrupt a running process that has exceeded its timeslice, even if it doesn't do any