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
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 d
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
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
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 spa
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
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 tha
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 tha
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 cur
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
fe
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
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. In
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
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
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 fro
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 after
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
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,
> > > > 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-empt
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 cli
> 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
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
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
>
Hi,
Tor Lillqvist <[EMAIL PROTECTED]> writes:
> I don't know what the solution is. Maybe some way to (temporarily)
> associate an invokation of the colour selector with a specific image?
> An entry in the menu "Select colour in image's colour space"?
The color selector is opened from the toolbo
Hi,
Tor Lillqvist <[EMAIL PROTECTED]> writes:
> Assume GIMP uses Sven's original idea (i.e. Alastair's preferred
> method) where images keep their original colour space. Say a user is
> working on an image in some colour space with a much larger gamut than
> sRGB. If the colour selector allows on
25 matches
Mail list logo
