PROBLEM IMPORTING DICOM FILES (creating ct and cst)

[valentina498]

I have DICOM files BraTS-2021. How can I do DICOM data conversion to matRad custom patient data format (ct and cst)?.
I tried to import these dicom files by MatRad GUI but they are not found in the directory.

How can I do?
Thanks

[wahln]

Correct me if I'm wrong, but Isn't BraTS a MRI dataset?
matRad does not support treatment planning/reading MRIs with the DICOM importer out of the box.
At some point I would like to see the possibility of showing MRI images in matRad (in principle, one could also plan on them with a density override or some form of rSP/rED conversion. @amitantony how about implementing this?

[valentina498]

I'm sorry, I assumed that it was possible.
We have converted the niftii files into dicom (flair and segmentation) but we don't have any useful information to use the matrad code. We also created ContourData (ROI) thanks to segmentations.
Could I send our data here?

Alternatively, could you suggest us a good repository to get useful images for matrad? What data types are certainly supported? (we would need only one glioblastoma patient)

[wahln]

In principle, you can also read in binary data like nifti an create the respective ct & cst structures manually. With this, you could also store an MRI within matRad's ct variable (to get a sensible dose calculation beyond pure visualization, some more tricks would be necessary, but this could be a first step to understand the ct and cst). There is now nifti importer within matRad, but Matlab itself has the function niftiread for importing those images. More information on how ct and cst are defined can be found here: https://github.com/e0404/matRad/wiki/matRad-technical-documentation#s-most-important-matlab-variables

DICOM CTs (instead of MRIs) and RTStructs can usually be read (for example from the cancer imaging archive).

[valentina498]

We modified the ct and cst structures of the BOXPHANTOM.mat based on the geometry of my starting volume(figure 1).
We used the treatment plan suggested in the matRad.m script, but the following error is returned in the dose calculation section: (figure 2)

[wahln]

So matRad uses this as a CT, and has HU of -1000 (air) inside the brain and HU of 0 (water) outside. This may cause problems when matRad tries to find the irradiation geometry and beamlet placement.

Makes more sense to have it the other way round. I would start setting the cube to air of -1000, e.g., ct.cubeHU{1}(:) = -1000;
Then set the structures to water by using the index lists in the cst, e.g. ct.cubeHU{1}(cst{i,4}{1}) = 0;.

[valentina498]

Yes, we had already solved the problem in this way. Thanks

[Fabydan]

Hi there,

Following on from this question - Is there a easy way to change HU/ED values of structures? (For eg. making a target inside lung smaller by removing a shell of tissue (contour algebra can be done outside matRad) and changing densities of structures (like a lung structures higher or lower) and then recalculate based on these changes?

One way I've tried to overcome this is, is to load a CT scan optimise on that CT and then bring in the second CT (with the changes made already to HU) and recompute the dose, but have struggled with this. Is there anything inherently wrong with this workflow?

Thanks

[wahln]

At the moment there is no internal mechanism to do a structure specific density override.
But you still have two options:

1. There is a hidden parameter pln.propDoseCalc.useGivenEqDensityCube with which you can override the rSP/rED used for dose calculation (i.e., it does not automatically run the HU-Lookup). It then uses the exact water-equivalent density cubes stored in ct.cube (instead of always looking up from cubeHU).
2. You can change/add a lookup table to map individual HU to specific densities, and then change your ct.cubeHU to have these exact HU-values in the specific regions.

For 1., a script (after defining pln etc.) could look something like

%% manually call the conversion to water-equivalent densities
ct = matRad_calcWaterEqD(ct, pln); %uses the HU look-up table to create ct.cube

%% Do your magic. For example, here I override the values of the first structure in the cst with water
ct.cube{1}(cst{1,4}{1}) = 1;

%% Now ask the dose calculation to not do the conversion again
pln.propDoseCalc.useGivenEqDensityCube = true;
resultGUI = matRad_calcPhotonDose(...); %or matRad_calcParticleDose(...), whatever you are looking for

Let me know if this doesn't work.

[wahln]

@amitantony a structure specific override could be easily done by allowing a respective struct property in the 5-th cst column. This could be requested in the dose calculation initialization. I would still combine this with a pln.propDoseCalc property to activate the overrides, but should be quite simple. When also allowing this for Monte Carlo, one would need to be able to override with specific materials / their elemental composition as well - this might complicate things. What do you think about an implementation?

[Fabydan]

Thanks for the quick reply - I'll try the solution outlined.

Just a quick question to my last point:
Say I have two dicom CT scans, the second has been modified outside matRad (forced changes to HU values) - They are otherwise identical (same rtStruct etc.) and have both been successfully imported into matRad and visualized.

Is it possible to plan, optimise and calculate the dose on the first scan and then bring in the second CT scan (with modifications to HU made outside matRad) and recalculate the new dose distribution given the previous optimised beam values?

Is there something inherent by loading the seconding CT scan that will break this proposed workflow - or are you aware of a neater way doing something along these lines?

[wahln]

If the second scan has the same properties (resolution / dimensions), this should be no issue. If these are different, it might get a little fishy to align the scans / coordinate systems properly.

But in general, you can just create a second variable, say, ct2, and pass these to the functions instead of ct. The standard variable names are only important if you use the GUI (because it looks for those names in the workspace).

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically closed because it has not seen any activity in four weeks. This happens usually when the issue has already been solved or it is no longer relevant. If that's not the case, feel free to reopen the issue.