|| ||           || Doxygen's  

---

The way image operations work

This is a description of the interaction between the various concepts that work together to implement an image processing operation. The description servers as a road map for analysis of the implementation. Also, it shows where the user is actually interacting with the infrastructure when a new image processing operation is being implemented.

To make the description more concrete, we trace the implementation of HxAbs. Note that you can easily trace the implementation of any operation in Global image functions via the source code incorporated in the documentation.

(1) Global image functions : (HxAbs)

Operations on images are invoked via a global function (see Global image functions for an overview). Basically, a global function is a wrapper around an HxImageRep member function that may do some prior initialization and translation of parameters.

So, HxAbs calls HxImageRep::unaryPixOp.

(2) HxImageRep member functions (HxImageRep::unaryPixOp)

The member functions of HxImageRep match the generic operations on images and their variations listed in Image processing patterns and variations. The most important task of the member function itself is to instantiate a method frame (see Method frames for an overview) to enfore the 'value' paradigm and to allow for heterogenous image types. To start the actual operation, the call is forwarded to HxImageData.

So, HxImageRep::unaryPixOp calls HxImageData::unaryPixOp.

(3) HxImageData member functions (HxImageData::unaryPixOp)

The member functions of HxImageData try to locate the approriate image functor (see Image functors for an overview). Lookup is based on a key. A key is constructed from the signature of the object image (this image) image and the name of the image functor. When present in the function, other image parameters may also be incorporated in the key. Note that the type of the key is "linked" to the member function. For example, unaryPixOp uses HxImgFtorUpoKey.

With the key, an image functor is searched for in the functor table and downcast to the level of "I-nary" functors (see Image functors). The functor found is given the task of invoking the actual functor (the "real" functor, see Image functors) via callIt.

So, HxImageData::unaryPixOp calls HxImgFtorI2::callIt.

(4) "I-nary" level image functors (HxImgFtorI2::callIt)

This is actually a pure virtual member function. It is implemented one level lower in the tree (the "cast" level) by a template class.

So, we end up in HxImgFtorI2Cast::callIt.

(5-1) "cast" level image functors (HxImgFtorI2Cast::callIt)

At the "cast" level, the polymorphic HxImageData parameters are converted to statically typed data pointer parameters. The data pointer parameters are passed to the doIt function of the same class.

So, HxImgFtorI2Cast::callIt calls HxImgFtorI2Cast::doIt.

(5-2) "cast" level image functors (HxImgFtorI2Cast::doIt)

This is actually a pure virtual member function. It is implemented at the lowest level in the tree by the "real functor".

So, we end up in HxImgFtorUpo::doIt.

(6) "real" image functors (HxImgFtorUpo::doIt)

The "real" functors introduce additional information for the pattern to work, typically in the form of template parameters. The number and type of the template parameters depend upon the pattern. For example, HxImgFtorUpo has only one : UpoT.

The template parameters may use information from the tag list for run-time initialization. To that end, the tag list is passed to the constructor of the template parameter.

Variations on patterns are typically specified through typedefs in a template parameter. Based on these typedefs, the appropriate global template function is selected to do the actual work. The selection is done by a separate global template function called a dispatch function.

So, HxImgFtorUpo::doIt calls HxFuncUpoDispatch

(7-1) global dispatch functions (HxFuncUpoDispatch)

A dispatch function is a global template function that selects the appropriate global template function implementing a variation on a pattern via typedefs in a template parameter.

The unary pixel operation has two variations : translation variant and translation invariant. The variation is defined by the TransVarianceCategory typedef in the UpoT template parameter.

So HxFuncUpoDispatch calls HxFuncUpo(DstDataPtrT,SrcDataPtrT,HxSizes,UpoT&,HxTagTransInVar) or HxFuncUpo(DstDataPtrT,SrcDataPtrT,HxSizes,UpoT&,HxTagTransVar).

(7-2) global image processing functions (HxFuncUpo)

At last, we have come to the function that actually implements the pattern and does some image processing. That is, the function implements "the loop over all pixels in the image" and calls the user defined functor(s) at the pre-defined moments.

Note that two times a virtual function was used to go down in the functor hierarchy. Ensuring the "right" path is enforced by the instantiations of the actual image functors and the keys. See HxInstantiatorAbs_c for the instantiations of our HxAbs example.

Graphical overview of the way image processing works

---

Go to the next section or go to images or return to the index.

---