Real-time and Mobile Imaging Map Image Storage System| Research Real-time and Mobile Imaging Map Image Storage System |
Search |
The real-time imaging development has been started yet in the latest eighties – earlier nineties. At about this time, the world overloaded by the waste of paper documents decides to go digital, and convert documents that existed mostly in the paper form into a digital form – images.
To understand how the compression is important for storing image data, we draw the following example. A typical topographic image representing a single map‑sheet will have dimensions of ~ 5000x5000 pixels. The following diagrams show the sizes of the image file in the raw and compressed form for the black-n-white and color representations. The JBIG2 and MISS columns on the picture correspond to the latest state-of-the-art techniques (JBIG2 and MISS). The results are quoted from [12].
A major drawback of existing compression techniques (including JBIG), is that entire image (at least prior to the point of interest) must be decompressed in the memory (means also entirely transmitted to the client location) before it can be presented to the user. Using supposition that client device may not have sufficient resources to hold entirely decoded image, and high-sped channel (and fast processor) is not available to transmit (decode) the entire image is real-time, the operations with remotely located images would not be possible.
The user needs made us to develop the requirements for the Real-time Imaging Storage System [13]:
High compression rates – improves transmission and saves on storage (already possible with JBIG and JBIG2).
Fast decoding – real-time operations.
Instant preview property – quickly extract the thumbnail image.
Spatial access – be able to operate directly on the compressed stream, decode on the fly!
As we have noted, typical viewing devices have smaller size and resolution than the original raster image and thus, only a small fragment of the entire image may be viewed at a time. If spatial access is supported, an image may be interactively browsed on the viewing device. When the image is scrolled, a new part of data is retrieved and decompressed on the fly. In this way, spatial access eliminates time delays caused by image decompression and transfer. The thumbnail image may serve as a map to locate the desired part of the image at a higher scale.
The EDM (Engineering Document Management) storage system satisfying the above requirements has been proposed in [13]. Applying the technology to the map image content, this system has been extended into MISS (Map Image Storage System) [12].
The MISS system supports the following properties:
Compact storage size (state of the art);
Multi-scale representation (zooming);
Fast scrolling (panning) ability, via the spatial access feature.
The original MISS images are stored in the server-side database. Spatial views are generated for the client-side application using compressed raster image format organized so that it supports the zooming and panning requirements. In this way, raster format is suitable in applications, where the maps are needed for viewing purposes only.
Furthermore, the system does not depend on any database or vector format as digitized raster maps can be easily generated are reproduced from any source format, including paper maps. Another advantage of the system is that it requires only a modest memory and computing resources in order to be operational in real-time environment.
The general idea of the MISS is (1) in the separation of the image into the multiple scales, semantic layers, and block tiles, and (2) in the use of the special encoding schemes satisfying with the above sub-division and system requirements.
The following picture shows how the map image is operated in the client device. The map blocks along the client’s route (providing that the client’s location is dynamically determined used either of positioning services) are dynamically decoded (or retrieved and decoded) and used to create a picture shown on the device display.
A following picture illustrated these operations in more details. First, the file possessing map image of the desired spatial location and scale is accessed and its header part is retrieved and parsed in the memory. From the headers, the image type and structure are determined and block index table is built. The table indicates the size and locations in the file of the compressed image blocks. All supplementary data required for image decoding (such as initial model, etc) is also retrieved and kept in memory until this map image is no longer used.
Next, depending on the requested location, the system calculates the map image fragment, which needs to be displayed. The blocks covering this fragment are retrieved and decoded. If the map image is accessed remotely, the retrieved blocks are also stored (in the compressed form) in a local storage space for further use. When the position of the object changes, the view is updated by decoding new image blocks in the direction of movement.
Bringing all the features together, there are four possible scenarios for the use of map image content in the mobile environment:
Bringing all the features together, there are four possible scenarios for the use of map image content in the mobile environment:
1. Client-side approach
2. Server-side approach
Dynamic map loading scenarios:
3. Client-server approach, shift on the server:
Client, capable for image decoding and HTTP communications (advanced phone, eg. Nokia Communicator): if the compressed map file existing on the device (either preloaded or saved from previous trip) does not cover the requested fragment, the client will request the data from the server. Server extracts the data for the requested fragment and serves it back in the original (compressed) form. Client adds this data to the existing compressed file, and proceeds as if the data is locally present.
4. Client-server approach, shift on the client:
Geomessaging and Mobile Map Imaging in Personal Navigation (article in PDF)
Other articles on the topic can be found in Publications section.
| Updated: 2008 | © Eugene Ageenko |
