A bit of an explanation about the last commit:

Sorry, silly mistake. :-(

And another glitch that is even more minor.

So, PR172 should now contain all the proposed changes.

PR160 was based on master, originally.

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 updated PR172 with two commits from PR161.

New task opened under T22113.
I closed PR152, and PR161 for T22113.

Just for the record. I closed PR160 and pushed an almost identical pull request for T22254.

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?

Note that if this gets accepted, it will probably validate T22113, that means after PR160 (or similar) you will need PR161 (or similar) to see correct indices in the image navigator.

You are welcome.

Sorry, this was after global re-init, as you can see it in the sagittal window.
Here is the screenshot after re-init, with texture interpolation off.

Here it is:

Hmmm...
This is probably because I mostly tested the changes on 2015.05.2 and a new orientation type has been introduced since then ('None').

I see. Many users find the direction annotations useful, even if they are always in the same place, e.g. because they also use other viewers that follow different conventions. It must always be evident how the image is oriented.

My implementation uses a class derived from vtkCornerAnnotation that overrides some functions so that it can display annotations on the sides of the window, not on its corners. But I am not sure that this solution fits in the new overlay/annotation service.

I tested this again with the latest master and the indices look correct now. I tried images with flipped, permuted and rotated axes, the indices were the same as on the status bar. (After reinit. After global reinit they were inverted iff the corresponding image axis was flipped. This is correct.)

I made a clean build on linux and mac of the latest master. On linux my test images are displayed correctly, both after re-init and global re-init. I tried images with flipped, permuted and rotated axes, they all looked fine.

I get the same blank windows when opening the nifties with bfcf1f07676058b32bee39f295ea1019013943ec.
I did a superbuild and deleted the plugin cache.

Is it the nifti image or it was converted to nrrd?
If nrrd, would you mind attaching it to this task if it is not too much of a hassle?

We have a utility to generate 3D test images with check pattern with any rotation matrix but it cannot save nrrd because the nrrd writer service is in DiffusionIO and we disabled the diffusion stuff because we do not really need it. I am trying to enable it but it has so many dependencies (even in ITK and VTK) that it is not easy. By the way, would you guys accept a PR for moving the nrrd writer service to MitkIOExt?

The aim is to see the original image indices in the image navigator. If there was global re-init, you are in world coordinate system, so nothing changes. Dragging the sliders from left to right always increases the index, and moves in the same direction in world. (Under 'same' I mean regardless how many and what type of data is loaded.)

Actually, this might fail also because the nifti reader in MITK (ITK) is broken. We are using a patched nifti reader.

Here are some:

Before you make any action on this ticket, (e.g. closing it without action), it would be good to have an overall discussion about the geometry related issues.

Can we have a talk on hangout or skype?

Thanks for the clarification, it's much more clear now. :-)

Yes, I meant that page. In the first section about world coordinates, line 5 and 6.
Did I misunderstand something?

All right.

I implemented it on our fork. I can prepare a pull request based on master if you want to take it.

I have to add little corrections about the assertions. So, all together there five commits to take. In reverse chronological order:

Thinking more about it, I think this is invalid. The scrolling direction was wrong because the renderer geometries had different handedness. The coronal renderer was left-handed, the other two was right-handed. This means that scrolling up in the coronal window brought you to the slice that was *ahead* of the current slice, not behind. Scrolling up in the other two renderers brought you to the slice behind the current one, as expected.

The problem is that the renderer geometries are shifted by half a voxel along the renderer plane normal compared to the 'reference' geometry.

I have a fix for this.

Guys, did you try my fix for T22114?

And at the same time the 'Created' could be removed from the function names as these return the geometries that the slice navigation controller currently has (time and 3D, respectively).

I updated the PR. Just some tidying up.

I updated the PR with adding a nullptr check for now, and with more detailed comment.

It sound like that T11113 definitely validates this issue in the sense that it does not just 'seem to be' wrong but can cause actual problems.

If you want to resolve the original issue (half voxel shift of renderer geometries) properly, I see two ways.

I still think that this issue is valid but it is not very important for me any more. I noticed the half voxel shift of renderer geometries compared to their input geometry, when I tried to initialise a renderer based on a geometry of another renderer.

Are you sure that this is the right patch? I do not see any reference to boost or eigen.

Sorry, my last comment was not on your new patch.

It was not working that time (v2015.05.2) because of the reason I detailed above. I did not try it again with the current master.

Do you want to switch to a microservice-based tool framework and retire the old tools at the same time?

Another thing.

Yes, it is a general design problem. It is an anti-pattern, I would say. A big NO. :)

these might be not the right directions

I do not think that the comment on DeleteEvent is valid.

I just realised that I already created an issue for this early last year:

This proposal is not a feature request but it describes a quite a sever bug with a lot of unforeseeable consequences. I try to explain it better.

T16895 is also the same problem. I described the issue and sent a PR almost three years ago. (It was not even commented on.) This ticket proposes a more general solution, though.

A bit smarter solution would be to use ctkSliderWidget for the index positions. ctkSliderWidget integrates a Qt slider and spin box in a single widget. The signals are connected, so that if you change the slider, the spin box changes accordingly and vice versa.

The code crashes because of T22122.

I agree that rewriting the basic classes in MitkCore would be a long and cumbersome work, but it is not so difficult, and it can be done systematically. In turn, you could get a much more robust and responsive application, and you could save a lot of time that would be spent with debugging later, otherwise.

This is related to T16895.

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

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

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

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

Note that in terms of T8802, these might be not the right directions. However, this should be handled in the interactor, in my opinion.

PR sent:
https://github.com/MITK/MITK/pull/152