Re: [Vxl-maintainers] Questions about vil2. Answers please!

[Amitha P. <pe...@cs...>]

"Ian Scott" <ian...@st...> writes:
> 1. vil_image_view<T>::operator =
> 
> (There is a also copy constructor matching each operator=.)
> 
> Current the code has two of these
> vil2_image_view<T>::operator=(const vil2_image_view_base &)
>   This appears to work for
>   vil2_image_view<char> a, b;
>   ....
>   a = b; // Don't appear to need
>          // vil2_image_view<T>::operator=(const vil2_image_view<T> &)
>   // as well as allowing (as soon as I've written it)
>   vil2_image_view<char> a,c;
>   vil2_image_view<vil_rgb<char>> b;
>   ....
>   a = b; // cheap, automatic view conversion of components to planes.
>   b = c;  // cheap, automatic view conversion of planes to
> components.

I think it's a really bad idea to do automatic conversion in the
operator=: it's too implicit. Rather make the conversion explicit,
c.f. vil_image_as. I don't think enough conversions are required in
well-written code to warrant an implicit conversion.

> I have also added.
> vil2_image_view<T>::operator=(const vil2_image_view_base_sptr &)
>   This allows such things as
>     vil2_image_view<vil_byte> = vil2_load("filename.ppm");
>   and will allow (as soon as I've written it)
>     vil2_image_view<vil_rgb<vil_byte> > = vil2_load("filename.ppm");
>   when vil2_load returns a pointer to a view.

This is a good thing: there it does not conflict with the above, as long
as the vil2_image_view<T>::operator= takes either a vil2_image_view<T>
or a vil2_image_view_base_sptr as arguments. (And does not take
vil2_image_view_base as an argument.)

As you presented at the VXL meeting, the vil2_image_view_base is meant
to be hidden for most things. To this end, the _sptr class could be
written to make it more difficult to accidently (implicitly) convert a
pointer to a _sptr.


> 2. order of function parameters for vil2/algo
> Vote please for
> A. vil2_algo(source, destX, destY) or
> B. vil2_algo(destX, destY, source)

I, too, vote for A. Note that the STL promotes the use of A in all its
code. As Joe wrote, it's a style thing. I think it is good to match
the semantics and style of the style where we can.

Which brings up a related point: could we rename "resize" to
"makesize" or "forcesize"? "resize" as used by the STL has a very
definite meaning of resizing while keeping data. vil2's resize does
not. I think the STL it is a bad idea to start modifying semantics set
by the standard (at least implicitly).

> 4. Which functions on vil2_image_view<T> should be members?
> 
> Currently we have a minimalist approach.
[...]
> (Note we are going to break up vil2_image_view_functions.* so that the file
> prefix naming scheme is observed.)

I agree with the minimalist approach. However, moving functions
outside the class brings up a filename problem: strict adherence to
the vxl file naming scheme will create a whole bunch of little include
files. I don't know if that is good or bad.

( I guess I would mostly use only one or two functions, and it's not
too much of a pain to include them. However, experience tells me that
once included, they are hardly ever excluded, even if the
corresponding function is no longer used. Bad coding, perhaps, but it
happens all the time. )

> 5.
> Names of get_view functions etc.
> 
> I still like the restriction on multi-plane-scalar-pixel views only as
> parameters of these functions. It makes coding a lot simpler. You can still
> have all the functionality you need with multi-component images, but the
> code support for this can localised over a smaller number of code files
> (including the smart vil2_view_image<T>::operator=.)

Modifying my statement above, perhaps it is useful to have an implicit
conversion between view<rgb<x>> and view<x> where the latter has
exactly three planes. However, assuming the load, save, and display
(vgui) routines do this conversion, I don't see it being important
from a user point of view.

> What names should we use for float (and double)?
> I think we should use carry on using "float" and "double", not "vxl_ieee_32"
> and "vxl_ieee_64". The argument that you should use types explicitly defined
> to be the same size as the pixels in the relevant image file format is not
> as persuasive it does in the integer case.

I agree.