I am trying to align the MR, CT and PET files in CC Tumor Heterogenity dataset. But I am facing issues with the tags in coregistration files not matching with corresponding folders of MRI,CT,PET etc. Need help with the coregistration file details.
1 Like
What have you tried so far? I’m not familiar with the collection, but from a quick look at the data it appears that the source data and registration objects are all available.
I tried uploading the co-registration file, along with the corresponding MR-CT and PET-CT folders in 3D Slicer to register the slices and save them. But, the PET-CT transformation matrix does not rotate the moving image. It merely moves the images closer. I tried volume rendering the same as well, but the volumes are not registering when using the given matrix in the co-reg files. (Although it did work for PET-MR).
To check for mapping among Coreg files, CTs and MRIs, I tried extracting the UIDs of files given in folders for patient A01. But I could not find matching series or instance IDs in the MR1-CT1 co-registration file that is within the same folder as MR1 and CT1. I wanted to know what could be possibly going wrong here, and if there is a better approach to this.
This is the post-alignment screenshot for Patient A01- PET1-CT1 :
I haven’t worked directly with this data, but the since you said it worked for PET-MR but not for PET-CT then it’s possible the datafiles themselves are not correct.
The fact that the CT is upside down in this image is a big red flag that something is incorrect in the data. Is that the way the CT loaded in Slicer or is that after applying the transform?
Are you using the SlicerRT extension to read the dicom registrations? Or how do you get them?
Yes, I am using SlicerRT, I am loading the volumes and then loading the Coregistration file as Dicom Import.
This is how PET and CT volumes render before applying the transform:
Not much difference evident, except for a slight shift towards each other.
Okay, to get to the bottom of thincs can you describe your exact steps and what software versions etc lead to what you observe?
@Sivapriya_P_J thank you for raising this question!
I have not worked with DICOM REG before, and I spent some time now to look at that collection and try to understand the relevant part of the standard - just a disclaimer!
First, it seems that the data in this collection is not organized well. You will see that there are some DICOM studies that contain just one series, and some that contain more than 10 series, with many of the series being REG. It might be that as part of post-processing or de-identification, series that were supposed to be in the same study were split into separate studies. This makes navigation of this dataset particularly difficult.
Second, from my understanding of the Registration sequence in the DICOM standard, it references specific image instances to which the transform applies. At the same time, DICOM REG import plugin does not automatically load the images referenced in REG, and the actual LoadDicomSro load function seems to assume the images to which the transform should be applied are already loaded, and may actually not be correct, since it seems to rely on SeriesInstanceUID values for establishing the correspondence of the registration transformation and the images. Registration sequence mentioned above does not contain SeriesInstanceUIDs, and the function seems to be picking those from the ReferencedSeriesSequence.
I think what might be happening in your example is that the registration you loaded does not correspond to the pair of images you have in the scene.
To debug the dataset, I downloaded all of the studies for the first patient using idc-index:
$ pip install --upgrade idc-index
$ idc download CCTH-A01
Then I sorted all of those files into folders using dicomsort:
$ python dicomsort.py -u ./cc-reg ./sorted/%StudyInstanceUID/%Modality-%SeriesDescription-%SeriesInstanceUID/%SOPInstanceUID.dcm
This will give you file layout like this:
Next I opened one of the REG “MR-MR” series, and took ReferencedSOPInstanceUID values from the first and second sequence items: 1.3.6.1.4.1.14519.5.2.1.202039873262802070974250993906039317912 and 1.3.6.1.4.1.14519.5.2.1.35526777209978203141991822578460736676.
Since the files in the folders are named by SOPInstanceUID, I could then quickly look up those instances like this:
$ find . |grep 1.3.6.1.4.1.14519.5.2.1.202039873262802070974250993906039317912
What I found is that there are no instances available for that patient that match the references. It appears to be a problem with the collection. It might be that UIDs were not properly hashed, or that the submission was incomplete.
CC-Tumor-Heterogeneity was curated by TCIA and ingested into IDC, so I recommend you reach out to TCIA helpdesk. You can mention this thread, it may help with the context. You can also ask them to add me to the ticket so I can try to help.
Hello,
Thank you for your response.
I have compared the ReferencedSOPInstanceUIDs and several other reference identifiers across multiple folders as you mentioned, for A01 patient, specifically those containing co-registration DICOMs (PET-CT and MR-CT), to identify matching instances. However, I continue to encounter the same issue.
I will be raising a support ticket regarding this matter and will request them that you be added to the ticket for visibility and further input.
1 Like
Hello @pieper,
Thank you for your response. Apologies for the late reply.
The first thing I tried was loading the whole folder, for patient A01 in 3D Slicer to visualize it. But, the transforms were not loading accurately, as in the screenshots.
I am fairly new to DICOM as well, so I read about the tags, what they refer to etc and was trying out an approach and wanted to know if this would be accurate.
I extracted the complete metadata from the dataset onto a file. Then, for patient A01, I extracted FrameofReferenceUID(fixed image) and SeriesInstanceUIDs (fixed image) from the Coregistration file and tried to match the corresponding SOPInstanceUIDs for the moving images that I extracted from the Coreg file as well, compared to that in the metadata file. I was able to find exact number of matches in the metadata file, in the corresponding columns. But, the Coreg file named as PET-CT pointed to multiple CT volumes for both fixed and moving, and no PET volume was referenced.
Therefore, It seems that the references or the folders have not been organised as listed, which is making it difficult to map the volumes.
Please let me know if I shall add you to the mail I have sent to TCIA for this dataset.
@fedorov I have mailed the TCIA helpdesk for this issue, Please let me know how to add you to the loop.
It sounds like getting input from the original submitters of the data will be helpful. Sometimes the deidentification pipeline could introduce ambiguities in the data. It would be great if you could crack the code to make the data useful as intended and post any findings here.
Sure, I am waiting for their response, will post it once I get some information. Thanks so much for the help. 
You can just ask in a comment to the issue to add Andrey Fedorov to the issue. They know me.