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 (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 (UI perspective for GIMP 2.8)
On Sat, Feb 13, 2010 at 8:59 AM, SHIRAKAWA Akira shirakawa.ak...@gmail.com 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 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
