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

[Andrew F. <aw...@ro...>]

0. The name "vil_image_data"

I still don't like vil_image_data as the name of the source/sink
object.  I think it looks like a chunk of memory, and hints that
it actually *is* the image data, rather than a handle to it.

vil_source would be a great name, if the class were not also a sink

We could follow iostream and use vil_ioimage?

Here are some suggestions
   vil_image_handle
   vil_image_pipe
   vil_data_handle

   vil_source_or_sink

   vil_external_image  // I think I like this one

   vil_large_image  // I know this is basically wrong, 
                    // but it gets the idea across well?
   vil_file_image


> 1. vil_image_view<T>::operator =
> Do people have any objections, corrections, additions to either of
> these operators?

They all look fine to me.  My main question would be "Does a line 
of the form 
  a = b;
, where a and b are vil types, ever do an expensive copy?"

> 
> 2. order of function parameters for vil2/algo
> 
> At the VXL meeting there was a distinct preference for
>   vil2_algo(source, destX, destY)
> over
>   vil2_algo(destX, destY, source)
> 
> The preference was based on an appeal to Matlab (which 
> favours the former),

Oh no! eeek!  Actually matlab is [destX, destY] = algo(source);

But I think the surprise witness pulled in by the defence must
be the STL's

  std :: transform(InputIterator first, InputIterator last,
                   OutputIterator result, UnaryFunction op);

strcpy's advanced years and decrepitude must make its 
evidence suspect.

My personal rule is that arguments should be ordered by their
frequency of being varied, from least- to most- frequent. i.e.
"constants" first, then "inputs", then "outputs", e.g. 

canny(0.2, 10, in, &out);

I vote for A.

> 3. Type of vimt_transform_2d.
> If anyone would like to see vimt_transform offer a wider 
> range, please let
> us know.

Look at the existing vil_warp ?  That works well and imposes no
restrictions on the transforms.


> 5.
> Names of get_view functions etc.
>   virtual bool set_view(const vil2_image_view_base& im,
>     unsigned x0, unsigned y0,
>     unsigned nx, unsigned ny) const=0;
Do you mean s/const// ?
If the view is going to be modified I'd be inclined to pass
by explicit reference:
    view<byte> v;
    image_data.set_view(0,0,768,576, &v);
This makes it clear that v is likely to be changed.

> Another reason is that we have most of our internal code uses 
> "float" and
> "vil_byte", so we'd like not to have to convert :)

SRTM ("Sounds reasonable to me")


> 7. Use vxl_int_32 or vxl_sint_32.
> in vxl_config.h there are separate typedefs for signed and 
> undecorated ints
> Why do we need two of our own typedefs for a signed integer when the
> standard defines "signed int = int"
> 
> Should we get rid of vxl_sint_32, vxl_sint_16, etc from vxl_config.h?
> If not I propose using vxl_int_32, not vxl_sint_32 in vil2. 
> These names will
> form part of a pixel format enumeration, so I need 
> standardise on one name.
> Is this OK?

SRTM.

> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: DEDICATED SERVERS only $89!
> Linux or FreeBSD, FREE setup, FAST network. Get your own server 
> today at http://www.ServePath.com/indexfm.htm
> _______________________________________________
> Vxl-maintainers mailing list
> Vxl...@li...
> https://lists.sourceforge.net/lists/listinfo/vxl-maintainers
>