>
>
> 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.
>
The current accessor concept kind of covers my setup if you guys
conceptually agree with the followings:
1. The write accessor should ignore with read accessors with IgnoreLock
policy
2. ImageToItk should provide API for acquiring read lock instead of write
lock.
3. ImageToItk should provide API for setting the locking policy (IgnoreLock)
4. The AccessByItk functions should provide API for acquiring read lock.
5. The AccessByItk functions should provie API for setting locking policy
I gave a patch for the first three points here:
https://github.com/MITK/MITK/pull/71
And proposed a way to solve 4.
4 and 5 I worked around by cloning the image and set the copy to the
pipeline. This image does not have a fixed type, so I had to use the
AccessByItk function, but the image is not modified later, so it has to be
cloned only once when the pipeline starts. Not ideal, but works.
I do not know what changes are planned in the memory management, so I
cannot tell if my setup would work with the new approach. Is there a draft
document about it?
>
>
> Since you seem to work with ITK filters, would it be possible to directly
> alter the itk image mask by user interaction?
>
This is what's being done, actually. But the segmentation tool is separated
from the pipeline manager, so it cannot access the ITK image through the
pipeline. It has to convert the MITK image to ITK, require a write lock,
and this is causing the conflict.
> 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.
>
I do this for the reference image because I cannot do better (see above),
but since that image has to be copied only once, that's not much overhead.
I mean once per pipeline, because there could be arbitrary number of
pipelines simultaneously, one for each segmentation. I considered doing
this for the masks, but that would make the interactive segmentation
sluggish, I'm afraid. The tool should work real-time.
Thanks for the ideas and sharing your opinion about this.
Cheers,
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
