- User Since
- Aug 1 2016, 12:10 PM (286 w, 4 d)
Apr 4 2019
Another place where inverse matrix calculation has been introduced:
As I see, the inverse matrix calculation came in with this commit of mine:
Apr 3 2019
The meaning of the dominant axes is also documented here:
Aug 6 2018
Mar 6 2018
Oct 2 2017
Jul 14 2017
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.
Jul 1 2017
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.
Jun 28 2017
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.
Jun 26 2017
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.
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.
Jun 23 2017
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.
Jun 22 2017
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.
Jun 16 2017
Jun 13 2017
Jun 6 2017
It works perfectly, thank you!
May 23 2017
I do not have a fix for this, so no pull request this time. Any fix is welcome. :-)
May 12 2017
Maybe the rotation matrix is not set for the clipping plane? Just guessing...
What do you think is wrong? It looks correct to me.
Apr 28 2017
Apr 27 2017
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.)
Apr 26 2017
The fix is probably easy. There are several ways.
Mar 9 2017
It is a trivial, one line fix, and does not change anything for the MITK Display.
Mar 8 2017
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.
Mar 3 2017
Feb 24 2017
The code compiles, at least everything that I could switch on. :)
Jan 23 2017
Resolved in T22254.
Jan 20 2017
I pushed a few fixes here:
Ah, ok, so the behaviour is good.
Jan 19 2017
Jan 17 2017
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.
Jan 12 2017
Are these isotropic voxels? I mean the slice thickness is 2mm in all the directions?
The assumptions are valid at the top.
Jan 11 2017
These tests fail, as I see:
Closing this. As @goch noted on the list, this feature is already there. I was using 2015.05.2.
Jan 10 2017
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.
Line 468 and 496 here?
Jan 4 2017
Dec 21 2016
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.)