From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2001-11-15 17:17:59
----- Original Message -----
From: Peter Dimov <pdimov_at_[hidden]>
Sent: Thursday, November 15, 2001 4:01 PM
Subject: Re: [boost] VIGRA - Image processing for boost
> From: "Fernando Cacciola" <fcacciola_at_[hidden]>
> > From: Peter Dimov <pdimov_at_[hidden]>
> > > This is one of the rare cases where I'd recommend a policy-based
> > The
> > > type of an 'image element' is orthogonal to the storage policy.
> > >
> > I think that they are not *entirely* orthogonal.
> Some combinations don't make much sense, but this doesn't mean they aren't
> > AFAIK, encoding schemes are different for color and bi-tonal (binary)
> > images.
> Which encoding schemes? linear, packed, RLE, huffman, LZW can be applied
> elements of any size.
This depends on how you interpret the meaning of 'being' a encoding scheme.
That is, bi-tonal econdings exploit the fact that the image has only two
tones, not only the redundancy of the data.
For example, the RLE used for binary images is not exactly the same as the
RLE used for color drawings.
The former stores only the run length, while the last stores also the color
of the run.
Binary images use truncated/modified huffman encondigs, again using the fact
that these images have just two possible transitions.
Of course you can argue that 'pure RLE'/'extended RLE' is just RLE, and that
'truncated huffman'/'huffman' is just huffman. However, some authors
consider encondings for binary images to be specific of that kind of image.
I'm not against the "pixel representation"/"enconding" orthogonality.
I'm against blurring the distinction between color and 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
> > kind of image.
> > IOW, I don't think that a complete ortogonality is at all useful; that
> > don't think that it would make any sense to use RLE with a color image.
> Sometimes it makes a lot of sense, say when your color image is a line
Yes. My mistake here.
> > I would agree with an interface with both color/binary images and
> > schemes:
> > color_image<float,huffman_encoder> ;
> > binary_image<rle>
> binary_image is obvious, it's a bi-level image; but what does color_image
> mean? How do you represent a four-level image?
I don't understand what's the problem with the distinction between a color
and a binary image.
Most of the image processing literature makes that distinction clear:
a color image contains an arbitrary number of colors, maybe two;
while a binary image is restricted to 2 colors and thus this fact is
exploited by the representation and the algorithms that operates on it.
I'm suggesting an interface were the distinction is made explicit.
It's OK if we have an enconding policy, but keep color/binary images
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk