ortho2 labels/orientation

[martin3141]

Hi,

I notice that when converting MRI dicom data to nifti via dcm2niix the data is incorrectly orientated in the LR direction when displayed with ortho2. fsleyes shows the data correctly. When loading the data with oro.nifti::readNIfTI I get an error about being unable to reorient - so I'm assuming oro.nifti is expecting the data to be in a particular orientation (LAS?) and this is the root cause of the problem. I also see this LR flip in your package vignette:

https://cran.r-project.org/web/packages/neurobase/vignettes/neurobase.html

It seems that the convention for nifti data is RAS orientation:

https://github.com/rordenlab/dcm2niix/issues/159

Given that neurobase is neuroimaging focussed - I suggest that reader functions should check for RAS orientation (and give a warning otherwise) and that ortho2 should expect RAS orientation and display labels correctly in this case. What do you think?

Martin

[jonclayden]

I’m not the best person to comment on the conventions of oro.nifti or neurobase, but there are some general NIfTI and radiology principles that are relevant here.

First and foremost, “correctness” is ill-defined, but to my mind the only thing that’s crucial is that the axes are labelled correctly by the viewer. Everything else with respect to orientation is up in the air.

In principle, for me at least, there is a distinction between the way an image is stored and the way it is displayed. It’s true that RAS is the default for NIfTI, but LAS, LPI, etc. are all allowed and perfectly valid as on-disk storage conventions. The question is what the viewer should do with files stored in different orientations. One possibility is to use the storage convention of the source file – which I think is FSL’s convention when one image is loaded. (After that it would be strange to load a second, overlay image in a different orientation.) Another is to use a fixed view, irrespective of the storage convention. This is easily achieved by reordering the data values in memory after reading the file, and is the convention adopted by TractoR. This has the advantage of not surprising the user each time they open a new file, but the disadvantage of not representing the file “faithfully”. My view is that the former outweighs the latter, because storage convention is unlikely to be of interest to most users, and at any rate can be determined by other means (the qform and sform).

The question is then what the fixed convention should be. RAS (the “neurological” convention) is NIfTI’s default; LAS (the “radiological” convention) was Analyze’s. Ultimately, the choice is arbitrary. LAS is familiar to radiologists but counterintuitive to people with different training. But, once again, the vital point is that left and right must be labelled correctly (and users should check the labels), otherwise bad things can happen.

So, if you’re saying that L and R are genuinely flipped, then that’s a serious problem. If they’re just not displayed the way around you expect, then that probably isn’t.

Sorry for the essay!

[muschellij2]

I wholeheartedly agree with @jonclayden. Also, ortho2 is based on @bjw34032 original code for orthographic. Reorientation only works if the rotation matrix is a transform of the identity. I tend to use fslr::readrpi to do the reorientation for me, but I think overall I lean on not changing any of underlying code as many depend on it.

[martin3141]

I also agree with these points, and perhaps I overestimated the degree of agreement on neuroimaging display conventions.

However, I still think there is an issue with ortho2 applying labels that are only correct for LAS/RPI data without warning or error. orthographic makes no claim about anatomy - so I don't see any need to change the underlying function. Perhaps a warning when ortho2 is used with non LAS/RPI data and add.orient == TRUE, or at the very least something in the function documentation to make it clear the requirements for the labels to be correct.

[jonclayden]

Yes, I would say there should be no circumstances where ortho2 mislabels the image, as in the screenshot below from the vignette.

If the code knows the labels are wrong, it should suppress them. If not, it may be necessary to introduce some logic to detect this situation and suppress accordingly, or detect the true orientation of the image and correct the labels, or never use labels.

[muschellij2]

I would defer to @bjw34032 about the labeling, but maybe just add the default add.orient = FALSE in ortho2.

[bjw34032]

Hello. I thought the orthographic function did make an attempt at re-orienting incoming volumes to overcome any left-right issues. In the stored vignette (from 05 Oct 2017) on github this appears to be the case (Figure 1 and subsequent figures). Looking on CRAN I cannot find the vignette for the most recent version of the package (don't know why).

[muschellij2]

I believe readNIfTI does, but I have all but abandoned the reorientation for that function.

On Wed, Oct 16, 2019 at 9:26 AM Brandon Whitcher notifications@github.com wrote:

Hello. I thought the orthographic function did make an attempt at re-orienting incoming volumes to overcome any left-right issues. In the stored vignette (from 05 Oct 2017) on github this appears to be the case (Figure 1 and subsequent figures). Looking on CRAN I cannot find the vignette for the most recent version of the package (don't know why).

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/muschellij2/neurobase/issues/2?email_source=notifications&email_token=AAIGPLVT46TD63BCWEKLFXDQO4I7RA5CNFSM4I7XHBR2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBMO74Q#issuecomment-542699506, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIGPLQL37LZW2KAYVSHLNTQO4I7RANCNFSM4I7XHBRQ .

-- Best, John