Re: [Gimp-developer] Re: Color Management
Hi, Hal V. Engel [EMAIL PROTECTED] writes: What is needed for GIMP 2.4 are two very simple plug-ins that will do two things: 1. Allow the user to assign a profile to an image. This would pull up a dialog that allows the user to assign the default working space profile or select from a list of available profiles. 2. Allow the user to do a color space conversion. This would pull up a dialog that would have a from and to section. In the from section the user would be able to select either the embedded profile if one exited (otherwise this is gray) or from a list of available profiles. In the to section the user would be able to select either the default working space profile or from a list of available profiles. This could already be done using the current API except that there's not yet a profile chooser widget. But one could use GtkFileChooserButton for now until such a widget is written. The API to access the color management preferences does already exist since GIMP = 2.3.2. I would very much welcome some help here. If this can save code duplication, this could very well be done in a single plug-in that registers multiple menu entries. 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
On Wednesday 10 August 2005 04:15 am, Jordi Canton wrote: I disagree somewhat. IMO there should be a configurable profile search path similar to what we have for brushes, fonts etc. The user shouldn't have to select ICC profiles by selecting files. Instead there should be a profile selector. This widget would list all available profiles, showing info such as the profile vendor, profile intent and other meta information that can be extracted from ICC profiles. That is more or less the idea I have about it. The idea is to select the ICC profile, not the file. I think we all agree on this the UI should present a list of profiles, not files, to the user. I suppose that the new plug-in API will have functionalities to get the: Embedded ICC profile (get/set) Profile search path (or alternatively list of available profiles) Do you have more or less the list of the new API ICC funcionalities? They will help me to clarify the actual user interface which actually looks like: http://www.virtual-sub.org/images/upload/abulmacolor2.jpg I agree that it can be improved. Jordi, You current plug-in is a good fit for GIMP 2.2 but it implements way too much stuff for GIMP 2.4 since the apparent plan is to have GIMP wide CM policies that are set in file == preferences == color management. So the policy stuff in your plug-in will not be needed. What is needed for GIMP 2.4 are two very simple plug-ins that will do two things: 1. Allow the user to assign a profile to an image. This would pull up a dialog that allows the user to assign the default working space profile or select from a list of available profiles. 2. Allow the user to do a color space conversion. This would pull up a dialog that would have a from and to section. In the from section the user would be able to select either the embedded profile if one exited (otherwise this is gray) or from a list of available profiles. In the to section the user would be able to select either the default working space profile or from a list of available profiles. Hal ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Color Management
Hello, Hal wrote: 1. Currently embedded profiles are not used. This needs to be implemented The gimp-color-management plug-in (by Jordi Canton [EMAIL PROTECTED]) looks like it has the code needed to read in an embedded profile and could be leveraged to get this functionality. Highest priority of any CM work. Actually the plugin is reading the profile attached as parasite. Last time I checked, only the TIFF files were abe to read/write the profiles as color parasites. There is no problem to read the color profile as parasite but the read/write color profile should also be implemented in the other file formats wich support embeebed color profiles (i.e. jpg) 2. Default Profile Paths need to be implemented. This should be user modifiable. On open source systems it should be set to ~/.color/icc:/usr/share/color/icc by default and the user should only be able to add additional locations to this path (not sure about the last part). On open source systems The GIMP installation should create these directories if they do not exist (? not sure about this). On closed source systems the system default locations should be used. On Windows XP this would normally be C:\windows\system32\spool\drivers\color. I don't know what it is on a Mac. Medium to low priority. I agree, the use of directories to store the profiles provides an easy and quick way to select the different profiles. 3. Menu items to assign profiles to images and to convert images between color spaces needs to be implemented. There is already a plug-in available that sort of does this (gimp-color-manager). It is on the rough side and has a more complex UI than is really needed and the UI confusing. This either needs to be simplified and cleaned up or just used to pull out needed functionality for implementing a cleaner UI. High priority. Well, obviouslly I am not a great interface designer ;). Although I improved it using some of the users suggestions it is really difficult to desing a simple interface wich supports all the different plugin funcionalities. I will appreciate any further suggestion wich clarifies the plugin interface. -- Jordi Cantón mailto:[EMAIL PROTECTED] http://www.Virtual-Sub.Org ___ 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
Hi, Jordi Canton [EMAIL PROTECTED] writes: Actually the plugin is reading the profile attached as parasite. Last time I checked, only the TIFF files were abe to read/write the profiles as color parasites. There is no problem to read the color profile as parasite but the read/write color profile should also be implemented in the other file formats wich support embeebed color profiles (i.e. jpg) I have added support for reading and writing embedded ICC profiles to the JPEG plug-in a while ago. What's missing is integration with GIMP's color management and that depends on some changes to the plug-in API that are still pending. 2. Default Profile Paths need to be implemented. This should be user modifiable. On open source systems it should be set to ~/.color/icc:/usr/share/color/icc by default and the user should only be able to add additional locations to this path (not sure about the last part). On open source systems The GIMP installation should create these directories if they do not exist (? not sure about this). On closed source systems the system default locations should be used. On Windows XP this would normally be C:\windows\system32\spool\drivers\color. I don't know what it is on a Mac. Medium to low priority. I agree, the use of directories to store the profiles provides an easy and quick way to select the different profiles. I disagree somewhat. IMO there should be a configurable profile search path similar to what we have for brushes, fonts etc. The user shouldn't have to select ICC profiles by selecting files. Instead there should be a profile selector. This widget would list all available profiles, showing info such as the profile vendor, profile intent and other meta information that can be extracted from ICC profiles. 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
I disagree somewhat. IMO there should be a configurable profile search path similar to what we have for brushes, fonts etc. The user shouldn't have to select ICC profiles by selecting files. Instead there should be a profile selector. This widget would list all available profiles, showing info such as the profile vendor, profile intent and other meta information that can be extracted from ICC profiles. That is more or less the idea I have about it. The idea is to select the ICC profile, not the file. I suppose that the new plug-in API will have functionalities to get the: Embedded ICC profile (get/set) Profile search path (or alternatively list of available profiles) Do you have more or less the list of the new API ICC funcionalities? They will help me to clarify the actual user interface which actually looks like: http://www.virtual-sub.org/images/upload/abulmacolor2.jpg I agree that it can be improved. -- Jordi Cantón mailto:[EMAIL PROTECTED] http://www.Virtual-Sub.Org ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: color management
I just released version 0.1.0 of the gimp-color-manager plugin. Important changes since last version: -Re-design of the user interface in order to clarify the workflow (Thanks to Hal suggestions) -I correct several bugs found in the code -Now it should also work on a windows box. I made a revision of all the file paths making them platform independent -A transformation from embedded profile to default work space profile can also be made -All the other changes Hal commented in his review of pre-0.0.10 It can be downloaded from ftp://www.virtual-sub.org/gimp-color-manager-0.1.0.tar.gz . I tried to upload the update also in registry.gimp.org but it is really slw. Do anyone knows why? The updated code will be also available at http://registry.gimp.org/plugin?id=5146 as soon as I can upload it. -- Jordi Cantón http://www.virtual-sub.org ___ 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
I just installed and tested this latest version. At this point it is good enough to be of use for those that need/want color management. The changes that were made between version 0.0.9 and this version were mostly to the user interface (big improvement) and some bug fixes. I have also asked Jordi to add a black point compensation option and a few other functionality things and perhaps we will see these in the next version. Along with the proofing filters already in GIMP all that is missing to implement a basic manual CM work flow is the ability to specify and use a display profile. On Wednesday 09 February 2005 12:30, Jordi Cantón wrote: I just released version 0.1.0 of the gimp-color-manager plugin. Important changes since last version: -Re-design of the user interface in order to clarify the workflow (Thanks to Hal suggestions) -I correct several bugs found in the code -Now it should also work on a windows box. I made a revision of all the file paths making them platform independent -A transformation from embedded profile to default work space profile can also be made -All the other changes Hal commented in his review of pre-0.0.10 It can be downloaded from ftp://www.virtual-sub.org/gimp-color-manager-0.1.0.tar.gz . I tried to upload the update also in registry.gimp.org but it is really slw. Do anyone knows why? The updated code will be also available at http://registry.gimp.org/plugin?id=5146 as soon as I can upload it. -- Jordi Cantón http://www.virtual-sub.org ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer -- Hal V. Engel pgpD3kknyhRuR.pgp Description: PGP signature
[Gimp-developer] Re: color management
Hi, J.Canton [EMAIL PROTECTED] writes: I should also compile a local version fo glib2.6/GTK 2.6 in order to be able to compile the Gimp cvs HEAD, isn't it? You will need glib/gtk+ 2.6 but there is actually no reason to keep those local since 2.6 is fully backward compatible to earlier glib/gtk+ 2.x releases. 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
Hello, Great news!! I have been working in the gimp-color-manager plugin which is strongly related (in fact it can be modified to meet your 7th point) I already have corrected the bugs found in the previous release and made some changes in order to clarify the workflow. Actually the plugin can do -Convert from input profile to work space profile -Convert from work space profile to output profile -Embed and use enbedded work space profiles (using icc-profile parasite) I also want to add the conversion from work space A to work space B before releasing this version. (you can check the actual code at ftp://www.virtual-sub.org/gimp-color-manager-pre-0.0.10.tgz ) It would be great if the plugin can get the color configuration (directory to look for profiles, scanner ,workspace and printer default profiles..) from the preferences set in the new dialog. Is there a guide to setup a cvs compilation in a local user without interfering the global configuration and the other users in the system? I am very interested on getting that color management stuff working, but I cannot change/reinstall the linux box I am using, so I must work locally. [EMAIL PROTECTED] wrote: Hi, [...] - add a plug-in to apply color profiles [...] -- Jordi Cantón http://www.virtual-sub.org ___ 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
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
[Gimp-developer] Re: color management
Hello. Several mails in this thread says that the images will be converted between colorspaces, such as monitor colorspace. Does GIMP keep two versions of the same image: one for image processing and saving, and one for displaying? I remember how XV converted images to fit better to the display. If one had 8-bit display (and most had), the image was quantized to 8-bit. Then when the image was enhanged and saved as jpeg, one could see that the jpeg image contained the quantized and dithered 8-bit image! People lost their 24-bit images because they used XV to trim and flip the images!! Please don't make the same mistage with the colorspace issue. Worse is if you force people to convert images in lossy way as you have planned. Juhana -- http://music.columbia.edu/mailman/listinfo/linux-graphics-dev for developers of open source graphics software ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: color management
On Fri, 16 Jul 2004 16:40:23 +0300, Juhana Sadeharju [EMAIL PROTECTED] wrote: Hello. Several mails in this thread says that the images will be converted between colorspaces, such as monitor colorspace. Does GIMP keep two versions of the same image: one for image processing and saving, and one for displaying? The monitor colorspace would never be an intermediate colorspace, just the final transformation the final composite would go through, the final composite (consisting of the merge visible layers is just an intermediate representation seperate from the actual data in the layers) Please don't make the same mistage with the colorspace issue. Worse is if you force people to convert images in lossy way as you have planned. The user would be in full control of what conversions happens, and could choose not to apply a transform, for most unspecified rgb data, sRGB would probably be a safe assumption, and thus would be no problem in actual use, the added benefit would be that the images would be blessed with correct information, when users have a monitor profile as well, they can be assured that the reproduction of the images is correct across other color managed programs and devices. /pippin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: color management
Hi, Juhana Sadeharju [EMAIL PROTECTED] writes: Several mails in this thread says that the images will be converted between colorspaces, such as monitor colorspace. I don't think anyone ever mentioned to convert the image to the monitor colorspace. Does GIMP keep two versions of the same image: one for image processing and saving, and one for displaying? No. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
