[Insight-developers] Image memory model

[Karthik Krishnan]

On Fri, May 23, 2008 at 11:04 AM, Dan Mueller <dan.muel at gmail.com> wrote:
> Hi Insight-Developers,
>
> I am investigating the feasibility of enhancing the ITK image memory
> model to support a slice-contiguous approach.
>
> # 2. What are the possible mechanisms for introducing this feature
> without breaking backwards compatibility?
> The two current proposals are to either (a) template the itk::Image
> class over the PixelContainer or (b) use inheritance/virtual functions
> to allow the existing itk::Image to operate on a variety of
> PixelContainer classes. Both of these proposals will require the
> removal of  Image::GetBufferPointer(), a massively breaking change.
> With the current backwards compatibility policy I'm not sure this is
> possible. Perhaps one option is to mark this function as deprecated
> and leave it as such for a suitable time (6-12 months?).

Removal, or even deprecation of GetBufferPointer is unacceptable to
most of us here at Kitware. We use VTK heavily and often our use of
ITK is in conjunction with VTK. ie ITK for image analysis/registration
"seamlessly" connected to VTK for visualization.

The GetBufferPointer() is the "seamless" part of that connection.

----

That said, you might tell us a bit more about the problems you are
trying to solve. As Luis mentioned having another image class along
with your own iterators to walk that class is a good option. However,
depending on the problem you are trying to solve, you may not need a
different ITK Image layout at all.

If your concerns are memory limitations, you might consider other
solutions such as "Streaming" which is supported by "parts" (several
filters, can be supported by readers) in ITK and VTK. This will let
you load up sub-blocks of your image into memory and process them one
at a time.

Thanks
Regards
--
karthik

BTW: I've been playing around with SharpImage. Its very very cool. Thanks