Putting the origin in the front flips the image upside down in the axial window. The other coordinate could be put to the bottom, though, so that the axial slices are counted from bottom to top, at least. This would not change the visualisation. (Bottom-Left-Front)

What do you think?

Pull request:

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

Thanks for discussing this.

I will probably provide a new pull request for the image navigator that checks the up-directions to decide whether to invert the control directions or not. Currently it is hard-coded, for the sagittal and coronal sliders the direction is straight, for axial it is reverted. This matches the way, how you create geometries. However, with this check, we could create the axial geometry from bottom to top, and everybody would be happy and stick with the convention they prefer.

Thinking more about the perfectly correct solution would be to use the same direction for each orientation, as in the reference geometry.

mitk::DataStorage::ComputeBoundingGeometry3D composes a geometry where the directions are bottom-to-top, left-to-right and back-to-front, the individual slice navigation controllers should keep the same directions. (Axial is flipped now.)

This would allow initialising the rendering manager with a custom geometry where the directions are different.

E.g. you could use an image geometry, and the slice indexes would preserve the original image indexes. (The order of indexes would be fix, though.)

My previous reasoning fails on the fact that the coronal (aka. frontal) renderer has a left-handed coordinate system at the moment, while the sagittal and axial ones are right-handed.

Note also, that it is not possible to create left-handed plane geometries at the moment because even if you set the 'flipped' property or provide negative thickness when you initialise a plane geometry, the normal will be overwritten by the cross product of the right and down vectors at some point, that makes the geometry always right-handed. I saw that there were changes related to this on the master (we still use 2015.05.2). I tried the changes but the normal is still overwritten, just now not in PlaneGeometry::EnsurePerpendicularNormal() but at another point in InitializeStandardPlane().

So, the plane geometries of the coronal renderer geometry are right handed but the sliced geometry of the coronal renderer is left handed that causes that the normals of the plane geometries and the 'stacked' sliced geometry are each others' inverse.

Something like this:

  slice 0 ^
--------------------------- renderer geometry bounding box 'back side'
| slice 1 ^
---------------------------
| slice 2 ^
---------------------------
...
...
...
---------------------------
| slice ny - 1 ^
--------------------------- renderer geometry bounding box 'front side'

I reopen this ticket because the current behaviour is inconsistent. If you want right-handed coordinate systems everywhere then the coronal renderer geometry should be flipped as well.

I have a fix for this.

The first commit allows creating left-handed and right-handed plane geometries., so that you do not need to used 'flipped == true' when you stack up the planes to build a sliced geometry. The planes can have a normal that points along the axis vector of the sliced geometry. Previously, planes could only have right-handed geometry because the normal was overwritten by the cross product of the right and bottom vectors, occasionally.

The second commit removes the option to create 'flipped' sliced geometries. They are invalid. It also adds a check for the handedness.

The last commit corrects the default way of initialising the axial, sagittal and coronal renderers, so that the resulted geometry is always right-handed.

The branch is here:

https://github.com/NifTK/MITK/commits/sliced-geometry-handedness

It's the last three commit after the "readme file updated".

I did not rebase it on the MITK master because it does not have the fix for T22112 and T22113 yet.

The commits should be cherry-picked on the top of this PR:
https://github.com/MITK/MITK/pull/160

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

4053fe0 Allow rounding error in assert statement
b21d95f Move variable to ifdef NDEBUG section
9c6f778 Correct handedness of coronal renderer geometries
0508875 Compose sliced geometries of planes with correct normal
7651232 Preserve handedness of plane geometries

They are on the 'niftk-2015.05.2' branch:

https://github.com/NifTK/MITK/commits/niftk-2015.05.2

If you take PR 160, I can put them on a branch based on the current master.

According to the documentation, the world geometry origin should be in the bottom-left-back corner.

No, documentation does not say this?!

Are you refering to Geometry Overview ?

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

Yes, misunderstood.
MITK uses LPS in world coordinates, therefore (0,0,0) is located in Right-Front-Bottom corner ( assuming 1. octant, that means all 3 positive half-axes ), of course the patient's right is on the left on the screen, as usual in medical imaging.

The "bottom-left-back"-corner or center of the non-image or image DATA is pointed at by a Point3D called origin.
Usually, as far as I know.
Can be changed by the Index2World-matrix, which should be specified by the data input file.

https://phabricator.mitk.org/file/data/kdjzwxzsn56duqb64xg3/PHID-FILE-zept6drjkpwlbu3id653/LPS_12x12x12_100010001.nrrd

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

Maybe my reasoning was not fully correct, but I think, the fixes are valid. The LPS coordinate system is right-handed, and so the renderers should have a right-handed geometry as well, so that you can go from one coordinate system to the other by rotation.

thank you very much for your input.
as you have experienced, documentation can be incomplete or unclear.

which renderers and rotation methods are you refering to?
please specify using c++ notation or link to docs.mitk.org

returntype namespace::class::functionname(parametertype)

Can we have a talk on hangout or skype?

I am not referring to any functions. It is a general mathematical principle that it is not possible to convert a left-handed coordinate system to a right-handed one by only translation and rotation. (Or the other way around.)

Missunderstood your comment then. Please think about radiologist's versus neurologist's view: rendered slices are twosided and twodimensional, so inverting an axis in a slice means changing the point of view, not changing handedness. Yes, thats an excellent source of confusion.

Concerning your request for a talk, I must respectfully decline - lets stick to written communication here on phabricator.

Don't mind me, just a stupid part-time student assistant...

Please explain and clarify the current state of this T20180.

I agree there are bugs in the way "Global reinit" and local "reinit" in MitkWorkbench currently behave and am working on test images.