Features

This page provides a quick overview of the features of the library. If you're not sure whether the library does what you need, read on.

Image File Decoding

The main purpose of paintlib is to decode image files and make the data available in a format that is easy to use. Supported formats are PNG, TGA, TIFF, JPEG/JFIF, Windows BMP, and Mac PICT as well as TIFF previews in EPS files. Support for PNG is through the PNG reference library libpng. TIFF is supported through use of Sam Leffler's libtiff. This library is the most complete implementation of the TIFF standard that I know of. The Independent JPEG Group's libjpeg provides solid support for the JPEG/JFIF format. The TGA, BMP, and PICT decoders are my work. They have been tested with a wide variety of files. The PICT decoder skips any non-bitmap data in the file and supports PICT/JPEG.

The library is capable of auto-detection of the image file type. Input data can come from memory or disk - or from a custom data source. Under windows, images linked into the .exe as resources can also be loaded. All data is converted to 8 or 32 bpp before being handed to the application.

Bitmap Manipulation

The image data is placed in an object of class CBmp. This class is an abstract base class defining an interface for bitmap storage and manipulation. The actual details of storage are defined in derived classes. Currently, three derived classes are defined: CWinBmp for windows DIBs (Device Independent Bitmaps), CAnyBmp for simple OS-independent storage, and CDIBSection for windows DIB sections. New classes can be defined for other operating systems and storage formats, the only restriction being that pixels in one line are stored consecutively and not as separate planes. To be compatible with the decoders, a bitmap class must define formats with 8 and 32 bpp.

[Bernard Delmées piclook (one of the sample programs) contains CDrawDibBmp, a derived bitmap class that uses the windows DrawDIB api for blitting.]

There is virtually no difference in speed between using the OS-independent interface and directly accessing OS-dependent data. The power of this design is demonstrated by the Windows GUI demo. This demo includes classes which implement complex bitblts with alpha information, resizing, and transparency in an OS-independent fashion.

Open Design

One of the primary design goals for paintlib was openness for expansion. Implementing additional decoders is simple because many basic operations (data source management, MSB/LSB conversion, error handling,...) have been taken care of already. Integrating libpng, for example, took Gilles and me about two days (total) of work. The data sources and the bitmap format can be tailored to suit the needs of the users.

While most of the development is being done under Microsoft Visual C++, paintlib is plattform-independent. Care was taken to ensure that the speed of the library did not suffer more than necessary through plattform- and data source-independence.

Missing...

paintlib is far from complete. I will implement new features as time permits. I plan to implement those features a lot of people ask for first, so tell me what you need. On the other hand, I'm doing this in my spare time. Don't expect miracles.

Of course, I welcome help of any kind. Indeed, if you augment the library in some way and don't submit anything, you're violating the spirit of free software IMHO. System-specific support for platforms other than DOS/Windows will have to come from other people anyway because I don't have access to other machines. Send me makefiles along with instructions, and I'll add them to the distribution. I also need bug reports, comments on the documentation, and above all code... my address is on the intro page.

If you'd like to contribute stuff to paintlib, please make sure it's free of copyrights of other people. To avoid complications, the core paintlib library will need to stay (c) Ulrich von Zadow. I commit to supporting paintlib as open source software for as long as I can, but having parts of the code copyrighted by different people - all of whom I'd have to ask if a word changes in the terms of use - would generate too much hassle. (If you can't live with this arrangement, you can always submit code for inclusion as a sample.)

This is the current todo-list in no particular order:

GIF support is not planned, since the GIF compression algorithm is patented by unisys and supporting GIF would mean paying a royalty to unisys.