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

From: Lubomir Bourdev (lbourdev_at_[hidden])
Date: 2006-06-25 11:48:11

>> Then there are refinements of RandomAccessNDImageConcept that allow
for
>> 2D images, and further refinements dealing with concrete,
memory-based
>> images, with the corresponding additional required functionality.
>But there you have row alignment support - Why?

The image owns the pixels and is responsible for allocating the memory
for the pixels. Some algorithms run more efficiently when each row of
the image is word-aligned, or even 16-byte aligned. This is why when you
create an image you can specify if and how you want your rows to be
aligned.
This is again not in the image concept, but in the underlying model
(probably should be in the concept...)
Why is that a problem?

>> The users of the library don't have to deal directly or know the
>> specifics of the underlying models. 
>
>What's the point of BGR class then?

I am not sure I understand your question. bgr_t class is a tag that
specifies the set of channels and the interpretation of each one. You
need this when you want to create a BGR image, for example. It is just a
tag class similar to your tag class:

struct rgb_t { 
    typedef rgb_t base; 
    BOOST_STATIC_CONSTANT(int, num_channels=3);
};

struct bgr_t : public rgb_t {};

As you can see, if you are interested in just the color space and not
the channel permutation, you can use bgr_t::base

>BTW, I would reject "view" concept at all, since it's actually same as 
>"image" concept because every subset of original image (such as 
>subsampled one) is still an image :)

In our earlier designs we used the same class for an image and a view.
The pixel ownership was determined with a smart pointer. Then Alex
Stepanov and Sean Parent convinced me to split these into two.
Originally I thought it will unnecessary complicate things, but now I
think this was the right decision.

An "image" is a container of pixels. It allocates them, does a
deep-copy, a deep-compare, etc. The STL equivalent is a container like
std::vector

An "image view" is a shallow range. It doesn't own the pixels, doesn't
propagate its constness to them, just contains a raw pointer to them.
Does a shallow-copy, shallow-compare, etc. This is equivalent to the STL
ranges, which are often represented as a pair of iterators.

GIL algorithms typically operate on image views (similarly, STL
algorithms typically operate on ranges).

Splitting these two makes the ownership semantics very clear.

>Thanks for your patience and politeness to expain all your points to 
>such a bad listener as I am, and I think I shouldn't have acted that 
>way.

Pavel - please do keep your questions and comments coming. And
criticisms are more helpful to us than praises :-)

Lubomir