[Insight-developers] Image memory model

[Mathieu Malaterre]

Hi Dan,

  Reading your email, I would think you are not running any 3D image
algorithm, as you are displaying one 2D slice at a time. Therefore,
why not instanciate DimensionZ of filters you want to run ? I think
those filters would be independant and thus could be call from
different thread. You would mimic the behavior of ITK- extent splitter
(used internally for ThreadedGenerateData) since it always split along
the highest dimension, except your threadExtent have a fixed dimz = 1.

  On a different note, if you have the souce of the software
displaying your 2D slice, why not do the contrary and have this
software use independant 2D slice of the contiguous ITK 3D volume ?

  Even if I think support for slice dis-contiguous would be a very
cool thing to have in ITK, I do not believe this is going to hapen any
time soon. I am pretty sure that some filter (if not explicitely)
requires O(1) access time to neighbooring pixels otherwise would be
too slow to be run.

  IMHO I would think that just like STL will have concept checking,
ITK could have a notion of concept checking where a filter would not
require slice contigous model to be run 'fast enough' (whatever that
mean). So that simple algorithm (like rescaling) could be instanciate
on both the 3D contiguous model or on the slice dis-contguous model,
but on the contrary gradient filter (requiring neightboor info) could
not be instanciated with the slice dis-contiguous model.

2 cents,
-Mathieu

On Fri, May 23, 2008 at 1:04 PM, 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.
>
> 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
>



-- 
Mathieu