Cli node references

[cpinter]

It was possible to define references in CLIs before, but they had special meaning (set parent transform, set subject hierarchy parent), and they were defined "in reverse", i.e. in the referenced object.
This change adds support for generic, forward references, which allow specifying any type of reference between two nodes. For example in a registration module, the output transform can specify node references to the moving and fixed images.

Registration modules have been updated to use this reference feature to reference the input images from the output transformations. This change is needed for proper DICOM spatial registration export (SlicerRt/SlicerRT#42)

The following PR is needed before this can be integrated: Slicer/SlicerExecutionModel#109

[pieper]

Sounds good to me 👍

[cpinter]

Thanks, Steve! Can we go ahead with Slicer/SlicerExecutionModel#109 as well?

[pieper]

Yes, both patches look good to me (haven't built, but looks good). Thanks for the contributions! 👍

[fedorov]

Just for the reference (no pun intended!), the original intent of adding "reference" to CLI was not motivated by transformations, but to initialize window/level for the resampled volume consistently with the input to the resampling tools. I managed to find the email below from 2010 when I emailed @hjmjohnson about adding this feature. I hope that feature is still working!

On 7/22/10 2:35 PM, "Andriy Fedorov" [email protected] wrote:

Hi Hans,

I added a feature to Slicer that allows to specify "reference" image
for output images produced by a command line module. If reference is
specified, then the display node (colormap and window width/level) for
the output image will be automatically set to be the same as in the
reference image.

I implemented this specifically to simplify window/level setting for
the result of image resampling.

If you don't mind, I will add this "reference" feature to
BRAINSResample xml. Let me know

[cpinter]

As far as I know this piece of code processes references in Slicer CLIs:
https://github.com/Slicer/Slicer/blob/master/Base/QTCLI/vtkSlicerCLIModuleLogic.cxx#L2449-L2534

And all I can see here are the transforms and the subject hierarchy parents. If the window/level feature stll works, then I don't know where it's implemented.

[lassoan]

It would be great to copy window/level indeed (I don't think it was implemented in Slicer4). Generating new output volume name based on input volume name would be useful, too.

@cpinter How do you think such features could be added in the future? Using special role names?

[cpinter]

It's a good idea to use references for actions on a node using another node, because it can be done without cluttering the CLI infrastructure, and handling these on the Slicer level would be easy. For example:

• Forward reference from the resampled volume to the input volume with role called "RequestWindowLevelCopy" or similar
• OnNodeReferenceAdded could react on this request, then even remove the reference if it makes sense

[cpinter]

@jcfr @pieper @lassoan I cherry-picked my BRAINS commit from their master after it was merged, to Slicer's BRAINS fork's master, but then I realized that it did not build, and that Slicer uses the slicer-2019-03-07-v5.0.0-2af1e31 branch not the master. What should I do? Create a new branch based on the slicer-2019-03-07-v5.0.0-2af1e31 branch? If yes, what should it be called? Thanks!

[cpinter]

I talked to @lassoan and did the following:

• Cherry-picked that commit in the existing slicer-2019-03-07-v5.0.0-2af1e31 branch
• Removed the commit from the master

Now I'll update Slicer's SuperBuild.cmake to use the latest hash from the branch (and do the same for SEM) and push this PR's commits and that one.

[cpinter]

Integrated in
Slicer/Slicer@4ad9ed1
Slicer/Slicer@62a9f9a
Slicer/Slicer@8301c8c
Slicer/Slicer@fea81f7