I am a bit new at using the Dicom export function and currently it gives the error:
Traceback (most recent call last):
File “”, line 2, in
TypeError: init() missing 1 required positional argument: ‘referenceFile’
When I try to export the scene into Dicom. I am aware that in this case it can only be opened with slicer but that is the point. I checked from the code of the export function that it should take the first file from the dicom database as the reference or you can specify a reference file but I do not see such option as the export scene freezes all options to begin with.
Thanks for reporting. Yes, it looks like this refactoring led to an argument mismatch between the dialog code and the python class. You could try going back to an earlier version of Slicer and it might work. @lassoan or @cpinter have you tried this feature lately?
@Pheasant you can call the exporter from Python with the needed argument - as you say it just needs to be a file from the study you want to export into.
We refactored the scene bundle export to use the export plugin infrastructure (using the first file in the DICOM database as a basis of the bundle just seemed very arbitrary). However, we forgot to remove the option from the top (and nobody reported it that it was broken until now).
You can choose Slicer data bundle export type to export a scene in a DICOM file:
The item that you right-click on will be used as a basis for the DICOM file, so if you don’t have anything loaded from DICOM then you first need to export something (e.g., a volume node) to DICOM and then load it into the scene. It is definitely not nice or convenient, there was just not a lot of interest in this feature to make it polished and easily usable for many workflows.
@Pheasant can you tell a bit about your workflow? How do you plan to use these scene bundle DICOM files?
@pieper@cpinter what do you think about removing the Export entire scene option from the top of the DICOM export dialog and just use export type selector instead?
Yes, I think coming up with something cleaner makes sense. Since the scene may not include anything loaded via dicom, it could be nice to be able to pick an instance to use as the source of metadata for the export, so that the exported scene gets associated with the desired study.
I’d also be curious to hear from @Pheasant how you might use this and how it works in actual practice.
The main purpose of the DICOM export is storage. The place where we store data accepts only DICOM-format. The point would be to be able to store old works in a way that doesn’t require them to be saved locally. The workflow is something that is repeated regularly and the main use for Slicer is jumping from one mark up point to other to see specific parts of the brain. The scene has multiple markups in it.
I tried the save data bundle option but got a different error from it (I removed the paths and replaced them with * for this post):
Saving Image…
Saving scene into MRB…
Making dicom reference file…
Using reference file reference_file.dcm
Failed to export using plugin DICOMSlicerDataBundlePluginClass
Traceback (most recent call last):
File “”, line 3, in
File “*/DICOMSlicerDataBundlePlugin.py”, line 226, in export
exporter.export()
File “*\DICOMExportScene.py”, line 58, in export
success = self.createDICOMFileForScene()
File “*\DICOMExportScene.py”, line 119, in createDICOMFileForScene
I did some tests on it and I didn’t get an error from selecting export scalar volume for the reference Dicom file. Then I loaded the exported file and used that as the reference for the Export as data bundle and it seems to work like that. I guess exporting it as scalar volume made the dicom file readable for it?
I think the reason might be that there are some characters (for example ä or ö) in the original Dicom file, I tried removing the ones that I noticed but it didn’t help though.
I am curious however about the reason for that exporting the scalar volume works well but not the data bundle one.
@Pheasant If it’s possible for you to create an mrb (no patient data) that fails to export to dicom for you then it could be tested on different machines for debugging.
As long as you are comfortable, sharing your own MRI is fine. You can put them in a service like dropbox, google drive, etc. Share a link by direct message if you’d rather not make them public.