- edited description
feature_dicom: Reading of DICOM files and implementation of the CT in BDSIM
The following issue contains relevant material for conversion of CT DICOM images to voxelized geometries into BDSIM.
Comments (7)
-
-
- attached IM-0003-0010.dcm
- attached IM-0003-0008.dcm
- attached IM-0003-0006.dcm
- attached IM-0003-0004.dcm
- attached IM-0003-0003.dcm
- attached IM-0003-0002.dcm
- attached IM-0003-0001.dcm
- attached example.gmad
- attached data.dat
- attached ColourMap.dat
- attached IM-0003-0009.dcm
- attached IM-0003-0007.dcm
- attached IM-0003-0005.dcm
Here are the different input files that allow the example to work
-
- attached bdsim_meeting_29032021.pptx
PowerPoint presentation that was held on 29/03/2021
-
I have edited the branch “feature_dicom” to move the relevant code into bdsim/modules/dicom and edited the cmake appropriately. I also added preprocessor if defs to the component factory so we can build without the dicom module on (controlled by USE_DICOM).
I made some edits to fix header includes and match the code base style as well as put in the various licences we need to have.
I have some concern about the dicom code from the Geant4 example as it has a lot of code smells. Certainly, some basic things can be fixed such as initialising all the class members in the constructor. It seems a little unfinished. Obviously, it works to a degree, but I do think it should be improved if we’re going to use it. Smells: exceptionally large functions; huge level of nested ifs (many inside double for loops), unnecessary level of print out for debug and verbosity.
Todo:
- (Laurie) allow placement anywhere of a bdsim component as opposed to just a piece of GDML
-
Thanks @Laurie Nevay !
I agree that the code needs to be improved and cleaned. Also, your to-do is something that will be really helpful! Maybe it is somehow related to secondary beamlines?
A few other to-dos that I propose:
- @Eliott Ramoisiaux @Nathan Farber I fear that your latest code was not pushed here. Please merge, rebase or cherry-pick your most recent commit on the latest commits on “feature_dicom” from Laurie. We must make sure that your contributions to follow are on top of the changes from Laurie.
- Then we can start cleaning-up the code as suggested in the previous comment.
- @Eliott Ramoisiaux please coordinate with @Laurie Nevay to update the documentation in the branch, document the “USE_DICOM” build variable, etc.
-
I’ve now implemented the placement of a single bdsim component. In the placement you can use the parameter
bdsimElement="nameOfComponent"
to specify the name of a component defined in the input. This can be an active (with field) or passive component all the same. I’ve updated the develop manual also:
http://www.pp.rhul.ac.uk/bdsim/manual-develop/model_customisation.html#placements
@Cédric Hernalsteens Multiple beam lines are actually a bit more difficult. Here, I just clone the container volume and place it at the same place in a parallel world. I have a special navigator class for that world for the global transform of the field. In the case of a real beam line, I use a series of cylinders and also two parallel worlds (one for the bridging components) to ensure an accurate transform at the boundaries. It’s on the todo list. To do this, I’ll have to make the auxiliary navigators be given an ID for which pair of parallel worlds to use for curvilinear transforms. This shouldn’t be too bad. The real work is in making the beam lines connect geometry-wise and also the coordinate systems - see Issue #261 where we’re keeping a list of ‘consequences’ / things to implement.
-
@Laurie Nevay Thanks for the info.
@Eliott Ramoisiaux @Nathan Farber Please follow on my previous comment and make sure to test Laurie’s implementation. This is probably the best way to go for the placement of a “CT”, so the documentation on this new feature should also explicitely mention it.
- Log in to comment