Re: [boost] GIL Review - Integration with other graphics libraries, such as Cairo.

From: Lubomir Bourdev (lbourdev_at_[hidden])
Date: 2006-10-07 15:47:52

Tom Brinkman wrote:
>Any thoughts on how GIL will integrate with these other
>graphics libraries?

There are many imaging/graphics libraries out there. People have invested huge efforts to provide efficient and comprehensive set of algorithms to do image processing, vector graphics and vision. GIL's strategy is not to compete with all other libraries (or we would fail miserably!) but to embrace them and allow for efficient integration. Betting on GIL doesn't mean you have to give up the speed of Intel's IPP library or the high quality rendering of Anti-Grain.

The vast majority of image libraries out there support a fixed set of image representations. This means that all of the goods they provide are limited by the set of images they can target. If you want to use features of multiple such libraries you will end up having to convert back and forth between image formats. You can forget about performance and your image quality may suffer too. GIL, on the other hand, imposes no restrictions on the way the image is represented, and it comes with a set of models that out-of-the-box cover the vast majority of common image representations. Because it works natively with the way your pixels are represented in memory, GIL can be used with all these other libraries with virtually no performance overhead.

There are degrees of GIL integration, varying on the amount of work you have to put in and the results you get:

1. Using GIL Algorithms with your favorite library

This is the simplest integration. If you want to use your favorite library but want to invoke GIL algorithms on occasion, all you have to do is get pointers to the raw data (which any reasonable library should allow you to get), create GIL image view from it and invoke the GIL algorithm on it. This is shown in the tutorial and the video presentation.

2. Providing GIL interface to algorithms from another library.

It would be nice to put a GIL interface on the algorithms this other library provides, so they could be called by other GIL algorithms. Of course, such adapted algorithms will not be fully generic; they will only work with the set of image representations supported by your library. So rather than:

template <typename View>
void draw_line(const View& view, const point2<int>& from, const point2<int>& to);

Your interface may look like:

void draw_line(const rgb8_view_t& view, const point2<int>& from, const point2<int>& to);

(Or maybe it will take a generic view but require that it be interleaved and 8 or 16-bit for example.)
As long as you stay within the image formats supported by this other library you will be fine.

3. Full GIL-ification of the algorithms

This integration requires the most work, but has the benefit that this algorithm will now become fully image representation independent, i.e. a first class GIL algorithm. It requires changing the internals of the other library algorithm to use GIL's image view concepts. The algorithm may be fully optimized to use the specific image format; in this case you may have to create a default generic GIL equivalent of the algorithm and invoke the other library one via specialization. An excellent example is Intel's IPP.

If you have a favorite library, we encourage you to provide a GIL extension for it!

Lubomir