ICL Overview

The ICL (image converter library) provides facilities to convert single and multiframe images stored in files or descriptors to CFbsBitmap objects. The library also provides facilities to convert single frame images from CFbsBitmap objects to files or descriptors. The key classes of the library (CImageDecoder, CBufferedImageDecoder and CImageEncoder) are plugin based, leaving the list of supported formats open ended. ICL does provide some standard plugins to facilitate some of the more common image formats. These are listed below:

Format Encode support Decode support BMP (Bitmap) Yes Yes EXIF (Exchangable Image File format) Yes Yes GIF (Graphics Interchange Format) Single frame, no transparency Single & multi frame, bitmap mask support JPEG (Joint Photographic Experts Group) Yes Yes MBM (Multi Bitmap) Single frame Single & multi frame MNG (Multiple image Network Graphic) Yes Yes PNG (Portable Network Graphics) No transparency Bitmap mask support SMS OTA (Over The Air) No Yes TIFF (Tagged Image File Format) No LittleEndian and BigEndian sub-type support WBMP (Wireless Bitmap) No Yes ICO (Icon) No Single & multi frame WMF (Windows Meta File) No Std, apm and clp sub-type support

Note: Within ICL, all images can be uniquely identified for purposes of plugin assignment by their type (BMP, GIF, JPEG etc) and their sub-type (for example for WMF, valid sub-types include, std, apm and clp). Each type and sub-type has an arbitrary ID assigned to it by ICL and its associated plugin, for use with the FileNewL() and DataNewL() functions. Supported format types and sub-types can be listed using the GetImagetypesL() and GetImageSubtypesL() functions of the encoder and decoder objects.

The client application does not access the plugin directly as all communication is done via the CImageDecoder, CBufferedImageDecoder and CImageEncoder classes. New decode and encode objects have to be created for each image that is to be decoded or encoded using the first two of these classes; Once the decode/encode operation has completed, the object cannot be reused for another image.

The CBufferedImageDecoder class behaves differently, in that it can be instantiated without specifying an image to convert. Once created the CBufferedImageDecoder object can be used to decode successive images.

The ICL decode/encode classes use asynchronous methods to perform conversions/transformations. The asynchronous operations use the standard system of taking a pointer to a TRequestStatus object that is signalled on completion or the requested action. It is assumed that the client application or calling DLL will hold the TRequestStatus values within active objects. The structure of the active objects themselves is dependent on the code that uses ICL and its own requirements, particularly its internal architecture and how many images are to be opened simultaneously.

In addition to the use of active objects in the interfacing, many of the ICL internal functions make extensive use of them to provide asynchronous behaviour. As with any use of an active object it is necessary to have an active scheduler present in the same thread as the application making use of the object.

The ICL decode and encode objects also have the facility to be run in their own thread. This is achieved by setting the EOptionAlwaysThread option when constructing the decoder or encoder objects. By running the object in its own thread, the application is shielded from any latencies that may occur during image conversion, or possibly due to a badly written plugin.

• ICL client side architecture - brief overview of the architecture of the image converted library client side classes.

• Overview - general overview of ICL, synchronous and asynchronous methods, active objects and concurrency issues.

• Image decoding - frame information and data, still image decoding, animated image decoding, progressive decoding and buffered decoding.

• Image encoding - encoding/decoding feature comparison, image encoding.

• Additional information - dithering, enabling progressive decoding, MIME type and plugin reporting, threading, memory usage, error handling and performance considerations.