RSS/Atom feed Twitter
Site is read-only, email is disabled

Gimp-developer Digest, Vol 29, Issue 13

This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.

This is a read-only list on gimpusers.com so this discussion thread is read-only, too.

2 of 4 messages available
Toggle history

Please log in to manage your subscriptions.

20050208065815.B68C010854@l... 07 Oct 20:23
  Gimp-developer Digest, Vol 29, Issue 13 Jordi Cantón 08 Feb 20:38
   Color manager plugin 0.0.10 released Hal V. Engel 08 Feb 23:05
   Pine.LNX.4.61.0502120739380... Kai-Uwe Behrmann 12 Feb 07:49
Jordi Cantón
2005-02-08 20:38:45 UTC (about 19 years ago)

Gimp-developer Digest, Vol 29, Issue 13

Hello,

Hal V. Engel wrote

1. There are significant improvements over 0.0.9 and it no longer crashes when selecting a non-default profiles directory. But it does not allow the user to select profiles from this non-default profiles directory. I would rather that this default to a system wide location for profiles.

Actually if you change the ICC color directory all the combos are updated to the profiles of the newest selected directory. The only limitation is that all the profiles should be in the same directory. The problem of a system wide location for all the profiles is that the normal user cannot use its own created profiles. Actually, the default ICC directory for this plugin is gimp_directory ()G_DIR_SEPARATORcolor I accept suggestions to change this. As Gimp color management is going to be centralized,what will be the official default directory for the color profiles? Is it already set?

2. It now finds monitor profiles and allows the user to select these from the display profile drop down list. It does not remember the monitor profile however after the plugin is closed. I believe that it currently does nothing with them.

Display profiles are not using actually I am gettin rid off this combo and usig it to select the work space profile instead. The display profile should be used in the prof visualization plugin

3. The work space profile function now works. As does the Embed WS profile function.

4. It correctly displays the profile embedded in the image.

It displays the working space profile enbedded in the image. (just to clarify the question about this point)

5. The user interface is still confusing. When the user clicks on apply profile it is not clear what will happen. If Input is selected for transformation and the user selects Apply Profile what happens? Does this convert from the embedded profile to the input profile or from the input profile to the working space profile? Or ...? Same for output. What is being converted and to what?

I am working on clarifying this. Actually it does

input input profile ---> working space profile output working space profile ---> output profile

if there is a working space profile enbedded in the image and the "use Enbedded profile" checkbox is checked then the enbedded profile is used as workspace profile.

6. There is a need for someplace to set the color management policies. And this plugin does not support that functionality.

I agree but these should be set globally, by the way, what should be that policies? Color management is not an easy topic and this setup should be as clear as possible.

Hal V. Engel
2005-02-08 23:05:16 UTC (about 19 years ago)

Color manager plugin 0.0.10 released

On Tuesday 08 February 2005 11:38, Jordi Cantón wrote:

I am working on clarifying this. Actually it does

input    input profile ---> working space profile output   working space profile ---> output profile

if there is a working space profile enbedded in the image and the "use Enbedded profile" checkbox is checked then the enbedded profile is used as workspace profile.

That helps at least now I know what will happen. The "use Embedded profile" checkbox as you are using it is really a CM policy item.

6. There is a need for someplace to set the color management

policies.  

And this plugin does not support that functionality.

I agree but these should be set globally, by the way, what should be

that policies? Color management is not an easy topic and this setup should be as clear as possible.

This is sort of an extended functionality type of thing. If the user has access to CM functions that allow embedding profiles and doing conversion between color spaces that user can then manually implement a CM policy. It is more work for the user and it is also more error prone.

Global CM Policy items would include things like:

1. Color management on or off. Should be off by default.

2. What happens when an image is loaded that has no profile embedded? a. Automatically assign the default work profile. b. Automatically assign some other user selected profile. c. Assume some user defined profile and convert to work space profile or some other user selected profile. d. ??
...
x. Ask the user.

3. What happens if an image is loaded that has an embedded profile that is not the default work profile.
a. Automatically convert to work space profile. b. Use the embedded profile.
c. Ask the user what to do.

4. Setting a default work space profile(s).

5. Selecting the monitor profile.

6. Setting up proofing filters. There needs to be a way to setup and name more than one. I do not use these because my printer has enough gamut to closely match what I see with out the proof filter. But those that work with offset printers which have less gamut will likely use this feature.

I think that input device and printer profiles are really too complex to be handled as general policy items. Remember that when you are dealing with the color space of an input or output device there can be many profiles that are valid depending on a number of factors.

I have one "photo" printer, an Epson 1280, but I have many profiles for it because you need a profile for each paper and resolution (actually a given set of driver settings). It is not unusual for me to have 5 or 6 printer profiles that are valid at any give time that are used with different papers and driver settings (resolutions) for this single printer.

This is why I believe that this belongs in the printing settings dialog. In the GIMP print interface you can set up logical printers (New Printer button) "This can be used to name a collection of settings that you wish to remember for future use." One set of these settings for the logical printer, if CM is turned on in general CM policies, should be the CM policy for that set of driver settings. This includes the output profile, the rendering intent and black point compensation. Even though this is a complex policy area I can see a very clear path to implementing a very workable and easy to use solution. As you can see this is NOT located in the general CM policy interface but is located close to the device since it is very dependant on the device settings.

The same things can happen with input devices. One of the things that I have started doing if I am shooting in unusual lighting conditions I will shoot an IT8 target along with what ever else I am shooting. I will then use the IT8 target image from that shoot to create a shoot specific color profile. This will be assigned to all images from that shoot and used as the starting point for CM for those images. So even though I am using the same input device I will have different profiles depending on conditions. How do you build a user interface that would allow a policy to be implemented for this? I am not sure this is possible. This is a very advanced use of CM and I would expect that this is some what unusual. But after my initial experiments with this I have found it to be very powerful.

The reason I went into such detail is that I wanted to make it clear that setting up a CM work flow can be very complex but also very powerful. The long term goal for GIMP should be to make it as easy as possible for users to leverage that power. But in the short term I would be very happy just to see basic CM functionality.