On Wednesday 15 November 2006 13:42, Plinnell wrote:
> <snipped>
> > Sven
> I have been playing with the color management in CVS and it is getting
> there for sure.
> My thinking is the choice of controls and terminology should be guided
> by the 3 modes you have.
> 1. No color management means that and everything assumes RGB with no
> display compensation.
> 2. Managed Display - To me mode this should be used for web graphics
> and users with the large majority of inkjets which are indeed RGB
> devices in that they expect RGB data.
> 3. Press Simulation - Exactly that. Simulating CMYK Printers of all
> kinds.

I think this may be a false dichotomy.  Most color printers are CMYK printers 
even if drivers in some environments like Windows expect RGB data.  For 
example my Epson printer drivers on Windows expect RGB data but using 
Guten-print on Linux I can send CMYK data to the printer and by pass the 
drivers RGB to CMYK conversion routines.  The same is true for users of RIPS 
on Windows and the Mac.  My intension on Linux is to profile my printer as a 
CMYK device and do my color management directly into the printers true native 
color space.  If anything I should actually get a slightly larger gamut then 
sending RGB data to Guten-print.  

I think the Press Simulation (was Print Simulation on 2.3.12) is intended to 
be a preview mode so that users can have a better idea what their output will 
look like on the intended printer/ink/paper combo or other output device and 
I don't think this has anything to do with the output device being CMYK or 
RGB.  This is also how this works in photoshop.

> In the case of #3, you could argue that having a choice to enable some
> form of gamut warning. Mind you gamut warnings are just that. I would
> not enable this for # 2

I would agree that having a gamut warning option is a good thing.  Since #2 is 
not a preview of the output results then it only makes sense to have this for 
#3.  I can however live without this in the short term in part because my 
printer is a fairly wide gamut device and gamut clipping only happens under 
extreme conditions. 

> One thing which needs fixing is profile locations. Finding and setting
> the profiles is not obvious on Linux
> On Linux/*nix, we've outlined those directories on openicc and most of
> it is taking hold as a spec. This should be a recursive search as
> some profile packages are now available for distros and they
> sometimes separate RGB and CMYK locations.

Krita, cinepaint and LProf all support the current *nix spec and LProf 
supports the Windows locations as well.  I am not sure about Scribus but I 
think is does as well.  So this is another thing that users will expect.

> Windows NT and Win9x have different default locations, but they should
> be searched automatically IMO.

The last version I tried is 2.3.12 and selecting profiles was by file name.  
Most other CM aware software including (but not limited to) photoshop, The 
Windows Color control panel applet, cinepaint, Krita and LProf (should Scibus 
be in this list?) use the profile description tag rather than the file name 
in these drop down lists of profiles.  This has been more or less standard 
for a long time and most CM savvy users will expect this same behavior from 
GIMP at least in the long run.


> File > Properties might be good place also to note if a given image
> has an embedded profile.

Or perhaps Image > Image Properties
Or both?

> I'm game to writeup some docs before 2.4 is done on a color
> management. section. Without good docs, this will flood the mail
> lists and IRC with questions.

This is critical.  CM is hard for new users to understand and a little 
documentation will go a long way in helping users get started.

> I did not mean this to be a comprehensive review and I know this is
> still a work in progress, but it is great to see what has been done
> so far.

I agree that there has been much progress.  I will be getting a CVS build 
setup on my machine so that I can keep more in touch with progress on this as 
it gets closer to final release.

Gimp-developer mailing list

Reply via email to