Creating and manipulating voxel phantoms.

HMLTD-09-02

Creating and manipulating voxel phantoms.

by

Gary H. Kramer, Kevin Capello, Albert Chiang and Erick Cardenas-Mendez

Human Monitoring Laboratory Technical Document Radiation Health Assessment Division Radiation Protection Bureau 775 Brookfield Road Ottawa, Ontario K1A 1C1 HMLTD-09-02

HMLTD-09-02 INTRODUCTION The Human Monitoring Laboratory has been using Monte Carlo simulations to investigate performance effects of different parameters for In Vivo counting some many years (Kramer et al 1997). Much of this work has utilised mathematical virtual phantoms (e.g. Snyder et al 1969); however, advances have been made in modelling phantoms so that a detailed human form can be created as the virtual phantom (e.g. Dimbylow 1997) from either Computer Tomographs (CT) or Magnetic Resonance Images (MRI) obtained from instruments in routine use in many hospitals and medical centres in North America. These phantoms are known as voxel phantoms; a voxel is simply a pixel with a given thickness (Mallet et al 1995). Voxel phantoms have been used in many different types of simulation such as X-ray doses (Winslow et al 2004), internal dose assessment (Stabin and Siegel 2003), determining dose conversion factors (Fill et al 2004), and micro-dosimetry (Sastre and Kavet 2002). The Human Monitoring Laboratory has successfully developed a procedure of generating voxel phantoms from CT or MRI images that can either be used immediately for Monte Carlo simulations or may be modified prior to use (i.e., modify organ size, stature etc.). This paper describes that procedure, the equipment, and the in-house code used for some of the manipulations. All codes described below, or phantoms developed by the HML, are available for public use and interested persons are encouraged to contact the HML. METHODS AND MATERIALS Software: The computer code MORITZ (White Rock Science, PO Box 4729, Los Alamos NM 87544 USA) is used to view the input files before Monte Carlo simulations. Monte Carlo N-Particle Transport Code version 5 or System X version 2.6D, known as MCNP5 and MCNPX respectively, (Radiation Safety Information Computational Centre, PO Box 2008, 1 Bethel Valley Road, Oak Ridge, TN 37831-6171) are used to perform the Monte Carlo simulations in the HML. 3D-Doctor v4.0 (Able Software Corp., 5 Apple Tree Lane, Lexington MA 02470 USA) is used to create boundary files and for simple changes to a structure. Rhinoceros v4.0 (McNeel and Associates, 3670 Woodland Park Ave. N, Seattle, WA 98103 USA) is used to edit the three dimensional shapes created by 3D-Doctor. Voxelizer, BoundCreator, LatticeConverter, FcreatDExt, LattEd, FDel were created by the HML using Microsoft Visual Basic for the .NET environment; their functions are described below. SDEF_helper, written in C++, locates voxel in a lattice so that the SDEF card in the Monte Carlo simulator can specify the exact co-ordinates of the source. Hardware: Images (CT, MRI, and bitmaps) are manipulated using a Cintiq Zonx tablet that is an interactive pen display monitor (Wacom Co. Ltd., 2-510-1 Toyonodai Otonemachi, Kita Saitama-gun, Saitama, Japan). It is used primarily to create the boundary files but also to view rendered files. The tablet is connected to a Quad-Core PC desktop. RESULTS AND DISCUSSION -2-

HMLTD-09-02 Voxelizer: this in-house code makes it possible to convert boundary lines and objects created in 3D-Doctor into a repeated-structure voxel phantom for Monte Carlo simulations. This is accomplished by reading the data from 3D-Doctor's exportable boundary file (*.bnd). From this file, Voxelizer counts and reads the names of the 3D-Doctor objects, each of which will correspond to a universe in the lattice structure that forms a portion of the Monte Carlo input file. The boundary file also contains the (x,y) coordinates of every node of every boundary, and the number of the plane where that boundary is located. Voxelizer goes through the node data plane-byplane. For each plane, Voxelizer places the corresponding nodes of that plane on a matrix grid, draws the lines between these nodes to obtain the closed boundaries, and then fills the space between each boundary with the appropriate material. Once this matrix grid has been filled, Voxelizer converts it into lattice code that can be read by the HML’s Monte Carlo simulator, and restarts the whole process for the next plane. Voxelizer has another function which is the boundary creator. When operating in this mode it first creates an empty matrix grid with the dimensions of the phantom's plane (i.e, the same width and length, but no height). It then reads the lattice code from the Monte Carlo input file until that grid is filled (meaning one plane has been read). It will create the node data for a boundary, wherever two different materials touch and creates a grey-scale bitmap of that plane. This process is repeated for each plane. When all planes have been processed, all the node data is gathered together and exported as a boundary file. This boundary file can now be imported into 3D-Doctor. The array size can also be adjusted using Voxelizer. This function combine multiple voxels into a single voxel. While this will reduce the overall array size, it will also reduce the resolution of the final lattice. These functions of Voxelizer, combined together, make it possible to import a voxel phantom into 3D-Doctor, modify it with the various tools supplied in that software, and then export it back into a Monte Carlo input file. It should be noted that once in 3D-Doctor, the voxel phantom can be exported into many different formats for other purposes. BoundCreator: this program analyses a Monte Carlo input file and counts the number of universes, the number of voxels per universe and the array size. It can then make a stack file and bitmap images (in grey scale) of each lattice slice. The is an expansion option that magnifies the voxel from 2 to 5 times. The program can also create 3D-Doctor boundary files that can be overlayed on the bitmap images and edited, if required. LatticeConverter: this program takes a lattice, or semi-repeated structure, and generates a fully repeated structure. The advantage is that the fully repeated structure loads much faster than the other two making multiple runs shorter in their overall processing time. It will also assign a value to Universe 0, if present.

-3-

HMLTD-09-02 FCreatDExt: this program specifically creates an input file for MCP5 or MCNPX. It will set up energy bins, create a batch file to run multiple simulations automatically, rename cells and surface when importing part of one input file from another, extracts a portion of an output file and automatically places the values in an Excel spreadsheet (F8 tally only), and calculate the volume of a cell. The latter is a useful function as MCNP will not also do this, especially if the cell is asymmetric. LattEd: this program consolidates several functions into one interface. It will launch Voxelizer and BoundCreator. Additionally it contains utilities for: formatting an input file (either lattice or repeated structure), replacing a universe with another, reflecting the repeated structure in three dimensional space, splice two universes together, split out a section of a lattice or repeated structure for use in another simulation, and crop the lattice or repeated structure in three dimensional space. FDel: a small utility for automatically deleting either run-time files or output files. Most useful when many simulations are being run to analyses a particular case study. SDEF_helper: an in-house code drastically reduces the run time for a simulation. When the volume of the source in a lattice structure is a very small compared with the entire lattice, it is necessary to specify the location of each source voxel to avoid long run-time or code crashes. During testing it was found the reduce the run-time by as much as a thousand-fold. Creating Virtual Phantoms: Using images from CT, MRI, or generated from Monte Carlo input files, a variety of scenarios can be generated using the same phantom (e.g., a hand with shrapnel in it). The images from from CT scans or MRI scans of humans are in the Digital Imaging and Communications in Medicine (DICOM) format. This standard was created by the National Electrical Manufacturers Association to aid the distribution and viewing of medical images, such as CT scans, MRIs, and ultrasound. DICOM is the most common standard for receiving scans from a hospital. 3D-Doctor can be used to convert DICOM image stacks into virtual phantoms by way of boundaries. The DICOM stack can be loaded into 3D-Doctor, where the user can contour the important features in the images. These boundaries can later be exported and used to make a lattice in a Monte Carlo input file using Voxeliser. Alternatively, one can convert a Monte Carlo input file to a boundary file that can be manipulate by 3D-Doctor. This gives the user the ability to modify and visualize the lattice structure of the a Monte Carlo input file. Voxelizer can be used to create bit map images of the lattice in the same style as the DICOM stack obtained from a CT scan. To bring the MCNP lattice into 3D-Doctor a conversion program must be used. BoundCreator (created by HML) is a program that can make this translation. BoundCreator reads in an MCNP file, makes bitmaps from the MCNP file, by assigning a grayscale intensity to each universe in the lattice, and outputs bitmap images of the lattice and a file containing the boundaries of the different objects readable by 3D-Doctor.

-4-

HMLTD-09-02 3D-Doctor files must be converted into lattices readable by MCNP. To make this conversion another program (Voxelizer) was written in Visual Basic to perform this task. The program uses the 3D-Doctor boundaries (‘.bnd’ file) as the input and creates a ‘.vxl’ file. The ‘.vxl’ file is used as the input to create the MCNP lattice structure. Other information such as the “slice thickness” and the number of “rows and columns” is needed which is provided by 3D-Doctor’s Image Information. 3D-Doctor can modify the lattice structures for later use in an MCNP input file. In 3D-Doctor, new objects can be added and existing objects can be removed or edited; however, one must keep careful track of the boundaries when making changes otherwise the input files will cause code crashes. Using the boundary edit functions in 3D-Doctor the user can modify the cross sections of each object at will. After a modification the three dimensional surface rendering function should be used to see the results of the modification and to check for errors. The disadvantage of 3D-Doctor is that the boundaries being added/modified must be done by hand on each slice, and this is very labour intensive. On the other hand, Rhinoceros eliminates the need to work on each slice as it allows global changes. Before converting a file from 3D-Doctor into a file Rhinoceros that can read, the boundaries must be edited. Some boundaries may not be required in Rhinoceros, so they must be turned off in 3D-Doctor and the user must make sure that the boundaries that are to be edited are turned on. Once the desired boundary set is defined (and visible) the file is rendered. This 3D-Doctor function creates a three dimensional object of the user’s boundary set and this is the object that will be seen in the Rhinoceros. To complete the conversion, the three dimensional object is saved as a wavefront object that can be opened by Rhinoceros. Unlike 3D-Doctor, where the image is modified slice-by-slice, Rhinoceros permits three dimensional modifications. The three dimensional environment of Rhinoceros allows one to instantly see the effect of any modifications. Rhinoceros also gives the user the ability to bend and twist the three dimensional object with ease. One drawback using Rhinoceros is that it is not very intuitive and has a steep learning curve. That being said, it is sometimes simpler to modify a phantom in a slice-by-slice environment using 3D-Doctor instead of in the three dimensional environment offered by Rhinoceros. Modifying a phantom one slice at a time gives the user the utmost control over the final product; however, it can be difficult to visualize the final product using this method. The optimal solution would be to use a three dimensional environment to visually estimate the desired shape of the image and then import it into 3D-Doctor and modify the boundaries as desired. Using this method the user could take advantage of both programs. One can use Rhinoceros to measure distances in free space with ease making it an ideal tool to determine the exact transformation needed to place on a detector or object virtual space. To find the transformation, the user builds a Rhinoceros version of the object to be moved and proceeds to rotate and translates the object (while recording the rotations and translations done) until it is the desired location for the simulation. -5-

HMLTD-09-02 Once an object(s) has been modified in Rhinoceros it can be placed in an MCNP input files via 3D-Doctor. The Rhinoceros object(s) are saved as a ‘.slc’ file with the slice thickness equal to the slice thickness of the corresponding images in 3D-Doctor. When exporting objects in an ‘.slc’, the user must make sure the origin that determines slice direction and thickness corresponds to the origin of the 3D-Doctor images (e.g., the 3D-Doctor origin is the top left hand corner of the top slice). The ‘.slc’ file can be imported into 3D-Doctor as a set of boundaries that can replace the pre-existing boundaries in the 3D-Doctor project file. The modified boundaries are now ready to be converted to an MCNP lattice using any 3D-Doctor conversion method. Procedure: As mentioned above, HML uses either MCNP5 or MCNPX as the Monte Carlo simulator. Using the suite of programs described above the HML’s capabilities are varied. If the data source is an MCNP input file then the first two steps are: • • •

Starting with a Monte Carlo input file that contains a lattice, bitmap images can be created of the slices. The bitmap images can be imported into 3D-Doctor. The process pathway then follows the steps outlined below, starting with the 2nd bullet.

If the data source are DICOM files from CT or MRI images, then the steps to create an MCNP input file are • DICOM files can be imported into 3D-Doctor • Boundaries can be created by hand or interactive segmentation or by automatic segmentation. The latter often involves hand editing as a post-process step. • The boundary files can be exported. • Voxelizer can convert the boundary files into a repeated structure • Other structures can be added to the repeated structure files to create the Monte Carlo input file If the data source are DICOM files from CT or MRI images, then the steps to create and edit a phantom are: • DICOM files can be imported into 3D-Doctor • Boundaries can be created by hand or interactive segmentation or by automatic segmentation. The latter often involves hand editing as a post-process step. • The boundary files can be exported. • The boundary file can be imported into Rhinoceros where the shapes can be edited, deleted, or have new shapes inserted into the structure. • A wavefront file can be exported. • The wavefront file can be imported in 3D-Doctor where it is rendered and checked before the boundary file is exported. At which point the process follows the pathway described above from the 4th bullet. Example 1 (Virtual Hand Simulation): The HML has used 3D-Doctor and Rhinoceros to place -6-

HMLTD-09-02 sources inside a phantom to simulate localised contamination. A small sphere, created from nonuniform rational B-spline (NURBS) surfaces using Rhinoceros, was placed in the phantom’s hand and the distance from the sphere to the skin was measured. This simulated a small piece of contaminated material in the hand as a result of a wound. The source was moved to different distances below the skin to perform an efficiency calibration for this type of wound. Finally the sphere was removed and a gash replaced it to spread the contamination in a more non-uniform manner. Results of this study will be forthcoming, elsewhere. Example 2 (Phantom Modification): The Japanese Atomic Energy Research Institute (JAERI) Torso phantom was recently imaged in a local hospital using one of their CT machines. The phantom was imaged with a variety of overlay plates in different combinations to cover a chest wall thickness range from about 2 cm to 6 cm. Unfortunately, one of the phantom overlay plate combinations was missed: the phantom with the thinnest overlay plate. The phantom was imaged with both the thick and thin overlay plates and so it was possible, using the tools described above, to remove the thick overlay plate and transform the thin overlay plate. It had been placed on top of the phantom and thicker overlay for the actual image. Using the software, it was lowered and curved to exactly reproduce the configuration as if that image had actually been taken. The results are shown in Figs 1 and 2. CONCLUSIONS The HML has purchased and developed a number or utilities that combined, allow it to create, modify, and use voxel phantoms for the study of In Vivo monitoring. The in-house tools described in this paper and the phantoms that have been created using them are all publically available upon request from the corresponding author.

-7-

HMLTD-09-02 REFERENCES Dimbylow PJ. FDTD calculations of the whole-body averaged SAR in an anatomically realistic voxel model of the human body from 1MHz 1 GHz. Phys. Med. Biol. 42: 479-490; 1997. Fill JA, Zankl M, Petoussi-Henss N, Siebert M, Regulla D. Adult female voxel models of different stature and photon conversion coefficients for radiation protection. Health Phys. 86: 253-272; 2004. Kramer GH, Burns LC, and Yiu S. Lung counting: evaluation of uncertainties in lung burden estimation arising from a heterogeneous deposition using Monte Carlo code simulations. Radiat. Prot. Dosim. 74(3): 173-182; 1997. Mallet MW, Hickman DP, Kruchten DA, Poston JW. Development of a method for calibrating In Vivo measurement systems using magnetic resonance imaging and Monte Carlo computations. Health Phys. 68: 773-785; 1995. Sastre A, Kavet R Candidate Sites of Action for Microdosimetry Associated with Exposure to Extremely-Low-Frequency Magnetic Fields, Electric Fields and Contact Currents. Health Phys. 83: 387-394; 2002. Snyder WS, Ford MR, Warner GG, Fisher HL. Estimates of absorbed fractions for monoenergetic photon sources uniformly distributed in various organs of a heterogeneous phantom. J. Nucl. Med. Sup. No. 3: 7-52; 1969. Stabin MG, Siegel JA. Physical models and dose factors for use in internal dose assessment. Health Phys. 85: 294-310; 2003. Winslow M, Huda W, Xu XG, Chao TC, Shi CY, Ogden KM, Scalzetti EM. Use of the VIP-man model to calculate energy imparted and effective dose for X-ray examinations. Health Phys. 86: 174-182; 2004. X5 Monte Carlo Team. MCNP - A general Monte Carlo N-particle Transport Code, Version 5. Los Alamos, NM: Los Alamos National Laboratory; LA-UR-03-1987; 2003.

-8-

HMLTD-09-02 FIGURE CAPTIONS Figure 1

CT image of the JAERI phantom with the thin overlay play stacked on the thicker overlay plate.

Figure 2

Modified version of Fig. 1 where the thicker overlay plate will be removed as shown by the modified boundary line that has been dropped into position, and curved as it would sit on the phantom.

-9-

HMLTD-09-02

-10-

HMLTD-09-02

-11-