# Central and Periodic Multi-Scale Discrete Radon Transforms
## 5 Results and Discussion  
### Time Measurements and Quality of Reconstructions  
Later in this section, we will cover the similarities and differences between our two proposed methods, but let's start by comparing them with previously available methods for computing Radon transform, in terms of our main motivation: speed. In that sense, we will measure how they compare with three methods that represent the plethora of available Radon transform algorithms. The three selected methods for comparison will be: the conventional multi-scale discrete Radon Transform, which is the direct ancestor of our propositions; a method representing those based on Fourier projection-slice theorem, namely the pseudo-polar Fourier-based Radon transform, PPFRT; and one covering the main alternative, whose lines can dispense with interpolation: the Mojette transform, in particular, the fast Mojette transform, FMT. The methods we will compare with, in each case, will be run on the same platform, with the most optimised versions provided by the different authors; the times will be averaged for 100 runs. The type of data in the multi-scale transforms will be integers, with floating points in the rest, reflecting the nature of each method. The conventional DRT has been programmed in C++ by us but is an almost direct transposition from the appendices of [PERSON] article [16]. As a reference for the Fourier-based methods, we have used the one provided by [PERSON] [28]. In spite of coming packaged for Matlab environment, most of its time is devoted to FFT computations, which are optimal, even if Matlab itself is suboptimal for time measurements. As a representative of the Mojette family, we have selected the fast Mojette transform, which can be found on the Finite transform library [29]. Pseudo-polar Radon transform is based on the Fourier slice-projection theorem; then, the core 2D Fourier algorithm, within the method, is computed on a non-Cartesian grid: the pseudo-polar Fourier transform, running on concentric squares, where points are equispaced in slopes. This is essential to guarantee results free of artifacts. The number of coefficients (displacements \(\times\) angles) computed by this algorithm is \(4N^{2}\), where \(N\) is the number of elements on a dimension of the input image. The now proposed methods return the same number of coefficients, but the conventional DRT computes \(6N^{2}\). The Mojette transform, to be commented subsequently, can operate with much less: \(\frac{3}{2}N^{2}\). Mojette transform uses a set of infinitesimal Dirac lines, whose slopes are rational: they can be written as the inverse tangent of an irreducible rational fraction. The number of angles computed in the test were \(\mathrm{N}+\mathrm{N}/2\), as recommended by the authors, and without redundancy, \(k=1\). There is not a _fast_ forward Mojette transform available in the software package. Tests were conducted on an Intel i5-6600 CPU with 16 GB of RAM running Arch Linux. This is a 64-bit CPU with 4 cores running between 3.3 and 3.9 GHz. It is not capable of hyper-threading. There are some interesting things to note in Figure 14. First, the multi-scale methods, denoted in the graph as DRT, CDRT, and PDRT, are sequential implementations that almost directly translate the provided pseudo-code, and they were not optimised. The central and periodic DRT are, at least, twice as fast as conventional DRT. Even these non-optimised versions are much faster than the widespread Fourier-based methods. FMT remains faster. It must be taken into account that, in order not to penalize the FMT, the times reported are those of its backward transform. While the rest were evaluated for forward transforms. FMT is dozens of times faster in the backward transform than in the forward transform, due to the low number of back-projections it considers. However, it is unable to keep the same pace in both applications that we will show later: line detection and Curvelet transform, as its forward transform, is impractical for real-time implementations.