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

2 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!