Am 24.05.04, 19:23 -0500 schrieb Bob Friesenhahn: > As I mentioned before, GraphicsMagick is planning to add rules-based > automated color management support. We plan to configure color > management via an XML file. There is no reason why the same XML > configuration file format can't be used by other open-source > applications (e.g. GIMP) and accessed in a shared location.
Fine to share informations. > Without getting into any specific configuration file details, the > following are my thoughts regarding the information which should be > supported by the configuration file. I am counting on the color > management experts on this list to make me aware of any defects in my > thinking. > > LCMS is the only well supported and freely usable open source CMS > system available, so it may be used to propel color management into > open source applications. I mostly agree on this. > Automated CMS Configuration Parameters > ====================================== > > CMS configuration paramers are stored in a structured XML file format. The > file format structure allows multiple configurations to exist at one time > so that there may be a default configuration, and multiple named > configurations. Named configurations allow the user to select a specific > color management workflow strategy. > > The following may be configured via the XML file: > > o Directory path to search for profiles. > > One or more directories to search for ICC CMS profile files. > > o Profile alias names. > > Shorthand names for profiles. For example "sRGB" is an alias for "sRGB > Color Space Profile.icm". Alias names may be used to provide a > user-friendly interface for device-specific profiles. good idea, I use this in the CinePaints print plug-in - very convenient. > o Working space profiles for grayscale, RGB, and CMYK. > > When an image is read, it is automatically transformed (if necessary) > into the most suitable (same type) working color space. preferences as usual > o Display profile for grayscale and RGB. > > If the current display does not support a color space identical to the > current working color space, then the image should transformed using > the most suitable display profile while displaying. If the display > otherwise lacks a profile, the default should be sRGB. good point > For X11, the current display is identified by the DISPLAY environment > variable. If the hostname is not part of the DISPLAY specification > (e.g. ":0.0") then the local hostname is prepended to identify the > display. A unique display output profile may be specified for any > number of DISPLAY specifications. This allows display profiles to be > managed from a central location. Ok so Your can manage muliple hosts. Just we want to see the display not the computer. I expect is is hard to circumvent X. Displays need names or identifiers to assign profiles. Think about one big display consisting of mulitple displays - all individually profiled. > o Output profile for grayscale, RGB, and CMYK. > > The working color space may not be the desired output color space. > Normally the user will want to save images using the working color > space in order to avoid losing information and for the best efficiency. > However, often output should be to some common colorspace like sRGB or > SWOP, or a specific device color space. Probably requiring the user to > specify the desired output colorspace by alias name is best. Do You mean the saving part? Then I would say, to select an other fileformat for saving other then for loading, people does it usually manually. Can You show an example about its usage? It would help. > o Default input profile for grayscale, RGB, and CMYK. > > Image files which do not contain CMS profiles could be assumed to be in > the current working colorspace (apparent Photoshop assumption) however, > the sRGB specification claims that many image files are implicitly sRGB > since they were developed to look good on a "standard" CRT monitor. > Given this, it seems desireable for the user to be able to specify the > default input profile for images. Responsible software should add a > color profile so it seems reasonable to always assume sRGB for JPEG, > BMP, GIF, or other file types which are clearly designed for viewing on It is allways an good thing to beeing able leaving any field black, and this disabling color management. Responsible software should add if this is the users intention. > CRTs. Applications should always allow the user to explicitly specify > the input color space to use. thanks for sharing Your thoughts Kai-Uwe Behrmann ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click _______________________________________________ Lcms-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/lcms-user
