[Rtk-users] Input and output image buffer

[ghostcz]

Hi Simon,

Yes, it solved the problem.
There are some more related questions. Filters like backprojectionFilter have more than one input. As it is an InPlaceFilter, it will overwrite the input. But which input will be updated? From the existing filters, it seems it is the input( 0 ). Is this defined somewhere? Can I change this? If I query the buffer of input(1), will I get the correct address?
Another one: if I pass an ITK image pointer to a function instead of defining this image as an input, will I run into the same problem? Does it have an impact on speed and ram consumption?
Thank you!

Best regards,
Louie

From: Simon Rit 
Sent: Wednesday, December 03, 2014 9:31 AM
To: louie L 
Cc: rtk-users at public.kitware.com 
Subject: Re: [Rtk-users] Input and output image buffer

Hi Louie,

What you do is correct and what you obtain is expected. BackProjectionImageFilter inherits from InPlaceImageFilter. InPlaceImageFilter overwrites the input by default. If you don't want this behavior, you can simply call InPlaceOff before updating. Then , the buffers will be indeed pointing to different memory spaces.

Hope this helps,
Simon


On Tue, Dec 2, 2014 at 10:21 PM, louie L <ghostcz at hotmail.com> wrote:

  Dear RTK users and developers,

  I am writing a backprojection filter whose superclass is ImageToImageFilter. After allocating the output, I called
  this->GetInput()->GetBufferPointer() and
  this->GetOutput()->GetBufferPointer().
  to get the address of the images in memory. However the two functions above return the same value. Why? If this is not the correct way to get the address of the input image, how can I get that address?
  Thank you.

  Best regards,
  Louie


  _______________________________________________
  Rtk-users mailing list
  Rtk-users at public.kitware.com
  http://public.kitware.com/mailman/listinfo/rtk-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20141203/ba6fbbe3/attachment-0009.html>