Deep-learning MRI reconstruction: sharper images from 4× faster scans
A research-use system that reconstructs and denoises MRI series with neural networks — recovering image quality from undersampled and low-SNR acquisitions — deployed as a DICOM node between the scanner and PACS, with automatic quality gates so that no unreliable image reaches a reader.
- Duration
- 8 months, research use
- Published
- 26 August 2026
- Stack
- PythonPyTorchMONAIpydicomOrthancPostgreSQLFastAPINVIDIA GPUDocker
0.93
SSIM at 4× acceleration, from 0.71
−70%
scan time on the accelerated protocol
6 s
per series on one GPU
100%
of output series pass or fail an explicit QA gate
What was the starting point?
The starting point was a physical trade-off: MRI exchanges scan time for signal-to-noise ratio and resolution, so a sharper image needs a longer acquisition, and a longer acquisition means more motion, less throughput and a patient who cannot hold still. Deep-learning reconstruction breaks that trade-off by learning what noise and undersampling artefacts look like. The field has moved fast since the fastMRI dataset and benchmark were released by NYU and Meta researchers in 2018, and every scanner vendor now ships some form of it — but vendor tools are tied to vendor hardware.
A research group with scanners from different vendors needed a vendor-neutral tool for their own studies: something that could take undersampled and low-SNR series, reconstruct them, and hand back DICOM series that fit into their existing workflow — clearly labelled as research use.
What problem had to be solved?
The problem was to improve image quality without ever inventing anatomy. Three constraints that generic “image enhancement” does not have: MRI data is not a photo, so the model has to respect the physics of k-space and preserve subtle pathology instead of smoothing it away; a generative model that hallucinates plausible tissue is worse than a noisy image, so every output needs a measurable quality gate; and the tool had to integrate with the clinical pipeline (DICOM, PACS, de-identification) without being mistaken for a cleared diagnostic device. WHO’s guidance on AI for health (2021) makes the same point in policy terms: safety, transparency and human oversight are conditions, not features.
Input and output, side by side
A zero-filled reconstruction of a 4× undersampled T2 FLAIR series next to the deep-learning reconstruction, with the quality gates the series passed before it was written back to PACS.
How was it built?
It was built as a DICOM node between the scanner and PACS: series arrive by C-STORE, are de-identified, reconstructed on a GPU by physics-informed networks, scored by explicit quality gates and written back as a new, research-labelled series. The models and the gates were developed with the life-cycle discipline of IEC 62304 in mind — versioned weights, traceable requirements, a per-study audit trail — even though the system is not a medical device.
- Models. A U-Net for image-domain denoising and an unrolled, physics-informed network with data-consistency layers for undersampled k-space reconstruction; a super-resolution head for thin-slice synthesis. Trained on retrospectively undersampled fully-sampled data (fastMRI-style) plus the group’s own multi-vendor data, with a held-out test set per scanner.
- Quality gates. Every output series is scored against its reference where one exists (SSIM, PSNR, NMSE) and against learned no-reference metrics where it does not — including a hallucination score from an ensemble-disagreement estimate and a motion index. A series that fails any gate is written back with a rejection tag, never silently.
- DICOM integration. An Orthanc-based node returns a new series with a distinct SeriesDescription suffix and research-use-only labelling, so the original is never overwritten and the two cannot be confused in PACS.
- Research tooling. Worklist, model registry with versioned weights, per-study audit trail, and export of paired series for reader studies.
Vendor reconstruction vs a vendor-neutral research node: which fits a multi-vendor group?
The table compares the reconstruction built into scanner software with the vendor-neutral node built here. Vendor tools are cleared for clinical use and need no integration, but each covers one vendor and its internals are closed. The research node works across vendors and exposes every metric, at the cost of staying outside clinical reporting until it is certified.
| Criterion | Vendor reconstruction | Vendor-neutral node (this project) |
|---|---|---|
| Regulatory status | Cleared / CE-marked | Research use only |
| Scanner coverage | One vendor | Any vendor via DICOM |
| Model transparency | Closed | Versioned weights, open metrics |
| Quality gates | Internal, not exposed | Explicit SSIM/PSNR/hallucination gates per series |
| Custom protocols and studies | Limited | Retrainable on the group’s data |
| Path to certification | Already done by vendor | MDR / 510(k) as an extension |
Results
On the 312-series multi-vendor test set, at 4× acceleration the deep-learning reconstruction recovers most of the image quality lost to undersampling — measured against the fully-sampled reference — and lets the group run brain protocols in a fraction of the time for its studies.
Mean over 312 series; PSNR 26.4 → 31.0 → 35.4 dB on the same set.
Data table
| SSIM | |
|---|---|
| Zero-filled | 0.71 |
| Compressed sensing | 0.83 |
| DL reconstruction | 0.93 |
Data table
| Minutes | |
|---|---|
| Standard protocol | 32 min |
| 2× accelerated + DL | 17 min |
| 4× accelerated + DL | 9 min |
A DICOM node between the scanner and PACS
The deployment pattern that makes a vendor-neutral tool possible: the node sits on the network like any other DICOM device, and its outputs are additional series, never replacements.
Is it a medical device?
No — the system is research-use software, not a medical device: outputs are labelled “for research use only — not for diagnostic use”, kept out of clinical reporting, and used under the group’s ethics approvals with de-identified data. Software intended for diagnosis falls under the EU Medical Device Regulation (2017/745), and AI in such devices is also treated as high-risk under the EU AI Act (2024/1689); in the US, the FDA’s public list of AI-enabled devices passed a thousand entries in 2025, most of them in radiology. The architecture — versioned models, audit trail, explicit QA gates, IEC 62304-style documentation — was designed so that a future path to CE marking under MDR or an FDA 510(k) would be an extension, not a rewrite.
Stack
The stack is PyTorch and MONAI for the models; pydicom and Orthanc for the DICOM layer; FastAPI inference services on NVIDIA GPUs; PostgreSQL for studies, model versions and the audit trail; and Docker deployment inside the institution’s own network. Nothing leaves the perimeter: de-identification happens on the node before inference, and the original series is never modified — the reconstruction is always written back as a new series.
Who is this approach for?
This approach is for teams building computer vision in a regulated or high-stakes setting: medical imaging research groups, industrial inspection, satellite imagery — any pipeline where a plausible-looking wrong answer is the real risk. It is a different discipline from a demo notebook: physics-aware models, measurable quality gates, integration with the standards the domain already uses, and documentation from day one, so that certification later is a matter of evidence rather than rework.
Frequently asked questions
Services behind this case
Services
AI & Machine Learning
AI agents, LLM pipelines with retrieval, forecasting, computer vision and document AI — built into your product and measured by before/after numbers.
AI & Machine Learning
Free Open-Source AI Chatbot for Business Automation
Discover Glanit's open-source AI chatbot solution. Automate customer support 24/7 using Grok, Gemini, and ChatGPT. A self-hosted, free alternative to expensive SaaS tools—pay only for API usage.
AI & Machine Learning
How AI agents work: architecture of a production agent
An AI agent is not a chatbot with a longer prompt. It is a system: a model for reasoning wrapped in perception, memory, tools, orchestration and monitoring. We build agents for clients and for our own products — this is the architecture behind them.
More case studies
Erudil: an AI engine that prices every match outcome
Our own product. A probability engine turns match data into outcome probability matrices, compares them with bookmaker odds, and publishes a tamper-proof track record of every pick — wins and losses alike.
- Sports analytics
- Python
- PyTorch
- PostgreSQL
AI knowledge assistants for a 30 000-employee grocery chain
Three RAG assistants on one platform — for commercial staff, store directors (by voice, from the shop floor) and HR — answer questions from corporate regulations with a citation to the exact clause, or say honestly that they do not know — so staff stop phoning head office for routine questions.
- Retail
- Python
- LangChain
- PostgreSQL + pgvector
Document AI that reads 1 300 supplier invoices a day
Scans and photos of invoices, delivery notes and acts go through a multimodal model that extracts typed fields with a confidence score per field, reconciles them with the supplier and contract master data, and posts to the ERP. Only low-confidence documents reach a human — roughly one in nine.
- Retail · Finance
- Python
- PyTorch
- Multimodal LLM