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
