Iris RESTful Server and IrisTileSource: An Iris implementation for existing OpenSeaDragon viewers

TL;DR

The paper presents the Iris RESTful Server, a lightweight C++ HTTP service with a RESTful API compatible with the DICOMweb WADO-RS standard, designed to stream subregions of high-resolution Iris File Extension (IFE) slides. It pairs the server with a new OSD IrisTileSource that integrates with OpenSeaDragon to replace the traditional DZI-based rendering, enabling drop-in tile requests from viewers with only minimal viewer-side changes (four lines of code). Performance evaluations on edge hardware and cloud deployments demonstrate high throughput (thousands of requests per second) and low latency (tens of milliseconds), outperforming several reference viewers in typical digital pathology tasks. The work includes deployment guidance, containerized deployment options, and an openly accessible example domain, highlighting practical impact for scalable, secure, and maintainable WSI web viewing across varied healthcare settings.

Abstract

The Iris File Extension (IFE) is a low overhead performance-oriented whole slide image (WSI) file format designed to improve the image rendering experience for pathologists and simplify image management for system administrators. However, static hypertext transfer protocol (HTTP) file servers cannot natively stream subregions of high-resolution image files, such as the IFE. The majority of contemporary WSI viewer systems are designed as browser-based web applications and leverage OpenSeaDragon as the tile-based rendering framework. These systems convert WSI files to Deep Zoom Images (DZI) for compatibility with simple static HTTP file servers. To address this limitation, we have developed the Iris RESTful Server, a low-overhead HTTP server with a RESTful API that is natively compatible with the DICOMweb WADO-RS API. Written in C++ with Boost Beast HTTP and Asio networking libraries atop the public IFE libraries, the server offers both security and high performance. Testing shows that a single Raspberry Pi equivalent system can handle a peak of 5,061 req/s (average 3,883 req/s) with a median latency of 21 ms on a private (i.e. hospital) network. We also developed and merged a new OpenSeaDragon TileSource, compatible with the Iris RESTful API, into the next OpenSeaDragon release, enabling simple and immediate drop-in replacement of DZI images within WSI viewer stacks. Designed as a secure cross-origin resource sharing microservice, this architecture includes detailed deployment instructions for new or existing WSI workflows, and the public examples.restful.irisdigitalpathology.org subdomain is provided as a development tool to accelerate WSI web viewer development. All relevant Iris software is available under the open-source MIT software license.

Figures (4)

• Figure 1: Current digital pathology workflow. Digital slides are stored within a system curated by an such as a . The often provides both file curation with image retrieval and an application by issuing -based viewer source code to a browser on the pathologist client machine. The application requests regions of digital slide based on the current view port magnification and location on the slide. viewer applications historically use for native static file server compatibility and are stored as nested directories of individual image files, each encoding a single tile.
• Figure 2: Iris RESTful server architecture. Isolated stacks execute the server requests on multiple independent threads in ordering. Asio Networking reactor threads are solely responsible for accepting packet requests and writing responses. The task of interpreting requests is forwarded to a separate Iris lockless file system stack and executed on a configurable number of separate independent threads. This reduces the pressure on the networking stack, limiting the network threads' scope to the execution of networking kernel calls in order to speed the draining of the network buffer and ensure high-reliability. File system kernel calls are isolated to the Iris stack, where slides are mapped into virtual memory space and shared between socket sessions accessing the same slide resources.
• Figure 3: Iris RESTful within digital pathology workflows. (left) Our suggested architecture separates the and application from a scalable RESTful instance on a container orchestrator like Kubernetes (or AWS Elastic Container Service / Google Run). In this design, Iris RESTful is a domain solely responsible for issuing slide tiles from the . (right) In a different implementation, Iris RESTful is hosted on a server without container orchestration (but may be in or outside of a Docker container) with static server capabilities enabled -- allowing it to issue the based application directly. These are two opposite example architectures; however, there are many other viable workflow designs.
• Figure 4: Ramped Locust server load testing performance. An ideal server shows low response time (boxes) while handling a high tile request rate (line trace). (top) Ramped load testing for a single Iris RESTful deployment on a local private network without container orchestration with 220 virtual users ramped at a rate of 1.8 usr/sec. The half-box plots show median / 50%-ile (bottom black line) to 75%-ile (top) and 95%-ile (whiskers) server response latency. The line trace shows total tile requests per second. (bottom) Comparisons of ramped load testing on publicly available servers with 160 virtual users ramped at a rate a 1 user per second showing both tile response times (box-plots) and tile requests per second (line-trace) for Iris RESTful example server (green), Path-Presenter (blue), and Slim viewer (red). A log scale was used for tile response times in the bottom pane to aid in visualization due to substantially prolonged (web) response times.