Flexibility is provided for developers to supply their own compression algorithms to compress image data serialized to disk. A pure virtual base class, CK_Compression, defines the interface. A sample compression class, CK_RLE, is provided. This is a basic run-length encoded compression algorithm that is most useful in images with large areas filled with one color, such as transparent images.
Compression is achieved by creating a compression object, such as an instance of CK_RLE, and telling an instance of CK_Image to use it via the setCompression() method. Only one instance of a compression object (of a given type) need be created, because it can be used by many CK_Image objects.
This architecture was designed for a number of reasons:
Compression Ids
The CK_Compression class defines the getId() member function. Each compression class created by the user must return an id that uniquely identifies the class. For example, all instances of CK_RLE will return 1 when getId() is called. There is a good reason for this, and this has to do with image tables (CK_ImageTable). An image table can hold many CK_Image objects, and the entire table can be serialized to disk. The problem is that each image in the table can be compressed differently, or not compressed at all. When the image table deserializes an image, it must know what decompression to use. The solution is this: The compression id is always stored with the serialized image. If one instance of each type of compression object is created beforehand, then the CK_ImageTable can 'lookup' the compression object given the compression id. (An internal list of every compression object created, and this list is used by classes such as CK_ImageTable.)