> 2. order of function parameters for vil2/algo
> At the VXL meeting there was a distinct preference for
> vil2_algo(source, destX, destY)
> vil2_algo(destX, destY, source)
> The preference was based on an appeal to Matlab (which favours the former),
> as well as reference to strcpy, etc (which it was claimed favours the
> former.) The order of parameters in operator= favours the latter. After
> reading string.h, I find that the declaration of strcpy is
> char *strcpy( char *strDestination, const char *strSource );
> which favours the latter layout.
> we believe that strcpy is the star witness in this case, but if a majority
> disagree we will defer. Vote please for
> A. vil2_algo(source, destX, destY) or
> B. vil2_algo(destX, destY, source)
I vote for A. No good reason - it just seems more natural to me.
> 4. Which functions on vil2_image_view<T> should be members?
> Currently we have a minimalist approach.
I personally prefer a maximilist approach. Mostly I take this view because of
ease of programming and finding relevant functions etc. Sometimes, I spend a
bit of time searching the documentation for appropriate functions especially
on vil (since most functions are not in the vil_image hierarchy). Much of the
time I'm reduced to grep'ing the source code or looking at filenames to see if
anything appropriate is there. Not sure if there is a good solution to this
though. Obviously including too much will make the class unwieldy. Perhaps a
vil2_image_functions class or something similar?
I don't have strong opinions on the other stuff.
Brendan McCane Email: mccane@...
Department of Computer Science Phone: +64 3 479 8588/8578.
University of Otago Fax: +64 3 479 8529
Box 56, Dunedin, New Zealand. There's only one catch - Catch 22.
From: Ian Scott <ian.scott@st...> - 2002-10-02 09:29:14
> Sometimes, I spend a
> bit of time searching the documentation for appropriate
> functions especially
> on vil (since most functions are not in the vil_image
> hierarchy). Much of the
> time I'm reduced to grep'ing the source code or looking at
> filenames to see if
> anything appropriate is there. Not sure if there is a good
> solution to this
Normally I would say that our vxl search engine is the solution
However, our webserver is having problems right now. It should be working
again in a day or so. I find it extremely useful for the problem you
In the longer term, there is good reason not merge all functions on images
into just one .h file. For instance a simple view transform such as
flip_ud() can't really go in the same place as canny(). Some compromise may
be sensible here.