Extend the markup json to support multiple markups object

In SlicerMorph, we often create different types of markup objects on the same volume/module (e.g., anatomical landmarks, geometrically sampled landmarks, resampled curves etc.).

Due to analytical requirements, we have to merge these objects into a single pointList node. There are couple problems with that:

  1. We loose visual properties that might have been set to distinguish these object (red for anatomical, blue for semiLM, yellow for curves type of things).
  2. We have to use the description field to tell what these points were previously (because certain analyses distinguish between these points)
  3. Not a good practice for data management as it increases data redundancy (user needs to preserve the individual files, if they have to redo/alter things)

Instead more elegant solution would be to save these into a single JSON file. The decision to save the markups objects individually versus by as a single file can be made actively by the user by nesting these markups objects under a hierarchy, from which the filename of the combined JSON file can be derived from.

We can implement this feature inside the SlicerMorph, but I think can have a broad appeal outside of SlicerMorph, so wanted to discuss.

Reading multiple markups from a single markup json file is already supported. There is currently no GUI for creating such combined file, but can be easily done using a text editor for testing. A right-click menu item could be added to Folder item type in the subject hierarchy tree (no Slicer core change is needed, a Python scripted Subject Hierarchy Plugin would work) to export all markups in that folder into a single file.

The markups reader could be updated to put markups that were loaded from a single file into a subject hierarchy subfolder.

One limitation is that we cannot save multiple nodes into a single file. We can save one node into multiple files. We can also import/export multiple nodes from/to a single file. If we wanted to change this, it would require changing the 1-to-1 association between data node and storage node, and it would make the saving logic much more complex.

Can you clarify these two statements?

Using the visual I provided above, what would happen if I try to read the combined JSON file into Slicer? I would not get three separate nodes?

Reading (importing) and exporting multiple nodes to/from file is fine.

Import is already implemented in the markups reader, so if you drag-and-drop a json file containing several markups to the Slicer application window, each markup will appear as a separate node.

ok. Thanks for the clarification.

This doesn’t seem to resolve the issue #3 (data redundancy), as I understand there will continue to be two sets of markups (one individual files saved with the scene, and one combined that’s exported).

One option could be to create a custom node type that has a dedicated storage node type that saves multiple referenced markups into a single file of the type you want. Then it would be able to re-use the existing save and load mechanisms. You could set the SaveWithScene flag to False for the referenced markup nodes so that you’d only have the one copy saved. This custom compound-markup type could also have logic and gui to make it easier to manage the naming and display properties.

Could describe more about this? Which analysis are you referring to? Is this outside of 3D Slicer? You are not able to select multiple markup objects to use as inputs?

In generalized procrustes analysis, you need to have the same number of landmarks for every sample. And more importantly, when the superimposition is generated non-anatomical landmarks (semiLMs, or resampled points on curves) are slid into new positions by minimizing the bending energy (or alternatively procrustes distances), but anatomical landmarks are treated as rigid. So you need to able to distinguish anatomical (fixed) landmarks from other types of landmarks.

Our GPA module (as well many other packages) have a one file per specimen/sample paradigm, so we if you are using semiLMs and anatomical LMs together, you need to concatenate them into a single file.