RE: [boost] VIGRA - Image processing for boost

From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2001-11-20 17:55:54

----- Original Message -----
From: Peter Dimov <pdimov_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Saturday, November 17, 2001 9:54 AM
Subject: Re: [boost] VIGRA - Image processing for boost

> From: "Fernando Cacciola" <fcacciola_at_[hidden]>

Peter,

Sorry for the late response but I wanted to think it all over again.

I'll explain the details below, but now I think that the interface
basic_image<pixel_type,encoding> is appropriate in terms of completeness,
but also more complex.
I suggest that if, as a tradeoff, Vigra is going to support
internally-encoded images only for the bitonal case, then it should do so
with a separate class.

> > It seems that our only disagreement is whether a binary image should be
> > considered as a different case and not as a special case.
>
> What would you gain by considering a binary image a different case?
>
Simplicity.
That is, if Vigra would generally support the <pixel_type,encoding>
interface
then this wouldn't be of much use;
but I think it isn't, so having a separate class is a reasonable compromise
(reasons below).

> > 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.
>
> Sorry, could you elaborate on that a bit?
>
I didn't frased that correctly, sorry.
See below.

> > 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>"
>
> Again, what would you gain by making basic_binary_image<> a separate class

> rather than a specialization of basic_image<>?
>
Let me explain:

What are the semantics of image<int>, or image<float>, say image<T>?
That the pixel values can be represented by the type T? Certainly.

That I can I expect it to have storage/access complexity similar to that of
T[]?
IMO, yes, and this is a fundamental property of image<T>.

Now, what about image<bool>?
If I want it to be like an arrangement of elements of type bool, that is,
like bool[]; then image<bool> is OK.

However, this thread started not because Vigra doesn't support image<bool>,
since it does, but because the semantics of image<bool> (which are similar
to that of bool[]) doesn't entirely fit the requirements of a user of a
'binary' image (because it supports fast access time but bigger storage).

I think that a binary image is conceptually an array of 'bits', so it cannot
be *properly* described as XXX[] regardeless of the type XXX.
Of course, you can use bool[] to make room for all the bits, but you can do
so with any builtin type as well.

My point is that there are two key aspects on the interface
image<pixel_type>:

1) you can put and get pixels whose values can be represented with the type
pixel_type
2) the storage/access semantics of the image are similar to that of
pixel_type[size].

IMO, the second property is very important, and is currently supported by
the Vigra BasicImage<> class.

Now, with image<bool> we have two choices: support both aspects, which is
gained by doing nothing;
or support only the first but gaining a compact representation.
But, if image<bool> were to support only aspect 1 we would have a special
case with a behaviour similar
but not exactly like the behaviour of the general case image<N>.
This is why I suggested to have a separate class, BinaryImage, which is not
like BasicImage<bool> in that
it doesn't behave like bool[].

I understand that if BasicImage<> had a second template argument, then that
second argument would
appropriately express if the image supports the second aspect, so a separate
class wouldn't be needed.

What I don't want is to have BasicImage<bool> *silently* behave differently
than BasicImage<int> in terms
of similarity with bool[]/int[].

So, IMO, the options are:

   BasicImage<pixel_type,encoding>

 or

   BasicImage<pixel_type> and BinaryImage

The former is more complete, but also more complex; the later is simpler and
just as appropriate as the first.

> > > 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?
>
> If you have an algorithm that takes basic_image<> and this algorithm does
> not need to treat binary images as a distinct case but happens to work on
> them as is, you don't have to supply a specialization for it.
>
> In the basic_binary_image<> case, you have to reimplement all algorithms
no
> matter whether the generic version would do the job as well.
>
I fail to see how having a different class name would make this happen.
basic_image<> is not a complete type, so the algorithm should be template
based,
thus the a specific type shouldn't be required, unless, of course,
template template parameteres were used.
What I am missing?

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