From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2001-11-20 17:55:54
----- Original Message -----
From: Peter Dimov <pdimov_at_[hidden]>
Sent: Saturday, November 17, 2001 9:54 AM
Subject: Re: [boost] VIGRA - Image processing for boost
> From: "Fernando Cacciola" <fcacciola_at_[hidden]>
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?
That is, if Vigra would generally support the <pixel_type,encoding>
then this wouldn't be of much use;
but I think it isn't, so having a separate class is a reasonable compromise
> > 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
> > implying with it.
> Sorry, could you elaborate on that a bit?
I didn't frased that correctly, sorry.
> > Anyway, I'm not an expert, so I can be plain wrong; and even if I were
> > expert and were theoretically right,
> > we are discussing the interface of a practical library, so if users
> > 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
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
1) you can put and get pixels whose values can be represented with the type
2) the storage/access semantics of the image are similar to that of
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> 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
> > the generality
> > of the algorithms?
> > Do you mean that those algorithms would take template template
> 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
> 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
thus the a specific type shouldn't be required, unless, of course,
template template parameteres were used.
What I am missing?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk