We experienced many problems related to scene views, seen many workarounds in many places in the code, and there are many open issues caused by or related to scene views.
The main problem seems to be that it is unclear what information scene views should store and restore.
Should it be enough for scene views to store display information of nodes, view layout, view settings, and camera settings?
If that’s true, we could simplify the scene view implementation a lot, because we would not need to deal with storable nodes (display, camera, etc. nodes are always stored in the scene). We could also delete display properties of nodes that are removed from the scene.
If still think scene views (or snapshots) are useful, they allow to capture different state of a workflow.
What would be needed is the notion of implicit sharing and copy on write for storable node.
This also means that if the same dataset is loaded multiple times, the dataset would be effectively in memory only once (until it is effectively modified).
This could be addressed at the itkImage/vtkImage level. or further up the stack at the node level.
There are a couple of scene state management mechanisms:
To demonstrate going through a processing a workflow, it is much simpler and safer to save each state as a separate scene.
If you want to capture different time points, you can use Sequences module.
To show different views of the same data, there is the current Scene views infrastructure.
For scene state snapshots, there is the (now mostly hidden) undo/redo infrastructure.
There is undo/redo stack in Editor and Segment editor for labelmap and segmentation nodes.
I’m not sure if we need to extend snapshots in addition to all these existing mechanisms for scene state management (scene views never saved storable nodes, so they were never usable for generic scene state management).
I love the title of this thread! I was struggling with this question when I started using Slicer 3, never found the answer, despite many attempts, and decided to just ignore the existence of this “feature”.
Yes!
Ironically, this is essentially what I suggested about 10 years ago to Ron, Steve and Nicole!
I agree that the feature set of the scene views should be better defined, and it should be made sure that the new feature set works correctly. I spent several days adding scene view support when rewriting subject hierarchy earlier this year, and it struck me that the only thing I needed to support in SH for scene views did not work (which I thought was basically re-adding removed nodes and removing new nodes - as display options are not stored in SH, these were the focus for me that time), but there was a mechanism for this and it was quite complex. So the same question popped up in my head: what is it supposed to do?
Based on my earlier conversations with people, I think it is mostly used for demonstrations/tutorials, so Sonia and Ron should definitely be asked.
My own opinion is that handling display properties should be enough. Cameras, display nodes, layouts, slice composite nodes, etc.
What about hierarchies though? They are in some sense display properties, and for models and annotations, those are actual nodes we need to handle. For SH, it is only one node that needs to be replaced (and then validated).
I would not save hierarchy nodes if at all possible. Is there any information in a hierarchy node that you think would be useful to capture in a scene view? Maybe the “Force color to children” setting (Expanded property)?
I mainly meant the hierarchy itself. Parents-children. I don’t see a huge need to preserve this information, but to me the hierarchies seem like a kind of display properties of the already loaded data. Good point about the force color option as well.
Handling the hierarchies would keep some of the complexity of the scene view implementation we want to get rid of, so we should only consider this if others think it is important. I brought this up because this thread is about re-design, and this may be something to consider.
I’d like to see us come up with a concrete definition of a scene view (or
if needed a new name for a new concept).
Functionally I’d say that creating a scene view is like saving an mrb, and
that switching to a scene view should be equivalent to closing one scene
and opening another. Then the only real question is how to make this
efficient by reusing data that is already loaded in memory. This
definition provides an easily testable baseline (which the current
implementation doesn’t meet).
What would be the use case for this? For reviewing an atlas or a surgical plan you would not need a complete copy of all nodes - changing visualization settings (display nodes, view nodes, composite nodes, maybe hierarchy nodes) would be enough.
Closing the scene means that we lose all node references (nodes that you selected in modules), so a scene view restore would be a huge, breaking change in the scene (you would need to set up everything again).
However, if we just update existing nodes in the scene, it would be very difficult to do it correctly for all nodes: node references and adding/removal of nodes between scene views is particularly tricky. Correct management of large storable nodes would be very difficult to implement, too.
If you follow the close scene rule then those parameter nodes will be deleted when you restore a previous scene view.
I think we can define a clear line: we restore content of all display nodes and view nodes (and potentially hierarchy nodes). If we limit the types of nodes that we support then we can ensure correct save/restore behavior. The behavior will be also very simple if we don’t support adding/removing nodes (we just hide anything that we don’t want to show) and saving/restoring content from files (all saved/restored data can be stored in xml string).
Yes, that’s the point - you get the parameter nodes from the other scene view that were in effect when it was created.
But what you are describing to just save view and display nodes could work. When you restore you can ignore anything that doesn’t apply (like display nodes for data that has been deleted). There will need to be graceful handling of data that’s been added since the view was created.
