Chapter 2 Profiles

In This Chapter

This chapter provides an overview of profiles. It discusses their contents, format, and KCMS profile classifications. It proceeds to describe how you typically use KCMS API functions in your application to manipulate profiles. The chapter provides an illustrated example, threading together some of the most frequently used operations. Finally, the chapter presents more advanced programming techniques your application can perform using the API.

What Is a Profile?

A profile (also called a color profile) provides the KCMS framework with information on how to convert input color data to the appropriate color-corrected output color data.

Profiles contain the following types of information:

• Color spaces in which the input and output data appear (for example, RGB, CMYK, or CIEXYZ).

• Specific color space parameters (for example, primary color chromaticities and tables that correct the response of each color component or channel).

• Data determined by the specific conditions in which colors are expected to be viewed (for example, the lighting conditions and type of media that will be used).

• Tables of data or equation parameters that a CMM uses to transform color data.

• CMM-specific information. Each profile is owned by a specific CMM. Although all profiles have common, public information, there may be private data in an individual profile format for use by that particular CMM.

What Is Your Interest in Profiles?

Profiles are the focus of your programming efforts. Typically, you write applications to load profiles, read profile attributes, connect profiles, optimize profiles, and apply profiles to color data. To perform these types of operations, you incorporate KCMS API functions into your application. See "KCMS API Functional Overview" for a summary of all the API functions.

Typically, you use the API to combine or connect existing profiles to create profiles, rather than to generate new ones. Creating new profiles is the left to the CMM developer.

Profile Format

When you write applications that use the KCMS API, you do not need to understand the details of the profile file format. However, you might be interested to know that KCMS, by default, uses the International Color Consortium (ICC) profile format. The ICC format is an emerging default de facto standard supported by a wide range of computer and color device vendors. This is extremely advantageous for users, as this standard allows a single profile to work over multiple platforms.

The ICC format is endorsed by many regular members. The founding members are Adobe Systems Inc., Agfa-Gevaert N.V., Apple Computer Inc., Eastman Kodak Company, FOGRA (Honorary), Microsoft Corporation, Silicon Graphics, Inc., Sun Microsystems Inc., and Taligent Inc.

The KCMS framework uses the ICC format as the default profile format. For details on the ICC profile format, see the ICC profile format specification. By default, it is located on-line in the SUNWsdk/kcms/doc directory. For the latest version of the ICC specification, see the web site at http://www.color.org.

CMM Specifics

Each color profile is owned by or associated with a specific CMM. Each CMM may have a different way of performing its color-correction technology. For example, a CMM may incorporate a unique way to calibrate its profiles.

In general, your application does not need to know which CMM owns a profile. In the case where the profile owner is not present and the profile is a valid ICC profile, the default CMM can provide the functionality necessary to use that profile.

The KCMS API functions your application calls are device-independent interfaces to the KCMS framework. The manner in which these API functions are preformed may differ depending on the underlying CMM and its particular color correction technology, but your application interface does not change. It always calls the API functions in the standard way. What you might want to be aware of, however, is that occasionally your application may receive CMM-specific error codes.

For more information on CMMs, see the DDK document, KCMS CMM Developer's Guide.

Profile Types

The KCMS framework supports several types of color profiles. Before describing these types, there are some terminology differences between the ICC specification and the KCMS framework you should be aware of. Table 2-1 identifies these differences, which are mostly historical.

Device Color Profile

A device color profile (DCP) represents the behavior of a specific digital color device, such as a flatbed or film scanner, a computer monitor, or a printer. Each DCP specifies device color appearance under a specific set of conditions (for example, lighting type, media type, and so on). Because device behavior tends to change over time, calibration software may adjust a DCP whenever its device is calibrated. Calibration fine tunes a specific device's color response by bring it back to normal using lookup tables. Typically calibration changes the profile data so that it can be color managed to produce the same color response as other devices of the same make and model. In other cases, depending on the device's method of calibration, the device itself is changed to match the profile.

The ICC specification separates DCPs into three categories: input, output, and display. This separation can be confusing when a device, such as a printer includes input device data. The data can be considered an input profile, an output profile, or both. This occurs in print simulation where the printer is an input device to a display or other output device.

Conceptually, it may be easier to separate profiles into these three categories only in terms of how data can and cannot be sent from and to the profile connection space (PCS). The PCS is the common junction where profiles are connected together.

KCMS does not make this syntactical separation. Rather it considers all input, output, and display profiles as device profiles and makes no assumptions about what profiles can and cannot be connected together. The connection of the profiles is then evaluated at connection time based on the data contained within the profile.

Color Space Profile

A color space profile (CSP) defines a color space. Colors are defined in terms directly related to spectral response. A CSP does not depend on the behavior of a particular color device. CSPs contain information about assumed viewing conditions in the data expressed for that color space. Typically, the color space can be relative to CIEXYZ values, defined by the Commission Internationale de l'Eclairage (CIE). The equivalent ICC term for color space profile is color space conversion profile. (See Table 2-1.)

Effects Color Profile

An effects color profile (ECP) represents a condition that changes the appearance of colors, such as a specific kind of lighting or a simulated anomalous color vision (color blindness). In addition, an ECP can be applied for artistic purposes, such as making colors appear lighter or darker. The equivalent ICC term for effects color profile is abstract profile. (See Table 2-1.)

Complete Color Profile

The preceding three profile types do not contain enough information for the KCMS framework to convert color data from one form to another. Useful color transformations can only happen when your application uses the KCMS API to connect two or more profiles together to form a complete color profile (CCP). A CCP is a connected sequence of profiles with a DCP or a CSP at either end, and possibly one or more ECPs or DCPs in between. The equivalent ICC term for complete color profile is device link profile. (See Table 2-1.)

KCMS API Functional Overview

The KCMS API consists of 14 interfaces for manipulating profiles. Table 2-2 alphabetically lists and briefly describes each function.

Typical Profile Operations Using the KCMS API

Your application can make function calls to the KCMS API to perform various tasks. Typically, applications want to use profiles to convert color data from one device type to another. This involves functions such as loading the profiles, getting and setting attributes, and saving the results. This section describes some of the typical API functions.

Getting and Setting Profile Attributes

The KCMS API provides a way to get profile information by examining the profile's attribute set. Each attribute has a value, which is data associated with the attribute. The API provides the following attribute calls:

• KcsGetAttribute()--gets a specific attribute value associated with a profile. See "KcsGetAttribute()" for detailed information.

• KcsSetAttribute()--modifies an attribute. (This is not always possible because some attributes are read-only.) See "KcsSetAttribute()" for detailed information.

For more information on profile attributes, see Chapter 5, KCMS Profile Attributes.

Loading and Saving Profiles

Profiles are typically stored as files on disks, although they can be imbedded in an image located across a network or in read-only memory in a printer.

Profiles are loaded with the KcsLoadProfile() function (see "KcsLoadProfile()") and are saved with the KcsSaveProfile() function (see "KcsSaveProfile()"). KcsLoadProfile() takes the three arguments listed below. KcsSaveProfile() takes the first two arguments listed.

• A profile identifier (Id)

• A profile description

• Hints about loading the profile

The profile Id is returned to the calling program from KcsLoadProfile() for use with other API functions. In the case of KcsSaveProfile(), the profile identifier is passed back into the KCMS framework library to indicate the profile to be saved.

The profile description is a union of many different types, each of which represents a way to supply a location where the profile data should be stored. The type and the associated fields in the union are required to complete a profile description. The type field indicates which of the union's fields to use.

A calling application can request that the KCMS framework load only specific parts of a profile, (for example, just its attributes). The caller uses the KcsModifyLoadHints() function to provide these load hints, which change the load status of the profile. Hints are described by the KcsLoadHints data type discussed on "KcsLoadHints". Load hints that request specific operations and specific content be loaded for a profile are described in "Operation Hints".

Example: Using Profiles to Convert Color Data

Figure 2-1 shows how color data is converted between a scanner device and a monitor device.

Figure 2-1 Converting Color Data From a Scanner to a Monitor

In the figure, the devices do not perform their own color correction. Rather, the color data is converted from the form provided by the scanner (Scanner DCP) to a form appropriate for display on the monitor (Monitor DCP). To convert the color data, your application would follow the steps below:

1. Load the scanner and monitor profiles.

   See "Loading Scanner and Monitor Profiles".

2. Connect the scanner profile to the monitor profile to get a complete profile.

   See "Connecting Scanner to Monitor Profiles".

3. Evaluate color data through the complete profile.

   See "Evaluating Color Data Through the Complete Profile".

Example 2-1 shows the sequence of calls that perform this conversion. For more information on the KcsConnectProfiles() function, see "Using Color Space Profiles" and the detailed function description on "KcsConnectProfiles()".

Example 2-1 Simple Color Data Conversion

/* Load the scanner's DCP.*/
 KcsLoadProfile(&inProfile, &scannerDescription, KcsLoadAllNow);

 /* Load the monitor's DCP. */
 KcsLoadProfile(&outProfile, &monitorDescription, KcsLoadAllNow);

 /* Connect two DCPs to form a CCP */
 profileSequence[0] = inProfile;
 profileSequence[1] = outProfile;
 KcsConnectProfiles(&completeProfile, 2, profileSequence,
 		KcsLoadAllNow, &failedProfileIndex);

 /* Apply the CCP to input color data. */
 KcsEvaluate(completeProfile, KcsOperationForward, &inbufLayout,
 		&outbufLayout);

Loading Scanner and Monitor Profiles

As shown in Example 2-1, the first color-conversion step is to use the KcsLoadProfile()function. KcsLoadProfile() loads the profile associated with a specific device, effect, partial, or complete profile, and it allocates any system resources the profile requires. For a detailed description of KcsLoadProfile(), see "KcsConnectProfiles()".

Connecting Scanner to Monitor Profiles

As shown in Example 2-1 and Figure 2-2, the next color-conversion step is to connect a pair of DCPs to form a CCP. KcsConnectProfiles() provides this functionality. Continuing with the example illustrated in Figure 2-1, a CCP is built by connecting the scanner's DCP to the monitor's DCP. The resulting CCP converts scanner data to monitor data.

Figure 2-2 Building a CCP From Two DCPs

Evaluating Color Data Through the Complete Profile

The final color-conversion step is to use the KcsEvaluate() function. KcsEvaluate() applies a color transformation based on the supplied CCP. One of the following operations is associated with the evaluation. These operations are illustrated in Figure 2-3.

• OpForward

• OpReverse

• OpSimulate

• OpGamutTest

Figure 2-3 Profile Load Hint Operations

OpForward

The forward operation is used to transform color from the scanner form to the monitor form.

OpReverse

The reverse operation is used to transform color from the monitor form to the scanner form. This is useful if your application modifies some colors in monitor space, to keep the greatest number of colors that can be converted back and stored in the scanner's color space.

A more familiar use of the reverse operation is to transform the color from printer to monitor form to see what the data looks like from the printer.

OpSimulate

The simulate operation is used to simulate the effect of running color data through a CCP, but retaining it in the form of the last device profile. For example, the simulate operation can produce monitor data that simulates the result of printed data.

OpGamutTest

The gamut-test operation is used to determine if each color in the source data is within the gamut of the destination device. Physical devices have a range of colors they can produce. This range of colors is known as the gamut of the device.

Using A Callback Function When Evaluating

KcsEvaluate() can take a long time to execute, especially if the input image or graphic contains millions of pixels. Therefore, your application can provide a callback function using KcsSetCallback(), which KcsEvaluate() calls when necessary. The callback function can, for example, provide feedback to request that processing be cancelled. If the callback returns a non-KCS_SUCCESS status, the processing stops.

Associating Profiles with Devices

The KcsSaveProfile() function, when supplied a KcsProfileDesc structure, associates that color profile with the supplied structure. Typically, a configuration or calibration program calls the KcsSaveProfile()function. The profile associated with the KcsDescription structure represents the last calibrated condition of the device. For more information on KcsSaveProfile(), see "KcsSaveProfile()".

Many events can change the condition of a device. For example, as room lighting changes, so does the viewer's perception of a monitor's colors. Or, consider a color printer. When different kinds of paper are used in the printer, the printer's color condition changes. As conditions change, a user may associate a different profile with the device.

Using Color Space Profiles

Another possible use of KcsConnectProfiles() is to connect a DCP and a CSP, creating a new CCP. Refer to Figure 2-1. If the scanner DCP in that figure is connected to the CSP (instead of the Monitor DCP shown that converts for the CIEXYZ color space), the resulting CCP will convert color data produced by the scanner into CIEXYZ format.

Example 2-2 shows the sequence of calls that creates and applies the CCP. Note that this example is very similar to Example 2-1. The difference is the second call to KcsLoadProfile(). In Code Example 2-2, KcsLoadProfile() loads the CIEXYZ profile description instead of the monitor description.

Example 2-2 Connecting a DCP and CSP

/*Load scanner's DCP. */
 KcsLoadProfile(&inProfile, &scannerDescription, KcsLoadAllNow);
 if(status != KCS_SUCCESS) {
 	status = KcsGetLastError(&errDesc);
 	KcsFreeProfile(profileid);
 	exit(1);
 }

 /*Load CSP for CIEXYZ color space. */
 KcsLoadProfile(&outProfile,&CIEXYZdescription, KcsLoadAllNow);
 if(status != KCS_SUCCESS) {
 	status = KcsGetLastError(&errDesc);
 	KcsFreeProfile(profileid);
 	exit(1);
 }

 /*Connect two profiles to form a CCP.*/
 profileSequence[0] = inProfile;
 profileSequence[1] = outProfile;
 KcsConnectProfiles(&completeProfile,2, profileSequence,
 		KcsLoadAllNow, &failedProfileIndex);
 if(status != KCS_SUCCESS) {
 	status = KcsGetLastError(&errDesc);
 	KcsFreeProfile(profileid);
 	exit(1);
 }

 /*Apply the CCP to input color data.*/
 KcsEvaluate(completeProfile, KcsOperationForward,
 		&inbufLayout, &outbufLayout);

Advanced Profile Operations Using the KCMS API

This section discusses advanced profile topics.

Operation Hints

KcsEvaluate() takes an additional argument that describes the operation to be performed on the profile. This argument is an operation hint. For example, your application can tell KcsEvaluate() to convert data in the forward direction (KcsOpForward), such as from the scanner to the printer. Data also can be converted in the reverse direction, such as from the monitor to the scanner. The reverse operation (KcsOpReverse), when it is available in a profile, inverts the function performed by KcsOpForward. However, KcsEvaluate()rarely performs an exact inverse, because information is lost when color data is transformed. In other words, if your application performs a KcsOpForward and then a KcsOpReverse of a profile on the same buffer, the result is almost equivalent to what it started with before KcsOpForward. Some quality may be lost.

Only one of these operation hint bits can be set at a time for KcsEvaluate(), unlike general load hints for which any combination can be set at the same time. As part of the KcsLoadHints data type, the operation hints signify the required set of operations available to use with the profile. By contrast, KcsEvaluate() uses only the single operation that the application wants to perform.

See "Operation Hint Constants" for more information on operation hints.

Content Hints

Your application can also specify hints about the content of the data being processed. Consider, for example, a photographic image data or computer-generated graphic image data. A CMM can use these hints to do a better job of converting the data such as adjusting the gamut-mapping technique.

See "Content Hint Constants" for more information on content hints.

Freeing Profiles

After creating a complete color profile (CCP), your application can use it more than once. For example, it can use the CCP to convert images page-by-page during printing and to process individual rasters or tiles in a large image. When your application no longer needs the profile, it can call K()csFreeProfile() to free the profile's resources. The profiles in the profile sequence used to create a CCP can be freed without affecting the CCP.

Managing Profile Memory

The KCMS API expects the application to allocate memory required for the data returned by the KCMS framework. In general, the application allocates a C structure and passes a pointer to that structure into the KCMS framework.

The one exception to this is the profile. The KCMS framework returns and accepts a profile Id only. Your application must manage the memory allocated for the Id. To inform the KCMS framework that it should release the memory associated with the profile Id, your application must call the KcsFreeProfile()function.

Optimizing Profiles

Once a color profile has been loaded, a CMM may be able to optimize it. Using the KcsOptimizeProfile()function, your application can optimize a profile (an individual profile or a CCP) in two ways:

• First, your application can optimize a profile to make it more accurate (by eliminating intermediate round-off errors, for instance), smaller (by merging sequences of look-up tables, for instance), or faster (by precomputing some results). The application specifies whether size, speed, accuracy, or some combination is more important.

• Second, by using load hints to limit a profile's operations, your application also may affect its optimization. This is valuable, for instance, if you want to write color data with a DCP that will be used later to read the data. The size of the DCP can be significantly reduced (depending on the CMM in use) by restricting the profile to the forward operation only.

Because optimization can take a long time, your application can provide a callback similar to the one used with KcsEvaluate().

After your application optimizes a profile, it must call KcsSaveProfile() to save the profile for future use. Then it can use this profile with KcsLoadProfile() to avoid the slow performance of KcsOptimizeProfile().

Saving an optimized profile has some potential implications. The optimization may indirectly affect future operations on the profile. For example, if the profile is optimized for size, portions of the profile needed only for highest accuracy may be discarded, resulting in compromised accuracy.

Characterizing and Calibrating Profiles

Characterization establishes a norm for a particular device across a range of samples of the device. This form of profile is typically supplied by a profile vendor. To obtain an optimally accurate DCP for a particular device, calibration is required.

Calibration makes measurements of an individual device and applies them to the base DCP. This causes the updated DCP to represent the actual color device the customer is using.

The KCMS API provides two API functions, KcsCreateProfile() and KcsUpdateProfile(), to create new blank profiles and then to update them with characterization data or calibration data.

The first step your application should take in building a new profile is to create an empty profile using KcsCreateProfile(). Then it can fill the empty profile with KcsSetAttribute() to describe the device being characterized. For example, it can supply monitor chromaticities and white-point values. Measurement data is required for KcsUpdateProfile() to complete the creation of the new profile. Once updated, your application should save the profile with KcsSaveProfile() to the desired KcsProfileDesc location.

Updating profiles typically is a CMM-dependent operation. Using measurement data at the KCMS framework interface level frees you from details of the profile format and the process by which the CMM turns the measurement data into its methodology for color manipulation.

The default CMM supports characterization and calibration of monitors and scanners.