Pushed new branch T22437-update-build-instructions.

rMPT needs to be updated when the release tag for rMITK is fixed.

Pushed new branch T22427-MITK_USE_Qt5-MITK-MBI.

Pushed new branch T22427-MITK_USE_Qt5.

The original issue was resolved, keep an eye on T22435: QmitkDataManager checks for deprecated QmitkStatisticsAction for the QmitkStatisticsAction fix.

Pushed new branch T22434-fix-linux-installer.

As I wrote, this happened on an old master and was already taken care of with the above mentioned task by Stefan. Still the 'QmitkStatisticsAction' is checked in the 'QmitkDataManagerView'-class, although the 'QmitkStatisticsAction' does not exist anymore?

Could you check whether this still happens? I can not reproduce any behaviour that would fit with what you describe, however I am still somewhat unclear on what you actually did.

@thomass What's the status of this one?

You're right. ITK doesn't seem to expose HDF5 anyway...

Also crashes with normal 4D images. In Multilabel segmentation 2D region crowing, too.

• rename all the files from .cpp and .h to .cpp.tmpl -h.tmpl

In T22243#91714, @goch wrote:

We could protect the code from being formatted by surrounding the lines containing the symbolic names with

//clang-format off
Code here...
//clang-format on

However this would result in those comments being transferred to the configured files, where we would not want formatting to be forbidden. Seeing as this should not be much of an issue as this code will be mostly not touched the solution is probably to be careful in future formatting steps.

In T22426#93042, @kislinsk wrote:

AFAIK they also updated their version of HDF5, which may require us to update our related code, but would allow us to get rid of our dependency to a separate version of HDF5.

AFAIK they also updated their version of HDF5, which may require us to update our related code, but would allow us to get rid of our dependency to a separate version of HDF5.

Should be fixed with T20196. However, QmitkStatisticsAction seems to be superfluous here.

Pushed new branch T22421-ImageCropperCropsWrongTimeStep.

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 wasn't even aware of that functionality. I can confirm the interaction STRG+Leftclick doing nothing for both tools. However, this functionality can more or less be recreated by just clicking on an empty area within the slice.

Ok. If I look long enough, there's indeed a difference.
Also between identical twins, there are noteable differences 😁

I pushed a few fixes here:

They do not. The icons are very similar, but not the same. I do however agree that having another icon would be nice. Not high priority though.

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.

Pushed new branch T22396-ImageCropperRenderUpdateScrolling.

This is expected, as changing the version is the last thing we're doing before we complete the release.

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.

Should be resolved. If any other issues crop up new tasks should be opened.

This concrete problem is solved. Further discussion will take place in T22328

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

Pushed new branch T19933-Outline-of-segmentation-merge-correction.

Pushed new branch T22353-fix-labelsetwidget-context-menu.

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

Pushed new branch T22352-crash-in-view-manager.

I will add a manual exclude for this view id in the widget itself, not an ideal solution but a quick one.

Pushed new branch T18475-remove-workbench-cpackoptions-include.

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: