RE: [boost] VIGRA - Image processing for boost

From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2001-11-15 13:53:35

----- Original Message -----
From: Peter Dimov <pdimov_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Thursday, November 15, 2001 2:30 PM
Subject: Re: [boost] VIGRA - Image processing for boost

> From: "Ullrich Koethe" <u.koethe_at_[hidden]>
> > Fernando Cacciola wrote:
> [...]
> > > However, in my experience, one resort to this representation ONLY when
> > > memory is the primary concern, so I think that a binary_image class
> should
> > > keep data compressed internally (using RLE, for instance) and not just
> > > bit-packed.
> > > Now, with this in mind, perhaps the path would be to have a
> > > 'compressed_image' type, for which 'binary_image' is derived.
> > >
> >
> > Yes, an RLE image class makes much sense to me. Among other benefits, it
> > allows for extremely fast morphological filters (erosion, dilation etc.)
> > because they can operate directly on the RLE images, without
> > decompression. (AFAIK, such optimized filters are part of the HALCON
> > image analysis system.)
>
> 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.
>
I think that they are not *entirely* orthogonal.
AFAIK, encoding schemes are different for color and bi-tonal (binary)
images.
Thus, the fixed distinction between color and binary images seems to be
appropriate even if a policy-based encoding scheme is supported within each
kind of image.
IOW, I don't think that a complete ortogonality is at all useful; that is, I
don't think that it would make any sense to use RLE with a color image.
I would agree with an interface with both color/binary images and encoding
schemes:

color_image<float,huffman_encoder> ;
binary_image<rle>

but this is beyond the scope of VIGRA as it currently is; therefore, I would
like it to provide just:

color_image  (no enconding) and binary_image (rle used internally).

Fernando Cacciola
Sierra s.r.l.
fcacciola_at_[hidden]
www.gosierra.com