The following diagram combines many aspects of the architecture, giving insight into the modules, deployment, and runtime plans for the architecture.
It can be accessed with proper permissions here: https://drive.google.com/a/g.rit.edu/file/d/0B8ALJia9jVzAOGVka2RaQjhtQmM/view?usp=sharing
This diagram shows a high-level overview of many aspects of the system.
The RocReadaR App is the mobile application developed by the RocReadaR team to scan publication pages (of things like magazines) and display media. Users can use the application to "scan" a physically printed piece of media. When the printed media is recognized, media is shown. For example, a printed piece of media may have an article on a presentation that happened at RIT. When scanned using the RocReadaR App, a video of the presentation is shown. Many types of media can be shown.
Image Recognition Servers
Due to scaling issues, image recognition cannot be done on the RocReadaR App itself. Users phones would not be able to download all possible pages that could be recognized. Therefore, recognition needs to occur on our own servers. These are the Image Recognition Servers.
The Publisher Portal provides the functionality for the different manager users of the system to create, edit, and otherwise manage how image recognition occurs and what media is presented after image recognition occurs. Users (Publishers, Advertisers, etc. - NOT RocReadaR users) can log in and provide images to be recognized. They can then provide and edit the media that is shown upon image recognition.
Different roles are defined for the publisher portal. The roles are:
- Technical users who manage the system (like developers)
- Users who manage the whole system (the owners/sponsors)
- Users who create and manage publication media
- Users who are granted permission to create and manage publication media for a limited set of pages.
When image recognition files have been uploaded, they need to be processed into ".wtc" files. these files should be organized in a way that makes image recognition optimal. Therefore, after uploading images, the system should save the file, then wait 1 hour, then run the optimization process.
All data, including recognition and media files, should be stored and read from the database. Images or other media can be located on a separate server, and recognition can send simply a URL (this is just a different type of media).
Tracker File Optimization
In the middle of the overview, there is a segment of a schema diagram. Page media is linked to a page. Tracker files may contain many images, therefore there is a table of tracker files, and a table linking tracker files to the pages they recognize (TrackerFilePage). This way, a tracker file can be linked to any number of pages.
Tracker File Organization is documented here: WTC File Processing Optimization
A Tracker File Searching Algorithm is documented here: V2 Endpoint Search Ordering