Dataset view orientation inconsistent

[dchiquito]

To reproduce:

• Go to the projects list, select a project containing the sample dataset
• Click on Scan
• The viewers will be black, but crosshairs will be present.
• Click up/down to go to a different experiment
• The viewers will be black, and the crosshairs will be misplaced.
• Click down/up to return to the first experiment
• The viewers will load the image correctly, but one crosshair axis will be absent in each axial view.

[annehaley]

I'm glad you found this, because during the implementation of the crosshairs and making the vtk viewer show slices as strictly orthogonal, Forrest and I were only using real brain images and never tested the fake ones.

I found that the problem is actually rooted in the direction matrix for the vtkViewer's representation object. On the brain scans we were using, this matrix always came already as expected, with numbers for which their absolute values round to the following matrix:

| 1 0 0 |
| 0 1 0 |
| 0 0 1 |

But the fake scans came with the following rounded absolute matrix for their directions:

| 0 0 1 |
| 1 0 0 |
| 0 1 0 |

Which meant that the Y axis was treated as the Z, the Z was treated as the X, and the X was treated as the Y. Having such a direction matrix was not a problem before we had crosshairs and an orthogonality transformation. But when Forrest and I added those features, these datasets didn't work because we were still working under the assumption that the direction matrix wouldn't be jumbled. With that assumption, there were several places where we used logic like if (this.name === 'x').

So the solution I'm considering is actually a mapping of these names based on the direction matrix, so we can treat the X column as X again, etc. I added a helper function to the computed name property and everything sorted itself out after that. This does mean, however, that the ordering of the vtkViewer components appears changed: For these scans, for example, the vtkViewer components appear in the following order: Coronal, Axial, Sagittal (instead of the usual Axial, Sagittal, Coronal).

I put in a PR (#236) to address this. I would appreciate extra scrutiny and testing on this change.

[curtislisle]

Radiology view vs. neurology view - We may want to add support in MIQA to handle both the radiology convention for imagery in addition to the neurology convention. This doesn't need UI support, but it might make sense to make a project attribute (Radiology or Neurology choice?) so MIQA displays datasets as clinicians would expect.

[curtislisle]

I have some more info to add about orientations. I just tried some PREDICT data (Hans' data from Univ. of Iowa). These scans are in RSP orientation (Coronal going from Posterior to Anterior (PA) ). They don't display correctly in MIQA. I'll email a sample .nii file that corresponds to the attached analysis images and exhibits the display problem to @annehaley and @dzenanz. Adding notes here so we can consider this case, since it is the data from our UofIowa collaborator.

[curtislisle]

Unfortunately, I just tried the fix-example-data PR branch includes an orientation fix, and there is still at least an initialization issue: At inifialization to a new scan, I see only a sideways brain in the yellow/sagittal panel. If I carefully use the scroll wheel in each axis panel, I can get a 3-axis view (see attached image here), but it is easy to accidentally blank out the axis views. By playing with it, I figured out the problem happens if the offset value shown in any axis goes to a positive value. Notice, in the attached image, all the axis offsets at the top of the slice views are negative (e.g. -4mm,-9mm, -2mm.) If any of these values are allowed to go positive, the corresponding slice view offset immediately pegs to the maximum (e.g. 133mm) and the image goes blank because it is out of range. So it is possible the orientations are OK but the cursor position management is still confused.

[annehaley]

@curtislisle Could you send me this input file so I may reproduce and debug?

[curtislisle]

@annehaley Thanks for asking. Here in the google drive is a small dataset of Hans' files, including the one displayed above. it is called predict-tiny. Reviewing the first two lines of the CSV file, they reference Nifti files converted from the original .mgz (FreeSurfer) format. This dataset can help us read FreeSurfer as well as be an orientation example. I used 3D Slicer to load the original .mgz format image and save it as Nifti without any changes, so these should be the same orientation, but I am mentioning my hand process in case saving from Slicer or the Nifti orientation bug contributed a change to the orientation.

https://drive.google.com/drive/u/0/folders/0ACFZuq__T6qAUk9PVA

[annehaley]

@curtislisle Thanks, I was able to get these examples in my local instance for debugging. It looks like these two first images are coming in as LIA (according to their orientation matrices). Our other LIA test was successful, so I have a feeling it's not the orientation that's the problem.

However, when I try to reproduce the screenshot you provided, I got the expected orientations. Thsi may be due to the fact that I just rebased and squashed this branch, so I may have changes you didn't have. I attached the following video to demonstrate:

https://user-images.githubusercontent.com/44912689/148270622-804cb82e-b6dc-451e-a15a-9f7ec9f9c33b.mov

Firstly, could you try again with the newly rebased and squashed branch to test the image orientations? Secondly, this video reveals a different problem, which might be why you had black screens. It seems the scroll behavior is what's broken on these images. Perhaps the increaseSlice and decreaseSlice functions are making incorrect assumptions. I'll take a look at this too.

[curtislisle]

@annehaley , I'm going to test orientation again now. The scroll behavior in your video is exactly what I experienced as well. Thanks.

[annehaley]

Oddly enough, the strange scroll behavior was resolved by changing the slider's connection to the slice from using v-model to using :value and @change, which is purely Vue-related. This change has now been merged.

[curtislisle]

The merged changes work perfectly on my local instance of MIQA. The predict-tiny scan orientation is correct and crosshairs work fine. Thanks.