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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
