[Insight-developers] Image memory model

[Luis Ibanez]

Hi Dan,

Thanks for this detailed description of the options.

Is there a particular set of algorithms that are
of interest for the slice-contiguous image ?

The reason for the question is that, at the end, most ITK filters
access images via iterators, and therefore, a modification in the
iterators behavior may be enough for making a large number of filters
compatible with slice-contiguous images.

In addition, since most filters are templaged over the image type,
your suggestion of creating a new itk::SliceContiguousImage is perfectly
feasible. (e.g. similat to what was done with the itk::OrientedImage).

The Registration Framework will also be very easy to convert too, since
images there are only accessed via the image iterators, and through the
image interpolators via GetIndex() methods.

We may be able to find a middle ground where, without converting the
entire toolkit, a large number of algorithms can be made compatible with
a slice-base memory arrangement and probably with other alternate memory
strategies (for example: octrees).


    Regards,



         Luis


-------------------
Dan Mueller wrote:
> Hi Insight-Developers,
> 
> I am investigating the feasibility of enhancing the ITK image memory
> model to support a slice-contiguous approach.
> 
> I notice this topic has been on the radar for a number of years:
>     http://www.itk.org/Wiki/ITK_Roadmap_2005_2006#Slice_dis-contiguous_images
>     http://www.itk.org/Wiki/Proposals:Slice_contiguous_images
> 
>>From where I sit, the biggest hurdle for this change is not the
> implementation itself, but ITK's backwards compatibility policy:
>     http://www.itk.org/Wiki/ITK_Backward_Compatibility_Open_Discussion
> 
> I am interested in soliciting developer feedback on possible steps
> forward. Here are some questions which might help generate further
> discussion:
>   # 1. How strong is the need in the (medical) imaging community for
> this feature?
>   # 2. What are the possible mechanisms for introducing this feature
> without breaking backwards compatibility (too much)?
>   # 3. Should a sparse memory model also be investigated/introduced
> during this process?
> 
> My thoughts:
> # 1. How strong is the need in the (medical) imaging community for this feature?
> The advent of 64-bit computing has certainly reduced this need (it is
> now possible to have multiple copies of a large image in memory),
> however good memory management practices should still be followed
> (this is especially important in commercial environments). I am
> working on a (commercial) project at the moment in which a DICOM image
> (using a slice-contiguous memory model) is open in memory and I want
> to import this into ITK; currently the only option is to duplicate the
> memory for ITK's contiguous memory model (which is not very
> desirable). For me at least, a slice-contiguous memory model is very
> desirable.
> 
> # 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?). The problem
> certainly is one of balance and moderation: do we strictly adhere to
> the backwards compatibility policy at the cost of not being able to
> make (potentially important) changes/additions to the toolkit? (Ross'
> and Simon's position statements on the backward compatibility open
> discussion wiki page certainly argue for good balance). What is the
> best way to achieve a good balance in this case?
> 
> # 3. Should a sparse memory model also be investigated/introduced
> during this process?
> I think adding the slice-contiguous feature is enough to start with.
> Obviously the sparse memory model should be in the back of our minds
> if/when slice-contiguous support is added.
> 
> Thanks for any input on this discussion.
> 
> Regards, Dan Mueller
> dan dot muel at gmail dot com
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk.org
> http://www.itk.org/mailman/listinfo/insight-developers
>