Parallel Processing of Images in Mobile Devices using BOINC

1 Introduction

The use of mobile devices has increased significantly around the world in the recent years. According to Digital Trends (https://www.digitaltrends.com/mobile/smartphone-users-number-6-1-billion-by-2020/), the number of smartphone users in the world is expected to reach 6.1 billion by 2020. Also, the current capabilities of these devices have increased considerably. With the recent advances in low powered processors, mobile devices can perform computationally intensive operations enabling these devices to be considered as computing platforms [1, 2, 3].

Taking advantage of the previously mentioned smartphones capabilities, since the last decade, many research projects have addressed the problem of incorporating mobile devices to the grid. Grid Computing involves the aggregation of geographically-disperse and heterogeneous resources from different organizations to solve computationally complex problems [4]. The inclusion of mobile devices to the grid infrastructure brought new categories of grids [5]. One of these new categories is the Mobile Grid, which was defined by Furthmuller and Waldhorst [6] as a grid that includes at least one mobile device. Users can connect their mobile devices to the grid (smartphones, tablets, etc.) with basically two purposes: 1) to obtain access to grid resources and/or 2) to place their mobile devices at the disposal of grid users (i.e. mobile devices are resource providers). Our research focuses on the use of mobile devices as providers of computing resources [6, 7, 8, 9, 10]. The idea is to take advantage of idle computing cycles of mobile and fixed devices to process in parallel any kind of images, in particular medical images. We are currently testing the feasibility of this technology, which would allow, in the long term, health professionals to send diagnostic images and receive results making few clicks on his/her mobile devices, while examining his/her patients. With mobile devices, it is also possible to reduce costs and space in computing resources for medical institutions as well as to reach places and communities with low penetration by other types of computer systems.

The chosen platform used to build our proposal was BOINC [11]. BOINC is an open grid framework that has been used mainly for voluntary grid computing projects. BOINC volunteers dedicate unused computing cycles on their personal computers, laptops, mobile devices, etc., to parallel scientific research computations.

The parallel processing of images in mobile grids involves at least four technical challenges: 1) Transparency for the programmer: the execution of programs in the mobile grid should not require changes in the source code; 2) Cross-compilation of the libraries for image processing (i.e. ITK [12]); 3) Distribution and collection of data; 4) Achieve acceptable performance.

In order to look for answers to these challenges, we pose the following problem: Apply the Smoothing Recursive Gaussian Image Filter [13] to an image. This filter computes the smoothing of an image by convolution with the Gaussian kernels. The idea is to divide the image in regions among several mobile devices to apply the filter in parallel. Then the individual results are merged in a final integrated result.

We start the article by providing some definitions in Section 2. In Section 3 the problem to be solved is presented. We briefly explain the main characteristics of BOINC in Section 4. In Section 5 we describe the modifications to BOINC components and the steps to generate the executable file to process the image. Once the infrastructure was ready, we conducted some preliminary tests to evaluate the performance of our solution; thus, experimental design is explained in Section 6. We present some related work in Section 7 and conclude in Section 8.

2 Background

A Grid is a collection of heterogeneous distributed computing resources for solving large-scale computational and data intensive problems ([4, 14]).

The rise of wireless technology and mobile devices has increased the number and types of resources to be integrated to the grid. As a result, the concept of grid has been enriched and new categories have emerged [5]. One of these new categories is the Accessible Grid, whose resources are available regardless of their physical capabilities and geographical locations. Accessible grids consist of a group of mobile or fixed devices with wired or wireless connectivity and predefined or ad hoc infrastructure [15]. Wireless, mobile, and ad hoc grids belong to this category. In Wireless Grids, wireless devices can be either resource providers, which contribute to data processing and/or storage, or only be mere consumers of grid services [6]. The concept of Mobile Grids is very similar to wireless grids concept; in fact, many authors used both terms indistinguishably. Furthmüller and Waldhorst [6] define a mobile grid as a grid that includes at least a mobile device. Finally, some researchers strictly define Ad Hoc Grids as grid environments without fixed infrastructures, i.e., all their components are mobile [16].

Volunteer computing is a type of distributed computing in which people, so-called volunteers, provide computing resources to projects, which use the resources to do distributed computing and/or storage [17]. Volunteers are usually members of the general public in the possession of their own personal computing resources (desktops, laptops, smartphones, etc.) with an Internet connection. Organizations can also act as volunteers and provide their computing resources. The Berkeley Open Infrastructure for Network Computing (BOINC) is an open grid framework that has been used mainly for voluntary grid computing projects [11]. Examples of volunteer computing with BOINC are SETI@home, ClimatePrediction.net, Rosetta@home and Einstein@home.

Image processing is a method to perform operations over images using mathematical operations, in order to change the image itself or to extract useful information from it. The output can be either an image or a set of characteristics or parameters related to the image [18].

Filters are algorithms that receive images as inputs and perform operations over these. The output is another image that highlights or de-emphasize certain characteristics of the initial image. For example, filters can reduce noise and highlight or soften curves in an image. In the spatial domain, most filters operate over each pixel independently, modifying its value given an operator matrix or kernel and the neighboring pixel’s values [19]. On the other hand, the frequency domain operates with the rate at which the the pixels change over the spatial domain.

Gaussian Filters are linear filters that operate in the special domain, modifying the input with a Gaussian convolution, namely, the weights in the operator matrix are given by the normal variance γ². These filters have the property of being separable, i.e. each component can be calculated independently [19, 20].

3 The Problem

Our research question is: Is it possible to do parallel processing of images using mobile devices?

The first step of our research was to choose the execution platform. We decided to use an existing grid instead of making our own implementation with MPI on Android devices (as in the works described in [21, 22, 23]) because grid technology offers extra values, mainly in regard to resource discovery, scheduling and quality of service.

In a previous paper [24], we compared several systems that implement mobile grids according to the literature. We analyzed BOINC [11], Ibis [25], MoGrid [26] and OurGrid [27]. Finally, we selected BOINC for the following reasons:

1. BOINC enables the inclusion of mobile devices among its resources. The code for execution in mobile devices is available.

2. It is possible to run tasks (workunits in BOINC) written in various programming languages. This is an advantage because the processing of medical images imposes certain constraints, such as the use of the ITK library [12], whose algorithms are programmed in C++. However, at the beginning of our research the execution of C++ code on Android required the introduction of additional code in the application.

3. The system has good documentation and it is an active project with many resources to solve possible difficulties in its deployment and use.

As the goal is the parallel processing of medical images using mobile devices, we chose a filter algorithm. Some filtering algorithms are adequate for parallel processing because of their simplicity and because they can process different regions of one image independently or by interchanging few data with their neighbors, i.e. they exhibit coarse or medium grained parallelism. For the previously mentioned reason, filters that require information of the whole image are not suitable for our purposes.

The parallel model according to Flynn’s taxonomy is the single-instruction-multiple-data model (SIMD), where multiple nodes do the same operation repeatedly over a large data set. In this case, each node processes a part of the image. The selected filter should have another important characteristic: the amount of computation should be high enough to justify the division of the work among multiple workunits. Initially we thought about using binarization or umbralization filters as they are very simple algorithms: for example, binarization algorithm generates a binary image based on a given threshold, replacing the values of each pixel, i.e. black or white. This characteristic makes this filter suitable for parallel processing since each pixel is independently processed. However this simplicity implies short execution times, hence parallel processing is not needed.

Finally, we decided to use a filter that only needs the information of some neighboring pixels (see Figure 1): The Smoothing Recursive Gaussian Image Filter of ITK [12]. This filter generates a smooth image by performing a convolution on it, which uses a kernel with values given by the Gaussian distribution. The result of this algorithm can be observed in Figure 2 on a magnetic resonance of a brain.

Figure 1

Overlap of regions in the processed image

Figure 2

Application of the Smoothing Recursive Gaussian Image Filter. Left: Original image. Right: Blurred image after applying the filter.

4 BOINC

BOINC (Berkeley Open Infrastructure for Network Computing) is an open grid framework that has been used mainly for voluntary grid computing projects. BOINC volunteers dedicate unused computing cycles on their personal computers, laptops, mobile devices, etc., to parallel scientific research computations [11]. The combination of both concepts: grids and mobile devices allows to define BOINC as a mobile grid. The main BOINC concepts are on the web page (https://boinc.berkeley.edu/trac/wiki/BasicConcepts).

The BOINC project corresponds to an organization or research group that must do volunteer or distributed computing. The project is identified by a master URL, which is the home page of its web site. Participants register with projects. A project can involve one or more applications. An Application includes several executable codes for different platforms (Windows, Linux/x86, Mac OS/X, etc.), a set of workunits and results. A Platform is a compilation target that typically includes a CPU architecture and an operating system. The Workunits represent the inputs or parameters to a computation such as CPU time, memory and storage requirements and a soft deadline for completion. Each computation has results that consists of a reference to a workunit and a list of references to output files. Files (associated with application versions, workunits, or results) have unique names by projects and are immutable.

The Server of a BOINC project manages a relational database that stores descriptions of applications, platforms, versions, workunits, results, accounts, teams, etc. Participants who want to be part of a BOINC project must visit the project’s website to download the BOINC Client.

The life-cycle of a BOINC workunit is:

1. A Work Generator (supplied by the user) creates the workunit and its input files.

2. BOINC creates one or more instances of the workunits and dispatches them to different hosts.

3. A client program in the host downloads the input files and executes the workunit.

4. Once completed the workunit, the host reports its culmination to the server.

5. A Validator (supplied by the user) checks the output files, perhaps comparing replicas. BOINC provides support for redundant computing by means of replicas. Two reasons justify the use of replicas:

   1. Lack of Battery: Considering that a mobile device can run out of battery or can be suddenly disconnected, BOINC can preventively send the execution of the same workunit to different volunteers (replicas).

   2. Malfunctioning computers or malicious participants: Public-resource computing projects must deal with erroneous computational results due to these two problems. In this case redundant computing is used for identifying and rejecting erroneous results. A project can specify that N results should be created for each workunit. Once M ≤ N of these have been distributed and completed, an application-specific function is called to compare the results and possibly select a canonical result. When no consensus is found, or if results fail, BOINC creates new results for the workunit, and continues this process until either a maximum result count or a timeout limit is reached. BOINC also offers the option of not creating replicas. In that case the validator (SampleTrivialValidator) only marks the result of the workunit as valid.

6. When a valid instance is found, an Assimilator program, supplied by the user, handles the results (e.g. by inserting them in a separate database).

7. When all instances have been completed, the File Deleter removes the input and output files.

5 Solution of the problem in BOINC

The solution of the given problem in BOINC involved four challenges. Three of them were related to technical issues and they are described in this section. The performance-related challenge is explored in the next section. The three technical issues were: 1) Transparency for the programmer: the execution of programs in the mobile grid should not require changes in the source code. 2) Cross-compilation of the libraries for image processing (i.e. ITK [12]). 3) Distribution and collection of data for parallel processing. The following subsections address each of these problems.

5.3 Parallel Processing of the Image

The cross-compilation of the ITK modules allowed us to generate the executable code to process the image.

For the parallel processing we developed code to: a) automate the generation of workunits giving the corresponding parameters (i.e. parts of the image) and b) collect the outputs and generate the final result. Two BOINC components were extended to address these issues: the Work Generator and the Assimilator.

Additionally, we implemented a program that divide the image and interact with the work generator to create the workunits.

5.3.1 The Work Generator

This new component uses the adapter pattern, allowing the integration of a programmer-provided data-division algorithm with BOINC. Figure 3 shows the class diagram. The class WorkDivisor implements the algorithm that divides the image in N sections which are then placed in N different files. The algorithm was programmed in C++. The WorkDivisor communicates with the WorkGeneratorAdapter and creates a workunit for each file previously created. The WorkGeneratorAdapter communicates with the BOINC server’s API and returns to the programmer the workunit id. The WorkGeneratorAdapter was programmed using Python.

Figure 3

Class Diagram of the Work Generator

5.3.2 The Assimilator

The objective of this component is to collect individual results generated by each finished workunit and to construct the resulting processed image. By default, once a workunit is completed and validated, BOINC deletes all the files uploaded by the client. Hence, the need to immediately process the results or save them. Currently BOINC offers an Assimilator module written in Python that does not perform any function but can be extended.

To extend this module it is necessary to know some details of BOINC, namely, to know where do the outputs get stored and understand how the outputs are related to each workunit.

In the development of the Assimilator, we set two objectives:

1. Simplify the work of the programmer, as he/she will only receive the output file’s location of the canonical result.

2. Create an extensible Assimilator for linking images that can be adopted for multiple algorithms.

In order to fulfill these requirements, we implemented the observer pattern. In this pattern, one observer contains a programmer-implemented algorithm to merge the data. The ConcreteObserver class is responsible for both, to periodically detect when a workunit is ready to be assimilated, and notify the changes to the MergeWork class, that joins the various parts of the image. This class was implemented in the C++ language. The ConcreteObserver class, which was programmed in Python, uses the BOINC API to look for completed workunit. Figure 4 shows the class diagram of the Assimilator.

Figure 4

Class Diagram of the Assimilator

6 Experiments

In this section we describe a performance evaluation of the proposed problem. Initially we performed a base experiment to have the execution time of Smoothing Recursive Gaussian Filter on a single desktop computer without the use of BOINC. Then we conducted a 2^k experimental design to evaluate how several factors affect the performance of the parallel processing in BOINC.

6.1 Base Test

This base test was executed in an 8 core Intel Core i7-920XM 2.0 GHz processor, 4GB of RAM and running Linux x86_64 Ubuntu 14.04 operating system. We used a tiff image of 301 MB, 30576 pixels wide and 9860 pixels high. We took the image from the LROC project (The Lunar Reconnaissance Orbiter Camera, http://lroc.sese.asu.edu/images). The image can be observed in Figure 5. This image was selected for its large size and format, which is one of the formats used in medical images. The running time of the base test was 49 minutes.

Figure 5

Image from the moon (http://lroc.sese.asu.edu/images)

6.3 Discussion

Table 3 presents the execution times obtained with each combination of factors. Figures 6, 7 and 8 show the execution times of two factors at once. Table 4 shows the percentage of variation on the response variable explained by each factor and their interactions. From the table, it is clear that the factors that affect the most the response variable are the server location and redundancy. Other factors and their interactions do not impact significantly the response variable. The third-order interactions are negligible; therefore, we do not present it. In the next paragraphs, some of the aspects will be explored in detail.

Table 3

Results of the 2^k experiment

		desktop computers		mobile devices
		450 workunits	1000 workunits	450 workunits	1000 workunits
Local	Redundancy 1	15min	37min	19min	42min
	Redundancy 2	38min	1h22min	40min	1h26
Remote	Redundancy 1	48min	59min	54min	1h03min
	Redundancy 2	lh37	1h54min	1h52min	2h01min

Table 4

Percentage per factor

A (Devices)	B (Parallelism)	C (Redundancy)	D (Server)	AB	AC	AD	BC	BD	CD
0%	6%	47%	30%	2%	1%	1%	1%	0%	6%

Figure 6

Impact of the server location

Figure 7

Impact of the degree of parallelism

Figure 8

Impact of the redundancy

6.3.1 Server Location

Figure 6 shows execution times of the base test and parallel executions, which correspond to the factors devices and servers. As it is shown in Figure 6, the execution times of the parallel solutions with a local server were reduced more than 50%, improving even the sequential solution. Setting the redundancy in 2 also causes the times to increase by more than 50% (Figure 8). When the performance is important, the recommendation is that both the BOINC server and the clients are on the same local network.

6.3.2 Redundancy

Redundancy has a significant impact in the execution time because it increases the number of workunits that must be sent and processed in the devices. As it was mentioned in Section 4, redundant computing can be a scheduling strategy to deal with problems that arise when using mobile devices as resource providers. With mobile devices new significant challenges appear, which are mainly due to mobility patterns and limitations in processing, memory, battery power and wireless communication capabilities. The limited battery and mobility patterns can cause intermittence of mobile devices, which could lead to a break of running tasks and to their subsequent rescheduling.

In [33] the scheduling strategies in mobile grids are divided into preventive and reactive. Preventive scheduling strategies try to ensure the task culmination either by selecting the most reliable resource to execute the grid tasks or using redundant resources in the execution (replication). Reliability in resource selection can be obtained by collecting the current status of the devices, using predictive models, etc. Reactive scheduling strategies act after the tasks have been assigned to resources. In this case at least two scenarios can be possible: a) a new assignment could be necessary when resources become unavailable because of unexpected events or faults; b) re-assignments could be necessary to balance the load and to maximize the number of tasks that can be completed.

BOINC supports redundant computing, so it is possible to implement a preventive strategy based on replication. The works presented in [34, 35, 36] explore these strategies. However, the performance obtained with the use of replication for this particular problem (see figure 8) lead us to think of other types of preventive or reactive strategies, especially if fast processing of the image is needed.

In BOINC, it is also possible to implement a predictive model based on the current status of the resources. BOINC clients send their characteristics before requesting a workunit; the scheduler use this information for the assigment of workunits. Part of these characteristics can be the current status of the battery to parameterize a predictive model. The works described in [37, 38, 39] exemplify this type of strategy. Also it is possible to implement rescheduling using the parameter delay_bound, which is specified when the workunit is created. The parameter delay_bound is an upper bound on the time (in seconds) between sending a result to a client and receiving a reply. If the client does not respond within this interval, the server gives up on the result and generates a new result, which will be assigned to another client.

BOINC group has some recommendations to avoid battery consumption due to the use of the mobile device for volunteer computing (https://boinc.berkeley.edu/trac/wiki/AndroidBoinc).

They recommend to do computing only when the device is recharging. During these periods the device typically is on Wi-Fi. To avoid using up cell-phone data transfer quotas, they recommend to do network communication only over Wi-Fi.

6.3.3 Devices

In table 3 and figures 6, 7 and 8, we did not observe a significant difference in execution times when comparing desktop computers with mobile devices: the highest difference when BOINC is running at a local server is 26%. The percentage impact of this factor on the response variable is negligible. This is a positive point with respect to using one or the other as executing platform. The best option may be to use both types of devices when possible.

6.3.4 Degree of parallelism

The parallel solution with mobile devices is better than the sequential one when the server is local and the image is divided in 450 workunits. The solution with desktops for the same case has a slightly better performance. Table 5 shows the speedup values computed for execution times obtained in a local network with no redundancy. These were the best results. Although the parallel solution is better than the sequential one, the speedup is not proportional to the large number of processors and it decreases significantly when the number of processors is more than double. The speedup is better in desktop computers compared to mobile devices. This makes the efficiency very poor: we obtained 0,007 and 0,005 for desktop computers and mobile devices with Android respectively, with 450 processors. We compute the efficiency only for the best speedup values. It is important to remark that we chose high values for the number of processors in this first phase of the experiments, thinking about a problem of voluntary computing where a substantial number of users participate. Our preliminary results have demonstrated that the parallelism could be adequate but in lower degrees. A finer performance evaluation of the parallel solution is left for the next phase of the project.

Table 5

Speedup. Local Server with no Redundancy

	450 processors	1000 processors
Desktop computer (Linux)	3.27	1.32
Mobile Devices (Android)	2.58	1.17

6.3.5 Resource Usage

Regarding the use of BOINC, it is important to mention that it uses a non-intrusive model in clients, characterized by low resource utilization. Thus, users can continue using their devices without perceiving a drop in performance of their running applications.

In the base test, when the image was processed in a desktop computer without BOINC, the algorithm monopolized all processing units, and the CPU usage reached 100%. In contrast, the CPU usage during the parallel processing of the image using BOINC was around 5%. This result is interesting because even using a much lower percentage of resources it was possible to significantly reduce the execution time by parallelizing the image processing. This also implies that, with an advanced configuration of the BOINC project, which allows, for example, to request more RAM or storage capacity in each client, it may be possible to obtain better execution times.

7 Related Work

Mobile Grids are a type of Accessible Grid [5] where devices are used as resources to execute tasks. According to the revised literature, some implemented mobile or wireless grid systems are: IBIS [25], MoGrid [26], Akogrimo [40] MORE [41], MiPeG [42], Mobile OGSI.NET [35], BOINC [43], Misco [44] and ELASTIC [45]. M. Black and W. Edgard [46] proposed the use of mobile devices as grid computing nodes. They implemented a BOINC client on an APPLE iPhone to demonstrate the feasibility of this concept. Other researchers have proposed the use of mobile devices as execution platforms without the support of a grid system (e.g. [21, 47, 48]).

Several articles are devoted to basic definitions and stand out the main challenges of mobile grids ([7, 8, 9, 49, 50]). The adoption of mobile devices as CPU platforms implies a number of challenges. While most of these challenges come from technical features of the mobile devices (i.e. heterogeneity, CPU capacity, screen size, short life of the battery, mobility, and intermittent disconnections), others are related to the possibility that mobile owners will allow their devices to be part of the Grid.

Regarding technical issues, there is a group of papers devoted to solve specific problems such as: middle-ware architectures ([25, 42, 51, 52, 53]), resource management ([15, 33, 54, 55, 56, 57, 58, 59, 60, 61]) or scheduling ([37, 62, 63, 64, 65, 66, 67]). Authors of [68] apply good programming practices and code refactoring to reduce battery consumption of scientific mobile applications running on Android.

The search for incentives for users to place CPU cycles of their mobile devices at the disposal of voluntary or collaborative computer project is currently a research problem. Duan et al. [3] designed an incentive mechanism for smartphone collaboration in distributed computing. Van de Wijngaert et al. studied in [69] the circumstances under which people could share resources on their edge devices (PDA’s, laptops and mobile phones) using a technology with which they are not yet familiar (wireless grids). Tapparello et al. [1] presented the current state of the art of the mobile volunteer computing. Their analysis includes motivations and challenges of adopting mobile devices as computing resources.

Mobile devices have also been widely used in various health contexts. Most of the applications developed help to manage and monitor diseases with the help of sensors located on mobile devices. Articles [70, 71] present a review of these works. In the search for related works, there were no similar experiences of the use of BOINC and mobile devices for parallel processing of images. In [72], authors present the development of software for electrocardiogram analysis using mobile devices. In that work, however, the use of one device was sufficient for the amount of processing required.

8 Conclusions and Future Work

The proposal of our research is to explore the use of a mobile grid for parallel processing of medical images. The solution of this problem using BOINC presented at least four challenges: 1) The execution of programs in the mobile grid without changing the source code; 2) Cross-compilation of the ITK library for image processing; 3) Distribution and collection of data for parallel processing; 4) The achievement of acceptable performance. In this article, we presented solutions to these challenges.

Related to the first challenge, it was possible to compile the wrapper of BOINC for Android mobile devices. We made this contribution to the official repository of BOINC source code. The wrapper allowed the execution of our programs in Android mobile devices without modifying the code. With regard to the second challenge, part of ITK library was compiled for Android. This was achieved by deactivating the flags that perform tests on the target platform and disabling the load of libraries at runtime. We generated a static executable including the Core and Filtering ITK modules.

Using BOINC and Android mobile devices, it was possible to apply a filter in parallel to a 301 MB image. BOINC supports the distribution of workunits in the computing platforms. However, when the SIMD model is used, some code must be provided to distribute and collect data between clients and the server. The development of this code can be laborious since it requires a deep understanding of BOINC functioning. Therefore, we implemented a Work Generator that allows the programmer to provide her/his own image division algorithm, which can be integrated to BOINC infrastructure without exhaustive knowledge of its API. Our implemented assimilator simplifies the process of unifying results and abstracting details of how BOINC works. This gives an answer to the third challenge.

With regard to performance, we obtained very promising results. Execution times of image processing were very similar in mobile devices and desktop computers. For most scenarios involving a local server, the execution times of the parallel solution decreased significantly with respect to sequential. However, it is important to conduct more experiments in parallel scenarios to explore the behavior of metrics such as speedup and efficiency.

Additionally, the platform did not fully invade the resources of the mobile devices. All these reasons make the use of BOINC as mobile grid interesting and attractive for the problem raised.

Once the feasibility of our goal has been proven, future work includes:

1. Continuing experiments with several types of BOINC clients (fixed and mobiles) and different techniques of image processing. Study the performance of several hardware-software configurations with new metrics, such as resource usage.

2. Finding use cases for this technology. This involves answering questions such as: Which situations or scenarios will this technology be adequate in? In what type of medical institutions? What types of medical problems will this technology be adequate in? Who would be the volunteers? What could be the incentives for them?