I will revisit this issue once T19933 has been merged to check what open issues remain and open a corresponding task.

Pushed new branch T22254-GeometryFixesAsProposed.

The changes unfortunately seem to break like "everything". The Coronal plane is completly off and touches the actual image volume in only one slice. The other windows are mirrored and/or upside down. This is our Pic3D.nrrd (same problem with every other image I tried, though):

In T22076#86648, @metzger wrote:

After adding/deleting a label there is no update of the label widget.
Also there is a problem if you delete the first layer. The segmented areas still remain on the image.

And another glitch that is even more minor.

So, PR172 should now contain all the proposed changes.

Doesn'r crash anymore.

I don't get it. What is the final solution? I added some VTK output to the image details in the DataManager and the VTK origin is always {0, 0, 0}. brain.nrrd is a good image for testing the origin BTW.

Can't reproduce it now on an approximately two week old master. Works like it should! 👍

http://git.mitk.org/MITK.git isn't valid anymore, we moved to https://phabricator.mitk.org/source/mitk.git in August.

Cannot reproduce as the other Release mode crashes. Does it crash like always on your PC, @hentsch?

Maybe this is related to the crashes in T22186: Watershed segmentation leads to crash and T22185: RegionGrowing new segmentation crash in Release mode as all these tools are probably using the same component to create a new segmentation.

Maybe this is related to the crashes in T22184: FastMarching create New segmentation crash in Release mode and T22185: RegionGrowing new segmentation crash in Release mode as all these tools are probably using the same component to create a new segmentation.

Data storage wasn't set for the context menu action.

Pushed new branch T20196-CrashOnCreateSegmentationContextMenuAction.

Pushed new branch T22202-PaintbrushToolStabilization.

Solved with T22136.

Pushed new branch T22136-WaitFor3DInterpolation.

PR160 was based on master, originally.

Is this resolved @goch @metzger?

Pushed new branch T22185-IHaveNoIdeaWhatIAmDoing.

Nope, didn't happen again. Nevertheless, I'll change a raw pointer to a smart pointer in the proximity of the code that probably crashes. Who knows. Can't hurt.

I tried to reproduce this over and over again, but it happened only once in like 50 tries and then never again... I'll try another 10 times and if it doesn't crash again, I'll lower the importance of this task and move it back to the Backlog on the Workboard.

Hm, I think the easiest way of getting the previous fixes is by either cherry-pick the fixes into your PR branch, or by rebase it on the master. As the Geometry fixes won't end up in 1000 commits, it shouldn't be too hard to cherry-pick them back to the release branch.

I tried the first commit of PR172 that is supposed to resolve this, but on top of rMITKc5b9d75 it makes the render windows blank.

I could not reproduce a crash with brain.nrrd and 0.04/0.17 input values.

Thank you, please let us know, when the PR is final and ready for testing. I doubt that we'll change our mind on the inverted sliders, though. ;-)

I updated PR172 with two commits from PR161.

Great, thank you! As long as it is based on rMITKc5b9d75, it is prepared for being included in releases/2016-11-beta, as at this point the branch was branched off. Does PR172 contain everything that's needed for all the Reinit issues?

I am not sure what is the 'None' plane orientation supposed to mean. I added 'None' as the same as the 'Axial' case, as I saw at another place in the same file, here:

I guess, it should be "releases/2016-11-beta" but that is not pushed to github, so I create the PR against master.

What should be the target branch of the updated PR?

@mpkh Does rMITK5ef3e4efc5cd work for you?

Pushed new branch T22280-OpenCV-2.4.13.1.

Pushed new branch T22278-CMake-3.5.