Changeset 1337 for trunk/examples/extended/medical/DICOM/README
- Timestamp:
- Sep 30, 2010, 2:47:17 PM (14 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
trunk/examples/extended/medical/DICOM/README
r807 r1337 18 18 19 19 And it has been deeply reviewed by Pedro Arce in December 2007. 20 Very small changes by Stephane Chauvie in January 2008. 21 Stephane Chauvie, Oct 2009: changed Physics list; changes in DICOM read. 22 Stephane Chauvie and Andrea Armando; June 2010 adapted for reading whatever DICOM file 20 23 21 24 … … 30 33 31 34 - A standard Geant4 example GNUmakefile is provided 32 - Compile it with 'make' 35 - Compile it with 'make'/'gmake' 33 36 34 37 ---> 3) Run the example: 35 38 36 - To run the environment variab le G4LEDATA needs to be set, pointing to the low energy data base, G4EMLOW4.339 - To run the environment variabmore le G4LEDATA needs to be set, pointing to the low energy data base 37 40 38 41 - batch mode: … … 41 44 - interactive mode: 42 45 - $G4INSTALL/bin/Linux-g++/dicom 43 the file vis.mac is read in order to visualise the phantom with OpenGL 46 the file vis.mac is read in order to visualise the phantom with OpenGL, DAWN or VRML 44 47 45 48 --->4) Metadata: 46 49 47 50 The file Data.dat has the following information 48 - A line with the compression value (used only to create the .g4dcm , not to read it)51 - A line with the compression value (used only to create the .g4dcm and .g4dcmb, not to read it) 49 52 - A line with the number of files 50 53 - A line for each file name (to these names it will be added the suffix .dcm to read the DICOM files in their original format, and the suffix .g4dcm to read the text files that contain the DICOM information where the Hounsfield numbers have been converted to material and densities) … … 94 97 The file Colormap.dat defines the colour that will be assigned to the voxels of each material. 95 98 96 --->8) DICOM text file format:99 --->8) DICOM file formats: 97 100 98 101 The DICOM files are converted to a simple text format. You may create your own file with the following format (see e.g. 14196616.g4dcm): … … 109 112 As commented before the DICOM files (.dcm) are assumed to describe one Z slice per file, and therefore the GEANT4 text files (.g4dcm) created from them have also one unique Z slice per file. Nevertheless if you create your own .g4dcm file you may include as many Z slices as desired. In any case you have to respect the rule that the Z slices must be contiguous. 110 113 114 The same information is also used to fill a file in binary format, that contains the same information as the text format. Its name ends in .g4dcmb, instead of .g4dcm . 115 111 116 --->9) Choosing different parameterisation/navigation options: 112 117 113 118 There are four possible ways in GEANT4 to treat the navigation in regular voxelised volumes: 114 119 115 - The non-optimised way. It will be very slow because each time a track exits a voxel it has to loop to all other voxels to know which one it may enter116 - The optimisation with G4SmartVoxel: a 3D grid is built, so that the location of voxels is fast, but it requires a lot of memory120 - The 1D optimisation . It will be very slow because each time a track exits a voxel it has to loop to all other voxels to know which one it may enter 121 - The 3D optimisation with G4SmartVoxel: a 3D grid is built, so that the location of voxels is fast, but it requires a lot of memory 117 122 - Using G4NestedParameterisation. The search is done hierarchically in X, Y and Z. It is fast and does not require big memory 118 - Using G4PhantomParameterisation/G4RegularNavigation: an special algorithm to navigate in regular voxelised geometries (see GEANT4 doc). This is the fastest way without any extra memory requirement (and it is the default in this example). It includes an option (default) to skip frontiers between voxels when they have the same material 123 - Using G4PhantomParameterisation/G4RegularNavigation: an special algorithm to navigate in regular voxelised geometries (see GEANT4 doc). This is the fastest way without any extra memory requirement (and it is the default in this example). It includes an option (default) to skip frontiers between voxels when they have the same material. When using this option at each step the energy is all deposited in the last voxel; for properly distribution of the dose (=energy/volume) the G4PSDoseDeposit_RegNav scorer can be used (see below) 119 124 120 125 You can select amont the four options in the following way: … … 138 143 - To use the third option you have to set the enviromental variable DICOM_NESTED_PARAM to 1 139 144 145 146 --->10) Calculating dose in phantom voxels for regular navigation 147 148 As mentioned above the regular navigation has the option to keip voxel frontiers when two voxels share the same material, what can make the CPU time several times smaller. But this option makes that all energy deposited is computed in the last voxel, instead of distributing it along the voxels traversed. To properly calculate the dose in each voxel the G4PSDoseDeposit_RegNav scorer can be used. 149 It takes into account the fact that, when the particle travels through the voxels it looses energy and therefore the energy lost per length (dEdx) is bigger and also the effect of the multiple scattering is bigger. 150 The algorithm to make this correction is an iterative one, as the step length increase due multiple scattering (that converts the geometrical step length in what we will call the true step length) and the energy loss are correlated. 151 It works in the folloing way: first the total true step length is distributed among the voxels proportionally to their geometrical step length; with these values it is calculated one voxel after another the value of dEdx and then the value of the kinetic energy at the entrance of each voxel; with these values it is calculated the geometrical to true step corrections due to multiple scattering for each voxel; finally these new values are used to recalculate the energy lost in each voxel. It has been demonstrated for dose in a water phantom and in a real phantom that the two-step iteration described is enough to reproduce the dose calcualted when no skipping of voxel frontiers is done. 152 153 This scorer is implemented in this examples if the regular navigation option is 154 chosen. It is triggered at the method RegularDicomDetectorConstruction::ConstructPatient() by the call 155 156 SetScorer(voxel_logic); 157 158 --->11) Output 159 dicom.out is produced running th macro file run.mac. It has 2 columns: the first is the number of 160 voxel (ordered in x,y,z) and the second the dose there deposited (in Gy) 161 It is produced, as an example, with a compression value of 32
Note: See TracChangeset
for help on using the changeset viewer.