Hi Joseph, I just stick to MITK for display purposes and generally refrain from using MITK images and filters at all. That is why I build the little construct below to just obtain an itk::Image of the mitk::DataNode's data for image processing. The casting block is closed so the mitk::Image* should run out of scope directly after the cast. The members m_baseImage and m_parentNode hold the currently acquired itk::Image and the currently selected mitk::DataNode for convenient access. If I just hold a itk::SmartPointer to the itk::Image, why does the mitk::ImageWriteAccessor still exist so that a second selection will generate a new mitk::ImageWriteAccessor on that image and trigger the assertion. Please tell me if I misunderstood the concept. I will open a bug report on your responds.
Best regards, Matthias -----Original Message----- From: Görres, Joseph [mailto:[email protected]] Sent: Freitag, 18. Oktober 2013 11:19 To: Noll, Matthias; [email protected] Subject: AW: Image accessor lock problem 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
