Stefan and I had a look on the bug today. Sort summary:

• The reason of the crash is that in case of 4D images the cropped image volume is set in a wrong way in the mitkAutoCropImageFilter. We fixed that.

• Now there is still a problem for 4D images...cropping is not working correctly. This problem is located in the QmitkAutoCropAction where the cropped image is padded to ensure that surfaces create out of the cropped image are closed. Here the time steps are not taken into account. We are working in that.

Now padding is possible with 4D images. But there is still a problem: The image data is set in a wrong way however the resulting cropped image is weird.

And apparently the code for cropping and padding exists twice:

• In QmitkAutoCropAction
• And in QmitkSegmentationPostprocessingView

there is definitely need for cleaning up the whole stuff!

I just stumbled over the mitkPadImageFilter which does exactly the same like the padding in the QmitkAutoCropAction and the QmitkSegmentationPostprocessingView

In QmitkAutocropAction.cpp - QmitkAutocropAction::Run():

GetData() is called on the output of IncreaseCroppedImageSize(). GetData() is supposed to return the actual image content (we guess) but it returns a pointer to some uninitialized or null data.

When we write some test data into that memory and call image->SetVolume(), we can see our test data.

Conclusion: mitk::Image::GetData() does not work for 4D-images - at leat for the 4D-images generated by IncreaseCroppedImageSize().

[c9d849]: Merge branch 'bug-11213-autocrop-crash'

Merged commits:

2012-05-09 15:05:58 Stefan Kislinskiy [2fb78d]
Disabled 4D auto crop.

There are some strange effects in mitk::Image::GetData() and mitk::Image::SetVolume(). These two methods seem to be broken for 3D slices of an 4D image.

2012-05-02 16:27:49 Stefan Kislinskiy [dd247f]
We isolated the bug for further bug squashing.

2012-04-02 08:41:30 Andreas Fetzer [ebaaa9]
WIP Fixed initialization of cropped image volume

Made some adaptions for 4D images