I was wondering whether there is a nice way to add the orientation labels into the 2D slice view. In the 3D view, we see these labels (A, P, S, I, R, L) but in the 2D views, we can only use the little marker as orientation.
A naive way to show the orientation labels, that I thought of, would be some fiducials that would be recalculated every time the slice view changes. But that seems a bit complicated computationally.
I looked for “orientation” in the source code, but I did not find any useful code where to start from.
Does anyone have an idea on how to do it or a tip on where to look? Is there a nice way to draw on the slice views? (Something like, I draw in the lower right corner the orientation marker) I guess, that with python scripting one can draw only in “3D” coordinates (meaning, I set the fiducial’s position in the 3D space), so one has to do it in c++ source code?
Inspiration. The 2D view would then look like this. It would have the labels on the corresponding sides:
We don’t have letters on the side of the images right now, but you can enable an orientation marker like axes or a human figure or a cube using the options illustrated below. If that doesn’t suit your needs it would be possible to generalize by looking at how these markers are implemented and add a feature to put the letters on the side.
Thanks @pieper, I know about the orientation marker. I looked at the source code, but wondering if for my purposes is not better to use the source code for the “3D view cube” (the pink cube in the image I posted). However, I cannot find where it is defined. Could you help me to find the right word to search the source code?
The purple cube is designed for 3D views. It is much easier to display direction codes in 2D views. The only complication is that there are lots more corner and side annotations that we want to show in slice views, so we need to make sure that all the information fits. We have an issue that tracks this task, it would be great if you could work on it:
Note that direction codes are not always just simple axis directions (L, R, A, P, I, S) but in case of oblique slices they can be a combination of 2 or 3 directions (LP, AR, LPI, SLP, …). You can see these direction codes next to the slice selector slider after you rotated slice views.
Is there a reason why not just “rotate” the L,R,A,P,I,S labels around the slice? For me it seems complicated to display the combination of the of the directions.
I have seen this “rotation” in another software that is widely used by clinicians.
In most cases direction codes displayed on the sides or rotated should work similarly well. Even very experienced radiologist have a lot of trouble interpreting oblique images, so most of the time the images would be aligned with anatomical axes or slightly rotated along one axis. Direction codes should be fairly straightforward to interpret either displayed at image sides or rotated around. Directions are only needed for the clinicians to distinguish sides of symmetric structures anyway, as they are getting the general sense of orientation by recognizing patient anatomy in the images.
However, when you display oblique slices, labeling direction becomes much harder, because neither slice intersection lines nor any axes that lie within the slice plane will concide with any of the anatomical axis directions.
For example, what direction codes would you draw an these image slices and where?
Rotating the labels can reduce the direction codes from 3-letter-code to 2, or from 2-letter-code to just 1 in some special cases, which I agree could be somewhat useful, as it could potentially make some directions easier to interpret. However, it would raise several new problems:
In general, you would not be able to show single-letter codes anywhere anyway. You could choose to show only the dominant direction (i.e., the first letter of the direction code), but that may be misleading.
It would make the already difficult corner text annotation layout problem even harder to solve: where would you show those labels to avoid overlap with corner annotations?
Users could have trouble finding those direction codes, because they move around.
Direction labels may be mistaken for other image annotations if the labels do not appear in a standard location.
Orientation codes are displayed at image sides in most if not all other radiology software. Users would have harder time getting used to the labels showing up in different location.
Considering that rotating the labels around would not make the directions much easier to interpret in complex cases and it would raise several new problems, overall it seems better to display labels in standard locations (at center of image sides).
I got back to the problem after a while, considering what you said. I thought of a solution (probably not general) utilizing vtk.CornerAnnotations to write on the sides of the viewers. I need to write only to the edge centers, as my views are always perpendicular to each other.
(However, it could be later extended to show the letters after reorienting your views such that one view would be horizontal and we would write at the right edge.)
During this, I found out, that one is not able to write to lower right corner. When you run
the note is visible for a moment, and then disapears again. Is it because the place is reserved for the orientation marker?
Another question I have is how do you get the orientation programatically?
In the image below, I have just hardcoded LIA into the code. I cannot find the right command to get this orientation.
Corner annotations are alredy used by DataProbe module. All corners are already used for displaying some content. Only the centers remain available for direction codes, and actually that is the position where you want to display the codes anyway.
Note that VTK corner annotations very limited. It can only do a small fraction of what we need (see here for some details), so if you implement direction code display using corner annotations, it’ll probably have to remain just prototype/test code and needs to be redesigned before it can be integrated into Slicer core.
