Realtime Medical Imaging System

Problem

A TÜBİTAK-funded medical technology company needed a cross-platform, realtime medical imaging application targeting NVIDIA Jetson hardware. A legacy codebase existed, but it wasn’t a foundation the product could grow on — the decision was made to rebuild from scratch. The constraints that shaped everything: embedded ARM hardware with limited compute, realtime visualization requirements, and a small team where most of the codebase would rest on one developer.

Approach

I built the application core in C++ with Qt (Core, GUI, Concurrent) and VTK for 3D visualization, with OpenCV handling image processing steps. Of a codebase that grew past 45k lines, the overwhelming majority was mine — detection and computation algorithms on the OpenCV side came from elsewhere, but the architecture, the Qt application layer, the VTK rendering integration, and the threading model were my responsibility.

Two problems dominated the engineering work. First, multithreaded code that ran correctly on x86 produced races and crashes on ARM — the porting effort meant hunting down synchronization assumptions that x86’s stronger memory behavior had silently forgiven, and redesigning the offending threading patterns until the system was stable on Jetson. Second, render time: VTK’s default pipeline was too heavy for the hardware, so I cut frame cost through render pipeline optimization, level-of-detail control, and volume resolution tuning, while keeping the OpenCV processing load light enough to coexist with rendering on the same constrained device.

Architecture

This project meets the Architecture Diagram Requirement on internal layering alone, but the system was built as closed-source client work for MEDPOINTR, so its architectural detail is withheld here deliberately rather than replaced with a diagram vague enough to say nothing.

Tradeoffs

Rendering fidelity was deliberately traded against responsiveness — volume resolution and LOD settings were tuned to what the hardware could sustain in realtime rather than what looked best in isolation. VTK expertise was scarce (few developers in Turkey work with it), which meant the project depended heavily on knowledge I had built up on the job — a risk for the company, and one of the reasons the codebase stayed under one person’s ownership rather than being distributed.

Outcome

The application shipped during my full-time tenure (2023–2024). When the funded period ended, the engagement closed with it — but the product’s story didn’t. The company later repositioned the system toward a training-and-evaluation use case, and I was brought back on freelance terms — twice through 2025 — to lead that adaptation: measurement and scoring of user precision and depth accuracy, structured data entry for trainees, workflow and calibration changes fitting the new setting, and a results screen with PDF report generation. Being the person recalled to evolve the system into a second product life is the outcome I value most from this work.