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
>
|