Hi Miklos,
Oh I see, sorry for focussing on the ReadAccessor topic. You’re right; your
pipeline setup is not covered by the current Accessor concept and upcoming
changes in memory management won’t change that (except for read access). If you
think this is too restrictive for your applications please file a bug regarding
the interplay of image access and pipelines, so we can consider your opinion in
future development and restructuring.
Since you seem to work with ITK filters, would it be possible to directly alter
the itk image mask by user interaction? Another solution could be to create a
new image from interaction and copy the image data into the itk image mask.
Although this solution gave a copy overhead of one image, the pipeline wouldn’t
be re-executed completely.
Best Regards
Joseph
Von: [email protected] [mailto:[email protected]] Im Auftrag von Miklos Espak
Gesendet: Mittwoch, 23. Juli 2014 15:34
An: Görres, Joseph
Cc: mitk-users
Betreff: Re: [mitk-users] ImageToItk write lock vs. pipelines
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]<mailto:[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]<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
