I am interested in converting the TotalSegmentator training dataset from NifTi to DICOM.
I’ve converted each CT NifTi file to a DICOM series using slicer.modules.createdicomseries, where I specified parameters including the inputVolume, dicomDirectory, patientID, studyID, seriesNumber, seriesDescription, and modality.
The converted DICOM files load successfully in Slicer. However, I then used dciodvfy from dicom3tools to verify that these converted DICOM files are valid. It displayed the following warnings/errors:
Warning - Value dubious for this VR - (0x0010,0x0010) PN Patient's Name PN [1] = <Anonymous> - Retired Person Name form
CTImage
Error - Missing attribute Type 2C Conditional Element=<Laterality> Module=<GeneralSeries>
Error - Missing attribute Type 2 Required Element=<KVP> Module=<CTImage>
Error - Missing attribute Type 2 Required Element=<AcquisitionNumber> Module=<CTImage>
Using the slicer.modules.createdicomseries, how do I specify these particular fields to create a valid DICOM file?
Hi @DeepaKrishnaswamy - this module was developed by some of our good friends at GE many years ago and I recall they only did the bare minimum to get their company’s workstation to recognize and show data generated from ITK/Slicer, so It’s not a surprise that the data isn’t perfect. The code is here if you want to have a look. It’s pretty hard coded but wouldn’t be hard to extend to fix these issues. It would just be exposing these tags as command line options following the existing pattern. It would be great if you or someone could try this.
Of course another, probably a bit easier but hacky, solution would be to write a pydicom script to patch the generated files to add these fields. Basically like the DICOMPatcher.
I’ll bet you don’t know KVP for this data so there’s no way to make them perfect, but I guess you can make them as close as possible.
None of the validation errors explain the completely garbled output in OHIF viewer. Is there any other DICOM viewer that has trouble loading and displaying this CT properly?
If none of those software had any issues with the image then most likely the problem is in OHIF. Report the error to them and attach the image that OHIF does not load correctly.
We reviewed this example with @David_Clunie, and he noticed that the slices have rather unusual for a typical DICOM resolution (since the original DICOM data was resampled and cropped prior to creating the source NIfTIs), resulting in an odd number of pixels in a frame, which may trigger a bug in OHIF v2. We will investigate this further with the OHIF team, and will try to make sure this is fixed for OHIF v3.