jdtournier
commented
3 months ago Ultimately these markers don't actually indicate L-R / P-A / I-S. They indicate realspace +-X, +-Y and +-Z, where it is expected that:
- The anatomical axis that most closely aligns with +X will be R.
- The anatomical axis that most closely aligns with +Y will be A.
- The anatomical axis that most closely aligns with +Z will be S.
So I get the gist, but there's also the interaction with the DICOM patient-based coordinate system (PCS) (see e.g. here for a more complete description). As far as I can tell, there are 3 different coordinate systems to worry about:
- the equipment coordinate system - what we'd think of as scanner X/Y/Z.
- the PCS, also referred to as the reference coordinate system (RCS) - these are equivalent, as far as I can tell. Also aligned with scanner X/Y/Z, but potentially swapped / inverted to match the orientation of the patient
- the axes of the image
The PCS is determined purely from how the operator sets up the scan - typically head-first supine (HFS) for us (encoded in DICOM as the Patient Position attribute). In that sense, I think these axes can correctly be labelled as L/R, A/P, and I/S, even if I agree there is no guarantee that these align perfectly with the patient's actual orientation. There's no way to determine that other than by looking at the contents of the image. But I personally think these are the correct labels to use, given the way the DICOM standard defines all of this - though we may need to document this better.
If we use X/Y/Z to label these, there is potential confusion with the actual scanner axes (i.e. the equipment coordinate system). Though to be fair, I doubt most users would know the difference.
Regardless, I like your mockup idea of showing both the PCS and image axes on the display. I would still keep the anatomical labels, especially L/R, since we really need to be completely unambiguous about that. Also, the tilting of the image plane should have no impact of these labels, other than potentially flipping between two axes when an image is tilted at exactly 45°. I can also see confusion when displaying such an image locked to axes, where the ambiguous axes are in plane - for example, the image is rotated 45° in the axial plane, so that the y axis of the image points along (1,1,0), and we display the image as a sagittal projection: it's then completely arbitrary as to whether that's a coronal or a sagittal projection... But I don't think the image markers necessary help in that regard...
What we could also do is always show all markers (whether anatomical labels or coloured lines, or both), but fade them in/out depending on alignment with the plane currently being displayed. For the example above, this would mean we'd show both A/P and L/R at the same time, both semi-transparent, and potentially on top of each other (along with I/S in full opacity). What do you reckon?
Lestropie
Thinking about the little red text characters indicating the three anatomical axes in
mrview. Particularly given recent work on the importance of distinctions between reference axes.Ultimately these markers don't actually indicate L-R / P-A / I-S. They indicate realspace +-X, +-Y and +-Z, where it is expected that:
There is however no guarantee that eg. the anatomical axis L>>R will be less than 45 degrees away from +X. It entirely depends on the subject's individual positioning within the scanner (assuming no transformation to some template has occurred). This imprecision conflicts with the fact that those anatomical labels are placed on the viewing window with pixel precision.
So I think that showing those characters is technically incorrect.
This is somewhat related to #452, where my previous thinking involved some sort of overlay box with lines showing the directions of realspace and image axes based on the current camera position. Re-thinking that issue in this context, I think there might be a hybrid solution that addresses both issues.
Replace the (potentially misleading) axis character labels with coloured lines at the viewing window extremities, coloured by axis (instead of using text characters), using some visual indication of sign. The very same mechanism can then be used to indicate the image axes (as distinct from realspace axes) if one so chooses. Unlike my previous idea of showing a little set of axis lines as some sort of overlay, this would take up no more useful screen space than the current axis labels.
Here's a mock-up, using a very tilted acquisition to accentuate the difference between XYZ (as RGB) and image axes ijk (using CMY), here using colour intensity & line thickness to indicate sign: