Skip to content

Image Processing Architecture

  • Date: 2026-03-18
  • Status: Draft
  • Author: Architecture Team

Overview

This document describes the proposed architecture for a flexible, configuration-driven image processing pipeline for whole-slide images. The design enables support for multiple input formats, processing libraries, output formats, and storage destinations.

Current State

The current implementation in VipsSlideConverter.cs provides DeepZoom conversion using NetVips with a monolithic approach:

SlideUploadedEvent -> SlideCreatedEventHandler -> VipsSlideConverter.ConvertToDeepZoomAsync()

The current method handles:

  1. Downloading the source file.
  2. Detecting format and loading the image.
  3. Generating DeepZoom tiles.
  4. Uploading the results to storage.

Requirements

Functional Requirements

Requirement Description
Input Formats SVS, NDPI, MRXS, VSI, CZI, SCN, BIF, TIFF, generic images
Output Formats DeepZoom, DICOM, custom tile layouts
Tile Formats JPEG, PNG, WebP, AVIF, TIFF
Storage Targets Local filesystem, AWS S3, and future cloud stores
Processing Libraries NetVips, OpenSlideNET, custom implementations
Configuration Appsettings-driven today with room for a control plane later

Non-Functional Requirements

  • Extensibility
  • Testability
  • Observability
  • Resilience
  • Performance

Library Comparison

NetVips vs OpenSlide

Task Tool Notes
Open proprietary WSI formats OpenSlide Rich vendor-specific handling
Read metadata OpenSlide Better metadata coverage
Extract regions by level OpenSlide Multi-resolution access
Resize and convert tiles NetVips High-performance image operations
Stain normalization and color ops NetVips Better transformation pipeline support
Generate DeepZoom output Both NetVips has dzsave; OpenSlide can support region extraction

Recommendation

Use a hybrid approach:

  • OpenSlide for reading proprietary formats and metadata.
  • NetVips for transformations, tiling, and output generation.
  • An abstraction layer so implementations can be swapped by capability.

Proposed Architecture

Replace the monolithic converter with a command/handler pipeline where each stage is discrete and composable.

Pipeline Orchestrator
  -> Download
  -> Load Image
  -> Transform Image
  -> Generate Output
  -> Upload Output

This supports single responsibility, composability, configurability, testability, and better step-level telemetry.

Core Abstractions

The draft proposes:

  • An ImageProcessingContext flowing through the pipeline.
  • Command and command-handler abstractions for each step.
  • A loader abstraction for slide-image implementations.

The original source doc contains the full example interfaces and class sketches from the architecture team draft and should remain the reference for implementation detail.