[Insight-developers] Image memory model

Bill Lorensen bill.lorensen at gmail.com
Fri May 23 15:39:20 EDT 2008


I agree that we should look at the problem (the what), not a single
solution (the how). There may be many ways to solve the problem. As
Karthik said, maybe the solution will be better support for streaming.
Or there may be other solutions.

Bill

On Fri, May 23, 2008 at 3:12 PM, Karthik Krishnan
<karthik.krishnan at kitware.com> wrote:
> 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
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk.org
> http://www.itk.org/mailman/listinfo/insight-developers
>


More information about the Insight-developers mailing list