Patent Publication Number: US-2015074181-A1

Title: Architecture for distributed server-side and client-side image data rendering

Description:
CROSS-REFERENCE TO RELATED APPLICATION 
     This application claims priority to U.S. Provisional Patent Application No. 61/875,749, filed Sep. 10, 2013, entitled “IMAGE VIEWING ARCHITECTURE INCLUDING SERVER-SIDE AND CLIENT-SIDE IMAGE DATA RENDERING,” the disclosure of which is incorporated herein by reference in its entirety. 
    
    
     BACKGROUND 
     In systems that provide ubiquitous remote access to graphical image data in a resource sharing network, adequate performance and scalability becomes a challenge. For example, for operations that are performed at a central server, scalability may not be optimized. For operations that are performed at a client, large datasets may take an unacceptable amount of time to transfer across the network. In addition, some client devices, such as hand-held devices, may not have sufficient computing power to effectively manage heavy processing operations. For example, in healthcare it may be desirable to access to patient studies that are housed within a clinic or hospital. In particular, Picture Archiving and Communication Systems (PACS) may not provide ubiquitous remote access to the patient studies; rather, may be limited to a local area network (LANS) that connects the PACS server to dedicated medical imaging workstations. Other applications, such as CAD design and seismic analysis may have similar challenges, as such applications may be used to produce complex images. 
     SUMMARY 
     Disclosed herein are systems and methods for distributed rendering of 2D and 3D image data in a remote access environment where 2D image data is streamed to a client computing device and 2D images are rendered on the client computing device for display, and 3D image data is rendered on a server computing device and the rendered 3D images are communicated to the client computing device for display. In accordance with an aspect of the present disclosure, there is provided a method of distributed rendering of image data in a remote access environment connecting a client computing devices to a service. The method may include storing 2D image data in a database associated with the service; receiving a request at the service from the client computing device; and determining if the request is for the 2D image data or 3D images. If the request is for the 2D image data, then the 2D image data is streamed to the client computing device for rendering of 2D images for display. If the request is for 3D images, then a server computing device associated with the service renders the 3D images from the 2D image data and communicates the 3D images to the client computing device for display. 
     In accordance with aspects of the disclosure, there is provided a method for distributed rendering of image data in a remote access environment connecting a client computing devices to a service. The method may include storing 2D image data in a database associated with the service; receiving a request at the service from the client computing device; and determining if the request is for the 2D image data or 3D images. If the request is for the 2D image data, then the method may include streaming the 2D image data to the client computing device for rendering of 2D images at the client computing device for display. However, if the request is for 3D images, then the method may include rendering, at a server computing device associated with the service, the 3D images from the 2D image data and communicating the rendered 3D images to the client computing device for display. 
     In accordance with other aspects of the disclosure, there is provided a method for providing a service for distributed rendering of image data between the service and a remotely connected client computing device. The method may include receiving a connection request from the client computing device; authenticating a user associated with the client computing device to present a user interface showing images available for viewing by the user; and receiving a request for images, and if the request of images is for 2D image data, then streaming the 2D image data from the service to the client computing device, or if the request is for 3D images, then rendering the 3D images at the service and communicating the rendered 3D images to the client computing device. 
     In accordance with other aspects of the disclosure, a tangible computer-readable storage medium storing a computer program having instructions for distributed rendering of image data in a remote access environment is disclosed. The instructions may execute a method comprising the steps of storing 2D image data in a database associated with the service; receiving a request at the service from the client computing device; determining if the request is for the 2D image data or 3D images; and if the request is for the 2D image data, then streaming the 2D image data to the client computing device for rendering of 2D images at the client computing device for display; or if the request is for 3D images, then rendering, at a server computing device associated with the service, the 3D images from the 2D image data and communicating the rendered 3D images to the client computing device for display. 
     Other systems, methods, features and/or advantages will be or may become apparent to one with skill in the art upon examination of the following drawings and detailed description. It is intended that all such additional systems, methods, features and/or advantages be included within this description and be protected by the accompanying claims. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The components in the drawings are not necessarily to scale relative to each other. Like reference numerals designate corresponding parts throughout the several views. 
         FIG. 1  is a simplified block diagrams illustrating a system for providing remote access to image data and other data at a remote device via a computer network; 
         FIG. 2A  illustrates aspects of preprocessing of image data and metadata in the environment of  FIG. 1 ; 
         FIG. 2B  illustrates data flow of 2D image data and metadata with regard to preprocessing of 2D image data and server-side rendering of 3D and/or MIP/MPR data and client-side rendering of 2D data in the environment of  FIG. 1 ; 
         FIG. 3  illustrates a flow diagram of example operations performed within the environment of  FIGS. 1 and 2  to service requests from client computing devices; 
         FIG. 4  illustrates a flow diagram of example client-side image data rendering operations; 
         FIG. 5  illustrates a flow diagram of example operations performed as part of a server-side rendering of the image data; 
         FIG. 6  illustrates a flow diagram of example operations performed within the environment of  FIG. 1  to provide for collaboration; and 
         FIG. 7  illustrates an exemplary computing device. 
     
    
    
     DETAILED DESCRIPTION 
     Unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art. Methods and materials similar or equivalent to those described herein can be used in the practice or testing of the present disclosure. While implementations will be described for remotely accessing applications, it will become evident to those skilled in the art that the implementations are not limited thereto, but are applicable for remotely accessing any type of data or service via a remote device. 
     Overview 
     In accordance with aspects of the present disclosure, remote users may access images using, e.g., a remote service, such as a cloud-based service. In accordance with a type of images being requested, certain types may be rendered by the remote service, whereas other types may be rendered locally on a client computing device. 
     For example, in the context of high resolution medical images, a hosting facility, such as a hospital, may push patient image data to the remote service, where it is pre-processed and made available to remote users. The patient image data (source data) is typically a series of DICOM files that each contain one or more images and metadata. The remote service coverts the source data into a sequence of 2D images having a common format which are communicated to a client computing device in a separately from the metadata. The client computing device renders the sequence of 2D images for display. In another aspect, the sequence of 2D images may be further processed into a representation suitable for 3D or Maximum Intensity Projection (MIP)/Multi-Planar Reconstruction (MPR) rendering by an imaging server at the remote service. The 3D or MIP/MPR rendered image is communicated to the client computing device. The 3D image data may be visually presented to a user as a 2D projection of the 3D image data. 
     While the above example describes aspects of the present disclosure with respect to medical images, the concepts described herein may be applied to any images that are transferred from a remote source to a client computing device. For example, in the context of other imagery, such as computer-aided design (CAD) engineering design, seismic imagery, etc. aspects of the present disclosure may be utilized to render a 2D schematic of a design on a client device, where 3D model of the design may be rendered on the imaging server of the remote service to take advantage of the a faster, more powerful graphics processing unit (GPU) array at the remote service. The rendered 3D model would be communicated to the client computing device for viewing. Such an implementation may be used, for example, to view a 2D schematic of a building on-site, whereas a 3D model of the same building may be rendered on a GPU array of the remote service. Similarly, such an implementation may be used, for example to render 2D images at the client computing device from 2D reflection seismic data or to render 3D images at the remote service from either raw 3D reflection seismic data or by interpolating 2D reflection seismic data that are communicated to the client computing device for viewing. For example, 2D seismic data may be used for well monitoring and other data sets, whereas 3D seismic data would be use for a reservoir analysis. 
     Thus, present disclosure provides for distributed image processing whereby less complex image data (e.g., 2D image data) may be processed by the client computing device and more complex image data (e.g., 3D image data) may be processed remotely and then communicated to the client computing device. In addition, the remote service may preprocess any other data associated with image data in order to optimize such data for search and retrieval in a distributed database arrangement. As such, the present disclosure provides a system and method for transmitting data efficiently over a network, thus conserving bandwidth while providing a responsive user experience. 
     Example Environment 
     With the above overview as an introduction, reference is now made to  FIGS. 1-2  where there is illustrated an environment  100  for image data viewing, collaboration and transfer via a computer network. In this example, and with reference to a medical imaging application for viewing patient data for the purpose of illustration, a server computer  109  may be provided at a facility  101 A (e.g., a hospital or other care facility) within an existing network as part of a medical imaging application to provide a mechanism to access data files, such as patient image files (studies) resident within, e.g., a Picture Archiving and Communication Systems (PACS) database  102 . Using PACS technology, a data file stored in the PACS database  102  may be retrieved and transferred to, for example, a diagnostic workstation  110 A using a Digital Imaging and Communications in Medicine (DICOM) communications protocol where it is processed for viewing by a medical practitioner. The diagnostic workstation  110 A may be connected to the PACS database  102 , for example, via a Local Area Network (LAN)  108  such as an internal hospital network or remotely via, for example, a Wide Area Network (WAN)  114  or the Internet. Metadata and image data may be accessed from the PACS database  102  using a DICOM query protocol, and using a DICOM communications protocol on the LAN  108 , information may be shared. 
     The server computer  109  may comprise a RESOLUTION MD server available from Calgary Scientific, Inc., of Calgary, Alberta, Canada. The server computer  109  may be one or more servers that provide other functionalities, such as remote access to patient data files within the PACS database  102 , and a HyperText Transfer Protocol (HTTP)-to-DICOM translation service to enable remote clients to make requests for data in the PACS database  102  using HTTP. 
     A pusher application  107  communicates patient image data from the facility  101 A (e.g., the PACS database  102 ) to a cloud service  120 . The pusher application  107  may make HTTP requests to the server computer  109  for patient image data, which may be retrieved from by the PACS database  102  by the server computer  109  and returned to the pusher application  107 . The pusher application  107  may retrieve patient image data on a schedule or as it becomes available in the PACS database  102  and provide it to the cloud service  120 . 
     Client computing devices  112 A or  112 B may be wireless handheld devices such as, for example, an IPHONE or an ANDRIOD that communicate via a computer network  114  such as, for example, the Internet, to the cloud service  120 . The communication may be HyperText Transport Protocol (HTTP) communication with the cloud service  120 . For example, a web client (e.g., a browser) or native client may be used to communicate with the cloud service  120 . The web client may be HTML5 compatible. Similarly, the client computing devices  112 A or  112 B may also include a desktop/notebook personal computer or a tablet device. It is noted that the connections to the communication network  114  may be any type of connection, for example, Wi-Fi (IEEE 802.11x), WiMax (IEEE 802.16), Ethernet, 3G, 4G, LTE, etc. 
     The cloud service  120  may host the patient image data, process patient image data and provide patient image data to, e.g., one or more of client computing devices  112 A or  112 B. An application server  122  may provide for functions such as authentication and authorization, patient image data access, searching of metadata, and application state dissemination. The application server  122  may receive raw image data from the pusher application  107  and place the raw image data into a binary large object (blob) store  126 . Other patient-related data (i.e., metadata) is placed by the application server  122  into a data store  128 . 
     The application server  122  may be virtualized, that is, created and destroyed based on, e.g., load or other requirements to perform the tasks associated therewith. In some implementations, the application server  122  may be, for example, a node.js web server or a java application server that services requests made by the client computing devices  112 A or  112 B. The application server  122  may also expose APIs to enable clients to access and manipulate data stored by the cloud service  120 . For example, the APIs may provide for search and retrieval of image data. In accordance with some implementations, the application server  122  may operate as a manager or gateway, whereby data, client requests and responses all pass through the application server  122 . Thus, the application server  122  may manage resources within the environment hosted by the cloud service  120 . 
     The application server  122  may also maintain application state information associated with each client computing device  112 A or  112 B. The application state may include, such as, but not limited to, a slice number of the patient image data that was last viewed at the client computing device  112 A or  112 B for viewing, etc. The application state may be represented by, e.g., an Extensible Markup Language (XML) document. Other representations of the application state may be used. The application state associated with one client computing device (e.g.,  112 A) may be accessed by another client computing device (e.g.,  112 B) such that both client computing devices may collaboratively interact with the patient image data. In other words, both client computing devices may view the patient image data such that changes in the display are synchronized to both client computing devices in the collaborative session. Although only two client computing devices are shown, any number of client computing devices may participate in a collaborative session. 
     In accordance with some implementations, the blob store  126  may be optimized for storage of image data, whereas the data store  128  may be optimized for search and rapid retrieval of other types of information, such as, but is not limited to a patient name, a patient birth date, a name of a doctor who ordered a study, facility information, or any other information that may be associated with the raw image data. The blob store  126  and data store  128  may hosted on, e.g., Amazon S3 or other service which provides for redundancy, integrity, versioning, and/or encryption. In addition, the blob store  126  and data store  128  may be HIPPA compliant. In accordance with some implementations, the blob store  126  and data store  128  may be implemented as a distributed database whereby application-dependent consistency criteria are achieved across all sites hosting the data. Updates to the blob store  126  and the data store  128  may be event driven, where the application server  122  acts as a master. 
     Message buses  123   a - 123   b  may be provided to decouple the various components with the cloud service  120 , and to provide for messaging between the components, such as pre-processors  124   a - 124   n  and imaging servers  130   a - 130   n . Messages may be communicated on the message buses  123   a - 123   b  using a request/reply or publish/subscribe paradigm. The message buses  123   a - 123   b  may be, e.g., ZeroMQ, RabbitMQ (or other AMQP implementation) or Amazon SQS. 
     With reference to  FIGS. 1 ,  2 A and  2 B, the pre-processors  124   a - 124   n  respond to messages on the message buses  123   a . For example, when raw image data is received by the application server  122  and is need of pre-processing, a message may be communicated by the application server  122  to the pre-processors  124   a - 124   n . As shown in  FIG. 2B , source data  150  (raw patient image data) may be stored in the PACS database  102  as a series of DICOM files that each contain one or more images and metadata. The pre-processing performed by the pre-processors  124   a - 124   n  may include, e.g., separation and storage of metadata, pixel data conversion and compression, and 3D down-sampling. As such, the source data may be converted into a sequence of 2D images having a common format that are stored in the blob store  126 , whereas the metadata is stored in the data store  128 . For example, as shown in  FIG. 2A , the processes may operate in it a push-pull arrangement such that when the application server  122  pushes data in a message, any available pre-processor may pull the data, perform a task on the data, and push the processed data back to the application server  122  for storage in the blob store  126  or the data store  128 . 
     The pre-processors  124   a - 124   n  may perform optimizations on the data such that the data is formatted for ingestion by the client computing devices  112 A or  112 B. The pre-processors  124   a - 124   n  may process the raw image data and store the processed image data in the blob store  126  until requested by the client computing devices  112 A or  112 B. For example, 2D patient image data may be formatted as Haar Wavelets. Other, non-image patient data (metadata) may be processed by the pre-processors  124   a - 124   n  and stored in the data store  128 . Any number of pre-processors  124   a - 124   n  may be created and/or destroyed in accordance, e.g., processing load requirements to perform any task to make the patient image data more usable or accessible to the client computing devices  112 A and  112 B. 
     The imaging servers  130   a - 130   n  provide for distributed rendering of image data. Each imaging server  130   a - 130   n  may serve multiple users. For example, as shown in  FIG. 2B , the imaging servers  130   a - 130   n  may process the patient image data stored as the sequence of 2D image in the blob store  126  to provide rendered 3D imagery and/or Maximum Intensity Projection (MIP)/Multi-Planar Reconstruction (MPR) image data, to the client computing devices  112 A and  112 B. For example, a user at one of the computing devices  112 A or  112 B may make a request to view a 3D representation of a volume with 3D orthogonal MPR slices. Accordingly, an imaging server  130  may render the 3D orthogonal MPR slices, which are communicated to the requesting client computing device via the application server  122 . 
     In accordance with some implementations, a 3D volume is computed from a set of N, X by Y images. This forms a 3D volume with a size of X×Y×N voxels. This 3D volume may then be decimated to reduce the amount of data that must be processed by the imaging servers  130   a - 130   n  to generate an image. For example, a reduction of 75% may be provided along each axis, which produces the sufficient results without a significant loss of fidelity in the resulting rendered imagery. A longest distance between any two corners of the decimated 3D volume can be used to determine the size of the rendered image. For example, a set of 1000 512×512 CT slices may be used to produce a 3D volume. This volume may be decimated to a size of 384×384×750, so the largest distance between any two corners is √{square root over (384 2 +384 2 +750 2 )} voxels, or approximately 926. The rendered image is, therefore, 926×926 pixels in order to capture information at a 1:1 relationship between voxels and pixels. In the event that the client&#39;s viewport (display) is smaller than 926×926, the client&#39;s viewport size is used, rather than the image size in order to determine the size of the rendered image. The rendered images may be scaled-up by a client computing device when displayed to a user if the viewport is larger than 926×926. As such, a greater number of images may be rendered at the imaging servers  130   a - 130   n  and the image rendering time is reduced. 
     Thus, when the image servers  130   a - 130   n  are requested to render 3D volumetric views, a set of 2D images may be decimated from 512×512×N pixels to 384×384×N pixels before processing, as noted above. However, for MIP/MPR images, the 2D image data may be used in its original size. 
     A process monitor  132  is provided to insure that the imaging servers  130   a - 130   n  are alive and running. Should the process monitor  132  find that a particular imaging server is unexpectedly stopped; the process monitor  132  may restart the imaging server such that it may service requests. 
     Thus, the environment  100  enables cloud-based distributed rendering of patient imaging data associated with a medical imaging application or other types of image data and their respective viewing/editing applications. Further, client computing devices  112 A or  112 B may participate in a collaborative session and each present a synchronized view of the display of the patient image data. 
       FIG. 3  illustrates a flow diagram  300  of example operations performed within the environment of  FIGS. 1 and 2  to service requests from client computing devices  112  A and  112  B. As noted above, the application server  122  receives patient image data from the pusher application  107  on a periodic basis or as patient data becomes available. The operational flow of  FIG. 3  begins at  302  where a client computing device connects to the application server in a session. For example, the client computing device  112 A may connect to the application server  122  at a predetermined uniform resource locator (URL). The user of the client computing device  112 A may use, e.g., a web browser or a native application to make the connection to the application server  122 . 
     At  304 , the user authenticates with the cloud service  120 . For example, due to the sensitive nature of patient image data, certain access controls may be put in place such that only authorized users are able to view patient image data. At  306 , the application server sends a user interface client to the client computing device. A user interface client may be downloaded to the client computing device  112 A to enable a user to select a patient study or to search and retrieve other information from the blob store  126  or the data store  128 . For example, an HTML5 study browser client may be downloaded to the client computing device  112 A that provides a dashboard whereby a user may view a thumbnail of a patient study, a description, a patient name, a referring doctor, an accession number, or other reports associated with the patient image data stored at the cloud service  120 . Different version of the user interface client may be designed for, e.g., mobile and desktop applications. In some implementations, the user interface client may be a hybrid application for mobile client computing devices where it may be installed having both native and HTML5 components. 
     The 308, user selects a study. For example, using the study browser, the user of the client computing device  112 A may select a study for viewing at the client computing device  112 A. At  310 , patent image data associated with the selected study is streamed to the client computing device  112 A from the application server  122 . The patient image data may be communicated using an XMLHttpRequest (XHR) mechanism. The patient image data may be provided as complete images or provided progressively. Concurrently, an application state associated with the client computing device  112 A is updated at the application server  122  in accordance with events at the client computing device  112 A. The application state is continuously updated at the application server  122  to reflect events at the client computing device  112 A, such as the user scrolling through the slices. The user may scroll slices or perform other actions that change application state while the image data is being sent to the client. As will be described later with reference to  FIG. 6 , the application state may provided to more than one client computing device connected to a collaboration session in order to provide synchronize views and enable collaboration among the multiple client computing devices that are simultaneously viewing imagery associated with a particular patient. 
     Thus, in accordance with the above, the patient image data maintained at the cloud service  120  is made available through the interaction of one or more the client computing device  112 A with the application server  122 . 
       FIG. 4  illustrates a flow diagram  400  of example client-side image rendering operations performed at the client computing device. At  402 , the 2D image data is received at the client computing device as streaming data, as described at  310  in accordance with the operational flow  300 . At  404 , the 2D image data is manipulated. The image data may be manipulated as an ArrayBuffer a data type or other JavaScript typed arrays. 
     At  406 , a display image is rendered at the client computing device from the 2D image data. For example, the display image may be rendered using WebGL, which provides for rendering graphics within a web browser. In some implementations, Canvas may also be used for client-side image rendering. Metadata associated with the image data may be utilized by the client computing device to aid the performance of the rendering. 
     Thus, in accordance with the flow diagram  400 , client-side rendering of the image data provides for high-performance presentation of images as the data need only be communicated to the client computing device for display, eliminating any need for round-trip communication with the cloud service  120 . In addition, each client can render the image data in a manner particular to the client. 
       FIG. 5  illustrates a flow diagram  500  of example operations performed as part of a server-side rendering of the image data. As described above in  FIG. 4 , 2D rendering of images is on the client computing device. The operational flow  500  may be used to provide 3D images and/or MIP/MPR images to the client computing device, where the 3D images and/or MIP/MPR images are rendered by, e.g., one of the imaging servers  130   a - 103   n , and communicated to the client computing device for display. Thus, the present disclosure provides a distributed image rendering model where 2D images are rendered on the client and 3D and/or MIP/MPR images are rendered on the server. 
     At  502 , the server-side rendering begins in accordance with, e.g., a request made by the user of the client computing device  112 A that is received by the application server  122 . For example, the user may wish to view the image data in 3D to perform operations such as, but not limited to, a zoom, pan or a rotate of the image associated with, e.g., a patient. The process monitor  132  may respond to insure that an imaging server  130  is available to service the user request. As noted above, each imaging server can service multiple users. 
     Optionally, at  504 , the image size is determined from the source image data. As noted above, the data size may be reduced for 3D volumetric rendering, whereas the original size is used for MIP/MPR images. At  506 , the image is rendered. For example, the imaging servers  130   a - 130   n  may render imagery in OpenGL. 
     At  508 , rendered image is communicated to the client computing device. For example, the entire image may be communicated to the client computing device, which is then displayed on the client computing device  510 . In accordance with the present disclosure, the client computing device may scale the image to fit within the particular display associated with the client computing device. 
     Thus, the image servers may provide the same-sized images to each client computing device that requests 3D image data, which reduces the size of images to be transmitted and conserves bandwidth. As such, scaling of the data is distributed across the client computing devices, rather than being performed by the imaging servers. 
       FIG. 6  illustrates a flow diagram  600  of example operations performed within the environment of  FIG. 1  to provide for collaboration. At  602 , a first client computing device (e.g.,  112 A) has established a session with the application server  122  and 2D image data is being streamed to the client computing device. As such, client-side rendering of the 2D image data and the application state updating has begun as described at  310 . At  604 , a second client computing device connects to the application server to join the session. For example, the client computing device  112 B may connect to the application server  122  at the same URL used by the first client computing device (e.g.,  112 A) to connect to the application server  112 . 
     At  606 , the second client computing device receives the application state associated with the first client computing device from the application server. Thus, a collaboration session between the client computing devices  112 A and  112 B may now be established. At  608 , image data associated with the first client computing device ( 112 A) is communicated to the second client computing device ( 112 B). After  608 , the second client computing device ( 112 B) will have knowledge of first computing device&#39;s application state and will be receiving image data. Next, at  610 , the image data and the application state are updated in accordance with events at both client computing devices  112 A and  112 B such that both of the client computing devices  112 A and  112 B will be displaying the same image data in a synchronized fashion. At  612 , the collaborators may view and interact with the image data to, e.g. discuss the patient&#39;s condition. Interacting with the image data may cause the image data and application state to be updated in a looping fashion at  610 - 612 . 
     Although the present disclosure has been described with reference to certain operational flows, other flows are possible. Also, while the present disclosure has been described with regard to patient image data, it is noted that any type of image data may be processed by the cloud service and/or (collaboratively) viewed by one or more client computing devices. 
     Numerous other general purpose or special purpose computing system environments or configurations may be used. Examples of well known computing systems, environments, and/or configurations that may be suitable for use include, but are not limited to, personal computers, server computers, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, network personal computers (PCs), minicomputers, mainframe computers, embedded systems, distributed computing environments that include any of the above systems or devices, and the like. 
     Computer-executable instructions, such as program modules, being executed by a computer may be used. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Distributed computing environments may be used where tasks are performed by remote processing devices that are linked through a communications network or other data transmission medium. In a distributed computing environment, program modules and other data may be located in both local and remote computer storage media including memory storage devices. 
       FIG. 7  shows an exemplary computing environment in which example embodiments and aspects may be implemented. The computing system environment is only one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality. 
     With reference to  FIG. 7 , an exemplary system for implementing aspects described herein includes a computing device, such as computing device  700 . In its most basic configuration, computing device  700  typically includes at least one processing unit  702  and memory  704 . Depending on the exact configuration and type of computing device, memory  704  may be volatile (such as random access memory (RAM)), non-volatile (such as read-only memory (ROM), flash memory, etc.), or some combination of the two. This most basic configuration is illustrated in  FIG. 7  by dashed line  706 . 
     Computing device  700  may have additional features/functionality. For example, computing device  700  may include additional storage (removable and/or non-removable) including, but not limited to, magnetic or optical disks or tape. Such additional storage is illustrated in  FIG. 7  by removable storage  708  and non-removable storage  710 . 
     Computing device  700  typically includes a variety of computer readable media. Computer readable media can be any available media that can be accessed by device  700  and includes both volatile and non-volatile media, removable and non-removable media. 
     Computer storage media include volatile and non-volatile, and removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Memory  704 , removable storage  708 , and non-removable storage  710  are all examples of computer storage media. Computer storage media include, but are not limited to, RAM, ROM, electrically erasable program read-only memory (EEPROM), flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by computing device  700 . Any such computer storage media may be part of computing device  700 . 
     Computing device  700  may contain communications connection(s)  712  that allow the device to communicate with other devices. Computing device  700  may also have input device(s)  714  such as a keyboard, mouse, pen, voice input device, touch input device, etc. Output device(s)  716  such as a display, speakers, printer, etc. may also be included. All these devices are well known in the art and need not be discussed at length here. 
     It should be understood that the various techniques described herein may be implemented in connection with hardware or software or, where appropriate, with a combination of both. Thus, the methods and apparatus of the presently disclosed subject matter, or certain aspects or portions thereof, may take the form of program code (i.e., instructions) embodied in tangible media, such as floppy diskettes, CD-ROMs, hard drives, or any other machine-readable storage medium wherein, when the program code is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the presently disclosed subject matter. In the case of program code execution on programmable computers, the computing device generally includes a processor, a storage medium readable by the processor (including volatile and non-volatile memory and/or storage elements), at least one input device, and at least one output device. One or more programs may implement or utilize the processes described in connection with the presently disclosed subject matter, e.g., through the use of an application programming interface (API), reusable controls, or the like. Such programs may be implemented in a high level procedural or object-oriented programming language to communicate with a computer system. However, the program(s) can be implemented in assembly or machine language, if desired. In any case, the language may be a compiled or interpreted language and it may be combined with hardware implementations. 
     Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.