Application of deformation field not doing anything

Hello, I am trying to apply a deformation field to a volume using the BRAINS resample image module but it ends up not doing anything and I am not sure why. Some context is needed:

We are looking at the AAPM TG-132 report and assessing the deformation algorithms at our center compared to gold standard data. As part of this, we are provided a volume, the deformed volume, and the deformation field that was used. I have attached the original dataset. The other dataset can be downloaded here: https://www.dropbox.com/s/jnyydbcie9bg9fu/TG132P2-1-1%20-%20Dataset%201%20deformed.zip?dl=0

The dropbox download contains the deformed image as well as 2 registration dicoms. It is unclear to me why there are two but I tried with both.

In any case my process was as follows:

  1. Import the Original dicom, the deformed dicom, and the 2 registrations
  2. Use the BRAINS resample image to apply the transform with the original image as input, a new volume as output, and either of the registrations as the transform
  3. Compare the new image and the original image.

Output: They are the same volume with no deformations.

I am wondering if I am running into a memory issue as I am running this on a fairly limited machine. I just didn’t expect it to return a volume in which nothing occurred and no error messages were specified. I also attempted the following:

in the python module in slicer I ran the following commands:
import slicer.util
voxelarray = array(‘SpatialRe’)
print(voxelarray)

which returned None (i.e., the spatial registration is empty?).

I also imported the registration in Matlab and looked at the vector grid header which contains the transform and it was not empty as far as I could tell.

Any help would be great, thanks

Just curious if there is any additional information I could supply to help resolve this issue. Still stuck on it.

It is quite possible that you are not successfully reading deformation fields correctly into Slicer. My cursory examination result in quite a bit of dicom errors importing those two deformation fields into Slicer.

Here are the error logs by the DICOMBrowser, after it asked me to install RT extension.

Warning: Warning: 1811 of 1811 selected files listed in the database cannot be found on disk.

See python console for error message.

W: DcmItem: Dataset not in ascending tag order, at element (0064,0005)

W: DcmItem: Dataset not in ascending tag order, at element (0064,0005)

W: DcmItem: Dataset not in ascending tag order, at element (0064,0005)

W: DcmItem: Dataset not in ascending tag order, at element (0064,0005)

W: DcmItem: Dataset not in ascending tag order, at element (0064,0005)

W: DcmItem: Dataset not in ascending tag order, at element (0064,0005)

MultiVolumeImportPlugin::examine

DICOMMultiVolumePlugin found 0 multivolumes!

MultiVolumeImportPlugin::examine

DICOMMultiVolumePlugin found 0 multivolumes!

MultiVolumeImportPlugin:examineMultiseries

DICOMMultiVolumePlugin found 0 multivolumes!

W: DcmItem: Dataset not in ascending tag order, at element (0064,0005)

Failed to load DICOM registration object from file C:/Users/murat/Downloads/TG132P2-1-1 - Dataset 1 deformed/REG_ImSimQA_20180713.123805.935322.dcm

Could not load: 1: SpatialReg [1] as a REG

Could not load: 1: SpatialReg [1] as a REG

W: DcmItem: Dataset not in ascending tag order, at element (0064,0005)

Failed to load DICOM registration object from file C:/Users/murat/Downloads/TG132P2-1-1 - Dataset 1 deformed/REG_ImSimQA_20180713.123759.932340.dcm

Could not load: 1: SpatialReg [1] as a REG

Could not load: 1: SpatialReg [1] as a REG

I had forgotten about the error window and see that now. I am not sure what this error means… Does it mean that the file itself is an improperly formed dicom? I think I’ll try and re-create it in matlab as the data loads fine there

For anyone in the future, note that this is a significant problem with the TG-132 Registration files as supplied. I am not sure what is exactly the issues but it looks like in generating the header data, something went amiss.

To fix this problem, I created a registration between the two datasets, exported this to DICOM and then used pydicom to replace the “DeformableRegistrationSequence” in the created registration file with the TG-132 header information. With this, I was able to load this into 3DSlicer. Even still, I think these deformation fields are not correct but that is a problem with the dataset not slicer.

What software was used to create the REG_ImSimQA_20180713.123759.932340.dcm and REG_ImSimQA_20180713.123805.935322.dcm files in the zip package?

What software did you use for this?

It was the ImSimQA software, I imagine an early version of it. The software package is not free and I am trying to get details on what the problem is. Apparently I am not the only one who has had issues with it including MIMSoftware as well as other authors (see https://doi.org/10.1002/acm2.12348)

I used python with Pydicom. It took about 5 lines to do it this way (just replaced the entire Deformable Registration Sequence field of a dummy dicom with the ImSimQA).

Even with the above, the deformation field doesn’t seem correct. It does not warp the “base” image into the deformed image when using slicer. Even further, while slicer will load this deformation, MIM still won’t (but may be related to memory allocation in settings which I cannot change).

I’ve checked REG_ImSimQA_20180713.123759.932340.dcm and REG_ImSimQA_20180713.123805.935322.dcm and they are invalid: SOPClassUID is set to SpatialRegistrationStorage but the stored registration is a DeformableRegistrationSequence. For grid transforms, the correct SOPClassUID is DeformableSpatialRegistrationStorage. It is a shame that commercial software developers don’t test their product diligently, as it puts other software developers into a difficult position: Should we add a workaround that allows loading this invalid file, making our code less safe and more complicated? Or keep out software correct and risk losing users because it “does not work” (cannot load a file that other software can load).

Another issue with the file that it stores displacement for every voxel. Since displacement field is smooth, it should be enough to store a vector for every 5th or 10th voxel in the image plane, reducing the image size by a factor of 25x-100x.

I have made SRO reader in SlicerRT more robust (maybe we will even temporarily enable loading of these invalid files). These changes will be available in the Preview Release within a few days.

1 Like

Performance and robustness fixes are integrated (will be available in Slicer preview Release from tomorrow). Workaround to enable loading of invalid ImSimQA images is being discussed here: https://github.com/SlicerRt/SlicerRT/pull/154

Thank you Andras for going into this - it is really helpful. I am really unsure how this “standard” dataset could be so poorly formed - as I mentioned there are other issues with it.

Thanks again

Hi Andras,

I tried downloading the Nightly (17/9/2020) and importing the registration file with SlicerRT installed and it still fails to load. I get the following messages:

Could not load: 1: SpatialReg [1] as a REG
W: DcmItem: Dataset not in ascending tag order, at element (0064,0005)
Warning: In D:\D\P\S-0-E-b\SlicerRT\DicomSroImportExport\Logic\vtkSlicerDicomSroReader.cxx, line 224
vtkSlicerDicomSroReader (0000021E73EC34C0): vtkSlicerDicomS…
Failed to load DICOM registration object from file [removed by mmtg]\REG_ImSimQA_20180713.123759.9323…
Could not load: 1: SpatialReg [1] as a REG

Not sure if I did something wrong.

The workaround that allowed loading of invalid registration objects created by ImSimQA was not integrated yet. I’ve merged it now, so tomorrow’s Slicer Preview Release will accept these files.