RE: [boost] VIGRA - Image processing for boost

From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2001-11-16 17:03:39

From: "Fernando Cacciola" <fcacciola_at_[hidden]>
> > From: Peter Dimov <pdimov_at_[hidden]>
> > > > AFAIK, encoding schemes are different for color and bi-tonal
(binary)
> > > > images.
> > >
> > > Which encoding schemes? linear, packed, RLE, huffman, LZW can be
applied
> > to
> > > 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.
>
> I agree. But whether an image is bitonal is determined by the element
type.
> 'bool' has two possible values, and hence a basic_image<bool> is bitonal.
>
> You could define a type that has four possible values, and it will produce
> an image with four levels.
>
> It is true that basic_image<bool, rle> can use a specialized form of RLE
> that exploits the fact that there is no need to store an element value.
This
> can be accomplished in various ways. One option is to make 'rle' simply a
> type tag that determines the storage policy. Another is to templatize the
> storage policy on the element type: basic_image<bool, rle<bool> > (or if
you
> want to be on the cutting (modern) C++ design edge, use a template
template
> parameter for the storage policy.)
>

It seems that our only disagreement is whether a binary image should be
considered as a different case and not as a special case.
IOW, if I would consider a binary image as a special case then I would
certainly agree with the basic_image<bool,xxx> interface.
It is not your interface what I don't like, but the generalization you are
implying with it.

> > I'm not against the "pixel representation"/"enconding" orthogonality.
> > I'm against blurring the distinction between color and binary images.
>
> There is no inherent distinction between the two. An image is a
> two-dimensional array of element (tuples.) When the element (tuple) is a
> simple bool, this is a bitonal image.
>
But I am not sure about this.
I think that a binary image is not just a image with 2 possible colors.
I think that a binary image is a different entity, with so much specific
properties that should be regarded
not as a special case of a color image but as a separate case.

Anyway, I'm not an expert, so I can be plain wrong; and even if I were an
expert and were theoretically right,
we are discussing the interface of a practical library, so if users would
prefer your view of a binary image as
just a special case of a color image then your interface is correct;
however, if users would prefer my view of
a binary image as a separte entity,
then I suggest "basic_color_image<pixel_type,encoding> and
basic_binary_image<encoding>"

What do others think about these two views?

> This allows generic algorithms to still operate on bitonal images
> unmodified, while in the same time allowing you to replace some with
> specialized versions.

How the choice of 'basic_image<bool>' vs 'basic_binary_image<>' could affect
the generality
of the algorithms?
Do you mean that those algorithms would take template template parameters?

>
>
> > I don't understand what's the problem with the distinction between a
color
> > and a binary image.
>
> There is none (problem, that is, not distinction.) A binary image is a
> special case of an image.
>
Well, if others agree with you here then this issue is settle.

> > 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.
>
> This is a dangerous definiton of a binary image since it means 'a paletted
> image with a palette size of 2.'
>
Why? Because I said that a binary image contains two "colors"?
Well, replace that with "intensity levels" (or whatever, the point is that
the pixels of a binary image are bivalued)

>
> I don't know whether VIGRA will (or should) handle paletted images.
>

Yes, this is a different question. And I don't know either.

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