On Wednesday 15 November 2006 13:42, Plinnell wrote: snip > > <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. snip > 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. Hal _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
