Re: [boost] GIL - is there interest for an image library in Boost?

From: Pavel Chikulaev (pavel.chikulaev_at_[hidden])
Date: 2006-06-08 13:58:15

Lubomir Bourdev wrote:
> Hello,
> 
> We have developed the Generic Image Library (GIL) - a library that
> abstracts away the image representation from algorithms written for
> images. It allows for writing the algorithm once and having it work for
> images in any color space, channel depth and pixel organization with
> performance comparable to writing the code for each specific image
> format.
> 
> GIL is currently part of the Adobe Open Source Libraries and we use it
> for several imaging projects inside Adobe. Its only dependency is boost.
> 
> You can find the sources and documentation at GIL's home page:
> 
> http://opensource.adobe.com/gil
> 
> Is there an interest for having GIL be a boost library?
> Also, I would appreciate any recommendations for improving the design of
> GIL.

Sure there is, but I do think that this library is not flexible enough - 
image layout (RGB and RGB classes).

I've got my own small library that is on an early stage of development.
Some examples of library:

Example 1. Defining your own image format with default planar layout:

namespace rgb
{
     struct tag;

     struct red {} const red;
     struct green {} const green;
     struct blue {} const blue;
}

typedef colorspace<
         rgb::tag,
         channels<
             channel<struct rgb::red,   bits<8> >, //or uint8
             channel<struct rgb::green, bits<8> >, //can be also float 
for example
             channel<struct rgb::blue,  bits<8> >
         >
rgb24_colorspace;

typedef image<rgb24_colorspace> rgb8_image;

void foo()
{
     rgb24_image img;

     using namespace rgb;

     img.resize(100, 100);

     img(0, 0, red) = 255;
     img(0, 0, blue) = 25
     img(1, 1) = rgb8_image::pixel_type(128, 128, 128);
}

For every colorspace one could define layout. The default is planar (in 
terms of GIL) (i.g. R G B R G B). To layout data in B G R order or some 
other there is no need to change the colorspace as you have to do in GIL.

Example of layout declaration:

typedef layout<
     rgb24_colorspace,
     row_major,
     alignment<
         row_alignment<4>
     >,
     allocator<std::allocator>,
     position<
         interleaved,
         // B B B B ... G G G G ... R R R R ...
         positions<struct rgb::blue, struct rgb::green, struct rgb::red>
     >
 > my_rgb24_layout;

typedef image<rgb24_colorspace, my_rgb24_layout> myrgb24image;

Other features:
* Images with same colorspaces but different layouts are treated the 
same way.
* Mutable and immutable views of image are available, such as 
channel_view (mutable).
* Row, column, channel, different sliding-windows and layout-specific 
iterators are available.
* Abilility to add custom implicit and explicit colorspace 
transformation algorithms (such as sRGB to CIE Lab).
* Pixel-to-Pixel transformations on images.
* Predefined support for RGB(sRGB and Adobe RGB), RGBA, CMY, CMYK, HSV, 
HSL, CIE Lab, CIE Luv, XYZ, YCbCr colorspaces and transformations 
between them.
* Some algorithms on images (FIR filtering, contrast enhancement, 
histogram equalization, etc).

Unresolved issues:
* Whether support packed formats such as RGB565, RGB555 or not...
* Whether support indexed images or not...

The current implementation uses state-of-the-art Boost.Fusion library.

Is there any interest and need in such additional flexibility (with some 
compile-time cost of course) ?

--
Pavel Chikulaev