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
