@maleike Regarding attachments, simply drag & drop them into the comment text box. 💡

I spent quite some time now on understanding what is happening. Attached to this task are my detailed notes (see two comments further down).
The overall situation is complicated, so I need to meditate on it for some time before any further changes. Discussions are welcome.

Seems to be related to the migration towards ILifeCycleAwarePart views, as the old Activated/Deactivated stuff apparently doesn't match to the new mechanism. For example, the interactions don't work because the selection is explicitly cleared in the Deactivated() method when clicking into the editor. I fixed the QmitkPointSetInteractionView so far. Needs to be tested manually, though, as it's always a strange feeling when simply deleting code and it still seems to work (again).

@maleike Did you try to use QString::toLatin1() instead of QString::toStdString()? AFAIK this is used rather often in MITK.

@maleike I think the current policy could be best described as "free for all"
However I am fully in favor of using a consistent conversion and policy and am open for suggestions. UTF 8 as internal string encoding seems reasonable to me and should harmonize reasonably well with Qt.
The most trouble would probably be the interplay with other, especially file system related, toolkits.
itksys is a problem you already encountered. I believe boost filesystem is currently not used anywhere, Poco might be another issue. I believe tinyxml supports UTF8 as well.

In T22602#96049, @goch wrote:

However as modern systems tend to support unicode filenames as well we might even want to consider changing the behaviour in QmitkIOUtil

I do not see an issue with it. EncodeName is really the wrong function to use at this point, as it was designed for encoding file names into platform/locale specific 8 bit.

Wait a little, there's more to this, I'll probably add to the first commit!

I just fixed the original description, the encodeName() originates from a commit by @zelzer, not @floca (the commit I originally cited just reused the pattern in multiple other lines)

@goch As you put some effort in these things as far as I know, is there something against the PR?

Hi, cool PR! 👍
Only had a very straight forward merge conflict and a forgotten migration from std::vector<mitk::DataNode*> to QList<mitk::DataNode::Pointer>. However, the interactions doesn't work anymore. For example, neither segmentation, clipping plane, nor point set work. I start to investigate what's going on, or what isn't.

Pushed new branch T22572-no-common-legacy.

Well it depends on the details but it is possible that if a public method doesn't make no sense anymore, a strategy could be to mark that method as deprecated in the class declaration and making a no-op out of it in the class definition. The more interesting question is if code from other clients would still work as they expect or if they would need to follow a migration guide.

Haha, ok, you're right, I don't want to do that. I don't know much about the deprecation process, so here's one question. Lets say my code is ok, the bug is fixed, but I deleted one public method somewhere because it made no sense anymore and it's incompatible with what I did. Are you telling me I must keep the old implementation along my new implementation for the next version(s)? The old implementation is buggy; it would make no sense to keep it.

The thing is, if you change public interface, you must go through the deprecation process. And you don't want to do this. 😄 Especially if it is simply a cosmetic change. Thanks for looking into it again.

Yes, I changed the public interface. I understand that you don't want to change it because some people might be using it, but all changes are related to the RenderWindowMenu. I doubt anyone outside of MITK is using this class.

It's hard to understand what you actually did to fix the issue as you touched large portions of the code. It also seems like you changed the public interface? Please describe the bug precisely and why the QSplitter is causing the trouble and what's needed to fix the issue. Also, please simplify your commit to the bare minimum necessary to fix the issue, as otherwise it is too confusing to review, thank you. :-)

Thank you, @goyette. 👍

Pushed new branch T22464-CrosshairRotation.

@maleike I will just go ahead and add that line myself.

@goch: very good point! I missed this while rebasing my branch.. sorry for that. I think your solution would work fine. I can adapt the code and test it Monday (wouldn't mind if you do it if you already have this change locally)

The provided pull request does not solve the problem for me. It only replaces the renderer specific property, but in most cases the property will not be renderer specific. node->GetProperty(name, renderer) will return the unspecific one if no specific is found.

Pushed new branch T19360-legacy-scene-surface-line-width-incompatible.

Thank you! 👍

Pushed new branch T22494-region-growing-fix-mitk.

Yippie yay!

Thank you! I cherry-picked the conversion fix as I completely rewrote the slice navigation controller test. I also updated the test data. All tests are green now. Seems like we made it! *fingers crossed*

I pushed a few fixes here:

Thank you! Yes, I also checked the coronal view direction. Works! The biggest problem was my misunderstanding of the axis vectors of the geometry. I thought that these vectors would point along the OpenGL coordinate system axes, however, they actually map the LPS coordinate frame into the OpenGL coordinate frame, which is why the other components than the main diagonal can be set when putting the vectors into a matrix. That's why the tables in my long comment above had the correct values but in the wrong places. I edited the comment to reflect the status quo.

Ah, ok, so the behaviour is good.

In T22254#92234, @espak wrote:

Have you pushed the fix for the flipped parameter of mitk::Image::Initialize() somewhere? I do not see it on the T22254-GeometryFixesAsProposed branch.

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"

In T22254#91916, @espak wrote:

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.

Referring to your long comment: Yes, this makes sense and it is what I tried to do. I had a wrong assumption, though, regarding the view direction for the L-axis, in which case, for whatever reason, we have look along the negative axis. In the P-case we look from anterior towards posterior and in the S-case we look from inferior towards superior.

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.

This is very odd as it doesn't fit nicely into the LPS scheme, where we're moving along the positive axes in the P and S case. So at the moment we are looking from the patient's left to the right but we're scrolling from the patient's right to the left. Can you confirm?

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.

It is a non-image geometry. Voxel width and height are 1mm each, thickness 2mm. The "Actual" tables show the values of the origin/axis vectors with the current master implementation (including your fixes).

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

The assumptions are valid at the top.

I will rewrite the SliceNavigationControllerTest, as it is highly confusing. For the new test, I will assume the following points:

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.

Pushed new branch T22254-Fixes.

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

Some other tests fail after the geometry changes on our dart clients. So it's not over yet. :)

Thank you, everything was successfully merged into the master branch and the release branch. I guess there are some PRs that need to be closed manually now?

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

Sorry, forgot to add the line numbers:

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

@espak The asserts in the PlaneGeometryTests that fail are always because of the normal pointing in the opposite direction as expected by the test. In one example the frontside parameter when initializing the plane geometry is set to false and then its normal is checked against (-normal). Is it expected that the normals after your changes in these cases are flipped?

Just to let you know, I started working on the two tests above again after the holidays. The SlicedGeometry3DTest is done, the PlaneGeometryTest follows.

Fixed remaining compile errors in tests. We need to adapt the following two tests:

• mitkPlaneGeometryTest
• mitkSlicedGeometry3DTest

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.)

Had to fix a a wrong signature as the top parameter was present twice, but now it looks very promising in the first tests.

Thank you for the explanation, Miklos. I'll give it another try tomorrow, as I'm currently in the middle of another complicated bug. :-/

A bit of an explanation about the last commit:

Sorry, silly mistake. :-(

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):

And another glitch that is even more minor.

So, PR172 should now contain all the proposed changes.

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