|
|
Boost : |
From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-11-15 12:30:49
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.
In addition (sorry if I'm misreading something since I've only glanced at
VIGRA) 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>
since many (not all, of course) algorithms actually operate on channels
independently - and rarely differentiate between red and green. (Actually
the number of channels is a runtime property in my image class.)
Another useful property of this scheme is that channels compress better than
packed-pixel formats.
-- Peter Dimov Multi Media Ltd.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk