CT brush and CancerZap!: two video games for computed tomography dose minimization

Background X-ray dose from computed tomography (CT) scanners has become a significant public health concern. All CT scanners spray x-ray photons across a patient, including those using compressive sensing algorithms. New technologies make it possible to aim x-ray beams where they are most needed to form a diagnostic or screening image. We have designed a computer game, CT Brush, that takes advantage of this new flexibility. It uses a standard MART algorithm (Multiplicative Algebraic Reconstruction Technique), but with a user defined dynamically selected subset of the rays. The image appears as the player moves the CT brush over an initially blank scene, with dose accumulating with every “mouse down” move. The goal is to find the “tumor” with as few moves (least dose) as possible. Results We have successfully implemented CT Brush in Java and made it available publicly, requesting crowdsourced feedback on improving the open source code. With this experience, we also outline a “shoot ‘em up game” CancerZap! for photon limited CT. Conclusions We anticipate that human computing games like these, analyzed by methods similar to those used to understand eye tracking, will lead to new object dependent CT algorithms that will require significantly less dose than object independent nonlinear and compressive sensing algorithms that depend on sprayed photons. Preliminary results suggest substantial dose reduction is achievable. Electronic supplementary material The online version of this article (doi:10.1186/s12976-015-0003-4) contains supplementary material, which is available to authorized users.

good or bad. Such games are an amalgam of the Where's Waldo books [8,9] and the Battleship game [10][11][12][13][14]. Thus, CT Brush is a "puzzle game" and CancerZap! is a "first person shooter" game [15]. A form of the latter game, CancerZap!, has already found its way into XLCT (X-ray Luminescence CT) software for sparse molecular images [16] based on our previous suggestions [17]. A more general CancerZap! game is outlined here, but has not yet been implemented.
In both games, as in golf, "the goal is to play as few strokes per round as possible" [18]; or, in other words, the purpose of the game is to find the tumors with as low an x-ray dose (the game score) as possible. Both games mimic standard absorption/scattering x-ray imaging, but should be modifiable to create games that use x-ray phase contrast imaging, which promises substantial x-ray dose reduction in itself [19][20][21].
In medicine we calculate computed tomography images to detect problems inside patients. While these scanners work, they do so at high x-ray dose, and the controversy over this cumulative dose to the population, 49% of the per capita dose in the USA [49], is hindering wider use of CT. There have been many algorithmic approaches to dose reduction [50][51][52][53], but in our opinion much further dose reduction should be possible. This is especially the case for our long term goal, which is the detection of premetastasis breast and other tumors [17]. We found that detection of 2 to 4 mm diameter premetastasis breast tumors, followed by their destruction, should lead to a greater than 99% cure rate [54]. Others subsequently estimated this target at 2.7 mm [55]. Our focus here is, then, on the detection of small tumors, rather than the quality of the general CT diagnostic image. The reduced resolution of iterative CT algorithms as dose is reduced [56] could be offset if the x-rays were directed more to the tumors being sought, as we propose here.

A 2D version of the CT brush
Please see Additional files 1, 2, and 3, which contain a binary JAR, the source code, and the documentation, respectively.
The simplest brush tool is the eraser, which has a given size and shape, and sets all pixels it encounters to zero as it is moved via mouse, joystick or track pad by the player [57]. The drawing brush tool likewise fills in a swath of pixels with a given value, design or color. Other tools have more subtle effects, such as "healing" (removing scratches, etc.), creating gradients, blurring edges or making smoke patterns as the tool moves. These tools can be used to create a digital painting from scratch, guided by the mind of the artist.
A CT brush consists of a "star" pattern of x-ray beams (rays) through a given point in the patient (Figures 1, 2 and 3). The point at which all beams in the brush intersect is called the "central point". As the brush moves, both the central point and all of the star lines through it are processed. The simplest design is to have a set of fixed, intersecting beams and move them from point to point within the patient, perhaps turning them on and off as we go. This would allow us to control the dose. This could be implemented in hardware using modern x-ray arrays, perhaps using Wolter lenses [58]. Note that while we are confining CT Brush to 2D images, it could readily be generalized to 3D, with, in general, a sharper point spread function for the images [17,59]. However, it would best be driven by a 3D joystick [60] and the images displayed in 3D.
Dose is controlled by two factors: the number of rays involved in the star of the CT brush, and by the motion of the brush when the player holds the mouse button down. As the player moves the CT brush with the mouse button down, all points along the rays of the star-brush receive radiation, i.e., all of those rays are labeled as "selected". However, to minimize redundant dose, we do not count selected rays twice. This is because the value of a given projection in this game is static, and so reprojecting a ray will not yield any increase in image quality for the player. The player can see this effect, because all of the projection lines in the star, which have not yet been irradiated, will Figure 1 The welcoming messages and initially uniform image in the CT Brush game. Buttons are available on screen to the player for increasing or decreasing the number of rays (n) or the width of the rays (w) at any time during play. "New" starts a new game. "Refine" allows the user to run the iterative CT algorithm (MART) to convergence. This does not add any dose. The rays are initially all green, meaning no dose has yet been applied along them.

Figure 2
On hitting the "Finish" button, the player is asked to state how many gray circles have been found. Here play was terminated early, and a wrong guess was made. Note that some of the rays are red, meaning that they have been used before, and are therefore not adding to the dose. The dose used so far is reported continuously on the bottom, along with the current number of rays and ray width. A correct guess advances one to the next level of difficulty. Here the image size is 256 x 256 pixels.

Figure 3
Left: This depicts the star-brush in the CT Brush game, as seen by a player, after playing a while on a 256x256 pixels canvas. Both real objects and artifacts appear in the image, but the player does not know which are which. The red lines represent selected rays (i.e., rays which have already been irradiated and analyzed), while the green lines represent available, unselected rays. These lines are shown dynamically as the player moves the brush. If the mouse button is down, the green rays become selected, turn red, and the dose is increased. Early in the game, one is playing "blind". Middle: further use of the CT brush starts to bring out more of the structure of the hidden image, and (what will later prove to be) artifacts decrease. Right: refinement of the image by further play clearly brings out the gray circle, which represents a possible tumor. The player might decide to stop at this point and report the apparent count of tumors. be displayed as green; meanwhile, any projection lines in the star of the CT brush, which have already been irradiated, will be displayed as red. Green means "available for selection" and red means "already selected". Thus the player is prevented from adding dose that could not improve the image. Again, this protection from extra dose when a ray is selected twice could be implemented in computer driven x-ray hardware.
If the player has a mouse with a wheel, the number of rays can be increased or decreased by turning it. Otherwise there are screen buttons for increasing/decreasing the number of rays. Screen buttons are also provided for increasing/decreasing the brush width. The dose per star increases in proportion to both its number of rays and its ray width. No detail is lost, since the rays that are bundled in a wide brush are calculated separately. In the current implementation, the views are equally spaced all the way around. Options could be added for limited angle range [30,[61][62][63][64][65][66][67][68][69][70][71][72] and for rotating the CT brush, thereby generating a fresh set of rays, despite using the same number of views in the star.
Using the CT brush, the player can select which subset of all possible rays across the image to use for the MART algorithm. As the player brushes the hidden image, a "canvas image" is generated. This canvas image is constructed using all of the ray sum values from the rays selected thus far as the brush was moved. Therefore, the maximum dose occurs if the player brushes all points in the canvas, with 180 rays in the star (the maximum number of rays we have allowed in the computer program, each line representing one degree around the central point). In other words, an image produced this way would be equivalent to an image made using 180 projected, parallel views equally spaced by 1 degree, and the same CT algorithm. In summary, the user of CT Brush is selecting a subset of all possible rays. The smaller that subset, the lower the dose.
The CT brush, while having a focal point (the "central point"), extends across the whole image, because each ray enters and exits at edges of the image (Figure 1, 2, and 3). Therefore, as the brush is moved with the mouse down, data is acquired for every pixel in the hidden image that is intersected by the brush's star pattern. The trajectory of the central point is tracked for later analysis. The raysum data is accumulated over time; so, as the CT brush is moved, all points in the canvas image (i.e. the patient), touched by any ray in the brush, may be updated to new values. These effects will fall off as the distance from the current location of the central point of the CT brush increases [73].
The CT algorithm we used, MART, is iterative and ray based. Because the program's algorithms have to be run in real-time on consumer personal computers, some compromises were necessary, such as only doing refinement iterations when the player clicks the "refine" button. Refining does not increase dose. The pattern of use of the refine button is recorded using the tracking feature, permitting its later automation.

CT brush playing levels
To facilitate unlimited playability, the CT Brush game generates levels for the player to solve. Each "level" (i.e. level of difficulty) in the CT Brush game corresponds to a hidden image comprised of gray and whole-tone (either white or black, depending on the background color) objects. As the user progresses, he or she may access canvases that are larger in height or width (or both), by up to 128 pixels per 5 levels. These larger canvases will appear randomly. Because the maximum number of objects is calculated randomly based on the dimension of the canvas, larger hidden images will generally be more complex. In addition, beyond level 8, there is a 1/6 chance for the grayscale of a level being inverted. The number of shapes per level is calculated by: mindim/64 + random((mindim/11) -(mindim/64))where mindim = the minimum dimension (height or width) in pixels. The reason higher levels are generally (but not always) harder is because the larger the image sizes available, the more likely the user is going to have a larger image. The randomness also provides the user with the occasional easy level.
The goal of each level in the game is to find the number of gray circles in the hidden image ( Figure 3). Each gray circle in the image represents a tumor in a patient. All objects in the hidden image vary in size, shape and quantity. The two possible shapes are circle and triangle; the quantity and size of each object is proportional to the size of the canvas. Every time the player successfully deduces the correct number of the gray circles in a level, they progress to the next level. As the player progresses, the general difficulty of the program should increase. However, if the player fails to identify the correct number of gray circles in the image, they are returned to a lower level.
By default, the background color is black; however, once the player reaches level 8, all levels ending with the digit 8 are "inverted" (i.e. a white background with black wholetone objects). Additionally, past level 8, there is a 1/6 chance that any level can be inverted.
To further vary the difficulty of each level, we alter the number of pixels in the hidden image. Each dimension (height and width) of the hidden image is calculated/ generated separately. The base size of the canvas is 256x256. Each dimension can be randomly increased by 128 pixels for every 5 levels. For example, at levels 5-9, the possible canvas sizes are: 256x256, 256x384, 384x256, and 384x384, and at levels 10-14 the possible canvas sizes are: 256x256, 256x384, 256x512, 384x256, 384x384, 384x512, 512x256, 512x384, and 512x512. In addition, because the number of objects is influenced by the size of canvas (via a random number generator), larger canvases may contain more objects to find.
While the number of levels currently possible is over 2 million (2 32 -1), most players will likely lose, give up, or get bored or die before they reach this level. Additionally, the practical limit of the game depends on the speed and memory of the computer the player is playing on. The code has been optimized to try to minimize the demand on the CPU, as the CPU speed seemed to be the weakest link in most situations.
Variations could be readily incorporated in the program. For example, the hidden image could be a real CT slice with real or simulated tumors in it.

Analysis/purpose of CT brush gameplay
The CT Brush game has a tracking feature, which causes the program to pipe specific data to a TCP/IP connection [74]. The data tracked is comprised of: the current level the player is working on, the hidden image for that given level, and the player's brush movements and refine requests. This data may be analyzed later to deduce patterns in the user's approach, which could help improve CT algorithm design. We thus hope to find strategies which hone in on features of the image that result in a more doseefficient detection of tumors. If any of the player strategies could be ascertained and formalized into a computer algorithm, then CT Brush algorithms could be automated and used to run hardware CT scanners. An automated CT Brush is, in effect, an intelligent flying spot 3D CT [17,75].
Thus, the advantage of CT Brush is that it allows us to explore inside a patient, attempting to hone in on the image information, while trying to keep total x-ray dose to a minimum, perhaps at substantially less than the dose of shotgun CT imaging. An analogy can be made to eye tracking of radiologists, in which the direction of their gaze is recorded [76][77][78]. The difference here is that the image data is acquired as the gaze is changed. In fact, eye tracking glasses or computer cameras [79] could be used to run the CT brush.
As a step towards analysis of players' actions, we may consider a process analogous to eye tracking of a scene, such as the study depicted in Figure 4. The main difference is that the scene is initially invisible (Figure 1). The hand/eye tracking by the user for the game played in Figure 3 is shown in Figure 5. This visual approach may permit us to use methods developed in studies of visual behavior [78,[80][81][82][83] to learn what the player pays attention to as he/she reconstructs the scene, such as in the construction of a "story board" from gaze tracking [84][85][86]. It is plausible that displaying the history of her/his hand/eye tracking might aid a player in deciding on future moves. This feedback, an on the fly version of the hand/eye tracking as in Figure 5 Right, could readily be added to the CT Brush game.

CT brush mathematics
Any CT reconstruction is generally one possible solution to the equations describing the relationship between raysums and the pixels or voxels of the image. Even with cross sectional images in 2D we are dealing with a slab of voxels. So, in this section of the manuscript, we will always refer to the image elements as voxels rather than pixels. The generalization from 2D to 3D is then conceptually straightforward. As we usually deal with many more unknowns (voxels) than measurements (raysums), there is a whole hyperspace of possible solutions. Most CT algorithms generate a single reconstruction from this vast array of possibilities. Figure 4 An eye tracking experiment by Alfred L. Yarbus [150] in which the eye movements have been superimposed [84] on a painting "Unexpected Visitors" by the 19th Century Russian artist Ilya Repin. The eye tracking is easier to appreciate if the two images are viewed as a stereo pair [151]. Figure 5 Middle and Right may also be viewed in stereo.
In previous work we showed how one could take an intelligent "walk" in the space of solutions, and explore for the existence of substantially different solutions to the same CT equations [73]. This "walk" was a "clunky" approach, in that one had to design "objects" to be added to the image, or subtract objects in the image, and then let convergence of the iterative equations take one back to the solution hyperspace. The CT brush is much easier to use as an exploratory tool. Pointing at and brushing over an area of possible interest is a much more natural operation. A given area can be "scrubbed" with a CT brush until it is apparent that something interesting lies there or not. If an edge shows up, the brush can be moved along the edge, to follow its trajectory in the image. If the brush width is varied, the operation can be sped up with a wider brush, or small details can be tested by using a finer brush.
To simulate this process in 2D, we begin with a square image U(i,j),i,j = 1,…,N which is stored in the computer, but is not seen by the player ("hidden" or "unknown" to the player). This could represent a cross section of a patient. The image is kept hidden from the player, because in real life we would not have that image, and we would have to decide how to collect the data to get just enough image detail to decide on tumor detection.
We approximate the R rays through a point in the image by a binary (0 or 1 valued) mask M(k,l,r),k,l = −N,,,N;r = 1,…,R. The dimensions of M are chosen so that if its center at (k,l) = (0,0) is placed over any voxel (a,b) in U, the mask will completely cover U. M is actually a stack of R masks, one for each ray r, because separate data is available for each ray traversing the image. Mathematically, by using a binary mask we avoid the problem and the computing time of calculating the "weight" to be assigned to each pixel in a given ray [31]. In the software, however, we used a staircase function, representing a binary ray-line (i.e., it is not anti-aliased), so that is not actually stored. The mask summed over its rays is in effect a thresholded version of the point spread function of an ART-type CT algorithm [63,65,67].
The raysum for a given ray r through point (a,b) in U may now be written as: Figure 5 Left: Same picture as Figure 3 Left (except that the game has been played a bit further), showing the reconstruction at this early stage of the game, without the star of rays. Middle: The hidden image containing one target "tumor" (gray circle) and the cluttering objects near and far. This image was hidden from the player during gameplay. Right: The track of the central-points used in the game by the player, superimposed on the hidden image, which the player couldn't see. The long straight lines are hand/eye movements that were straightened by the mouse interpolation algorithm. While the image on the left includes the target, it does not accurately reconstruct any of the objects, and some artifacts appear that are comparable to the real objects. As play continues, these artifacts can be seen to have disappeared ( Figure 3, Middle and Right), perhaps because the player paid some attention to them (Right).
This formulation allows M to represent any kind of ray, including parallel, diverging fan or cone beam, or converging [17,87]. We are assuming that the rays available from the x-ray sources come in parallel bundles with uniform properties, so that the same mask M may be used for all voxels. Put another way, M is translationally symmetric, i.e., spatially homogeneous. Any (x,y,z) mechanical scan mode would fit these constraints; however, these constraints could be lifted.
We start with an initial image A 0 (a,b) = 1;a,b = 1,…,N, which would typically be a uniform image. Each time a ray is processed, or some other image processing operation is performed, we increment the index on A. The general gameplay would consist of "mouse down", drag, and then "mouse up", resulting in a sequence of voxels (a i ,b i ),i = 1,…,m representing the central points of the CT brush stars by which the player irradiated the image. These voxels are recorded via the tracking system. If the player puts the mouse down with a canvas image A s , then the sequence of images up to A s+m would be generated and displayed.
Since we are dealing with the rays one by one, we may use the general ART-type [30] computed tomography algorithm. The specific algorithm used to adjust the values of the pixels along a ray may be additive ART [30], multiplicative ART (MART) [30,[88][89][90][91], streak suppression ART [39], or any other variant on this theme. In our implementation of 2D CT Brush, we used MART, and considered each previously unused ray of the CT brush in a clockwise order from horizontal: 1. Calculate the raysum for the ray (a,b,r) by traversing the hidden image U: 2. Calculate the current estimate of the raysum for the ray (a,b,r) by traversing the current estimate for the image A i : 3. Find new values for each voxel in the ray, represented by M(a-k,b-l,r)=1, such that: S i + 1 (a, b, r) = S(a, b, r). This step may be done differently based on the flavor of ART. In our implementation, multiplicative ART (MART) was used. Therefore, we used the formula: 4. When the values of voxels along a ray are changed, so are the raysums for all of the previously used rays that intersect the voxel. Therefore, at each step, or periodically, the previously used rays would also need to be adjusted per the CT algorithm. Such adjustments can be made iteratively until a convergence criterion is satisfied. With all these voxels updated, we have the next image A i+1 . Clicking the "Refine" button will perform one iteration of refinement, in our program. Thus, we track the number of refinements the player uses. The player sees the results of each iteration, and can judge if further iterations are warranted.
Since the MART algorithm always leaves a raysum of zero as zero (Equation 4), the initial image, while uniform, should not contain zeros in the region of interest. Thus we set A 0 (a, b) = 1 ∀ (a, b). All of the equations in this section are implemented in the Java method do_projection, which is located in the file path src/org/alvaregordon/ ctbrush/GFXMath.java in the appended software.

Estimation of the reduction in dose with CT brush
For visual comparison of Figures 3 and 5 with "traditional" CT algorithms and use of rays, in Figure 6 we show the reconstruction of the image ( Figure 5 Middle) that was unknown to the player, as reconstructed by MART with increasing numbers of parallel projections equally spaced in angle. In Figure 7 we show line profiles [104], which give another visual comparison.
For dose comparison, we need to find a common basis for comparing the irregular usage of rays in CT Brush with traditional MART. While, of course, absorbed dose is most important to patients, that is an object dependent measure. We thus decided to use a simpler parameter, i.e., the number of unique rays. Since in CT Brush each Figure 6 A sequence of MART reconstructions of Figure 5 Middle, with increasing numbers of views: 5, 6, 9, 18, 36, and 72, equally spaced in angle. These were generated by using the CT Brush code, looping the central-point of the CT brush through all of the pixels (each initially set to 1), and refining until convergence. Such "traditional" CT images provide a visual comparison with the player driven, object dependent CT Brush reconstructions in Figure 3. Of course they have more uniform spatial resolution, as the point spread function is approximately spatially homogeneous [63,65,67]. distinct ray is used only once, corresponding to pointing an x-ray microbeam in a given direction, this count would seem to be a good measure of the total emitted dose the patient is subjected to (Table 1).
However, two problems became apparent. As shown in Figure 8, if the star angles have rational tangents, many rays overlap, and since each should not be counted more than once, this leads to a difficult counting problem. On the other hand, if we deliberately use star angles with irrational tangents, the overlap problem is reduced or eliminated (Figure 9), and we obtain:  Table 1 Comparison of the relative emitted dose for all of the standard CT images generated in Figure 6 compared to the manual CT Brush play of Figure 3 Right All of these angles have irrational tangents. The stars used here all include the 0°ray, whose tangent is rational, so that Equation 5 is used for T. Figure 8 The problem of counting the unique rays for a given number of views is illustrated here on an N × N = 4 × 4 picture with R = 4 views with rational tangents. We were able to place only 3 stars so that none of their rays overlapped. Their centers are shown as red circles and their unique rays as dashed lines.
The missing rays are drawn as solid green lines. For the 16 pixels shown here, the total number of unique rays is therefore T = 3R + 8 = 20. This is substantially less than T = RN 2 = 4 × 16 = 64. Thus 31.25% of the possible rays with this star are unique.

Figure 9
Here we show all of the stars through all 16 pixels of the same array as Figure 8, but with 5 evenly spaced views for which the tangent is irrational, except for 0°. The total number of unique rays is thus 68. With a slight rotation all of the rays could have irrational tangents, raising the number of unique rays to T = MN 2 = 5 × 16 = 80. Thus 85% of the possible rays with this star are unique, and with the rotation this would rise to 100%. Of course, with truncation of rays to staircase functions, as we have done for the sake of computational speed, many of the otherwise distinct rays end up with the same staircase function. This would not be the case if weights between 0 and 1, rather than 0 or 1 only, were used [31].
The negative term is due to the 0°ray, whose tangent is rational. With a slight rotation of all the angles, their tangents could all be irrational, so that: The number of unique rays far exceeds what is reasonable for a digitized picture because we represent each ray by a staircase function, and many rays will have the same or very similar staircase approximations. However, since we used stars going through every pixel to emulate the standard MART algorithm, we indeed used the whole set of these staircase functions M, so the result is better than we might otherwise anticipate from MART. Furthermore, here we are using pseudoprojections [94,105,106], i.e., raysums calculated from an already digitized image U, which make a small difference from real world data.
Another way to estimate the number of rays is to pretend that all of them at a given angle are equally spaced, with a width equal to the pixel width. These are not the rays used by CT Brush. While this would be the ordinary way of coding MART, it in general involves specifying weights [31], and thus comparison with CT Brush as implemented here would be problematic. A bit of trigonometry shows that for rays at angle θ the number of rays intersecting an N × N square is: and the emitted dose becomes: Figure 3 Right was reconstructed by playing CT Brush accumulating 2,126 rays, as calculated by the method shown in Figure 8. In retrospect the user started with 3 views, then refined with 4, 5 and 8 views, a mixture of angles with irrational and rational tangents. We can see in Table 1 that the bounds formed by E and T compared to this single example of CT Brush play are not tight, but do suggest that substantial dose reduction is achievable via human computing.

Mouse interpolation
On the computer we used (2008 Apple MacPro -Two Quad-Core 2.8 GHz Intel Xeon Processors, 20GB RAM, ATI Radeon HD 2600XT Graphics Card, and OS X 10.6.3 Server), we measured the mouse sampling rate as one sample per 16.5 msec. This meant that pixel locations, read via the mouse, would not be consecutive neighbors. Thus, mouse interpolation was required. For this, we used linear interpolation [107].
CancerZap!, a first person shooter game CT Brush proved a bit too abstract for children, inspiring us to think about an alternative, shoot 'em up game. This would differ from CT Brush in the following aspects: 1. What is seen in the front of the screen is a machine gun pointing away that shoots lots of individual x-ray photons ( Figure 10). 2. The gun swivels, so that it is creating, in effect, a fan beam. 3. The good and bad guys (normal and tumor tissues) are represented by lively action figures standing on a platform, so there is a 3D scene to shoot at. 4. The platform keeps rotating like a merry-go-round, though perhaps reversing and changing speed at random, providing moving targets, even though the action figures don't move across the platform. This simulates multiple views. 5. The player has to identify which figures are the bad guys. They might grimace, wear weird clothes, collapse dead when shot too much, revealing their identification, etc. 6. The image being reconstructed is in some way a vertical projection of the action figures onto the platform.

Results and discussion
Our purpose here is to place the CT Brush game into the public domain, so that experimentation can begin in developing object dependent strategies for x-ray dose reduction in CT. Various problems in science are being solved via crowdsourcing by taking advantage of human intuition [116][117][118][119][120][121][122][123][124][125][126]. Some of these are games that are explicitly used in "human computing" for labelling images [127] or finding objects in images (that are not hidden from the player, as here) [128]. We anticipate feedback well beyond our own limited imaginations, regarding this as a communal effort. By making it fun and straightforward, we hope that all kinds of people, lay to professionals, will contribute to the goal of x-ray CT dose reduction.
Our hope is that a combination of fun and altruism will draw people in to play the game. We collected some qualitative responses from a small group, prior to Figure 10 A mockup of what the screen might look like in a CancerZap! video game. The player shoots x-ray photons at a scene that is rotating, with one object (the Martian eye [152]) in this case representing the "bad guy" tumor. The gun's lateral motion would correspond to a fan beam. As in CT Brush, the objects would only become visible as they were shot at, accumulating x-ray dose. In the plane, the ornate figures would be represented by simpler "footprints", such as triangles and circles, shown here beneath them.
writing the article, and the consensus was that the game was fun to play. We hope this enjoyment will scale well to a larger audience. We also hope that an altruistic attitude towards advancing science will draw some people towards playing the game. In addition, because the program is open-source, we welcome other developers to modify our source code and create fun game "mods".

Future improvements
CT Brush is available online, with open code, permitting its further development [129], and we hope to get feedback from readers and players. Here are some examples for improvement of the CT Brush game: 1. The CT brush could be used sparingly, by reducing its x-ray intensity, thus permitting a rough sketch of the patient at low dose, analogous to a scout scan [130]. This would, of course, have to be a noisy image, but if any feature caught the eye, it could be run over again with the CT brush set to a higher intensity. A suspect region would then be sharpened up, or, alternatively, smoothed out, depending on whether the apparent feature was really present or just due to noise fluctuations. 2. Different weights could be assigned to rays in different directions, to allow following of edges, etc. The direction of mouse movement could be used to automatically adjust these weights. This approximates linear receptive fields in vision [131,132]. 3. Rays could be anti-aliased. 4. CT Brush could be implemented with consideration of the order in which rays are analyzed: ART algorithms converge most rapidly if the rays are considered in a particular order, where consecutively processed rays are as close to mutually perpendicular as possible [133]. The primary impact of this would be to reduce the number of Refine steps to convergence. 5. Local dose could be kept under a given maximum, to avoid radiation burning, by locking out rays that would cause the maximum to be crossed. Regions in which the local dose had reached its maximum could be displayed to the player. 6. A palette of image processing operations [134] could be made available that could, for instance, sharpen or smooth the image, apply various norms [135], create pseudocolors, round up localized pixels into compact structures, apply histogram equalization, fit models to the image [136,137], sketch in guesses for tumors based on hints in the image at a given stage, erase suspected artifacts, etc. [73]. By hitting "Refine" a few times, the altered image would be made consistent with the raysum data. This involves no cost in dose, yet allows the player to bring in many kinds of a priori information. 7. In cases where the total angle range for the rays may be restricted [72], as in breast CT [69,[138][139][140] or electron or visible light microscopy [141][142][143], deconvolution of the point spread function [62,63,65,67,144] corresponding to the CT brush could be invoked, again with no cost in dose. Ringing artifacts could be damped by filtering and/ or iteratively applying "Refine". 8. Cumulative dose used so far could be compared to the best (lowest) score obtained by any player so far, via the Internet. 9. A multiuser version could allow players to compete in finding the first or all of the tumors present, to challenge one another with different hidden images, etc. 10. A library of realistic hidden images could be developed for radiologists to hone their skills at detecting tumors inside various tissues at low dose, with the tumors being real or simulated [145]. 11. The hand/eye tracking could be made visible to the player, as a guide to what moves they have already tried. Additional information about the tracking could also be visualized: the number of rays in the star, number of rays of the star not previously used, ray width, and time stamps. 12. Compressive sensing (CS) algorithms for CT could be included as part of CT Brush.
We can elaborate on the use of compressive sensing in CT Brush, as follows. In general, the CT reconstruction problem can be formulated, in the noise free case, as finding a solution to a matrix: where x is a vector representing the unknown image, A is a sparse measurement matrix, and b is the data (raysums). Here we are using the notation and vocabulary of recent papers on CS in CT [28,29]. In particular, CS has been applied to a set of rays selected randomly and independently of the image (using the commercial optimization software MOSEK [146]). Not surprisingly, performance was worse than with uniformly selected rays [147]. The situation is a bit different in CT Brush, because the rays are selected by the player in an image dependent manner. This means that with the addition of each ray by the player, the matrix A and the data b are changed, and all of the components of x (the pixels or voxels) have to be recalculated. Instead of applying the MART algorithm, which is ray based and therefore simple to implement with deferred refining, we could consider solving a separate global CS problem at each step: The index i refers to the rays consecutively added by the player. This "progressive compressive sensing" algorithm could be attempted in future work, addressing three questions: 1) can the CS software be run fast enough to keep up with the hand/eye motion of the player? 2) does CS reduce the total number of rays needed for the player to reach a decision, N tumor(s)found ? 3) Will image-dependent dictionaries [148,149] lead to further CS improvement in the image? CS CT via Equation 10 has the advantage over MART (Equation 4) of calculating values for all the pixels, whereas MART only calculates values for pixels along the rays used so far, but that very fact also slows the CS computation in comparison with MART.
With open source code, alternative CT algorithms to MART, including CS, may be added by participating programmers. The experience gained from many people playing CT Brush should improve our concept of how to develop CancerZap!.
In previous work [73] we showed how an intelligent walk in the hyperplane of solutions to a set of underdetermined CT equations allows one to hone in on the structures present in the unknown image. Now that computers are so much faster than in 1973, it becomes practical to explore similar ideas in real time games. As CT dose has become a major issue in radiology, we hope that these games will lead to intelligent algorithms and new designs for CT scanners that reduce the dose to the minimum for the screening or diagnostic task at hand.

Conclusions
Nonlinear and object dependent algorithms abound in computed tomography. Compressive sensing is beginning to show how to best use linear methods. However, all of these depend on spraying the patient with x-ray photons. The major improvement in gaming CT Brush and CancerZap! approaches to CT algorithms is that the very act of aiming the x-ray beams becomes object dependent. This is why we suggest that these games point a way to significantly greater dose reduction in x-ray CT. Preliminary results of playing CT Brush suggest that emitted dose might be reducible by a factor of 2 to 10 compared to current practice.

Availability and requirements
○ Project name: CT Brush ○ Project home page: http://home.cc.umanitoba.ca/~alvare/ctbrush ○ Operating system(s): Platform independent ○ Programming language: Java ○ Other requirements: Java 1.5 or higher ○ License: Creative Commons 3.0 by-sa ○ Any restrictions to use by non-academics: none The file ctbrush.jar is the Java JAR archive for the CT Brush game. This file may be used to run the Java applet. Currently, the only parameters available to the applet are the track parameter and the port parameter. Each of these parameters is optional. If the track parameter is set to anything, other than blank, the CT Brush applet will track the player's brush strokes and progress. By default, this tracking information will be sent to port 4444. However, an alternate port may be specified, by passing a "port" parameter to the applet.
The tracking information is represented as "pseudo-functions", where only one function is allowed on each line. Each level is preceded by a line containing ten (10) equal signs ('='). In addition, the triangles and circles describing a level are preceded, on each line, by four (4) space characters.
Each pseudo-function is followed by parentheses. Inside the parentheses, parameters may be passed. These parameters are generally numbers, which are represented in the table below by the number sign ('#'); however, some of the pseudo-functions also pass boolean values (denoted as 'bool') as parameters: level(#:#:#)indicates that the player has progressed to a new level. The first number passed is the level number, the second number is the width of the level canvas, and the third is the height of the level canvas. t(#,#,#:bool)indicates where a triangle is located within the current level canvas. The first 2 numbers are the x and y coordinates of the triangle. The next number is the size of the triangle. Because all of the triangles are right-angle isoceles triangles (with two 45 degree angles and one 90 degree angle), the size corresponds to either of the non-hypotenuse sides. Lastly, the boolean corresponds to whether the triangle is gray half-tone (true) or full tone (false). c(#,#,#:bool)indicates where a circle is located within the current level canvas. The first 2 numbers are the x and y coordinates of the circle. The next number is the radius of the circle. Lastly, the boolean corresponds to whether the circle is a gray half-tone (true) or full tone (false). m(#,#:#^#_#)indicates a player mouse-brush movement within the level. The first two numbers, from the left, are the X and Y-coordinates, respectively; the third number corresponds to the width of the brush; the fourth number corresponds to the number of rays in the brush; the right-most number corresponds to the rotation of the brush. Currently, brush rotation is not implemented; however, it may be easily added in future versions. r()indicates the player has chosen to perform a refinement action. g(#)indicates the player has finished the level, and guessed the number of gray circles. The number passed by this pseudo-function is the player's guess.
The file ctbrush.zip is a zip file that contains all of the Java source code for CT Brush. The source code files are located in the "src" directory. The zip file also contains some optional files and directories, to assist users with editing and building the code: the files "build.xml" and "app.properties" may be used to build the CT Brush project using