Re: [Gimp-developer] Color manager plugin 0.0.10 released

2005-02-08 Thread Francisco Bernal Rosso
 4. It correctly displays the profile embedded in the image.

I do not understand this ¿Why are somebody intetrested in embebed the screen
profile in the photo? The screen is only one step in the chain. It is not
the main step. In the photo should be an intermediate profile. A
independent device profile to be useful.

___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Color manager plugin 0.0.10 released

2005-02-08 Thread Hal V. Engel
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.

-- 
Hal V. Engel


pgpJqFrCMsDu5.pgp
Description: PGP signature