Hi!
We would need to use a colormap node that would be used in many of our Slicer scripted modules and also CLIs.
Is it ok if I just add the file to the https://github.com/Slicer/Slicer/tree/master/Base/Logic/Resources/ColorFiles folder and someone integrates the changes in the core?
Thank you
We plan to change how color map nodes are stored in Slicer to avoid keeping 100+ unused nodes in the scene (see https://issues.slicer.org/view.php?id=3955). So, it is better not to add any further color nodes, especially not application-specific ones to the current color module.
It would be better (more robust and future-proof) to add a Get…() method to one of the module logic classes in your extension that would add the color node to the scene (if not present already) and return a pointer to it. You may even add it when your module is initialized, but in general it is preferable to add nodes to a scene when they are actually needed.
That works in modules, but as I said, the same thing applies to dozens of our CLIs. How would you manage to assign a custom colormap node to a labelmap node that is a CLI output?
I think you can create colormap nodes using mini-scenes, but it is probably simpler to add your custom color nodes in one of your module logic’s initialization method.
Some more information that you may find helpful:
There are many issues with current default labelmaps. I just referred to one ticket above, but there are a couple of more, related to problems due to having many nodes in the scene, requirement of all color nodes must be hidden, difficulty with sharing color nodes that have the same range, showing color bars in 2D/3D views with absolute range, etc. Due to these issues, eventually the design of these default color tables will be refactored, so I would recommend to only use them for defining qualitative color gradients, and add custom color nodes for anything more complicated. Those recently added perceptually uniform colormaps fell into this category of being some nice color gradients for visualization, and they were completely generic, so it made sense to add to the core, but in general we should avoid adding more color maps to the core.
Therefore, the proposed solution:
Short term: Since the introduction of extension infrastructure, there is no reason to pollute the Slicer scene with application/extension-specific color maps. Extension-specific color maps can be very easily added to the scene in the extension that needs those - as it is already done in several extensions. Examples for the two main approaches:
Adding color map on-demand with Get…() method:
https://github.com/QIICR/LongitudinalPETCT/blob/41438ecfafd9470a6dc4d16940256b8005bb9fe4/Logic/vtkSlicerLongitudinalPETCTLogic.cxx#L239-L279
Pro: does not pollute the scene with potentially unused nodes. Con: may be more complicated with CLIs.
Example for adding color map in the module logic on initialization:
https://app.assembla.com/spaces/slicerrt/subversion/source/HEAD/trunk/SlicerRt/src/Isodose/Logic/vtkSlicerIsodoseModuleLogic.cxx#ln108
Long term: CIP should use standard terminologies instead of relying on LUTs for labeling structures to make it easier and safer to import, process, and store results in a standard, structured way. Segmentation nodes already associate a standard DICOM coded entry with each segment, Segment Statistics module can compute metrics, results can be exported to/imported from DICOM. Segmentations are not yet supported by CLIs because we always had more important things to do, but if you can spend some time with working on it, then it would happen sooner. Just let us know if you are interested and start the discussion.