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
