Revisit implementation using standard Slicer annotation

[jcfr]

Following the initial development of the module started in 2015, a lot changed in Slicer. There are now built-in annotations (lines, angles, plane, ... ) that may be used as building blocks.

Re-using these would reduce maintenance cost by simplifying the implementation.

To support computing the following relative measurements:

• Midpoint between two fiducials
• Angle between two lines
• Distance between line and a point
• Distance between two landmark

Use cases

To more effectively refine the plan outline below, it would be great to describe the measurement use cases.

Some of the use cases a described in #7

To be done

@bpaniagua @luciacev

Suggested approach

The sections below discuss possible approach to simplify the module.

Relative measurements

Midpoint between two fiducials

Few options:#7 (comment)

• (1) custom python code in extension to add (and update) fiducial position based on fiducial position associated with line annotation
• (2) update built-in line annotation to support displaying midpoint. @lassoan: What do you think ?

Benefits:

• address colors of landmarks #5
• greatly simplify the use of KD-tree implemented in dev/issue-19 #21 to address Issues defining the middle point #19

Note: The new json format for markup currently allow to save only one annotation per json file, we should evaluate if support for saving multiple annotation per json is strictly required. (see this previous discussion at Slicer/Slicer#4938 (comment))

Distance between two landmarks

Re-use the build-in line annotation. The R-L, A-P and S-I components associated with the distance would then be easily computed given a line annotation.

For example:

Angle between two lines

User would have two options:

• (1) re-use the built-in angle annotation. For example:

• (2) compute the angle given two "line" annotations.

Distance between line and a point

The logic function would be given a line annotation and a fiducial.

Saving/Loading measurements

Currently them module allows to save/load linePoint.csv, distance.csv or angle.csv. Custom read/write functions are maintained in the module.

Considering Slicer now allows for saving and loading data from csv/text/json as table:

• https://www.slicer.org/wiki/Documentation/Nightly/Modules/Tables
• https://discourse.slicer.org/t/table-columns-customization/436

For now, I suggest we revisit the module to leverage the saving/loading of tabular data through the tables modules.

References:

• Discussion about json structure to organize relative measurements. See adding one new measurement in Q3DC #7 (comment)

Long term

In the future, we are thinking about creating a "Relative Measurements" module (or similar name) in Slicer allowing to easily define measurement computed based on position of other simple annotation.

At that stage, there is nothing formal but considering this type of features seems to be a common need, I think it is worth having a discussion.

cc: @lassoan

[JEHoctor]

Note that Q3DC does not actually measure the angle between two lines. In fact, it projects two line segments (which do not necessarily intersect) onto the x-y, x-z, and y-z planes, and measures the orientation angles of these projections. I think it doesn't even take the difference.

*This is not based on a vigorous reading of the code.

[lassoan]

Probably we need to add a few more primitives, such as bilinear measurement (ratio, distance, angle between two line segments), ROI (similar to annotation ROI but with built-in rotation; and with box and ellipsoid option). If we have these then we can perform the most common measurement types manually, and can also use these widgets to display custom automatic measurement results.

Since relative measurement results are usually distances, angles, etc., they can be displayed using markups nodes. Markups nodes can already store measurement results. As all other MRML nodes, markups nodes can store references to other nodes. Therefore, markups nodes are well suited to store all inputs and outputs of a relative measurement. We could use independent custom modules to observe markups nodes and update relative measurement results, but I think we know enough already to do better than this. For example, @Sunderlandkyl has implemented a relative measurement system before. Based on that experience and using the latest widgets, we should be able to create a flexible, extensible plugin system for this.

Saving/loading measurements: There could be several measurements for a single markup, which could be easily saved into the markups json file. One of the measurements for a markup could be "highlighted", which would be the one that is displayed in the markups module tree, would be displayed in slice/3D views, and this single measurement could be exported to a table node.

Saving/loading markups: Current markups json schema allows export of multiple markups into a single file (e.g., from a Subject hierarchy plugin, by right-clicking on a folder in the Subject hierarchy tree). Import is also easy to implement, in the markups reader plugin. Saving/loading the scene would still always save a single markup per file (it would be very hard to save multiple markups in a single file).

[lassoan]

Probably we should continue this discussion on the Slicer forum to give more visibility and allow others to join.