Slicer can save the scene in a DICOM file that can be stored on a PACS or other DICOM archives. Review workstations (other than Slicer) cannot interpret the contents (other than showing a short description and a screenshot) but they may be able to download it and save it to file that Slicer can open.
As Slicer’s standard DICOM export capabilities are improved, this special Slicer-specific export capability may be removed in the future. To help us make an informed decision, please answer the poll below (even if you haven’t heard about this feature and don’t plan to use it).
I haven’t heard about this feature and I don’t think I would use it
I haven’t heard about this feature but I think I will use it
In my opinion, Slicer standard DICOM export will not replace Slicer-specific export capabilities any time soon. The standard does not cover all of the types of data Slicer needs to store, and implementation of even all those that it covers will take a very big effort.
The feature is potentially useful. I’ve asked the question because if we really want to make it easy to find and use then we need to invest time in it (not just now but later, continuously with maintenance, testing, support). If nobody uses the feature then we could spend the same time with improving or developing other things, such as standard DICOM export.
The original motivation for the data bundle was to allow people to use dicom storage tools to manage scene data. So far I haven’t seen anyone doing that.
I agree with @fedorov that there’s a lot of Slicer data that doesn’t have a perfect match to standard DICOM objects, so we will always need some level of application-specific data format, but the point is that I don’t think it’s proven useful to opaquely store that inside a DICOM object as opposed to MRBs and other representations.
@pieper I agree, I am not advocating to keep it or fix it. Just saying that DICOM will not meet all of the needs.
My approach is to stay as close as possible to what DICOM supports, and use custom non-mrml-scene things where it is lacking the capabilities. I had a lot of very bad experience with scenes and don’t want to rely on them at all anywhere.
Your bad experience with scene saving always surprises me. I use Slicer a lot for many projects (with tens of students, working full time) and we don’t have any issue with saving the application state into scene file and restoring everything. Could you please file a bug report for any issue that you know about or send list of related bug reports?
If you looked over all the issues I submitted related to scene/mrml, perhaps you would not be so surprised. Especially considering that some of those issues remained open for 5 years. And I had a lot for Slicer 3, which were never addressed. I was very active submitting bugs related to this topic many many years ago, but not anymore, since I realized they were never prioritized. It may work now, I don’t know. I just lost the faith in this feature, and I don’t want to revisit it.
I’ve checked all errors you reported and still open (58 in total) and there are only 2-3 related to scene saving/loading, all are quite special cases. So, it seems scene saving/loading issues have been mostly solved after all. It’s OK not to use scene saving/loading, but it may be important for you and others to know that these features work reliably.
I’ve also stopped submitting bug reports to the bug tracker due to the long list of unresolved issues, but now I’m in the process of cleaning this up so that we can start using the bug tracker again for tracking and prioritizing issues.
I didn’t know about the existence of this feature. If it allows storing the entire scene easily to a PACS server, it sounds a very useful feature and I will likely start using it. I think that standard DICOM export can not replace it in a near future.
For context, here are the pros and cons of the approach as I see it:
Pros:
it’s basically just a .mrb package binary blob added in a private tag of a dicom secondary capture, where a screen grab of the slicer display is the image portion of the capture image.
secondary captures are widely supported on PACS and on viewer software so people can transfer the data and see the screen capture on standard hardware.
the data transfer is ‘lossless’ from a slicer perspective since it preserves the normal scene state (assuming scenes work well for your use case).
putting binary blobs in private tags is pretty common in commercial systems.
the mrb binary data is just a renamed zip file that stores the mrml file and corresponding data in standard research formats (nrrd, vtk, csv, etc) so if someone really wanted to extract the data for another purpose it wouldn’t be too hard.
Cons:
the contents of our private tag is definitely non-standard
a scene file contains copies of all the image data (stored as nrrd in the .mrb) so it’s not efficient
a large binary blob in a secondary capture object is kind of an abuse of the standard and would likely cause performance issues on some viewers that expect an SC to be a lightweight object.
in general we try to avoid pushing Slicer results into clinical PACS systems. Some careful testing would be a good idea.