UNIVERSIDAD DE EXTREMADURA

Transcripción

1 UNIVERSIDAD DE EXTREMADURA Escuela Politécnica Máster en Ingeniería Informática Trabajo Final de Máster Desarrollo de un Sistema de Información para realizar búsquedas por contenido en imágenes de satélite, mediante Ángel María Ferrán Frías Marzo 2012

2 2 Desarrollo de Sistema de Información para realizar búsquedas por contenido en imágenes de satélite, mediante

3 3 Desarrollo de Sistema de Información para realizar búsquedas por contenido en imágenes de satélite, mediante UNIVERSIDAD DE EXTREMADURA Escuela Politécnica Máster en Ingeniería Informática Trabajo Final de Máster Desarrollo de un Sistema de Información para realizar búsquedas por contenido en imágenes de satélite, mediante Autor: Ángel María Ferrán Frías Fdo: TRIBUNAL CALIFICADOR Presidente: Fdo: Directores: Pablo García Rodríguez Fdo Antonio Plaza Miguel Fdo: Secretario: Fdo Vocal: Fdo: CALIFICACIÓN: FECHA:

4 4 Desarrollo de Sistema de Información para realizar búsquedas por contenido en imágenes de satélite, mediante

5 5 Desarrollo de Sistema de Información para realizar búsquedas por contenido en imágenes de satélite, mediante Dedicado a mi mujer, Marta, por darme las fuerzas necesarias cada día para poder realizar este Máster, por confiar en mí más que yo mismo y por permitirme haberle robado tanto tiempo. A mis padres y hermanos, por el poco tiempo prestado y por su generosidad. A mis sobrinas, Carla, Mara y Lucía por darme tantas risas, alegrías y energías. Ángel Ferrán Marzo, 2012

6 6 Desarrollo de Sistema de Información para realizar búsquedas por contenido en imágenes de satélite, mediante

7 7 Desarrollo de Sistema de Información para realizar búsquedas por contenido en imágenes de satélite, mediante Agradecimientos A Pablo García, por el continuo apoyo prestado, la generosidad demostrada, por transmitirme siempre la motivación necesaria para finalizar este Máster y por confiar en mí para realizar este trabajo. Sin su apoyo hubiera resultado mucho más difícil. A Antonio Plaza, por estar siempre ahí, por colaborar tanto y tan bien en este proyecto y por darme la oportunidad de aprender algo tan interesante de su trabajo. A Sergio Bernabé, por su inestimable ayuda en este proyecto, por tanta colaboración prestada y por enseñarme mucho de algoritmos de procesamiento. A Abel Paz, por su aportación en materia de Servidores y Sistemas y por todo el apoyo y el buen hacer. A mis compañeros del Máster en Ingeniería Informática, Sergio, Jose, Samuel, Roberto, Manuel, Juan Luis, Noelia y Ricardo por ser tan buenos compañeros, dejarme aprender algo de ellos y pasar muy buenos ratos juntos. A todo el profesorado del MII de la Universidad de Extremadura, por el trabajo realizado con tan poco tiempo disponible y las ganas demostradas por conseguir una buena Universidad para Extremadura. A todos, un fuerte abrazo y muchas gracias. Ángel Ferrán Marzo, 2012

8 8 Desarrollo de Sistema de Información para realizar búsquedas por contenido en imágenes de satélite, mediante

9 9 Desarrollo de Sistema de Información para realizar búsquedas por contenido en imágenes de satélite, mediante Table of Contents Abstract Introduction System architecture Maps layer Server layer Client layer Methodology Image acquisition Graphical user interface (GUI) Image processing Handling image processing requests Performing the actual image processing task Saving the final obtained results Experimental results Experiment 1: Validation of the k-means unsupervised classification algorithm Experiment 2: Validation of the ISODATA algorithm with spatial post-processing Experiment 3: Performance of the client-server architecture Conclusions and future research lines Annexes A) User Manual A.1. Introducción A.1.1 Qué es WMPS? A.2. Acceso a la Aplicación A.3. Configuración A.4. Barra de Herramientas A.4.1. Creación de Mapas A.4.2. Obtención de Capturas A.4.3. Actualizar Capturas... 54

10 10 Desarrollo de Sistema de Información para realizar búsquedas por contenido en imágenes de satélite, mediante A.4.4. Manejo de Nivel de Zoom A.4.5 Procesado K-Means A.4.6. Procesado Isodata A.4.7. Gestión de Clases A.4.8. Centrado del Mapa A.4.9. Guardar Capturas B) Programmer Manual B.1. Introducción B.2. Arquitectura B.3. Tecnología B.4. Estructura de Ficheros B.5. Requisitos del Sistema B.6. Instrucciones de Despliegue B.7. Módulos y código Fuente B.7.1. Capa: SERVIDOR B.7.2. Capa REPOSITORIO DE IMÁGENES B.7.3. Capa CLIENTE C) Project Charter C.1. Información general C.2. Resumen del proyecto C.3. Objetivos del proyecto C.4. Alcance del proyecto C.5. Descripción del producto / servicio C.6. Participantes del proyecto C.7. Hitos importantes del proyecto C.8. Restricciones del proyecto C.9. Criterios de aceptación del proyecto C.10. Sponsor que autoriza el proyecto D) Planning and System Construction D.1. Introducción D.2. Planificación Inicial D.3. Planificación Final D.4. Análisis Requisitos D.5. Análisis del Proyecto... 87

11 11 Desarrollo de Sistema de Información para realizar búsquedas por contenido en imágenes de satélite, mediante D.6. Construcción del Proyecto D.7. Pruebas del Proyecto D.8. Plan de Mantenimiento D.8.1. Introducción D.8.2. Nuevas Funcionalidades D.8.3. Módulos revisables y mejorables E) Glossary of Terms E.1. Introducción E.2. Glosario de Términos References... 99

12 12 Desarrollo de Sistema de Información para realizar búsquedas por contenido en imágenes de satélite, mediante

13 13 Desarrollo de Sistema de Información para realizar búsquedas por contenido en imágenes de satélite, mediante New Web-Based System for Unsupervised Classification of Satellite Imagery Angel Ferrán 1, Sergio Bernabé 2, Pablo García-Rodríguez 1 and Antonio Plaza 2 1 Grupo de Ingeniería de Medios, Dept. of Systems Engineering and Telematics University of Extremadura, Avda. de la Universidad s/n, Cáceres, SPAIN angelmff@gmail.com, pablogr@unex.es 2 Hyperspectral Computing Laboratory, Dept. of Technology of Computers and Communications University of Extremadura, Avda. de la Universidad s/n, Cáceres, SPAIN {sergiobernabe,aplaza}@unex.es Abstract The availability of satellite images has significantly increased in recent years, and the possibility to perform fast processing of massive databases comprising this kind of imagery data has opened ground-breaking perspectives in many different fields. In this regard, the widespread use and availability of web-based tools such as Google Maps has quickly introduced new processing challenges. In this paper, we develop a new webbased system for unsupervised classification of remotely sensed images which is available for public use 1. The system has been developed using the Google Maps applications programming interface (API), and incorporates a complete unsupervised classification chain for satellite image data. It is made up of the well-known ISODATA and k-means algorithms, followed by spatial post-processing based on majority voting. The system makes use of a remote server to speed-up the processing of large satellite images, using a cluster of commodity graphics processing units (GPUs) to perform the calculations in computationally efficient fashion. The system has been experimentally 1

14 14 Desarrollo de Sistema de Información para realizar búsquedas por contenido en imágenes de satélite, mediante validated using different satellite images obtained from the Google Maps tool, and the classification accuracy has been validated with regards to techniques available in the well-known Environment for Visualizing Images (ENVI) commercial software package. Our experimental results indicate that the proposed system can perform computationally efficient and accurate web-based classification of satellite images available from Google Maps engine. Keywords: Web-based system, satellite image classification, Google Maps. 1. Introduction Remote sensing image analysis and interpretation has become an important tool, particularly thanks to the wide availability of web mapping services and programs which have increased the community of users of satellite images that not long ago were available mainly to government intelligence agencies [1, 2]. Specifically, the wealth of satellite imagery available from Google Maps, which now provides high-resolution satellite images from many locations around the Earth 2, has opened the appealing perspective of performing classification and retrieval tasks via the Google Maps application programming interface (API). In fact, the introduction of Google's mapping engine prompted a worldwide interest in satellite imagery exploitation. The combination of an easily searchable mapping and satellite imagery tool such as Google Maps with advanced image classification and retrieval features [3]. has the potential to significantly expand the functionalities of the tool and also to allow end-users to extract relevant information from a massive and widely available database of satellite images (the Google Maps service is free for non-commercial use). By using the Google Maps Javascript API, it is now possible to embed the full Google Maps site into an external website application. Other similar services currently available comprise Yahoo Maps 3 and OpenStreetMap 4. The characteristics of Yahoo Maps are similar to those available in Google Maps

15 15 Desarrollo de Sistema de Información para realizar búsquedas por contenido en imágenes de satélite, mediante (although the spatial resolution of the satellite imagery available in Yahoo Maps is generally lower than the resolution of the image data available from Google Maps). On the other hand, the OpenStreetMap follows a different approach. It is a collaborative project aimed at creating a free editable map of the world. Its design was inspired by sites such as Wikipedia 5. As shown by Fig. 1, the Google Maps service offers important competitive advantages, such as the availability of high resolution satellite imagery, the smoothness in the navigation and interaction with the system, the availability of a hybrid satellite view which can be integrated with other views (e.g. maps view), and adaptivity for general-purpose desktop applications. Despite its competitive advantages, the possibility to perform unsupervised or supervised classification of satellite images at different zoom levels [4, 5] is not available in Google Maps, despite image classification is widely recognized as one of the most powerful approaches in order to extract information from satellite imagery [6, 7]. The incorporation of such functionality to Google Maps would allow us to extract relevant information from a massive and widely available database of satellite images and the possibility to perform contentbased image retrieval (CBIR) tasks [8] which are of great interest for the exploitation of this and other satellite image databases

16 16 Desarrollo de Sistema de Información para realizar búsquedas por contenido en imágenes de satélite, mediante Figure 1. A comparison of the main functionalities offered by web mapping services: Google MapsTM, Yahoo Maps and OpenStreetMap. In this paper, we describe a new web-based system (which represents a follow-up to our previous work in [9]) which allows an unexperienced user to perform unsupervised classification of satellite images obtained via Google Maps through a web-based system that incorporates a fully unsupervised processing chain based on two well-known clustering techniques: ISODATA [10] and k-means [11], followed by spatial postprocessing based on majority voting [12]. The processing chain has been implemented in the C++ language and integrated into our proposed tool, developed using HTML5, JavaScript, Php, Ajax and other web programming languages. A very important functionality of our newly developed tool is the fact that it exploits a remote server to speed-up the processing of large satellite images, using a cluster of commodity graphics processing units (GPUs) [13] to perform the calculations in computationally efficient fashion. Recent literature has focused on the development of high-performance computing implementations for remotely sensed satellite imagery [14-18], and particularly GPUs [19-25] have been used as a source of computational power that can be obtained at low cost in order to accelerate processing chains in satellite image

17 17 Desarrollo de Sistema de Información para realizar búsquedas por contenido en imágenes de satélite, mediante interpretation. In this regard, our proposed contribution represents an innovative way to process the satellite imagery available from Google Maps engine by resorting to a centralized GPU cluster with the capacity to perform the processing of large amounts of satellite data in computationally efficient fashion. The remainder of the paper is organized as follows. Section 2 describes the system architecture, including relevant aspects such as the map, server and client layers. Section 3 describes the processing chain implemented by the proposed methodology, including aspects such as the image acquisition process, the graphical user interface (GUI) that allows end-users to interact with the proposed system, the image processing algorithms implemented and their efficient implementation in the GPU cluster, and the procedure adopted for data saving and end product distribution to the users. Section 4 performs an experimental validation of the classification results obtained by the proposed system by comparing the classification accuracy of the proposed chain with regards to techniques available in the well-known Environment for Visualizing Images (ENVI) software package 6. Finally, section 5 concludes the paper with some remarks and hints at plausible future research. 2 System architecture In this section we describe the architecture of the proposed system, whose general architecture is described in Fig. 2. The system is a web application made up of several layers or modules. Each module serves a different purpose, and the technology adopted for the development of the system is based on open standards and free software. Specifically, we have used a blend of different tools for the development of the system, including Apache web server 7, PHP 8 (a widely-used general-purpose scripting language that is especially suited for Web development and can be embedded into the hypertext

18 18 Desarrollo de Sistema de Información para realizar búsquedas por contenido en imágenes de satélite, mediante markup language such as the version HTML5 9 used in our development), JavaScript libraries 10, Asynchronous JavaScript and extensive markup language (AJAX) 11, Jquery 12 and its user interface (UI) 13, cascading style sheets (CSS) 14 and, last but not least, the C++ programming language and NVidia s compute device unified architecture (CUDA) 15 for carrying out the image processing tasks. As shown by the architecture model described in Fig. 2, the proposed system can be described from a high level viewpoint using three different layers, which are completely independent from each other. Due to the adopted modular design, any of the layers can be replaced. Also, the system is fully scalable, allowing for the incorporation of additional layers. The communication betweetn two layers is carried out throught the Internet, using the hypertext transfer protocol (HTTP) 16. As a result, the system performance will depend largely (as expected) on the available bandwidth. Therefore, both the map layer (currently provided by Google Maps) and the server layer (developed by ourselves) are available from any location in the world. In the following, we describe each of the layers adopted in the system in detail

19 19 Desarrollo de Sistema de Información para realizar búsquedas por contenido en imágenes de satélite, mediante Figure 2: Architecture of the proposed system expressed in the form of different modular layers. 2.1 Maps layer This layer contains the source imagery data to be used by the system, i.e. the image repository. Google Maps is used in the current version by means of the Google Maps API V3 as a programming interface intended for accessing the provided maps. Taking this into account, it is important to emphasize that the current framework is limited to the types of maps provided by Google Maps. Therefore, all types of maps provided by the API V3 can be used, including roadmaps (2D mosaics), satellite images, hybrid view (mixed satellite images and roadmap, superimposed), or terrain (physical relief). Also, all the potentials and functionalities provided by the Google Maps API V3 are included (this comprises management of zoom levels, image centering, location by geospatial coordinates, etc.) Although Google Maps is now used by our system as a repository of images, the system is open and could support other possible alternative repositories such as Yahoo Maps or OpenStreetMap. These systems are all accessible

20 20 Desarrollo de Sistema de Información para realizar búsquedas por contenido en imágenes de satélite, mediante for free and easy to include in our proposed platform. In this work, Google Maps was mainly chosen due to the advantages summarized in Fig. 1. In fact, the image repository can be used to capture any satellite image displayed by the Google Maps engine, and most importantly the images can be captured at different zoom levels. Even a single image can be extracted at different zoom levels, which is obtained by different image sizes and resolutions. This offers significant advantages in terms of analyzing perfectly geo-registered satellite imagery at different resolutions [26]. 2.2 Server layer The server layer is one of the main components of the system. It is formed by two submodules: web server and compute server. The former is the part of the system in charge of hosting the source code of the application (developed using HTML5, PHP, JavaScript and CSS) and deal with the incoming traffic and requests from client browsers. In our system we have used the Apache web server due to its wide acceptance and performance, and also due to the fact that its software license is free. Further, PHP is used both in the server layer and also for managing the communications between the clients and the web server (mainly dominated by the transmission of satellite imagery to be processed) and between the web server and the compute server (intended for the processing of satellite images). In fact, the compute server is mainly in charge of the actual image processing tasks which comprise clustering using k-means [10] and ISODATA [11] algorithms, and spatial post-processing [12]. In this regard, the compute server receives the processing requests from end-users, manages them effectively by resorting to a local GPU cluster made up of 44 NVidia Tesla C1060 GPUs 17 (in the future, further acceleration by means of efficient NVidia CUDA implementations will be pursued), and then provides the obtained result to the end-user. Currently the web server and the computer server are hosted in the same machine, but the system also allows to have different machines for this purpose. It is also worth noting that the system is modular, thus allowing for the incorproation of additional processing modules other than ISODATA, k-means and spatial postprocessing. At this point, we also emphasize that the current system has been 17

21 21 Desarrollo de Sistema de Información para realizar búsquedas por contenido en imágenes de satélite, mediante shown to be able to handle the processing of large image data sets. This is because, in the current implementation, both the web server and the compute server are implemented in a cluster of GPUs, thus reducing the communication time which is limited to the transfer of the image to be processed from the client to the server and the return of the obtained processing result after it is locally obtained in the cluster. 2.3 Client layer The client layer defines the interactions between the user (through an internet browser) and our system. Only one web page is needed as user interface thanks to the adopted AJAX and JavaScript technologies, which allow updating the web interface without the need for interactions with the web server. The design of the web interface has been done using Jquery UI, which provides built-in JavaScript modules which are attractive, easy to use and freely available. The interaction betwen the user and the client web interface is captured by the event handlers of the Jquery libraries, and executed at the local browser as JavaScript is only executed in the browser in our implementation. Hence, the only actions from the user which are transmitted to the server layer are those related with the processing of satellite images. In this context, the images to be processed are transmitted to the server using AJAX-based requests, and the web server provides such requests to the compute server (in our implementation, implemented in the same machine) so that the compute server can process the images very efficiently and produce a result that is then transmitted back to the client layer. This process is illustrated in Fig. 3, which also shows how the client layer perform requests to the maps layer in order to update the maps which are being handled by the end-user. This comprises operations such as zoom in-out, changing of location in the map, creation of maps, selection of the specific view in which the processing will be accomplished (satellite, roadmap, hybrid, etc.) In this regard, Fig. 3 provides an illustrative view of the communications taking place between the main layers in our system. In order to better interpret the interactions between the different layers of our system, graphically illustrated in Fig. 3, in the following we provide an example of the flow of a processing request started by the client in the system and the different steps needed until a processing result is received by the end-user. The following steps are identified in Fig. 3:

22 22 Desarrollo de Sistema de Información para realizar búsquedas por contenido en imágenes de satélite, mediante Figure 3: Interactions between the three main layers (map, client and server) of our system. 1. First, the client starts the use of the system by requesting a web page from the local internet browser. This results in an HTTP request to the web server. 2. The web server receives this request and provides the client with an HTML web page and all necessary references (JavaScript libraries, CSS, etc.) 3. At this point, the client requests from the map server the information needed to perform the map modification locally (i.e., zooming in-out, etc.) This operation is transparent to the system, and the requests are performed via messages from the client to the maps server. 4. The maps layer returns the information requested by the client in the form of updated maps that will be locally managed by the end-user. 5. Once the end-user has decided the image and view to be processed, a capture of the image information is performed in order to delimit the image that will be processed by the compute server. This process is locally managed at the client by means of JavaScript functions. We emphasize that the end-used can decide the zoom level and the image view (street, satellite, hybrid, etc.) in which the image to be processed is captured.

23 23 Desarrollo de Sistema de Información para realizar búsquedas por contenido en imágenes de satélite, mediante 6. Now the captured image is sent to the web server by means of AJAX functions and asynchronous requests. In this way, the interaction with the application at the client layer can continue while the captured image is being transferred to the server. 7. The web server provides the satellite image to be processed to the compute server. In this regard, we emphasize that our system delegates the processing task to an independent high-performance system (GPU cluster) that takes care of the processing task independently from other layers in the system. 8. Once the satellite image has been procesed, the compute server returns the obtained result to the web server. We reiterate that in our current implementation both the web server and the compute server are implemented in the same computing machine, hence in this case the communications are minimized. 9. Finally, the processing result is returned to the client so that it can be saved to disk as the final outcome of the adopted processing chain. 3. Methodology In this section we describe the methodology adopted for the development of the proposed system. Several main tasks have been identified: image acquisition, graphical user interface (GUI), web server, image processing and image saving. These tasks, which are summarized in the flowchart given in Fig. 4, will be described in detail in the present section.

24 24 Desarrollo de Sistema de Información para realizar búsquedas por contenido en imágenes de satélite, mediante. Figure 4: Flowchart describing the methodology adopted for the development of the system. 3.1 Image acquisition Image acquisition is the starting point of the system operation. The images to be processed are considered from two different viewpoints. On the one hand, the images are parts of a map and, on the other hand, the images can also be considered as a specific capture or snapshot of a larger map. The maps are dynamic entities which can be dragged, zoomed (i.e. displayed in more or less detail), but the captures can be seen as static parts of a map which are selected by the end-user through the interface. These captures or snapshots can then be sent to the server and processed in spite of the components of the map layer, in our case supported by the Google Maps engine.

25 25 Desarrollo de Sistema de Información para realizar búsquedas por contenido en imágenes de satélite, mediante Figure 5: Flowchart describing the strategies adopted for managing image captures. The methodology implemented in our system for obtaining the image captures from the maps layer has been developed using JavaScript libraries. These processes have access to the collection or puzzle of images that compose a certain map, thus taking advantage of the browser cache memory to optimize such operation. The query is directed to the map layer in case that the image is not already present in the cache memory (a situation which happens quite rarely). This allows some advantages, most notably the high speed achieved by the system in the task of obtaining image captures regardless of the latency of communications with the server. This reduces the communication traffic and increases the performance in the local management of image captures. In order to achieve this functionality, several layers of images from the server are considered once the image captures have been processed, thereby obtaining a stack of images in which each layer represents a class (as determined by the considered processing algorithms, i.e. k-means and ISODATA). The layers are completely

26 26 Desarrollo de Sistema de Información para realizar búsquedas por contenido en imágenes de satélite, mediante independent, thus allowing visualization as individual entities or as a combination between layers, providing a lot of flexibility in the analysis of the obtained results and a specific management of layers. Finally, the system also allows for the rapid acquisition of multiple captures from the same map, along with the simultaneous operation of multiple maps at the same time. For illustrative purposes, Fig. 5 shows the strategy adopted by our system for managing image captures Graphical user interface (GUI) GUI is a very important component as it is the visible part of our system and it allows the user to perform all operations available in the application. An HTML page and JavaScript libraries have been used for development. These libraries are the Jquery framework (version 1.6.2) and Jquery-UI (version ). Other own developments using JavaScript libraries have been accomplished in order to add new functionalities to the created widgets. As the whole GUI runs on the client layer, usability and speed of response is guaranteed and the adopted design is very flexible. The GUI has been developed in the form of a single HTML page, avoiding repeated requests and responses back to the server while. Several features within the HTML5 standard have been used in order to design the GUI for our system applciation. The most important object used is the canvas object, which allows for an efficient management of the images to be processed. Pixel-level accesses to the content of a canvas object is possible, thus largely simplifying the implementation of image processing operations. Therefore, the container is adequate to carry out map captures (snapshots), to access information of each pixel of the capture, to transfer all such information to the server layer, and to save the obtained information (processed images). As noted above, a stack of images is obtained as an outcome with as many layers as the classes identified by the processing algorithms k-means and ISODATA. The obtained layers can be merged in order to simplify the interpretation of the obtained results. To achieve the aforementioned functionality, the only requirement at the client layer is the use of browsers that support HTML5. Some browsers currently support some (but not all) of the features in HTML5. One of the key features that client browsers must

27 27 Desarrollo de Sistema de Información para realizar búsquedas por contenido en imágenes de satélite, mediante support in the context of our application is the so-called attribute crossorigin of the image object in HTML18. Essentially, if this feature is not supported then the application will display a security error and will not work correctly. On the other hand, it is worth noting that our application is fully accessible from mobile devices: although the application is developed to be accessed primarily from the browser of a personal computer, it is also operational on mobile devices such as cell phones or tablets, as far as these devices use browsers that support HTML 5. For illustrative purposes, Fig. 6 shows an example of the designed GUI application. As shown by Fig. 6, the GUI of our application has been designed to be quite simple. It consists of a single web page with a working panel, a container of maps, and a capture container. The work panel allows creating maps, updating the captures of a given map, changing the zoom level, and select processing parameters for the k-means, ISODATA and spatial postprocessing algorithms implemented for image analysis tasks in the current version of the application. The map container can hold multiple maps of individual sizes, while the capture container allows several captures of the same map. Different captures of the same map always have the same size as the original map size. 18

28 28 Desarrollo de Sistema de Información para realizar búsquedas por contenido en imágenes de satélite, mediante Figure 6: Graphical user interface of our designed application. To conclude this subsection, Fig. 7 shows a view of our application in which the management of different layers is illustrated. In the considered example, we show how an image has been processed and several classes have been identified by one of the considered processing algorithms. The system allows showing, hiding and merging of the different classes identified by such processing algorithms. The colors associated to these classes can also be edited and completely personalized. The layers can be superimposed on the original image (capture) to be processed, thus generating a final product which comprises an unsupervised classification of a certain area whose location, size, dimensionality, zoom level, etc. are defined by the end-user.

29 29 Desarrollo de Sistema de Información para realizar búsquedas por contenido en imágenes de satélite, mediante Figure 7: An example illustrating the management of different layers in the considered application Image processing Two different modules are devoted to image processing tasks within our system. On the one hand, the web server is responsible for receiving the image, processing it in accordance with the methodologies implemented in the system, and then forwarding the obtained result to the client layer. On the other hand, the compute server is in charge of the actual processing of the image (e.g. applying the considered clustering and spatial post-processing algorithms) in efficient fashion. In the following we describe in more detail the image processing tasks at bot layers with particular attention to describing how image processing requests are handled Handling image processing requests The main task of the web server is to receive requests from the clients. Such requests are handled as follows. First, the client selects the image capture to be processed and an access to a canvas object in HTML5 is performed. From this access the image content is

30 30 Desarrollo de Sistema de Información para realizar búsquedas por contenido en imágenes de satélite, mediante extracted using a method called todataurl of the canvas object. In this way the image content can be then encapsulated into an Ajax request together with all processing options, and sent to the compute server in asynchronous fashion using the HTTP protocol, and specifically a function called post. Once the web server has received the full request, a PHP funcion is used for receiving the image to be processed and the parameters needed for such task (number of classes, number of iterations, etc.) Then the compute server assigns a timestamp to the image in order to have it uniquely identified. Then the image is stored into a temporary folder. Finally the web server calls the compute server indicating the location and unique identification of the image. so that the data can be efficiently processed by the compute server (both the web server and the compute server can access the image structure and its particular location). Finally the compute server generates a final product (in our case, the processed image) from the information received, and stores the output in another temporary location. After the processing task has been completed, the web server takes again the control. It collects the final product generated by the compute server and sends it to the client in response to the original Ajax request originated at the client layer, thus closing the communication cycle with the client that originated the request Performing the actual image processing task In this subsection we describe in more details how the actual image processing task is performed at the compute server. In our system we use a high-level programming language such as C++ to perform the analysis of the input image, thus producing a final product (processed image) which is stored in a different location. As described in the previous subsection, the communication between the system layers is performed using system calls from the web server to the compute server, passing the information related with the timestamp identification and location of the original image as additional parameters. The compute server sends a signal to the web server indicating that the processing has been completed when the image has been analyzed, and also provides the identification and location of the resulting final product. A very important aspect of the layering structure adopted by our proposed system is that it is highly modular and scalable, since the system calls (in our case confined within the same machine as the web and compute server are implemented as a unique computing resource in our architecture) can be adapted to more complex and parallel processing environments,

31 31 Desarrollo de Sistema de Información para realizar búsquedas por contenido en imágenes de satélite, mediante such as the adopted multi-gpu system which will be fully exploited in future developments of the proposed system. For illustrative purposes, Fig. 8 graphically summarizes the whole image processing strategy adopted by our proposed system, from the generation of the initial request and its placement into a canvas object that contains the image to be processed, to the generation of an Ajax request in order to start the processing cycle at the web server, and ultimately to the execution of the request and the compute server and the provision of the final product (processed image) back to the client that initiated the request. An important final step of the process is to overlay the final product with the original image to be processed. As indicated by Fig. 8 this is done at the client, once the processing cycle has been finalized. The method used to perform this task is the one called putimagedata which is also a method of the canvas object. Fig. 8 reveals a highly modular design with clearly defined interactions between the different layers of the system. Finally, Fig. 9 shows a processing example of an image captured from Google Maps corresponding to the Iberian Peninsula. As indicated by Fig. 8 many classes could be identified in the considered test case, including different classes in the water areas. Visually, it can be seen that the combination of classes (a functionality that is also included in the proposed system) can lead to improved results by joining different classes (such as those belonging to water). Figure 8: A summary of the whole image processing strategy adopted by our proposed system.

32 32 Desarrollo de Sistema de Información para realizar búsquedas por contenido en imágenes de satélite, mediante Figure 9: Processing example, using the proposed system, of a Google Maps image of the Iberian Peninsula. The example shows that the classification can be refined by merging classes Saving the final obtained results We devote this section to the saving of the final results as it required a special treatment in the proposed system implementation. Specifically, the generated product is not stored in any server when the processing is completed, and it is only located in the local memory of the browser of at the client. In addition, the obtained results can be expressed in different forms, e.g. as a processed image, as a collection of layers that can be superimposed with the original data set, or as a combination of both. In order to handle the treatment of the obtained results, two specific actions have been implemented in the proposed system: 1. A JavaScript library (called canvas2image) has been used to save the contents of the canvas object in the local devide using different image formats, such as JPEG, PNG or Bitmap. 2. In order to save the combined result after putting together different layers of the obtained results into the canvas object, we have used another canvas container which integrates all the data layers to be displayed. Once the image is saved the initial container is not retained. This process is transparent to the user and it is also optimized from the viewpoint of computational performance. For

33 33 Desarrollo de Sistema de Información para realizar búsquedas por contenido en imágenes de satélite, mediante illustrative purposes, Fig. 10 shows a graphical illustration of the content of a canvas object, which is the container of both the original image capture and also of the processed image, which can be decomposed in the form of different layers after the processing is completed. Figure 10: Structure of the canvas object that contains the initial image to be processed and the outcome of the processing. 4. Experimental results In this section, we perform an experimental validation of our developed system using satellite images obtained from Google Maps engine across different locations. The validation is conducted by means of the following experiments: 1. In the first experiment, we conduct an experimental validation of the k-means unsupervised classification algorithm by selecting a satellite image over an urban area (Pavia city, Italy) which represents a challenging classification

34 34 Desarrollo de Sistema de Información para realizar búsquedas por contenido en imágenes de satélite, mediante scenario due to the presence of complex urban features. The validation has been conducted by evaluating the agreement between the classification results provided by our implemented versions of k-means with regards to those available in the well-known ENVI commercial software package. In our tests, we adopt exactly the same parameters when running our implementations and those available in the ENVI package. 2. In a second experiment, we conduct a similar analysis using a satellite image collected over the city of Mérida, Spain. This area contains archeological remains from ancient Rome and has been used in order to evaluate the possibility of using the proposed web-based tool in the context of archeologicaloriented remote sensing applications. In this experiment, we also evaluate the impact of using the ISODATA algorithm and a spatial post-processing over the considered processing chain. This experiment is based on visual assessment of the classification results obtained for the satellite images considered in previous experiments. 3. While in the previous two experiments the analyses were conducted using Google Maps images obtained at the highest level of zoom available, in a third experiment we process a satellite image obtained over the Amazon river in South-America, using a higher zoom level in order to evaluate the feasibility of using the proposed web-based tool to process much larger areas covering a wide extension of the surface of the Earth. In this experiment we also evaluate the computational performance of the server-client architecture developed for fast processing of massive data sets Experiment 1: Validation of the k-means unsupervised classification algorithm For this experiment, we have selected a satellite image over an urban area collected over the city of Pavia, Italy [see Fig. 11(a)]. This area represents a challenging classification scenario due to the presence of complex urban features. The spatial resolution of the image is approximately 1.2 meters per pixel. Fig. 11(b) shows the unsupervised classification result obtained by the proposed processing chain, using the well-known k- means algorithm, implemented to search for a total of c=6 clusters [11]. No spatial post-

35 35 Desarrollo de Sistema de Información para realizar búsquedas por contenido en imágenes de satélite, mediante processing is performed in this experiment in order to evaluate the spectral clustering performance of the algorithm without including any spatial information. (a) (b) (c) Figure 11. (a) Satellite image collected over the city of Pavia, Italy. (b) Classification using our processing chain implemented with k-means and c=6 classes. (c) Classification using ENVI s k-means implemented with the same parameters.

36 36 Desarrollo de Sistema de Información para realizar búsquedas por contenido en imágenes de satélite, mediante Table 1. Percentage of agreement (in terms of individual classes and also from a global point of view) after comparing the classification map in Fig. 11(b), produced by our tool (with the k-means algorithm) with the classification map in Fig. 11(c), produced by ENVI. Water Arid soil Grove Urban areas Semiarid soil Urban areas Overall (Cyan) (Grey) (Red) #1 (Orange) (Yellow) #2 (Green) agreement Table 2. Confusion matrix obtained after comparing the classification map in Fig. 11(b), produced by our system (with the k-means algorithm) with the classification map in Fig. 11(c) produced by ENVI. Class Water Arid soil Grove Urban areas Semiarid Urban areas (red) (Magenta) (Green) #1 (Yellow) soil (Blue) #2 (Cyan) Water (Cyan) Arid soil (Grey) Grove (Red) Urban areas #1 (Orange) Semiarid soil (Yellow) Urban areas #2 (Green) 99, , , , , , , ,073 53, , ,579

37 37 Desarrollo de Sistema de Información para realizar búsquedas por contenido en imágenes de satélite, mediante Finally, Fig. 11(c) shows the classification result obtained by the k-means algorithm implemented by Research Systems ENVI software19, using also c=6 classes. As shown by comparing Figs. 11(b) and 11(c), the color labels obtained in the different classification results are different, but the classification maps provided by our processing chain applied to the original satellite image in Fig. 11(b) and by ENVI s implementation of k-means in Fig. 11(c) are very similar. Table 1 reports the classification agreement (in percentage) [3] measured after comparing our processing chain result, based on k-means classification, with the one obtained by ENVI (assuming the latter as the reference). As shown by Table 1, the agreement between the obtained classification maps is always very high regardless of the labeling of the classes. This is also confirmed by the confusion matrix [27] displayed in Table 2. This experiment reveals that our k-means classifier is very similar to the one available in the commercial (ENVI) software Experiment 2: Validation of the ISODATA algorithm with spatial post-processing In this second experiment, we use a satellite image collected over the city of Mérida, Spain [see Fig. 12(a)]. The spatial resolution of the image is quite high, with approximately 1.2 meters per pixel. Specifically, the image in Fig. 12(a) was collected over the Roman Theater of Mérida, a construction which dates from the years 16 and 15 BC and which has undergone several renovations. The theatre is located in the archaeological ensemble of Mérida, one of the largest and most extensive archaeological sites in Spain. It was declared a World Heritage Site by UNESCO in The theatre was located on the edge of the Roman city by the walls. The grandstand consists essentially of a semicircular seating area (cavea), with capacity for 6,000 spectators eventually divided into three zones: the lowest tier called the ima cavea (22 rows), the medium tier called the media (5 rows) and a top tier called the summa, the latter in very poor state at present. Besides being the most visited monument in the city, since 1933 it is home to the development of a Festival of Classical Theatre, thus returning to its original function and transcending the mere ornament. In this experiment, we have selected this historical monument as an example of remotely sensed archeology, and have decided to adopt an improved view offered by Google 19

38 38 Desarrollo de Sistema de Información para realizar búsquedas por contenido en imágenes de satélite, mediante Maps in order to better visualize the structure and scale of this highly relevant monument for the city of Extremadura, Spain. (a) (b) (c) (d) (e) Figure 12. (a) Satellite image collected over the Roman city of Mérida, Spain. (b) Classification using our processing chain with ISODATA. (c) Classification using ENVI s ISODATA. (d) Classification using our processing chain with ISODATA with spatial post-processing. (e) Classification using ENVI s ISODATA with spatial postprocessing.

39 39 Desarrollo de Sistema de Información para realizar búsquedas por contenido en imágenes de satélite, mediante Table 3. Percentage of agreement after comparing the classification map in Fig. 12(b), produced by our tool (with ISODATA), with the classification map in Fig. 11(c), produced by ENVI, and after comparing the map in Fig. 12(d) produced by our tool (with spatial post-processing) with the classification map in Fig. 12(e) produced by ENVI (also with spatial post-processing). Clustering Sand Structure Trees Shadow Rocks Pavement Overall algorithm (red) (cyan) (grey) (yellow) (green) (orange) agreement ISODATA ISODATA with spatial postprocessing Table 4. Confusion matrix obtained after comparing the classification map in Fig. 12(b), produced by our system (with ISODATA) with the map in Fig. 12(c), produced by ENVI. Class Shadow Structure Trees Shadows Rocks Pavement (yellow) (magenta) (grey) (red) (blue) (orange) Sand (red) Structure (cyan) Trees (grey) 35, , , , ,187 0 Shadows (yellow) 0 0 2,739 45, Rocks (green) Pavement (orange) 4, , , ,298

40 40 Desarrollo de Sistema de Información para realizar búsquedas por contenido en imágenes de satélite, mediante Table 5. Confusion matrix obtained after comparing the classification map in Fig. 12(d), produced by our system (with ISODATA plus spatial post-processing), with the classification map in Fig. 12(e), produced by ENVI. Class Shadow Structure Trees Shadows Rocks Pavement (yellow) (magenta) (grey) (red) (blue) (orange) Sand (red) Structure (cyan) Trees (grey) Shadow (yellow) Rocks (green) Pavement (orange) 32, , , , , ,703 46, , , , ,440 1, , Experiment 3: Performance of the client-server architecture In this experiment we evaluate the performance of the system in terms of computational cost and processing time. The experiment consists of two main parts. First, we evaluate the performance of the proposed application using a web/compute server and three different client configurations (medium, high and very high quality of access to the Internet). Then, we discuss the impact of using a local compute server or a remote server in experiments. In all cases we use a satellite image collected by the Amazon river in South-America, using different zoom levels to illustrate the impact of this parameters which was fixed in the two previous experiments when performing the

41 41 Desarrollo de Sistema de Información para realizar búsquedas por contenido en imágenes de satélite, mediante image capture (snapshot) in the Google Maps engine. For illustrative purposes, Fig. 13(a) shows the image to be processed at a given zoom level. Fig. 13(b) shows the obtained processing result, using the k-means algorithm with c=6 classes and without spatial post-processing. Table 6 summarizes the different zoom levels that will be considered in our experiments with this scene. The table indicates the spatial resolution of each image (depending on the considered zoom level) and the size in MB of the captured image at each zoom level. Before describing the obtained timing results, we summarize in Table 7 the client-server configurations adopted in our experimental evaluation. Specifically, Table 7 describes four different scenarios given by different processing speeds, where the PC home scenario can be considered of medium quality, the PC work scenario can be considered of high quality, and the UEX LAN and Server UEX LAN scenarios can be considered of extremely high quality (in terms of bandwidth transmission). (a) (b) Figure 13. (a) Satellite image collected over the Amazon river in South-America. (b) Classification using our processing chain with k-means.

42 42 Desarrollo de Sistema de Información para realizar búsquedas por contenido en imágenes de satélite, mediante Table 6. Different zoom levels considered in the experiments with a satellite image over the Amazon river in South-America and available in Google Maps. Considered zoom level Image size (MB) Dimensions (pixels) Zoom 1 0, x 150 Zoom 2 0, x 300 Zoom 3 2, x 600 Zoom 4 10, x 1200 Table 7. Different scenarios used in the computational performance evaluation of our system. Settings External LAN External LAN UEX LAN Server UEX (PC home) (PC work) LAN CPU Intel Core 2 Intel Core 2 Intel Core 2 Duo, 2 x QuadCore Duo, 3 GHz Duo, 3 GHz 2.53 GHz Intel Xeon 2.26GHz Main memory Client browser 6 GB 4 GB 4 GB 12 GB Google Chrome Google Chrome Google Chrome Google Chrome Operating Windows Vista Windows Vista Windows 7 CentOS 6.2 system Business 32 Business 32 Professional 64 Bits Bits bits Internet down Kbps Kbps kbps 100 Mbps Internet up 1100 Kbps 1100 Kbps Hbps 100 Mbps

43 43 Desarrollo de Sistema de Información para realizar búsquedas por contenido en imágenes de satélite, mediante Table 8 shows the timing results obtained for the PC home (medium quality) scenario after processing the satellite image in Fig. 13 (with different zoom levels) using k- means with and without spatial post-processing. The measured times are subdivided into three stages: 1) the time for sending the image from the client to the server for processing; 2) the waiting time since the image is sent from the client till the client receives a response after the image has been processed; and 3) the time needed to receive the image. Similarly, Table 9 shows the timing results obtained for the PC work (high quality) scenario after processing the same image. Finally, Table 10 shows the timing results obtained for the UEX LAN (extremely high quality) scenario after processing the same image. In all cases, we can observe how the processing complexity increases with the image size (i.e. with the considered zoom level). It is also remarkable that the spatial post-processing does not significantly increase the computational complexity (despite the relatively large size of the spatial window adopted in experiments, with 7x7 pixels). Another important observation is that, as the quality of the used configuration is increased, the processing times can be significantly reduced although the proposed system performs adequately in all cases. This indicates the portability of the proposed system to different quality configurations. Table 8. Timing results obtained for the PC home scenario. Without spatial post-processing Spatial post-processing (7x7 window) Event Send Waiting Image Total Send Waiting Image Total Image Receive Image Receive Zoom 1 Zoom 2 Zoom 3 Zoom 4 2 2,6 0,125 4, ,64 0,132 4,772 7,74 9,29 0,225 17,255 7,69 9,61 0,222 17,522 30,14 33,59 1,012 64,742 30,17 34,86 0,735 65, ,2 273, ,1 273,1

44 44 Desarrollo de Sistema de Información para realizar búsquedas por contenido en imágenes de satélite, mediante Table 9. Timing results obtained for the PC work scenario. Without spatial post-processing Spatial post-processing (7x7 window) Event Send Waiting Image Total Send Waiting Image Total Image Receive Image Receive Zoom 1 0,295 2,28 0,107 2,682 0,354 1,43 0,103 1,887 Zoom 2 0,793 8,76 0,198 9,751 0,81 9,06 1,91 11,78 Zoom 3 2,39 33,03 0,337 35,757 2,45 34,29 0,335 37,075 Zoom 4 8, ,7 99,45 8, ,72 105,45 Table 10. Timing results obtained for the UEX LAN scenario. Without spatial post-processing Spatial post-processing (7x7 window) Event Send Waiting Image Total Send Waiting Image Total Image Receive Image Receive Zoom 1 0,062 1,93 0,014 2,006 0,062 1,93 0,014 2,006 Zoom 2 0,125 3,33 0,032 3,487 0,125 3,33 0,032 3,487 Zoom 3 0,247 20,01 0,062 20,319 0,247 20,01 0,062 20,319 Zoom 4 0, ,126 84,86 0, ,126 84,86

45 Seconds Seconds 45 Desarrollo de Sistema de Información para realizar búsquedas por contenido en imágenes de satélite, mediante For illustrative purposes, Fig. 14 shows a comparison between the timing results obtained in the three considered scenarios (reported on Tables 8-10) with and without spatial post-processing. From Fig. 14, several important conclusions can be derived. First and foremost, it is clear that the processing time of the application depends on the type of internet connection. Second, the processing time depends largely on the size of the image to be processed. As indicated in Fig. 14, this time will grow significantly as the zoom level becomes more detailed, in particular for the medium-quality scenario. Finally, it is also clear from Fig. 14 that the spatial post-processing increases the execution time but not significantly, regardless of the quality of the connection available. No Post-Processing Zoom 1 Zoom 2 Zoom 3 Zoom 4 Pc-Home 4,725 17,255 64, ,2 Work 2,682 9,751 35,757 99,45 Lan - Uex 2,006 3,487 20,319 84,86 Post-Processing 7x Zoom 1 Zoom 2 Zoom 3 Zoom 4 Pc-Home 4,772 17,522 65, ,1 Work 1,887 11,78 37, ,45 Lan - Uex 2,006 3,487 20,319 84,86 Figure 14. Comparison of the timing results obtained in the three considered scenarios (reported on Tables 8-10) with and without spatial post-processing.

46 46 Desarrollo de Sistema de Información para realizar búsquedas por contenido en imágenes de satélite, mediante Table 11. Timing results obtained when the compute server is implemented in the local machine. Without spatial post-processing Spatial post-processing (7x7 window) Zoom 1 0,023 5,20 0,013 5,236 0,048 4,01 0,021 4,079 Zoom 2 0,032 22,22 0,035 22,287 0,045 23,60 0,030 23,675 Zoom 3 0, ,37 0, ,635 0, ,9 0, ,19 Zoom 4 0, ,3 0, ,360 0, ,1 0, ,27 Table 12. Timing results obtained when the compute server is implemented as a (remote) cluster. Without spatial post-processing Spatial post-processing (7x7 window) Zoom 1 0,062 1,93 0,014 2,006 0,062 1,93 0,014 2,006 Zoom 2 0,125 3,33 0,032 3,487 0,125 3,33 0,032 3,487 Zoom 3 0,247 20,01 0,062 20,319 0,247 20,01 0,062 20,319 Zoom 4 0, ,126 84,86 0, ,126 84,86 To conclude this section, we perform a comparison between the processing time invested by the proposed system to perform the same image processing task described in this subsection if the compute server is implemented in a local machine with regards to the actual implementation, in which the compute server is implemented in a remote machine. Table 11 shows the processing times measured for the considered image processing scenario when the compute server is implemented in the local machine, while Table 12 reports the timing results for processing the same scene when the compute server is a remote (cluster) system. After comparing Tables 11 and 12, we can observe the significant improvements achieved by implementing the compute server as

47 Seconds Seconds 47 Desarrollo de Sistema de Información para realizar búsquedas por contenido en imágenes de satélite, mediante a remote (cluster), which offers the possibility to reduce the processing times very significantly. These improvements are graphically illustrated in Fig. 15, which reveals that the following main observations: 1) when the compute server is implemented as a local machine, the processing times are always much higher than using a remote server, even if the local processing removes communication times over the network since all work is performed on the same machine; and 2) the larger the image size, the higher the times measured for the local processing while the remote processing times do not increase so significantly. This reveals that the use of a dedicated, high-performance compute server (cluster) offers important advantages from the viewpoint of the computational efficiency of the considered application. In this case, an internet LAN connection is recommended in order to keep the communication times within reasonable levels. No Post-Processing Zoo m 1 Zoo m 2 Zoo m 3 Zoo m 4 Local Server 5,236 22, ,635319,360 Remote Server ,006 3,487 20,319 84,86 Post-Processing 7x7 Zoo m 1 Zoo m 2 Zoo m 3 Zoo m 4 Local Server 4,079 23, , ,27 Remote Server ,006 3,487 20,319 84,86 Figure 15. Comparison of the timing results obtained by the proposed system when the compute server is implemented as a local machine or as a (remote) cluster.

48 48 Desarrollo de Sistema de Información para realizar búsquedas por contenido en imágenes de satélite, mediante 5. Conclusions and future research lines This paper has described a new web-based system for computationally efficient processing of satellite images from Google Maps engine. The system has been developed using the Google Maps applications programming interface (API), and incorporates functionalities such as unsupervised classification of image portions selected by the user (at the desired zoom level) using the k-means and ISODATA clustering algorithms, followed by spatial post-processing. Most importantly, the processing of satellite images is conducted by means of a centralized server which receives the image to be processed, performs the analysis in computationally efficient fashion in a cluster of commodity graphics processing units (GPUs), and returns the classification result to the end-user. This represents an improvement over a previously development desktop application presented in [9]. Our experimental results, conducted by comparing the obtained classification results with those provided by commercial products such as the popular ENVI software package, reveal that the proposed webbased tool provides classification maps of high similarity with regards to those provided by ENVI for the same satellite imagery, but with the possibility to perform classification of any image portion available in Google Maps engine. This work will be first presented to the community in the form of a conference publication [28]. A peer-reviewed journal contribution describing the system in detail is already in process [29]. In the future, we plan to incorporate other advanced classifiers to the proposed webbased system, such as random forests and support vector machines (SVMs). Also, we would like to extend the developed tool with the incorporation of content-based image retrieval (CBIR) functionalities. For that purpose, the strategy will be based on a query system linked to feature extraction from an image repository (such as Google Maps). The retrieved features (which will comprise shape descriptors, texture features, etc.) will be stored in a database of features and used to compare the feature vector of the input query with those recorded in the database by means of a similarity function, which will provide a result to the end-user in the form of image portions (across different locations) with sufficient similarity with regards to the features in the input query. This strategy is

49 49 Desarrollo de Sistema de Información para realizar búsquedas por contenido en imágenes de satélite, mediante illustrated in Fig. 16, which suggests an overall architecture for a future CBIR system based on remote queries to an image repository which performs feature extraction tasks in order to catalog the remotely sensed images through a vector of features, which can then be used to peform the search in a database of feature vectors by means of a carefully selected similarity function. Incorporating such CBIR architecture to our proposed system will be the focus of our future research developments. Figure 16: An overview of the different modules that we plan to develop in order to include the functionality of content-based image retrieval (CBIR) in future developments of our proposed web-based application.

50 50 Desarrollo de Sistema de Información para realizar búsquedas por contenido en imágenes de satélite, mediante

51 51 Desarrollo de Sistema de Información para realizar búsquedas por contenido en imágenes de satélite, mediante Annexes A) User Manual A.1. Introducción Este Manual de usuario explica el manejo y funcionamiento de la Aplicación WPMS. Inicialmente se explicará qué es y para qué sirve la Aplicación WMPS para, posteriormente, realizar un recorrido por las funcionalidades de la Aplicación detallando su funcionamiento, configuración y opciones de procesamiento. A.1.1 Qué es WMPS? WMPS es una aplicación WEB para el procesamiento de imágenes obtenidas desde repositorios de imágenes satélites disponibles de forma gratuita en Internet. Esta aplicación utiliza, así, el repositorio facilitado por Google Maps TM. La Aplicación proporciona acceso a cualquier imagen disponible desde Google Maps y permite, posteriormente, que estas puedan ser procesadas y clasificadas según ciertos algoritmos de clasificación. Actualmente están disponibles los algoritmos o procesos Kmeans e Isodata. El sistema está abierto a futuras líneas de desarrollo para la incorporación de nuevos procesos de clasificación y funcionalidades. A.2. Acceso a la Aplicación La aplicación está alojada actualmente en un servidor perteneciente al centro de investigación CETA-CIEMAT. Se ha contado con la colaboración, muy activa, por parte de este centro lo que ha permitido utilizar los servidores existentes en sus instalaciones y que son de gran potencia de cálculo, lo que facilita el uso del sistema por la celeridad de las operaciones de procesamiento que se utilizan en dichos servidores. El acceso a la aplicación está actualmente permitido únicamente al personal de Investigación de la Universidad de Extremadura, no obstante, en un futuro se plantea el acceso a la misma para el público en general. La dirección actual de la aplicación es la siguiente:

52 52 Desarrollo de Sistema de Información para realizar búsquedas por contenido en imágenes de satélite, mediante A.3. Configuración Existen algunos valores de configuración en el sistema. Estos valores son, esencialmente, características predeterminadas para la carga de mapas y para el procesamiento de las capturas realizadas. A continuación se indican la configuración de las variables que pueden configurarse en el sistema mediante esta configuración con sus correspondientes valores. configuration.defaultwidhimage='200' configuration.defaultheightimage='300' configuration.defaultlongitud=' ' configuration.defaultlatitud=' ' configuration.defaultmapzoom=5 configuration.defaultnumberclasses=7 configuration.defaultitermax=15; configuration.defaultkmeanspp='5x5' configuration.defaultisodatapp='off' configuration.defaultisodataoptions={ max_pares_union:5, min_porc_muestra:2, max_desv_estandar:1, min_distancia_clases:3 } //Valor Por defecto del Ancho de Mapa //Valor Por defecto del Alto de Mapa //Valor Por defecto de Longitud del Mapa //Valor Por defecto del Latitud del Mapa //Valor Por defecto del Zoom de Mapa //Valor Por defecto del Nº Clases para //Procesamientos Kmeans e Isodata //Valor Por defecto de Iteraciones Máximas //para procesamiento Kmeans e Isodata //Valor Por defecto de Post-Procesado Kmeans //Valor Por defecto del Post-Procesado Isodata //Otros valores por defecto del procesado // Isodata Actualmente la configuración de estos valores es común para todos los usuarios y es administrada, por tanto, por el administrador del sistema. En un futuro se prevé que sea única por usuario y gestionada, así, por el mismo. A.4. Barra de Herramientas La barra de herramientas de la aplicación es el contenedor de las funcionalidades que provee el sistema. De ella es de donde se pueden crear mapas, capturas, controlar el nº de clases de procesamiento, etc. A continuación se detalla cada función que puede realizarse mediante la barra de herramientas. Estas funciones están habilitadas mediante iconos activos que interaccionan con las pulsaciones del usuario.

53 53 Desarrollo de Sistema de Información para realizar búsquedas por contenido en imágenes de satélite, mediante A.4.1. Creación de Mapas Mediante este icono, al pulsarlo, se crear un nuevo mapa interactivo con el usuario. Este mapa es proporcionado por Google Maps. La creación de mapas permite, así mismo, otras opciones, como las que se muestra a continuación: Alto del mapa (se carga con el valor por defecto) Ancho del mapa (se carga con el valor por defecto) Nombre del Mapa Latitud del Mapa (se carga con el valor por defecto) Longitud del Mapa (se carga con el valor por defecto) Nivel de Zoom del Mapa (se carga con el valor por defecto) Descripción Al pulsar el botón de Aceptar se crea un nuevo mapa en el contenedor de mapas del sistema con los valores introducidos. El contenedor de mapas es la parte superior de la pantalla que contiene una pestaña por cada mapa creado en el sistema, como se presenta en la imagen siguiente.

54 54 Desarrollo de Sistema de Información para realizar búsquedas por contenido en imágenes de satélite, mediante A.4.2. Obtención de Capturas Las capturas son fotos estáticas de los mapas. Estas capturas permiten obtener una imagen fija del mapa visible y posteriormente ser procesadas mediante alguna función de clasificación de las existentes en el sistema (actualmente Kmeans e Isodata). Para cada Mapa pueden realizarse tantas capturas como se desee. Por tanto existirá otro contenedor de capturas para cada contenedor de mapas. Icono creador de Capturas Contenedor de Capturas A.4.3. Actualizar Capturas Mediante esta acción se actualiza la captura actualmente seleccionada (si existe alguna) con el contenido del mapa seleccionado en ese momento. Es como un refresco de la captura original. A.4.4. Manejo de Nivel de Zoom El nivel de Zoom controla el zoom del mapa activo. Éste se controlar mediante dos eventos, por una lado el propio botón de + y - y mediante el ratón sobre el propio mapa, funcionamiento estándar de los mapas de Google Maps. La etiqueta de Zoom nos indica en todo momento el zoom en el que se encuentra el mapa, ya se actualice éste tanto por los propios botones de incremento y decremento como por el evento del ratón sobre el propio mapa

55 55 Desarrollo de Sistema de Información para realizar búsquedas por contenido en imágenes de satélite, mediante A.4.5 Procesado K-Means El procesado Kmeans es uno de los dos algoritmos de clasificación no supervisados que actualmente ejecuta el sistema. Consiste en obtener, dada una imagen, otra nueva imagen cuyos pixeles son agrupados dependiendo del color de los mismos. Se realiza una agrupación de pixeles y se asigna un color concreto a cada grupo de pixeles de colores parecidos. La imagen que se obtiene es una representación de la original que puede utilizarse posteriormente para realizar búsquedas por contenidos. Estas búsquedas se permitirán en una futura versión del sistema. Este proceso se ejecuta en un servidor externo y el tiempo de procesamiento dependerán tanto de las características de este servidor como del tamaño de la imagen a clasificar. Para imágenes no muy grandes (de hasta 1200 x 600) el tiempo estimado de procesamiento son algunos segundos. Este procesado tiene algunos parámetros que se indican en la barra de herramientas: Nº de Iteraciones Máximas: valor técnico del algoritmo de procesado Nº de Clases: número de grupos de pixeles resultantes (en el sistema se identificarán con colores) Opción de Post-Procesado: valor técnico para el algoritmo. Se selecciona del desplegable existente junto al botón de procesamiento Kmeans Botón de procesado y opción de post-procesado A continuación se muestra un ejemplo de procesamiento del mapa de España y la imagen correspondiente: Figura A.1: Ejemplo de procesamiento de imagen

56 56 Desarrollo de Sistema de Información para realizar búsquedas por contenido en imágenes de satélite, mediante A.4.6. Procesado Isodata El procesado Isodata es otro algoritmo de clasificación de imágenes. Es muy semejante al Kmeans señalado anteriormente. La forma de obtener las imágenes que devuelve este procesado es mediante el botón Isodata, que en este caso conlleva algunos otros parámetros, aparte de los parámetros indicados anteriormente para el procesamiento Kmeans y que son comunes (Nº clases, Iteraciones Máximas). Son parámetros técnicos de entrada al algoritmo y se indican a continuación: Figura A.2: Opciones de Procesamiento de Algoritmo Isodata A.4.7. Gestión de Clases El botón de Clases permite aumentar o disminuir el nº de clases de agrupamiento que indicábamos anteriormente. Eso por una parte, pero por otra, al pulsar sobre la etiqueta propia de clases se abrirá una ventana que muestra las clases existentes, el olor asignado a cada clase y si esa clase está o no visible. Una clase visible mostrará su propio color e invisible no mostrará ninguno, pudiendo verse la imagen original en los pixeles que conforman la clase. También es posible modificar los colores(r, G, B) de cada clase eligiendo el usuario el valor de cada componente. A continuación se muestra una imagen como ejemplo de gestión de clases y otra donde se muestra únicamente 3 clases visibles de la imagen procesada anteriormente de España.

57 57 Desarrollo de Sistema de Información para realizar búsquedas por contenido en imágenes de satélite, mediante Figura A.3: Configuración de Capas Figura A.4: Configuración de Capas A.4.8. Centrado del Mapa Centrar un mapa significa posicionar el centro del mapa en unas determinadas coordenadas. Estas coordenadas son la que se indican en los 2 cuadros de texto separados por una coma: