HiRISE Operations Center

Department of Planetary Sciences
University of Arizona
Tucson, Arizona

HiView User's Guide
Addendum

Further
Information

The HiView FAQ provides answers to frequently asked questions not covered in this Guide. Users are encouraged to contribute advice that helps clarify the use of HiView or reveals a nuance or gotcha that other users might benefit from knowing.

Please send bug reports to the HiView@pirl.lpl.arizona.edu email address (this contact address can also be found on the About HiView dialog). Include the version of HiView in use (this can be found on the top line of the About HiView dialog, or by running the "HiView -version" command) and sufficient information so the problem condition can be reproduced, if possible. If HiView crashes on a Mac system a crash report will be generated by the system which needs to be included in the report sent to the HiView contact.

HiView continues to be developed with new features and performance improvements. Requests for HiView enhancements are welcomed and will be considered for inclusion in new development work.

Technical
Details

There are various implementation technologies that HiView employs to provide an effective application experience. Understanding some of these might help users accommodate the resource constraints of their host system. For those seriously interested in learning more about these technologies by participating in the development of HiView, please send an email to the HiView contact indicating how you might contribute to the project.

The HiView frontend is built on the Qt framework. Like all of the HiView software, this is a C++ code base (Qt provides a source code distribution) that is used to build native libraries. The HiView C++ classes are written to employ Qt capabilities that abstract the services of the underlying operating system. This enables a single HiView code base to be built on all platforms supported by the Qt libraries. This is particularly important when implementing a GUI application. It is also important when taking advantage of low level system services such as threading.

The Display Viewport of the HiView Main Window is managed by a Tiled_Image_Display class. The tiled image display technique introduces another level of complexity over managing a single display image - keeping track of the location of each tile in the display relative to the source image that is used to render the display image data, as well maintaining display pixel continuity between tiles, as the source image is scrolled and scaled can be challenging - while offering the possibility of a more responsive user experience. There are the obvious benefits - limiting the remote data transmit delay, memory space, and image rendering time - of only rendering those tiles that the application determines are needed. There are also benefits that can be realized by doing look-ahead rendering of display tile images for a margin around the Display Viewport in a background thread while the user is viewing the current image display. When the anticipated scrolling of the image in the Display Viewport to adjoining image areas occurs the required display tile images will already be ready in memory for immediate painting. As part of the look-ahead strategy, HiView also renders the entire source image at a scale selected to limit the amount of resources required into a background image. Whenever an area of the Display Viewport is to be painted but the tile image for the area has not yet completed rendering the corresponding area of the background image is used at the appropriate scaling factor to fill in for the tile image; when the tile image has completed rendering it is used to paint over the temporarily filled area of the display.

If the entire source image pixel data set could be held in memory the single display image solution would almost always be more effective than tiling. Most image viewing software assumes that all source image pixel data will be directly accessible in memory (this includes memory mapped storage). For the very large JP2 images that HiView is designed to manage this may not be possible on the user's host system: When the size of a source image pixel data set exceeds 2 GB a 32-bit architecture will not be able to encompass the entire memory space required by a very large image. Even for 64-bit systems which could hold an entire very large image in memory, the transmit time to bring all the image data across the network from a remote location, even when the data is compressed, is intolerable for an interactive application. Image tiling has long been used as a solution to this kind of problem by enabling the application to access the source image data in tile-sized chunks. This solution tiles the source image; HiView tiles the display image.

HiView renders its image displays using an Image_Renderer class. Because the software design goal was to manage very large images while maintaining a responsive user interface, the Image_Renderer operates in a separate thread from the main application GUI event loop thread. User actions cause image tiles to be queued for rendering without blocking the responsiveness of the GUI event loop. The Image_Renderer sends rendering status events to the main loop which may result in various GUI update operations, including image display repainting, image region statistics recalculation, and tool updates. User actions may preempt rendering operations. For example, while scaling an image display using a slider each minute change of the scaling factor causes the last set of image display tiles being rendered to be canceled and a new set queued for rendering at the changed scale factor.

The Qt framework provides the ability to read and write image data stored in numerous types of file formats. For some image file formats access capabilities are built into the core Qt library. For accessing additional image formats Qt finds and links to image format plug-in libraries at runtime. Several such plug-in libraries are included with the Qt distribution. Additional plug-in libraries may also be provided. For example, the KDE desktop environment, which is itself based on Qt, offers several additional image format plug-ins. HiView may discover such additional image file format support through the Qt framework.

The HiView Open and Save Image dialogs each have a "File of type" pop-down list that identifies all of the image file formats that are supported for image reading and writing, respectively. The JP2 file format is a special case: Some systems may have a plugin to write JP2 files; for reading JP2 files HiView provides a special set of backend libraries.

The JP2 image files are managed differently than conventional image files. Rather than reading all of the image data into memory for processing and display, the JPEG2000 codestreams are rendered selectively into memory on demand based on the area of the source image requested and the scale factor to be used.

HiView encapsulates every display image inside a Fungible_Image class that abstracts access to its source image data. The display image data of a Fungible_Image can be replaced on demand with pixel values from different regions of the source image rendered at different scaling factors. In addition, more than one Fungible_Image may share a single instance of the provider source image data class. How the Fungible_Image does this is determined by the particular subclass implementation that is used, which will depend on the image format of the source file. For conventional image file formats a simple in-memory source image pixel data set provider is used; though more sophisticated implementations could be implemented as appropriate. For JP2 files the Fungible_Image is implemented by a specialized JP2_Image class that dynamically employs the services of the HiView sibling JP2 libraries which provide an abstract interface to the source data. The interface includes asynchronous signaling of source data rendering progress to the application which the application may cancel. The JP2 libraries employ a replaceable JPEG2000 engine module that does the heavy lifting.

Behind the HiView JP2 libraries the Kakadu Software JPEG2000 libraries provide a high performance engine. In particular, the codestream rendering is multi-threaded: all available CPU processing lines are detected and utilized for the compute intensive rendering operations. For example, on a system with four hyper-threaded CPUs eight processing threads will be simultaneously run to complete the rendering of the source image data from the codestream segments fetched from the JP2 file, which can significantly increase the responsiveness of HiView compared to a single CPU system. The JP2 libraries also encapsulate a JPIP client implemented by the JPEG2000 engine module. The client manages asynchronous server connections and codestream data requests and delivery to the rendering machinery.