Systems and methods for rendering images on a device

Abstract

1. A method for rendering images on a device, the method including: launching an image viewing application; downloading, in the image viewing application, a plurality of unrendered image files stored in a server memory; rendering, in the image viewing application, using one or more device processors, the plurality of unrendered image files to generate a plurality of rendered image files; displaying, in the image viewing application, the plurality of rendered image files in at least one image window; and rendering, in the image viewing application, at least one server application in at least one native window container, the at least one server application stored in the server memory and processed by one or more server processors.

Description

[Technical Field]

[0001] The disclosed subject matter relates to systems and methods for downloading and rendering images, such as medical images, and more specifically, DICOM (Digital Imaging and Communications in Medicine) objects, onto a device. The systems and methods described herein can utilize a combined server and device implementation to optimize performance in downloading and rendering images on the device. [Background technology]

[0002] In medical imaging, a PACS (Picture Archiving and Communication Systems) is a combination of computers and networks dedicated to storing, retrieving, presenting, and distributing images. Medical information can be stored in a variety of formats, but a common format for image storage is DICOM. DICOM is a standard that, among other things, allows medical images and associated metadata to be communicated from imaging modalities (e.g., X-ray (or its digital counterparts: computed radiography (CR) and digital radiography (DR)), computed tomography (CT), and magnetic resonance imaging (MRI) machines) to remote storage and / or client devices for viewing and / or other uses.

[0003] As an example, current image viewing applications may be built with server-side rendering technology. This client-server model includes a server capable of performing image rendering and a client application that runs in a web browser to display images to a workstation client. The client application implementation is web-based and hosted on the web browser. Implementing advanced features in web technology and hosting them in a web browser presents several challenges in providing the best experience for radiologists and cardiologists when reviewing exams.

[0004] Some challenges associated with this model include network latency, which impacts accurate, high-speed image visualization and navigation, and image rendering latency, which impacts accurate use of imaging tools. Additionally, browser-based web technologies impact the performance, smoothness, and predictability of interactive image navigation / scrolling, especially on high-resolution diagnostic monitors. Browser-based web technologies further impact fast and accurate playback of images on high-resolution diagnostic monitors, such as cine playback of DICOM images. These challenges may also reduce the ability to improve functionality, especially for more advanced features.

[0005] Therefore, there is a need for improved systems and methods for rendering images on a device. Summary of the Invention [Means for solving the problem]

[0006] The objects and advantages of the disclosed subject matter will be set forth in and apparent from the following description, as well as be learned by practice of the disclosed subject matter. Additional advantages of the disclosed subject matter will be realized and attained by the methods and systems particularly pointed out in the description and claims hereof, as well as the appended drawings.

[0007] To achieve these and other advantages, and in accordance with the objectives of the disclosed subject matter, as embodied and broadly described, the disclosed subject matter relates to a system and method for rendering an image on a device, for example, a method for rendering an image on a device, the method including: launching an image viewing application; downloading, in the image viewing application, a plurality of unrendered image files stored in a server memory; rendering, in the image viewing application, using one or more device processors, the plurality of unrendered image files to generate a plurality of rendered image files; displaying, in the image viewing application, the plurality of rendered image files in at least one image window; and rendering, in the image viewing application, at least one server application in at least one native window container, the at least one server application stored in the server memory and processed by one or more server processors.

[0008] The method may further include storing the plurality of unrendered image files in a device memory. The device memory may be at least one of an in-memory cache and a disk cache. The method may further include decompressing the plurality of unrendered image files before rendering. The method may further include rendering the plurality of unrendered image files using the server processor in the image viewing application until download of the plurality of unrendered image files is complete. During the step of launching the image viewing application, the at least one native window container may be initialized during application launch. After the native window is initialized, the at least one server application may be rendered in the at least one native window container upon login by the user. The method may further include rendering at least one second server application in a second native window container in the image viewing application, the at least one second server application may be stored in a second server memory and processed by one or more second server processors. The at least one server application may include a web page. The plurality of unrendered image files may include DICOM images. The plurality of rendered image files may include multi-frame images.

[0009] In accordance with the disclosed subject matter, a system for rendering images on a device is provided. The system may include a server having one or more server processors and a server memory coupled to the server processors, the server processors including instructions executable by the server processors; and a device having one or more device processors and a device memory coupled to the device processors, the device processor including instructions executable by the device processors. The device processor may be operable to execute instructions to launch an image viewing application, download, in the image viewing application, a plurality of unrendered image files stored in the server memory, render, in the image viewing application, using the device processor to generate a plurality of rendered image files, display, in the image viewing application, the plurality of rendered image files in at least one image window, and render, in the image viewing application, at least one server application in at least one native window container, wherein the at least one server application may be stored in the server memory and processed by the one or more server processors.

[0010] The device processor may also execute instructions to store the plurality of unrendered image files in the device memory. The device memory may be at least one of an in-memory cache and a disk cache. The device processor may also execute instructions to decompress the plurality of unrendered image files before rendering. The device processor may also execute instructions to render the plurality of unrendered image files using the server processor in the image viewing application until download of the plurality of unrendered image files is complete. During the instructions to launch the image viewing application, the at least one native window container may be initialized during application launch. After the native window is initialized, the at least one server application may be rendered in the at least one native window container upon login by the user. The device processor may also execute instructions to render at least one second server application in the second native window container in the image viewing application. The at least one second server application may be stored in a second server memory and processed by one or more second server processors.

[0011] In accordance with the disclosed subject matter, a method of rendering images on a device is provided, the method may include launching an image viewing application operating on the device, downloading, in the image viewing application, a plurality of unrendered image files, the plurality of unrendered image files being assigned priority values ​​based on when the plurality of image files are to be displayed, storing, in the image viewing application, the downloaded plurality of unrendered image files in at least one of a first device memory and a second device memory, the plurality of unrendered image files being stored in at least one of the first device memory and the second device memory according to the assigned priority values, rendering, in the image viewing application, the plurality of unrendered image files based on the assigned priority values ​​using at least one device processor, wherein if the plurality of unrendered image files having a predetermined priority value need to be displayed before downloading is complete, the rendering occurs in at least one processor of a server electrically coupled to the image viewing application, and displaying, in the image viewing application, the plurality of rendered image files based on the assigned priority values. The second device memory transfers at least one of the plurality of unrendered image files to the first device memory based on the assigned priority value and available storage space in the first device memory.

[0012] The assigned priority values ​​may be at least two priority values ​​assigned to the plurality of image files. The method may also further include, in the image viewing application, decompressing the plurality of unrendered image files according to the assigned priority values ​​and available storage space in at least one of the first device memory and the second device memory. The decompression of the plurality of unrendered image files may be performed in the at least one device processor based on processing availability of the at least one device processor. The plurality of unrendered images may be DICOM images. The plurality of unrendered image files may each include a plurality of frame images, each of the plurality of frame images having a plurality of frames, each of the plurality of frame images being divided into a plurality of single-frame files, and the plurality of single-frame files being stored in at least one of the first device memory and the second device memory. The plurality of frame images may be divided into the plurality of single-frame files by the at least one processor, the server. The plurality of unrendered image files may be DICOM images.

[0013] In accordance with the disclosed subject matter, there is provided a system for rendering an image on a device, which may include a server having one or more server processors and a server memory coupled to the server processors that includes instructions executable by the server processors, and a device having one or more device processors and a device memory coupled to the device processors that includes instructions executable by the device processors. The device processor may be operable to execute instructions to launch an image viewing application operating on the device, download a plurality of unrendered image files in the image viewing application, wherein the plurality of unrendered image files are assigned priority values ​​based on when the plurality of image files are to be displayed, store the downloaded plurality of unrendered image files in at least one of a first device memory and a second device memory, wherein the plurality of unrendered image files are stored in at least one of the first device memory and the second device memory according to the assigned priority values, render the plurality of unrendered image files in the image viewing application using at least one device processor based on the assigned priority values, wherein if the plurality of unrendered image files having a predetermined priority value need to be displayed before downloading is complete, the rendering occurs in at least one processor of a server electrically coupled to the image viewing application, and display the plurality of rendered image files in the image viewing application based on the assigned priority values. The second device memory transfers at least one of the plurality of unrendered image files to the first device memory based on the assigned priority value and available storage space in the first device memory.

[0014] In accordance with the disclosed subject matter, a method of rendering an image on a device is provided, the method may include launching an image viewing application operating on a device, downloading at least one first unrendered image file in the image viewing application, storing the downloaded at least one first unrendered image file in at least one of a first device memory and a second device memory in the image viewing application, rendering the at least one first unrendered image file into at least one first rendered image file using at least one device processor in the image viewing application, and displaying the at least one first rendered image file in the image viewing application, wherein the display of the at least one rendered image file is controlled by movement of a pointing device, and the image viewing application receives input data related to the movement of the pointing device from the pointing device.

[0015] The pointing device may be a mouse connected to the device. The movement of the pointing device may include at least one of relative and absolute movement of the pointing device. The plurality of unrendered image files may be assigned priority values ​​based on when the plurality of unrendered image files are displayed, the plurality of unrendered image files are stored in at least one of the first device memory and the second device memory according to the assigned priority values, and the plurality of unrendered image files are rendered based on the assigned priority values. The image viewing application may track the movement of the pointing device to predict at least one second unrendered image file to be displayed after the at least one first rendered image file. The method may include downloading the at least one second unrendered image file in the image viewing application; storing the downloaded at least one second unrendered image file in at least one of a first device memory and a second device memory in the image viewing application; rendering the at least one second unrendered image file into at least one second rendered image file using the at least one device processor in the image viewing application; and displaying the at least one second rendered image file in the image viewing application. The image viewing application may be configured to scroll between the at least one first rendered image file and the at least one second rendered image file. The movement of the pointing device may include scrolling a wheel. The image viewing application may be configured to transfer the at least one first unrendered image file from at least one of the first device memory and the second device memory.

[0016] In accordance with the disclosed subject matter, there is provided a system for rendering an image on a device, which may include a server having one or more server processors and a server memory coupled to the server processors that includes instructions executable by the server processors, and a device having one or more device processors and a device memory coupled to the device processors that includes instructions executable by the device processors. The device processor may be operable in executing instructions to launch an image viewing application operating on the device, download at least one first unrendered image file in the image viewing application, store the downloaded at least one first unrendered image file in at least one of a first device memory and a second device memory in the image viewing application, render the at least one first unrendered image file into at least one first rendered image file using the at least one device processor in the image viewing application, and display the at least one first rendered image file in the image viewing application, wherein the display of the at least one rendered image file is controlled by movement of a pointing device, and the image viewing application receives input data from the pointing device regarding movement of the pointing device.

[0017] In accordance with the disclosed subject matter, a method for rendering images on a device is provided. The method may include launching an image viewing application operating on a device, launching a plurality of windows in the image viewing application, the plurality of windows configured to execute an image viewer window and at least one application window, and establishing a configuration relationship between the plurality of windows on the device in the image viewing application. The plurality of windows are assigned a relationship configured to synchronize content between the plurality of windows, the image viewer window includes a first communication interface registered with at least one application window based on the configuration relationship, the at least one first application window includes a first window container operated by the device and a first web interface layer operated by a first server electrically coupled to the device, the image viewer window is operated by the device, and the first communication interface is configured to operate within the device in communicating between the image viewer window and the first window container.

[0018] The first application window may be either a server application window or an external application window. The server application window may be configured to run a server application, and the external application window may be configured to run an external application. The plurality of windows may include a second application window having a second window container operated by the device and a second web interface layer operated by one of a first server and a second server electrically coupled to the device. The image viewer window may include a second communication interface registered with the second application window. The second web interface layer operates within the device and at least one of the first server and the second server electrically coupled to the device when communicating with the first web interface layer. The second application window may be one of a server application window and an external application window, the server application window configured to run a server application, and the external application window configured to run an external application.

[0019] In accordance with the disclosed subject matter, a method for rendering images on a device is provided, the method may include launching an image viewing application operating on a device, launching a first instance of the image viewing application including a plurality of windows, the plurality of windows configured to execute at least an image viewer window and an application window, establishing a configuration relationship between the plurality of windows on the device, the plurality of windows being assigned a relationship configured to synchronize content between the plurality of windows, launching a second instance of the image viewing application including a second plurality of windows, the second plurality of windows being configured to execute at least a second image viewer window and a second application window, and establishing a second configuration relationship between the second plurality of windows on the device, the second plurality of windows being assigned a relationship configured to synchronize content between the second plurality of windows. Here, the image viewer window includes a first communication interface registered with the application window based on the setting relationship, and wherein the second image viewer window includes a second communication interface registered with the second application window based on the setting relationship, and wherein switching from the first instance to the second instance causes the at least one application window to be hidden and the at least one second window to be displayed.

[0020] The application window and the second application window may both execute the same application. The same application may be one of a server application, a device application, and an external application. The image viewing application may manage a memory cache to maintain memory usage below a predetermined value. The image viewing application may communicate with a device application, and the image viewing application may be configured to transfer data to the device application. The image viewing application may be configured to transfer images from the image viewing application to the device application. The method may include downloading data associated with at least the first instance to enable image viewing even while disconnected from the Internet. The data associated with the first instance may include at least a plurality of image files. The data associated with the first instance may include at least one of user settings, JavaScript, and HTML assets. The method may further include downloading data associated with at least the second instance to enable image viewing even while disconnected from the Internet. Switching from the first instance to the second instance may automatically save data associated with the application window to device memory. [Brief explanation of the drawings]

[0021] [Figure 1] 1 illustrates a hierarchy of a medical image record that may be rendered in accordance with the disclosed subject matter. [Figure 2] 1 illustrates the architecture of a system for rendering images within a device in accordance with the disclosed subject matter. [Figure 3] 1 illustrates the architecture of a system for rendering images within a device using an image viewing application in accordance with the disclosed subject matter. [Figure 4]1 illustrates a system architecture for an image viewing application in accordance with the disclosed subject matter. [Figure 5] 1 illustrates a system architecture for an image viewing application for tracking mouse movements in accordance with the disclosed subject matter. [Figure 6] 1 illustrates a system architecture for an image viewing application for tracking mouse wheel scrolling in accordance with the disclosed subject matter. [Figure 7] 1 illustrates a system architecture for an image viewing application for providing cine playback in accordance with the disclosed subject matter. [Figure 8] 1 illustrates the architecture of a system in an image viewing application for managing applications integrated into the image viewing application in accordance with the disclosed subject matter. [Figure 9] 1 illustrates the architecture of a system that provides management support for an image viewing application in accordance with the disclosed subject matter. [Figure 10] 1 is a flowchart illustrating how an image is rendered on a device in accordance with the disclosed subject matter. [Figure 11] 1 is a flowchart illustrating a method for rendering an image on a device in accordance with the disclosed subject matter. [Figure 12] 1 is a flowchart illustrating a method for rendering an image on a device in accordance with the disclosed subject matter. [Figure 13] 1 is a flowchart illustrating a method for rendering an image on a device in accordance with the disclosed subject matter. [Figure 14] 1 is a flowchart illustrating a method for rendering an image on a device in accordance with the disclosed subject matter. DETAILED DESCRIPTION OF THE INVENTION

[0022] Reference will now be made in detail to various exemplary embodiments of the disclosed subject matter, which are illustrated in the accompanying drawings. For purposes of illustration and not limitation, systems and methods are described herein for rendering images, particularly digital medical images (also referred to as "medical images"), and more particularly DICOM images.

[0023] However, the methods and systems described herein may be used to render any digital image. As used in this specification and the appended claims, singular forms such as "a," "an," and "the" (e.g., "one") are intended to include the plural unless the context clearly dictates otherwise. Thus, as used herein, the term "medical image" may refer to a single medical image or multiple medical images. For example, and for purposes of illustration and not limitation, referring to FIG. 1, a medical image record referenced herein may include a single DICOM Service Object Pair (SOP) instance (also referred to as a "DICOM instance," "DICOM image," and "image") 1 (e.g., 1A-1H), one or more DICOM SOP instances 1 in one or more series 2 (e.g., 2A-D), one or more series 2 in one or more studies 3 (e.g., 3A, 3B), and one or more studies 3. A DICOM image may have photometric interpretation tags associated with it. Photometric interpretation tags can identify, for example, that an image can be interpreted as Monochrome1, Monochrome2, RGB, YBR_Full, etc. DICOM images can have a window center attribute. DICOM images can have a window width attribute.

[0024] For purposes of illustration and not limitation, and referring to FIG. 2 , the disclosed system 100 may be configured to render digital images on a device. For example, the system 100 may be configured to render digital images of medical records, such as DICOM images 1 (e.g., 1A-1H). In particular, the system 100 may render DICOM images 11 (e.g., 1A-1H) so that the DICOM images 1 (e.g., 1A-1H) can be quickly and accurately displayed to perform medical diagnoses. The system 100 may include one or more computing devices defining a server 30 and a user workstation 60. The user workstation 60 may be connected to the server 30 by a network. The network may be, for example, a local area network (LAN), a wireless LAN (WLAN), a virtual private network (VPN), or any other network enabling any radio frequency or wireless type of connection. For example, other radio frequencies or wireless connections may include one or more network access technologies, including, but not limited to, Global System for Mobile Communications (GSM), Universal Mobile Telecommunications System (UMTS), General Packet Radio Service (GPRS), Enhanced Data GSM Environment (EDGE), Third Generation Partnership Project (3GPP) technologies (including Long Term Evolution (LTE), LTE-Advanced, 3G technologies, Internet of Things (IoT), Fifth Generation (5G), or New Radio (NR) technologies, etc.). Other examples may include Wideband Code Division Multiple Access (WCDMA), Bluetooth, IEEE 802.11b / g / n or any other 802.11 protocol, or any other wired or wireless connection.

[0025] The workstation 60 can take the form of any known client device. For example, the workstation 60 can be a computer, such as a laptop or desktop computer, a personal data assistant / personal digital assistant (PDA), or any other user equipment, such as a mobile device or mobile portable media player, or a tablet. The server 30 can be a service point providing processing, database, and communication capabilities. For example, the server 30 can include a dedicated rack-mounted server, a desktop computer, a laptop computer, a set-top box, an integrated device combining various functions, such as the functions of two or more of the foregoing devices, etc. The server 30 can include one or more processors, memory, and / or transceivers, although configurations and capabilities may vary. The server 30 can also include one or more mass storage devices, one or more power supplies, one or more wired or wireless network interfaces, one or more input / output interfaces, and / or one or more operating systems.

[0026] A user may be anyone authorized to access workstation 60 and / or server 30, including a medical professional, medical technician, researcher, or patient. In some embodiments, a user authorized to use workstation 60 and / or communicate with server 30 may have a username and / or password that can be used to log in to or access workstation 60 and / or server 30.

[0027] The workstation 60 may include a GUI 65, a display 64, a memory 61, a processor 62, and a transceiver 63. Medical image records 1 (e.g., 1A-1H) received by the workstation 60 may be processed using one or more processors 62. The processor 62 may be any hardware or software used to execute computer program instructions. These computer program instructions may be provided to a processor in a general-purpose computer to modify its functionality into a specific application, a special-purpose computer, an application-specific integrated circuit (ASIC), or other programmable digital data processing device, and the instructions executed via the processor of the workstation 60 or other programmable data processing device cause it to perform the functions / operations specified in the block diagram or one or more operational blocks, thereby modifying its functionality in accordance with embodiments herein. The processor 62 may be a portable embedded microcontroller or microcomputer. For example, processor 62 may be embodied by any computing or data processing device, such as a central processing unit (CPU), digital signal processor (DSP), ASIC, programmable logic device (PLD), field programmable gate array (FPGA), digital expansion circuit, or equivalent device, or combination thereof. Processor 62 may be implemented as a single controller or multiple controllers or processors.

[0028] The workstation 60 can transmit and receive medical image records 1 (e.g., 1A-1H) from the server 30 using a transceiver 63. The transceiver 63 can be a unit or device that can be independently configured as a transmitter, a receiver, or both a transmitter and a receiver, or both transmit and receive. In other words, the transceiver 63 can include any hardware or software that enables the workstation 60 to communicate with the server 30.

[0029] The transceiver 63 may be either a wired or wireless transceiver. If wireless, the transceiver 63 may be implemented as a remote radio head located on a mast rather than the device itself. While FIG. 2 illustrates only a single transceiver 63, the workstation 60 may include one or more transceivers 63. The memory 61 may be a non-volatile storage medium or any other suitable storage device, such as a non-transitory computer-readable medium or storage medium. For example, the memory 61 may be random access memory (RAM), read-only memory (ROM), a hard disk drive (HDD), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, or other solid-state memory technology. Additionally, memory 61 may be a compact disc read-only optical memory (CD-ROM), a digital versatile disc (DVD), any other optical storage, a magnetic cassette, a magnetic tape, a magnetic disk storage, or other magnetic storage device, or any other physical or material medium that can be used to tangibly store desired information, data, or instructions and that can be accessed by a computer or processor. Memory 61 may be removable or non-removable. Although FIG. 2 illustrates only a single memory 61, workstation 60 may include one or more memories 61. The one or more memories 61 may be of the same type or different types (e.g., one RAM and one HDD).

[0030] The workstation 60 can display the medical image records 1 (e.g., 1A-1H) on a display 64 via a GUI 65. The display 64 can be any device suitable for viewing the medical image records 1 (e.g., 1A-1H). For example, the display 64 can be a light-emitting diode (LED) display or a liquid crystal display (LCD). The display 64 can be integrated into the workstation 60 so that the workstation 60 is a single device, or can be a separate device connected by wire or wireless communication. Although FIG. 2 illustrates only a single display 64, the workstation 60 can include one or more displays 64. The GUI 65 can be an image viewing application 100 (shown in FIGS. 3 and 4).

[0031] The server 30 may include one or more server processors 31. The one or more processors may be of any of the types described above with respect to the workstation processor 62. The server 30 may include one or more server memories 38. The one or more memories may be of any of the types described above with respect to the workstation memory 61.

[0032] For purposes of illustration and not limitation, and referring to FIGS. 3 and 4 , an image viewing application 100 (also referred to as a Synapse diagnostic viewer 100) can be a native application deployed on a workstation 60 (also referred to as a diagnostic workstation 60), where a user interacts with the application and its content to interpret imaging studies 3 (e.g., 3A and 3B) shown in FIG. 1 . Native can mean workstation 60-based, as opposed to server 30-based or web-based, for example. The diagnostic viewer 100 is a hybrid application whose core implementation can be written in high-performance, cross-platform C++ technology or other suitable programming platform and can render web pages hosted on the server 30 (also referred to as a Synapse PACS client or server), thereby combining the capabilities of both native and web technologies. C++ technology is best suited for creating the diagnostic viewer 100. This is because, for example, C does not have the object-oriented paradigm necessary for designing and developing larger systems, and C# and Java® are not purely native because running code compiled from C# or Java® may require an interpreter layer between the hardware and the program. The diagnostic viewer 100 works best when it can execute directly with the hardware without another layer between the program and the hardware. Object C could also be used, but would only be suitable for MAC OS® systems. Native technologies can include the resources of the workstation 60. The resources of the workstation 60 can include the following non-exhaustive list: workstation processor 62, workstation memory 61 (including RAM, hard disk storage, or any of the memory described above).The diagnostic viewer 100 may include the ability to host existing application web pages within its native window container 103, allowing the diagnostic viewer 100 to reuse the resources of the workstation 60 while enhancing intuitive functionality. The diagnostic viewer 100 may implement advanced functionality using the resources of the workstation 60. The diagnostic viewer 100 may include integration of external applications 200 (sometimes referred to as third-party applications) having web pages hosted on an external server (not shown). The diagnostic viewer 100 may include integration of a Synapse Agent 300. The Synapse agent 300 may be a lightweight application with the following functions: (1) maintaining the life of the diagnostic viewer 100 by launching it when a user logs into the operating system; (2) maintaining the login session based on the user's session; (3) performing maintenance needs such as clearing the temporary internet file cache and clearing cached DICOM content from disk (if any) during logoff or shutdown; (4) providing a tray icon and context menu for performing operations such as launching the application, logging in, logging off, configuring data sources, and shutting down; and (5) enabling management tasks including, for example, viewing the current version, testing compatibility with data sources for connecting to the system, viewing current health status, connection status, performance benchmarks, upgrading to the latest version, and uploading troubleshooting to the server.

[0033] The diagnostic viewer 100 can reuse existing web page-based user interfaces, allowing users to use the diagnostic viewer 100 to have the same application experience as when launching a web browser-based image viewing application (also known as Synapse Zero Viewer). While existing web browser-based image viewing applications utilize server-side rendering and transmit image files over a network, the diagnostic viewer 100 can take advantage of a distributed computing paradigm by performing rendering on the workstation 60. While the diagnostic viewer 100 can utilize the resources of the workstation 60 for its processing needs, the diagnostic viewer can also provide greater accuracy and performance without relying on latency from the web browser or the network.

[0034] The diagnostic viewer 100 may include one or more native window containers 103 that host each web page of an application hosted by the server 30. In addition, the diagnostic viewer 100 may include a workstation implementation for downloading and caching DICOM images 1 (e.g., 1A-1H) from the server memory 38 to the workstation memory 61 or workstation cache 61, workstation rendering of images, workstation implementation of imaging functions such as image playback / scrolling, advanced imaging functions such as volume rendering, advanced workflow functions such as multi-study dictation, or any other suitable implementation. In general, implementations requiring performance and accuracy beyond what a web implementation can provide can operate with a workstation implementation.

[0035] The diagnostic viewer 100 may include one or more native window containers 103 capable of rendering web pages 111, 112, 113, 114 of applications hosted on at least one of the server 30 or a second server (not shown). By utilizing a native window container framework, the diagnostic viewer 100 eliminates the need to use a third-party browser application to host applications hosted on the server 30. The web pages may include a Worklist 111, a Power Jacket 112, a Cardiology Advanced Reporting 113, a Series Viewer Settings 114, integrated third-party web pages (which may include a third-party worklist 201, clinical applications 202, reporting applications 203, and a dictation system 204), as well as other web pages not shown. For example, other window containers 103 may include homegrown or third-party web pages such as (1) homegrown web pages that may be used to display radiologist / physician notes (e.g., regarding an exam), reports, or other related documents; (2) integrated third-party vendor-developed applications or web pages for displaying notes, reports, or documents; (3) integrated third-party vendor clinical applications for assisting in the reading of Study 3 (e.g., 3A and 3B); (4) integrated third-party vendor reporting / dictation applications for creating or viewing reports; and (5) third-party worklist or workflow applications.

[0036] Server 30 may include one or more server-based applications (e.g., 32, 33, 34, 35, 36, 37) stored in one or more server memories 38 and processed within server 30 by one or more server processors 31. The server-based applications may include Application UI 32, Study Service 33, Streaming Service 34, Image Rendering Service 35, Single Sign-On (SSO) 36, Administration Services 37, and other server applications not shown (e.g., DICOM services, administration services used for management, monitoring, and troubleshooting). Application UI 32 may include HTML / JavaScript implementations of Image Viewer 124, Worklist 111, Power Jacket 112, Advanced Reports 113, or other suitable programs, including the Synapse Zero Viewer web application, which may be hosted on Synapse PACS server 30 and launched in a web browser. Other example programs include (1) Synapse Collaboration Chat, (2) User / Administrative Settings UI, (3) Series Viewer (unlike Image Viewer 124, which is used to display the entire Study 3 (e.g., 3A, 3B), the Series Viewer is for visualizing images from one Series 2 (e.g., 2A-2D) of Study 3 (e.g., 3A, 3B) at a time), (4) Synapse Help Page, (5) DICOM Transfer / Media Burn UI, which can be used to send DICOM images to other servers capable of receiving them or to burn DICOM images to media, and (6) Synapse 3D, an application that can be used for advanced 3D visualization capabilities.

[0037] The Synapse Diagnostic Viewer 100 can render the same web implementation in a native window container 103, providing the same UI / UX experience to the user. The study service 33 can provide study information to the diagnostic viewer 100 for displaying imaging studies in the viewer 100. Study information can also be provided for display in a worklist 111 and a power jacket 112.

[0038] The streaming service 34 can be used by the diagnostic viewer 100 to download medical images 1 (e.g., 1A-1H) for local rendering. The diagnostic viewer 100 can download images 1 (e.g., 1A-1H) by sending one HTTP request per image 1 (e.g., 1A-1H). For multi-frame images, the streaming service 34 can perform frame segmentation, allowing the diagnostic viewer 100 to download medical images 1 (e.g., 1A-1H) frame by frame by sending one HTTP request per frame. The image rendering service 35 runs on the Synapse Server 30 and can perform server-side rendering for the Zero Viewer 32. The Synapse Diagnostic Viewer 100 can use this service to render images 1 (e.g., 1A-1H) when the corresponding DICOM images 1 (e.g., 1A-1H) have not been downloaded to the workstation 60 but the images 1 (e.g., 1A-1H) need to be displayed in the image viewport 102. The SSO 36 may allow users of the diagnostic viewer 100 to log into the system. The administration services 37 may include a set of services for managing the deployment, upgrades, monitoring, troubleshooting and maintainability of the diagnostic viewer 100.

[0039] 7 / 2 The Diagnostic Viewer 100 can include one or more native window containers 103 that host one or more web pages from the Synapse PACS server 30. For example, the worklist 111, power jacket 112, and other applications (not including the image viewer 124) can be hosted in one of the native window containers 103, similar to how these web pages are rendered in modern web browsers. The image viewer 124 can also be hosted in the native image viewer window container 101, but certain portions of this web page can be overridden by the native implementation to provide intuitive and accurate image processing and visualization performance. Some portions of the image viewer 124 can be reused from the web implementation. For example, a Study List Grid 121 (which may display a list of all of the patient's DICOM studies, including the currently being read Study 3 (e.g., 3A and 3B) and previous studies, if any), a Series Picker 122 (which may include a list of thumbnails displayed side-by-side, with each thumbnail representing a Series 2 (e.g., 2A-2D) in Study 3 (e.g., 3A and 3B) opened in Image Viewer 124), a Viewer Toolbar 123 (which may include UI for enabling imaging tools during reading), a Context Menu (not shown) (which may include UI for enabling imaging tools during reading), and various buttons and indicators. For example, a Reading Protocol Editor may be used to prepare / modify a reading protocol to arrange the prepared layout when viewing Study 3 (e.g., 3A and 3B) in Image Viewer 124. Any series picker similar to the series picker 122 shown at the top of the image viewer 124 is available to invoke anywhere within the image viewer 124 and can be moved around for convenience.The Thinklog panel can show the AI ​​and CAD algorithms used to analyze Study 3 (e.g., 3A and 3B) or the results of manual / CAD findings from the patient's previous studies. The image viewport 102 can be the area where Images 1 (e.g., 1A-1H) can be displayed for interpretation. The existing ZeroViewer web-based implementation can be overridden with a native image visualization implementation, for example, using C++.

[0040] When the diagnostic viewer 100 is launched on the workstation 60, the diagnostic viewer 100 can connect to the server 30. A user can provide login information to the diagnostic viewer 100 to access the application. The user can then select one or more imaging studies from a worklist 111 provided with other server 30-hosted applications. During launch of the diagnostic viewer 100, the diagnostic viewer 100 can begin initializing at least one native image viewer window container 101. During login, the diagnostic viewer 100 can begin rendering at least one web page within the at least one native image viewer window container 101, making one or more features of the diagnostic viewer 100 available to the user once they are ready to view the clinical content. When the user opens clinical content, such as DICOM studies 3 (e.g., 3A and 3B), the diagnostic viewer 100 can display at least one native image viewer window container 101 to the user. This allows for quick viewing and navigation of the UIs of various applications, providing the user with a fast and efficient workflow. Additionally, at least one native image viewer window container 101 can fully display clinical content such as DICOM study 3 (e.g., 3A and 3B) before the at least one native image viewer window container 101 is presented to the user, thereby eliminating potential workflow ambiguity for the user by preventing the user from viewing a partial state.

[0041] Upon opening clinical study 3 (e.g., 3A and 3B), the diagnostic viewer 100 begins downloading all images 1 (e.g., 1A-1H) in study 3 (e.g., 3A and 3B) to the workstation 60 and stores them in the workstation cache 61. The workstation cache 61 may consist of an in-memory image cache (not shown) and a disk cache (not shown). The in-memory portion of the cache 61 may have an upper size threshold that can be calculated based on the memory configuration and available primary memory (i.e., the free space available in the workstation 60's RAM) within the workstation 60. An automatic calculation can calculate the available space based on the workstation 60's configuration. For example, in a configuration using 3 GB of minimum memory and 80% stretch capacity, the automatic calculation logic can determine to use a minimum of 3 GB and a maximum of 80% of the free RAM space within the workstation 60 by ensuring that 20% of the RAM space within the workstation 60 is available for running other applications. This is a configurable percentage, and a particular workstation 60 can set a preferred percentage based on the available hardware and other applications expected to run on the workstation 60. When the size of downloaded images 1 (e.g., 1A-1H) reaches a threshold, the remaining images 1 (e.g., 1A-1H) can be saved to a disk cache (not shown). Image caching ensures that images 1 (e.g., 1A-1H) are locally available at the workstation 60, allowing the diagnostic viewer 100 to render the locally available images 1 (e.g., 1A-1H) on the workstation 60 itself, without having to access the images 1 (e.g., 1A-1H) from the server 30. This speeds up the performance of imaging functions, including cine playback, scrolling, and interactive imaging operations, without the network delays currently associated with server-side image rendering. Downloads can begin automatically when a study 3 (e.g., 3A and 3B) is opened in the diagnostic viewer 100.A user can also subscribe to one or more clinical studies 3 (e.g., 3A and 3B) or one or more worklist folders in the worklist 111, allowing streaming and caching to occur in the background so that images 1 (e.g., 1A-1F) are available to the workstation 60 before the user opens a study 3 (e.g., 3A and 3B). Caching images 1 (e.g., 1A-1F) of a study 3 (e.g., 3A and 3B) can include caching related prior study images 1 (e.g., 1A-1F), thereby ensuring that related prior study images 1 (e.g., 1A-1H) are also available locally. Related prior images 1 (e.g., 1A-1H) can be identified based on the user's reading protocol preferences. For example, a preference can be provided in the reading protocol settings, which can provide the number of prior studies the user desires to compare with study 3 (e.g., 3A and 3B). A set of rules can be provided for selecting and using related prior studies from among available prior studies. The number of prior studies can range from 0 to 6, and rules for finding related prior studies can include matching modality, procedure, procedure date, or other relevant aspects of study 3 (e.g., 3A and 3B) or prior studies. When a user opens study 3 (e.g., 3A and 3B), if rules are configured and diagnostic viewer 100 identifies that prior studies exist, study 3 (e.g., 3A and 3B) is presented to the user, and diagnostic viewer 100 can automatically compare study 3 (e.g., 3A and 3B) with the identified prior studies. As diagnostic viewer 100 presents study 3 (e.g., 3A and 3B) and related prior studies during reading, a caching algorithm can use configured preferences to pull related prior studies into the workstation cache 61 in addition to the current study 3 (e.g., 3A and 3B) so that DICOM images from the prior studies are also available for rapid rendering and display.

[0042] A cache (e.g., 3A and 3B) of images 1 (e.g., 1A-1F) from a clinical study 3 can be assigned a priority value. By way of example, the priority value is one of five priority values. Priority 1 can be the image 1 (e.g., 1A-1H) that needs to be displayed immediately and is considered the highest priority and will be downloaded first. Priority 2 can include the neighboring images 1 (e.g., 1A-1H) of the currently displayed image 1 (e.g., 1A-1H) in the image stack, which are likely to be displayed next and therefore downloaded with the next highest priority. Priority 3 can be all other images 1 (e.g., 1A-1H) belonging to a DICOM series 2 (e.g., 2A-2D) (a stack of images displayed within the viewport) that can be downloaded next. Priority 4 can be the remaining images 1 (e.g., 1A-1H) belonging to the study 3 (e.g., 3A and 3B) being diagnosed, as well as any preceding studies 3 (e.g., 3A and 3B) associated with the study 3 (e.g., 3A and 3B).

[0043] Priority 5 is an image 1 (e.g., 1A-1H) of study 3 (e.g., 3A and 3B) that is registered in the worklist 111 of the next image study 3 (e.g., 3A and 3B) to be used but has not yet been opened in the diagnostic viewer 100, and can be considered the lowest priority.

[0044] The diagnostic viewer 100 can use the assigned priority values ​​to ensure that the next image 1 (e.g., 1A-1H) to be displayed is available in an in-memory cache (also referred to as primary memory) and can allow the least needed image 1 (e.g., 1A-1H) to remain in a disk cache (also referred to as secondary memory) until it is needed. The diagnostic viewer 100 can perform intelligent memory management to ensure that the actively displayed image 1 (e.g., 1A-1H) and the next image 1 (e.g., 1A-1H) to be displayed are available in primary memory, and the diagnostic viewer 100 can swap content between the primary memory and secondary memory depending on the priority and availability of primary memory space designated for storing cached DICOM images 1 (e.g., 1A-1H).

[0045] Because DICOM-formatted images 1 (e.g., 1A-1H) may be compressed using any of the DICOM-supported compression formats, images 1 (e.g., 1A-1H) must be decompressed before they can be rendered into displayable images 1 (e.g., 1A-1H). By respecting the above-mentioned priorities and based on the availability of designated memory space in the workstation cache 61 for storing decompressed pixel data, the diagnostic viewer 100 can perform intelligent background decompression on images 1 (e.g., 1A-1H) that are next needed for display. This allows for faster image rendering when images 1 (e.g., 1A-1H) need to be displayed in the viewport 102. Decompression can be performed using multiple CPU cores in the workstation 60, based on the compression technique used and the availability of CPU cores in the workstation 60 at the time of the decompression process.

[0046] Image 1 (e.g., 1A-1H) can be a multi-frame SOP class image or a multi-frame image (e.g., TOMO, US, XA, etc.). In a multi-frame image, Image 1 (e.g., 1A-1H) may contain multiple frames, resulting in a relatively large image file. This can pose a challenge to download performance because a user must wait for the large multi-frame SOP class image to finish downloading before beginning to perform diagnostic viewer functions (e.g., scrolling, cine playback, etc.). The diagnostic viewer 100 can download multi-frame SOP class images to the workstation 60 one frame at a time. The server 30 can perform frame segmentation of multi-frame images to enable multiple frame downloads on a frame-by-frame basis. This can eliminate the potential additional wait time required for multi-frame SOP class images and provide the same initial display performance as single-frame SOP images (e.g., CT, MR, CR / DX, etc.).

[0047] The diagnostic viewer 100 can use image processing and rendering algorithms to create a displayable image 1 (e.g., 1A-1H) from a DICOM image 1 (e.g., 1A-1H) locally on the workstation if the DICOM image 1 (e.g., 1A-1H) is available in the workstation cache 61. This local rendering eliminates the need for the workstation 60 to access server resources in real time over the network, providing better performance and predictability, especially in low-bandwidth scenarios. Local rendering can also eliminate the need for additional compression, transmission, and decompression of the image 1 (e.g., 1A-1H) before displaying it. This is because both the rendering and display of the image 1 (e.g., 1A-1H) can occur within the address space of the diagnostic viewer process. The rendered pixel data can be in the same format as required for display on the viewport. The rendered pixel data format can be dynamically selected based on the decompressed pixel channels of the DICOM image 1 (e.g., 1A-1H); for example, a single-channel image can be rendered to 16-bit display pixels, while a multi-channel image can be rendered to an RGB display pixel format.

[0048] When the DICOM images 1 (eg, 1A-1H) are still in compressed form, the diagnostic viewer 100 can automatically perform DICOM decompression to ensure that the decompressed pixels are available for rendering.

[0049] The image rendering of the diagnostic viewer 100 can support not only regular 2D image rendering, but also all necessary image processing, such as scaling, windowing, inversion, flipping, and rotation. The diagnostic viewer 100 can also support multiplanar reconstruction, multimodality fusion, and volume rendering. The diagnostic viewer 100 can also provide various image processing techniques, such as automatic registration of anatomical structures between images 1 (e.g., 1A-1H) belonging to different reference frames, height alignment of MG view pairs, among other techniques, such as pixel density calculation of selected pixels in an image or a selected region of interest in a CT image, automatic calculation of breast boundaries by removing non-breast tissue in a mammogram image, and automatic segmentation of region(s) in an image with respect to a given selected point.

[0050] The diagnostic viewer 100 may be designed to perform image rendering locally on the workstation 60 by utilizing the workstation's processing power. For example, the diagnostic viewer 100 may establish distributed computing and eliminate the need to use server-side rendering over a network. However, when performing remote reading, image downloads of DICOM image files 1 (e.g., 1A-1H) from the server 30 to the workstation 60 may be slower. Therefore, if caching of images 1 (e.g., 1A-1H) to be displayed in the viewport 102 is still in progress, the user may experience slower initial display performance and image scrolling performance. As described above, the diagnostic viewer 100 may have download priority management to ensure that available network bandwidth is utilized to download a series of images 1 (e.g., 1A-1H) being displayed before other content, although this may still depend on the network speed and the size of the image 1 (e.g., 1A-1H) files. To eliminate and / or mitigate such remote reading and slow network issues, the diagnostic viewer 100 can perform server-side rendering when the corresponding image 1 (e.g., 1A-1H) has not yet been downloaded and cached. As an example, when a DICOM image 1 (e.g., 1A-1H) is not yet available in the workstation cache 61, the diagnostic viewer can perform server-side rendering by requesting the server 30 to provide a rendered, displayable image 1 (e.g., 1A-1H) in a compressed format (e.g., PNG). The image 1 (e.g., 1A-1H) can then be decompressed into a device-specific display format and displayed on the viewport. In addition to the compressed image, DICOM header information can also be downloaded from the server 30 and decoded at the workstation 60 to visualize overlay information on top of the image 1 (e.g., 1A-1H).

[0051] Before displaying a rendered image in the viewport, the diagnostic viewer 100 can prepare additional overlays to be displayed with the image. Such overlays can include text overlays containing multiple clinically relevant text and numerical information about the DICOM image and scale markers to assist the user in performing measurements and analysis. These overlays can be burned into the displayable image before the image is displayed in the viewport 102, ensuring that the displayed image is stable and free of flickering effects. Furthermore, all images 1 (e.g., 1A-1H) belonging to series 2 (e.g., 2A-2D) of image 1 (e.g., 1A-1H) can be displayed together without potential mismatches. Once the necessary layers have been burned into image 1 (e.g., 1A-1H), the diagnostic viewer 100 can present image 1 (e.g., 1A-1H) in the viewport 102 so that the user can view image 1 (e.g., 1A-1H).

[0052] Instead of using a different scaling, diagnostic viewer 100 can calculate the viewport space at 100% DPI scaling. Such scaling ensures that images 1 (e.g., 1A-1H) are rendered without loss of image quality due to the DPI scaling of the display device. Additionally or alternatively, diagnostic viewer 100 can display a similar calibration to existing browser-based viewers.

[0053] The diagnostic viewer 100 can synchronize the swapping of image frames to the refresh rate of the monitor of the display 64 while the user navigates through the image stack (series 2 (e.g., 2A-2D)). This synchronization prevents image 1 (e.g., 1A-1H) from being hidden from the user due to a race condition between the monitor's hardware refresh clock and the CPU's clock. In a multi-monitor environment, e.g., multiple displays 64, the refresh rate of each monitor can be adjusted individually in conjunction with the frame rate at which image navigation is desired by the user.

[0054] 5, for purposes of illustration and not limitation, the diagnostic viewer 100 may enable a user to navigate through the images 1 (e.g., 1A-1H) displayed in the viewport using mouse movements. There are three different modes in which a user may navigate through the images 1 (e.g., 1A-1H) using mouse movements: (1) precision mode, (2) standard mode, and (3) rapid mode.

[0055] In Precision Mode, users can navigate through images 1 (e.g., 1A-1H) one by one without skipping any images in between. This non-skip mode navigation allows users to perform precise visualization and analysis of anatomical regions within the image stack without missing any images 1 (e.g., 1A-1H).

[0056] In standard mode, the user can navigate through images 1 (e.g., 1A-1H) at a frame rate tied to the speed of the user's mouse movements. When the mouse moves slowly, the image navigation follows the mouse at a slower rate, and as the mouse moves faster, the navigation speed increases. This mode also allows the user to navigate through smaller, medium, or larger stacks of images 1 (e.g., 1A-1H) with similar mouse movements.

[0057] Rapid mode allows the user to scroll in standard mode with half the mouse movement required in standard mode.

[0058] To achieve smoother and more fully controlled navigation of images 1 (e.g., 1A-1H) using mouse movements, highly accurate mouse event processing is required. The diagnostic viewer 100 can receive mouse events 71 as raw input directly from the mouse device 70 connected to the workstation 60, which helps the diagnostic viewer 100 track precise mouse movements by the user. This type of event processing helps ignore other mouse event handlers on the workstation 60 because the additional mouse tracking is performed in the existing web page layer implementation as an HTML / JavaScript event handler, and does not interfere with the need for precise event processing in the native layer. The diagnostic viewer 100 can process both relative and absolute mouse movements, allowing the diagnostic viewer 100 to accurately track the mouse device 71 in any type of environment, including virtual desktop environments.

[0059] 7 / 2 Image scrolling begins when a user initiates a dynamic scrolling operation from the diagnostic viewer 100. In the diagnostic viewer, the web implementation 124 can hand off control to the native implementation 101 of dynamic scrolling so that the native implementation 101 has full control of the navigation, providing the user with a premium image scrolling experience.

[0060] Within the diagnostic viewer 100, the Scroll Orchestrator 106A engine may be a single-threaded engine that coordinates scrolling operations. When dynamic scrolling is initiated, the Scroll Orchestrator 106A can begin tracking mouse movement by monitoring mouse events 71 from the mouse device 70 and can calculate scroll parameters (e.g., direction, frame rate, images to be displayed, anatomical structures the user intends to navigate to or remain near, etc.). The Scroll Orchestrator 106A can also track past mouse movements and perform processing tasks, such as rendering, in advance to ensure accurate navigation predictions. When identifying an image 1 (e.g., 1A-1H) to be displayed during each frame swap in the image scroll, the Scroll Orchestrator 106A also identifies related images 1 (e.g., 1A-1H) in other viewports 102 by calculating various intelligent scroll evaluation criteria.

[0061] IntelliScroll can provide the ability to scroll / navigate the active viewport, and images displayed in other viewports are automatically scrolled relative to the active viewport. Various rules can be provided to determine how other viewports are scrolled in synchronization with the active viewport. For example, "Orientation" mode synchronization (primarily used for CT / MR / PET examinations) can scroll other viewport images that match the spatial plane. In this case, the images in the active viewport and other viewports must be coplanar (the spatial plane angles must be the same or within 30 degrees of each other) and their spatial locations must be at the patient's position regardless of the reference frame. As used herein, a reference frame refers to the patient's position as the reference when the scan is performed. This is a special type of synchronization. "Frame of Reference" mode synchronization (primarily used for CT / MR / PET examinations) is the same as "Orientation" mode, except that both images must be in the same reference frame. This is also a type of spatial synchronization. "Sync by Index" mode (used in any modality) can synchronize images in other viewports by matching the image index of the active viewport. The "Synch by R-Wave" mode (used in ultrasound and X-ray multiframe) can synchronize other viewports with the active viewport using a time vector so that heart rate and ECG signals always match. This is a type of temporal synchronization. The "Synch by Prior" mode (used in mammogram examinations) can provide stacking viewports in which mammogram images from the current and previous examinations are displayed together and scrolled by matching index. The "XA Biplane" mode can display X-ray biplane multiframe images side by side, so that scrolling a frame in one plane automatically scrolls the corresponding frame in the other plane."Echo" mode allows synchronization in the same way as "R-wave synchronization" mode, but groups different views or stages of an ultrasound echo examination.

[0062] Within the diagnostic viewer 100, the caching and decoding engine 104 may be a multi-threaded engine that can use navigation information compiled by the scroll orchestrator 106A to ensure that required images 1 (e.g., 1A-1H) are downloaded to the workstation cache 61 if they have not already been downloaded. Also, if the cached images 1 (e.g., 1A-1H) are in compressed format, the images 1 (e.g., 1A-1H) may be decoded into a decompressed pixel data format for faster rendering. The order of caching and decoding may be based on the scrolling speed and direction predicted by the scroll orchestrator 106A.

[0063] Within the diagnostic viewer 100, the image render engine 105 may be a multi-threaded engine that can render images 1 (e.g., 1A-1H) that are required to be displayed to achieve image navigation using navigation information compiled by the scroll orchestrator 106A. The image renderer can perform image rendering using one or more processors 62 of the workstation 60 based on priority. The priority can be determined by the navigation information compiled by the scroll orchestrator 106A. As a non-limiting example, an image 1 (e.g., 1A-1H) that is required to be displayed can be rendered first, while a second image 1 (e.g., 1A-1H) that is required to be displayed can be rendered second, and an image 1 (e.g., 1A-1H) that is likely to be required in the near future can be rendered third. The image render engine 105 can generate rendered pixel data and overlays 109 and store them in the tracker 108. In addition to the image 1 (e.g., 1A-1H) desired to be displayed in the active viewport 102, the images 1 (e.g., 1A-1H) desired to be displayed in other linked viewports 102 may be rendered and stored together in the tracker 108. This process may continue with navigation, as not all images 1 (e.g., 1A-1H) may be kept in the tracker 108 at a given time because the diagnostic viewer 100 must manage memory usage during scrolling. This may be based on the number of images that may be rendered in the background, a value that may be calculated by the scroll orchestrator 106A. This value may be calculated based on a configured value (e.g., a default may be 64), may attribute the size required for each rendered image in memory, and may be verified against the maximum number of rendered image caches (which may be another configured value (e.g., a default may be 2GB)).At a particular point in time, the tracker 108 has an active image 1 (e.g., 1A-1H), a certain number of images 1 (e.g., 1A-1H) that are already displayed but are needed to allow for a possible quick reversal in the direction of image navigation, and a certain number of images 1 (e.g., 1A-1H) that can be displayed in the next few seconds in the direction of scrolling.

[0064] Even though this process can ensure that image 1 (e.g., 1A-1H) required to be displayed in viewport 102 is available when navigation requires image 1 (e.g., 1A-1H), there may be situations where image 1 (e.g., 1A-1H) is not available in tracker 108. In such situations, high priority rendering may be triggered by scroll orchestrator 106A for image 1 (e.g., 1A-1H), allowing image 1 (e.g., 1A-1H) to be immediately rendered and displayed in viewport 102.

[0065] Within the diagnostic viewer 100, the visualization engine 107 can be a multi-threaded engine responsible for drawing images 1 (e.g., 1A-1H) and overlays 109 onto the viewport 102. The visualization engine 107 can retrieve the rendered images 1 (e.g., 1A-1H) and overlays 109 from the tracker 108 and perform off-screen rendering to create a memory image for the viewport 102 by combining both the images 1 (e.g., 1A-1H) and the overlays 109. The visualization engine 107 can then draw the resulting off-screen image onto the on-screen viewport 102. This can prevent flickering during frame swaps on the visual screen. This can eliminate the possibility of mismatches between the images 1 (e.g., 1A-1H) and overlays 109 presented on the viewport 102. This off-screen rendering can occur not only for the image 1 (e.g., 1A-1H) that is to be displayed in the active viewport 102, but also for the image 1 (e.g., 1A-1H) that is required to be displayed in linked viewports 102, with all updated viewports presented with the new off-screen image. The rendering of the new image 1 (e.g., 1A-1H) to each viewport can be performed in parallel by the visualization engine 107, with one or more dedicated processors 62 of the workstation 60 being used to render the image 1 (e.g., 1A-1H) to each viewport 102. This eliminates the possibility of mismatched images 1 (e.g., 1A-1H) appearing in linked viewports and provides the best IntelliScroll experience since all required viewports are updated together.

[0066] There are various intelligent scrolling criteria that the diagnostic viewer 100 can provide, including, but not limited to, index synchronization (multiple viewports can be scrolled in unison by synchronizing on an image index), reference frame synchronization (multiple viewports can be scrolled in unison by identifying matching spatial images 1 (e.g., 1A-1H) for an image 1 (e.g., 1A-1H) displayed in the active viewport, but limited to images 1 (e.g., 1A-1H) having the same reference frame), orientation synchronization (multiple viewports can be scrolled in unison by identifying matching spatial images 1 (e.g., 1A-1H) for an image 1 (e.g., 1A-1H) displayed in the active viewport, but limited to images 1 (e.g., 1A-1H) having the same spatial orientation), and other suitable intelligent scrolling functions, such as those described above.

[0067] 6, for purposes of illustration and not limitation, the diagnostic viewer 100 may also enable a user to utilize wheel movement of the mouse 70 to navigate the images 1 (e.g., 1A-1H) displayed in the viewport 102. There are four different modes in which a user may navigate the images 1 (e.g., 1A-1H) using mouse movement: (1) Legacy Mode, (2) Lightning Mode, (3) Dual Mode, and (4) Adaptive Mode.

[0068] In legacy mode, the user can navigate through images 1 (e.g., 1A-1H) one by one with each wheel notch movement. In this mode, regardless of the strength of the mouse wheel rotation, navigation always corresponds to one image 1 (e.g., 1A-1H) per wheel notch movement, allowing the user to precisely navigate the anatomy.

[0069] In Lightning mode, the user can initiate image playback depending on the speed of the mouse wheel movement. For example, navigation through images 1 (e.g., 1A-1H) can be performed at a specific frames per second, typically 60 fps.

[0070] Dual mode allows users to combine features from both Legacy and Lightning modes, for example, users can rotate the mouse wheel one notch at a time for slow notch-by-notch image navigation, or rotate the mouse wheel continuously to switch to a Lightning-like playback mode.

[0071] In adaptive mode, the user can slowly navigate through images 1 (e.g., 1A-1H) one at a time by rotating the mouse wheel one notch at a time. The user can also accelerate navigation by accelerating the mouse wheel rotation, typically providing 10 fps image navigation. The user can increase the mouse wheel rotation speed and continuity to 15 fps, 30 fps, 45 fps, 60 fps, etc. Similarly, the user can decrease the mouse wheel rotation speed and continuity to reduce fps. Adaptive mode provides precise navigation control over mouse wheel movement.

[0072] Image scrolling can begin when the user focuses on the viewport 102 and begins to rotate the mouse wheel. In the diagnostic viewer 100, the web implementation 124 is hidden, allowing the native implementation of wheel scrolling 101 to take full control of navigation, providing the user with a premium image scrolling experience.

[0073] Like elements in FIG. 6 are like numbered and may include all of the features described above with respect to FIG.

[0074] 7, for purposes of illustration and not limitation, the diagnostic viewer 100 may enable a user to perform image playback on DICOM Series 2 and may provide the ability to input the playback speed in frames per second. There may be various types of playback modes supported by the diagnostic viewer 100: (1) Loop Playback, (2) Oscillation Playback, and (3) Independent Playback.

[0075] Loop playback can start from the current image 1 (e.g., 1A-1H), continue to the last image 1 (e.g., 1A-1H) in the viewport, and start the next loop from the first image 1 (e.g., 1A-1H). This can continue until the user stops playback or changes the playback mode to oscillation.

[0076] Oscillatory playback can start from the current image 1 (e.g., 1A-1H) and continue to the last image 1 (e.g., 1A-1H) in the viewport 102, and then play backward from the last image 1 (e.g., 1A-1H) to the first image 1 (e.g., 1A-1H). This can continue until the user stops playback or changes the playback mode to loop.

[0077] Independent playback allows each viewport 102 to adjust its own playback speed in frames per second.

[0078] Achieving accurate playback at accurate frames per second per viewport 20 requires extremely accurate animation events to hit the processor at set intervals. The Cine Engine 106B can have a high-precision multimedia timer 72 that can hit timer steps accurately every millisecond, allowing the Cine Engine 106B to play back at an accurate frame rate. This can be achieved by configuring a timer that can be synchronized with a CPU counter, so that the timer hits every millisecond when the CPU counter counts every millisecond. If the CPU clocking is every millisecond, to ensure that the Diagnostic Viewer 100 does not miss a counter hit even when the application thread is busy with other operations, the Diagnostic Viewer 100 can use a dedicated thread to listen to the CPU clocking and a queue to which the 1 millisecond clocking is sent. This allows the Diagnostic Viewer 100 to accurately track 1 millisecond intervals.

[0079] Cine playback can begin when a user initiates playback from the diagnostic viewer 100. If configured to do so, cine playback can also begin when the diagnostic viewer 100 is first displayed based on the study modality. In the diagnostic viewer, playback is coordinated by the cine engine 106B in the native implementation 101. The cine engine 106B can start the multimedia timer 72 and calculate playback parameters for the images 1 (e.g., 1A-1H) that need to be displayed in each viewport 102, such as orientation, frames per second required for each viewport, and for each frame swap per animation interval.

[0080] The caching and decoding engine 104 can use the playback information compiled by the cine engine 106B to cause the required image 1 (e.g., 1A-1H) to be downloaded to the workstation cache 61 if it has not already been downloaded. Like elements in Figure 7 are like numbered and can include all of the features described above with respect to Figure 5.

[0081] The diagnostic viewer 100 can include several synchronization playback criteria, such as index synchronization (multiple viewports can be played back together by synchronizing on image index), reference frame synchronization (multiple viewports can be played back together by identifying matching spatial images 1 (e.g., 1A-1H) with respect to the image 1 (e.g., 1A-1H) displayed in the active viewport, but only images 1 (e.g., 1A-1H) having the same reference frame), orientation synchronization (multiple viewports can be played back together by identifying matching spatial images 1 (e.g., 1A-1H) with respect to the image 1 (e.g., 1A-1H) displayed in the active viewport, but only images 1 (e.g., 1A-1H) having the same spatial orientation), and / or other suitable playback criteria. The diagnostic viewer 100 can include independent playback at different frame-per-second rates for each viewport 102, R-wave synchronization, echo playback, biplane playback, modality-based DSA playback, and other suitable playback criteria. DSA is a technique for blending X-ray contrast and mask frames from the same X-ray multi-frame image, where the mask and contrast frames are specified in the DICOM header of the image based on the acquisition method by the X-ray scanner. During scrolling, the diagnostic viewer 100 can ensure that the mask and contrast are always blended together and visualized together when DSA mode is on. When DSA mode is off, the mask and contrast images can be displayed as independent frames of the image stack.

[0082] Cine playback can have a maximum speed of 60 fps on a monitor with a 60 Hz refresh rate. Cine playback can also have a maximum speed of 120 fps on a monitor with a 120 Hz refresh rate. Cine playback can also have a skippable mode playback where the maximum speed exceeds the refresh capability of the monitor.

[0083] The diagnostic viewer 100 can perform image rendering on a workstation 60 with multiple high-resolution monitors 64 (6 megapixels or greater). Each monitor 64 can include a large 1-up viewport 102 on which an image 1 (e.g., 1A-1H) is displayed. While the monitors 64 can achieve 60 fps with synchronized playback across multiple monitors 64, the frame rate may drop to a realistically achievable maximum of 30 or 40 fps. To overcome this limitation, rather than using a graphics processing unit (GPU), the diagnostic viewer 100 can include an emulated GPU rendering technology called an off-screen render engine 105B. The off-screen render engine 105B can pre-allocate one or more image memories matching the viewport size and use one or more dedicated processors 62 of the workstation 60 to perform off-screen rendering of the image 1 (e.g., 1A-1H). This in-memory off-screen rendering can occur after image render engine 105 has finished rendering, but before visualization engine 107 displays it on the screen. This allows images 1 (e.g., 1A-1H) to be displayed more quickly than usual, and allows visualization engine 107 to draw images 1 (e.g., 1A-1H) to the screen more quickly. Because this processing requires one or more dedicated processors 62 reserved for this processing, and this additional step is only necessary when there are multiple high-resolution diagnostic monitors used with multiple large 1-up viewports, the diagnostic viewer can turn off off-screen render engine 105B based on the need and availability of the required hardware.

[0084] As well as scrolling and cine playback, there are several other Image Viewer 124 features (including Image Slider, Reference Lines, and Active Overlay) that have been overridden from the native implementation to provide users with a premium experience for reading Imaging Study 3 (e.g., 3A and 3B).

[0085] Image Slider: When there are more than 10 images 1 (e.g., 1A-1H) in a viewport, a slider bar is provided in each viewport 102. The slider bar helps the user with image navigation and can convey the relative position of the current image 1 (e.g., 1A-1H) in the image stack. Because web implementation of an image slider impacts scroll / playback performance, the diagnostic viewer has a native implementation of the image slider.

[0086] Reference Lines: Reference lines are lines displayed in the viewport to indicate the relative spatial position of image 1 (e.g. 1A-1H) displayed in the linked viewport with respect to image 1 (e.g. 1A-1H) displayed in the focused viewport. Displaying these lines in a web implementation would impact scrolling / playback performance, so the diagnostic viewer has a native implementation of the visualization of reference lines.

[0087] Active Overlay: Some fields in the text overlay are interactive, and users can click on the text overlay fields to perform various operations such as changing the window level, scaling, etc. Since the diagnostic viewer implementation of the text overlay is in the native layer, the active overlay is also implemented in the native layer.

[0088] For purposes of illustration and not limitation, and referring to FIG. 8 , the diagnostic viewer 100 may have various application windows for running applications (e.g., worklist 111, power jacket 112, image viewer 124, advanced report 113, user settings 114, series viewer (not shown), or other suitable applications). Managing and coordinating these different windows is key to establishing various reading workflows while ensuring that the information displayed in each window is accurate and without mismatches. Existing browser viewers launch each of these windows as separate browser windows and utilize the browser's local storage as a means to store active clinical content information and local storage events used to send messages between different windows. This invariably creates performance challenges, timing issues, and race conditions. The diagnostic viewer 100 maintains each of these windows as native window containers 103 in the same application process and can establish appropriate parent-child relationships between these windows, allowing them to communicate and exchange clinical information with each other without ambiguity.

[0089] The diagnostic viewer 100 can maintain a pool of pre-initialized windows, and based on the content launched by the user, the diagnostic viewer 100 can present the required window or window group. The diagnostic viewer 100 can establish relationships between windows (by registering communication interfaces between related windows). These relationships allow the relationships themselves to be used to synchronize context between window groups, eliminating the need for additional mechanisms, such as browser local storage, to synchronize various windows and prevent information discrepancies. For example, the diagnostic viewer 100 can have a window pool from which the diagnostic viewer 100 can select a viewer window to display the content of a newly opened Study 3 (e.g., 3A and 3B). A view window retrieved from the pool may have already been used in the past to display another Study 3 (e.g., 3A and 3B). When pushed back to the window pool, the window pool can reload the user interface so that none of the content from the previously displayed Study 3 (e.g., 3A and 3B) is shown in the view window, and the study content displayed in the view window is deleted. If there are no viewer windows in use in the window pool, the diagnostic viewer 100 may create a new window to display the contents of the newly opened study 3 (eg, 3A and 3B).

[0090] Having all application windows within the same native process allows for a high-performance, highly predictable, and accurate communication mechanism between multiple windows in the diagnostic viewer 100. The diagnostic viewer can ensure that clinical context is always accurately synchronized between application windows, thereby eliminating potential patient safety issues. In addition to synchronizing multiple application windows, the diagnostic viewer 100 also synchronizes third-party integrated clinical applications 202 and reporting applications 203. For example, measurements performed must also be synchronized between multiple application windows, but this is handled through native-layer communication between application windows displaying the same measurements. Synchronizing clinical information between multiple windows is simplified by the diagnostic viewer 100, eliminating the need for inter-process communication between application windows. Instead, each window can communicate directly with its child and parent windows, eliminating potential communication gaps, timing issues, and latency. This direct communication also ensures that the sending and receiving windows of a communication directly exchange information and acknowledgments without the need for additional communication for the communication's acknowledgment feature.

[0091] Communication between related application windows can occur using a designated interface registered with each window. For example, a native image viewer window 101 can have interfaces for a PowerJacket window 103 and an Advanced Report window 103 to communicate with the corresponding application (e.g., PowerJacket 112, Advanced Report 113, or other suitable application). An interface can be registered with each window as part of the established relationship between them. Because each window can have a native portion, which is the window container 103, and a web portion, which is the UI layer (e.g., PowerJacket 112, Advanced Report 113, or other suitable application), communication between windows can also occur based on which layer needs to communicate with which layer. For example, if the native container layer of one window needs to communicate with the native layer of another window, interface calls can occur within the native address space. If the web layer of one window needs to communicate with the web layer of another window, interface calls can occur in both the web address space and the native address space.

[0092] The diagnostic viewer 100 also allows radiologists and cardiologists to open multiple studies side by side as tabs and use the dictation system 204 to read and dictate multiple studies by switching between tabs. This increases the flexibility of interrupted workflows, eliminating the need for users to save a study 3 (e.g., 3A and 3B) while closing and reopening the study 3 (e.g., 3A and 3B), restoring it to its previous state, and continuing dictation using the dictation system 204. When a user switches from one study 3 (e.g., 3A and 3B) to another, the associated application window, e.g., Power Jacket, also switches to the new study 3 (e.g., 3A and 3B) by hiding the currently displayed associated application window and displaying a new associated application window corresponding to the new study 3 (e.g., 3A and 3B). The parent-child relationship of window management makes this transition easy and unambiguous. The integrated external dictation system application window 204 can also be updated by saving the previous study report as a draft and switching to the new study report. There is no technical limit to the number of studies that can be open at one time, and the Diagnostic Viewer's memory management system ensures that memory utilization remains within desirable limits while working with multiple studies. This includes storing the least frequently used study images (e.g., 1A-1H) on disk memory, while primary memory is utilized for images (e.g., 1A-1H) belonging to the active study (e.g., 3A and 3B). Each tab can have a patient banner that displays patient information, such as the patient name, gender, age, medical record number, or other appropriate patient information, and can uniquely identify the study (e.g., 3A and 3B). Each tab also has a close button to close a specific study (e.g., 3A and 3B).

[0093] Existing ZeroViewer implementations allow applications to run in a web browser, but existing ZeroViewer implementations require an additional intermediary application / framework if they need to communicate with third-party clinical / reporting applications 202, 203. This always poses performance, stability, and maintainability challenges. The Diagnostic Viewer 100 can eliminate the need for an additional intermediary and instead communicate directly with third-party clinical / reporting applications 202, 203, regardless of whether the applications require web or native integration. In addition to clinical / reporting applications 202, 203, some applications, such as an external RIS worklist 201, also communicate with the Diagnostic Viewer 100, regardless of whether such systems have web or native integration (e.g., the RIS worklist 201 launches DICOM studies 3 (e.g., 3A and 3B) in the Diagnostic Client by executing a pre-configured WebQuery URL).

[0094] If the DICOM images of Study 3 (e.g., 3A and 3B) need to be written to an external storage medium 67, such as a compact disc (CD), the current Zero Viewer must download all DICOM images 1 (e.g., 1A-1H) to the workstation before it can begin burning the content to the external storage medium, resulting in significant waiting time for the user. The diagnostic viewer 100 already has the DICOM content available at the workstation 60, so the system can write the content directly to the external storage medium 67, allowing the user to complete the operation more quickly.

[0095] The diagnostic viewer 100 can also exchange a displayed image 1 (e.g., 1A-1H) from the image viewer 124 to an external third-party application 200 (e.g., Microsoft PowerPoint) by utilizing the native drag-and-drop mechanism provided by the operating system.

[0096] In the current implementation of Zero Viewer, this is not possible due to the sandboxed browser environment. The Diagnostic Viewer 100 can also connect to and exchange information with at least one printer 68 attached to the workstation 60.

[0097] The diagnostic viewer 100 can provide an offline workflow. For example, an authorized user can download imaging studies 3 (e.g., 3A and 3B) and other necessary information to view offline. The downloaded information, other than the imaging studies 3 (e.g., 3A and 3B), can include JavaScript / HTML assets, user settings, reading protocols, etc. This downloaded content can be opened in the diagnostic viewer 100 in offline mode, eliminating the need for a network connection to the server. The diagnostic viewer 100 can also include anonymization of the downloaded imaging studies 3 (e.g., 3A and 3B), ensuring protection from PHI information and public traceability.

[0098] 9, for purposes of illustration and not limitation, the diagnostic viewer 100 can support multiple deployment methods that can be selected based on the user's needs. For example, manual installation by downloading a package from the server 30, and installation of the application by an administrator 400 from a remote location by pushing the application via a group policy software deployment mechanism 401. For example, software can be installed remotely by using group policy to distribute the program to users or computers, or by pushing the software to users (e.g., when they log in to the system), as is known in the art. Once deployed, the diagnostic viewer 100 can automatically detect updates by monitoring the server 30 and automatically upgrade with the user's approval.

[0099] The diagnostic viewer 100 can post health statistics to the server 30, including performance data (e.g., initial display performance, network speed, cache performance, decode performance, rendering performance), workstation resource utilization, and critical error reports sent to the server 30, available for monitoring from a central administration page 400. The administration page 400 can display a list of all connected workstations categorized based on physical location (e.g., on-premise vs. remote).

[0100] Each workstation 60 has an indicator that shows its health and connection status. Color coding can be used for the status indicators to show whether the workstation 60 is stable or requires troubleshooting. Authorized users can click on each workstation 60 to expand the display area where recent health statistics recorded by that workstation 60 are displayed.

[0101] An authorized user can use the administration page 400 to perform various operations as part of troubleshooting the workstation 60 without physically reaching for the workstation 60. For example, an administrator may work in a data center where the workstation 60 is located in another location (e.g., another room, building, city, state, or country). A user can upload detailed log files to the server 30 to analyze potential problems with the workstation 60. The log files may include various application logs, performance logs, operating system logs, or other suitable log files. To obtain more detailed log information, such as operation logs and TCP layer communication logs, an authorized user can turn on troubleshooting mode and upload the logs to the server 30.

[0102] FIG. 10 illustrates an exemplary method 1000 for rendering images on a device. The method may begin at step 1010, where the method may include launching an image viewing application. In step 1020, the method may include downloading, in the image viewing application, a plurality of unrendered image files stored in a server memory. In step 1030, the method may include rendering, in the image viewing application, the plurality of unrendered image files using one or more device processors to generate a plurality of rendered image files. In step 1040, the method may include displaying, in the image viewing application, the plurality of rendered image files in at least one image window. In step 1050, the method may include rendering, in the image viewing application, at least one server application in at least one native window container, the at least one server application stored in server memory and processed by one or more server processors. Although this disclosure describes and illustrates certain steps of the method of FIG. 10 as occurring in a particular order, this disclosure contemplates that any suitable steps of the method of FIG. 10 may occur in any suitable order. Additionally, although this disclosure describes and illustrates exemplary methods for rendering images on a device that include particular steps of the method of Figure 10, this disclosure contemplates any suitable method for rendering images on a device that includes any suitable steps, which may include all, some, or none of the steps of the method of Figure 10, as appropriate. Additionally, although this disclosure describes and illustrates particular components, devices, or systems that perform particular steps of the method of Figure 10, this disclosure contemplates any suitable combination of any suitable components, devices, or systems that perform any suitable steps of the method of Figure 10.

[0103] FIG. 11 illustrates an exemplary method 2000 for rendering images on a device. The method may begin at step 2010, where the method may include launching an image viewing application running on the device. In step 2020, the method may include downloading, in the image viewing application, a plurality of unrendered image files, where the plurality of unrendered image files are assigned priority values ​​based on when the plurality of image files are to be displayed. In step 2030, the method may include storing, in the image viewing application, the downloaded plurality of unrendered image files in at least one of a first device memory and a second device memory, where the plurality of unrendered image files are stored in at least one of the first device memory and the second device memory according to the assigned priority values. In step 2040, the method may include rendering, in the image viewing application, the plurality of unrendered image files based on the assigned priority values ​​using at least one device processor, where if a plurality of unrendered image files having a predetermined priority value need to be displayed before downloading is complete, the rendering occurs in at least one processor of a server electrically coupled to the image viewing application. In step 2050, the method may include displaying the plurality of rendered image files in an image viewing application based on the assigned priority values, and the second device memory transferring at least one of the plurality of unrendered image files to the first device memory based on the assigned priority values ​​and available storage space in the first device memory. In accordance with the disclosed subject matter, the method may repeat one or more steps of the method of Figure 11, if appropriate. Although this disclosure describes and illustrates certain steps of the method of Figure 11 as occurring in a particular order, this disclosure contemplates any suitable steps of the method of Figure 11 occurring in any suitable order.Additionally, although this disclosure describes and illustrates exemplary methods for rendering images on a device that include particular steps of the method of Figure 11, this disclosure contemplates any suitable method for rendering images on a device that includes any suitable steps, which may include all, some, or none of the steps of the method of Figure 11, as appropriate. Additionally, although this disclosure describes and illustrates particular components, devices, or systems that perform particular steps of the method of Figure 11, this disclosure contemplates any suitable combination of any suitable components, devices, or systems that perform any suitable steps of the method of Figure 11.

[0104] 12 shows an example method 3000 for rendering an image on a device. The method may begin at step 3010, where the method may include launching an image viewing application operating on the device. In step 3020, the method may include downloading at least one first unrendered image file in the image viewing application. In step 3030, the method may include storing the downloaded at least one first unrendered image file in at least one of a first device memory and a second device memory in the image viewing application. In step 3040, the method may include rendering, in the image viewing application, using at least one device processor, the at least one first unrendered image file into at least one first rendered image file. In step 3050, the method may include displaying, in the image viewing application, the at least one first rendered image file, wherein the display of the at least one rendered image file is controlled through movement of a pointing device, and the image viewing application receives input data from the device regarding the movement of the pointing device. In accordance with the disclosed subject matter, a method may repeat one or more steps of the method of Figure 12, if appropriate. Although this disclosure describes and illustrates certain steps of the method of Figure 12 as occurring in a particular order, this disclosure contemplates any suitable steps of the method of Figure 12 occurring in any suitable order. Furthermore, although this disclosure describes and illustrates an example method for rendering an image on a device that includes certain steps of the method of Figure 12, this disclosure contemplates any suitable method for rendering an image on a device that includes any suitable steps, which may include all, some, or none of the steps of the method of Figure 12, if appropriate.Additionally, although this disclosure describes and illustrates particular components, devices, or systems that perform particular steps of the method of FIG. 12, this disclosure contemplates any suitable combination of any suitable components, devices, or systems that perform any suitable steps of the method of FIG. 12.

[0105] FIG. 13 illustrates an exemplary method 4000 for rendering images on a device. The method may begin at step 4010, where the method may include launching an image viewing application running on the device. In step 4020, the method may include launching multiple windows in the image viewing application, the multiple windows configured to execute an image viewer window and at least one application window. In step 4030, the method may include establishing a configuration relationship between multiple windows on the device in the image viewing application, the multiple windows assigned a relationship configured to synchronize content between the multiple windows, the image viewer window including a first communication interface registered with the application window based on the configuration relationship, the first application window including a first window container operated by the device and a first web interface layer operated by a first server electrically coupled to the device, the image viewer window being operated by the device, and the first communication interface configured to operate within the device in communicating between the image viewer window and the window container. In accordance with the disclosed subject matter, the method may repeat one or more steps of the method of FIG. 13, if appropriate. Although this disclosure describes and illustrates certain steps of the method of Figure 13 as occurring in a particular order, this disclosure contemplates any suitable steps of the method of Figure 13 occurring in any suitable order. Additionally, although this disclosure describes and illustrates example methods for rendering images on a device that include certain steps of the method of Figure 13, this disclosure contemplates any suitable method for rendering images on a device that includes any suitable steps, which may include all, some, or none of the steps of the method of Figure 13, where appropriate.Additionally, although this disclosure describes and illustrates particular components, devices, or systems that perform particular steps of the method of FIG. 13, this disclosure contemplates any suitable combination of any suitable components, devices, or systems that perform any suitable steps of the method of FIG. 13.

[0106] 14 illustrates an exemplary method 5000 for rendering images on a device. The method may begin at step 5010, where the method may include launching an image viewing application running on the device. In step 5020, the method may include launching a first instance of the image viewing application including a plurality of windows, the plurality of windows configured to execute at least an image viewer window and an application window. In step 5030, the method may include establishing a relationship between a plurality of windows on the device in the image viewing application, the plurality of windows being assigned a relationship configured to synchronize content among the plurality of windows. In step 5040, the method may include launching a second instance of the image viewing application including a second plurality of windows, the second plurality of windows configured to execute at least a second image viewer window and a second application window. In step 5050, the method may include establishing, in an image viewing application, a second setting relationship between a second plurality of windows on the device, the second plurality of windows being assigned a relationship configured to synchronize content among the second plurality of windows, the image viewer window including a first communication interface registered with the application window based on the setting relationship, the second image viewer window including a second communication interface registered with the second application window based on the setting relationship, and switching from the first instance to the second instance hiding at least one application window and displaying at least one second window. In accordance with the disclosed subject matter, the method may repeat one or more steps of the method of FIG. 14 as appropriate. Although this disclosure describes and illustrates certain steps of the method of FIG. 14 as occurring in a particular order, this disclosure contemplates any suitable steps of the method of FIG. 14 occurring in any suitable order.Additionally, although this disclosure describes and illustrates exemplary methods for rendering images on a device that include particular steps of the method of Figure 14, this disclosure contemplates any suitable method for rendering images on a device that includes any suitable steps, which may include all, some, or none of the steps of the method of Figure 14, as appropriate. Additionally, although this disclosure describes and illustrates particular components, devices, or systems that perform particular steps of the method of Figure 14, this disclosure contemplates any suitable combination of any suitable components, devices, or systems that perform any suitable steps of the method of Figure 14.

[0107] The subject matter and operations described herein can be implemented in digital electronic circuitry, or in computer software, firmware, or hardware (including the structures disclosed herein and their structural equivalents), or in one or more combinations thereof. Embodiments of the subject matter described herein can be implemented as one or more computer programs, i.e., one or more modules of computer program instructions, encoded on a computer storage medium for execution by, or to control the operation of, a data processing apparatus.

[0108] A computer storage medium may be or be contained in a computer-readable storage device, a computer-readable storage substrate, a random-access or serial-access memory array or device, or a combination of one or more of these. Further, a computer storage medium is not a propagated signal, but a computer storage medium can be a source or destination of computer program instructions encoded in an artificially generated propagated signal. A computer storage medium may also be or be contained in one or more separate physical components or media (e.g., multiple CDs, disks, or other storage devices).

[0109] The term "processor" encompasses all types of apparatus, devices, and machines for processing data, including, by way of example, a programmable processor, a computer, a system-on-chip (chip or chips), or a combination thereof. An apparatus may include, for example, special-purpose logic circuitry such as an FPGA or an ASIC. In addition to hardware, an apparatus may also include code that establishes an execution environment for the computer program (e.g., code that constitutes processor firmware, a protocol stack, a database management system, an operating system, a cross-platform execution environment, a virtual machine, or one or more combinations thereof). The apparatus and execution environment may implement a variety of different computing model infrastructures, such as web services, distributed computing, or grid computing infrastructures.

[0110] A computer program (also known as a program, software, software application, script, or code) may be written in any form of programming language, including compiled or interpreted, declarative or procedural, and may be deployed in any form, such as a stand-alone program or as modules, components, subroutines, objects, or other units suitable for use in a computing environment. A computer program may, but need not, correspond to a file in a file system. A program may be stored as part of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program, or in multiple cooperating files (e.g., files storing one or more modules, subprograms, or portions of code). A computer program may be deployed to run on one computer, on multiple computers at a single site, or on multiple computers distributed across multiple sites and interconnected by a communications network.

[0111] The processes and logic flows described herein may be performed by one or more programmable processors executing one or more computer programs, which perform actions by operating on input data and generating output. The processes and logic flows may also be performed by, or devices may be implemented as, special purpose logic circuitry (e.g., FPGAs or ASICs).

[0112] Processors suitable for the execution of a computer program can include, by way of example and not limitation, both general-purpose and special-purpose microprocessors. Devices suitable for storing computer program instructions and data can include all forms of non-volatile memory, media, and memory devices, including, by way of example and not limitation, semiconductor memory devices (e.g., EPROM, EEPROM, and flash memory devices), magnetic disks (e.g., internal or removable disks), magneto-optical disks, and CD-ROM and DVD-ROM disks. The processor and memory can be supplemented by, or incorporated in, special-purpose logic circuitry.

[0113] Additionally, as described above in connection with particular embodiments, certain components may communicate with other certain components, for example, via a network (e.g., a local area network or the Internet). Unless expressly stated above, the disclosed subject matter is intended to encompass each transaction, including both sending and receiving. Those skilled in the art will readily understand that, with respect to the features described above, if one component transmits, sends, or otherwise makes available to another component, the other component will receive or acquire it, whether or not expressly stated.

[0114] In addition to the specific embodiments claimed below, the disclosed subject matter also relates to other embodiments having the dependent features claimed below and any other possible combinations of the above-disclosed features. As such, the specific features set forth in the dependent claims and disclosed above can be combined with each other in other possible combinations. Accordingly, the foregoing description of specific embodiments of the disclosed subject matter has been presented for purposes of illustration and description and is not intended to be exhaustive or to limit the disclosed subject matter to the disclosed embodiments.

[0115] It will be apparent to those skilled in the art that various modifications and variations can be made to the method and system of the disclosed subject matter without departing from the spirit or scope of the disclosed subject matter. Thus, it is intended that the disclosed subject matter include modifications and variations that come within the scope of the appended claims and their equivalents.

Claims

1. 1. A method for rendering an image on a device, comprising: Launching an image viewing application; downloading, in the image viewing application, a plurality of unrendered image files stored in a server memory; rendering the plurality of unrendered image files using one or more device processors in the image viewing application to generate a plurality of rendered image files; displaying the plurality of rendered image files in at least one image window in the image viewing application; and Rendering at least one server application in at least one native window container in the image viewing application, the at least one server application stored in the server memory and processed by one or more server processors. A method comprising:

2. The method of claim 1 , further comprising storing the plurality of unrendered image files in a device memory.

3. The method of claim 2 , wherein the device memory is at least one of an in-memory cache and a disk cache.

4. The method of claim 1 , further comprising decompressing the plurality of unrendered image files before rendering.

5. The method of claim 1 , further comprising: in the image viewing application, using the server processor to render the plurality of unrendered image files until downloading of the plurality of unrendered image files is complete.

6. The method of claim 1 , wherein during the step of launching the image viewing application, the at least one native window container is initialized during application launch.

7. The method of claim 6 , wherein, after a native window is initialized, upon login by a user, the at least one server application is rendered in the at least one native window container.

8. 10. The method of claim 1, further comprising: rendering at least one second server application in a second native window container in the image viewing application, the at least one second server application stored in a second server memory and processed on one or more second server processors.

9. The method of claim 1 , wherein the at least one server application comprises a web page.

10. The method of claim 1 , wherein the plurality of unrendered image files comprises DICOM images.

11. The method of claim 1 , wherein the plurality of rendered image files comprises a multi-frame image.

12. 1. A system for rendering an image on a device, comprising: a server having one or more server processors and a server memory coupled to said server processors containing instructions executable by said server processors; 1. A device having one or more device processors and a device memory coupled to the device processors, the device memory including instructions executable by the device processors, the device processor comprising: Start the image viewing application. downloading, in the image viewing application, a plurality of unrendered image files stored in the server memory; rendering the plurality of unrendered image files using the device processor in the image viewing application to generate a plurality of rendered image files; displaying the plurality of rendered image files in at least one image window in the image viewing application; and The image viewing application renders at least one server application in at least one native window container, the at least one server application being stored in the server memory and processed by one or more server processors. a device operable to execute instructions for Including, the system.

13. The system of claim 12 , further comprising the instructions for saving the plurality of unrendered image files to the device memory.

14. The system of claim 13 , wherein the device memory is at least one of an in-memory cache and a disk cache.

15. The system of claim 12 , further comprising the instructions for decompressing the plurality of unrendered image files before rendering.

16. 13. The system of claim 12, further comprising instructions in the image viewing application for using the server processor to render the plurality of unrendered image files until downloading of the plurality of unrendered image files is complete.

17. The system of claim 12 , wherein during the command to launch the image viewing application, the at least one native window container is initialized during application launch.

18. 20. The system of claim 17, wherein after a native window is initialized, upon login by a user, the at least one server application is rendered in the at least one native window container.

19. 13. The system of claim 12, further comprising instructions in the image viewing application for rendering at least one second server application in a second native window container, the at least one second server application stored in a second server memory and processed by one or more second server processors.

Images