Hi Matthias,

You're right, casting to an itk::Image causes an access by the 
ImageWriteAccessor. The access is finished as soon as the itk::Smartpointer to 
the itk::Image is removed.

The use of filters should not be affected by this concept. You have to make 
sure that there is no on-going write access before starting a mitk-filter 
pipeline or casting to an itk::Image.
For example, if you have an itk::Smartpointer to the same Image within the same 
scope and do not delete it or if you keep the smart-pointer as a class member 
(m_baseImage?), a mitk-filter won't be able to run. I would recommend not to 
intermix mitk- and itk-image representations when accessing. Instead, access 
sequentially in separate scopes. Then, there shouldn't be a problem. Otherwise, 
please file a bug.

Best Regards,
Joseph

________________________________
Von: Noll, Matthias [[email protected]]
Gesendet: Donnerstag, 17. Oktober 2013 16:32
An: [email protected]
Betreff: [mitk-users] Image accessor lock problem

Dear list,

I recently encountered a new problem with MITK when using images that are 
stored in the DataStorage. Acquiring images using the image cast in 
OnSelectionChanged() method of each plugin the following way


FloatingImageType3D::Pointer itkImage;
mitk::BaseData* data = node->GetData();
if(data)
{
  mitk::Image* image = dynamic_cast<mitk::Image*>( data );
  if(image)
    mitk::CastToItkImage(image, itkImage);
}


if(itkImage.IsNotNull())

{

 m_baseImage = itkImage;

 m_parentNode = node;

}



I receive an error message selecting an image twice. The error message reads as 
follows:



117.13 blueberry.ui.wrkbncPlg: LOG: 
..\..\..\..\..\MITK_SOURCE\MITK-2013.06.0\Core\Code\DataManagement\mitkImageAccessorBase.cpp:174:

Prohibited image access: the requested image part is already in use and cannot 
be requested recursively!



In each image cast one of the new write image accessor is created on the source 
object. Why I don’t know! Utilizing the image in a member context seems to 
sustain that accessor until the object is deleted, which it usually wont for 
quite some time. Because if an image is loaded one might apply many different 
algorithms to it. The same behavior is true for const Images as well.



Anyway, how do I use images stored in the DataStorage in a multiple filter 
context, so that I don’t encounter the accessor problem. Utilizing the newly 
introduced clone function would certainly be an option, but it will double the 
memory usage. Additionally, one would need to keep track of all clones images, 
which makes the whole image processing a bit uncomfortable.

It also will make it impossible that different algorithm parts work on the same 
image.



Any comments? Or am I missing something



Best regards,

Matthias

------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
_______________________________________________
mitk-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mitk-users

Reply via email to