GSOC 2026 Project #40: QC-Studio-integrated quality control toolkit for MRI datasets

GSoC
1

Mentors: Nikhil Bhagwat nikhil.bhagwat@mcgill.ca, Erin Dickie erin.dickie@camh.ca,

Brent McPherson bcmcpher@gmail.com, Sebastian Urchs sebastian.urchs@gmail.com,

Michelle Wang michelle.wang6@mail.mcgill.ca

About:

MRI quality control (QC) is a time intensive process often requiring visual inspection. The

QC-Studio project is part of a larger Nipoppy neuroinformatics framework for standardized

organization and processing of neuroimaging-clinical datasets. QC-Studio specifically aims to

simplify the QC tasks within neuroimaging data processing by providing an integrated web

interface to allow quick visual checks of multiple raw and processed MR images. QC-Studio

relies on NiiVue and Nipoppy frameworks to build a semi-automated workflow that can support

visual QC of outputs from several NiPreps pipelines.

Aims:

  • Core:

    • Build NiiVue+Streamlit based Python app to visualize raw and processed MR
    • images
    • Support multiple data formats (eg. nifti, mgz, gii, svg, png)
    • Support multiple pipeline outputs (e.g. volumes, surfaces, networks)

  • Enhancements:

    • Support interactive dashboards of quality metrics
    • Explore LLM utility towards image quality annotations and generating explanations to the users.

Expected Deliverables (MVP):

  • Code modules:

    • Data loaders for the following datatypes
      • MRI, SVGs, TSVs (IQMs)
    • UI manager
      • Data Panels
        • Niivue streamlit panel, SVG panel, IQM panel
      • Optimizations
        • User experience, Scaling to large datasets

  • LLM exploration report:

    • Write a brief summary on the utility of LLM tools towards generating image

quality annotations and reporting insights and explanations to the users.

What to Expect: We view GSoC contributors as members of our development team. You can

expect:

  • Close Supervision: Regular check-ins and guidance from mentors.
  • Team Integration: Attendance at our weekly development meetings to discuss theproject and progress.
  • Collaboration: A supportive environment where you work alongside the core maintainers.

Next Steps:

  • Explore our Code: Visit the qc-studio repo for the design overview
  • Reach out to us via email (nikhil.bhagwat@mcgill.ca) or opening an issue on the repo.

Skill level: Intermediate to Advanced

Required skills: Python, Streamlit, NiiVue, NiPreps

Helpful skills: Familiarity with MRI image data standards (BIDS) and processing pipelines (e.g.

fMRIPrep, QSIPrep, MRIQC), Some experience with LLMs, SKILLS.md, agentic workflows.

Time commitment: Full time (350 hours)

Tech keywords: Python, BIDS, Streamlit, NiiVue, Nipoppy, QC

3 Likes
2

Hi mentors!!!

I’m Favour Achara, a final-year Computer Science student and I am very excited about Project #40: QC-Studio. Nice to meet you all!!!

I have a solid background in building AI tools for medical imaging. Recently, I developed a 3D Brain Tumor Segmentation API that handles the end-to-end pipeline of converting raw DICOM/NIfTI series into 3D GLB meshes for web visualization.

My experience aligns closely with several core aims of this project: I have deep experience with Nibabel and SimpleITK for handling NIfTI volumes. I’ve worked with marching_cubes and trimesh to generate decimated 3D meshes for browser performance. I believe will translate well to working with NiiVue. While my recent project used FastAPI, I am very comfortable with Python-based web frameworks and am eager to apply this to the Streamlit requirements. I am particularly interested in the enhancement goal of exploring LLM utility for image quality annotations and explanations.

I’ve already begun exploring the qc-studio repository design. Are there any specific good first issues/newcomer issues or a particular area of the NiiVue+Streamlit integration you’d recommend I look into first to better prepare my proposal?

Looking forward to contributing!

5

Hi everyone,
I came across this project yesterday and it immediately jumped out at me because the tech stack (Python + Streamlit) lines up almost exactly with what I work in. I’m a 2nd year student in IT Engineering, with experience in Python, Streamlit, deep learning, and LLM-based pipelines. I spent the day reading through the MRIQC docs, looking at the IQM taxonomy (CJV, CNR, FBER, EFC, SNR for T1w; GSR, FD, DVARS for BOLD; CC_SNR, NDC for DWI), and understanding how Nipoppy organizes pipeline outputs, so I wanted to share where my head is at.

**On the core app:**
The three-panel layout (NiiVue for raw image → SVG panel for fMRIPrep/MRIQC report thumbnails → IQM TSV dashboard) makes sense to me as the MVP. For the NiiVue integration in Streamlit, since ipyniivue is built on anywidget, I’m thinking we can wrap it as a Streamlit custom component, it’d give us the full NiiVue API (multi-volume, overlay support, crosshair sync) without reimplementing the renderer. Happy to prototype this early if it would help validate the approach.

For the IQM panel, beyond just displaying the TSV values, I think there’s real value in showing each metric’s position relative to the MRIQC normative distribution (the ABIDE/OpenNeuro reference dataset has thousands of scans). A percentile-rank visualization per IQM gives curators immediate context, instead of reading that CJV=0.82 and not knowing if that’s bad, they see it’s at the 96th percentile and know to look closely at that scan.

**On the LLM component :- this is the piece I’m most interested in:**
The way I see it, asking an LLM to look at raw MRI images is a dead end for QC, the signal is in the IQMs, not the pixels. My proposed approach:

  1. For each scan, compute percentile ranks for all IQMs against the normative distribution
  2. Identify which metrics are outliers (e.g., CJV > 90th percentile, FD > 95th percentile)
  3. Feed that structured summary (not raw images to) the LLM: *“T1w scan, CJV at 96th percentile, SNR within normal range, EFC slightly elevated”*
  4. The LLM generates a natural language annotation: *“High CJV suggests reduced gray-white matter contrast, potentially from motion or field inhomogeneity. Recommend visual inspection of the cortical boundary.”*

This approach keeps the LLM grounded in quantitative data (less hallucination risk), produces annotations that match how radiologists actually talk about these artifacts, and the percentile computation alone doubles as a smart triage layer, worst scans surface first, which directly addresses the “time-intensive manual inspection” problem even without the LLM step.

I’m also curious whether the LLM component is envisioned as a research exploration (comparing different models/prompting strategies, evaluating annotation quality against expert ratings) or as a production feature integrated into the curator’s workflow. That distinction affects how I’d structure the report and what evaluation metrics make sense, I’d want to make sure I’m building toward what you actually need.

One quick question: for datasets with hundreds of subjects running through fMRIPrep/QSIPrep, the SVG report files can be large and numerous. Is there a preferred lazy-loading or caching strategy within the Nipoppy ecosystem (e.g., pre-indexing the derivatives directory), or is that part of what QC-Studio should figure out?

Really excited about this one,
looking forward to hearing more,

  • Yogin Langalia
6

hi!! I’m Laura, 3rd year medicine student at the University of Barcelona

I found this project through the GSoC org list and it immediately caught my attention — MRI QC is something I’ve encountered from the clinical side and I’ve always found the disconnect between what the metrics say and what actually makes a scan usable kind of frustrating. tools that make that more transparent seem genuinely useful.

I’ve been building a Streamlit data visualization tool recently (for proteomics, as part of another GSoC application) so the stack here feels familiar. I’ve started going through the Nipoppy docs and the QC-Studio repo to get oriented.

couple of questions before I go deeper — is the NiiVue integration meant to go through ipyniivue or a custom Streamlit component? and is referencing normative IQM distributions (like from ABIDE or OpenNeuro) in scope for the MVP or more of a stretch goal?

thanks, Laura

7

Title: Seeking feedback on AI-assisted MRI Quality Control prototype for QC-Studio

Hi everyone,

I’m currently working on a prototype to enhance MRI quality control workflows, inspired by tools like MRIQC and QC-Studio. The goal is to reduce manual QC effort and improve interpretability for users.

So far, I’ve implemented a few preliminary components:

  • MRI data loading and slice visualization using NiBabel

  • Basic preprocessing pipeline (normalization + resizing)

  • A small-scale baseline experiment using ResNet18 for binary quality classification (Good vs Poor)

  • A simple rule-based QC scoring prototype using intensity and noise statistics

I’m planning to extend this into:

  • A more robust learned QC scoring model

  • Artifact detection (motion, noise, intensity issues)

  • An explanation layer that converts QC metrics into human-readable insights

I’d really appreciate feedback from the community on a few points:

  1. Are there recommended datasets (beyond OpenNeuro/MRIQC) specifically suited for QC or artifact detection tasks?

  2. What are the most reliable indicators of MRI quality in practice (e.g., SNR, motion metrics, others)?

  3. Are there common pitfalls when training models for QC that I should watch out for early?

  4. For integration with existing workflows, what features would make such a tool actually useful to researchers?

If any mentors or contributors involved with MRIQC/QC-Studio are available, I would especially value your feedback on whether this direction aligns with real-world usage.

I’m sharing this early to validate direction before scaling further.

Thanks in advance for your insights!

8

Hi mentors,

I’ve been exploring QC-Studio and the Nipoppy framework over the past few days, and I tried building a small prototype using Streamlit to understand the workflow better.

In my prototype, I was able to load and visualize NIfTI images, display basic metadata, and create a simple IQM TSV panel. I also experimented a bit with generating basic explanations from IQM values to explore the LLM direction mentioned in the project.

This helped me get a better sense of how MRIQC outputs and other pipeline results might be used during QC.

I’m particularly interested in the data loaders and data panels, especially when handling outputs from multiple pipelines like MRIQC or fMRIPrep. I wanted to ask — is there a preferred way QC-Studio plans to structure or standardize these different outputs (for example, a unified loader vs separate modules)?

I’d love to align what I’m building with the project goals.

Here’s my prototype in case it’s useful to take a look:

Thanks!

9

Hello mentors,

My name is Vikas K, and I am a final-year Computer Science student with a strong focus on Python development and building practical systems.

I have been exploring the QC-Studio project and its role within the Nipoppy ecosystem, particularly how it aims to simplify MRI QC workflows that are currently fragmented and require significant manual inspection.

To better understand the expected architecture and workflow, I built a small prototype that focuses on:

  • MRI visualization with support for .nii files

  • Interactive slice-based exploration using Streamlit

  • A basic QC pipeline combining metrics (TSV) with a simple decision layer (PASS/FAIL)

  • Metadata inspection (shape, intensity range)

:link: GitHub: https://github.com/vikask011/QC-Studio-demo

While building this, I tried to structure the system in a modular way (data loaders → visualization → QC evaluation), which seems aligned with the MVP goals such as data panels and UI management.

Regarding the LLM component, my understanding is that it can be used to translate quantitative QC metrics into human-readable explanations, helping users interpret scan quality more intuitively. I am currently thinking of starting with a rule-based explanation layer and then exploring lightweight LLM-based summarization.

I had a few questions I would appreciate guidance on:

  • How QC-Studio is expected to integrate with Nipoppy outputs (e.g., MRIQC / fMRIPrep pipelines)

  • The intended role of NiiVue for handling multi-format visualization (surfaces, volumes, etc.)

  • How IQM metrics are structured and extended into interactive dashboards

I would appreciate any feedback on whether this direction makes sense, and I am looking forward to learning more about the project.

Thank you!

10

Hi mentors,

My name is Patapee Siribenjaponsakun, a third year Biomedical Engineering student at Rangsit University, Thailand. I have been exploring QC Studio and Nipoppy over the past week, and I wanted to share what I have learned and ask a few clarifying questions.

Why I am interested in this project:

I built a brain tumor segmentation pipeline (BraTS 2020 with MONAI/PyTorch) and learned firsthand how poor input image quality directly breaks downstream model accuracy. That experience gave me a strong appreciation for why upstream QC matters. I recently submitted a paper on medical imaging workflows to the MTAP Special Issue on AI Driven Immersive Multimedia (Springer), which further deepened my understanding of how quality control integrates into clinical pipelines. Additionally, I have hands on experience building LLM systems for healthcare applications in the mental health domain, and while I have not worked with Vision Language Models before, I am eager to learn and apply those skills to medical imaging contexts.

What I have prototyped:

To better understand the workflow, I built a small Streamlit prototype that:
• Loads and visualizes NIfTI images with metadata display
• Creates a basic IQM TSV panel
• Experiments with LLM based metric explanations (exploring the LLM component)
• Implements simple modular loaders (NIfTI, TSV)

This helped me understand how MRIQC outputs and pipeline results fit into a QC workflow, and I am particularly interested in data loaders and panels.

My questions:

  1. On the LLM component: is this envisioned as a standalone research report with findings, or as a prototype integrated into the UI itself? This helps me scope the timeline appropriately.

  2. On multi pipeline integration: when handling outputs from MRIQC, fMRIPrep, etc., is there a preferred way to standardize loader interfaces? Should each pipeline have a separate loader, or a unified approach?

  3. On NiiVue integration: what data formats and outputs beyond NIfTI are highest priority (surfaces, networks, SVGs)?

I am ready to build the MVP thoroughly and would love alignment on these points before finalizing my proposal. Here is my prototype repository for reference:

Thanks!