Re: [Gimp-developer] jpeg-exif continued
Hi, William Skaggs [EMAIL PROTECTED] writes: Sven: What is akward about it? Passing, say, an ExifData struct to a plug-in is awkward. Calling a function and giving it a pointer is simpler, and much faster too. And then there's all the extra baggage of registering a plug-in etc. I agree that for a C plug-in a library is easier to use but we will also have to care about plug-ins written in other languages. Making the functionality available in the PDB solves this nicely. What we usually do is to provide wrappers that let the procedure call appear as a simple function call. Sven: The JPEG plug-in would have to change the orientation tag if it's rotating the image on load, wouldn't it? It would have to do that before calling gimp_metadata_store_exif(). It can do that if it wants to, but there is no requirement. The orientation needs to be set to top-left when an image is saved, but it doesn't really matter whether the change is made upon loading or upon saving. If nothing else, doing it on saving prevents the user from setting things incorrectly in the metadata editor. Well, how is the save plug-in supposed to know that it needs to change the orientation field upon saving? Only when the image is rotated, during load, is this information available. Or am I missing something here? Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg-exif continued
Hi, Robert L Krawitz [EMAIL PROTECTED] writes: I know I've been making a nuisance of myself about this, but PLEASE at least provide a way to turn this query off. Robert, we are at the very beginning of the development cycle and are discussing the basics. The query is off-topic right now. Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] mbox archive of [gimp-devel] 2004 and 2005
Hello, I subscribed today to gimp-developers, and I need at least the archives for January 2005 in mbox format (b- or gziped). http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer has got only the archives until 2003. Thank you Kind regards Gerhard Gaußling ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg-exif continued
Sven: I agree that for a C plug-in a library is easier to use but we will also have to care about plug-ins written in other languages. Making the functionality available in the PDB solves this nicely. What we usually do is to provide wrappers that let the procedure call appear as a simple function call. This is only relevant to file plug-ins. It didn't occur to me that they would ever be written in anything except C, but if that is a reasonable possibility, then I accept the argument. Sven: Well, how is the save plug-in supposed to know that it needs to change the orientation field upon saving? Only when the image is rotated, during load, is this information available. Or am I missing something here? The orientation is *always* supposed to be set to top-left when an image is saved, on the principle that after the user has edited the image in GIMP, the orientation is the way the user wants it. Only a camera should ever set it to anything other than top-left. -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] mbox archive of [gimp-devel] 2004 and 2005
Gerhard Gau�ling wrote: I subscribed today to gimp-developers, and I need at least the archives for January 2005 in mbox format (b- or gziped). http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer has got only the archives until 2003. It's broken. See http://www.gimp.org/mail_lists.html for other archives. Best, -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] mbox archive of [gimp-devel] 2004 and 2005
Am Samstag 15 Januar 2005 18:07 schrieb William Skaggs: It's broken. See http://www.gimp.org/mail_lists.html for other archives. Hello Bill, Thank you for the hint, but unfortunately there is nothing to find for downloading in mbox format :-( regards Gerhard ___ 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] jpeg-exif continued
Hi, William Skaggs [EMAIL PROTECTED] writes: I agree that for a C plug-in a library is easier to use but we will also have to care about plug-ins written in other languages. Making the functionality available in the PDB solves this nicely. What we usually do is to provide wrappers that let the procedure call appear as a simple function call. This is only relevant to file plug-ins. It didn't occur to me that they would ever be written in anything except C, but if that is a reasonable possibility, then I accept the argument. It's just an argument, not a requirement. Simply something that might be worth keeping in mind. Is this really only relevant to file plug-ins? A metadata editor would need to use these functions as well, wouldn't it? The orientation is *always* supposed to be set to top-left when an image is saved, on the principle that after the user has edited the image in GIMP, the orientation is the way the user wants it. Only a camera should ever set it to anything other than top-left. Hmm, so if I open an image, do some color corrections, but do not rotate it, the orientation tag is supposed to change? I can hardly believe that. But if you say that's what the spec says... 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 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
[Gimp-developer] Re: Re: Color Management was GEGL development/gimp integration
Hello David, BTW: Using the gmane.org newsserver and a news client seems to be a good alternative to the mbox archive ;-). David Neary wrote: [...] 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 If you apply a conversion to the file there will be a loss of color information, so it's necessary, that we avoid unneeded conversions to the original file. For example, if you convert from adobeRGB into sRGB and viceversa several times, you wouldn't receive the original color impression never more, it's lost, and there for in poor quality (comparable with the jpeg lossy compression, keep that in mind). So, we have to convert only the displayed version of the data, not the original data (Jan-Peter, Hal and others, please correct me if I'm wrong). This is important, to get a display color as closed to the original scene in nature as possible, adjusted to the display hardware by the measured or proofed monitor profile. While rendering the data for the display this way, the data itselves stays in working color space, or original color space (as choosen by the user while opening the file). It should be saved with the working color space e.g. as device independant suggested by ECI.org eciRGB.icc, which is comparable with widegammut and adobeRGB, or the original color space (as choosen by the user while opening the file), to avoid unneeded conversions while saving the data. eciRGB.icc offers a wider range of colors compared to sRGB, which got a very limited color space, so it avoids clipping, when converting e.g. from scanner profiles to the working color space. The user should archive the data in the recommended device independent colorspace (e.g. for Europe according to the suggestion of the ECI in eciRGB color space [1]). To Print the data it should be converted to the printer profile (This should happen in the service bureau or the printer service, maybe the printer offers you the printer-device profile to do the conversion by yourself. At home you can measure your inkjet profile for example, and apply that.) If you want to save your work for web you should do that by using the conversion from (the wider) working color space to sRGB the default for webpublishing. - During saving, save the originally loaded ICC profile back to file, if the format supports it, or convert to sRGB if it doesnt. This all should be flexible and interactive (there could be an easy mode coosen in the preferences to disable colormanagement at all), and it's important to retain as much original color informations than possible. 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. 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? I want only remember the developers that there is already a state of the art color-management used by the printing industry, which the GIMP-developers can't ignore while implementing colormanagement and CMYK or multichannel/DeviceN mode for the GIMP. Just avoid to go into the wrong direction when going further with the implementation of colormanagement. - 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 Photoshop lets pop up a dialog where the user can decide the kind of conversion he will do for the pasted/dragged 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. Desired is a 'On the fly' Softproof. I admit, that this is a very complex subject, and it is much work to implement all this color stuff into the GIMP, but I'm shure it's worth it. Thank you Gerhard [1]http://www.eci.org/eci/en/044_working_colour_spaces.php
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
Re: [Gimp-developer] Re: Re: Color Management was GEGL development/gimp integration
Hi, Gerhard Gauling [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. 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? Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Re: Color Management was GEGL development/gimp integration
Sven Neumann wrote: 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. That's a good point, also because in the lcms-user maillist there was a thread about Fast colour managed preview, how? , where Gerhard Fuernkranz pointed out, that Argyll's IMDI routines are _very fast_ with 8bpp input: http://sourceforge.net/mailarchive/forum.php?thread_id=6213268forum_id=1912 . regards Gerhard ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Re: Color Management was GEGL development/gimp integration
On Saturday 15 January 2005 14:42, Gerhard Gaußling wrote: snip For example, if you convert from adobeRGB into sRGB and viceversa several times, you wouldn't receive the original color impression never more, it's lost, and there for in poor quality (comparable with the jpeg lossy compression, keep that in mind). So, we have to convert only the displayed version of the data, not the original data (Jan-Peter, Hal and others, please correct me if I'm wrong). This is exactly correct. The conversion between color spaces will always introduce quantization errors. If only one conversion is done these have a minimal effect on the image assuming the the gamut of the original fits into the new color space with minimal loses. This is not likely to be the case when converting from a wider space such as AdobeRGB to a narrow space like sRGB. But if this happens many times the image will suffer significant degradation. In other words the color space conversion is NEVER lossless. 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? I am not sure that I want to wait that long but if it will take that long to get it right then so be it. I would rather wait and get a correct implementation then get an incorrect one sooner. But I think that it should be possible to do at least some of this sooner. For example perhaps a color aware printer interface could be added sooner by leveraging Alastair M.Robinson work on PhotoPrint. 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. Desired is a 'On the fly' Softproof. I have little use for soft proofs since my custom profiled printer gives results that are almost identical to what I see on the screen in Photoshop. But for those that are working with low gamut printers this is likely more useful. I admit, that this is a very complex subject, and it is much work to implement all this color stuff into the GIMP, but I'm shure it's worth it. I would also like to add that although I am not a color management professional I did struggle with color issues in my digital darkroom and as a result I have spent many hours setting up a proper (but perhaps somewhat basic) color management work flow. In the process I studied many sources and learned a lot. Gerard is correct this is not going to be trivial and it will take a lot of effort to get this in place. For those that are new to color management and would like to understand this better from a CM users perspective I would like to recommend that a good starting point is http://www.normankoren.com/color_management_2.html#Implementation%3C/A%3EHere, %20you%20helped%20me, %20again!%20%20I%20am%20learning%20how%20to%20do%20the This web site is from a color management users perspective and it starts out with a basic overview of how color management works and what all of the pieces are and how they all work together. He give examples of how to setup things in both Photoshop and Picture Window Pro. So this has lots of info about how two different apps have set up the user interface for this. Also one of the interesting things on this site is that he has the GretagMacbeth ColorChecker test pattern in both SMPTE-240M (same as AdobeRGB 1998) and sRGB color spaces. One of the patches (out of 24) is out of gamut in the sRGB version of the image but is in gamut in the SMPTE-240M image. -- Hal V. Engel pgp0hVLaJ6x0W.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
[Gimp-developer] Re: Re: Re: Color Management was GEGL development/gimp integration
Hal V. Engel wrote: snip For those that are new to color management and would like to understand this better from a CM users perspective I would like to recommend that a good starting point is http://www.normankoren.com/color_management_2.html#Implementation%3C/A%3EHere, %20you%20helped%20me, %20again!%20%20I%20am%20learning%20how%20to%20do%20the Hello Hal, thanks for the link! This is a shorter one of the same site ;-) http://www.normankoren.com/color_management.html or the same uri like you used in a more shorter way: http://Implementing-cms.notlong.com This web site is from a color management users perspective and it starts out with a basic overview of how color management works and what all of the pieces are and how they all work together. He give examples of how to setup things in both Photoshop and Picture Window Pro. So this has lots of info about how two different apps have set up the user interface for this. Also one of the interesting things on this site is that he has the GretagMacbeth ColorChecker test pattern in both SMPTE-240M (same as AdobeRGB 1998) and sRGB color spaces. One of the patches (out of 24) is out of gamut in the sRGB version of the image but is in gamut in the SMPTE-240M image. good night Gerhard ___ 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
[Gimp-developer] Re: Re: Color Management was GEGL development/gimp integration
Sven Neumann wrote: Go to View-Display Filters and enable the Display Proof filter. Thanks to you and Alastair to pointing that out, I'm quite impressed! Even the rendering intends are there! So I'm pleased that there is some work going on in this direction. In the GEGL TODO there is shown 0% progress for the color models and cms, that might be not related to reality! (even if this display filter is not part of GEGL) 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. You're welcome! (Hope this english fits!) Kind regards Gerhard ___ 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] 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
[Gimp-developer] Re: Re: Color Management was GEGL development/gimp integration
Hello Sven, Sven Neumann wrote: - display profile should be adjusted _once_ systemwide (every time changeable by systemwide color preferences independant from the GIMP, as used by (e.g.)scribus [1], inkscape [2], sodipodi[3] wine e.g. for Photoshop and maaybeee by commercial apps available for *nix like Page Stream [4], Cenon [5], Viva Designer [6]) with an monitor profile (like the one of l-prof or adobe-gamma etc.), there for it would be a little overwhelming to have this choice again in the opening file dialog, if the profile doesn't fits the working color space. regards Gerhard [1] http://www.scribus.org.uk/ [2] http://www.inkscape.org [3] http://www.sodipodi.com/ [4] http://www.grasshopperllc.com/ [5] http://www.cenon.info/frame_gb.html [6] http://www.vivaip.de/ ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Re: Color Management was GEGL development/gimp integration
Sven Neumann wrote: Stefan Döhla 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) monitor/display profile + from workspace to printer (should default to us: webcoatedSWOP for ads (coated paper) and europe: isocoated.icc (also coated paper) * perceptual for pictures * relative colorimetric for most other work) agreed, but flexible enough to set it to saturation or absolute rendering intend. - default cmyk-profile (is later used to convert RGB-CMYK) see above europe: isocoated.icc - default profile path (/usr/share/color/icc/ and ~/.color/icc/) agreed 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. I like the idea of an abstract API, which can be managed by different cmm e.g. lcms or argyll This seems to be all over viewed a reasonable practice to use CMS on image manipulation. regards Gerhard ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Re: Color Management was GEGL development/gimp integration
Gerhard Gaußling wrote: + from workspace to printer (should default to us: webcoatedSWOP for ads (coated paper) and europe: isocoated.icc (also coated paper) Only as a suggestion, please keep it flexible! * perceptual for pictures * relative colorimetric for most other work) agreed, but flexible enough to set it to saturation or absolute rendering intend. - default cmyk-profile (is later used to convert RGB-CMYK) see above europe: isocoated.icc see above, keep it flexible! You have to have the access to choose the printer profile of the device, which is used actually ! regards Gerhard ___ 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
