This image is actually working for me. What exactly did you do and what is your build configuration (ITK, Qt versions) and was it perhaps due to a lack of free memory? Two things are obvious already:

• if there is not enough memory, there should be an error message, no crash
• loading this image seems to trigger a lot of preprocessing, using far too much memory. I'll check what is happening there..

The application is still crashing when a new Segmentation will created for image Aufnahme.pic.gz.

I have following Build Configuration:
QT-4.5.1_VC9.0_Bin
VTK-5.4.2-QT-4.5.1_VC9.0_Bin
ITK-3.16.0_VC9.0_Bin

I reproduced the test also at PCs of Jan, Markus E. and Casper and it took a very long time to generate a EMPTY segmentation file. However, it did not crashed for them.

Ok, the reason for this is some preprocessing that is done for volume rendering. I'll open a new bug to discuss this (my opinion is that this preprocessing should only be done when visualization is actually requested).

I rename this bug to reflect it's new issues. The only thing left to do for the segmentation view is to catch exceptions that occur when the system is out of memory.

An easy avoidance strategy: turning off volume rendering in the view's preferences

Hmmm.. I turned off 3D volume rendering in Preferences->Segmentation, but the Application is still crashing.

Error in vtkMitkVolumeTextureMapper3D, line 1187: std::bad_alloc at memory location xxxx

CallStack:
mitkCoreExt.dll!operator new[](unsigned int count=355467264) Line 7
mitkCoreExt.dll!vtkMitkVolumeTextureMapper3D::UpdateVolumes(vtkVolume * formal=0x13b399c8) Line 1187
mitkCoreExt.dll!vtkMitkOpenGLVolumeTextureMapper3D::SetupOneIndependentTextures(vtkRenderer * formal=0x0c3c39a8, vtkVolume * vol=0x13b399c8) Line 784
mitkCoreExt.dll!vtkMitkOpenGLVolumeTextureMapper3D::RenderOneIndependentShadeFP(vtkRenderer * ren=0x0c3c39a8, vtkVolume * vol=0x13b399c8) Line 1539
mitkCoreExt.dll!vtkMitkOpenGLVolumeTextureMapper3D::RenderFP(vtkRenderer * ren=0x0c3c39a8, vtkVolume * vol=0x13b399c8) Line 430
mitkCoreExt.dll!vtkMitkOpenGLVolumeTextureMapper3D::Render(vtkRenderer * ren=0x0c3c39a8, vtkVolume * vol=0x13b399c8) Line 379
vtkRendering.dll!vtkVolume::RenderVolumetricGeometry(vtkViewport * vp=0x0c3c39a8) Line 385
mitkCore.dll!mitk::BaseVtkMapper3D::MitkRenderVolumetricGeometry(mitk::BaseRenderer * renderer=0x0c3b8f18) Line 119
mitkCoreExt.dll!mitk::GPUVolumeMapper3D::MitkRenderVolumetricGeometry(mitk::BaseRenderer * renderer=0x0c3b8f18) Line 77
mitkCore.dll!mitk::VtkPropRenderer::Render(mitk::VtkPropRenderer::RenderType type=Volumetric) Line 220
mitkCore.dll!vtkMitkRenderProp::RenderVolumetricGeometry(vtkViewport * __formal=0x0c3c39a8) Line 109
vtkRendering.dll!vtkRenderer::UpdateGeometry() Line 645
vtkRendering.dll!vtkOpenGLRenderer::DeviceRender() Line 242
vtkRendering.dll!vtkRenderer::Render() Line 336
vtkRendering.dll!vtkRendererCollection::Render() Line 52
vtkRendering.dll!vtkRenderWindow::DoStereoRender() Line 711
vtkRendering.dll!vtkRenderWindow::DoFDRender() Line 677
vtkRendering.dll!vtkRenderWindow::DoAARender() Line 564
vtkRendering.dll!vtkRenderWindow::Render() Line 377
mitkCore.dll!mitk::RenderingManager::ForceImmediateUpdate(vtkRenderWindow * renderWindow=0x0c3bd3d8) Line 241
mitkCore.dll!mitk::RenderingManager::UpdateCallback() Line 666
Qmitk.dll!QmitkRenderingManager::event(QEvent * event=0x138ee3e0) Line 73

[SVN revision 19968]
FIX (#2845): respect the volume rendering preferences set by user and warn her about potential side effects.

at comment #5: Of course, because nothing has changed yet(In reply to comment #5)

Hmmm.. I turned off 3D volume rendering in Preferences->Segmentation, but the
Application is still crashing.

Yes, nothing has changed yet. I just committed a fix that makes the view at least use the preference settings chosen by the user. However, there is no out-of-memory handling yet. I'll implement it and when the commit is made, a comment will appear here.

[SVN revision 20005]
FIX (#2845): added out-of-memory handling to segmentation view in order to catch exceptions from creating an empty segmentation. Some problems also seem to be solved by reimplementation of QApplication::notify() (see T2873)

Diana, could you please verify Alex' fix using the data from the original bug description? Is the application still crashing?

ok... Now the application did not crashed anymore.

But it have still the unusual behaviour:
start Application ........: 104MB
load Aufnahme.pic.gz .....: 340MB
create new Segmentation ..: 811MB

theoretical the new segmentation should only be of half size of the original ct image (c.a. 120mb) but it takes 471mb..

Diana, this sounds extremely similar to T2894 now. Could you perhaps check once again the behavior with/without volume rendering? Please see http://bugs.mitk.org/show_bug.cgi?id=2894 for a description of what sounds similar to me.

Hi Daniel,

yes, that really sounds similar to T2894. When I disabled 3D Rendering I got following (correct) memory results:

start Application ........: 117MB
load Aufnahme.pic.gz .....: 353MB
create new Segmentation ..: 470MB

So I will close this bug.

fine, thanks!

Merging "applicazion modules" component with "ExtApp plugins"