Hi Joseph,
unfortunately, I cannot avoid storing itk image smart pointers as member in
my ITK filters. That was exactly the point I wanted to make. The pipeline
has to be relaunched several times. At each time only those filters should
be re-executed whose inputs or parameters have been modified.
I could release the pointers if I called SetInput(n, NULL) on the filters.
And before I run the pipeline next time, I could convert the MITK images to
ITK again, and set the inputs back. But this would change the MTime of the
filter. Even if the MITK image has not changed and the filter should not be
re-executed, it will be relaunched.
The current situation is that the pipeline always runs from the very first
filter even if none of the inputs have changed. Exactly because we released
the smart pointers to the input images after every Update() and set them
back before the next one. This undermines the concept of pipelines.
Regards,
Miklos
On 23 July 2014 13:13, Görres, Joseph <[email protected]> wrote:
> Hi Miklos,
>
>
>
> Thank you for your helpful patch, which provides a missing part regarding
> image access. The reason why we haven’t provided this part on our own is
> that there are legacy problems with our image memory management (see Bug
> 16381).
>
> We (the MITK team) have still a difference in opinions, whether it is more
> useful to provide a complete interface and make it work with some tricks
> (e.g. with const_cast as you did) or to wait until the redesign of the
> memory management is completed.
>
>
>
> Regarding your pipeline problem, it might be helpful to avoid storing the
> affected itk image smart pointers as member in your mitk filters. I
> recommend using the AccessByItk macros (see
> http://docs.mitk.org/nightly-qt4/group__Adaptor.html). By applying them,
> you can narrow down the scope of access and thus avoid the risk of
> requesting simultaneous access from different sources.
>
>
>
> Best Regards,
>
> Joseph
>
>
>
>
>
> *Von:* Miklos Espak [mailto:[email protected]]
> *Gesendet:* Dienstag, 22. Juli 2014 14:52
> *An:* mitk-users
> *Betreff:* [mitk-users] ImageToItk write lock vs. pipelines
>
>
>
> Hi there,
>
>
>
>
>
> I have a problem with the locking mechanism of the ITK access macros.
>
>
>
> I have a linear pipeline with several (~10) filters. The only initial
> input of the pipeline is a reference image, but some filters have
> additional input images (masks). These masks can be edited interactively by
> a segmentation tool.
>
>
>
> When the pipeline is created, all the inputs (the reference image and the
> masks) are converted to ITK images by mitk::ImageToITK and set as inputs to
> the filters.
>
>
>
> Then, when the user modifies a mask by the tool, it tries to convert the
> image to ITK with ImageToItk again, so that it can write into the data. At
> which point it fails with this exception:
>
>
>
> Prohibited image access: the requested image part is already in use and
> cannot be requested recursively!
>
>
>
> I understand that this is because the first ImageToItk (when setting the
> inputs of the pipeline filters) creates a ImageWriteAccessor for the MITK
> image and that will not be released until the output (ITK) image exists.
> And my case the pipeline holds a reference to the outputs.
>
>
>
> One solution could be to release the accessors after every run of the
> pipeline by calling SetInput(n, NULL) on the filters. This is what we did
> until now. The problem with this is that it updates the MTime of the
> filter, and even if you set back the same input later (let's say the MITK
> images don't change), the filter will be re-executed at the next update.
> This resulted that the filter always ran from the very beginning,
> regardless which inputs have been modified.
>
>
>
> Another workaround would be to duplicate the images every time when the
> MTime of the MITK image changes, and set the copies as inputs of the
> filters. This would work, but results a lot of memory operation.
>
>
>
> I proposed a change in ImageToItk, so that it creates an ImageReadAccesor
> instead of ImageWriteAccessor if the output type is const. I opened #17931
> for this and sent a patch through github.
>
>
>
> This, however, does not solve the problem, because the tool still cannot
> open the image for writing, because it is locked for reading by the
> pipeline. (Not for writing with that fix.)
>
>
>
> The solution could be to release the lock for the time when the pipeline
> is not running, and regain it back when the pipeline starts.
>
>
>
> Is there a way to implement such a mechanism?
>
>
>
> Any other idea how to tackle with this?
>
>
>
> Thank you so much,
>
> Miklos
>
>
>
>
>
>
>
------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
mitk-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mitk-users
