Re: [Gimp-developer] Re: Color Management was GEGL development/gimp integration
The idea is to be able to use different color management systems and not to restrict ourselves to lcms. Yes !! Please. We should have the possibility to decide if use one or other CMS. /*--*/ Francisco Bernal Rosso Webpage at: http://www.geocities.com/pacorosso http://www.fotoforum.net/socios/b/b_f/fotos.htm http://www.michelle7.com/contributors/r/paco_rosso.htm ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Color Management was GEGL development/gimp integration
Hi, Hal V. Engel [EMAIL PROTECTED] writes: - default cmyk-profile (is later used to convert RGB-CMYK) I guess that this is for the printer? Since all of my printers are logically RGB devices (the drivers expect RGB input) I am not sure how useful this is to me but for others it might have it's uses. But perhaps we need to understand what this will be used for before including it. I am not sure what Stefan added this for in the first place but we will need a CMYK profile to be able to implement a useful CMYK color selector. We already have such a color selector but at the moment it uses a rather naive approach of converting between CMYK and RGB. When you are in the printer dialog in GIMP you have the ability to add a new logical printer and use that to name a collection of settings you wish to remember for future use. This is the ideal place for printer profiles to be specified. So the user should be able to set the default profile and rendering intents for each logical printer along with all of the other settings for the driver. This would be a way better setup than how this is handled in photoshop and would be a great way to simplify and facilitate the management this part of a CM work flow. We will let the print plug-in deal with this. Ideally the print plug-in would not be part of GIMP. Instead give the user the choice to pick his/her preferred print plug-in. Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Color Management was GEGL development/gimp integration
Sven Neumann wrote: 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. Hello Sven, Sorry for breaking the thread, but I was not able to find this message as mbox-archiv. I think that the suggestions made by Hal V. Engel and Jan-Peter Homann (a well known color management consultant in Germany, afair also a member of the eci.org maillist, a very good resource for cms knowledge)are very important for a professional color management in the GIMP. I'm not a Programmer, but isn't it possible to make a plug-in which load's the icc information at a first step, to offer the user the ability to decide in which way he wants to handle the file regarding it's color space? After this step the file will be converted into the choosed colorspace[*] and then loaded into the gimp, displayed in the working colorspace, corrected by the monitor profile, with the possibility to choose a color proof view with a selectable icc profile for the soft proof. Please, correct me if I'm wrong. [*] a. no colormanagement b. working colorspace (imho don't offer the user the ability to preselect the working color space in the preferences and instead convert all files into sRGB is the worst we can do) c. apply an icc profile and then as a suboption c1. convert it into the working color space. For Gimp-print we can handle the icc like Jan-Peter Homann suggested. I agree, that this behavior would be very close to the behavior of adobe photoshop regarding color-management, which got imho a very good implementation of a colormanagement for professional needs. There are good starting points by Alastair M.Robinson blackfive [ a t ] fakenhamweb.co.uk. He made a good start of such a plugin with it's 'separate' plugin: http://www.blackfiveservices.co.uk/separate.shtml He send me a copy of an improved version for gimp 2.x . Please see this thread in gimp user: http://article.gmane.org/gmane.comp.video.gimp.user/6008 He also works on a programm called photoprint: http://www.blackfiveservices.co.uk/photoprint.shtml based on guten print for gimp. (GIMP-Print/GutenPrint version 5 (beta 2)) for example photoprint.. quote o Can apply ICC colour profiles, with selectable rendering intent. o Can generate rough-cast ICC colour profiles, given RGB Primary chromaticity coordinates (x,y), Gamma values and White Point. o Can read and use an embedded colour profile (currently TIFF only). /quote He's working on CMYK support implemented with Argyll: quote Coming soon: Support for CMYK images and profiles (useful in combination with Argyll), and widgets for dealing with physical dimensions. [...] CMYK images are not yet properly supported, but I intend to support these in future. /quote I think it's very important for the future of the gimp, to handle color management in a proper and professional way, to get it on a professional level also for pre-press image processing. Is there an existing roadmap for this issue? Thank you Gerhard Gaussling ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Color Management was GEGL development/gimp integration
Hi Gerhard, Gerhard Gaußling wrote: I'm not a Programmer, but isn't it possible to make a plug-in which load's the icc information at a first step, to offer the user the ability to decide in which way he wants to handle the file regarding it's color space? It would be possible to do the following: - load image's raw data, and ICC profile - During display, convert from source colorspace to display colorspace - During saving, save the originally loaded ICC profile back to file, if the format supports it, or convert to sRGB if it doesnt. The problems with that approach are - Lots of elements in the GIMP are not colorspace aware - for example, you would have to modify the paint tools to detect whether there was an ICC profile associated with a display they were painting to, and color convert the (sRGB) data that they are painting. This is not possible currently, and Sven has expressed a desire that color management be kept out of the core in the past. - Data which enters the image from other sources (copy paste from another image, for example) may have been in a different colorspace, requiring convertion or some other funkiness to keep things coherent inside the image After this step the file will be converted into the choosed colorspace[*] and then loaded into the gimp, displayed in the working colorspace, corrected by the monitor profile, with the possibility to choose a color proof view with a selectable icc profile for the soft proof. We currently have the ability to do color proofs with external ICC profiles. THe interface to the loading of the profiles isn't perfect yet, but it's there. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] CV: http://dneary.free.fr/CV/ ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Color Management was GEGL development/gimp integration
Hi, Gerhard Gauling [EMAIL PROTECTED] writes: I think that the suggestions made by Hal V. Engel and Jan-Peter Homann (a well known color management consultant in Germany, afair also a member of the eci.org maillist, a very good resource for cms knowledge) are very important for a professional color management in the GIMP. Sure, noone questioned that. I think it's very important for the future of the gimp, to handle color management in a proper and professional way, to get it on a professional level also for pre-press image processing. Ditto. Is there an existing roadmap for this issue? No, we are only just in the process of making one. Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Color Management was GEGL development/gimp integration
Hi, David Neary [EMAIL PROTECTED] writes: ...Sven has expressed a desire that color management be kept out of the core in the past. You misunderstood me then. Managing colors does of course belong into the core but I would like to keep the implementation out of the core. The idea is to be able to use different color management systems and not to restrict ourselves to lcms. GEGL seems to offer just the right level of abstraction that would be needed here. That's why it seems like a nice idea to use it. Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Color Management was GEGL development/gimp integration
On Saturday 15 January 2005 13:21, David Neary wrote: Hi Gerhard, Gerhard Gaußling wrote: I'm not a Programmer, but isn't it possible to make a plug-in which load's the icc information at a first step, to offer the user the ability to decide in which way he wants to handle the file regarding it's color space? It would be possible to do the following: - load image's raw data, and ICC profile - During display, convert from source colorspace to display colorspace - During saving, save the originally loaded ICC profile back to file, if the format supports it, or convert to sRGB if it doesnt. I am not sure that the image should be converted to sRGB if the file format does not support embedded profiles. For one thing how likely is it that someone would open an image in a file format that had an embedded profile would then save the file in a format that did not support an embedded profile. The other reason that I have for this reservation is that many of us have printers that have more gamut than sRGB supports. sRGB is OK, even preferred, for web work and for those that are working with low gamut printers, such as CMYK offset printers, but my feeling is that it is too limited for those that have wider gamut printers like the 6 and 7 color Epson or HP printers for example. That is one of the reasons that Photoshop defaults to the AdobeRGB color space, which is a medium wide gamut color space, as this has enough gamut to fully support these wider gamut printers. If the GIMP is going to use a default color space this should not be a low gamut color space like sRGB. On the other hand anyone working with image file formats that do not support embedded profiles should have color management turned off. So perhaps someone can convince me that this is the correct thing to do. I think it would be useful for this list to talk about how The GIMP will work with color management turned on and with it turned off. As these 2 configurations will be used by users that are working at very different levels of expertise and with significantly different expectations. The problems with that approach are - Lots of elements in the GIMP are not colorspace aware - for example, you would have to modify the paint tools to detect whether there was an ICC profile associated with a display they were painting to, and color convert the (sRGB) data that they are painting. This is not possible currently, and Sven has expressed a desire that color management be kept out of the core in the past. At this point nothing in The GIMP is color aware other than the proofing plugin. So should every plugin need to do color conversions to the display color space or should this be handled in one place? Since current plugins know nothing about color management and color spaces should we be making assumptions about what color space these are working in (some plugin authors may have assumed sRGB but have all of them)? Since I have not looked at the code I do not know what should and should not be in the core. But perhaps some color management functionality belongs in the core. But I will let those that know how the application is structured work this out. But it seems to me that the core could have a high level color management interface that abstracts this to hide the specific implementation details. Then the core could map these to a specific implementation using LCMS, Argyll or some other CMS library. Perhaps this is what Sven had in mind. - Data which enters the image from other sources (copy paste from another image, for example) may have been in a different colorspace, requiring convertion or some other funkiness to keep things coherent inside the image Yes is is exactly correct. When we copy from image A in color space X to image B in color space Y the image data coming from A must be converted from color space X to color space Y. To do anything else would not be correct. After this step the file will be converted into the choosed colorspace[*] and then loaded into the gimp, displayed in the working colorspace, corrected by the monitor profile, with the possibility to choose a color proof view with a selectable icc profile for the soft proof. We currently have the ability to do color proofs with external ICC profiles. THe interface to the loading of the profiles isn't perfect yet, but it's there. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] CV: http://dneary.free.fr/CV/ ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer pgpQLbz5BjoR9.pgp Description: PGP signature
[Gimp-developer] Re: Color Management was GEGL development/gimp integration
Hello Sven, thank you for your reply! Sven Neumann wrote: Gerhard Gaußling [EMAIL PROTECTED] writes: Okay, so I assume, that my (and Hal's and Jan-Peter's) suggestions have to wait for the release after GEGL? For a new rendering-engine further to GEGL? GIMP 3.0? Why? Almost everything you listed can already be done in GIMP. It's just a bit akward to do it from a user interface point of view and that's what we want to improve for GIMP 2.4. This is good to hear! Desired is a 'On the fly' Softproof. Could you explain what you mean by on the fly softproof and how that is any different to the softproof that's available? What kind of softproof is available? Hmm.. I can nothing similar find here. I got under Image Separate Proof the possibility of an Softproof (plug in 'separate' by Alistair M. Robinson). It shows up a dialog which asks me the Source Profile /usr/lib/scribus/profiles/AdobeRGB1998.icc and the Destination Profile /usr/lib/scribus/profiles/USWebCoatedSWOP.icc (defaults, should be eciRGB.icc and isocoated.icc according to eci.org [1]) and the checkboxes Preserve Pure Black and Overprint Pure Black. If I press OK I got the message-dialog PROOF IMAGE Image is not separated So I have to separate the image first into cmyk mode by the plugin 'separate'. That's not a Softproof 'on the fly'. So I have to seperate the image first. I do it with the default profiles. A new image with the CMYK separated RGB shows up (5 layers, 4 layers CMYK mode 'darken only' 1 Background, Image in RGB Mode, if I save that it will be saved as cmyk tif). The 3rd step is to proof that image with the CMYK profile. A 3rd image pops up (RGB, 1 Layer)... That's Not a on the fly preview at all. Please, I'm sorry for my sad english, and I hope this all doesn't sounds to rude. I wanted only spend some Information of an user point of view, that's all... regards Gerhard [1] http://www.eci.org/eci/en/044_working_colour_spaces.php More information about the European Color Initiative and their work on standardisation of a color workflow: http://www.eci.org/eci/en/021_goals.php http://www.eci.org/eci/en/035_digital_photography.php http://www.eci.org/eci/en/050_news.php Here is some Information for download: http://www.eci.org/eci/downloads/ECI-en/eci_general_downloads/eci_whitepaper_1_1_ENG.pdf 46 page (~ 500 kB) Guidelines for device-independent color data processing in accordance with the ICC-Standard (Preview) Table of Content: Foreword 1. Objectives of the »European Color Initiative« 2. Objectives and Contents of the ECI-Guidelines 3. Commitment to Supporting the ICC-Standard 4. Establishing the Proof 4.1 »Idealized ICC-Proof« 4.2 »ICC-Proof« (»ICC Contract Proof«) 4.3 »ICC-Proof with Generic Profiles« (»ICC Contract Proof«) 4.4 »ICC-Soft Proof« 4.5 Proprietary Digital Proof Methods 5. Administrative Communication between »Data Supplier« and »Data Receiver« 6. Basic Workflow for Digital Processing of Printed Material 7. Technical Specifications for the Exchange of Advertisement Files 7.1 Exchange Format 7.2 Exchange Color Spaces 7.3 Overprinting and Trapping 7.4 Process and Data Control 7.5 Proofs 7.6 Data Exchange Media 8. Technical Specifications for the Exchange of Files for Catalogue Production 8.1 to 8.x 9. Technical Specifications 9.1 to 9.x Appendix 1: Recommendations for the Adaptaion of ICC-Workflows in Advertising Production Appendix 2: Recommendations for the Adaptation of ICC-Workflows in Catalogue Production Appendix 3: Recommendations for the Adaptation of ICC-Workflows in General Offset Production Appendix 4: Recommendations for the Adaptation of ICC-Workflows in Editorial and Publishing Techniques Appendix 5: Process Control The Ugra/FOGRA Media Wedge Appendix 6: »MediaStandardPrint« (not included) Appendix 7: The Corner Points of the ICC-Standard Appendix 8: »The 10 Commandments of Color Managements« Appendix 9: Example of a Measuring File in Accordance with the Color Chart ISO 12642 (IT8.7-3) ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Color Management was GEGL development/gimp integration
Hi Gerhard, Gerhard Gaußling wrote: What kind of softproof is available? Hmm.. I can nothing similar find here. It took me a while to find it too - it's under the View - Display Filters. In the resulting dialog you can choose from a number of filters, including Colour Proof. When we were discussing colour management a few months back, I hacked the Colour Proof filter to do a normal working-profile - monitor-profile transform, and it worked pretty well. The sticking point with the display filters is that there's currently no way of getting a reference to the current image into them. Without that, using a specific profile for individual images is next to impossible, and while we're restricted to 8-bit precision internally, that's pretty much a vital capability. 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] Re: Color Management was GEGL development/gimp integration
Hi, Gerhard Gauling [EMAIL PROTECTED] writes: What kind of softproof is available? Hmm.. I can nothing similar find here. Go to View-Display Filters and enable the Display Proof filter. Please, I'm sorry for my sad english, and I hope this all doesn't sounds to rude. I wanted only spend some Information of an user point of view, that's all... Your feedback is very much appreciated. Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Color Management was GEGL development/gimp integration
Hi, Alastair M. Robinson [EMAIL PROTECTED] writes: When we were discussing colour management a few months back, I hacked the Colour Proof filter to do a normal working-profile - monitor-profile transform, and it worked pretty well. Yes, it's a shame that you never submitted this for inclusion. It could have become part of the 2.2 release. The sticking point with the display filters is that there's currently no way of getting a reference to the current image into them. Without that, using a specific profile for individual images is next to impossible, and while we're restricted to 8-bit precision internally, that's pretty much a vital capability. 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 Dhla 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 ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Color Management was GEGL development/gimp integration
On Saturday 15 January 2005 17:37, 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 Dhla 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) I guess that this is for the printer? Since all of my printers are logically RGB devices (the drivers expect RGB input) I am not sure how useful this is to me but for others it might have it's uses. But perhaps we need to understand what this will be used for before including it. Also printer profiles are very specific to the printer hardware (not just the printer model but the specific printer you are using), the paper, ink and all of the driver setting (resolution, dither). So I have more than one printer profile for each printer (typically 5 or 6). When you are in the printer dialog in GIMP you have the ability to add a new logical printer and use that to name a collection of settings you wish to remember for future use. This is the ideal place for printer profiles to be specified. So the user should be able to set the default profile and rendering intents for each logical printer along with all of the other settings for the driver. This would be a way better setup than how this is handled in photoshop and would be a great way to simplify and facilitate the management this part of a CM work flow. - default profile path (/usr/share/color/icc/ and ~/.color/icc/) All of the other stuff looks fine to me. -- Hal V. Engel pgpabJ0gwQVKt.pgp Description: PGP signature
