# Central and Periodic Multi-Scale Discrete Radon Transforms
## 6 Example of Central DRT Application
### Implementation on Mobile Devices  
Central DRT has been devised with its vectorized implementation in mind: it not only computes less sums than conventional DRT, its formulation have also been modified to operate on vectors, instead of single values. Additionally, central DRT has been adapted for this application, by operating on unsigned, 16-bit integers. It is easy to avoid arithmetic overflow when it is the relative value that is important (and not the absolute values). Table 1 shows the computation times for central DRT run on an Android(tm) smartphone, and the transform is computed on the GPU. A demonstrative execution of the application has been provided as Supplementary Materials, a screenshot can be seen in  
Figure 19: From top to bottom, quality of the inversion for conventional, periodic, and central DRTs. (**a**) Inversion after three iterations; (**b**) Inversion after five iterations. Figure 20. The position on Radon space of the most prominent edges are highlighted. With this information, the rectangle is determined in image coordinates; simultaneously, the output of DRT is being shown, in order to verify the ability to compute the DRT on an smart-phone camera preview pipeline. The camera is initialized and put in preview mode at around 30 frames per second and at a resolution of \(1920\times 1080\) (depending on light conditions). These frames are converted to a single luminance (grayscale) channel of 16-bit depth. Then, it is cropped to \(1024\times 1024\) or \(512\times 512\) and fed to the kernel that calculates the gradient magnitude, which outputs another image of the same resolution. The gradient magnitude output image is then processed by the central DRT, giving a four times wider output as a result. This output is resized to fill the whole screen and converted to the screen display format (32 floating point ARGB); an overlay, containing the input image, is added. The processing time of the central DRT on the SnapdragonTM 835 [32] is 16% faster than the 821 [33], and the 845 [34] is 40% faster. Halving the resolution on both dimensions yields an average speedup of 70%. With all this in mind, for terminals equipped with a SnapdragonTM 845, it is possible to acquire full resolution images and process them, after resizing to \(1024\times 1024\), at 30 frames per second. The vectorized central DRT, along with the rest of the pipeline, was programmed on OpenCLTM. Given that the whole process happens in the GPU, the computation times do not vary a lot and, given the nature of the Android environment, it does not suffer visibly from throttling, as it drastically would when running the same processes on CPU. The measured times showed variations of only 2-5%. The use of this transform, in the context of automatic localization of bar-codes, has been patented by the company Wooptix [35]. The use of Radon transform to accurately \begin{table}
\begin{tabular}{c c c} \hline \hline
**Central DRT Times Model \& SoC** & **Resolution** & **Time in ms** \\ \hline SnapdragonTM 821 (AdrenoTM 530) & \(1024\times 1024\) & 41.9 \\ \cline{2-3}  & \(512\times 512\) & 14.2 \\ \hline SnapdragonTM 835 (AdrenoTM 540) & \(1024\times 1024\) & 35.4 \\ \cline{2-3}  & \(512\times 512\) & 12.3 \\ \hline SnapdragonTM 845 (AdrenoTM 630) & \(1024\times 1024\) & 25.4 \\ \cline{2-3}  & \(512\times 512\) & 5.9 \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Measured times, in milliseconds, of an AndroidTM application, running a GPU implementation of the central DRT on different SoCs with different resolutions. Figure 20: Screen recording of a smart-phone executing the demonstrative application. The camera input is shown on the top-left corner. The rest of the image is the output of the central DRT of the gradient magnitude. Four maxima are highlighted and back-projected to image domain. localize a bar-code on smart-phones has been prohibitive until now [36; 37].