Re: [boost] VIGRA - Image processing for boost

From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-11-15 13:30:32

From: "Ullrich Koethe" <u.koethe_at_[hidden]>
> Peter Dimov wrote:
> > This is one of the rare cases where I'd recommend a policy-based design.
The
> > type of an 'image element' is orthogonal to the storage policy.
>
> In principle, I agree, and VIGRA is designed this way. But in case of
> packed bits and RLE images, I think 'image elements' and storage policy
> are NOT orthogonal. You loose most of the benefits of the specific
> storage format if you force orthogonality here.

The interface as presented to the user would be orthogonal:

basic_image<bool, linear> // == basic_image<unsigned char, linear>
basic_image<bool, packed> // == vector<bool>
basic_image<bool, rle>
basic_image<unsigned char, linear>
basic_image<unsigned char, rle>

You'd still be free to specialize appropriately to take advantage of
storage-specific optimizations, or prohibit, say, basic_image<unsigned char,
packed>.

> > I've found it useful to separate the number of channels from the
> > element type. That is, in my image library, I don't use
> >
> > image<rgb>
> >
> > but
> >
> > image<unsigned char, 3>
>
> Both formats have their merits (only the first form allows for the
> implementation of a STL-like RGBImage iterator). In fact, in the Python
> version of VIGRA, I'm also using a band oriented format.
>
> This very problem was a major motivation for the introduction of
> 'accessors'. By using accessors (in particular RGBAccessor, RedAccessor,
> GreenAccessor, BlueAccessor, and VectorBandAccessor), the difference
> becomes completely transparent for algorithms. This has worked very well
> also in the case of complex numbers - from the algorithms' point of
> view, it's not important whether a complex image is
> image<std::complex<double> > or image<double, 2>.

True, with an accessor layer on top it doesn't matter whether it's

image<double, 3>

or

image<array<double, 3> >

(when the number of channels is fixed at compile time, which it might not be
if you want to load PSDs or other multichannel formats.)

I chose the band scheme because for my needs (computer games) certain
per-channel algorithms (alpha blending, addition, multiplication) can be
optimized much more heavily using x86 MMX (with a packed pixel scheme, half
of the time is spent unpacking/repacking the pixels.)

> BTW, what's your image library doing? Is it also public?

Proprietary. ;-)

--
Peter Dimov
Multi Media Ltd.