Re: [Gimp-developer] Re: Re: Color Management was GEGL development/gimp integration
Hi, Gerhard Gauling [EMAIL PROTECTED] writes: Sven Neumann wrote: -displayprofile 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. Yes, ideally it would be configured systemwide. Not once, but once per monitor. But unless a standard exists for system-wide color management configuration, we don't have much choice but to implement our own configuration. If you can point me to such a standard, we will of course consider to adopt 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
Sven Neumann wrote: - display profile should be adjusted _once_ systemwide (every time changeble by systemwide color preferences indepenant 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 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] [6] http://www.vivaip.de/ ___ 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 Sat, 15 Jan 2005 23:42:55 +0100, Gerhard Gaußling 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 some filters and operations to be correct, the image data needs to be in a color space with linear light. (e.g. not gamma corrected for CRT display devices). Operations that need linear light to be correct: gaussian blurs smudge anti aliased brush strokes soften brightness / contrast adjustments resampling (scaling an image up/down, rotating etc.) To avoid extra conversions whenever such a filter is applied to an image, having a standard working space that has linear light will decrease the total number of conversions needed. Doing the custom conversion and countermeasures to account for gamma in all these operations will introduce quantification whenever such an operation is performed, less conversions are better, and a consistent high range internal working space is the path to the lowest number of conversions whenever any of the above listed operations are done. This is why I am advocating that gimp/GEGL should prefer to work, save and load in a preferred working color space. For multiple loads/edits of a project the conversion to a preferred internal working space already have happened when you load an image using gimps own file format. other image file formats are not suited as intermediate formats for saving an image that is being edited (for the same reasons that you shouldn't use lossy compression,. compression through generations/multiple unneeded conversions degrades your image) When exporting from gimps internal file format to display / printer / other file format with embedded icc profile, the image data shouldn't be touched by gimp again. /Øyvind K. -- Software patents hinder progress | http://swpat.ffii.org/ Web : http://pippin.gimp.org/ ___ 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: 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: 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
[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
