The VXL Project

On Wed 13 Aug 2003, Ian Scott wrote:
> Are you suggesting that we should add a friend constructor function to
> vil_memory_image that takes a single memory pointer, and that Mark should
> use that? If so I can't see any reason to be that restrictive. Or have I
> missed something?

I am not suggesting anything of the sort. I think I jumped into the
middle of a discussion and did nothing but introduce confusion.

I merely pointed at vgui_generic_image_view which is esstentially an
image view with run-time (instead of compile-time) pixel format
information. I was suggesting that this may be a useful thing, and
perhaps could be incorporated into vil if someone else also needed it.

Amitha.

On Wed, Aug 13, 2003, Ian Scott wrote: 

Regarding converting a vil_image_view to a vil_memory_image:
> Well, I'm not sure why one would want to do (see my previous email to the
> list). However, If someone wants to do it, the only fundamental problem is
> the risk of confusing themselves.

So the original reason why I posed the question of how one might acquire
a vil_image_resource from a vil_image_view is because I was looking for
a way to easily pass around image information without committing to a
specific type for a vil_image_view.

Upon loading images from files, I would store them to a vector of
vil_image_resource_sptr objects. Video processes could acquire those
vil_image_resource_sptr's and do with them whatever they wanted -- using
the easy get_view function, getting a vil_image_view in whatever format
is desired is very simple.

However, upon altering those images, I was looking for an easy way to
store the altered images as vil_image_resource_sptr objects again. 

At this point I don't think I completely understand the purpose of
vil_image_resources -- from the discussion between Ian and Amitha, it
seems I should storing these images in a vector of
vil_image_view_base_sptr objects instead.

Part of the reason I was led to begin using vil_image_resources was from
the documentation in the "VXL Book" on "Converting from using the old
vil1 to vil" -- it states that the abstract vil1_image is now replaced
with a smart pointer to a vil_image_resource. Although the documentation
later states code written using vil1_images should be converted to using
vil_image_views, I was under the impression that for storing and passing
generic image information from function to function, vil_image_resources 
would be the way to go. Perhaps that section of documentation could be
re-worded to put a stronger emphasis on using vil_image_views and
vil_image_view_base_sptrs? 

Mark Johnson
mrj@...

My own view is the following

When processing pixels - you are advised to use a vil_image_view<T>.

When wanting to represent images from a wide variety of sources that may not
fit all in memory, whose type you may not be able to know in advance, and
about which there may be additional image-related data (e.g. pixel sizes,
colour-specifications) you should use a vil_image_resource(_sptr).

This leaves a grey area however. This is the case where the image has a real
pixel type but which we currently do not want to deal with, and where the
image is stored wholly in memory, then I suggest you use a
vil_image_view_base_sptr. We originally did not advertise this option,
because we didn't want people using it too much, and adding lots of extra
APIs to vil. Currently they are just used to interface vil_image_view and
vil_image_resource. However, the vgui case you describe appears to be an
obvious place where vil_image_view_base_sptr would be ideal.

As an aside, there is a 4th class-tree that you can use. The vimt_image
class in mul is used by the Manchester group to pass images around a lot
without worrying just yet about their types. A vimt_image also contains a
world to image transform. vgui however cannot depend on vimt.

I think all this confusion calls for better documentation. So I'll add some.

Ian.

> -----Original Message-----
> From: Mark Johnson [mailto:mrj@...]
> Sent: Thursday, August 14, 2003 3:18 PM
> To: vxl-maintainers@...
> Subject: Re: [Vxl-maintainers] FW: quick vil question
>
>
> On Wed, Aug 13, 2003, Ian Scott wrote:
>
> Regarding converting a vil_image_view to a vil_memory_image:
> > Well, I'm not sure why one would want to do (see my
> previous email to the
> > list). However, If someone wants to do it, the only
> fundamental problem is
> > the risk of confusing themselves.
>
> So the original reason why I posed the question of how one
> might acquire
> a vil_image_resource from a vil_image_view is because I was
> looking for
> a way to easily pass around image information without committing to a
> specific type for a vil_image_view.
>
> Upon loading images from files, I would store them to a vector of
> vil_image_resource_sptr objects. Video processes could acquire those
> vil_image_resource_sptr's and do with them whatever they
> wanted -- using
> the easy get_view function, getting a vil_image_view in
> whatever format
> is desired is very simple.
>
> However, upon altering those images, I was looking for an easy way to
> store the altered images as vil_image_resource_sptr objects again.
>
> At this point I don't think I completely understand the purpose of
> vil_image_resources -- from the discussion between Ian and Amitha, it
> seems I should storing these images in a vector of
> vil_image_view_base_sptr objects instead.
>
> Part of the reason I was led to begin using
> vil_image_resources was from
> the documentation in the "VXL Book" on "Converting from using the old
> vil1 to vil" -- it states that the abstract vil1_image is now replaced
> with a smart pointer to a vil_image_resource. Although the
> documentation
> later states code written using vil1_images should be
> converted to using
> vil_image_views, I was under the impression that for storing
> and passing
> generic image information from function to function,
> vil_image_resources
> would be the way to go. Perhaps that section of documentation could be
> re-worded to put a stronger emphasis on using vil_image_views and
> vil_image_view_base_sptrs?
>
> Mark Johnson
> mrj@...
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet
> _072303_01/01
> _______________________________________________
> Vxl-maintainers mailing list
> Vxl-maintainers@...
> https://lists.sourceforge.net/lists/listinfo/vxl-maintainers
>