No subject

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