Evaluation

When a KcsXform is instantiated, it is ready to transform n->m component data (unless it is in the process of being built). Since it can handle many different data formats, the KCMS framework encapsulates the description of the data to be transformed into a data structure called KcsPixelLayout. This structure is an array of component descriptions. See the KCMS Application Developer's Guide for more information on KcsPixelLayout.

The KcsPixelLayout structure is used by the eval() methods to describe the information to be transformed. When using an eval()method(), supply a source PixelLayout, a destination PixelLayout, and a callback function. The eval()method takes the data described by the source layout, transforms it, and puts it into the buffer described by the destination layout. If the evaluation is going to take a long time, the callback function is repeatedly called until evaluation is complete.

The layouts can describe the same buffer (a technique called in-place transformation). In this case, the eval() method detects it is the same buffer and optimizes for performance. The layouts can also specify different buffers, in which case the data is moved as well as transformed. You can even supply two layouts which differ in composition (for example, planar RGB and chunky CMYK), and the data is moved and transformed from RGB to CMYK as well as has its composition transformed from planar to chunky. The evaluation methods accomplish this with minimal steps. Evaluation is most efficient when given large buffers of data to transform.

If the transformation is not compatible with the layout(s), it returns an error. For example, if an RGB->CMYK KcsXform * is given two 3-component descriptions, it would return an error if the destination is expecting 4-component data.

If your data can be represented in different formats, get the value of the attribute KcsAttrPixelLayoutSupported to see what the most efficient pixel layout is for that KcsXform derivative.

Evaluation Helper Methods

KcsXform includes only one pure virtual eval() method. It is the one with two pixel layouts and a callback as arguments. Other eval() methods are overloaded in the base KcsXform class to allow other data types to fit a long on each side of the xform, for example,

(long *) -> (long *)

and

aRGB->aR'G'B'

The base class takes all the overloaded methods and creates a pixel layout for each method. Then it calls the pure virtual method. Therefore, derivatives only need to implement one eval() method.

When starting an evaluation, the derivative can use any of the helper functions provided for pixel layout usage. The convertLayouts() method takes any layout and transforms it into any other. If a derivative can only handle chunky, the derivative may want to convert a non-chunky derivative to chunky before the evaluation is started.