Re: [Gimp-developer] Color management dataflow [was: Color management (UI perspective for GIMP 2.8)]
Christopher Curtis wrote: > On a more philosophical note, how does one represent a color that does > not exist on a display but does on an output device? Do we make the > assumption that the display always has the widest gamut? (I.e: GIMP > will never run on a mono/CGA device and print to a CMYK printer.) Is > that a concern? There's nothing special about this. In general any transformation from one colorspace to another has to cope with different gamuts. You simply choose how to handle it (ie. clip, perceptually map, etc.) by choosing an intent. It's not unknown to have a mode in an image editor that compresses the gamut of the source so that a very large gamut image can be viewed on a limited gamut display without loosing the ability to be able to see all its color variations. Naturally it will look a lot duller than it will when displayed on the intended device. Graeme Gill. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color management dataflow [was: Color management (UI perspective for GIMP 2.8)]
David Gowers wrote: > Imo the video card is the correct handler of these issues. X should > just upload an appropriate lookup table (which is functionality > already available in X, but doesn't happen automatically). Presumably > a multihead video card allows multiple LUTs. From that point of view, > it might make most sense for the desktop environment to do the > uploading of the LUT(s), since you would probably use it to select and > test the profile. Calibration != Profiling While most cards have per channel Luts, none will have per rendering context 3D color transforms (although it can be simulated using 3D texture lookups). Rendering context is usually somewhere up the rendering stack though, not something the hardware will be directly aware of. (It's rendering context because the transform depends on the source colorspace & intent as well as the display profile. In general it's not a 3x3 matrix transform either.) Graeme Gill. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color management dataflow [was: Color management (UI perspective for GIMP 2.8)]
On Sun, Feb 14, 2010 at 10:03 AM, Christopher Curtis wrote: > On Sat, Feb 13, 2010 at 5:58 PM, Jon Cruz wrote: > > [...] >> does seem to come down to the points that X11 does not and should not deal >> with color management in these regards and needs to leave it to the >> individual apps. To get a fully usable system, X11 would require some major >> reworking, and thus won't be seen any time soon. > > Do you have a reference to these discussions? It seems like X > *should*, accepting that it may be difficult. Imo the video card is the correct handler of these issues. X should just upload an appropriate lookup table (which is functionality already available in X, but doesn't happen automatically). Presumably a multihead video card allows multiple LUTs. From that point of view, it might make most sense for the desktop environment to do the uploading of the LUT(s), since you would probably use it to select and test the profile. >> Of course, to end up with an optimal workflow for end users, GTK could be >> adapted to handle a fair bit by itself (and, yes, there is work happening on >> this at the moment). Toolbars, icons, menus, color selectors, [...] > > I was just going to say here that putting it in GTK could also 'fix' > the color selector issues; let me just emphasize that point here. > > > On a more philosophical note, how does one represent a color that does > not exist on a display but does on an output device? > Do we make the > assumption that the display always has the widest gamut? That's tempting but ultimately incorrect, IMO, since most displays approximate sRGB, which only has what ..56% coverage of the visible spectrum? We should only make that assumption when the coverage becomes close to a superset of all other important mediums of reproduction (eg. when scRGB or whatever displays with 90% coverage of visible gamut are common). Looking at GEGL, the intermediate result of a computation (like mathematically a + b where a,b are layers) may be >1.0 or <0.0, and we must be able to differentiate those areas ,in the image and when we are eyedropping. I guess we need some way of depicting exposure stops independently for the R,G,B levels and also of setting them. To clarify: I mean that the color RGB 1.0, 1.0, 1.0 would have exposure 0,0,0; the color RGB -1.,0.,-2. would have exposure -1, 0, -2; RGB 2,2.5,2.8 would have exposure 1, 2, 2 etc. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color management dataflow [was: Color management (UI perspective for GIMP 2.8)]
On Sat, Feb 13, 2010 at 5:58 PM, Jon Cruz wrote: [...] > does seem to come down to the points that X11 does not and should not deal > with color management in these regards and needs to leave it to the > individual apps. To get a fully usable system, X11 would require some major > reworking, and thus won't be seen any time soon. Do you have a reference to these discussions? It seems like X *should*, accepting that it may be difficult. > Of course, to end up with an optimal workflow for end users, GTK could be > adapted to handle a fair bit by itself (and, yes, there is work happening on > this at the moment). Toolbars, icons, menus, color selectors, [...] I was just going to say here that putting it in GTK could also 'fix' the color selector issues; let me just emphasize that point here. On a more philosophical note, how does one represent a color that does not exist on a display but does on an output device? Do we make the assumption that the display always has the widest gamut? (I.e: GIMP will never run on a mono/CGA device and print to a CMYK printer.) Is that a concern? Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color management dataflow [was: Color management (UI perspective for GIMP 2.8)]
On Feb 13, 2010, at 12:08 AM, David Gowers wrote: > I agree; GIMP windows should support color management for individual > image windows according to these atoms, absolutely; > What it would be of little use to do, is to support showing the SAME > image in a single window spanning multiple monitors, with different > colormanagement for each monitor-segment of that Single window. > As I understand, that is what Christopher was requesting and yahvuu > was accurately describing as an uncommon use case, rather than the > general case of one image window on this monitor, one on that, and > they are color managed differently because of it. Ah, but that is exactly what I was thinking. I know the ancient-of-days workflow was to have one "good" color monitor for the actual images, and a monochrome "control" monitor with the buttons and interfaces to control the software. Over the years I've seen more and more users with two or three good monitors, including gamers and programmers in addition to artists. And I have seen such users have windows with images spanning those monitors very often. I'd also point out that this single-window-across-multiple-monitors use case is exactly one of the main ones that artists using Macintoshes had been quite fond of pointing out to their "poor cousins" on Windows (when I've seen them do such, it reminds me very much how "real programmers" use Linux). It highlights the fact that MacOS has had good color management built in to the OS for years and years. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color management dataflow [was: Color management (UI perspective for GIMP 2.8)]
On Feb 13, 2010, at 2:39 AM, yahvuu wrote: > > In reality, the wall of monitors probably won't work like that as long > as GIMP has to manage the windows' colors. As others have said, it is > unreasonable to manage split windows at application level. Well, personally I don't consider it unmanageable at all to have an application manage split windows. Especially with all the detail being presented via GTK on the geometry and positioning of the monitors, this is a fairly trivial matter. That's trivial in the abstract case, of course. The main complication will be in the details of hooking GIMP's display code at the very last moment (since among other things color management adjustments need to be done once and only once and on the final result just before it gets sent to the display). ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color management dataflow [was: Color management (UI perspective for GIMP 2.8)]
On Feb 13, 2010, at 9:42 AM, Hal V. Engel wrote: > I some ways I agree with Chris but the X.Org developers have insisted on an > ongoing basis that it is NOT their responsibility to handle color management > of the display. If we wait for X.Org to implement CM it will likely never > happen. I'd definitely second this point. I've been in many discussions with several key players in this arena, and when all technical details are explored it does seem to come down to the points that X11 does not and should not deal with color management in these regards and needs to leave it to the individual apps. To get a fully usable system, X11 would require some major reworking, and thus won't be seen any time soon. Of course, to end up with an optimal workflow for end users, GTK could be adapted to handle a fair bit by itself (and, yes, there is work happening on this at the moment). Toolbars, icons, menus, color selectors, etc., ideally would be color managed by GTK. But whatever "automatic" color management is added to GTK needs to be done in such a way as to allow the "smart" programs (such as GIMP) to hook in and control/override as needed.___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color management dataflow [was: Color management (UI perspective for GIMP 2.8)]
On Saturday 13 February 2010 09:15:13 am Christopher Curtis wrote: > On Sat, Feb 13, 2010 at 5:39 AM, yahvuu wrote: > > Christopher Curtis wrote: > >> What happens in a multi-head setup when I maximize an image over (say) > >> a CRT and an LCD? Does "monitor profile" take this into account? > > > > Following the logic of the diagram, i'd say yes: > > your case is equivalent to cutting an image into two pieces and printing > > one piece with an ink jet and the other one with a laser printer. > > I don't know that I'd agree with that; the example was not meant as a > use-case, just a demonstration of a potential problem. One could > argue that you'd need to print exactly this way to take advantage of > the specific gamuts (or materials) of each device. > > But that's not my point. I would rather suggest this: that GIMP not > do colorspace management of the display profile at all, and rely on X > to do the right thing even if it does not do so today. > > Imagine you are editing some image on one screen and trying to match > another image opened in another program on a different head. This > other program is not colorspace aware because it's scientific modeling > data or whatever so you have this dichotomy. In reality, you may > never be able to match the colors because of the different display > device gamuts. Maybe you can work around this with 'Acquire Image -> > Screen Shot' but isn't that really too burdensome? > > You could push colorspace management into GTK, which would be better, > but at the end of the day only one thing should be transforming gamuts > and I think that thing is X. Perhaps GTK and X can negotiate who's in > control so it becomes optional at the GTK level, but then you have the > possibility that the transformations are implemented differently and > slightly incompatibly. I think it's better to fix the problem once > and to do so in a way that all applications can take advantage of it. > > It is X's job to render the final display, whether it's local, remote, > DPS, Xprt, or whatever else X can render to. > > $0.02 > Chris I some ways I agree with Chris but the X.Org developers have insisted on an ongoing basis that it is NOT their responsibility to handle color management of the display. If we wait for X.Org to implement CM it will likely never happen. Hal ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color management dataflow [was: Color management (UI perspective for GIMP 2.8)]
On Sat, Feb 13, 2010 at 5:39 AM, yahvuu wrote: > Christopher Curtis wrote: >> What happens in a multi-head setup when I maximize an image over (say) >> a CRT and an LCD? Does "monitor profile" take this into account? > > Following the logic of the diagram, i'd say yes: > your case is equivalent to cutting an image into two pieces and printing > one piece with an ink jet and the other one with a laser printer. I don't know that I'd agree with that; the example was not meant as a use-case, just a demonstration of a potential problem. One could argue that you'd need to print exactly this way to take advantage of the specific gamuts (or materials) of each device. But that's not my point. I would rather suggest this: that GIMP not do colorspace management of the display profile at all, and rely on X to do the right thing even if it does not do so today. Imagine you are editing some image on one screen and trying to match another image opened in another program on a different head. This other program is not colorspace aware because it's scientific modeling data or whatever so you have this dichotomy. In reality, you may never be able to match the colors because of the different display device gamuts. Maybe you can work around this with 'Acquire Image -> Screen Shot' but isn't that really too burdensome? You could push colorspace management into GTK, which would be better, but at the end of the day only one thing should be transforming gamuts and I think that thing is X. Perhaps GTK and X can negotiate who's in control so it becomes optional at the GTK level, but then you have the possibility that the transformations are implemented differently and slightly incompatibly. I think it's better to fix the problem once and to do so in a way that all applications can take advantage of it. It is X's job to render the final display, whether it's local, remote, DPS, Xprt, or whatever else X can render to. $0.02 Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color management dataflow [was: Color management (UI perspective for GIMP 2.8)]
Christopher Curtis wrote: > What happens in a multi-head setup when I maximize an image over (say) > a CRT and an LCD? Does "monitor profile" take this into account? Following the logic of the diagram, i'd say yes: your case is equivalent to cutting an image into two pieces and printing one piece with an ink jet and the other one with a laser printer. In reality, the wall of monitors probably won't work like that as long as GIMP has to manage the windows' colors. As others have said, it is unreasonable to manage split windows at application level. However, in those places where color is really important, a second monitor means additional calibration cost and an additional potential source of error, i guess. regards, yahvuu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color management (UI perspective for GIMP 2.8)
David Gowers wrote: > * Color selector colors must be stored in a profile independent > colorspace (LAB?[1]). This ensures that we can paint any color onto > any image and get the right result. Otherwise, we'd have to know the > profile that the color was specified in, in order to use the correct > color on the image we're painting in now.. which makes color storage > way too heavyweight. [..] > * We should be able to a) specify colors outside of the color profile gamut > and b) clip the current color to the limits of the current color > profile when painting, previewing etc. > b) should probably be a toggle, then it could be quite helpful in > quick soft-proofing simpler: Color selectors give an overview of available colors and display a few selected colors, namely fg/bg color plus history. The range of available colors changes with the current working color space, and the color selectors should reflect that. E.g. the colors inside the 'triangle' should change according to current working space. The selected colors however, should be transferable between images and thus need to be stored in an absolute color space. Gamut warnings indicate when they are outside the current working space. (They may well be outside of display gamut as well..) everything IMHO, yahvuu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color management dataflow [was: Color management (UI perspective for GIMP 2.8)]
On Sat, Feb 13, 2010 at 5:22 PM, Jon Cruz wrote: > However, the answer to the base question is "Yes, X and Gtk support that to > a very good degree, and all the low-level API's support delivering all the > required information". > and "No, X does nothing with the colorspaces. It is left to the application > to implement" > It also is more of a per-monitor issue, rather than per-pixel. So one > generally will have to deal with a small set of rectangles (two being the > most common) to adjust. So it's not *quite* up to the complexity of a purely > per-pixel problem. > I also would question the assertion that it is an uncommon use case. Those > most likely to be working seriously with images are generally much likely to > have two (or more) monitors. They also have a higher chance of caring about > color fidelity. I agree; GIMP windows should support color management for individual image windows according to these atoms, absolutely; What it would be of little use to do, is to support showing the SAME image in a single window spanning multiple monitors, with different colormanagement for each monitor-segment of that Single window. As I understand, that is what Christopher was requesting and yahvuu was accurately describing as an uncommon use case, rather than the general case of one image window on this monitor, one on that, and they are color managed differently because of it. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color management dataflow [was: Color management (UI perspective for GIMP 2.8)]
On Feb 12, 2010, at 5:42 PM, Omari Stephens wrote: > On 02/12/2010 10:12 PM, Christopher Curtis wrote: >> On Fri, Feb 12, 2010 at 11:55 AM, yahvuu wrote: >> >>> here are some diagrams depicting selected configurations for >>> colormanagement: >>> http://yahvuu.files.wordpress.com/2009/08/dataflow.png >> >> What happens in a multi-head setup when I maximize an image over (say) >> a CRT and an LCD? Does "monitor profile" take this into account? >> >> I think my question is: Is X handling the colorspace or are profiles >> being applied on individual pixel regions? Is this even supported or >> is there something else I'm not understanding at a very basic level? > > This is an uncommon usecase that would require too much effort to > support properly for the small amount of benefit. > > X11 has an atom which stores one ICC display profile per screen. We > would have to change the display transform depending on which screen > each pixel shows up on. This would also mean that we'd have to deal > with the case where an image tile is split across two screens. > > Again, this would be a lot of code (and, thus, the potential for a lot > of bugs). It would be infrequently used (and so the bugs would tend to > not be found as quickly). And it would likely slow down our common code > paths for little benefit. However, the answer to the base question is "Yes, X and Gtk support that to a very good degree, and all the low-level API's support delivering all the required information". and "No, X does nothing with the colorspaces. It is left to the application to implement" It also is more of a per-monitor issue, rather than per-pixel. So one generally will have to deal with a small set of rectangles (two being the most common) to adjust. So it's not *quite* up to the complexity of a purely per-pixel problem. I also would question the assertion that it is an uncommon use case. Those most likely to be working seriously with images are generally much likely to have two (or more) monitors. They also have a higher chance of caring about color fidelity. And given the direction GIMP is taking in regards to dropping support for the casual users (or whichever wording best describes the current directive on this) I would expect this to be even more in line with GIMP's targeted user base and use cases. Of course, I've not delved down into the details of GIMP's display code and where to best hook in such display transformations. On the other hand, when I added the initial XICC X11 profile support to Inkscape I had researched this a fair bit, and for Inkscape's display code the extra needed for multi-monitor support is actually rather trivial. Then again the main consideration does need to go to the pragmatic factors. Given the constraints of that situation (including being the sole engineer doing any and all color work), per-monitor simultaneous profile support was deferred. However, switching profiles as the window moved mainly from one monitor to the next went in, along with dynamic detection and reloading of the profile as they get set or cleared on the current monitor also went in quite easily. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color management dataflow [was: Color management (UI perspective for GIMP 2.8)]
On 02/12/2010 10:12 PM, Christopher Curtis wrote: > On Fri, Feb 12, 2010 at 11:55 AM, yahvuu wrote: > >> here are some diagrams depicting selected configurations for colormanagement: >> http://yahvuu.files.wordpress.com/2009/08/dataflow.png > > What happens in a multi-head setup when I maximize an image over (say) > a CRT and an LCD? Does "monitor profile" take this into account? > > I think my question is: Is X handling the colorspace or are profiles > being applied on individual pixel regions? Is this even supported or > is there something else I'm not understanding at a very basic level? This is an uncommon usecase that would require too much effort to support properly for the small amount of benefit. X11 has an atom which stores one ICC display profile per screen. We would have to change the display transform depending on which screen each pixel shows up on. This would also mean that we'd have to deal with the case where an image tile is split across two screens. Again, this would be a lot of code (and, thus, the potential for a lot of bugs). It would be infrequently used (and so the bugs would tend to not be found as quickly). And it would likely slow down our common code paths for little benefit. --xsdg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color management (UI perspective for GIMP 2.8)
On Sat, Feb 13, 2010 at 8:59 AM, SHIRAKAWA Akira wrote: > On 2010-02-09 19:52, Martin Nordholts wrote: >> "GIMP is nearly flawless in its color handling, but there is one >> problem. It forgets to convert copy and pasted image content." > > Also don't forget that the various color picker/selectors aren't color > managed at the moment, so selected colors (FG/BG colors) will look > differently when painted on a color managed image. I think color management of individual colors and color selectors is a tricky subject. * Color selector colors must be stored in a profile independent colorspace (LAB?[1]). This ensures that we can paint any color onto any image and get the right result. Otherwise, we'd have to know the profile that the color was specified in, in order to use the correct color on the image we're painting in now.. which makes color storage way too heavyweight. * We should consider improving the color history system. MyPaint has one with the property that I think is important here: A color gets added to the history once it is 'read' (in Mypaint's case, when you paint with it; In GIMP's case, this would also be if it was read via the PDB (ie plugins or scripts)). And the previous color is shown in the color selector side-by-side to the color you're now adjusting. This makes it easier to do color comparisons, which are pretty important to get right when the previous color and current color are based on different color profiles. * We should be able to a) specify colors outside of the color profile gamut and b) clip the current color to the limits of the current color profile when painting, previewing etc. b) should probably be a toggle, then it could be quite helpful in quick soft-proofing * Some of the color selectors are already quite slow (eg. the 'scales' one). We should avoid making them slower if possible. [1] correct me if I'm wrong here... scRGB might do the job okay, I'm not 100% sure. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color management (UI perspective for GIMP 2.8)
On 2010-02-09 19:52, Martin Nordholts wrote: > "GIMP is nearly flawless in its color handling, but there is one > problem. It forgets to convert copy and pasted image content." Also don't forget that the various color picker/selectors aren't color managed at the moment, so selected colors (FG/BG colors) will look differently when painted on a color managed image. -- SHIRAKAWA Akira ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color management dataflow [was: Color management (UI perspective for GIMP 2.8)]
On Fri, Feb 12, 2010 at 11:55 AM, yahvuu wrote: > here are some diagrams depicting selected configurations for colormanagement: > http://yahvuu.files.wordpress.com/2009/08/dataflow.png What happens in a multi-head setup when I maximize an image over (say) a CRT and an LCD? Does "monitor profile" take this into account? I think my question is: Is X handling the colorspace or are profiles being applied on individual pixel regions? Is this even supported or is there something else I'm not understanding at a very basic level? Thanks, Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color management dataflow [was: Color management (UI perspective for GIMP 2.8)]
On 02/12/2010 07:18 PM, Omari Stephens wrote: > If the user with a weird monitor (wide-gamut, AdobeRGB, or other) has a > display profile and opens an image-without-profile, what do we display? >We can't apply the display profile unless the image has some source > color profile to link to the transform. This is where I suggest we use the working space color profile, although always using sRGB would work too in the scope of this discussion. Yes, in order to display the image we need to assume a color color profile, but the way I think this is different from thinking about the image as having an implicit color profile. > In doing so, it allows us to stop special-casing for cases where the > image may not have a color profile. We gain uniformity of display logic > and a decrease in code complexity by being able to assume the presence > of a color profile as an invariant. We need special casing either way, it's just a matter of where we have it. With your implicit profile strategy, we need a special case in the export code and image property code: if image.color_profile_implicit() color_profile = null else color_profile = image.get_color_profile() while with my strategy it would be in the display code: color_profile = image.get_color_profile() if (color_profile == null) color_profile = gimp.get_working_space_color_profile() Since we want to support working with non-color managed images it is more logical to handle images with no associated color profile than to handle images with implicit color profiles. "Images always have an associated color profile" is by design not an invariant. Regards, Martin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color management dataflow [was: Color management (UI perspective for GIMP 2.8)]
On 02/12/2010 05:36 PM, Martin Nordholts wrote: > On 02/12/2010 06:27 PM, Omari Stephens wrote: >> On 02/12/2010 04:55 PM, yahvuu wrote: >>> Hi, >>> >>> here are some diagrams depicting selected configurations for >>> colormanagement: >>> http://yahvuu.files.wordpress.com/2009/08/dataflow.png >> >> I believe number 1 is incorrect: >> All images in GIMP will have a color profile. > > People will want to create unmanaged images without a color profile for > use on the web for example, so we need to handle images with no color > profile attached. I think introducing the conepts of "implicit profiles" > adds unnecessary complexity. If the user with a weird monitor (wide-gamut, AdobeRGB, or other) has a display profile and opens an image-without-profile, what do we display? We can't apply the display profile unless the image has some source color profile to link to the transform. Hence, we assume sRGB to enable this and other situations to behave as correctly as possible. The sRGB assumption is one what we already make, this change will simply make that assumption a bit more explicit. In doing so, it allows us to stop special-casing for cases where the image may not have a color profile. We gain uniformity of display logic and a decrease in code complexity by being able to assume the presence of a color profile as an invariant. And the code itself is trivial: just add a "give_me_color_profile" function which returns icc-profile contents if present, or the sRGB profile otherwise. (with a more-reasonable name, of course). --xsdg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color management dataflow [was: Color management (UI perspective for GIMP 2.8)]
hi, and thanks for the feedback Omari Stephens wrote: > I believe number 1 is incorrect: First thing to note is that i should have added a legend: - grey: device-dependent colors, plain RGB values, no profile info available. - orange: colors from an absolute color space Picture 1) was intended to show the situation before color management was introduced: the RGB data gets exchanged between devices without any conversion. The resulting colors are unknown as none of the devices has been profiled or calibrated. > All images in GIMP will have a color profile. This will either be the > implicit sRGB profile, or some explicit profile. Similarly, in the case > where the monitor has no explicit display profile, we send it RGB on the > assumption that it mostly conforms to sRGB. > > More specifically, that means that everywhere we display an image will > be color-managed, even if that image isn't explicitly tagged with a > profile. Color-related tools (the color picker comes to mind) should > always function relative to the color profile of the image, be it > explicit or implicit. This may spell some interesting changes for > Curves and Levels down the line; I'm not sure. oh, i meant to talk about the principal configurations / UX options. I hope that there's no conflict with implementation issues by now. I'm working on a set of use cases to use as a decision aid... > I > also do not understand why 2a and 2b are separated. the goal was to make explicit that importing unmanaged data and creating unmanged data on export might be unrelated. For example, 2b) might be a photographer that opens a ClayRGB file from his archive and exports a JPG without any profile information, for web use. regards, yahvuu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color management dataflow [was: Color management (UI perspective for GIMP 2.8)]
On Fri, Feb 12, 2010 at 8:36 PM, Martin Nordholts wrote: > People will want to create unmanaged images without a color profile for > use on the web That is, if people want to make everyone's lives more difficult, who are we to stop them from doing so? :) Just make web equal to sRGB as it already is. Alexandre ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color management dataflow [was: Color management (UI perspective for GIMP 2.8)]
On 02/12/2010 06:27 PM, Omari Stephens wrote: > On 02/12/2010 04:55 PM, yahvuu wrote: >> Hi, >> >> here are some diagrams depicting selected configurations for colormanagement: >> http://yahvuu.files.wordpress.com/2009/08/dataflow.png > > I believe number 1 is incorrect: > All images in GIMP will have a color profile. People will want to create unmanaged images without a color profile for use on the web for example, so we need to handle images with no color profile attached. I think introducing the conepts of "implicit profiles" adds unnecessary complexity. / Martin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color management dataflow [was: Color management (UI perspective for GIMP 2.8)]
On 02/12/2010 04:55 PM, yahvuu wrote: > Hi, > > here are some diagrams depicting selected configurations for colormanagement: > http://yahvuu.files.wordpress.com/2009/08/dataflow.png I believe number 1 is incorrect: All images in GIMP will have a color profile. This will either be the implicit sRGB profile, or some explicit profile. Similarly, in the case where the monitor has no explicit display profile, we send it RGB on the assumption that it mostly conforms to sRGB. More specifically, that means that everywhere we display an image will be color-managed, even if that image isn't explicitly tagged with a profile. Color-related tools (the color picker comes to mind) should always function relative to the color profile of the image, be it explicit or implicit. This may spell some interesting changes for Curves and Levels down the line; I'm not sure. For 2, an image that, when imported, does not have any explicit color profile information will be exported without saving any explicit color profile information (unless an explicit color profile was added). I also do not understand why 2a and 2b are separated. --xsdg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Color management dataflow [was: Color management (UI perspective for GIMP 2.8)]
Hi, here are some diagrams depicting selected configurations for colormanagement: http://yahvuu.files.wordpress.com/2009/08/dataflow.png While not yet a set of uses cases, i think these diagrams will be useful when discussing the use cases. Please let me know in case you spot errors or think i missed an important configuration. regards, peter ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color management (UI perspective for GIMP 2.8)
On 02/08/2010 07:07 PM, yahvuu wrote: > From the User Scenarios [1], i'd like to pick "Creating Original Art", > short name: "create a collage". This seems to be the clearest case, > and perhaps the others can be modelled after this one. > > Compositing several images into one image requires that all parts > have the same color space. The work is saved as XCF. > > Interestingly, from this follows that the working color space is not > a preference item, but a property of the image (XCF). Instead, > the _default_ image's color space is a preference item. The color > space should be set by choosing a template or from the Image->Mode menu. > > > For collage work, 'open as layers' can safely auto-convert to working color > space: > if a to-be-imported image requires manual color space adjustment, > it can be opened as an image on its own, be converted and then just be > dragged to the collage. So dragging layers between images should > silently auto-convert, too. This problem was observed in the excellent GIMP 2.6 review by Ars Technica: "GIMP is nearly flawless in its color handling, but there is one problem. It forgets to convert copy and pasted image content." http://arstechnica.com/features/2009/01/gimp-2-6-review.ars/2 > Somewhat related, why is 'color management' available as a display filter? > The name suggests it's a filter between image and monitor, so at most > the monitor profile(s) may be chosen here. As far as I know this is just an implementation detail leaking out in the UI: color managaing the viewing of an image is handled internally through a display filter. Regards, Martin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Color management (UI perspective for GIMP 2.8)
hi all, this is work in progress, mostly in analysis stage and a bit chaotic, but there are already some conclusions which might be worth discussing. any comments appreciated, yahvuu >From the product vision follows a tightly coupled workflow as default, where each file should have a profile embedded: a few bytes overhead are a nuisance, but wrong colors can be a quite expensive error. Notable exception is save-for-web. Which import/export behaviour is desired, depends more on the workflow than on the file formats. So it's rarely the import/export plugins which can decide properly. However, following the hi-fi attitude from the product vision, an overall rule for export is: if in doubt, embed a color profile. >From the User Scenarios [1], i'd like to pick "Creating Original Art", short name: "create a collage". This seems to be the clearest case, and perhaps the others can be modelled after this one. Compositing several images into one image requires that all parts have the same color space. The work is saved as XCF. Interestingly, from this follows that the working color space is not a preference item, but a property of the image (XCF). Instead, the _default_ image's color space is a preference item. The color space should be set by choosing a template or from the Image->Mode menu. For collage work, 'open as layers' can safely auto-convert to working color space: if a to-be-imported image requires manual color space adjustment, it can be opened as an image on its own, be converted and then just be dragged to the collage. So dragging layers between images should silently auto-convert, too. Other observation: the Assign/Convert commands are correctly placed in the Image->Mode menu [2]. Dealing with invalid profiles (in order of preference) - do nothing: an experienced user just _sees_ that something went wrong - red message in status bar, clicking it reveals backlog with detailed problem description - image overlay on top: "color space problem on import. click to see details", like Firefoxen's popup-blocker does (or stackoverflow.com to advertise its FAQ). - definitely not a pop-up Bug 320447 - fast switching between "color managed display" and "softproof" In future this can be solved very elegantly with a projection screen, analogous to the printing press projection and index color work [3]. For 2.8, the 'display filters' seem just right for this, so i'll second the approach taken in the bug report. Somewhat related, why is 'color management' available as a display filter? The name suggests it's a filter between image and monitor, so at most the monitor profile(s) may be chosen here. Export: There's no explicit save-for-web in 2.8, so a drop-down selector in the export dialog should do, which defaults to 'embed profile'. (thanks for reading) [1] http://gui.gimp.org/index.php/User_Scenarios [2] off-topic: and for 3.x we should be rid of that Image->Mode menu. With floating point processing, it is very tempting to fix the working space to some full-gamut color space, like scRGB or betaRGB (http://www.brucelindbloom.com/index.html?BetaRGB.html). [3] http://www.mmiworks.net/eng/publications/2009/06/gimp-squaring-cmyk-circle.html ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color management preferences not working and other CM stuff
Hi, On Wed, 2007-01-17 at 09:45 -0500, Christopher Curtis wrote: > Something to consider, I think, is momentum. I think that people want > to be part of a vibrant developer community. If a project does not > have this, it may be beneficial to create an artificial one by > increasing the number of releases. To this end, it may be wise to > make future releases more "bite-sized": 2.6 implements CMS workflow > and fixes 2.4 problems. 2.8 introduces Cairo rendering. And then 3.0 > can integrate GEGL. That's what we are targeting for with 2.6. It will be a short development cycle with only very few changes. But there are people waiting to be able to commit GEGL code into the GIMP tree. So we will definitely not wait with that. The transition to GEGL will take a while anyway and the user won't notice in the beginning anyway. > Now, I'm not trying to be so bold as to propose a schedule, but it > seems that if there were three or four releases this year - 2.4 now, > then 2.6, 2.8, and maybe a 2.10 - that's roughly four months per > release. Asking people to "wait for the next release to include your > plugin" doesn't sound so severe then. The biggest burden I think > would fall to the translators, which is something that developers just > need to be sensitive to. Four releases per year is impractical. We wouldn't get anything done because we would be busy preparing releases all the time. Even the two releases per year schedule that GNOME is running is considered to be too short by most developers. And we can't release 2.4 now. It may even take another four months before we are there. Have a look at the bug reports on milestone 2.4. A few of them can be postponed but there are still some major ones that absolutely have to be addressed. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color management preferences not working and other CM stuff
On 1/16/07, Sven Neumann <[EMAIL PROTECTED]> wrote: > 2.6 has an even minor version number so it's obviously a stable release Obvious only to people who don't need to ask. > series. It will most probably use GEGL at a few places internally, but [...] > 2.6 is to finish some stuff that wasn't completed in time for 2.4 and to > start porting the core to GEGL. Perhaps we should also start porting the > display code to Cairo. But that depends on whether someone wants to work > on this or not. Something to consider, I think, is momentum. I think that people want to be part of a vibrant developer community. If a project does not have this, it may be beneficial to create an artificial one by increasing the number of releases. To this end, it may be wise to make future releases more "bite-sized": 2.6 implements CMS workflow and fixes 2.4 problems. 2.8 introduces Cairo rendering. And then 3.0 can integrate GEGL. GEGL of course has the same problem (limited developers) so it may be wise to do some partial integration where reasonable through the 2.x series to help keep that project going - people want to see the results of their efforts. More releases furthers this goal, and also entices new users to try the new features. This can create a nice feedback loop where lots of little changes can be cleaned up across each release. I don't think that additional stable releases further this goal because the GIMP generally just works. Bug fixes here and there just aren't exciting. Now, I'm not trying to be so bold as to propose a schedule, but it seems that if there were three or four releases this year - 2.4 now, then 2.6, 2.8, and maybe a 2.10 - that's roughly four months per release. Asking people to "wait for the next release to include your plugin" doesn't sound so severe then. The biggest burden I think would fall to the translators, which is something that developers just need to be sensitive to. The 3.0 release doesn't have to be so quick, assuming that GEGL integration upsets things. If timed properly, it may be wise to adapt a schedule to the Google summer of code program. The implication then being that this would complete summer 2009. Of course, that also means that this has to be a reasonable SoC project. Finally, in relation to my first comment, every mailing list has its share of hostile people. If developers truly want a large and vibrant development community, somebody needs to be a welcoming beacon. Condenscending remarks (blah blah is _obvious_) are damaging to that goal. There needs to be a consistent voice that welcomes masses of newbies asking "dumb questions" in hopes that some kernel within that mass are new GIMP developers that just need a little nurturing. (If it _should_ be obvious to someone, replying privately is better because the tone of the list matters.) Also, and this is related to above, I think we (all) should recognize the growing numbers of people running free software on non-free platforms and realize that they are important parts of the user base. Linux, for example, is not as scary to people who are already familiar with and use its software. But in order for them to use that software, it has to be a good experience on that non-free platform. "You mean if I buy a computer with Linux it already has the GIMP installed? Great!" For your consideration, Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] color management
On Tue, Jan 16, 2007 at 10:53:49AM +0200, Alexander Rabtchevich wrote: > It is located at [WINDOWS]\system32\spool\drivers\color\ at least on 2000+ > Plese usa [WINDOWS] as %SystemRoot% as in http://support.microsoft.com/kb/259852/en Perhaps this could be useful too: http://www.adobe.com/support/techdocs/321608.html Is there anyone who knows of a specific icc color profile registry key? -- Marco Ciampa ++ | Linux User #78271 | | FSFE fellow #364 | ++ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] color management
It is located at [WINDOWS]\system32\spool\drivers\color\ at least on 2000+ Sven Neumann wrote: > Hi, > > On Tue, 2007-01-16 at 11:23 +0300, Alexandre Prokoudine wrote: > >> Is it possible to at least default to /usr/share/color/icc or >> ~/.color/icc on unixes in current dialog? > > The profile file selection dialog isn't finished yet. But it already > installs a shortcut to the systemwide profile folder. At least on UNIX, > no idea if there's a similar folder on Win32. > > -- With respect Alexander Rabtchevich ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] color management
Hi, On Tue, 2007-01-16 at 11:23 +0300, Alexandre Prokoudine wrote: > Is it possible to at least default to /usr/share/color/icc or > ~/.color/icc on unixes in current dialog? The profile file selection dialog isn't finished yet. But it already installs a shortcut to the systemwide profile folder. At least on UNIX, no idea if there's a similar folder on Win32. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color management preferences not working and other CM stuff
Hi, On Tue, 2007-01-16 at 11:16 +0300, Alexandre Prokoudine wrote: > > We plan to have 2.6 out shortly after so I am currently postponing > > pretty much everything related to color management to the 2.6 release. > > Is 2.6 going to be bugfix release or a first stable version using GEGL/babl? 2.6 has an even minor version number so it's obviously a stable release series. It will most probably use GEGL at a few places internally, but the users are not likely going to notice that. Currently the plan for 2.6 is to finish some stuff that wasn't completed in time for 2.4 and to start porting the core to GEGL. Perhaps we should also start porting the display code to Cairo. But that depends on whether someone wants to work on this or not. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] color management
On 1/13/07, Sven Neumann wrote: > I thought about having it in 2.4 but I think it's probably best > distributed seperately until we find the time to integrate it properly. > Since we are almost ready for 2.4, we should probably not add any new > plug-ins at this point. Makes sense. > > 3. Is it planned to support OpenIcc's initiative to look for profiles > > in /usr/color/icc and ~/color/icc on Linux and standard profiles > > directories on other systems? If no, why? > > Yes, we plan to support it at some point. But it's too late to implement > this for 2.4. Fortunately though we are planning to release 2.6 shortly > after and that should give us the chance to add a proper ICC profile > selection widget that can be used from the core and from plug-ins. Is it possible to at least default to /usr/share/color/icc or ~/.color/icc on unixes in current dialog? > > 5. Main question: is color management going to be enabled by default > > in 2.4? With Scribus we found out that users actually demand it (on > > all platforms) and that it is safe, if sane defaults are used. > > Not sure yet. It depends on how well it works by then and if we manage > to find sane defaults. You can reuse default settings in Scribus (those applicable ones) ;-) Alexandre ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color management preferences not working and other CM stuff
On 1/16/07, Sven Neumann wrote: > We plan to have 2.6 out shortly after so I am currently postponing > pretty much everything related to color management to the 2.6 release. Is 2.6 going to be bugfix release or a first stable version using GEGL/babl? Alexandre ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color management preferences not working and other CM stuff
Hi, some of these things will be fixed for 2.4. But we can't delay the release any further and this means that color management is not going to be fully functional and usable in 2.4. We plan to have 2.6 out shortly after so I am currently postponing pretty much everything related to color management to the 2.6 release. Perhaps in the next development cycle, there will not only be people who point out problems and request features but also someone who wants to do the coding. Otherwise it might taken even longer before a full CM workflow is implemented. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color management preferences not working and other CM stuff
On Tuesday 16 January 2007 03:45, Hal V. Engel wrote: > 3. The file dialog does not have a way to show hidden directories that I > have been able to find other than typing in the path. This is probably > a GTK issue rather than a GIMP issue. Just right-click on the file list and you'll see a pop-up menu showing an option to let you display or not hidden files. This *is* a GTK issue ;o) -- Frédéric http://www.gbiloba.org pgpLRpsylEAg8.pgp Description: PGP signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Color management preferences not working and other CM stuff
I just built GIMP from subversion trunk. This did fix the lcms plugin error. But on my system the color management preferences are not working. Specifically when I try to change any of the profiles there are significant issues. At first I though that perhaps my configuration was corrupted but removing it and letting gimp recreate it did not fix the problem (#1 below). 1. After setting one of the profiles (for example the monitor profile) in the preferences dialog it disappears after the dialog is closed. Almost like I had pressed Cancel instead of OK. That is when reopening the dialog this is reset to (None). This is happening with all of the profile settings in the dialog. 2. The profile file dialog currently does not use system standard profile directories. I know that this will not be fixed in the upcoming release. 3. The file dialog does not have a way to show hidden directories that I have been able to find other than typing in the path. This is probably a GTK issue rather than a GIMP issue. But it does make the dialog more difficult to use if you keep your profiles in the Linux standard user location for these files (IE. ~/.color/icc). I know this will not be fixed for 2.4 but would it be possible to set this up so that it at least remembers where the user last opened a profile and defaults to that location instead of always opening in the current directory? That way once I open a profile in ~/.color/icc the dialog would open in that same location the next time. 4. The file type filter on the profile file dialog is limited to *.icc or all files. Since profiles can also have a .icm extension that needs to be added to the ICC Profile filter. 5. Of course this has already been touched on but most applications that do color management do not present users with lists of files names for profiles. Rather they use a widget that parses the profiles in (at least) a given directory or, better, all system standard locations for profiles and uses the profile description tag to build a list of available profiles for the user. In addition, these widgets usually will also filter the profiles and only present users with a list of those that are of the correct type for the current context (IE. only display profiles if a user is selecting a monitor profile). In general profile file names tend to be rather cryptic and the description tag tends to be more user friendly. Unfortunately writing such a widget is somewhat involved and the only GTK application that I know of that has this feature is Cinepaint. All of the other open source apps that do this that I know about are QT based (LProf, Scribus and Krita). I know that this will not make it into 2.4 but it does need to get done at some point. Perhaps this can make it into 2.4.1 or 2.5/2.6 or whatever version is next. There should also be a UI for users to: 1. Embed profiles into images. 2. Do color space conversions to images. These are both missing at this point. Separate and separate+ does some of #2 but is rather specialized (IE. looks like it should be part of a CMYK printing work flow). The color manager plugin by Jordi Canton has this functionality but likely needs to be updated to work with gimp 2.3 and would need some work to make the UI a little more user friendly. If these changes were made to this plugin it would be good to include this as part of GIMP. Perhaps this could be done as part of the next release but I would really like to see something like this in 2.4. Without this implementing a full CM work flow is much more difficult for users. Hal ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] color management
Hi, The functions included in Separate+ are jointly used, so I think that it is appropriate that those are placed in the same submenu. I don't understand where the "Separate" menu should be placed. However, I don't have the sense of incompatibility very much even if it is in a present place. > Only context valid profiles should be suggested (see question 4 > above). It isn't what I should do. Appropriate widget will be added to the GIMP's core in the future. Then I will use it. > I would also merge "normal" and "to Colour" into one dialog with a > combobox or a radiobuttons group to switch between them and a hint > explaining the difference. Try Separate+ (20070115). I'm not good at English, and pardon the incompleteness of the explanation, please. -- Yoshinori Yamakawa [EMAIL PROTECTED] ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] color management
Hi, On Sat, 2007-01-13 at 13:35 +0300, Alexandre Prokoudine wrote: > 1. Is it planned to have separate+ as part of 2.4? There was some > mentioning of it in gimp-developer@, but the thread came from some > other mailing list or a private discussion, so no clues. I thought about having it in 2.4 but I think it's probably best distributed seperately until we find the time to integrate it properly. Since we are almost ready for 2.4, we should probably not add any new plug-ins at this point. > 3. Is it planned to support OpenIcc's initiative to look for profiles > in /usr/color/icc and ~/color/icc on Linux and standard profiles > directories on other systems? If no, why? Yes, we plan to support it at some point. But it's too late to implement this for 2.4. Fortunately though we are planning to release 2.6 shortly after and that should give us the chance to add a proper ICC profile selection widget that can be used from the core and from plug-ins. > 5. Main question: is color management going to be enabled by default > in 2.4? With Scribus we found out that users actually demand it (on > all platforms) and that it is safe, if sane defaults are used. Not sure yet. It depends on how well it works by then and if we manage to find sane defaults. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] color management
Hi, Since Sven proposed discussing 2.4 in mailing list and none of my questions/proposals are reflected in the bugzilla, here they are. Before you read any further, please note that I'm not trying to look smarter than you, I'm just initiating discussion ;-) Please prove me wrong where I am wrong. 1. Is it planned to have separate+ as part of 2.4? There was some mentioning of it in gimp-developer@, but the thread came from some other mailing list or a private discussion, so no clues. 2. If it is planned to have separate+ as part of 2.4, we need a better place for its menu entries and a better integration into core (more below). 3. Is it planned to support OpenIcc's initiative to look for profiles in /usr/color/icc and ~/color/icc on Linux and standard profiles directories on other systems? If no, why? 4. If the answer to 3) is "yes", is it planned to implement reading device classes from ICC profiles and group profiles in comboboxes in "Color management" tab of Preferences dialog, showing names and not filenames, which would improve usability? If it is planned to have separate+ as part of 2.4 and make GIMP read device classes, then Separate/Proof/Save dialogs will have to be redesigned in a consistent manner as well (more below). 5. Main question: is color management going to be enabled by default in 2.4? With Scribus we found out that users actually demand it (on all platforms) and that it is safe, if sane defaults are used. Now on separate+ plug-in. If there are some requirements it doesn't meet to be part of 2.4, what are those? Currently the functionality is spread across 5 dialogs: 1. Duotone. Traditionally people would expect this in /Image/Mode, but this duotone is not a real image mode, but an emulation. What would be the best place to your mind? 2. Proof. This should live in some obvious place in /Image/. Only context valid profiles should be suggested (see question 4 above). 3. Save. Ideally, this should be a "CMYK separated TIFF image" option in Save/Save As/Save As Copy dialogs. Only context valid profiles should be suggested (see question 4 above). 4. Separate (normal). I don't know, what's the best place in menu is. What do you think? 5. Separate (to Colour). Same as above. I would also merge "normal" and "to Colour" into one dialog with a combobox or a radiobuttons group to switch between them and a hint explaining the difference. It would be great hearing from you. Cheers, Alexandre ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color management -- softproof comments
Hi, On Mon, 2006-09-18 at 21:40 +0200, Peter Karp wrote: > I assume that RGB and CMYK space are the default spaces for new > pictures and that it can be assigend to untagged pictures? For what is > CMYK space used when Gimp does not support CMYK editing of files or > have I overseen that this will be possible with Gimp 2.3/2.4? The CMYK default colorspace is supposed to be used by the CMYK color selector as well as by plug-ins that want to offer export to CMYK. > 2) I loaded a picture which has an embedded profile, but I found that > the embedded profile is not honored (of course the mode "colormanaged > monitor" was active). > > That's a 'must have' for a colormanaged image editor. We know that. Colormanagement is still unfinished and it's not considered to do anything useful yet. You are loooking at a rough prototype. I hope that I can get back to hacking on color management soon. > 3) In addition to 2) I could not find an option to assign or in the > other case convert a file from one color space to the other. That's > also a very important function which is possible with lcms and which > must be present. > > 4) From 2) and 3) will follow that one has to make a decision what to > do when a picture profile does not match the default RGB working space > (as long as Gimp does not support CMYK editing). Photoshop allows to > choose > a) "no colormanagement" > b) assign profile (Combo box with installed profiles) > c) convert to profile (Combo box with installed profiles) This is all planned. Your comments are however quite useful and I would very much appreciate if you could have a look at color management again as soon as the implementation has come forward a little. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Color management -- softproof comments
Hi, I'm new to this list and just wanted to share some ideas and findings I have. I tried Gimp 2.3.11 for Windows. I don't have the option to compile gimp myself. This was the latest win binary I found. I hope the descritpions from me make sense, because I used the german version and I'm not sure which phrases are used for the english developer version. Not in the order of importance... 1) A tiny, but welcome improvement of the color settings could be to change the order from - Working Mode Rendering Intent Monitor Renderinig Intent Printer simulation RGB space CMYK space monitor profile printer simulation profile --- to group the items which belong together: --- Working Mode RGB space CMYK space monitor profile Rendering Intent Monitor printer simulation profile Renderinig Intent Printer simulation I assume that RGB and CMYK space are the default spaces for new pictures and that it can be assigend to untagged pictures? For what is CMYK space used when Gimp does not support CMYK editing of files or have I overseen that this will be possible with Gimp 2.3/2.4? I also assume that the printer simulation profile can be either an RGB or CMYK printer profile. A short tooltip which explains the basics could help there. 2) I loaded a picture which has an embedded profile, but I found that the embedded profile is not honored (of course the mode "colormanaged monitor" was active). That's a 'must have' for a colormanaged image editor. When a picture has an embedded profile and working mode "printer simulation" or "colormanaged monitor" is choosen the profile must be honored. 3) In addition to 2) I could not find an option to assign or in the other case convert a file from one color space to the other. That's also a very important function which is possible with lcms and which must be present. 4) From 2) and 3) will follow that one has to make a decision what to do when a picture profile does not match the default RGB working space (as long as Gimp does not support CMYK editing). Photoshop allows to choose a) "no colormanagement" b) assign profile (Combo box with installed profiles) c) convert to profile (Combo box with installed profiles) This would also be very useful to have :-) I like that in Gimp one can choose the rendering intent for the monitor profile. I hope my comments are helpful in improving the colormanaged part of the upcoming Gimp. Still very few applications offer full colormanagement support and I look forward to see Gimp enter this league :-) Best regards Peter ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color Management
Hi, Jay Cox wrote: Black point compensation is not a part of the ICC specification and is not currently available in any icc library that I know of. For the record: Black Point Compensation is supported by LCMS - you just supply a flag when building the transform... All the best, -- Alastair M. Robinson ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color Management
On Mon, 2005-08-08 at 23:31 -0700, Hal V. Engel wrote: > > View ==> Print Simulation (or SoftProof or Proof Setup?) > (currently is located in View ==> Display Filters which is confusing) > > Simulation (SoftProof or Proof?) Mode on or off (radio button or check box) > Printer Profile (drop down use profile path to get list) > Rendering Intent (drop down) > Black Point comp (check box) > Use Paper White (check box) (new - low priority) > Use Ink Black (check box) (new - low priority) > Just some notes for anyone thinking about implementing some of this: Black point compensation is not a part of the ICC specification and is not currently available in any icc library that I know of. Use paper white: requires ink black to be on also. Use an absolute colorimetric transform. Use ink black: I belive this option would be pretty simular to using an absolute colorimetric transform for the shadow, and a relative colorimetric transform for the highlight. I know this is possible with the argyll cms library, but I'm not sure about any others. (see the -w option to icclink) Neither ink black or paper white is on: Use a relative colorimetric transform. IMHO: Rather than trying to duplicate adobe's black point compensation, I think our time would be better spent exploiting argyll's device link profiles and image specific gamut mapping capabilities. more info on argyll at http://www.argyllcms.com Jay Cox [EMAIL PROTECTED] ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color Management
I reiter my desire to work in that modules. But do not have time to play the game of the bugs to learn the basis of the gimp programming. /*--*/ "If quality is important, sRGB is not an option" (From the European Color Initiative web page www.eci.org) Francisco Bernal Rosso Luz-color-fotografia Redacción y traducción Webpage at: http://pacorosso.blogspot.com http://www.geocities.com/pacorosso http://www.fotoforum.net/socios/b/b_f/fotos.htm http://www.michelle7.com/contributors/r/paco_rosso.htm > Hi, > > interesting how much effort is being spent lately on reiterating what > still needs to be done on color management. I think we have made a > rather detailed list of required changes for GIMP 2.4 and obviously > it's not quite there yet. I will get back to color management as soon > as the new foreground select tool is working good enough. Then, as > soon as the missing infrastructure for plug-ins and modules is added, > I could need some help with implementing the missing bits in plug-ins > and modules. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color Management
Hi, interesting how much effort is being spent lately on reiterating what still needs to be done on color management. I think we have made a rather detailed list of required changes for GIMP 2.4 and obviously it's not quite there yet. I will get back to color management as soon as the new foreground select tool is working good enough. Then, as soon as the missing infrastructure for plug-ins and modules is added, I could need some help with implementing the missing bits in plug-ins and modules. Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color Management
On Saturday 15 January 2005 05:37 pm, Sven Neumann wrote: snip > Let's try to implement this in small steps then. As a first step I > would like to add a couple of options to the preferences to allow > users to define default locations for color profiles, to > enable/disable color management and to set a number of default > settings. Stefan Döhla sent me a patch last year that implements this > and I will probably base the changes on that. The settings he > suggested are: > > - use CM or not > - display profile > - default workspace profile > - default rendering intent for color conversion >+ from workspace to display (default set in display profile) >+ from workspace to printer (should default to >* perceptual for pictures >* relative colorimetric for most other work) > - default cmyk-profile (is later used to convert RGB->CMYK) > - default profile path (/usr/share/color/icc/ and ~/.color/icc/) > > As soon as we have such settings, we need to figure out a way to make > them available to plug-ins and modules. We also need an API to access > the color-profile attached to an image. > > > Sven Sorry for such a long note. I have been playing around with the 2.3.2 snap shot and it looks like much of the above is working. It also gave me some ideas about what needs to be done and also how the menus for this could be structured. I thought that perhaps some of this is allready underway and in CVS. So I got a copy of CVS and tested it. I did not see any noticeable changes. Things that need to be implemented: 1. Currently embedded profiles are not used. This needs to be implemented. The gimp-color-management plug-in (by Jordi Canton <[EMAIL PROTECTED]>) looks like it has the code needed to read in an embedded profile and could be leveraged to get this functionality. Highest priority of any CM work. 2. Default Profile Paths need to be implemented. This should be user modifiable. On open source systems it should be set to ~/.color/icc:/usr/share/color/icc by default and the user should only be able to add additional locations to this path (not sure about the last part). On open source systems The GIMP installation should create these directories if they do not exist (? not sure about this). On closed source systems the system default locations should be used. On Windows XP this would normally be C:\windows\system32\spool\drivers\color. I don't know what it is on a Mac. Medium to low priority. 3. Menu items to assign profiles to images and to convert images between color spaces needs to be implemented. There is already a plug-in available that sort of does this (gimp-color-manager). It is on the rough side and has a more complex UI than is really needed and the UI confusing. This either needs to be simplified and cleaned up or just used to pull out needed functionality for implementing a cleaner UI. High priority. 4. Some (image acquisition) plug-ins will need a way to pass profile information into GIMP. For example UFRAW (recommended) is a RAW conversion utility that runs both stand alone and as a GIMP plug-in. It is CM aware and it can embed user specified profiles and optionally convert images from that device profile to a working space profile. In standalone mode it can save the image file with an embedded profile. Currently it has no way to pass the profile information to GIMP when running as a plug-in. Medium priority. Here is a proposal for how the color management related menus could be structured. It leverages what is allready there but tries to make the intent of each item clearer and easier to understand if possible. It also implies certain functionality that needs to be implemented. Global CM configuration menus located in: File ==> Preferences ==> Color Management Color Management on (check box) (global flag to turn CM on or off. Default is off. If off all CM options, global or image specific, have no affect. This is currently missing.) Profiles Path dialog (see #2 above) Display (This could also be located in File ==> Preferences ==> Display) Try to obtain the monitor profile from the X server (check box) Monitor profile (drop down use profile path to get list of profiles) Rendering Intent (drop down) Desaturate monitor colors by ??? % (new - low priority) (This does not need the current Mode of operation drop down. see Color Management on item above and Print Simulation item below.) Color Management Policies Working Color Spaces (These are the RGB and CMYK profiles in the current GIMP preferences menu) RGB (drop down use profile path to get list) CMYK (drop down use profile path to get list) Grey (drop down use profile path to get list) (new) Profile Mismatches On Opening ask
[Gimp-developer] color management
Hi, just wanted to let everyone interested know that I started to add code for color management to GIMP CVS. For now, all we have is a configuration object that is supposed to be visible by the core, modules and plug-ins. This is based on a patch that Stefan DÃhla mailed me last year. The next steps I plan to do are: - add a color management page to the preferences dialog - establish a framework for passing the color management settings to modules and plug-ins - give color display modules access to image parasites, or at least to the "icc-profile" parasite - replacement of the proof display filter by a slightly more complex color display module that deals with monitor profile and printer profile based on the user's color management settings - move the display color management module out of the display filter configuration dialog and add it automatically to all image displays - use the cms module from all color areas and color selectors - add a plug-in to apply color profiles - deal with embedded color profiles on image load - ... So if you want to participate in this development or just check that the right things are being done here, you should consider to follow CVS. I also do not insist on doing all coding myself. There are a couple of tasks that could very well be "outsourced". Let me know if you want to help. Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color Management was GEGL development/gimp integration
Am Samstag 15 Januar 2005 23:42 schrieb Gerhard Gaußling: > Photoshop lets pop up a dialog where the user can decide the kind of > conversion he will do for the pasted/dragged image Of course only if the source color space of the imported (pasted/dragged) image is different from the working color space. As I mentioned before the working color space is also meant as 'device independent' like recommended by eci.org, and there for suitable for archives. (The recommendations might be different for the US and other non-european states: there it might be recommend to use AdobeRGB as wotrking color space - and WebCoatedSWOPv2v as printing profile ). If the archived files are saved in (the recommended wide working color space such as eciRGB or AdobeRGB, or WideGammut) the appropriate color space, then it can be imported without flaws (w.o. popup window with the selection dialog) into theGIMP. regards Gerhard ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color Management was GEGL development/gimp integration
Hi, "Hal V. Engel" <[EMAIL PROTECTED]> writes: > I didn't think we were talking about user interface issues. Rather > this is about how the image data is handled while it is being > manipulated by the GIMP. Specifically should there be a color space > transformation as part of loading the image and another when the > image is saved. Well, at this point we are rather talking about preparing the framework that we will need to implement color management. How exactly this is all wired up and presented to the user remains to be seen. Your feedback will certainly help with this. > I think I already did but not in great detail. My main point is that > the color space of the users image should ALWAYS be untouched unless > the user specifically asks for a transformation. There are a number > of cases where the image must go through a color space transformation > but only a limited set of these should affect the actual image data. If we don't convert the image at load time, all plug-ins that change colors would have to be aware of the color-space the image is in. Since this is not the case for the time being, it would probably be a bad idea to not convert the image. As soon as we go further down the road and have all plug-ins as GEGL ops, this will change. But for the time being, I don't see much choice but to convert everything to sRGB. Note that we are just talking about the first step here. Something that we can achieve in the next few months, without changing each and every piece of code in GIMP and it's plug-ins. Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color Management was GEGL development/gimp integration
On Monday 03 January 2005 14:27, Sven Neumann wrote: snip > > I don't think we rejected this part. IIRC we said that it should be > optional and that we want to allow people to disable color management > entirely. Anyway, whatever we decide to do is just a matter of user > interface and doesn't affect the GEGL operators involved. > I didn't think we were talking about user interface issues. Rather this is about how the image data is handled while it is being manipulated by the GIMP. Specifically should there be a color space transformation as part of loading the image and another when the image is saved. Yes the user should be able to turn color management off if they want. In fact I think that at install time it should be off by default. Color management is not for all users as it requires a lot of work to understand how it works, to setup a good work flow and to get good device profiles (printers are particularly difficult). So color management is really only for those that are graphics and photo professionals and hard core amateurs. Anyone not prepared to do a lot of work to get this right should not bother with it. snip > Sure, that's much appreciated. Perhaps you want to suggest a better > design then? > I think I already did but not in great detail. My main point is that the color space of the users image should ALWAYS be untouched unless the user specifically asks for a transformation. There are a number of cases where the image must go through a color space transformation but only a limited set of these should affect the actual image data. 1. When the image is acquired. The image may either remain in the device color space or be transformed to the users preferred working color space. Either way that then becomes the image color space. As an example a scanned image might initially be tagged with the color space profile of the scanning device by the scanning software and then optionally converted to the users working color space either in the scanning software or the image software. In Photoshop the user can setup Photoshop to do several different things when am image is opened and the embedded profile is not the same as the default (user selected) working profile. a. If no profile is embedded in the image ask the user if one should be and allow the user to select the profile. So if your scanning software was not "color aware" (like sane) you could embed the correct device profile here and then optionally convert the image to the (user selected) working color space. b. Do nothing and use the embedded profile. c. Ask the user if they want the image converted to the default (user selected) working color space. d. Automatically convert all images to the default (user selected) working color space. In this case the transformation is automatic but the user has specifically requested that this happen. High end scanning software like VueScan Pro and SilverFast AI can also be configured to support conversion from the device color space to a user specified working color space. This software scans the image then converts it to the working profile using the device profile as the starting point for the conversion. As a side note Vuescan Pro is available for Linux for $79 and supports all scanner supported by sane. This is one of the few cases where it is normal for an image to have a color space transformation that affects the actual image data. 2. Before sending the image to a printer the image will be optionally converted from the image color space to a user selected printer color space. But this is only done to a copy of the image as it is being sent to the printer. This could also happen in the print driver. I would personally prefer that the print driver handle this as this would allow for the printer to be color managed from all software not just "color aware" software. In Photoshop the user selects File ==> Print with preview. In the dialog the user can select how the color transformation will happen by selecting both the from and to color profiles and the conversion intent (same as image(AdobeRGB1998) to Epson1280-1440 intent is perceptual with black point compensation - would be typical settings). 3. When the image is sent to the display device it will be converted from the image color space to the display color space. Again like images going to a printer (#2 above) this will be done to a copy of the data not to the original image. 4. The user can at any time pull up a menu and force a color space conversion to an image. I have never used this functionality in Photoshop. Others may have work flows that require this functionality such as those that work on images for customers that require that the final images be in a specific color space. Color work flows will vary depending on what the user is trying to do. But once someone has a good color work flow they will stick to it in every detail. M
Re: [Gimp-developer] Color Management
Hi, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes: > The display filter for gamma is nice, but > it should be accompanied by some linear > adjustment of brightness and contrast. > (That contrast filter that's there just > doesn't do the trick!) That contrast filter is not meant to be used for adjusting contrast. It is meant to be used to visualize very subtle color changes that are otherwise invisible. Writing a display filter for brightness/contrast adjustment would be trivial. Why don't you just do it? Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color Management
The display filter for gamma is nice, but it should be accompanied by some linear adjustment of brightness and contrast. (That contrast filter that's there just doesn't do the trick!) I looked into using ICC profiles, but that would be too difficult to adjust easily. Perhaps a mechanism for saving a set of display filters into a display profile could be adopted. (note how dark and ugly stuff looks on a CRT that looked fine when developed on an LCD without a display filter to compensate - so this is a great way to help compensate for that problem) The best thing to hit the Internet in years - Juno SpeedBand! Surf the Web up to FIVE TIMES FASTER! Only $14.95/ month - visit www.juno.com to sign up today! ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color Management
Hi, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes: > What's the easy way to get an ICC color profile? > I'd like to look at an image on my display and > on the wall simultaneously and tweak the profile > until the display matches the wall. But I don't > see any kind of GUI to accomplish this. Do I have > to create the profile by entering some numbers with > a text editor? or am I missing something here? You will need software that allows to create ICC profiles. Please use google to find such software. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color Management
]> I use GIMP to touch up photos before projecting ]> them on a wall. The washed out effect of a projector ]> might be nice to see while editing the image on ]> a different device. (i.e. use a filter to preview ]> approximately what it would look like being viewed ]> with a different device). ]> ]> Maybe this is a different feature, but it seems ]> like some kind of display filter would be helpful ]> in this scenario. ] ]You should be able to achieve this using the proof display filter. ]All you need is an ICC color profile that simulates the projector. ] ] ]Sven What's the easy way to get an ICC color profile? I'd like to look at an image on my display and on the wall simultaneously and tweak the profile until the display matches the wall. But I don't see any kind of GUI to accomplish this. Do I have to create the profile by entering some numbers with a text editor? or am I missing something here? The best thing to hit the Internet in years - Juno SpeedBand! Surf the Web up to FIVE TIMES FASTER! Only $14.95/ month - visit www.juno.com to sign up today! ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color Management
Hi, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes: > I use GIMP to touch up photos before projecting > them on a wall. The washed out effect of a projector > might be nice to see while editing the image on > a different device. (i.e. use a filter to preview > approximately what it would look like being viewed > with a different device). > > Maybe this is a different feature, but it seems > like some kind of display filter would be helpful > in this scenario. You should be able to achieve this using the proof display filter. All you need is an ICC color profile that simulates the projector. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Color Management
I use GIMP to touch up photos before projecting them on a wall. The washed out effect of a projector might be nice to see while editing the image on a different device. (i.e. use a filter to preview approximately what it would look like being viewed with a different device). Maybe this is a different feature, but it seems like some kind of display filter would be helpful in this scenario. _-Ted The best thing to hit the Internet in years - Juno SpeedBand! Surf the Web up to FIVE TIMES FASTER! Only $14.95/ month - visit www.juno.com to sign up today! ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color management: conclusions?
Hi, David Neary <[EMAIL PROTECTED]> writes: > > > Finally, a question: How is a plugin supposed to go about storing > > > persistent data between sessions (i.e. in my case, the filenames of > > > the profiles last used)? > > > > The plug-in can attach a persistent parasite to gimp. > > Are parasites ever saved across sessions? I didn't think they > were. Persistent parasites are saved of course. Otherwise they wouldn't be persistent. This also implies that the plug-in authors should be careful with persistent parasites. They would better be able to parse any parasite they set in an earlier version (or at least detect that the format changed and gracefully ignore it). Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color management: conclusions?
Hi, Sven Neumann wrote: > "Alastair M. Robinson" <[EMAIL PROTECTED]> writes: > > > Finally, a question: How is a plugin supposed to go about storing > > persistent data between sessions (i.e. in my case, the filenames of > > the profiles last used)? > > The plug-in can attach a persistent parasite to gimp. Are parasites ever saved across sessions? I didn't think they were. 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: conclusions?
Hi, "Alastair M. Robinson" <[EMAIL PROTECTED]> writes: > Finally, a question: How is a plugin supposed to go about storing > persistent data between sessions (i.e. in my case, the filenames of > the profiles last used)? The plug-in can attach a persistent parasite to gimp. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color management: conclusions?
Hi Sven, Sven Neumann wrote: I wrote this in an earlier mail already but perhaps you didn't notice, so here's my question again: Sorry, yes I did miss that... I wonder if we should add the separate plug-in to the GIMP tarball for GIMP 2.2. Would you like to see that happening? I'd be delighted - though there are a few bugs I'd like to fix first! If it's going to become semi-official, though, I guess some discussion is needed about various points: 1. Where in the menus it should live. Currently, my functions are in Image->Separate. The separation is, however, performed on the current layer, not the whole image. The separation functions themselves are really not much more than a colour-profile-aware version of the compose/decompose code that's there already, so maybe alongside those would be the best place. Alternatively, depending on how far we get with colour-management in general, a new top-level Colour Management menu might be a better option? 2. Should the saving function be left with the separation functions, or be moved into the TIFF plugin. 3. How about adding support to the TIFF plugin for loading CMYK images into individual greyscale layers, thus solving the biggest limitation that the separate plugin currently has, i.e. not being able to load its own images back in. (This would have to be an alternative option to converting the CMYK data to RGB using lcms, if we implement that, or using libtiff's own Everything->RGBA converter.) Does anyone else want to bring up any further points? Finally, a question: How is a plugin supposed to go about storing persistent data between sessions (i.e. in my case, the filenames of the profiles last used)? 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: conclusions?
Hi, David Neary <[EMAIL PROTECTED]> writes: > > I wrote this in an earlier mail already but perhaps you didn't notice, > > so here's my question again: > > > > > I wonder if we should add the separate plug-in to the GIMP tarball > > > for GIMP 2.2. Would you like to see that happening? > > I would. I assumed you were asking Alastair, though. I do, that's why I sent my mail To: "Alastair M. Robinson". Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color management: conclusions?
Hi, Sven Neumann wrote: > I wrote this in an earlier mail already but perhaps you didn't notice, > so here's my question again: > > > I wonder if we should add the separate plug-in to the GIMP tarball > > for GIMP 2.2. Would you like to see that happening? I would. I assumed you were asking Alastair, though. Also, I found another color management plug-in for the GIMP (pretty old, and I haven't looked at it in depth yet, but it's someone else who has looked into the issue and might save us some work): http://www.khk.net/color/color_manager.html 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: conclusions?
Hi, I wrote this in an earlier mail already but perhaps you didn't notice, so here's my question again: > I wonder if we should add the separate plug-in to the GIMP tarball > for GIMP 2.2. Would you like to see that happening? Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color management: conclusions?
Hi, "Alastair M. Robinson" <[EMAIL PROTECTED]> writes: > Sure, but the plugin will depend on the implementation of the other > stages. The guts of the plugin, thanks to lcms, will be pretty > trivial - far simpler than the separate plugin; the most important > factor will be the design of its user interface, and supporting > factors, e.g. do we support tagging images both with an actual > profile, or with the filename of a profile, and such like. Well, adding a few gimprc options takes a couple of minutes only and that should be all that is needed for now. We already support tagging images with a profile. the suggested parasite name for this is currently "icc-profile" and we should try to keep this for backward compatibility. Of course we will need to define some more parasites. Perhaps someone could sit down and propose the parasites we will need for color management. > There are a couple of other issues that might warrant discussion > with the developers of lcms; how to go about comparing profiles for > equality for instance (we want to be able to avoid converting > between an embedded profile and the working space if they are in > fact the same profile!) Does lcms provide an API for this? Sven PS: I wonder if we should add the separate plug-in to the GIMP tarball for GIMP 2.2. Would you like to see that happening? ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color management: conclusions?
Hi Sven, Sven Neumann wrote: "William Skaggs" <[EMAIL PROTECTED]> writes: So at the most concrete possible level, here is a suggestion on how to start: Step 1: Add a "Color Management" page to the Preferences. Step 2: Add "enable/disable color management" and "working colorspace" options to the page. To start with, sRGB will be the only option for the latter, but the infrastructure should not build in any assumption that this will always be true. GIMP really won't care what this working space is; as far as the core is concerned it's just a filename, so why limit it to sRGB even temporarily? Step 3: In the file-loading code, after an image has been loaded, check for the presence of parasites called either "icc-profile" or "colorspace". If one of these is found, execute the color management plug-in. Step 4: Write a color management plug-in. Sounds good except that Step 4 should be first. Sure, but the plugin will depend on the implementation of the other stages. The guts of the plugin, thanks to lcms, will be pretty trivial - far simpler than the separate plugin; the most important factor will be the design of its user interface, and supporting factors, e.g. do we support tagging images both with an actual profile, or with the filename of a profile, and such like. There are a couple of other issues that might warrant discussion with the developers of lcms; how to go about comparing profiles for equality for instance (we want to be able to avoid converting between an embedded profile and the working space if they are in fact the same 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: conclusions?
Hi, "William Skaggs" <[EMAIL PROTECTED]> writes: > So at the most concrete possible level, here is a suggestion on > how to start: > > Step 1: Add a "Color Management" page to the Preferences. > > Step 2: Add "enable/disable color management" and "working > colorspace" options to the page. To start with, sRGB will > be the only option for the latter, but the infrastructure > should not build in any assumption that this will always > be true. > > Step 3: In the file-loading code, after an image has been > loaded, check for the presence of parasites called either > "icc-profile" or "colorspace". If one of these is found, > execute the color management plug-in. > > Step 4: Write a color management plug-in. Sounds good except that Step 4 should be first. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color management: conclusions?
So at the most concrete possible level, here is a suggestion on how to start: Step 1: Add a "Color Management" page to the Preferences. Step 2: Add "enable/disable color management" and "working colorspace" options to the page. To start with, sRGB will be the only option for the latter, but the infrastructure should not build in any assumption that this will always be true. Step 3: In the file-loading code, after an image has been loaded, check for the presence of parasites called either "icc-profile" or "colorspace". If one of these is found, execute the color management plug-in. Step 4: Write a color management plug-in. 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
[Gimp-developer] Color management (addendum)
Hi all, Here's how cinepaint is doing color management: http://cinepaint.bigasterisk.com/CinePaintColourManagementUserDocumentation The page is a number of usecases, explaining what happens in each case. It is basically similar to many of the things that we have been saying, perhaps a little complicated to configure, but it seems from the feedback that I have seen that several people are quite happy with it. This is for informational purposes, since we are talking about usecases for this. Cheers, Dave. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color management: conclusions?
Hi, David Neary <[EMAIL PROTECTED]> writes: > The two propositions are (or seem to be): > > 1) Apply embedded profiles (after prompting the user whether they > would like to do that) at load time, or attach the profile to the > image at load time and use the raw image data, assuming that sRGB > (or some other colourspace) is the internal colourspace all the > time. > > 2) Allow the user to set the internal colourspace, and warn when > an attached colourspace does not match the current internal one, > allowing the user to either apply the profile to convert to the > current colourspace, set the internal colourspace to the new one, > or not use the colour profile for the image. I don't see how (2) could work without adding color management throughout the application and most plug-ins. This is certainly a goal for the time with GEGL but nothing that we should target for 2.2. It seems to me that (1) is the best solution for now. I propose however that we keep most of this functionality in a color-management plug-in. Such a plug-in would offer to apply color profiles and to change the color profile attached to an image. Combined with a color display filter to handle the monitor profile this would keep the lcms dependency to a few defined places and would still allow us to add some basic color management. This should allow us to collect some experiences in this new area. Experience that should help us to get color management right in GEGL. > I was talking to Sven on IRC, and he seemed to believe that neither > of these would be done for 2.2, and that only the infrastructure > which would allow these to be done easily post-2.2 (when we hope to > have higher bitdepths internally for image data). At least, that's > what I think he said, but I didn't really follow. I think that we should focus on adding the API that is needed to implement some basic but useful color management in plug-ins and modules. Whether this means that 2.2 will include these plug-ins and modules or if they will be developed separately (and perhaps even after 2.2 is released) remains to be seen. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Color management: conclusions?
Hi all, So as I was saying on gimp-user, we have had a really good chat about this now, but it seems that we are still unclear about what we hope to do in the area of colour management between now and 2.2. Who is prepared to put some time (perhaps a lot) into implementing this? What exactly would they implement? There seem to be 2 solid propositions coming out of the discussions, which agree on a number of points. The points of agreement are: 1) Color management should be disablable. 2) The monitor's profile should be applied to the projected image as a last step before displaying. The monitor profile could also be applied pretty much everywhere that the GIMP exposes colour in its interface. The two propositions are (or seem to be): 1) Apply embedded profiles (after prompting the user whether they would like to do that) at load time, or attach the profile to the image at load time and use the raw image data, assuming that sRGB (or some other colourspace) is the internal colourspace all the time. 2) Allow the user to set the internal colourspace, and warn when an attached colourspace does not match the current internal one, allowing the user to either apply the profile to convert to the current colourspace, set the internal colourspace to the new one, or not use the colour profile for the image. I was talking to Sven on IRC, and he seemed to believe that neither of these would be done for 2.2, and that only the infrastructure which would allow these to be done easily post-2.2 (when we hope to have higher bitdepths internally for image data). At least, that's what I think he said, but I didn't really follow. So - back to the essential - who, what (and when)? :-) 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
David, > So say I open an image with a color profile, and then load a > second image with a different profile. If I now decide to do the > above, what do we do to the first image? how about attaching a profile to each image? Correction is then done using the individual image's profile and the application-wide monitor profile. This gives you a lot of flexibility in the use of different profiles and saves you from having to switch the workspace profile back and forth. >From my own research on the matter, the way it is done in most apps and CMS workflows seems to use three profile settings: 1. a monitor profile 2. a default image profile 3. a working space profile The meaning of the monitor profile is obvious. The default image profile is assigned to images that don't have an embedded profile. The working space profile is a kind of preferred colour space, such as the in-house space of a studio. The workflow is then as follows: When an image is opened, it is assigned its embedded profile, or, if there is none, the default image profile. The assigned profile is then compared to the workspace profile. If they are identical, nothing happens, since the image already is in the user's working space. Otherwise, the user is notified of the fact that the image profile differs from the working space profile and is asked whether she would like to convert the image to the working space or to maintain its original profile. For ease of use there should be a preference setting that defines a default for this dialog and allows it not to be displayed (e.g. "always convert images to working space"). Display correction is then done based on the profile that was assigned to the image (which could be the embedded profile, the default image profile, or, if the image was converted, the workspace profile). Here the working space is more of a preference setting, a colourspace that the user prefers to work in. It is not necessarily used in the display correction (only if it is made the image's profile). In addition there are usually functions to assign a different profile to an image (only changes the attached profile, but doesn't manipulate the image data) or to convert an image to a different profile (changes the profile and the image data). Hope this is of any use Stef an ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] color management
On 12 Jul 2004 21:47:21 +0200, Sven Neumann <[EMAIL PROTECTED]> wrote:
> > loading of file !profile
> > "no color profile associated with image"
> > "convert from [sRGB (dropdown)]"
> > "save as [sRGB (dropdown)]"
> > parasite_set ("export_profile", users_choice)
>
> This means that we would need to open a dialog for almost every image
> file the user opens. Is that a good idea? Shouldn't we just assume
> sRGB in that case?
We should provide a checkbox in the dialog, asking that the dialog
newer be shown again, (it whould hide that part of the dialog, and a
preference would be used to toggle it back on).
/pippin
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] color management
Hi,
Øyvind Kolås <[EMAIL PROTECTED]> writes:
> new image
> parasite_set ("export_profile", "sRGB")
>
> loading of file profile==sRGB
> best scenario, just load the file
> parasite_set ("export_profile","sRGB")
>
> loading of file !profile
> "no color profile associated with image"
> "convert from [sRGB (dropdown)]"
> "save as [sRGB (dropdown)]"
> parasite_set ("export_profile", users_choice)
This means that we would need to open a dialog for almost every image
file the user opens. Is that a good idea? Shouldn't we just assume
sRGB in that case?
Sven
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] color management
I haven't read the whole thread, but the last mail in the thread by
William Skaggs seems very similar to the ideas discussed at gimpcon,
what follows is my own understanding of what we discussed there:
assuming working space of gimp == sRGB
new image
parasite_set ("export_profile", "sRGB")
loading of file profile==sRGB
best scenario, just load the file
parasite_set ("export_profile","sRGB")
loading of file !profile
"no color profile associated with image"
"convert from [sRGB (dropdown)]"
"save as [sRGB (dropdown)]"
parasite_set ("export_profile", users_choice)
loading of file profile!=sRGB
"image has a color profile attached"
"convert from [YUV (dropdown)]"
"save as [sRGB (dropdown)]"
parasite_set ("export_profile", users_choice)
displaying the image while working on it
this is actually the hardest thing to get right,. since it requires
user interaction
and cooperation,. even with a correct icc profile for the display the user can
introduce errors to the display by fiddling with the
brightness/contrast knobs.
saving when export_profile == sRGB
attach profile if possible
saving when export_profile != sRGB
this is of course dependent upon the file supporting the intended
format, if it does
pixel data should be converted upon saving, and the correct profile attached.
/pippin
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] color management
It really isn't all that complicated. Here is all you need to do (this is basically what Sven outlined with a couple of extra details.) 1) Gimp uses the same color space internally for all images. This could be either sRGB or a user-selected one (in which case it is specified by a preference). 2) Gimp permits the use of a monitor profile to color-correct the display. A conversion is done between the working colorspace and the monitor colorspace -- the user is asked to choose the intent of the conversion as a preference (the normal choice would be "perceptual", but people setting things up for printing would sometimes make other choices). 3) When you open an image, if it does not have any color profile info, it is assumed to be in Gimp's working colorspace. If it does, then you are asked to choose between two options: a) convert it to Gimp's working colorspace. If you choose this, then you are asked to choose the conversion intent. b) use the RGB values from the image, without any correction. Whatever is done, a parasite is attached to the image describing it. 4) When you save an image, you have the option of converting it to a different colorspace and/or attaching a color profile if the file format supports it. It is a bad idea to change the working colorspace based on the image. Users need to be able to form an understanding of the relationship between what they see on the screen and the pixel values in the image. It will drive people nuts if 255,255,255 looks gray at one time and white at another. That's what will happen if the working colorspace is flopping around all the time. 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 Dave, David Neary wrote: So say I open an image with a color profile, and then load a second image with a different profile. If I now decide to do the above, what do we do to the first image? 1) We stop using the profile for the first image (and if the image window is open, this will obviously change the visual representation of the image), but keep it attached to the image so that we can re-save it with the image at save time I think this is the best bet - disable the colour-management filter for any images that don't use the current working profile. 2) We stop using the profile and propose the dialog with the 4 options the next time the image is activated (basically allowing us to change the working colorspace on demand, but this could get annoying, I guess) The easiest option is to provide a simple plugin that adds a couple of menu entries - for example: Image -> Colour Management -> Convert to working profile and Image -> Colour Management -> Use as working profile That sounds sane. I'm not quite sure how it would be implemented, but it probably involves having a color profile parasite attached to an image, with some kind of configuration parameter for the working colorspace and the monitor profile. I'm not 100% sure, but I think the TIFF plugin already attaches embedded profiles as a parasite, so they're preserved when the image is saved again. If so, we have a lead to follow! 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, Sven Neumann wrote: > David Neary <[EMAIL PROTECTED]> writes: > > 1) We stop using the profile for the first image (and if the > > image window is open, this will obviously change the visual > > representation of the image), but keep it attached to the image > > so that we can re-save it with the image at save time > > That doesn't sound feasible to implement. How would the other image > get notified about this change? There isn't any notification about > parasite changes. Yeah - fair point. The changing colorspace has to get taken into account next time we activate the image, then - and we're back to option 2. 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 <[EMAIL PROTECTED]> writes: > So say I open an image with a color profile, and then load a > second image with a different profile. If I now decide to do the > above, what do we do to the first image? > > 1) We stop using the profile for the first image (and if the > image window is open, this will obviously change the visual > representation of the image), but keep it attached to the image > so that we can re-save it with the image at save time That doesn't sound feasible to implement. How would the other image get notified about this change? There isn't any notification about parasite changes. Sven ___ 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: > Given the limitations we're trying to work within, I think the best > compromise is likely to be something like this: > - Change the GIMP's working profile to match this image. This will > leave the image data untouched. (This should disable the display filter > for existing images, since they are presumably using a different profile.) So say I open an image with a color profile, and then load a second image with a different profile. If I now decide to do the above, what do we do to the first image? 1) We stop using the profile for the first image (and if the image window is open, this will obviously change the visual representation of the image), but keep it attached to the image so that we can re-save it with the image at save time 2) We stop using the profile and propose the dialog with the 4 options the next time the image is activated (basically allowing us to change the working colorspace on demand, but this could get annoying, I guess) 3) Something else I hadn't thought of? > - the user just needs to be made aware that colour-space transformations > are a destructive change, and have an opportunity to avoid them. That sounds sane. I'm not quite sure how it would be implemented, but it probably involves having a color profile parasite attached to an image, with some kind of configuration parameter for the working colorspace and the monitor profile. 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 Sven, Sven Neumann wrote: Well, it got to be doable in the file plug-ins since we don't want to have the core depend on lcms. Applying the embedded profile at load time could very well happen in the file plug-ins though. If the core needs to perform colorspace transformations then we should postpone this whole thing and do it properly with GEGL. Given the limitations we're trying to work within, I think the best compromise is likely to be something like this: - GIMP uses a user-selectable working profile. - If a user loads an image tagged with a different profile, she is presented with the following options: - Convert from the image's profile to the working profile, and accept the degredation that will result. - Change the GIMP's working profile to match this image. This will leave the image data untouched. (This should disable the display filter for existing images, since they are presumably using a different profile.) - Load the image without colour management, disabling the display filter for this image. - If a use loads an image with no profile, the display filter should be disabled. - A simple plugin should be available to fill in the gaps, i.e. tagging an image with a specific profile (for images with no profile), or converting an image to the current working space if it has changed. For the majority of users, this should suffice; I suspect compositing images with different profiles won't be a particularly common occurrence - the user just needs to be made aware that colour-space transformations are a destructive change, and have an opportunity to avoid them. 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 David, David Neary wrote: 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've done some testing - I wrote a little program that puts every possible 8-bit RGB colour through an lcms transform. A frequency table is kept of every colour that comes out the other side, which gives us some idea of how many codes are "lost" - how badly the dynamic range is reduced. First, as a control subject, I analyzed the gamma function at 1.1 and 0.6. The results are as follows: Gamma 1.1 Code use tally: 00: 1707993 01: 13481272 02: 1529388 03: 0 04: 57834 05: 0 06: 0 07: 0 08: 729 09: 0 In other words, 13,481,272 colours are mapped with a 1:1 ratio, so can be transformed back again without loss. 1,707,993 colours are missing from the destination set, and just under 1,600,000 colours are arrived at from multiple source colours. Gamma 0.6 Code use tally: 00: 7647887 01: 4251528 02: 3700404 03: 0 04: 1073574 05: 0 06: 0 07: 0 08: 103823 09: 0 Gamma 0.6 is considerably more destructive, only 1/4 of the codes maintain a 1:1 mapping. Now for AdobeRGB <-> sRGB: sRGB -> AdobeRGB1988 Code use tally: 00: 8102616 01: 4172676 02: 3175714 03: 438068 04: 538838 05: 66267 06: 124002 07: 23117 08: 48831 09: 87087 AdobeRGB1988 -> sRGB Code use tally: 00: 8012181 01: 8325155 02: 156167 03: 54498 04: 10468 05: 58725 06: 15054 07: 2108 08: 2129 09: 140731 This isn't as bad as I'd feared, but still considerably worse than either of the gamma tests. In both cases nearly half the codes in 8-bit RGB space are lost! This in effect reduced 24-bit RGB to 23-bit RGB. As I said, this isn't as bad as I'd feared - I was expecting to see a loss of nearly 1-bit per channel; in fact we lose only approximately 1-bit over the whole image. If anyone's curious enough to want the source of my test program, just ask :) 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 Neary <[EMAIL PROTECTED]> writes: > > 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. > > I may be listening to a different conversation. The other point was > whether embedded profiles should be applied at load time or be > factored into the projection. In this scheme, the core would have to > be at least aware of color profiles attached to images. It's not > simply a question of attach or apply, since one has implications for > the core, and the other doesn't. So this isn't just about the file > plug-ins. Well, it got to be doable in the file plug-ins since we don't want to have the core depend on lcms. Applying the embedded profile at load time could very well happen in the file plug-ins though. If the core needs to perform colorspace transformations then we should postpone this whole thing and do it properly with GEGL. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] color management
Hi, Quoting Sven Neumann <[EMAIL PROTECTED]>: > 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). I don't think there is any argument about that. It does make sense to apply the monitor's profile as the last step in the projection. > 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. I may be listening to a different conversation. The other point was whether embedded profiles should be applied at load time or be factored into the projection. In this scheme, the core would have to be at least aware of color profiles attached to images. It's not simply a question of attach or apply, since one has implications for the core, and the other doesn't. So this isn't just about the file plug-ins. Cheers, Dave. -- Dave Neary Lyon, France ___ 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
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
> 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] 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
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] 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
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, 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
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 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
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 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 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, "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: [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
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
