KCMS Framework Architecture

Figure 3-1 illustrates the KCMS framework architecture. It provides an overview of how the KCMS classes are used to implement the KCMS framework. Basically, the framework is implemented by manipulating an array of KcsProfile objects within a set of "C" wrapper functions. The "C" wrapper functions are C-to-C++ calls that make up the KCMS API. Use this figure as a general reference as you read this chapter.

Figure 3-1 KCMS Framework Architecture

KcsProfile

KcsProfile objects are created from a static store which is a KcsIO object. KcsProfile objects are described using one of the types in the KcsProfileDesc structure which is defined in the kcstypes.h header file. Objects can read from and write to data in a static store. Examples of a static store include a file and memory. KcsProfile objects generated internally by the framework use a KcsMemoryBlock object.

The KcsProfile class static member function, createProfile() reads the CMM Id from the static store and generates a pointer to the KcsProfile derivative. The CMM Id is located at byte 4 in the ICC profile format. If the CMM Id has no associated runtime derivative, the default KcsProfile derivative, KcsProfileKCMS, is used.

---

Note -

The CMM Id must be in a set location in the file that is the same location as used by the ICC profile format. For details, see "ICC Profile Header".

---

The KcsProfile class contains a set of public member functions that correspond to the KCMS "C" API functions shown in the following table.

Table 3-1 Mapping of API Functions to KcsProfile Class Member Functions

KCMS API Function	KcsProfile Member Functions
KcsLoadProfile()	load()
KcsSaveProfile()	save()
KcsSetAttribute()	setAttribute()
KcsGetAttribute()	getAttribute()
KcsConnectProfiles()	connect()
KcsEvaluate()	evaluate()
KcsUpdateProfile()	updateXforms()

KcsProfileFormat

Each KcsProfile base class contains a pointer to a KcsProfileFormat object. This allows the architecture to link different profile formats and keep the KcsProfile class independent of the actual profile format. The KcsProfileFormat object is created based on the profile format Id (also called profile file signature) and profile version number. The ICC profile format Id is acsp, located at byte 36 in the profile header. (See "ICC Profile Header".) The version number is derived from the profile version number; ICC profile byte 8. The framework uses the version number with the profile format Id so that it can handle different versions of profile formats. For non-ICC profile formats the format Id and version number must be at the same byte location in the static store.

KcsAttributeSet

Each KcsProfileFormat base class contains a pointer to a KcsAttributeSet object and handles all of the functionality for attributes.Using the KcsIO class associated with the parent KcsProfile, the KcsAttributeSet object can load itself from the static store. KcsAttributeSet does not use the KcsIO class directly; it uses the KcsChunkSet utility class to access the static store. KcsChunkSet knows how to handle the mapping from desired information blocks to its actual location in the static store. KcsChunkSet and KcsIO have no knowledge of the contents of the data. That is left to the calling class.

KcsXform

The KcsXform base class contains an array of pointers to KcsXforms. The primary function of KcsXform (or transformation) is to manipulate color data. KcsXform also uses the KcsChunkSet class to load from and save to static store.

KCMS Framework Flow Examples

The following examples will help you better understand the flow of control and data between the KCMS "C" API and the KCMS framework. Use Figure 3-1 as a reference.

Loading a Profile

This example explains what the KCMS framework does when an application makes a KCMS "C" API call to load a profile.

1. Using the KcsIO derivative, the framework determines the CMM Id of the profile.

2. The framework calls the KcsProfile::createProfile() static method and loading starts. It uses the CMM Id of the profile as a key to determine the particular KcsProfile derivative to load. The CMM Id is associated with the dynamically loadable module using entries in the OWconfig file.

   Once dynamically loaded, the module returns a pointer to a KcsProfile object. If the particular CMM Id has no match in the OWconfig file, the framework uses the default KcsProfile derivative, KcsProfileKCMS. There is a special CMM Id key dflt entry in the OWconfig file, so that your CMM can override the default KcsProfile class. (See "KcsProfile Example" for details.) If you want your CMM to override the default KcsProfile class, it must duplicate all of the functionality that the default class handles.

3. The framework calls the load() method on the KcsProfile object pointer that was created in step 2. This causes a KcsProfileFormat object pointer to be created using an entry in the OWconfig file. Then the KcsProfileFormat object loads itself.

   The profile format Id (also called the profile signature or magic number, which starts at byte 36 of the ICC profile format) is used as the key to this entry in the OWconfig file. (For details on the ICC profile format, see "ICC Profile Header".)

4. The KcsProfileFormat object contains pointers to a KcsAttributeSet object and an array of pointers to KcsXform objects. The framework also creates these objects and calls their load() methods so they load themselves from the static store.

   Your CMM can derive directly from the KcsAttributeSet object, since it is statically linked into the KCMS framework. The KcsXform array has an OWconfig entry that uses a 4-byte identifier as a key. For ICC-based profiles, use the 8- and 16-bit LUT tags, mft1 and mft2. (See "KcsXform Example" for details.)

5. If all pieces of the profile load successfully, the framework returns a KCS_SUCCESS status to the calling application.

Getting Attributes

Once a profile is loaded (see "Loading a Profile" ), an application can call the KcsGetAttribute() "C" API function to retrieve the profile's attributes. The following outlines the flow of control at the framework level to obtain the profile's attributes (see Figure 3-2):

1. For the appropriate object in the KcsProfile object array, the framework calls its getAttribute() method.

2. The KcsProfile()XXXX::getAttribute ()calls its KcsProfileFormat::getAttribute() method.

3. This in turn calls its KcsAttributeSet::getAttribute() method.

4. The KcsAttributeSet::getAttribute() method gets the attribute and returns it back up the chain to the API layer.

   Figure 3-2 KcsGetAttribute() Flow Example

   
   

A similar flow of control is true for the other KCMS "C" API calls.