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
