Another place where inverse matrix calculation has been introduced:

As I see, the inverse matrix calculation came in with this commit of mine:

The meaning of the dominant axes is also documented here:

I wanted to open new tasks for the individual plugins that need a similar fix as the segmentation plugin, so that we can track the progress.

The only way I see to figure out the difference between the two ways of setting the "selected" property is to put a breakpoint at SetBoolProperty("selected") and to through all the listeners, step by step, systematically. Hopefully there are not so many.

I would try this->GetSelectionProvider()->SetSelection(...) and right after this->GetSelectionProvider()->GetSelection() and check if the two are the same.

So, the render window manager plugin uses its own selection provider, right? If you set its selection and and right after you get the selection from it, do you get the back the same?

Do you have the Properties view open? I know that it is listening to the property list changes because the ReplaceProperty calls caused crash. I reported this not long ago and Stefan fixed it. It would be surprising, but maybe...

I thought about that blocking the signals might cause such errors, but it did not occur here, so I thought it is fine. It may depend on the platform as well, and the qt version. I use Qt4 on Mac.

I can also imagine that we see different behaviour because I am testing with 2015.05.2, and just rebased my patch on the master.

Actually, there was no PR, so I opened one:

What I told above about the data roles was wrong. That part works correctly. I made a mistake. After I set the selection of the selection model, like in QmitkAbstractView::FireSelectedNodes(), I also set the selection through the selection provider that overwrote what I've just set.

It seems that they fixed this other error already. This works for me:

I tried, but I get a different error:

//Flags used to enable C++11 support.
DCMTK_CXX11_FLAGS:STRING=-std=c++11

You remember well, but I do not know if this can be matched this to the official numbering.

It reports this:

As I see, PropertyList::SetProperty() does an equality check, and returns early if the parameter is equal to the current value. No modified event is sent, either.

I sent a new PR and closed the previous one.

I have to allow an epsilon difference for rounding error, but it is not enough, it still crashes when the volume is rotated around two world axes by 45 degrees. I get a matrix that I thought is invalid but it is not.

Our tests failed. :-(

node->SetBoolProperty("selected", true/false); and node->SetSelected(true/false); are almost exactly the same.

All the geometry tests of MITK pass on Linux, although probably there is not a test for this special case.

I am testing a PR with the latest master and ran into this again.

https://github.com/MITK/MITK/pull/201

It works perfectly, thank you!

I do not have a fix for this, so no pull request this time. Any fix is welcome. :-)

Maybe the rotation matrix is not set for the clipping plane? Just guessing...

What do you think is wrong? It looks correct to me.

I updated the PR because the limit was applied only in one of the undo models. (The verbose undo model overrode the function in which the superclass applied the limit.)

PR sent:

The fix is probably easy. There are several ways.

It is a trivial, one line fix, and does not change anything for the MITK Display.

That sounds cool! Is there a prototype already to try out?

Rebased on master and conflicts resolved:

We follow a different way in our plugins. They show which images you are working on, but by labels, not combo boxes. We have not seen problem with this approach, but this does not mean that you need to change the MITK Segmentation plugin if you are happy with it.

The code compiles, at least everything that I could switch on. :)

PR 175:
https://github.com/MITK/MITK/pull/175

Resolved in T22254.

Yippie yay!

I pushed a few fixes here:

Ah, ok, so the behaviour is good.

In T22254#91677, @kislinsk wrote:

For the image test, the missing image geometry flag wasn't the actual problem. The problem is that mitk::Image::Initialize() has a parameter called flipped. As you changed a similar signature in the InitializeByStandardPlane() methods of a geometry, this bool flag was now passed as number of slices (false -> 0). I fixed it by making the Initialize() method deprecated and adding a new signature without the flag.

I have trouble with the mitkSliceNavigationControllerTest, though. The frontal case fails and I didn't get it. It doesn't seem to be a changed sign problem alone. Would be really cool, if you could have a look at the test. It can be executed by the CoreTestDriver.

The PointSetInteraction test seems to be tricky as well as a few points out of many have a difference of 1 in the second coordinate (128.x vs 127.x).

For my best understanding, scrolling up should move right in sagittal, posterior in coronal and superior in axial. And as I remember, only the coronal did not match, because the coronal renderer had left-handed coordinate system. So, the scrolling direction changed there as a consequence of the changes. I might remember wrong.

"scrolling up brings us to the heart"

No, scrolling up should go to the slice behind in any render window. In sagittal, scrolling up should go towards the patient's right. It was like this when I was testing. If it is not like that, something is wrong.

The actual values all look correct to me.

In sagittal we see the left side of the face of the patient, i.e. we are looking towards the patient's right, what is on their other side. We can't see their right.

Are these isotropic voxels? I mean the slice thickness is 2mm in all the directions?

The assumptions are valid at the top.

These tests fail, as I see:
http://cdash.mitk.org/viewTest.php?onlyfailed&buildid=643361

Closing this. As @goch noted on the list, this feature is already there. I was using 2015.05.2.

My guess is that the minus sign has to be removed from line 750 and 773.

The direction can be either way, as you can create left or right handed systems as well. If right handed, the direction is the same as the cross product of the righ and bottomvectors. If left-handed then the normal points in the opposite direction. You can create left-handed plande geometries by specifying negative thickness.

Which asserts?
Line 468 and 496 here?
https://phabricator.mitk.org/source/mitk/browse/T22254-GeometryFixesAsProposed/Modules/Core/test/mitkPlaneGeometryTest.cpp;4261ef7a44c7e44b4a7b38a9781533235a366293

That's totally possible. The PlaneGeometry API was already a bit messy, and my commit made it worse by adding 'top' at the end. (Some functions had 'top' somewhere at the beginning already, not directly before the 'frontside' and 'rotated' args as usual.)