@Joseph: could you have a look at this and comment? I think this is something that could be handled properly by the use of image accessors, e.g. the destructor of write accessor calls modified or something similar.

Anyone fixing this should also test and remove the workaround from T3499.

Updating target_milestone

What is the status of this bug? Please change the target milestone to "AfterNextRelease" if this bug is not relevant or cannot be fixed in time for the 2013-06 release.

This bug has a high severity and was not fixed within the 2013-06 release. Setting target milestone to next release.

Since an image can have several instances of vtkImageData, it is not possible to address the right vtkImageData on a global Modified()-call for the whole image. Therefore, we implemented the calls into the destructor of ImagePixelWriteAccessor, which has access to a given ImageDataItem and its vtkImageData.

New remote branch pushed: bug-13526-IntegrateModifyIntoImageAccessor

Could you please bring this up in tomorrows MITK meeting? There are some points that need clarification:

• I don't see how the fix is related to the original report of Michael (the fix solves "accessor destructed -> image modified", Michael requested "mitk::Image modified -> vtkImage modified")
• I understand that there are multiple vtkImageData for one mitk::Image but I do not see a reason why not all or selected ones can be marked modified.
• Unless there are performance reasons, placing the code in the destructor has two problems that should at least be discussed:
  • it is also called when there were no actual modifications
  • it comes later than the modifications

1. I asked him in person and his particular case was covered. But you’re right, in general it would be better to implement a mitk::Image::Modified() method. But it's not that easy (see next remark)

2. Unfortunately vtkImageData objects are invoked on-demand. Therefore, we might invoke the creation of many vtkImageData objects, which are actually not needed. If we want to call them all in any case, we better first focus on getting rid of the on-demand relationship between mitk::Image and mitk::ImageDataItem. This on-demand behavior also affects several other currently blocked bugs: 13324, 14443, 11536, 15325. Restructuring this relationship is however too extensive for our weekly BugSquashing – Party.

3. Dealing with these issues means to have additional overhead for every single pixel access and would slow down algorithms that depend on many pixel values (e.g. segmentation filters).

Current release is finished. Reseting target milestone...