Categories: S60 | Symbian C++ | Imaging

This page was last modified 07:04, 30 May 2007.

From Forum Nokia Wiki

In previous versions of Symbian OS all image conversion and manipulation had been performed via client APIs interacting with the Media Server. This was no longer possible since the Media Server had been removed, so a new library had to be created to handle this functionality.

At around the same time that work was progressing on the MMF, another team was set up to provide a new framework that would provide similar image conversion functionality to that of the Media Server, but in a more lightweight manner. This became known as the image conversion library (ICL).

The ICL provides a lightweight library, based on active objects, to support encoding and decoding image files, and the rotation and scaling of bitmaps. The library is a client-side framework that is, if required, capable of decoding or encoding image files in separate threads. In a similar manner to the MMF, third parties can develop plugins to extend the supported image formats. The ICL utilizes the ECom framework to identify the correct plugins and thus all ICL plugins are also ECom plugins. The basic architecture comprises a client API layer, the ICL framework, and the ICL plugins themselves. Illustrated in Figure below, it also shows how data is transferred through the ICL.

Client APIs

The client APIs form the top-level abstraction of the ICL. In Symbian OS v7.0s there are client APIs for the decoding and encoding of images, as well as the rotation and scaling of bitmaps.

ICL framework

The ICL framework provides a communication layer between the client APIs and the actual ICL plugins, and all plugin control is performed via this layer. The underlying architecture is subdivided into two further layers.

• The relay layer provides a connection between the underlying client API classes and the core framework. The relay is mainly used to provide thread encapsulation for the ICL when threaded decoding or encoding is employed. All inter-thread communication is performed by this layer, allowing the Client API classes and the core framework to be ignorant of all threading.

• The core framework is essentially a centralized place for storing data and for achieving the functionality associated with the ICL itself. In normal usage, it is the core framework that performs all plugin instantiation and control. This framework communicates with the ICL plugins via the abstract plugin API that all ICL plugins have to implement.

ICL plugins

The ICL plugins provide the actual decoding and encoding functionality to the ICL. The ICL framework provides four abstract classes from which all ICL plugins are derived. These are CImageDecoderPlugin and CImageEncoderPlugin for decoding and encoding respectively, and corresponding codec classes, CImageReadCodec and CImageWrite - Codec. The intended split in responsibilities is as follows.

• The decoder and encoder plugin classes are designed to deal with the interface to the ICL framework, the retrieval and writing of image headers, and additional non-frame data, such as text fields.

• The read and write codec classes are designed to deal with the main decoding and encoding stages for individual frames. Provided the virtual functions of these classes are implemented, there is no reason why a plugin writer could not have more complicated processing chains inside a plugin. For example, a codec class could forward messages to one or more sub-codec classes, to provide specialized processing.