Exploring the Radon and Trace Transforms

Joshua Stough
COMP 255, Gerig
December 9, 2003

In fulfilling the requirements of the final project for the Advances in Image Analysis
course, I have implemented the trace transform and inverse trace transform in Matlab. The goal
of my implementation is to understand the trace transform more intuitively and explore the
inverse trace image.
The Trace transform is an interesting technique in image analysis originally described in
[Kadyrov and Petrou, PAMI 2001]. It is a generalization of the common Radon transform used
in medical imaging applications (MRI, CT). The trace is more general in the sense that any
functional can be applied in the projection directions. In section 1, I explore the Hesse line form
that implies the trace image structure, and different functional selections for sensitive and
insensitive transforms, which refer to sensitivity of the transform to linear deformations of the
original image (translation, rotation, and scale). Useful applications of the trace include object
recognition in image databases and affine registration between two images. We reviewed a
recent conference paper on face recognition that used a limited part of the trace image to
characterize and distinguish subjects. An interesting question is what these parts refer to in the
original image. I explore this in section 2 using the inverse trace image.

Figure 1. On the left, the image pixels are considered in terms of  and , which imply a line through the
image perpendicular to the vector described by the parameters. Some real valued function of the
intensities along the line is computed and the result is placed, on the right (trace) image, in the appropriate
place (the black point on the vertical bar). The same function of the line intensities is computed for all
’s to form the vertical bar on the right. xyz

1 The Intuition Behind the Trace Transform

The trace transform begins with a reparameterization of the image coordinates, according
to figure 1. The line through the image coordinate system (x,y) implied by the parameters  and
 can be written in Hesse form:

x*cos() + y*sin() = 
where the origin is in the center of the image. For all   [0, 2], for all   [-k,k] (where k is
some constant based on the image dimension), some function of the intensities at solutions to the
above equation are computed and placed in an image with coordinates (, ).
A better way to understand what happens to an image being transformed is to follow a
pixel from image space to transform space. For (x’,y’), the above equation makes  a function of
. As  proceeds from 0 to 2 the point (x’, y’) is thus transformed to a sine curve, as in figures
2 and 3. The magnitude of the curve grows with the distance of the pixel to the origin, ||(x’,y’)||,
and the phase is determined by tan-1(y/x).

Figure 2. (In these pictures, the vertical direction is the positive x-axis, where the angle of (x,y) is 0.) On
the left, the point (0,1) is taken to the classic sine curve. On the right, (1,0) implies the cosine curve in the
transform image.

Figure 3. On the left is an animation showing all the phases for a dot moving in a circle. On the right, the
moving dot crosses the origin in addition to rotating. These are animations, so in the electronic version
they are playable (double click on the object), and I have included them in submitted materials.

Knowing how a point transforms, one can easily understand the general shape of the trace
image given the original for simple cases. In fact, the prominent shape in an image can be
thought of as a collection of simple shapes. If we transform each simple shape separately, the
composition of the transforms will be very similar to the transform of the original image, as in
figure 4.
Figure 4. The shark image and its trace can be approximated by a grossly simplified shape and resultant
trace. This shape can furthermore be considered separately as body, tail and fins, and the separate traces
composited.

Implementing the Trace Transform

I wrote a Matlab function TraceTransform.m, which receives an image, an output

resolution, and a functional as arguments and returns the trace image of the image argument.
Since every pixel can be mapped separately, one could think to simply traverse the image,
mapping and adding every pixel onto the trace, binning them to calculate the functional later.
However, the order of the intensities along the projection line implied by (, ) are important for
applying different functionals and thus computing the general Trace Transform, and order is not
recoverable in the binning context. (In the above examples, the simple average along the line
was computed, which is independent of order.) Thus in order to allow for the range of possible
functionals, the program computes an ordered list of pixel coordinates for every (, ) pair.
The program proceeds in few steps:
-let k be half the minimum dimension of the input image.
-for each evenly spaced increment of   [0, 2]
-for all   [-k,k] compute the image coordinates for N samples along the projection line
implied by (, ). Result is two matrices X and Y of size N x 2k.
-Compute the linearly interpolated image values at (X,Y) and record in ZI. (uses interp2)
-The columns of ZI are the lines along which the functional is computed.
-The 2k results are placed as in the vertical line of figure 1.b in the trace image.

There were few issues in writing the program. One simple detail I had not previously
considered was that to compute the coordinates to sample the image at, every line has to be
clipped to the image boundary. This is done by using the known boundary value, which is one of
the x or y coordinates, in the Hesse line equation above, and solving for the remaining image
coordinate. All four clip points are found (to the bottom and top horizontal, left and right
vertical), and then the two that were within the image boundaries are determined, as in figure 5.
Figure 5. The four clip points of the projection line are computed. The inner two become the actual ends
of the line for sampling purposes.

Figure 6. The shark image and three variations on the classic trace (or radon) transform. The topmost is
the one I have describe in this paper, the middle is with a normalization based on the extent of the line.
The bottom image is computed by having the  sampling change over . The distortions in the bottom
two images appear to misrepresent the trace transform.

The program runs a little slowly, with all the sampling coordinate computations and
overwriting of memory. However, it is quite flexible, allowing the user to specify any
functional. I considered trying to normalize somehow for the variable extent of the lines, but
doing so creates artifacts that confuse the trace. Such artifacts (a repeated diamond pattern
masking the more interesting trace information) are clear in using the Matlab system function
radon, where the radon transform of an all white image is not blank. I also considered having ’s
extent vary for each , to accommodate different x and y image dimensions and the fact that the
images are rectangular ( could extend farther at  = /4 for example). However, this confuses
the sine curve pattern, shrinking the curve at some . Both such artifacts are shown in figure 6.

2 Varying the functionals

The paper describes functionals applied to projection lines in terms of properties that the
resultant trace image will have. A functional  is termed invariant if
((x+b)) = ((x)) for all b  

where (x) are the projection line samples as a function. Consider a shape being moved within
the image boundaries. Every line through the shape will still find its way into one of the
projection lines. That projection line will have some piece of the shape identical to a piece from
the unmoved shape’s projection lines, minus a translation of the intensities. This property notes
that such corresponding lines will compute to the same result. The example shown in section 1
has this property—where a simple translation along the columns or a shift of the columns brings
trace images into correspondence. Such functionals include aggregate, mean, and maximum, and
amplitudes of (at least the first four) harmonics of the projection line. See figure 7.

Figure 7. Escher’s Mobius and several trace images of it. The lone image has the mean of the projection
line as the functional. The first column has the invariant second, third, and fourth harmonic amplitudes
(the first is the mean). The second column has the second through fourth harmonic phases, which are
sensitive.

Sensitive functionals are in contrast to invariant ones. By definition, a functional Z is

sensitive if
Z((x+b)) = Z((x)) – b for all b  .
I have less intuition for what sensitive functionals compute or do to an image, though they make
interesting pictures (see figure 7). Examples include the harmonic phases and the midpoint
position of the cumulative sum of the projection line (what I submit as the functional
half_point.m). The difference between the two types does seem apparent though: the invariants
are quite simple, like min, max, sum, mean and variations, while the sensitive functionals seem
to go out of their way in formulation to include something about position along the projection
line. Such properties are hard to visually comprehend in the original image. Many of these
functionals, which are easy to code, are submitted.

Inverse Transform

The inverse trace image can be computed in much the same way that the forward
transform proceeds. The pseudocode for my ITraceTransform.m is almost identical to the above
given for the forward. For each phi, or column in the trace image, project the intensities along
the projection lines for that orientation. Since the projections do not cross integer pixel
coordinates, I use the griddata function in a capacity similar to the interp2 function used in the
forward transform. The result of all the back projections leads to an effective reconstruction.

Figure 8. Several resolutions of reconstruction (left to right, top down). First the image and its trace, at
phi steps of 2 degrees and 140 projection lines per orientation. Reconstruction in 20 degree increments
and 5 degree increments. Then (first on the bottom), the 5 deg with a little intensity windowing. Finally,
2 degree increments and a windowed version.
As can be seen in the reconstructions from figure 8, I had a couple of issues with the inverse
trace. First, the images have the annoying circle of white. This messes up the contrast of the
subject. The circle is caused by the limited extent of my sampling of the original image. In the
forward transform, I let  vary from 0 to the vertical or horizontal boundary, and I keep that
distance constant throughout . Simple windowing takes care of this. The second issue is that
the inverse image is blurred. This happened because I had not applied a high-pass filter on the
projections (the columns of the trace image). That this has to be done was not clear to me
originally. I used code from iradon, the matlab inverse radon function, to perform the high pass
filter (which is simple of course: I just didn’t know it existed before I saw it). By doing this,
most of the blurring goes away. Also, the brightest parts of the filtered trace image are parts that
transform to the white circle. So I can zero some of them out to make the reconstruction more
visually appealing.
Due to the limited speed of my function ITraceTransform.m, I reimplemented it with
ITraceTransformv2.m. In this function, rather than back project, I use the hesse line form to
sample the trace image (after high-pass filtering). As described in section 1.1, given a known x
and y (image coordinates), we can look at the pixels corresponding to the sine curve that the
hesse line form becomes, and only look from 0 to . Since I’m sampling the trace image at non-
pixel centers, I use interp2 again to linearly interpolate the values. This runs much faster, which
is good. However, I may be creating additional artifacts by not sampling at exactly the right
places (Fig. 9).

Figure 9. A fast reconstruction using ITraceTransformv2.

Conclusions

What I gained most from this project is an understanding of how the trace transform
works. One thing the class was interested in during presentations on the trace transform was to
understand what in the original image corresponds to some part of the trace image. Specifically,
the authors performed a threshold the gradient image. A small part of the trace image will
correspond to those lines in the original (Fig. 10), as I stated during my presentation. As for
whole sections of the trace being inverted, that was addressed in figure 4 (where sections of the
shark transform to interesting pieces of the trace image).

Figure 10. The gradient magnitude of the trace image has a threshold applied to it. The resulting inverse
implies the projection lines where there was significant edgeness. You can see the fins, tail and body of
the shark in the intersections of the projection lines.