# Real-Time Stream Processing in Social Networks with RAM\({}^{3}\)S
## 4 Use Cases
### Plate Recognition  
Automatic license plate recognition (ALPR) concerns the identification of vehicle license plates from an image or video [18]. ALPR was initially developed in the UK during the 1970s ([[https://en.wikipedia.org/wiki/Automatic_number-plate_recognition](https://en.wikipedia.org/wiki/Automatic_number-plate_recognition)]([https://en.wikipedia.org/wiki/Automatic_number-plate_recognition](https://en.wikipedia.org/wiki/Automatic_number-plate_recognition))). Applications of ALPR range from electronic toll collection on pay-per-use roads to speed limit enforcement and traffic control. The key technology for ALPR is optical character recognition (OCR) on images taken by cameras. The relevance of ALPR is also demonstrated by the fact that many countries recently favored it by adopting retro-reflective plates or using fonts that can be more easily interpreted by OCR. ALPR algorithms typically follow these steps to perform plate identification:  
1. **Plate localization:** To discover the plate in the image. 2. **Plate orientation:** To correct the possible skewing of the plate. 3. **Character segmentation:** To detect actual characters within the plate. 4. **OCR:** To recognize the extracted characters. ALPR can be performed directly on the camera or on an external server. The former solution clearly requires a higher cost and its accuracy is likely to be inferior to the latter: For this, we consider  
Figure 6: Throughput for Storm and Flink. that images are taken by a number of cameras scattered throughout the territory and sent as a data stream to an ALPR system, exploiting distributed computing to take care of the amount of input data. Our implementation used OpenALPR ([[http://www.openalpr.com/](http://www.openalpr.com/)]([http://www.openalpr.com/](http://www.openalpr.com/))), an open source ALPR library written in C++, exploiting OpenCV ([[https://opencv.org/](https://opencv.org/)]([https://opencv.org/](https://opencv.org/))) for image processing and Tesseract ([[https://github.com/tesseract-ocr](https://github.com/tesseract-ocr)]([https://github.com/tesseract-ocr](https://github.com/tesseract-ocr))) for OCR. The input data stream was simulated by feeding car images to a RabbitMQ queue, which was then connected to the implemented Receiver. Car images were taken from the OpenALPR benchmark ([[https://github.com/openalpr/benchmarks/tree/master/endtoend/](https://github.com/openalpr/benchmarks/tree/master/endtoend/)]([https://github.com/openalpr/benchmarks/tree/master/endtoend/](https://github.com/openalpr/benchmarks/tree/master/endtoend/))), which includes pictures of cars taken under different light conditions with resolution with ranges \(640\times 480\), \(800\times,600\), and \(1792\times 1312\) pixels. The average image size is 368 KB with a few images having size over 1 MB. As to the effort required to implement this use case, the total number of lines of code was around 100 (this was the first use case implemented natively in RAM3S, thus no comparison is possible with the effort required to implement the system on top of the three big data platforms separately). Figure 7 shows some visual examples taken from the RAM3S application. As for the previous use case, each example shows the actual and the recognized plate ID (\"Real Subject Name\" and \"Response Subject Name\" field, respectively) and only plates included in the knowledge base are highlighted in red (examples (a) and (b)). This implementation also allowed us to perform an experiment comparing the efficiency of Flink and Storm in scaling out the stream analysis. The experimental setup was the same used in the face recognition use case. We measured the sustainable input rate by increasing the frequency with which images are fed into the RabbitMQ queue and monitoring its length. When the overall system is overloaded, the queue starts filling up and input images overflow: The previously used frequency is taken as the sustainable input rate.