Re: [Gimp-developer] CVS updates?
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 viewcvs, which > works, instead of bonsai, which doesn't? I don't know, to be honest... Sven? Cheers, Dave. -- Dave Neary Lyon, France ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CVS updates?
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 than anon cvs, and > diffs can be dug out of it. > > Would it be possible to fix the RSS changelog to point at viewcvs, > which works, instead of bonsai, which doesn't? The URLs in the RSS originate from the cvs commit mails so this would have to be fixed there. I'd also prefer to see Bonsai be restored since it offers a lot more functionality than viewcvs. Someone please bug the gnome cvs masters about this. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] color management
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 converted from its source colour space into a "working" colour > space (sRGB, AdobeRGB, etc.). Of course, the source colour-space and > working colour-space can be the same. The advantage of this method is > that the working data is always "normalised", so plugins and the like > have perceptually identical results, whatever the image's "native" > colour space. > > The workflow for an sRGB Image might be: > > Image (AdobeRGB) -> Working data (convert to sRGB) -> Editing -> Save > (convert back to AdobeRGB) > > Personally, I don't think this method is appropriate for the GIMP until > such time as we have support for 16-bit or float pixels, because if we > convert from the source space to a working space with only 8 bits per > sample we're going to lose some information through quantization errors. > > The second method, which I think we should use for the time being, is > just to keep track of the "source" profile for each image (and have a > user-selectable default profile - sRGB, AdobeRGB or whatever). This > source profile should be user-changable (so the user can tag a scanned > image with the scanner's profile, for example), and just needs to be > accessible to the proof and image-saving code. > > The equivalent workflow would be: > Image (tagged with AdobeRGB) -> Working data (8-bit RGB, unmodified) -> > Editing -> Save (AdobeRGB) 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 feasible as long as we work with 8bit per channel. > Colour-choosing is less-predictable (though no less than at > present), since the RGB values selected are in a variable colour > space. Since we're unlikely to get a PanTone colour-selector any > time soon, this shouldn't be an issue. The ultimate solution here > is to have a colour-profile attached to the colour-selector, and > simply transform the selected colour to the current image's profile. > The colour-selector's profile is probably as close as we need to get > at the moment to a "working" profile. Color-correcting the color-selectors is of course a must. We have put the color display filter architecture into libgimpwidgets to be able to implement this. It shouldn't be too hard and could be achieved for GIMP 2.2. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] color management
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, scanned or whatever, > it is converted from its source colour space into a "working" colour > space (sRGB, AdobeRGB, etc.). Of course, the source colour-space and > working colour-space can be the same. The advantage of this method is > that the working data is always "normalised", so plugins and the like > have perceptually identical results, whatever the image's "native" > colour space. > > The workflow for an sRGB Image might be: > > Image (AdobeRGB) -> Working data (convert to sRGB) -> Editing -> Save > (convert back to AdobeRGB) > > Personally, I don't think this method is appropriate for the GIMP until > such time as we have support for 16-bit or float pixels, because if we > convert from the source space to a working space with only 8 bits per > sample we're going to lose some information through quantization errors. > Whatever you do, you will have to make a compromise. The question is, what is the best compromise. I'm very far from being an expert in this area, but I'll try to put in some thoughts. 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 the littlecms site I found a command line program that does the colorspace conversion with very high accuracy. Check http://www.littlecms.com/newutils.htm#icctrans (This command line program does compute colorspace conversion based on icc profiles. Additionally, it can show XYZ and Lab values of PCS, and up to 16 bits of precision (48, 64 bits per pixel)). So, we even have example code ready for the conversion. The bigger problem we will have when converting colorspaces, is the limited gamut of sRGB in comparison with the source colorspace. For example, if we convert from CMYK to sRGB, then almost any color with CMYK values in the range C>90, M<10, Y<10, will have no sRGB counterpart. Would it be feasible to switch from sRGB to something better? Maybe AdobeRGB? I found usefull the http://www.brucelindbloom.com/index.html?WorkingSpaceInfo.html when comparing color spaces. Keep in mind though, that if we change the internal color space from sRGB to something else there must be an option for the user to save his image in sRGB (and maybe that should be the default on many cases). sRGB is the best option when someone tries to view an image in a computer monitor with no color profiling. 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) -> Working data in Internal gimp colorspace (sRGB or better something else) -> Editing -> Save (user selectable space; defaulting, at least for the xcf format, to the internal gimp colorspace) The question is: Are all these feasible for the 2.2 release? (which can be trivially converted to: Is there anyone willing to work on that?) ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] color management
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) -> Working data in Internal > gimp colorspace (sRGB or better something else) -> Editing -> Save (user > selectable space; defaulting, at least for the xcf format, to the internal > gimp colorspace) 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. I do not develop for the Gimp, I am even partially color blind (which is why I read stuff about color spaces), but I think operations should be done in the image color space. Which means we have to keep track of an "image color space". ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] color management
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 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: (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. It would be a real can of worms not to use the same color space internally for all images -- losses in conversion are not an important enough factor to overcome this. (But there is a reasonably strong case for allowing choice as to which color space is used internally.) Best, -- Bill __ __ __ __ Sent via the KillerWebMail system at primate.ucdavis.edu ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] color management
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 changing any time soon. So, you will never make operations in CMYK. The whole point with colorspaces is to have acurate colors. If you work in a colorspace with a wide enough gamut you are ok. That's why photoshop uses internally Adobe RGB 1998 independently of the images original color space. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] color management
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: > > (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 fail to see what would be bad about this behaviour. > It would be a real can of worms not to use the same color space > internally for all images -- losses in conversion are not an > important enough factor to overcome this. (But there is a > reasonably strong case for allowing choice as to which color space > is used internally.) For now we can only use the same color space internally since we are not going to make all operations aware of color management. Beware that we are discussing a short-term solution here with the right fix waiting right around the corner (GEGL). So the only places that would care about the color profile would be some save and load plug-ins and display filters. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: Lists, Arrays and Vectors [was Re: [Gimp-developer] Re: Tiny-Fu: A new plug-in for GIMP]
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 current scripts would work practically unmodified, without explicit conversions list->vector that would only cost time (with everybody ending up calling these instead of working on lists most of the time). By using vectors I was able to very quickly update the portion of those scripts which used SIOD array functions. I have not changed the Tiny-Fu marshalling code yet but I will do that soon and release a new tarball. Cheers! Kevin. (http://www.interlog.com/~kcozens/) Owner of Elecraft K2 #2172|"What are we going to do today, Borg?" E-mail:kcozens at interlog dot com|"Same thing we always do, Pinkutus: Packet:[EMAIL PROTECTED]| Try to assimilate the world!" #include| -Pinkutus & the Borg ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] color management
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 feasible as long as we work with 8bit per channel. Is there a transcript of these discussion available anywhere? I'd certainly be interested to hear all the counter-arguments :) Color-correcting the color-selectors is of course a must. We have put the color display filter architecture into libgimpwidgets to be able to implement this. It shouldn't be too hard and could be achieved for GIMP 2.2. 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. All the best, -- Alastair M. Robinson ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] color management
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 most situations unneccessary. I see your point. Perhaps there could be some kind of pre-loading where we apply the color profile in floating-point, and quantise afterwards? Just thinking out loud, this may be completely unfeasible. 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 one profile to another will not be a 1:1 mapping, so some colour information will be lost - I haven't yet conducted empirical tests for the severity of this effect, but I suspect that the 8-bit source data will be downgraded to something like 7 - 7.25 bit. For me, seeing as 8-bit RGB is already inadequate for smooth subtle gradients (cf. my gradient dither patch of a few months back) this is unacceptable. I concede, however, that not everybody will see it this way! How does this fit in with display calibration? If we work on the unmodified image data as we read it in, then on what data should the monitor's calibration profile work during projection? Should it work on the raw RGB data, or should we apply the input profile at projection time? Would a color profile be a per-layer thing? First of all, a profile on its own is worthless for rendering accurate colour - they must be used in pairs, source and destination, to create a colour "transform". Thus, if the GIMP is using sRGB internally, then at projection time you feed the RGB image data through an sRGB->Monitor Profile transformation. If instead you're using the unmodified RGB data from the original file, you just use an Image Profile -> Monitor Profile transform instead. (If the source image has no profile of it's own, then you can just tag it with a default profile.) In short, projection your way looks like this: Image (Source Profile) -> Internal data (sRGB) -> Screen (Monitor Profile) Two transformations, first from Source Profile to sRGB, secondly from sRGB to the Monitor's profile. This would work very nicely if the internal data could be stored in 16-bit or float precision. Because it can't we lose precision. My way looks like this: Image (Source Profile) -> Internal data (Source Profile) -> Screen (Monitor Profile) Just one transformation directly from the source profle to the screen profile, and more importantly, no destructive change to the raw image data. I don't think it would be feasible to make the profile a per-layer thing. I personally consider per-image to be the best solution, as long as there's some way of warning the user if they're copying and pasting between images with mismatched profiles. I think these are the kinds of issues that Sven thought about before, and they make adding color management considerably more complicated. I think that the simplicity of applying a color profile on imput and not having to worry about it in the rendering code outweighs the down side of any quantisation that occurs. I'll conduct some tests some time and try and figure out just how bad these quantisation errors could be. I can certainly see the appeal of a simplistic approach, but if a little extra effort can prevent unnecessary destructive changes to the image data, I think it's worth exploring. I think this is probably a very bad idea. Could you expand on why you think this? Confusion? Difficulty of implementation? Something else? All the best, -- Alastair M. Robinson ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] color management
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 the littlecms site I found a command line program that does the colorspace conversion with very high accuracy. Check 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 the converted data will not use the full dynamic range that 8-bit RGB can provide. Since the dynamic range of 8-bit RGB is already severly limited, I consider impairing it further to be unacceptable. The bigger problem we will have when converting colorspaces, is the limited gamut of sRGB in comparison with the source colorspace. For example, if we convert from CMYK to sRGB, then almost any color with CMYK values in the range C>90, M<10, Y<10, will have no sRGB counterpart. Would it be feasible to switch from sRGB to something better? Maybe AdobeRGB? I found usefull the http://www.brucelindbloom.com/index.html?WorkingSpaceInfo.html when comparing color spaces. If the GIMP is going to hand off the colour-matching work to littlecms, then using a different profile is as trivial as providing the filename of AdobeRGB instead of sRGB! Keep in mind though, that if we change the internal color space from sRGB to something else there must be an option for the user to save his image in sRGB (and maybe that should be the default on many cases). sRGB is the best option when someone tries to view an image in a computer monitor with no color profiling. Absolutely - though under my proposal, if an sRGB image is loaded, then for that image sRGB *is* the working space. 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. Agreed. Subconsciously, I suppose I'd considered it "good manners" to save a modified image in the same colour space it started in, but you're right, this is not necessary. All the best -- Alastair M. Robinson ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] color management
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 would happen; I don't, however, consider that to be a major problem, because you'd be able to see with more accuracy than at present what the result would be! It would be a real can of worms not to use the same color space internally for all images -- losses in conversion are not an important enough factor to overcome this. (But there is a reasonably strong case for allowing choice as to which color space is used internally.) I beg to differ! A silently applied destructive change to the image data is in my opinion a very important factor! All the best, -- Alastair M. Roobinson ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] color management
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 dialog that asks whether you want to (1) convert to Gimp's working space, or (2) use the RGB values without conversion. If you convert, then you should be asked to choose a conversion intent. Nothing should happen without the user's knowledge. For users who don't want to deal with these things, it may be useful to have a preference which, if enabled, turns off colorspace conversions and all queries related to them. Best, -- Bill __ __ __ __ Sent via the KillerWebMail system at primate.ucdavis.edu ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] color management
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 one profile to another will not be a 1:1 mapping, so some > colour information will be lost - I haven't yet conducted empirical > tests for the severity of this effect, but I suspect that the 8-bit > source data will be downgraded to something like 7 - 7.25 bit. 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 the application of the profile. But I think we still get the full 8 bits of data (they may not have the exact colours in the source file, though). > First of all, a profile on its own is worthless for rendering accurate > colour - they must be used in pairs, source and destination, to create a > colour "transform". Thus, if the GIMP is using sRGB internally, then at > projection time you feed the RGB image data through an sRGB->Monitor > Profile transformation. Yes, but since this profile is applied once, on the projection drawable, as the final step, its application doesn't present any problems. But I see what you mean - we can go from the source colourspace directly to the monitor's with one transformation. This, however, poses problems for say the checkerboard pattern (which will be transformed differently with different source profiles), and for any occasion where different profiles get mixed (cut & paste operations, for example). I would have thought you would still have to have the 2 profiles applied though... I'm sure I just don't know how lcms works. > I'll conduct some tests some time and try and figure out just how bad > these quantisation errors could be. Great - quantitative data will really help. > I can certainly see the appeal of a > simplistic approach, but if a little extra effort can prevent > unnecessary destructive changes to the image data, I think it's worth > exploring. Sure. > >I think this is probably a very bad idea. > > Could you expand on why you think this? Confusion? Difficulty of > implementation? Something else? The "this" was referring to a passage that you cut - I think it is probably a bad idea to have lots of image data in different colorspaces. I can't put my finger on why, but I just have this feeling that we will end up with a certain amount of confusion when it comes to colour stuff (as you pointed out, the colour picker is a good example, so is cut & paste). I'm more than willing to defer to the many experts we have, though. I wish I knew enough about the subject to consider myself one. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] CV: http://dneary.free.fr/CV/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] color management
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 the application of the profile. But I think we still get the full 8 bits of data (they may not have the exact colours in the source file, though). As a (somewhat extreme) analogy, imagine applying a lightening gamma curve to an 8-bit data set (0,1,2,3,4.253,254,255) you'd end up with not all codes being used at the dark end and codes being used multiple times at the light end - something like (0,2,4,6,7 254,254,255,255). I.e. there are missing codes at the dark end, and reused codes at the light end, due to the limited dynamic range of the destination space. The problem I'm talking about will be something vaguely similar; there will likely be missing and reused codes in the working space. Yes, but since this profile is applied once, on the projection drawable, as the final step, its application doesn't present any problems. But I see what you mean - we can go from the source I wasn't suggesting this was a problem, merely trying to explain that profiles are only meaningful when used in pairs. People talk about applying a profile to an image; usually what they mean is applying a transformation between profiles to an image. It's an important distinction. colourspace directly to the monitor's with one transformation. This, however, poses problems for say the checkerboard pattern (which will be transformed differently with different source profiles), and for any occasion where different profiles get mixed (cut & paste operations, for example). It will indeed - I had already mentioned the cut-and-paste case as a possible pitfall. I hadn't considered the checkerboard pattern, but I'm not totally convinced that this is a critical problem! I would have thought you would still have to have the 2 profiles applied though... I'm sure I just don't know how lcms works. Yes, you need 2 profiles - the key is that you don't use profiles directly, you use transformations built from a pair of profiles. The proposed method of using a standard working space involves three profiles (and hence two transformations linking them) - the image's own profile, the internal working space profile and the monitor profile. The "this" was referring to a passage that you cut - I think it is probably a bad idea to have lots of image data in different colorspaces. I can't put my finger on why, but I just have this feeling that we will end up with a certain amount of confusion when it comes to colour stuff (as you pointed out, the colour picker is a good example, so is cut & paste). I can certainly understand your gut feeling, and agree to a certain extent. The thought of destructive modification to the source data in just loading it makes me marginally queasier though! I agree that copy-and-paste is a major potential pitfall, and will require at least a warning on mismatched profiles, and at best an option to convert as part of the paste operation. I'm more than willing to defer to the many experts we have, though. I wish I knew enough about the subject to consider myself one. I'm no expert either (expert: n. from "X", meaning unknown, and "Spurt", meaning a drip under pressure!), but I have used colour profiles outside of the usual PhotoShop setting, and am just anxious that any colour management abilities the GIMP should sprout will be usuable for pre-press work in my job! All the best, -- Alastair M. Robinson ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] color management
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 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. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] color management
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 the converted data will not use > the full dynamic range that 8-bit RGB can provide. 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 much or how little these looses are, but photoshop works internally with adobe rgb 98 and no one complains about that. It seems that for practical use even the conversions to and from CMYK will be ok. The specifications of color spaces and the gamut projections on http://www.brucelindbloom.com/index.html?WorkingSpaceInfo.html I think will be of great help. > Since the dynamic > range of 8-bit RGB is already severly limited, I consider impairing it > further to be unacceptable. > I don't think that we will have much lost gamut if we work in a wide-gamut internal color space. But again, I'm not an expert... ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] easy questions
> > > > 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* 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 kernel a chance to let another process have the CPU. (For instance, Windows 3.1 wasn't able to do that.) As far as I can guess, sure, GIMP might work on such a system... as long as it has other functionality that GIMP and GTK needs. That's the main problem, not having pre-emptive multitasking would to me indicate there's a good chance that the OS is very lacking in other respects, too. --tml ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] color management
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 clipping, I'm talking about an effective loss of colour depth through quantization errors. I'm about to run some experiments, so I can hopefully provide some concrete illustrations, or eat humble pie, as may be appropriate! much or how little these looses are, but photoshop works internally with adobe rgb 98 and no one complains about that. It seems that for practical use even the conversions to and from CMYK will be ok. Photoshop can get avoid this issue by using 16-bit / float values to hold internal data. We can't (yet). The specifications of color spaces and the gamut projections on http://www.brucelindbloom.com/index.html?WorkingSpaceInfo.html I think will be of great help. Yes indeed, I'll digest that information in due course... All the best, -- Alastair M. Robinson ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] color management
> 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 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 only sRGB colours to be selected, the "most blue" colours he can select have the B value 255. When converted to the image's wide-gamut colour space, the colour will have significantly less B value. There won't be any way to select the colours that are out of the colour selector's sRGB gamut. 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"? What does Potatoshop do? --tml ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] easy questions
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 kernel a chance to > let another process have the CPU. (For instance, Windows 3.1 wasn't > able to do that.) As far as I can guess, sure, GIMP might work on > such a system... I don't think GIMP plug-ins would work w/o proper multitasking and using GIMP w/o plug-ins doesn't make too much sense. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] easy questions
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 system calls (or similar) that gives the kernel a chance to > > let another process have the CPU. (For instance, Windows 3.1 wasn't > > able to do that.) As far as I can guess, sure, GIMP might work on > > such a system... > > I don't think GIMP plug-ins would work w/o proper multitasking and > using GIMP w/o plug-ins doesn't make too much sense. Hmm, I'm confident you could get it to work on a cooperative multitasking system. You might need to add a yield() into the glib loop, but no big deal. Of course, it wouldn't work *well*, but then again cooperative multitasking never does. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] color management
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 toolbox or it is even permanently opened in one of the user's dock windows. I don't think we want to change that. Color management shouldn't stand in the way of established work-flows. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] color management
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 only sRGB colours to be selected, > the "most blue" colours he can select have the B value 255. When > converted to the image's wide-gamut colour space, the colour will have > significantly less B value. There won't be any way to select the > colours that are out of the colour selector's sRGB gamut. Who said the color would be converted to the image's color-space? We are discussing short-term solutions for color management here. GIMP won't know anything about color-spaces. All we are discussing here is whether it makes sense to use display filters to color-correct the image display (and optionally color selector displays). The other point that we are discussing is how file plug-ins should handle embedded color profiles, i.e. whether to attach the profile to the image or not. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
