MASARYK UNIVERSITY FACULTY OF INFORMATICS Receipt database with OCR scan BACHELOR'S THESIS Petr Janík Brno, Spring 2021 MASARYK UNIVERSITY FACULTY OF INFORMATICS Receipt database with OCR scan BACHELOR'S THESIS Petr Janík Brno, Spring 2021 This is where a copy of the official signed thesis assignment and a copy of the Statement ofan Author is located in the printed version of the document. Declaration Hereby I declare that this paper is my original authorial work, which I have worked out on my own. A l l sources, references, and literature used or excerpted during elaboration of this work are properly cited and listed in complete reference to the due source. Petr Janík Advisor: Ing. Lukáš Grolig i Acknowledgements I would like to thank my supervisor Ing. Lukas Grolig for bringing up an incredibly interesting assignment for this thesis. Secondly, I would like to acknowledge all my friends, family and colleagues who sent me images of receipts and took part in the survey. I would especially like to thank my sister for helping me proofread the thesis. I wish to express my deepest gratitude to my girlfriend for her endless support, encouragement and advice. ii Abstract This thesis aims to develop a mobile and desktop application to store sales receipts in a digitalised form, removing the need to keep the original. The application uses optical character recognition to extract data from a receipt image and pre-fill the database record. It utilises word embeddings to assign emojis to receipt items and image processing techniques to transform the receipt photo into a more readable form. The theoretical part introduces React Native in the context of other cross-platform development frameworks. A n emphasis is put on testing and continuous integration as an integral part of creating reliable software. iii Keywords React Native, OCR, mobile development, Android, Windows, testing, continuous integration, natural language processing, word embedding, machine learning, sales receipts, cross-platform development, image processing, OpenCV iv Contents Introduction 1 1 Existing solutions 3 2 Image data extraction 5 2.1 Optical character recognition 5 2.2 Data extraction from text 6 3 Choice of platforms 7 4 Choice of technology 8 4.1 Xamarin 8 4.2 .NET Multi-platform A p p UI 8 4.3 Flutter 9 4.4 Capacitor 9 4.4.1 Electron 9 4.5 React + PWA + Electron 9 4.6 React Native 10 5 React Native in detail 12 5.1 Creating new React Native application 12 5.1.1 Ignite 12 5.1.2 Expo 12 5.2 Native Modules 13 5.3 Platform-specific code 15 6 Development 17 6.1 Version control system commit messages 17 6.2 Component library 17 6.3 Logging 21 6.4 Testing 22 6.4.1 Unit tests 22 6.4.2 Component tests 22 6.4.3 Snapshot testing 23 6.4.4 Visual testing 24 6.4.5 End-to-end testing 27 v 6.5 Continuous integration 28 7 Implementation 30 7.1 Storage 30 7.1.1 Textual data 30 7.1.2 Image data 32 7.2 Authentication 33 7.3 Adding a receipt 35 7.3.1 Uploading image from Windows 36 7.4 Form Recognizer 38 7.5 Python API 39 7.5.1 Item categorization 39 7.5.2 Image processing 41 7.5.3 Deployment 48 7.6 Styles 49 7.6.1 Dark mode 49 7.7 Real-time user interface 51 7.8 Offline support 52 7.9 Features 52 8 Financial sustainability 55 9 Evaluation 58 9.1 Emoji assignment 59 9.2 Image processing 60 10 Conclusion 62 A Appendix 63 A . l Attachments 63 A.2 Authentication activity diagrams 64 A.3 Version control system commit messages 67 Bibliography 68 vi List of Tables 7.1 Comparison of pre-trained word embeddings models. 42 vii List of Figures 6.1 Storybookfor React Native running on a device. 19 6.2 Storybookfor Web running in a browser. 21 6.3 Chromatic user interfacefor reviewing visual change of a component. The scan icon moved up. 25 6.4 Image generated by Loki indicating a visual change to the component. The scan icon moved up. 26 7.1 Data model of Receipts Scanner. 31 7.2 Login screen of Receipts Scanner on Android. 34 7.3 Settings screen of Receipts Scanner on Android. 35 7.4 Activity diagram of adding a new receipt. 37 7.5 Comparison of an image before and after Gaussian blur. 43 7.6 Comparison of afixed and Otsu's thresholding. 44 7.7 Comparison of an image before and after dilation. 45 7.8 Photo of a receipt with detected corners. 46 7.9 Result of adaptive thresholding applied on an image without and with Gaussian blur. 47 7.10 Comparison of the original and the processed image. 48 7.11 User interface of Receipts Scanner on Android in the dark mode. 50 7.12 User interface of Receipts Scanner on Windows in the dark mode. 51 8.1 Number of stored receipts by the number of users. 56 8.2 Operational costs of using Form Recognizer compared to other services. 58 9.1 Results of a survey evaluating how accurate the emojis assigned to the receipt items were. 60 9.2 Results of a survey comparing which image of a receipt was more readable. 61 A.l User sign-in activity diagram. 64 A.2 User sign-up activity diagram. 65 A.3 Google authentication activity diagram. 66 A.4 Meaning of emojis in commit messages. 67 Introduction During everyday life, people take part in transactions. Be it grocery shopping or refuelling of a car. Despite more and more goods being offered online, offline transactions still form an important part of the overall purchases. Proof of such transactions is, in most cases, a receipt. This proof is necessary when complaining or returning goods. However, it can get tough to keep track of all the receipts, and people can be rejected when asking for a refund simply because they either did not keep their receipt or put it among all the other receipts and cannot find it. The receipt can also get damaged in such a way that it is not readable anymore. The goal of my thesis is to develop an application that would serve as a user's digital receipt database. It would allow the user to take a photo of a receipt, and by using optical character recognition, it would extract the textual information from the photo. This extracted information would be used to pre-fill the receipt record. The receipt records should be editable and searchable, e.g. by the merchant name or items bought. The application should be available on Android and Windows. In the first chapter, I describe currently available applications trying to solve this task, their main features and drawbacks. In the second chapter, I provide an overview of techniques used for data extraction from images. The next chapter focuses on choosing target platforms for which the application should be developed. The fourth chapter introduces available technologies for developing cross-platform applications. It also provides an overview of the chosen framework — React Native—which is further elaborated in the subsequent chapter. A n essential part of the thesis is testing and continuous integration. The types of testing used to ensure the high quality and reliability of the application are described in the sixth chapter. The seventh chapter describes the implementation and functionality of the application. It shows how Microsoft Form Recognizer [1] was used to extract the information from a receipt photo. This chapter also includes a description of a receipt item categorization using word 1 embeddings. The image processing using the OpenCV1 library is featured as well. The subsequent chapter is concerned with the business model of Receipts Scanner. It elaborates the costs of third-party services used in Receipts Scanner and proposes solutions for financing the application. The ninth chapter provides an evaluation of the application. The outcome of the thesis is an application named Receipts Scanner. It can be used to conveniently organize receipts and access them both from a mobile device and desktop. The patterns used in this application can be used for developing other React Native applications. 1. https://opencv.org/ 2 1 Existing solutions Applications addressing the need for unified digital storage of receipts are usually referred to as expense managers. The most popular expense manager for iOS1 is called Smart Receipts2 . It is also available on Android3 , but it is superseded by an application called Receipt Scanner4 in terms of downloads. They allow users to take photos of receipts and fill in additional information such as total price, date of purchase or expense category. These receipts can then be searched by name, price or category. Both applications provide an option to organize expenses into reports. Users can export these reports in the CSV5 format; Smart Receipts also supports PDF export. Another feature is a visualization of expenses throughout time and across categories. The main feature I will focus on is the automatic information extraction from the receipts. It is available for $0.1 per scan in Smart Receipts, as of April 2021, and it is free in Receipt Scanner. Other applications that offer this feature are Expensify6 , Receipt Lens7 and Dext8 . A l l are available for Android and iOS. The amount of information extracted from the picture is, however, limited. Usually, it includes only merchant name, total paid amount, tax amount, date, currency and category. Any information about individual items is missing. 1. Mobile operating system developed by Apple. 2. https://www.smartreceipts.co/ 3. Mobile operating system developed by Open Handset Alliance and sponsored by Google. 4. Receipt Scanner on Google Play: https://play.google.com/store/apps/details?id=com.easyexpense/. 5. Comma-separated values. 6. Expensify on A p p Store: https://apps.apple.com/au/app/expensify-receipts-expenses/ id471713959. 7. Receipt Lens on A p p Store: https://apps.apple.com/us/app/receipt-lens-receipt-scanner/ idl424280764. 8. Dext on A p p Store: https://apps.apple.com/us/app/dext-finance-and-accounting/ id418327708. 3 1. EXISTING SOLUTIONS A n open-source9 alternative to the mentioned applications is Receipt Manager1 0 . It uses Tesseract11 for text recognition from the image and a fixed set of rules to extract the information. The main idea of this project is that it does not rely on any third-party services. It is available on iOS, Android and the Web. All these clients connect to a server on which the data extraction runs. It is deployed separately as a Docker container1 2 . 9. Open-source software is software whose source code is released with permission to use, copy, distribute and modify [2]. It is usually free to use. It is often developed collaboratively on platforms such as GitHub. 10. Receipt Manager on GitHub: https: / / g i t h u b . com/ReceiptManager. 11. Tesseract is a library and a command line program for extracting textual data from images. Tesseract on GitHub: https://github.com/tesseract-ocr/ tesseract. 12. Docker containers are Docker container images run by Docker Engine. Docker container image is a standalone, executable package of software that includes everything needed to run an application. It will always run the same, regardless of the computing environment. [3] See https: //www. docker. com/. 4 2 Image data extraction On a high level, the data extraction from the photo of a receipt involves two steps: optical character recognition and data extraction from text. 2.1 Optical character recognition First, the raw textual data need to be extracted. This is done using Optical Character Recognition (OCR). OCR is the process of translating images of handwritten, typewritten, or printed text into a format understood by machines. It works by pre-processing the image1 and segmenting the text into lines, then words and eventually into individual characters to which a code, such as ASCII, is assigned. [4] The code can be assigned based on template matching. A n image of an unknown character is compared to a set of images of known characters. The code of the most similar character is chosen. The similarity can be computed as a difference between the pixel's grayscale value in the unknown character and a pixel's grayscale value in the known character [5]. This approach works well2 for receipts because the characters are printed and are thus almost the same, except for minor deficiencies in printing. Receipts also usually use the same or a very similar font. Another approach is to extract the most relevant information from the character image. This is called feature extraction. A n example of such a feature could be the density of dark pixels in a given part of the image. These features are used as inputs for machine learning models such as K-Nearest Neighbors and Support Vector Machines3 . [6] The third approach is to use a Convolutional Neural Network. It has the highest computational cost among the three mentioned approaches and requires a large dataset of images to learn on, but it has the best performance. [4] 1. Image pre-processing refers to a set of techniques (e.g. noise reduction), that are applied to the image to make it more suitable for the subsequent steps. 2. The template matching technique reached a recognition rate of 97.36% in [5]. 3. Supervised machine learning models for classification and regression problems. 5 2. IMAGE DATA EXTRACTION 2.2 Data extraction from text The second step is to assign a meaning to the parts of the extracted text. This can be done by pattern matching, dictionary matching or using more complex methods such as neural networks. Pattern matching uses the fact that some data have a specific format compared to other data available on the receipt. For example, dates and phone numbers can be extracted using regular expressions. Dictionary matching tries to find a value from a list of possible values. A n example would be finding a merchant name in a predefined list of merchants. A l l methods can take advantage of the actual text position. The merchant name is most likely to appear on the top, the individual items in the middle and the total price at the bottom. However, receipts vary significantly in the locations of different data. Therefore this method, referred to as Zone OCR, is more suitable for forms and invoices where the format is known. 6 3 Choice of platforms According to Pew Research Center [7], as of 2021, 85% of adults in the United States own a smartphone. There is no dispute about smartphone being a ubiquitous device in people's lives. Most smartphones have a decent camera that allows taking photos of receipts in sufficient quality. Hence, most of the focus has been on developing a mobile application. The next question that needs to be answered is whether to target Android, iOS or both. According to IDC's market research [8], in 2020,84.1% of smartphones were equipped with Android and 15.9% with iOS. The development of iOS applications requires a Mac1 and Xcode2 . Some workarounds exist around this limitation, but most of them rely on using a Mac in the cloud. At the beginning of the writing of the thesis, I did not have access to Mac. In order to be able to target more devices and given the mentioned limitation, I chose to develop an Android application. Although smartphones are convenient for taking the photo of the receipt right after the purchase, some users might prefer a desktop application to view and search the receipts. According to Statcounter [9], Windows3 operating system makes for 75.55% of desktop operating systems, macOS4 comes second with 16.5%5 . For the same reasons (ability to cover more devices and having Windows PC), I chose Windows as the supported desktop operating system. 1. Mac, also known as Macintosh, is a family of personal computers sold by Apple. Current models include MacBook Pro and iMac. 2. Xcode is software by Apple for developing applications for Apple products. See https://developer.apple.com/xcode/. 3. Group of operating systems developed by Microsoft. 4. Desktop operating system developed by Apple. 5. Data have been collected based on website views. 7 4 Choice of technology As established in the previous Chapter 3, the targeted platforms are Android and Windows. The traditional approach would be to implement a separate application for each platform, for Android using Java or Kotlin, and for Windows using Universal Windows Platform (UWP) or Windows Presentation Foundation (WPF). This approach suffers from the apparent disadvantage of writing the code twice. The functionality of the application differs only slightly on Android and Windows, so the preferred solution is to have a cross-platform application. A cross-platform application is an application that can run on multiple platforms without a need for having a separate code base for each. There are many available frameworks that aid cross-platform de- velopment. 4.1 Xamarin "Xamarin is an open-source platformfor building modern and performant applicationsfor iOS, Android, and Windows with .NET." [10] With Xamarin, the business logic and backend code are written in C# and fully shared. Xamarin.Forms extends this code reuse to the user interface (UI). The user interface is defined using X A M L 1 . It targets iOS, Android, and Windows. 4.2 .NET Multi-platform App UI .NET MAUI is an evolution of Xamarin.Forms. It targets Android, iOS, Windows and macOS. It is still in a preview version2 . 1. extensible Application Markup Language is a markup language based on X M L used to define user interfaces [11]. 2. Roadmap of.NET MAUI: https: / / g i t h u b . com/dotnet/maui/wiki/Roadmap. 8 4. CHOICE OF TECHNOLOGY 4.3 Flutter "Flutter is Google's UI toolkitfor building beautiful, natively compiled applications for mobile, web, and desktopfrom a single codebase." [12] It uses Dart programming language. The desktop support is available as a beta release [13]. 4.4 Capacitor Capacitor is an open-source native runtime for building Web Native3 apps. It enables development of cross-platform iOS, Android, and Progressive Web Apps [15]. Capacitor is developed by Ionic. The application is built using web technologies (JavaScript4 , H T M L 5 , and CSS6 ) and rendered using Web View. Web View resembles a fullscreen browser, but it is not limited to browser APIs7 . It can call native APIs such as sensors and storage. It is possible to create a desktop application by wrapping the web application inside Electron. Capacitor has built-in support for Elec- tron. 4.4.1 Electron Electron is a framework that enables creating desktop applications with JavaScript, H T M L , and CSS. These applications can then be run on macOS, Windows, or Linux [19]. Electron is used, for example, by Visual Studio Code and Slack. 4.5 React + PWA + Electron React is a JavaScript library for building user interfaces created by Facebook. It is one of the most used libraries for building web applications. 3. A Web application that accesses native APIs [14]. 4. JavaScript is a scripting language targeted specifically to the Internet [16]. 5. Hypertext Markup Language is a document-formatting language used to create Web pages [17]. 6. Cascading Style Sheets add style (e.g., fonts, colors, spacing) to Web documents [18]. 7. Application programming interface. 9 4. CHOICE OF TECHNOLOGY It uses JSX, which is a combination of JavaScript and X M L 8 , for example,const element = Hello {'react' .toUpperCaseO};. React is declarative and component-based, which means that complex UIs are composed of multiple simpler, independent and reusable components. The components are parametrized with properties (very often called props). React itself is not a cross-platform framework. However, if we release the constraint of having a native mobile application, it is possible to create a progressive web application (PWA). Most React starter templates provide this functionality. The PWA looks very similar to the native application. It is installed directly from a browser by visiting the website that provides the PWA. PWA can be installed both on mobile and desktop. In a similar manner to Capacitor, desktop support is possible by wrapping the React application inside Electron. 4.6 React Native React Native is a JavaScript framework created by Facebook. It is based on React, but instead of targeting the browser, it targets mobile platforms — Android and iOS [21]. There are community-supported projects9 that bring React Native to other platforms, such as React Native Windows, React Native macOS and React Native Web. It is used by companies such as Facebook, Instagram and Shopify. Unlike Capacitor, which uses Web Views, React Native is compiled into native code, allowing developers to create applications that look and feel like native applications written in Java/Kotlin (for Android) and Objective-C/Swift (for iOS). It also comes with performance ben- efits. As opposed to React, which uses elements that correspond to H T M L elements, e.g.
and

, React Native uses platformagnostic elements such as and . Those are then translated to native UI elements. It also uses its own abstraction of CSS. 8. Extensible Markup Language is a W3C open standard for describing data using embedded tags [20]. 9. https://reactnative.dev/docs/out-of-tree-platforms 10 4. CHOICE OF TECHNOLOGY React Native exposes JavaScript interfaces for platform APIs so that the applications can access platform features like the camera or the user's location. By default, React Native can run on iOS and Android. To run on Windows, React Native Windows is installed into an existing React Native application. After compiling the React Native code, the result will be a U W P application, which can run on Windows PC and other UWP supported devices such as Xbox. React Native's motto Learn once, write anywhere, means that when a developer learns the concepts and syntax of React Native, they should be able to write programs for any platform (that React Native supports). This motto is not to be confused with Write once, run anywhere., which would promise that the same code would be able to run on any platform. However, during the time, and with lots of community efforts, React Native has developed into a framework whose users usually report around 90% code reuse, which means that only 10% of code needs to be platform-specific. React Native provides easy ways to write platform-specific code that does not affect other platforms. This concept is described in Section 5.3. I chose to develop Receipts Scanner in React Native for its previously mentioned benefits, i.e. native controls, performance, a wide range of supported platforms and also due to my familiarity with React. 11 5 React Native in detail 5.1 Creating new React Native application The official way of creating a new React Native application is to use React Native CLI1 . The application produced by the CLI contains only one component. It does not use any additional libraries apart from a linter2 and a testing framework. Developing applications with React Native is often repetitive, and the same setup needs to be made for every application. To reduce the time it would take to install all required libraries and to enforce the best practices, application boilerplates have been created. 5.1.1 Ignite The most used boilerplate for React Native is Ignite3 . Ignite is a CLI and an application boilerplate at the same time. It is opinionated, meaning that it enforces specific project structure and libraries. Navigation, application state management, Storybook component library4 , Detox end-to-end tests5 and Reactotron6 (for inspecting the application) are already set up. The CLI can be used for generating new components and screens. 5.1.2 Expo Expo7 is a framework built on top of React Native. A n application created with Expo CLI can run on iOS, Android and the Web. It provides many external tools that help with the development process. Many libraries for React Native have been created by Expo. Those 1. Command Line Interface 2. A static analysis tool that highlights errors and enforces good programming practices. 3. Ignite on GitHub: h t t p s : / / g i t h u b . c o m / i n f i n i t e r e d / i g n i t e . 4. Described in Section 6.2. 5. Described in Section 6.4.5. 6. Described in Section 6.2. 7. h t t p s : / / d o c s . e x p o . i o / 12 5. REACT NATIVE IN DETAIL libraries can be often used also in applications that do not run on Expo. It is not possible to add a React Native for Windows to the Expo project. For this reason, Receipts Scanner was set up with the React Native CLI instead. Expo will likely support React Native for Windows in the future8 . In the meantime, the Expo built for the Web could be run on Windows using Electron9 . 5.2 Native Modules Native modules provide access to the native platform API that is not available by default in JavaScript [22], for example, an API to select a picture on the device. Other reasons for using native modules are taking advantage of existing native libraries or running multi-threaded code. Native modules for Android are written in Java or Kotlin. For Windows, they can be written in C++ or C#, but C++ is the preferred language, primarily due to its performance. Native modules can be written directly in the application or added as an external package. React Native Directory1 0 provides a list of available native modules. They can be filtered by the supported platform because the native module is often unavailable on all platforms that React Native supports. In my opinion, not having a native module's functionality available for a given platform is the most considerable drawback of using React Native. Most native modules are made for Android and iOS only and cannot be therefore used on the Web or Windows. The missing Windows support is an obstacle encountered many times during Receipts Scanner development. 8. Feature request to support React Native for Windows in Expo: https: //expo. canny.io/feature-requests/p/support-for-react-native-windows-apps. 9. Expo has been introduced in Section 4.4.1. 10. h t t p s : / / r e a c t n a t i v e . d i r e c t o r y / 13 5. REACT NATIVE IN DETAIL In case a native module is not available on a given platform, there are four available options: 1. Omitting the module. If the functionality provided by the native module is not critical, it might be omitted on a given platform. This is possible by having a different code for each platform. This concept is described in Section 5.3. In Receipts Scanner, this approach has been taken with Google Sign In1 1 , which is not available on Windows. 2. Mocking the module. In the context of this thesis, mocking means substituting an object or a whole module with a simpler implementation. The simpler object is called a mock. The approach of mocking a module has been applied in Receipts Scanner on Netlnfo module, which provides information about the internet connection. Currently, it is not possible to use Netlnfo on Windows1 2 . Consequently, it has been temporarily mocked on Windows always to return information about the device being online. 3. Replacing the module. In case a different module that provides similar functionality is available, it can be used instead. If such a module does not exist, it can be implemented. Receipts Scanner implements its own File Picker module to provide the functionality of picking an image from the file system on Windows. 4. Adding the missing platform to the module. Most of the modules are open-source projects to which anyone can contribute. React Native is a relatively new ecosystem and 11. Authentication using Google, further described in Section 2. 12. GitHub issue: https://github.com/react-native-netinfo/react-native-netinfo/issues/ 306. 14 5. REACT NATIVE IN DETAIL relies on community contributions. In general, anyone can add a new platform to an existing library. 5.3 Platform-specific code Sometimes it is necessary to have a different code for a different platform. The main reasons are: • some platform does not support certain functionality, or the same functionality needs to be implemented differently, • the application on a particular platform should behave differ- ently, • the styles need to be different. React Native provides two ways of separating code by platform: 1. Platform module By writing Platform. OS === ' windows ', it is possible to determine if the code is running on Windows. 2. Platform-specific file extensions If there are two files, Button. android. ts and Button. windows. ts and the Button is imported as import Button from ' . / B u t t o n ' ; , the file with the extension of the platform on which the application is running will be picked. In Receipts Scanner, the Platform module's functionality is used, for example, in the following places: • to allow scanning of a receipt only on Android, • to use different styles for each platform, • to use Google Sign In only on Android, • in Firebase adapter13 to use a different Firebase library for each platform, 13. Described in Section 7.1.2. 15 5. REACT NATIVE IN DETAIL • to use a different Modal1 4 component for each platform. Most of these were driven by libraries not having support for React Native Windows. 14. A component that appears on top overlaying other components. The background is usually grayed out. 16 6 Development 6.1 Version control system commit messages When working with a version control system1 , it is good to indicate the type of source code change in a commit message. This can be done either verbally or using an emoji. Using emojis in commit messages provides an easy way of identifying the purpose or intention of a commit. In the Receipts Scanner repository, the notation in Figure A.4 has been used. It is loosely based on Gitmojl2 . The Figure A.4 shows a Unicode3 representation of an emoji and its meaning. 6.2 Component library When developing a React application, it is a good practice to have a set of basic components from which more complex ones are built up. The set of those foundational components is called a component library or a design system. A n efficient way of building the component library is by using a tool that allows the development of each component in isolation. Storybook4 is a widely used tool for developing UI components in isolation. It is based on plugins. Thanks to its open-source nature, there are many plugins created by the community, which extend the core functionality of Storybook. Storybook is based on the concept of stories. A story is a permutation of the component with given properties. Each component can have multiple stories. A Button component could have one story displaying the Button in its enabled state and a second one for the disabled state. Storybook stories serve as a gallery of available components and as a documentation of their properties. They can be used for snap- 1. Software for tracking changes in files, for example, Git. 2. Gitmoji is an initiative to standardize and explain the use of emojis on GitHub commit messages. See https: //gitmoj i . dev/. 3. "The standard for digital representation of the characters used in writing all of the world's languages." [23] 4. h t t p s : / / s t o r y b o o k . j s . o r g / 17 6. DEVELOPMENT shot and visual tests, which are described in Sections 6.4.3 and 6.4.4 respectively. Storybook supports multiple platforms, including React and React Native. To better distinguish between the two, I will refer to Storybook for React as Storybookfor Web because React is a web framework. Whereas Storybook for Web runs in a web browser, Storybook for React Native needs to run on a mobile device because React Native uses native components that cannot be displayed in the browser. Running Storybook on a mobile device is achieved by rendering the Storybook component instead of the root component that would normally be rendered. To not have to replace the component manually in code every time, Receipts Scanner takes advantage of Reactotron5 . Reactotron is a desktop application that provides a suite of tools for easier development in React Native. It is integrated inside the project, so it is possible to switch between displaying Storybook and the actual application from the Reactotron UI. Figure 6.1 shows the component library and the interface of Storybook for React Native. 5. Reactotron on GitHub: https: / / g i t h u b . com/inf initered/reactotron. 18 6. DEVELOPMENT Filter Scan Button Raw NotProcessing Processing PrimaryButton With text With emoji GoogleSignlnButton Enabled Disabled ConfirmDelete Basic ConfirmationModal Basic FullWidthlmage Basic ImageThumbnail Basic Receiptltem Remove this item? NAVIGATOR PREVIEW ADDONS NAVIGATOR PREVIEW ADDONS (a) Components menu. (b) Detail of Confirmation Dialog component. Figure 6.1: Storybook for React Native running on a device. It is possible to install a Storybook server that enables navigation between stories from a browser. However, the stories are still displayed only on mobile device. In order to show the stories in the browser, a react-native-web6 library must be used. This library provides the same elementary components that are used to create React Native applications. The difference is that instead of translating those components into Android and iOS native components, it translates them into H T M L elements. There are two options for running the Storybook in a browser: 6. h t t p s : / / n e c o l a s . g i t h u b . i o / r e a c t - n a t i v e - w e b / 19 6. DEVELOPMENT 1. Adding Web support to the whole application. A l l react-native components are replaced by react-native-web components by aliasing react-native imports to react-nativeweb in the bundling7 process of the whole application. This makes the whole application run in a browser. The Storybook functionality is, therefore, a side-effect. The Expo8 applications can run in a browser by default. They are set up with react-native-web from the beginning. No extra configuration is necessary to have Storybook for React Native running in the browser. 2. Installing Storybook for Web. It is possible to install Storybook for Web and alias react-native imports to react-native-web in the bundling process of Storybook. This approach is used in Receipts Scanner. Figure 6.2 shows the component library and the user interface of Storybook for Web. A n advantage of this approach is that even though Storybook for React Native is in version 5, the Storybook for Web can use the latest version 6 (as of May 2021). In version 6, all stories in the projects are found automatically without having to list each story explicitly. It also uses a more concise and more intuitive syntax for writing stories. Another advantage is that the Storybook for Web can be used with other libraries for web development, such as Chromatic for visual testing, which is described in Section 6.4.4. Storybook for Web can be built into static files and served as an application independent of the React Native application. The main disadvantage is that there are two separate Storybooks in the project. A small amount of extra code needs to be written for each story to make it visible in both Storybooks. 7. Bundling is the process of transpiling all source files and assets of the application, usually into one large JavaScript file that can be run across different browsers. 8. Expo has been introduced in Section 5.1.2. 20 6. DEVELOPMENT (P s @1 Q Q 51 iPhone6(PJ [1j [J Actions ^ Q Find components n ConfirmDelete • FullWidthlmage • ImageThumbnail n Receiptltem i • TermsLink M O • A L S ConfiimationModal • Universal Modal B U T T O N S • GoogleSignlnButton ' Enabled ] Disabled ' • PrimaryButton n With Text ~ With Emoji I C O N S n Themedlonlcon > • Toastlcc-n onCancel: (1) [ClassJ onDelete: (1) [Class} If Remove Figure 6.2: Storybook for Web running in a browser. 6.3 Logging The logging in Receipts Scanner happens via methods of a LOG object. This abstraction ensures that the application does not depend on a particular logging system. A l l logs are sent to the console in development mode. WARN and ERROR level messages are sent into Sentry9 , both in development and release mode. Sentry is a third party service that collects logs, errors, and events sent through the network. This enables monitoring of the application behaviour on users' devices. 9. h t t p s : / / s e n t r y . i o / 21 6. DEVELOPMENT 6.4 Testing Testing is an integral part of developing a reliable software. The Receipts Scanner uses five types of tests: unit tests, component tests, snapshot tests, visual regression tests and end-to-end tests. Apart from visual tests, all tests use a JavaScript testing framework Jest10 that is included by default in new React Native applications. The tests run in a Node.js1 1 environment that mimics the environment of a React Native application. 6.4.1 Unit tests Unit tests cover a single piece of functionality, usually individual functions. In Receipts Scanner, their main goal is to assure that the utility functions such as RGB to H E X color conversion or receipt filtering work. Mocking When the tested function or object has any dependencies, they are often mocked out. 6.4.2 Component tests Component tests test individual React components. A n example could be a test for a Receipts List component. Let us assume that the component calls an API and displays the returned receipts. The test would mock the API call by returning a fixed list of receipts and then assert that those receipts are visible. In React Native, there is an option to choose between two libraries for component tests: react-test-renderer and React Native Testing Li- brary. react-test-renderer renders components to pure JavaScript objects without depending on the D O M 1 2 or a native mobile environment [24]. It provides methods for locating elements, for example, by component 10. h t t p s : / / j e s t j s . i o / 11. Node.js is a JavaScript runtime. See https: //nodej s. org/. 12. Document Object Model. 22 6. DEVELOPMENT type (e.g. Text) or properties (e.g. finding a button with t i t l e value equal to Submit). It is possible to get the rendered component as a JSON1 3 and use it for snapshot testing. Snapshot testing is described in Section 6.4.3. The issue of testing with react-test-renderer is that the tests rely on implementation details of the components. React Native Testing Library solves this problem by providing utility functions on top of react-test-renderer [26] for locating elements, e.g. by the visible text or accessibility label so that tests resemble how users interact with the application. It is inspired by React Testing Library [26], which is a widely used testing library for React. React Native Testing Library also adds a f ireEvent method that can simulate press, scroll and text changed events. Thus, both the rendering of the element and interaction with it can be tested. Mocking Because the components are rendered with react-test-renderer into pure JavaScript objects without depending on a native mobile environment, any native modules need to be mocked. 6.4.3 Snapshot testing Snapshot tests verify that the rendered markup of the components stays the same. When the snapshot tests are run for the first time, the rendered markup is saved in a file. During subsequent runs, the newly rendered markup is compared to the saved one. The tests fail when there are differences between the two. Those differences are usually highlighted for the developer to assess whether or not this change was intentional. If it was, the saved snapshots are updated. Otherwise, the unintentional changes are fixed. It is possible to create snapshot tests with Jest and react-test-renderer by rendering the component to JSON and comparing it to the previously rendered version1 4 . This process can be automated with Storybook. Using a Storybook addon StoryShots15 , all stories in the project 13. JavaScript Object Notation is a lightweight data-interchange format [25]. 14. See snapshot testing with Jest: https: / / j e s t j s . io/docs/snapshot-testing. 15. https://www.npmj s.com/package/Qstorybook/addon-storyshots 23 6. DEVELOPMENT are turned into snapshot tests. This is a very efficient and inexpensive way of testing because the stories most of the time already exist. Snapshot testing catches only changes in markup. If, for example, an image on a given URL changes, the snapshot tests will still pass. On the other hand, changing markup does not necessarily mean that the result is different. It is often the case that even though the markup has changed, the page looks the same as before, and the tests report false positives. It can be hard to tell whether the change is intended, especially when dealing with large snapshots. Mocking Because the StoryShots addon uses react-test-renderer internally to render the components and save their snapshot, any native modules need to be mocked. 6.4.4 Visual testing Visual testing addresses the issues of snapshot testing mentioned earlier. It is not crucial if the markup changed. The important thing is whether the component looks as desired. Visual tests, also called visual regression tests, assure that once the expected look of a component was achieved, it will stay unchanged. Visual testing compares screenshots of newly rendered components with the old screenshots, also called reference images. When visual tests run for the first time, a set of screenshots is made. During subsequent runs, those screenshots are compared to the stored ones. Possible differences are highlighted. There are various tools that can highlight the differences between images. Those tools can be independent of tools used to take the screenshots. A widely used tool for visual testing in React community is Chromatic1 6 . It creates screenshots of the Storybook stories. It is not possible to use Chromatic with Storybook for React Native. Nonetheless, Receipts Scanner repository uses Storybook for Web too, by utilizing react-native-web. The Chromatic is therefore set up for testing components with Storybook for Web. 16. https://www.chromatic.com/ 24 6. DEVELOPMENT ScanButtonRaw:Not Processing DOM D I F F © ligu r-1777fci r-15nkf81 r-lotgn73 r-l±6wzkk r - l r v i b r r-195 lr-37igu r-lh&zSmd r-15nkfBl r-lertgn73 r-liBwzkk r - l r v i b r r le: normal; font-weight: normal;">[] -style: normal; fcnt-weight: normal; ">•

Figure 6.3: Chromatic user interface for reviewing visual change of a component. The scan icon moved up. Chromatic runs in the continuous integration (CI) pipeline1 7 . The changes need to be reviewed on the Chromatic website created for the given CI run. Chromatic also publishes the Storybook as a website. Figure 6.3 shows how the review process of a visual change in Chromatic UI looks. Both the visual change and the change in the markup are visible. A n alternative to Chromatic is a tool called Loki1 8 , which also integrates with Storybook. It can take screenshots in a Chrome browser, on an iOS simulator or on an Android emulator, which means that it can be used both with Storybook for Web and Storybook for React Native. Loki creates images that highlight the visual change. A visual change of a Scan Button component is shown in Figure 6.4. 17. A series of steps executed when changes are pushed to the remote project repository. Described in Section 6.5. 18. h t t p s : / / l o k i . j s . o r g / 25 6. DEVELOPMENT r r j j Figure 6.4: Image generated by Loki indicating a visual change to the component. The scan icon moved up. I would not recommend using Loki for Storybook for React Native. The tests are unstable, and the Screenshots differ even though the component itself has not changed. This is caused by the component not being fully loaded when the Screenshot is made. Loki uses a running Storybook server for controlling which story is shown, which sometimes does not work, resulting in flashing between different stories. Loki performs better with Storybook for Web, but it cannot take Screenshots of modal components. The third approach of visual testing I tried was a combination of Storycap1 9 and Reg Suit2 0 . Similar to Chromatic, Storycap and Reg Suit work only with Storybook for Web. First, Storycap takes Screenshots of the stories. Reg Suit then downloads the previous Screenshots from Google Cloud Storage, compares them with the new ones and stores the differences. Storycap and Reg Suit should run in the CI pipeline. From my experience, Reg Suit had issues determining the hash of the previous commit. This hash is used to pick correct images from the Google Cloud Storage bucket for comparison. For this reason, all stories were being reported as new, and no comparison took place. Naturally, it is not good to use all three solutions for visual testing together. I would suggest using only Chromatic because it has a fast setup, provides a clean user interface for reviewing the changes, and seems the most reliable solution among those I have tried. 19. Storycap on GitHub: https: / / g i t h u b . com/reg-viz/storycap. 20. Reg Suit on GitHub: h t t p s : / / g i t h u b . c o m / r e g - v i z / r e g - s u i t . 26 6. DEVELOPMENT Similarly to snapshot tests, the visual tests are created automatically from stories. The visual testing is therefore very convenient. Mocking Visual tests require Storybook to be running. If the Storybook is running on an Android device, no mocking is necessary. If Storybook for Web is used, native modules that do not have web support need to be mocked. The need for mocking can be alleviated by separating the view part of the application from the business logic. The components can be divided into two categories: pure and connected. Pure components are components that display data based on their properties. Connected components connect to the database, make API calls and depend on native modules. They pass the data to pure components. In general, stories are written for pure components. This way, no mocking of native modules is needed. 6.4.5 End-to-end testing End-to-end tests are used to test user interaction with the application from the beginning to the end. A n example of an end-to-end test would be testing the sign-in functionality, i.e. after the required fields of the sign-in form are filled in, and the Sign in button is pressed, a screen for the authenticated users is shown. Multiple end-to-end testing frameworks for React Native exist. Receipts Scanner uses Detox2 1 end-to-end tests. Detox is a popular choice for React Native testing, mostly for its speed and reliability. Apart from test logs, it can capture screenshots and videos of the running tests, providing greater insight into why tests are failing. A more recent project, Cavy2 2 , takes a different approach from Detox. It does not use any native code. A l l functionality is achieved with pure JavaScript. This makes the setup more straightforward, but the functionality is limited. 21. Detox on GitHub: https: / / g i t h u b . com/wix/Detox. 22. h t t p s : / / c a v y . a p p / 27 6. DEVELOPMENT Whereas Detox can locate elements by text or label, Cavy needs each component that is being tested to be wrapped with a special function. This creates noise in the code The oldest testing framework of the ones mentioned is Appium2 3 . Similar to Selenium WebDriver2 4 , it uses WebDriver protocol2 5 . It could be used for testing both the Android and the Windows version of Receipts Scanner. Appium tests are referred to as black-box tests. Black-box testing ignores the internal mechanism of a system and focuses solely on the outputs generated in response to selected inputs and execution conditions [27]. In practise this means, that when a certain element is expected to be visible, Appium polls until the element becomes visible or until a timeout occurs. This usually leads to flaky and nondeterministic tests. Detox has been created to address this issue. Detox tests are socalled gray-box tests, which means that the tests are aware of the internal state of the application. Detox automatically waits until all asynchronous operations (such as querying a server or animations) end, and only then is the assertion triggered. Mocking Because the Detox tests run on the device (Android or iOS), the native modules need not be mocked. It is still possible to mock external dependencies to make the tests faster and more stable. 6.5 Continuous integration Continuous integration is a practise of frequently merging code changes into a central repository. The changes are validated by creating a build and running automated tests. [28] Receipts scanner takes advantage of GitHub Actions2 6 . Every time new code is pushed to the main branch of the GitHub repository, three 23. h t t p : / / a p p i u m . i o / 24. Selenium is software for automated testing of web applications. 25. WebDriver protocol is used to control the browser. 26. https://github.com/features/actions 28 6. DEVELOPMENT workflows are run. A workflow consists of multiple jobs that run in parallel. Each job consists of multiple sequential steps. During the first workflow, • the code is checked for any linting or type errors, • a suite of unit and snapshot tests runs, • Storybook is deployed and visual tests run, • a release version of Android application is built, • a release version of Windows application is built. The second workflow runs end-to-end tests on an emulated A n droid device. The third workflow runs tests of the Python API2 7 . The workflows do not contain the Python API deployment logic. Instead, a repository hook is set up in the Google Cloud Platform Console2 8 to deploy the latest version of the Python API. 27. Python API is described in Section 7.5. 28. A user interface to manage services provided by Google. 29 7 Implementation 7.1 Storage The Receipt Scanner needs to store two kinds of data: textual data, i.e. data about the receipts and the users' credentials, and the receipt images. 7.1.1 Textual data For textual receipt information, document-oriented databases are a perfect fit because they make it easy to store data in the same format and shape as they are used in the application. The document-oriented database is a type of NoSQL1 database that stores data in the form of documents. A l l data of a given object (for example, receipt) can be stored in one document. The documents are stored mostly in JSON, BSON2 , X M L or Y A M L 3 format. Unlike SQL databases, document-orient databases do not have a schema. This makes them more flexible. The documents are stored in collections. Documents can also contain subcollections of documents. Two very popular document-oriented databases are MongoDB4 and Google Firestore5 . MongoDB uses BSON to store documents, Firestore uses JSON. Both databases support data types such as strings, numbers, arrays and timestamps6 . Although document-oriented databases do not have a schema, it is beneficial to have a fixed data model so that the shape of the stored data is predictable. The data model for Receipts Scanner is shown in 1. NoSQL database is a database that does not employ the relational model of data [29]. 2. Binary JSON. 3. Y A M L is a human-readable data serialization language. 4. https://www.mongodb.com/ 5. https://firebase.google.com/products/firestore 6. Supported data types in MongoDB: https://docs.mongodb.com/manual/ reference/bson-types/. Supported data types in Google Firestore: https: / / f irebase .google. com/docs/ firestore/manage-data/data-types. 30 7. IMPLEMENTATION Users collection User id (PK) string email string name string I Receipts collection Receipt id (PK) string added timestamp currency string merchantAddress string merchantName string merchantPhoneNumber string subtotal number tax number tip number total number transactionDate timestamp urIOriginal string urIProcessed string id (PK) string name string price number quantity number totalPrice number Figure 7.1: Data model of Receipts Scanner. Figure 7.1. It shows how the data are structured into two collections, Users and Receipts. Because all user data are child nodes of a given user document, it is easy to restrict access to other documents based on the path to that document. The authentication and access rules are described in Section 7.2. Although the item forms a separate entity, it is not a document but only an object in the array of items of the receipt. Other notable fields are urIOriginal and urIProcessed, which specify the URL address of the original receipt photo and a processed photo, respectively. 31 7. IMPLEMENTATION 7.1.2 Image data Although storing images directly in the document-oriented database would be possible7 , this solution is not optimal. For receipt images, the most cost-effective storage is object storage. Object storage is storage optimized for storing BLOBs (Binary Large Objects). BLOB is a collection of binary data stored as a single entity. It can be, for example, an image, audio or video. The images are stored inside Users//Receipts/ directory. This folder structure enables restricting access to images based on the value of . I have chosen Google Firestore to store the textual data and Google Storage to store the photos of receipts. These two cloud-based services are available under a platform called Firebase. The Firebase platform also provides authentication and analytics services to Receipts Scanner. Firebase is supported on iOS, Android and the Web. A n unofficial library named React Native Firebase8 provides the same services on React Native for Android and iOS. However, it does not support React Native Windows. Consequently, Receipts Scanner uses Firebase for Web on Windows and React Native Firebase on Android. To be able to write the same code that could be run both on Android and Windows, an adapter f irebase .ts was created. It imports both libraries, and, based on the platform the application is currently running on, it exports the proper objects. The rest of the code that needs to work with Firebase imports the objects from f irebase. ts instead of importing them directly from Firebase for Web or React Native Firebase. In theory, the Receipts Scanner could use Firebase for Web both on Android and Windows, but I would expect React Native Firebase to be more suitable and faster since it uses native APIs. React Native Firebase could also get support for React Native Windows in the future. 7. In MongoDB, it is possible to store BSON documents up to 16 M B . Larger files can be split into parts of 255 kB using GridFS [30]. 8. h t t p s : / / r n f i r e b a s e . i o / 32 7. IMPLEMENTATION 7.2 Authentication "Authentication is the process of verifying an entity's identity, given its credentials." [31] In Receipts Scanner, users are being authenticated. The authentication in the application serves two purposes. The first one is the ability to connect saved receipts with the user who created them. The second reason for authentication is to ensure proper database rules. The rules are set so that only authenticated user can create a new User document9 . The user can read and modify the User document if they are authenticated and if the document belongs to them. The last rule ensures that each user can create, read and modify only their receipts inside the Receipts collection and not receipts of other users. When the user first launches the application, a login screen is displayed. The login screen is depicted in Figure 7.2. It consists of two text input fields and three buttons. The first input field is for email, and the second is for password. It is possible to display the entered password in plain text form by pressing the eye icon next to the password input. Based on the user's preference, they can choose one of the two supported authentication mechanisms: 1. Authentication with email and password Figure A . l shows how the process of a sign-in with email and password looks. The form offers a real-time validation, so the user is instantly notified if they have entered an invalid email or a password. The validation is shown in Figure 7.2b. Figure A.2 shows the process of a registration with email and password. 9. Documents and data model of Receipts Scanner have been introduced in Section 7.1. 33 8:16 @ I r Receipts scanner 7. IMPLEMENTATION 0 Email £ Password 9 ^ Sign in / Sign up with Google ^ Privacy Policy 0 Terms; & ConditionsQ Privacy Policy Receipts scanner 0 invalid-email r fi Invalid email format 9Password must be at least 8 characters long >i+h n.r>r>n\a 1 2 3 4 5 6 7 8 9 0 q w e r t y u i o p a s d f g h j k I O z x c v b n m < x ] o (a) Empty login form. (b) Form with validation errors. Figure 7.2: Login screen of Receipts Scanner on Android. 2. Authentication with a Google account Figure A.3 shows authentication flow using Google Sign In1 0 native module. Authentication with Google is not available in the Windows version of Receipts Scanner because the Google Sign In library does not support React Native Windows yet1 1 . 10. Google Sign In on GitHub: https://github.com/react-native-google-signin/google-signin. 11. GitHub issue that tracks adding of support of Google Sign In for Windows: https://github.com/microsoft/react-native-windows/issues/6531. 34 7. IMPLEMENTATION What all three workflows have in common is that the user's session is persisted even if the application is restarted. If a user wanted to use a different account, they could sign out in the settings screen, depicted in Figure 7.3. Clicking the Sign out button ends the session and redirects the user back to the login screen. C2b You are connected to the internet. Export receipts Sign out Figure 7.3: Settings screen of Receipts Scanner on Android. 7.3 Adding a receipt The main functionality offered by Receipts Scanner is adding a receipt and storing it in the user's collection of receipts. This process is visu- 35 7. IMPLEMENTATION alized in Figure 7.4. It starts by the user selecting an already existing photo of a receipt from a gallery or by taking a new photo with the phone camera. The photo can be cropped to remove the background. It can also be rotated. The rotation does not have any effect on the result of OCR. It affects only how the photo will be shown to the user in their receipts collection. Next, three sequences of processes happen asynchronously: • The image of the receipts is sent to Form Recognizer API. The returned data (structured text information extracted from the image) is sent to the Python API /category endpoint, where emojis are added to all items that have been recognized on the receipt. Form Recognizer and Python API are described in Sections 7.4 and 7.5, respectively. • The image is uploaded to Firebase Storage. • The image is sent to the Python API /process-image endpoint. The endpoint returns a processed grayscale image that is then uploaded to Firebase Storage. At the end, the receipt document is added to the user's receipt collection in Google Firestore, and the edit form is shown. The benefit of the asynchronicity of those processes is that the whole process is much faster than if it happened synchronously. Adding a receipt takes under 8 seconds on average12 . 7.3.1 Uploading image from Windows On Android, the image capture and selection from the gallery is provided by library react-native-image-crop-picker1 3 . However, this library does not support Windows. A library react-native-documentpicker1 4 used to provide a file selection feature for Windows but is incompatible with the current version of React Native for Windows. 12. Based on measurements of 10 different receipts. 13. https://github.com/ivpusic/react-native-image-crop-picker 14. https://github.com/rnmods/react-native-document-picker 36 7. IMPLEMENTATION 7. IMPLEMENTATION For this reason, a native C++ module File Picker was implemented. It allows to pick an image from the Windows Explorer and returns an object containing the path to the image, MIME type1 5 and the image data encoded as Base6416 . This module is then used in the JavaScript code. However, the image upload functionality is not complete on Windows because Firebase Storage for Web uses Web APIs that are not available in React Native running on Windows. A n option to overcome this issue would be finding cloud storage that supports the upload of Base64 strings, preferably without any library, using only REST API. The File Picker module could be eventually released as a separate package, so that it could be used by other React Native developers. 7.4 Form Recognizer Form Recognizer is a cloud service by Microsoft for extracting structured information from documents [1]. It provides a pre-built model that is suitable for recognizing English receipts [32]. It can be accessed through a JavaScript client library1 7 . However, this library is built for Node.js runtime, which is different from the React Native runtime. In most cases, React Native uses JavaScriptCore, which is the JavaScript engine that powers Safari [33]. Receipts Scanner implements a service FormRecognizerClient with the same interface as the one from the official library, but it relies solely on API calls to the Form Recognizer API. The method to extract the information from the receipt is modelled as a long-running operation, which means that the initial request returns a URL to which the subsequent requests for the result should be made. After FormRecognizerClient is created, its beginRecognizeContent method is called with the image that should be processed with the OCR service. The method returns an instance of a P o l l e r . The P o l l e r provides a method p o l l U n t i l D o n e that repeatedly sends requests to the Form Recognizer API until the result is available. 15. M I M E (Multipurpose Internet Mail Extensions) type identifies the format of data transmitted on the internet. 16. Base64 is an encoding that encodes binary data into ASCII text. 17. https://docs.microsoft.com/en-us/javascript/api/overview/azure/ ai-form-recognizer-readme?view=azure-node-latest#recognize-receipts 38 7. IMPLEMENTATION The final response from the Form Recognizer contains multiple fields1 8 , such as merchant name, merchant address, transaction date and time, total price, items in the receipt with their name, quantity, price per item and total price for all pieces of the given item. Every field has information about the location in which it was found, i.e. bounding box and a confidence value from zero to one. 7.5 Python API The Python API is a service that runs separately from Receipts Scanner. It serves two purposes: to process an image of a receipt and to categorize receipt items. It provides three endpoints1 9 : • GET / — Returns a health check string. It is used to make sure that the service is running. • POST /category — Expects a JSON containing an item name, possibly consisting of multiple words. It returns a category of that item and an associated emoji. • POST /process-image — Expects a form-data containing an image. It returns a JSON containing the processed version of the image as a Base64 string and the image MIME type. 7.5.1 Item categorization In order to make the application more visually attractive and to improve the user experience, each item on the receipt is assigned an emoji. The emoji is chosen based on the words that appear in the item name. If the user is not content with the automatically assigned emoji, they can remove it in the receipt edit form. 18. Form Recognizer API documentation: https://westcentralus.dev.cognitive.microsoft.com/docs/ services/form-recognizer-api-v2-l-preview-2/operations/ GetAnalyzeReceiptResult. 19. Detailed documentation of the endpoints is available at https: //documenter. getpostman.com/view/9355808/TzJsfdUK. 39 7. IMPLEMENTATION When a user adds a new receipt, the items on the receipt are sent to the Python API / category endpoint. The service contains a dictionary of category names as keys and emojis as values. Each item name is compared to all dictionary keys by using method most_similar_to_given and the key that is most similar to the item name is returned, together with the emoji. The method most_similar_to_given is provided by the Magnitude library [34]. Magnitude is a tool for utilizing and processing word embeddings. Word embeddings are typically real-valued vectors that encode the meaning of a word, such that the vectors that are close in the vector space are similar in their meaning [35]. Magnitude is a fast and memory-efficient alternative to tools like Gensim2 0 . It uses its own vector storage file format .magnitude. Popular embedding models such as Google's word2vec, Stanford's GloVe and Facebook's fastText have been pre-converted to the . magnitude format for download and usage2 1 . Furthermore, each word embeddings model is available in three variants: light, medium and heavy. The difference is that medium and heavy models have advanced support for out-of-vocabulary keys2 2 . The heavy model also features faster approximate K-Nearest Neighbors2 3 . Magnitude implements functions for looking up vector representations for misspeled or out-of-vocabulary words. This means that it can handle abbreviations, which often appear on receipts, and whole sentences reasonably well. The interface of the library is agnostic to the underlying model. In Receipt Scanner, the fastText model is used — more specifically, its medium variant, as only the exact similarity search is performed, so there is no need for faster approximate K-Nearest Neighbors. The light variant is not used because it handles item names that contain multiple words poorly. Another constraint for choosing the model was its size. Google Cloud Run, a cloud service where the model is running, does not 20. https://radimrehurek.com/gensim/ 21. Pre-converted Magnitude models for download: https : //github.com/plasticityai/magnitude#pre-converted-magnitude-formats-of-popular-embe< 22. Words that do not appear in the model's vocabulary. 23. A supervised machine learning algorithm for classification and regression prob- lems. 40 7. IMPLEMENTATION allow containers larger than 8 GB. Google's medium word2vec model is 4.9 GB large compared to fastText, which is only 1.6 GB large. The container with word2vec did not fit into the 8 GB limit. The used fastText model was pre-trained on over 16 billion words from Wikipedia 2017, Statmt.org news and U M B C news [36]. It contains only English word vectors. However, fastText provides models for other languages24 , which could be converted using the Magnitude converter25 and used in a localized Receipts Scanner, e.g. with support for the Czech language. Table 7.1 shows results from various word embeddings models. The first two columns are produced by Google's word2vec, which was trained on 100 billion words from Google News [37]. The third column is fastText. The fourth column is fastText with subwords information. In the subwords model, each word is represented as a bag of character n-grams. Taking the word where and n = 3 as an example, it will be represented by the following character n-grams: < wh, whe, her, ere, re > and the special sequence < where >. The less-than sign < and the greater-than sign > are special boundary symbols. [38] The results show that the case matters, e.i. CHUPA LOLLIPOPS and Chupa lollipops are categorized differently, and how more concrete terms are mapped to more general terms, e.i. salmon and cola are categorized as fish and cold beverage respectively. 7.5.2 Image processing The image processing happens independently of the OCR. The image sent to the Form Recognizer API is the original image because it uses its own image processing techniques and provides better results on original images. The purpose of image processing in the Receipts Scanner is to provide a cleaner preview of the receipt for the user. The result is a 24. Word vectors for 157 languages: h t t p s : / / f a s t t e x t . c c / d o c s / e n / c r a w l - v e c t o r s . h t m l . 25. https://github.com/plasticityai/magnitude# file-format-and-converter 41 7. IMPLEMENTATION Table 7.1: Comparison of pre-trained word embeddings models. item name word2vec word2vec fastText fastText subwords medium item name light medium medium fastText subwords medium salty snack 8> santa claus ® snack ® snack ® snack C H U P A L O L L I P O P S c/j field hockey * candy ^ candy ^ lollipop Chupa lollipops H floppy disk "* candy % lollipop ®s lollipop salmon • f i s h • fish • fish • fish shampoo lotion lotion lotion lotion ipad air I air condition 1 iphone 1 iphone 1 iphone manual ?3 woman's * weight weight « weight weight hat lifting lifting lifting frozen pizza ^ hot pepper 1 pizza pizza ^ pizza Cola 11 fKi woman's _f cold i cold chocolate Cola 11 sandal beverage beverage bar eggs J egg J egg ' egg J egg T M A T C H E D D A R M floppy disk cheese cheese & cheese pork loin chop Js motor scooter ^ hot dog " pork " pork 42 7. IMPLEMENTATION CHUPA LOLLIPOPS FRUITELLA HIPPOS DR PEPPER ZERO REV MULTIVITS S IRON 1SOS MULIV 1PK QRIP SCOURER STRAYfBERY FRUIT SMILES CHUPA LOLLIPOPS TOTAL TO PAY CARD TENDER CHANGE DUE CHUPA LOLLIPOPS FRUITELLA HIPPOS 3R PEPPER ZERO REV MULT1VITS * IRON 180S MULTY 4PK QRIP SCOURER STRAWERY FRUIT SMILES CHUPA LOUIPOPS 0.10 0.99 0.49 1.99 0.39 0.99 0.10 TOTAL TO PAY CARD TENDER CHANGE DUE 38.67 38.67 0.00 (a) Before Gaussian blur. (b) After Gaussian blur. Figure 7.5: Comparison of an image before and after Gaussian blur. cropped picture with black text on a white background. The whole process consists of the following steps: 1. Image loading The image is loaded in a grayscale. 2. Noise removal Gaussian blur is applied to reduce the Gaussian noise in the image. It is the most common type of noise in an image [4]. The blur is achieved by convolving the image with a Gaussian function. G { X ' V ) = 2 ^ 6 ~ ^ ' { 7 1 ) where x and y are the distances from the origin in the horizontal and vertical axis, respectively. o~ is the standard deviation of the Gaussian distribution. [4] The result of applying Gaussian blur is shown in Figure 7.5. 3. Binary thresholding It is beneficial to convert the images to binary images to detect the edges and contours better. Binary thresholding sets pixel value to the maximum value — usually 255 (white) — if 43 7. IMPLEMENTATION CHJPA LOLLIPOPS O.W r RUIT£LLA HIPPOS 0.99 IB PEPPER ZERO 0-S =E« MULTIVITS S IRON 130S 1.99 M'JLTY 4PH BRIP SCOURER 0.39 STRAWBERY FRUIT SMILES 0.99 X'jPA LOLLIPOPS 0.10 TOTAL TO PAV CARD TENDER CHANGE DUE 38.67 38.67 0.00 CHUPA LOLLIPOPS thresh (72) 0 otherwise In Equation 7.2, src(x,y) is a value of a source pixel on coordinates x and y and dst(x,y) is a value of destination, i.e. resulting pixel, on coordinates x and y. The threshold value can be either fixed, e.g. 127, or computed from the image. Finding the right value for the fixed thresholding is challenging, and each image might have a different optimal threshold value. Otsu's thresholding calculates the threshold value dynamically from the histogram of each image, such that the found threshold maximizes the between-class variance [39]. Classes are black and white pixels. Figure 7.6a shows the result of applying fixed binarization with a threshold value of 127. The edges of the receipt in this image would not be correctly recognized because the threshold value is too small. Figure 7.6b shows the result of applying Otsu's thresholding, which automatically found a threshold value of 151. The edges are clearly visible. 44 7. IMPLEMENTATION 4. Dilation In order to determine the edges of the receipt more easily, the image is dilated. Dilation increases the size of the grid lines. Before performing dilation, the image has to be inverted. Otherwise, an opposite effect, erosion, would be achieved. It is necessary to invert the image back before contour detection, which is described in the next step. A kernel slides through the image the same way as in 2D convolution. A pixel is considered white if at least one pixel in the original image under the kernel is white. The result of applying dilation is shown in Figure 7.7. I CHUPA'LOLLIPOPS • • S f c A ' L b U J W S FRUITELLA HIPPOS J . » • • FRUITELLA HIPPOS » • » DR PEPPER ZERO J . « • • w pfppQ) 2 0 » 0 . « REV MULTIVITS 8 IRON 180S 1 . » • • REV MULTIWTS « IRON IMS 1 . » MULTY 4PK GRIP SCOURER I 0.39 • • ^ j , ^ QRIP SCOURER ) 0.39 STRAWERY FRUIT SMILES 0-99 • • STRAWERY FRUIT SMILES 0.99 CHUPA LCU-IP0PS _0.10 • • s*JI>A L0LUP0PS __0.10 TOTAL TO PAV 3B.S7 I I TOTAL TO PAY 3B.S7 CARD TENDER 38.87 • • CARD TENDER 3B.67 CHANGE DUE 0.00 • • CHANGE DUE 0.00 (a) Before dilation. (b) After dilation. Figure 7.7: Comparison of an image before and after dilation. 5. Finding the corners of a receipt As the next step, all external contours in the image are found. Contour is a curve joining points of the same color and intensity. The contour with the largest area is most probably the contour of a receipt. Four points that represent the corners of the receipt are then found in the contour and returned. The idea behind finding the corners is that the bottom-left corner has the smallest x coordinate and the largest y coordinate, the bottom-right corner has the largest x a y coordinates etc. The result of this step is visualized in Figure 7.8. However, if the contour area is smaller than 30% of the overall image, the next step, Cropping and warping, is skipped. 45 7. IMPLEMENTATION Figure 7.8: Photo of a receipt with detected corners. 6. Preparing the underlying picture The previous steps were used to find the corners of a receipt. Although Otsu's thresholding made the edges of the white receipt clearly distinguishable from the dark background, the text of the receipt became unreadable. With receipts scans, the situation is different. Since scans usually do not have any background, Otsu's thresholding maximizes the contrast between the paper and the text instead of the contrast between the paper and the background. For receipt photos, adaptive thresholding is a better choice. This is also caused by shades in the photos, which are not present in scans. With adaptive thresholding, the threshold value for each pixel is based on a small region around it. This method gives better results for images with varying illumination. [40] OpenCV library provides two methods of computing the adaptive threshold. It can be computed as the mean of the neighbor- 46 7. IMPLEMENTATION CHUPA LOHLlPOPS FRUITELLA HJ.P°0S 1 DP PEPPER ZERO s, . • REV t'ULTI .'ITS .S IRON lSCb. MULrY 4PK 8RIP SCOURER, ' STRMBEPY FRUIT SMIufi1 j. J I M TOTAL TO PAV \ , CARD TENDER \ CHANGE DUE 38.67 38,67 " B A CHUPA LOLLIPOPS FRUITELLA HIPPOS \ DR PEPPER ZERO v 'v - REV HULTIVITS 8UR0N 180S MULTY 4PK GRIP SCOURER STRAWBERY FRUIT SMILES • CHUPA LOLLIPOPS TOTAL TO PAY \ CARD TENDER \ CHANGE DUE \ 0.10 0.99 0.'19 1.99 0.39 0.99 0.10 38.67 . 38.67 0.00 (a) Without Gaussian blur. (b) With Gaussian blur. Figure 7.9: Result of adaptive thresholding applied on an image without and with Gaussian blur. hood area minus a constant C or as a Gaussian-weighted sum of the neighborhood values minus the constant C. Empirically, the Gaussian method with C = 2 produced the best results. Before the adaptive thresholding is applied, the original image is blurred using Gaussian blur. This improves the result significantly, as can be seen in Figure 7.9. 7. Cropping and warping Lastly, a perspective transformation (warping) is applied to the underlying photo produced by the previous step. The found quadrilateral, represented by four corners, is warped into a rectangle of a similar size. This step also crops the receipt from the background. A comparison of the original image and the final processed image is shown in Figure 7.10. 47 7. IMPLEMENTATION Top Bran* Berry-den Retai 1 P L AberdeenfcB253SG FLASH SPFEDHOP KIT *6 WIPES P/DY VEGAN STRAW PROT TUB 1KG MAUI MASK BAMBOO 340ML EVEREADY FLOOR ANTI BAC WIPES BRADBURYS PISTACHIOS AOL-A SOFT SPONGE ASTROPLAST FIRST AID KIT R03 COMPOSTABLE CADDY LINERS 25PK CHUPA LOLLIPOPS FRUITELLA HIPPOS DR PEPPER ZERO REV MULTIVITS a IRON 1S0S MULTY 4PK GRIP SCOURER \ STRAWBERY FRUIT SMILES CHUPA LOLLIPOPS 9 . * 12.99 1.99 0.79 1.99 0.39 4.99 0.99 0.10 0.99 0.39 0.99 0.10 TOTAL TO PAY 38.67 CARD TENDER 38.67 CHANGE DUE 0.00 VAT 9 20.00% Net 30.57 VAT 6.11 VAT ) 0.00» Net 1.99 VAT 0.00 PL EASE RETAIN YOUR RECEIPT. Vol will need it 1n case of product exoftanga, refund or warranty c l a i m . [j Morris Ltd WWW.tJnorris.co.uk VAT NUMBIU: 320093700 23/04/2] 19:30 TILL1 JUTAMA-^ M 970641 hommm—Top Brands Bottom Prices I Berryden Retail Park , / Aberdeen AB25 3SG FLASH SPEEDMOP KIT +6 W I P E S ; P/OY VEGAN STRAW PROT TUB 1KG MAUI MASK BAMBOO 340ML EVEREADV" .'FLOOR ANTI BAC WIPES BRADBURYS1 PISTACHIOS AQUA SOFT SPONGE ASTROPLAST FIRST AIO KIT R03 COMPOSTABLE1 CADDY LINERS 25PK CHUPA LOLLIPOPS FRUITELLA HIPPOS DR PEPPER ZERO i /V , REV MULTIVITS 8> IRON 180S MULTY 4PK GRIP SCOURER . STRAWBERY FRUIT SMILES '/': CHUPA LOLLIPOPS 9.49 12.99 1.99 0.79', 1.99' 0.39 4.99 0.99 0.10 0.99 0.49 1.99 0.39 0.99 0.10 TOTAL TO PAY \ CARD TENDER \ CHANGE OUE \ 38.67 . 38.67 0.00 VAT 8 20.00ÍS VAT/8 0:00% Net Net 30.57 VAT 1.99 VAT 6.11 0.00 PLEASE RETAIN YOUR RECEIPT. Voli «111 need It In case of product exchange, refund or warranty claim [J Morris Ltd M f . t j n o r r l s ' i VAT NUMBER: 320093700 970644 "<»•rts.co.uk 23/04/21 19:30 TILL1 JUTAMAS M V / ,,,,,„,,, I, Illlllllllllllllllllllllllll (a) Original image. (b) Processed image after adaptive binarization and perspective transfor- mation. Figure 7.10: Comparison of the original and the processed image. 7.5.3 Deployment The Python API is a Flask2 6 server. It is automatically deployed after each push to the master branch. First, Google Cloud Build2 7 builds a Docker image that contains the source files, external dependencies and the Magnitude word embeddings model. The built image is saved into Google Container Registry2 8 . Google Cloud Run2 9 then runs the image in a container. If the image is not built successfully or the Python API service fails to start, the previously deployed service stays available. The newly deployed Python API service is tested with tests that run in the repository CI pipeline. 26. h t t p s : / / f l a s k . p a l l e t s p r o j e c t s . c o m / e n / 1 . 1 . x / 27. https://cloud.google.com/build 28. https://cloud.google.com/container-registry 29. https://cloud.google.com/run 48 7. IMPLEMENTATION 7.6 Styles Apart from black and white, the Receipts Scanner user interface uses two main colors. The primary color is malachite, #078331 and the secondary is #310783 ^ 1 . The primary color has been chosen to resemble the color of banknotes. The secondary color is one of the three colors of malachite's triadic colors3 0 . The colors are chosen with respect to the contrast ratio between each other as well as the contrast ratio between those two colors and black and white. This is especially important in the dark mode. Most of the elements are styled with these two colors to ensure a clean and consistent user interface look. 7.6.1 Dark mode Receipts scanner switches automatically into the dark mode based on the user's device settings. The dark mode is a popular feature among users. It helps reduce digital eye strain and saves battery on devices with O L E D 3 1 screen. Figure 7.11 shows the user interface with the dark mode enabled on an Android device. Figure 7.12 shows the application in the dark mode on Windows. 30. The color triad was generated using color-hex tool available at https: //www. color-hex.com/color/078331. 31. Unlike L C D screens that illuminate using a back panel that always lights up completely in O L E D displays, each pixel is individually lit. 49 7. IMPLEMENTATION My receipts Q H Mcdonald's Restaurant for 7.27. Mon May 10 2021 e • FALMOUTH RAW BAR for 219.81 Mon May 10 2021 - o • Primo Family Restaurant for $ 32.47. Mon May 10 2021 e 11 SUKHOTHAI SUKHOTHAI SUSHI + ASIAN FUSION for $28.04. Mon May 10 2021 •WINGS & THINGS for 9.5. Mon May 10 2021 e 1GRAND LUX CAFE for 69.25. Mon May 10 2021 e Morrisons for $ 27. Mon May 10 2021 o JB L .DL for $ 20.68. = • Mon May 10 202**"" My Receipts ^^^^^^r e © Sellings • (a) List of receipts. 4- Items Add Name • Garlic Fries Quantity Price Total Price © e 1 2 12 Name W Drink of the Day Quantity Price Total Price B © 1 14 9.75 • © My Receipts ^. ' Settings -4 • • (b) Receipt items. Figure 7.11: User interface of Receipts Scanner on Android in the dark mode. 50 7. IMPLEMENTATION Figure 7.12: User interface of Receipts Scanner on Windows in the dark mode. 7.7 Real-time user interface The receipts are always up to date. Any change in the receipt database for a given user is almost instantly reflected on all other devices where that user is logged in. This means that a user can scan a receipt on the mobile and fill in the receipt information from the PC. If they decide to delete the receipt, the receipt disappears from the other device as well. This functionality is possible thanks to Google Firebase. 51 7. IMPLEMENTATION 7.8 Offline support The application works partially offline. Suppose a user is offline and makes any changes to an already existing receipt (edits a receipt, adds a receipt item, deletes a receipt). In that case, the change is reflected in the application UI on the device where the changes were made. Once the user connects to the internet, the changes propagate to the database and other user's devices. The offline changes are persisted even if the application is turned off. This functionality is provided by the Google Firebase library. The receipt scanning functionality is not possible in an offline mode. If a user tries to scan a receipt without an internet connection, an alert modal window is shown to them. Ideally, the image would be stored locally, and its thumbnail would be shown among other receipts with a status of being processed. After the device connected to the internet again, the image would be sent to Form Recognizer, which would return the extracted data, and the user could complete the pre-filled form. Another approach would be to use a local model instead of Form Recognizer that would extract the receipt data. This way, the user could complete the complete journey of adding a receipt at once, and the receipt data and the image would be sent to the APIs later on. Microsoft Form Recognizer does not provide an option to export the model, even if it was a custom one. Therefore a different O C R and data extraction approach would be needed. Furthermore, if the offline model was too large, it should be an opt-in feature of Receipts Scanner. 7.9 Features This section provides an overview of the functionality available in the Receipts Scanner. Unless stated differently, the feature is available on both platforms, i.e. Android and Windows. • Authentication - Sign-in/registration with email - Sign-in/registration with Google — only on Android 52 7. IMPLEMENTATION - Email format validation - Password length validation - Preview of password in plain text on toggle • Adding of receipt — only on Android - Picking the receipt image from gallery - Taking a photo of the receipt - Receipt image cropping and rotation - Automatic data extraction from the photo that pre-fills the form - Automatic insertion of emoji to each receipt item • Receipt preview - Preview of the original image - Preview of a processed image for better readability - Purchase date, merchant name, merchant address, merchant phone number, total price, subtotal, tax, tip and currency. - List of receipt items with emoji, name, quantity, price and total price. • Receipt editing - Editing of purchase date, merchant name, merchant address, merchant phone number, total price, subtotal, tax, tip and currency. - Form fields validation - Fluent navigation between form fields and submitting of form using keyboard only - Ability to add, edit and delete a receipt item • Searching through receipts by merchant name, merchant address and individual names of receipt items • Receipt deletion 53 7. IMPLEMENTATION • Dark mode that reflects system settings • Real-time changes • Partial offline support • Internet connectivity notification — mocked on Windows • Export of receipts data and images • Notification toast messages 54 8 Financial sustainability The Receipts Scanner uses paid third-party services, namely: • Microsoft Form Recognizer for OCR and data extraction, • Google Cloud Build, Google Container Registry and Google Cloud Run for the deployment of Python API container, • Google Firebase for document database and image storage. The Firebase Authentication is free. It would be necessary to run the application for some time to figure out the usage statistics, such as the average number of receipts a user uploads. Since those statistics are not available yet, I will provide an estimate of the operational costs. Let us assume that the application has 1000 active users, where each user makes one scan per day on average. The price for Microsoft Form Recognizer is $0.01 per scan [41]. This means the total cost of this service would be 10,000 • 30 • $0.01 = $300.00. The size of an uploaded image is around 500 KB, the processed image is smaller, around 100 KB large. The price of storing the textual data is negligible compared to other costs and would be lost in the approximations. Cloud Firestore is a very cheap storage [42] and its free tier provides storage for 1 GB, which is about 400,000 averagesized receipts1 . Whereas the number of scans is linearly proportional to the number of users, the numbers of stored receipts grows quadratically. It can be expressed recurrently as: s(t) = or as a function of t: s- +r-u-t i f f > l 0 otherwise (8.1) s(t) = r -^- • t • (t + 1), (8.2) 1. The size of a stored receipt, 2500 K B , was computed using the firestore-size library available at https: / / g i t h u b . com/alekslario/f i r e s t o r e - s i z e . 55 8. FINANCIAL SUSTAINABILITY Figure 8.1: Number of stored receipts by the number of users. where t is a point in time (e.g. month), r is the number of receipts per user per chosen time period (in this case month) and u is the number of new users at the end of the chosen time period (i.e. at the end of a month). Since we assume one receipt per user per day, r = 30. Assuming 1000 new users per month, u = 1000. Substitution of the values into Equation 8.2 gives s(t) = 15,000 •£ • (t + 1). (8.3) A graph of this function is shown in Figure 8.1. The images of receipts are stored in Google Cloud Storage. The price is $0,026 per GB [43]. For the first month, the cost would be 1000 • 30 • (600 KB/1 GB) • $0,026 = $0,468. For the second, assuming 1000 new users, it would be $1,404. The Google Container Registry is charged the same way as Google Cloud Storage [44], depending on the size of all stored containers. Even though storing only the newest container would suffice, it is good to keep a few previous containers as well. It is then possible to go back to these containers, should the newest one have any errors. Older containers can be deleted2 . This means that the price for the stored containers will be fixed. The size of one Python API container 2. Google provides an automated way of deleting old containers available at https: //github.com/sethvargo/gcr-cleaner. 56 8. FINANCIAL SUSTAINABILITY is 2.7 GB. The price of storing the five latest containers would be 5 • 2.7 • $0.02 = $0.27 per month. Google Cloud Run provides autoscaling, which means that the number of provisioned instances depends on the number of incoming requests. If a minimum number of instances is set to zero, the service goes idle each time the requests are not coming. The service is set up to use 2 CPUs and 6 GB of memory. For each receipt, one request is made to process the image and one to assign categories to items, resulting in 1000 • 30 • 2 = 60,000 requests per month. Assuming that each request comes after the previous request ended and that each request takes 1000 ms, the service will be used only for 120,000 vCPU-seconds3 . This is included in the free plan. Memory consumption would be 480,000 GiB-seconds4 , which slightly exceeds the free plan [45], incurring $0.3 of additional costs. If a minimum number of instances was set to one in order to prevent a cold start, the cost would be $66.00 per month. Building a container using Google Cloud Build takes approximately 9 minutes. The price is $0,016 per build-minute [46]. Assuming three builds per day due to code changes pushed to the master branch, the cost per month is 3 • 9 • $0,016 • 30 = $12.96. The total operational cost per month with 1000 users would be $314.00, i.e. $0,314 per user. From Figure 4, it is apparent that most of these costs are due to the O C R service. For this reason, other applications offer the feature of automatic data extraction only after paying a fee. Smart Receipts charges $0.1 per one O C R scan (as of April 2021). Therefore, the Receipts Scanner would need to have its own OCR service, which would be free, or become monetized. In my opinion, inapp advertising, such as AdMob5 , would not generate enough revenue. A subscription-based model seems like a more viable option. The third option would be combining the two previous approaches: a limited number of scans and visible advertisement for non-subscribed users, and an unlimited number of scans and removed advertisement for the subscribed ones. 3. vCPU-seconds are calculated as number of CPUs x running time of service (sec). 4. GiB-seconds are calculated as size (GiB) x running time ofservice (sec). 5. Mobile app monetization from Google. 57 95.5% Form Recognizer 4.5% Other services Figure 8.2: Operational costs of using Form Recognizer compared to other services. 9 Evaluation The application has not been given to real users yet. Hence, there is no available feedback concerning usability, performance and the overall user experience. The Form Recognizer API used for OCR and data extraction from an image is a third-party service, and as such, measuring its performance would provide little value compared to the rest of the thesis. It would become more important if the current data extraction was insufficient, which would be best found by users in practice. Quantifying how well Form Recognizer extracts the data from the photo would require a labelled set of receipts. One such set is available as part of the ICDAR2019 Competition on Scanned Receipt OCR and Information Extraction [47]. It provides 1000 labelled receipt scans1 as well as an evaluation technique. However, the labels from this dataset contain only company, date, address and total. Form Recognizer can recognize other information, such as phone number and individual items, too. Furthermore, the main use case in Receipts Scanner is 1. A corrected set of the original images is available on GitHub: https: / / g i t h u b . com/zzzDavid/ICDAR-2019-SR0IE. 58 9. EVALUATION recognition of photographed receipts, not receipt scans. Therefore a different dataset would be needed. A questionnaire was given to 28 people. It consisted of two parts: evaluation of automatically assigned emojis and comparison of the processed image to the original image regarding readability. 9.1 Emoji assignment This section aims to evaluate how accurately the emoji chosen by the categorization service inside Python API fits the text. The text is the name of a receipt item recognized by Form Recognizer, consisting of one or more words. Receipts contain very often abbreviations and names of brands. The categorization service cannot handle those items in a meaningful manner. The assigned emojis in this case are rather arbitrary. A n example to illustrate this is P/DY VEGAN STRAW PROT TUB 1KG classified as &, teddy bear or DR PEPPER ZERO classified as f key. Another challenge is assigning emojis to restaurant receipts, which often contain peculiar names of dishes. Seventy items2 have been selected from the data extracted by Form Recognizer on various receipts, excluding items incorrectly classified as a receipt item and items with which the respondents would be unfamiliar. Duplicates and similar items have not been included in this set either. For each item and its assigned emoji, the task was to choose whether the emoji is Not accurate, Mildly accurate or Accurate. As can be seen in Figure 9.1, in the majority of cases, i.e. 53.8%, the chosen emoji was not accurate. Only in 20.8% of cases was the emoji considered accurate. This feature of Receipts Scanner is meant to bring an element of fun into the application, and as such, its functionality is not critical. 2. A l l items from the survey are inserted in the archive in the Information System of Masaryk University A . l . 59 9. EVALUATION Figure 9.1: Results of a survey evaluating how accurate the emojis assigned to the receipt items were. 9.2 Image processing The purpose of this section is to evaluate whether the processed images provide any benefits over the original images. Thirty receipt photos have been processed using Receipts Scanner. The original and processed images have been placed side by side3 . The task was to choose which image was more readable. As presented in Figure 9.2, respondents found 54.5% of the processed images more readable than the original image. Sixteen receipts were from the ExpressExpense [48] dataset, and fourteen were taken with modern phone cameras for the purpose of this survey. A l l new images and one image from the ExpressExpense dataset were considered more readable in the processed form by most respondents. Two ExpressExpense images had an equal number of votes for each option. The common feature of ExpressExpense receipts is that they have lower quality than the newly taken photos. These results show that the image processing provides a more readable form of the original image if the original image is of sufficiently good quality. Based on the survey results, the image processing feature of Receipts Scanner will provide value to users, as most modern smartphones can take images of high quality. For the individual cases when 3. A l l images from the survey are inserted into the archive in the Information System of Masaryk University A . l . 60 9. EVALUATION 54.5% Processed 45.5% Original Figure 9.2: Results of a survey comparing which image of a receipt was more readable. the image processing produces worse or even unreadable images, the original image is still available to the users. 61 10 Conclusion The aim of my thesis was to develop an application that would allow users to take a photo of a receipt and pre-fill the database record with the information extracted from the image. The receipts are stored in a central repository and can be accessed from mobile and desktop application written in React Native. The users of the application can search through the receipts, view and edit them. Compared to similar available applications, the newly developed application can extract information about individual receipt items, automatically assign an emoji based on the item category and provide a receipt preview in a more readable form. The thesis focuses on development and testing of cross-platform React Native applications. The desktop application can be further enhanced with features currently available only on mobile as React Native for Windows develops. Future development of the application could also include support for multiple languages and offline data extraction. The source code of the application is publicly available on GitHub1 and can be used as a reference for developing other React Native applications. 1. https://github.com/petr7555/bachelors_thesis_accounting_ocr 62 A Appendix A.l Attachments Files inserted into the archive in the Information System of Masaryk University: • receipts_scarmer.zip — Source code of the application. • thesis . pdf — Text of the thesis in PDF. • questionnaire_materials .zip — Receipt items and images that have been used in the evaluation survey. • screenshots.zip — Screenshots of Receipts Scanner on A n droid/Windows in light/dark mode. • receipts_scanner. apk — Android application package for installation of Receipts Scanner. The latest application source code can be found on GitHub: • https://github.com/petr7555/bachelors_thesis_accounting ocr 63 A . APPENDIX A.2 Authentication activity diagrams Figure A . l : User sign-in activity diagram. 64 A . APPENDIX A . APPENDIX Figure A.3: Google authentication activity diagram. 66 A . APPENDIX A.3 Version control system commit messages £fe I n i t i a l commit. ST** Implementing a new feature. Fixing a bug or issue ^ Improving structure / refactoring the code. \'//( Work in progress. ^ Improving performance. S Updating documentation or readme. ^ Dealing with security. X Removing code or f i l e s . 7 Adding or updating tests. O Updating dependencies. Figure A.4: Meaning of emojis in commit messages. 67 Bibliography 1. What is Form Recognizer? [Online]. Redmond, Washington, USA: Microsoft, 2021-03-15 [visited on 2021-04-01]. Available from: https : / / docs . microsoft . com / en - us / azure / cognitive - services/form-recognizer/overview. 2. Definition of Open Source [online]. Stamford, Connecticut, USA: Gartner [visited on 2021-05-18]. Available from: https : //www. gartner . com/en/information-technology/glossary/open- source. 3. What is a Container? [Online]. Redmond, Washington, USA: Microsoft, 2021-03-15 [visited on 2021-05-21]. Available from: https://www.docker.com/resources/what-container. 4. SHREYA, Sakshi; UPADHYAY, Yash; M A N C H A N D A , Mohit; V O H R A , Rubeena; SINGH, Gagan Deep. Optical Character Recognition using Convolutional Neural Network. In: 2019 6th International Conference on Computing for Sustainable Global Development (INDIACom) [online]. 2019, pp. 55-59 [visited on 2021-04-25]. ISBN 978-9-3805-4434-2. Available from: https://ieeexplore.ieee.org/document/8991268. 5. ZIEGAUS, Marco. Optical Character Recognition on supermarket receipts [online]. Passau, Germany, 2016-06-19, chap. 5.4.3, Template matching [visited on 2021-04-01]. Available from: https : //www . fim . uni-passau . d e / f ileadmin/dokumente/ fakultaeten/fim/lehrstuhl/sauer/geyer/BA_MA_Arbeiten/ BA-ZiegausMarco-201607 . pdf. Bachelor's thesis. University of Passau, Faculty of Computer Science and Mathematics. 6. SINGH, Pritpal; BUDHIRAJA, Sumit. Feature extraction and classification techniques in OCR systems for handwritten Gurmukhi Script-a survey. International Journal of Engineering Research and Applications (IJERA) [online]. 2011, vol. 1, no. 4, pp. 1736-1739 [visited on 2021-04-25]. Available from: http: //citeseerx. i s t . psu . edu /viewdoc/ download?doi = 10 . 1 . 1 . 299 . 7852&rep = repl&type=pdf. 68 BIBLIOGRAPHY 7. Mobile Fact Sheet [online]. Washington (D.C.), USA: Pew Research Center, 2021-04-07 [visited on 2021-04-17]. Available from: https : / / www . pewresearch . org / internet / fact - sheet/mobile/. 8. Smartphone Market Share [online]. Needham, Massachusetts, USA: IDC Corporate USA, 2021-04-08 [visited on 2021-04-17]. Available from: https : //www. idc . com/promo/smartphone-market- share/os. 9. Desktop Operating System Market Share Worldwide [online]. Dublin, Ireland: Statcounter, 2021-03 [visited on 2021-04-17]. Available from: https : / / gs . statcounter . com / os - market - share / desktop/worldwide. License: C C BY-SA 3.0. 10. What is Xamarin? [Online]. Redmond, Washington, U S A : Microsoft, 2020-05-28 [visited on 2021-04-17]. Available from: https : / / docs . microsoft . com / cs - cz / xamarin / get - started/what-is-xamarin. 11. HERMES, Dan; M A Z L O U M I , Nina. Building Xamarin.Forms Mobile Apps Using X A M L : Mobile Cross-Platform X A M L and Xamarin.Forms Fundamentals. In: New York, New York, USA: Apress, c2019, chap. 2, Building Xamarin.Forms Apps Using X A M L , pp. 43^4. ISBN 978-1-4842-4030-4. Available from DOI: 10.1007/978-1-4842-4030-4. 12. Flutter - Beautiful native apps in record time [online]. Mountain View, California, USA: Google [visited on 2021-04-17]. Available from: https: / / f l u t t e r . d e v / . 13. Desktop supportfor Flutter [online]. Mountain View, California, USA: Google, 2021-05-17 [visited on 2021-05-19]. Available from: https://flutter.dev/desktop. 14. Web Native [online]. Madison, Wisconsin, USA: Ionic [visited on 2021-05-18]. Available from: https://webnative.tech/. 15. Capacitor: Cross-platform native runtimefor web apps [online]. Madison, Wisconsin, USA: Ionic [visited on 2021-04-17]. Available from: https: //capacitor j s. com/. 69 BIBLIOGRAPHY 16. Definition of Javascript [online]. Stamford, Connecticut, USA: Gartner [visited on 2021-05-18]. Available from: https : //www.gartner.com/en/information-technology/glossary/ javascript. 17. Definition ofHTML [online]. Stamford, Connecticut, USA: Gartner [visited on 2021-05-18]. Available from: https: //www. gartner. com/en/information-technology/glossary/html-hypertext- markup-1anguage. 18. Cascading Style Sheets [online]. W3C, 2021-05-13 [visited on 2021-05-18]. Available from: https: //www. w3. org/Style/CSS/. 19. Quick Start Guide [online]. San Francisco, California, USA: OpenJS Foundation, 2021-05-13 [visited on 2021-05-19]. Available from: https://www.electronjs.org/docs/tutorial/quick-start. 20. Definition of Extensible Markup Language (XML) [online]. Stamford, Connecticut, USA: Gartner [visited on 2021-05-20]. Available from: https : //www . gartner . com/en/inf ormation- technology/glossary/xml-extensible-markup-language. 21. E I S E N M A N , Bonnie. Learning React Native : building mobile applications with JavaScript. In: Sebastopol, California, USA: O'Reilly Media, 2015, chap. 1, What Is React Native? ISBN 978-1- 4919-2900-1. 22. Native Modules Intro [online]. Menlo Park, California, USA: Facebook, 2021-03-12 [visited on 2021-04-15]. Available from: https: //reactnative.dev/docs/native-modules-intro. 23. Unicode [online]. Unicode, 2021-02-10 [visited on 2021-05-19]. Available from: https: //unicode. org/glossary/#unicode. 24. Test Renderer [online]. Menlo Park, California, USA: Facebook, 2021 [visited on 2021-05-13]. Available from: https : //react j s. org/docs/test-renderer.html. 25. ECMA-404 [online]. 2nd ed. Geneva, Switzerland: Ecma International, 2017-12 [visited on 2021-05-19]. Available from: https: //www.ecma-international.org/wp-content/uploads/ECMA- 404_2nd_edition_december_2017.pdf. 70 BIBLIOGRAPHY 26. Getting Started [online]. Wroclaw, Poland: Callstack, 2021 [visited on 2021-05-13]. Available from: https: / / c a l l s t a c k . github. i o / react-native-testing-library/docs/getting-started/. 27. GAO, Jerry Zeyu; TSAO, H.-S. Jacob; WU, Ye. Testing and Quality Assurance for Component-Based Software. In: Norwood, Massachusetts, USA: Artech House, c2003, chap. 6, Black-box testing methods for software components, ISBN 978-1-5805-3480-2. 28. Continuous Integration [online]. Chicago, Illinois, USA: Martin Fowler, 2006-05-01 [visited on 2021-05-10]. Available from: https: / / martinfowler . com / a r t i c l e s / continuouslntegration . html. 29. A Comparison ofNoSQL Database Management Systems and Models [online]. New York, New York, USA: DigitalOcean, 2014-02-21/ 2019-08-09 [visited on 2021-04-20]. Available from: https: //www. digitalocean.com/community/tutorials/a-comparison-of nosql - database - management - systems - and - models. License: CC BY-NC-SA 4.0. 30. GridFS [online]. New York, New York, USA: MongoDB, 2021-04-08 [visited on 2021-04-20]. Available from: https : //docs.mongodb.com/manual/core/gridfs/. 31. C A N K A Y A , EbruCelikel. Authentication. In: ed. by TILBORG, Henk C. A. van; JAJODIA, Sushil. Boston, Massachusetts, USA: Springer US, 2011, pp. 61-62. ISBN 978-1-4419-5906-5. Available from DOI: 10.1007/978-l-4419-5906-5_772. 32. Form Recognizer prebuilt receipt model [online]. Palo Alto, California, USA: Docker, 2021-04-30 [visited on 2021-05-20]. Available from: https://docs.microsoft.com/en-us/azure/cognitive- services/form-recognizer/overview. 33. JavaScript Environment [online]. Menlo Park, California, USA: Facebook, 2021-03-12 [visited on 2021-05-02]. Available from: https://reactnative.dev/docs/javascript-environment. 34. PATEL, Ajay; SANDS, Alexander; CALLISON-BURCH, Chris; APIDIANAKI, Marianna. Magnitude: A Fast, Efficient Universal Vector Embedding Utility Package. In: Proceedings of the 2018 Conference on Empirical Methods in Natural Language Processing: 71 BIBLIOGRAPHY System Demonstrations [online]. Brussels, Belgium: Association for Computational Linguistics, 2018, pp. 120-126 [visited on 2021-04-01]. Available from DOI: 10.18653/vl/D18-2021. 35. JURAFSKY2020, Daniel; H . JAMES, Martin. Speech and Language Processing: A n introduction to natural language processing, computational linguistics, and speech recognition. In: [online]. 3rd ed. draft. c2020, chap. 6, Vector Semantics and Embeddings [visited on 2021-04-29]. Available from: https: //web. Stanford.edu/~jurafsky/slp3/6.pdf. 36. MIKOLOV, Tomas; GRAVE, Edouard; BOJANOWSKL Piotr; P U H R S C H , Christian; JOULIN, Armand. Advances in Pre-Training Distributed Word Representations. In: Proceedings of the International Conference on Language Resources and Evaluation (LREC 2018) [online]. 2018, chap. 3, Training data, pp. 2-3 [visited on 2021-04-29]. Available from: https://arxiv.org/pdf/1712.09405.pdf. 37. voordlvec [online]. Mountain View, California, USA: Google, 2013-07-30 [visited on 2021-05-20]. Available from: https : //code.google.com/archive/p/word2vec/. 38. BOJANOWSKL Piotr; GRAVE, Edouard; JOULIN, Armand; MIKOLOV, Tomas. Enriching Word Vectors with Subword Information. Transactions of the Association for Computational Linguistics [online]. 2017, vol. 5, p. 137 [visited on 2021-04-29]. ISSN 2307-387X. Available from DOI: 10.1162/tacl_a_00051. 39. G O N Z A L E Z , Rafael C ; WOODS, Richard E. Digital Image Processing: Third Edition. 3rd ed. Upper Saddle River, New Jersey, USA: Pearson Prentice Hall, 2008. ISBN 978-0-1316-8728-8. 40. Image Thresholding [online]. OpenCV, 2021-04-02 [visited on 2021-05-08]. Available from: https : / / docs . opencv . org / master/d7/d4d/tutorial_py_thresholding.html. 41. Cognitive Services Pricing - Form Recognizer API [online]. Redmond, Washington, USA: Microsoft [visited on 2021-04-28]. Available from: https : / / azure . microsoft . com / en - us / pricing/details/cognitive-services/form-recognizer/. 72 BIBLIOGRAPHY 42. Cloud Firestore Pricing [online]. Mountain View, California, USA: Google, 2021-05-17 [visited on 2021-05-18]. Available from: https://cloud.google.com/firestore/pricing. 43. Cloud Storage Pricing [online]. Mountain View, California, USA: Google, 2021-05-17 [visited on 2021-05-18]. Available from: https://cloud.google.com/storage/pricing. 44. Container Registry Pricing [online]. Mountain View, California, USA: Google, 2021-05-17 [visited on 2021-05-18]. Available from: https://cloud.google.com/container-registry/pricing. 45. Cloud Run Pricing [online]. Mountain View, California, USA: Google, 2021-05-17 [visited on 2021-05-18]. Available from: https://cloud.google.com/run/pricing. 46. Cloud Build Pricing [online]. Mountain View, California, USA: Google, 2021-05-17 [visited on 2021-05-18]. Available from: https://cloud.google.com/build/pricing. 47. H U A N G , Zheng; C H E N , Kai; H E , Jianhua; BAI, Xiang; K A R A T Z A S , Dimosthenis; L U , Shijian; JAWAHAR, C. V. ICDAR2019 Competition on Scanned Receipt OCR and Information Extraction. In: 2019 International Conference on Document Analysis and Recognition (ICDAR) [online]. 2019, pp. 1516-1520 [visited on 2021-05-11]. ISBN 978-1-7281-3014-9. Available from DOI: 10.1109/ICDAR.2019.00244. 48. FREE Receipt Images - OCR / Machine Learning Dataset [online]. Walnut, California, USA: ExpressExpense, 2019 [visited on 2021-05-06]. Available from: https : / / express expense . com / b l o g / free - receipt - images - ocr - machine - learning- dataset/. 73