I want to export 3D ultrasound to DICOM.
When I choose the modality as US during export, and then load the exported DICOMs back it into Slicer, it gets loaded as a lot of separate slices, instead of one volume (like for example with an MR or CT):
I can choose MR or CT as the modality and then it gets loaded as one volume, but that does not seem right.
What should I do?
Does exporting it to a different format produce the same outcome?
When I export it to .nii and import it back again it gets imported as a volume and not slices
I also just noticed that I get the following warning (for each slice) when I load the dicoms:
Warning in DICOM plugin Image sequence when examining loadable 1: US No series description [107]: Image spacing may need to be calibrated for accurate size measurements.
There is no commonly used DICOM standard for storing 3D/4D ultrasound images. What software do you plan to use to read the exported images? What DICOM information objects does that software support?
Wouldn’t the Enhanced Ultrasound Volume Storage (EUVS) be the DICOM standard to be used?
I’m preparing data for a publication on TCIA which wants all the data in DICOM - so I can’t say what kind of software other people would use to read those images.
However, I would ideally want to keep using Slicer and Python (Pydicom).
@fedorov @David_Clunie What DICOM information object would you recommend to store 3D ultrasound data on TCIA?
I would recommend staying as close as possible (ie, keep everything that remains after de-identification following a DICOM profile) to the original representation produced by the US scanner, whatever it is. Exporting from NIFTI to any DICOM object will most likely result in meaningless metadata.
3D ultrasound images in RESECT are created using research software, they are in MINC file format and have never been written to DICOM.
The only 3D ultrasound data in TCIA that I know of is the infamous Eigen Artemis volumes in the Prostate-MRI-US-Biopsy collection, but I would not want to follow bad practices. @David_Clunie’s recommendations a few years ago when the Artemis data set was discussed was:
It would obviously be far preferable (for us) if the submitter did created an Enhanced US Volume instance, but then probably nobody would be able to display it, so in a clinical product they would have to be able to create both, depending on what the user could cope with. They could stuff the Enhanced US Volume attributes (esp. the spatial macros) in the old SOP Class (as a Standard Extended SOP Class), which would probably be a good compromise.
@fedorov do you know about any such data set or tools or examples that can create such Standard Extended SOP Class files? Or we should just use the enhanced format and not care about incompatibility with clinical software?
I just gave the RESECT file as an example as I’m not allowed to share my data yet. Bu this is how I gather all my data:
OK, this is essentially the same as the case with RESECT, i.e., research software creates a 3D ultrasound volume, so the 3D ultrasound DICOM files must be created from scratch.
Thank you for the clarification, I didn’t know those details.
First and foremost, even if you end up doing the conversion to DICOM, I would recommend including the original data as collected by the acquisition equipment in the final package you will be sharing via TCIA.
If you decide to explore conversion to DICOM, I am not aware of any tools or examples that you could leverage. Reading the recommendation from @dclunie, it sounds like the recommended approach is not something that anyone implemented before. Quite likely, it will take significant effort to create those standard representations (it is not even clear to me if that compromise suggested would pass David’s validator - and if it is expected that validation will not be passed, it will be challenging to distinguish expected errors from the real errors).
My recommendation would be to proceed with sharing of the data in NRRD format to make them available expediently, and in parallel evaluate the effort that would be required to follow recommendations from David.
Sounds good to me. @koeglfryderyk I can offer my help with implementing 3D ultrasound DICOM import/export plugin for Slicer if you can provide a Python script that creates a valid DICOM file (e.g., using pydicom). I can also help with advice/review your Python script and participate in a few meetings with @David_Clunie and TCIA folks to agree in an acceptable file format.
@koeglfryderyk if you decide to work on such a converter, I can also advice/participate in a few meetings. I do not anticipate TCIA will have any guidance on the details of DICOM encoding. As long as the result passes David’s validator, or has David’s approval, I am sure it will be fine, so we can save the time. I am not sure David is monitoring this forum, so I will add this topic to my agenda for the weekly meeting with David on Friday, and can update this thread after that. For me the key question is how useful the resulting converter would be for the community beyond your specific use case, and whether the investment of effort is justified.
@fedorov ok, thank you for your advice. I’ll share it as NRRD then, this will save me a lot of time.
@lassoan thank you for your offer of help. I think I’ll first try to determine, as @fedorov mentioned, whether anyone else would use this and if the investment would make sense.
However, I have one last question:
When I load the exported US DICOM, next to the slices there is also a Scalar volume loaded, which contains all the data in one volume, however, the pixel spacing is incorrect (as I describe here).
So it seems to me like the exporting and loading of 3D US in Slicer kind of works, only that it also loads slices and has wrong pixel spacing
@koeglfryderyk I discussed this with David Clunie today. There is a NRRD to DICOM converter that he has: NRRDToDicom, but it currently does not have the features needed to produce DICOM US. David thinks it may not be a very complex task to improve that converter to generate DICOM US, he is willing to spend time on this, and we can justify this work within the scope of the IDC project. BUT in order to start David would need a sample of your data. I understand you are not able to share that yet, but as soon as you can, it would be great if you could update this thread, or email me, so we can start this work.
The converter will likely be useful to others, and you won’t find a better expert to work on this than David Clunie, so let’s make sure we use this opportunity!
Would you need a 3D US DICOM or NRRD?
I thought NRRD is the only thing that you have, no?
For most cases we have only NRRDs, but we have DICOMs for a few specific ones. We are still working on getting everything in DICOM, but this depends on on Brainlab fixing some things and not on us.
