Re: [Gimp-developer] color management
David, So say I open an image with a color profile, and then load a second image with a different profile. If I now decide to do the above, what do we do to the first image? how about attaching a profile to each image? Correction is then done using the individual image's profile and the application-wide monitor profile. This gives you a lot of flexibility in the use of different profiles and saves you from having to switch the workspace profile back and forth. From my own research on the matter, the way it is done in most apps and CMS workflows seems to use three profile settings: 1. a monitor profile 2. a default image profile 3. a working space profile The meaning of the monitor profile is obvious. The default image profile is assigned to images that don't have an embedded profile. The working space profile is a kind of preferred colour space, such as the in-house space of a studio. The workflow is then as follows: When an image is opened, it is assigned its embedded profile, or, if there is none, the default image profile. The assigned profile is then compared to the workspace profile. If they are identical, nothing happens, since the image already is in the user's working space. Otherwise, the user is notified of the fact that the image profile differs from the working space profile and is asked whether she would like to convert the image to the working space or to maintain its original profile. For ease of use there should be a preference setting that defines a default for this dialog and allows it not to be displayed (e.g. always convert images to working space). Display correction is then done based on the profile that was assigned to the image (which could be the embedded profile, the default image profile, or, if the image was converted, the workspace profile). Here the working space is more of a preference setting, a colourspace that the user prefers to work in. It is not necessarily used in the display correction (only if it is made the image's profile). In addition there are usually functions to assign a different profile to an image (only changes the attached profile, but doesn't manipulate the image data) or to convert an image to a different profile (changes the profile and the image data). Hope this is of any use Stef an ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Linux common ICC profile directory
Hello, sorry about the cross-list posting, but it is the easiest way to say this... At CinePaint (cinepaint.sourceforge.net) we are in the process of integrating full colour management following the ICC standard. A while ago, there has been some discussion on the Open ICC list ([EMAIL PROTECTED]) about a directory standard for ICC profiles on Linux. Marti Maria, developer of littlecms (www.littlecms.com), suggested /usr/share/color/icc and ~/.color/icc as intuitive paths. We decided to go along with this. So this is just to let you know about it in the hope you like the suggestion and might adopt it in your own application as appropriate thereby turning the paths into a standard which would be a first step towards an OS-based colour management on Linux. Thanks Stefan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] makes it sense to add native CMYK support to GIMP?
Hi all, I am a computer science student looking for a final year project. I'd love to do something in the Open Source community and I am looking around where my help might be needed. Having a little interest in graphics design and prepress, I came across GIMP and CMYK support. The little research I've done gives me the impression that over the last couple of years it's regularly been asked for and it might be an important feature to get GIMP into the pre-press world. What I'd like to know is the following: 1. Is anybody actually working on this? There were hints now and then that people are thinking about it, but I didn't find anything definite, apart from an entry Additional ColorModels on the GEGL todo list (http://developer.gimp.org/gegl-todo.html) that seems to point in that direction. 2. How important is this really? What I am talking about is native CMYK support, not just a conversion function. There was a thread on the developers-list in November 2001 (http://www.mail-archive.com/[EMAIL PROTECTED]/msg01350. html) that gives the impression that it might not be all that important and that there might be cheaper workarounds (converting when saving, spot color channels). How important is a CMYK mode for people working in prepress? 3. Any guesses on the effort to implement this? I'd appreciate it if you could answer asap, since I have to hand in my project proposals very shortly. Thanks Stefan Mit der Grupppen-SMS von WEB.DE FreeMail können Sie eine SMS an alle Freunde gleichzeitig schicken: http://freemail.web.de/features/?mc=021179 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
