search

nipreps / fmriprep

fMRIPrep is a robust and easy-to-use pipeline for preprocessing of diverse fMRI data. The transparent workflow dispenses of manual intervention, thereby ensuring the reproducibility of the results.
https://fmriprep.org
Apache License 2.0
631 stars 293 forks source link

Add optional NORDIC denoising step #3308

Open tsalo opened 3 months ago

tsalo commented 3 months ago

What would you like to see added in fMRIPrep?

If possible, it would be great to support NORDIC denoising.

NORDIC is currently written in MATLAB, which might be a problem.

Do you have any interest in helping implement the feature?

Yes

Additional information / screenshots

BIDS now supports separate noRF scans for the no-excitation pulse volumes people often acquire at the ends of their runs for NORDIC.

effigies commented 3 months ago

Would be good to know how NORDIC fits into the fit and transform workflows. Does it need to be done before/after HMC/STC? Is it deterministic/nondeterministic? What's the runtime? Is there a compact set of parameters that can be saved, or is it basically just the noRF files are the parameters?

tsalo commented 3 months ago

Pinging @madisoth for his thoughts, but my understanding is that it needs to be done before HMC, STC, or basically anything else. I don't think it's deterministic, unfortunately.

Most parameters are determined from the data (e.g., how many noise volumes, whether there's phase data or not). The only one I can think of that users might want to vary is phase_filter_width, but there's a strong recommendation to use a value of 10 for fMRI data, so even that could be hardcoded.

Not sure about the runtime since I've only ever run it on large numbers of runs in jobs.

mvdoc commented 3 months ago

Just popping in to say that re the MATLAB implementation, I recently found this package with a python implementation of NORDIC: https://paquiteau.github.io/patch-denoising/ (and associated paper: https://hal.science/hal-03895194/file/isbi2023_denoise.pdf)

I did not have a chance to try it myself (or NORDIC itself), so buyer beware.

tsalo commented 3 months ago

Thanks @mvdoc! The repo looks really promising, and even if it's not completely up-to-date with SteenMoeller/NORDIC_Raw (which it very much could be), it would still be a great jumping off point.

I also wanted to note that, for multi-echo data, NORDIC could be run on each echo independently (which I believe is how most folks do it), or we could try the HYDRA-OC approach from this OHBM abstract by Marco Flores-Coronado and Cesar Caballero-Gaudes. In that approach, it looks like you concatenate the multi-echo in a spatial direction (Z in their case), run NORDIC, and then split up the denoised data.

tsalo commented 1 month ago

I looked at the patch-denoising code and it doesn't seem like it uses noRF scans for its NORDIC implementation, so I'm not sure how close it is to the "official" method.

tsalo commented 1 month ago

I think we might need to use the MATLAB version.

@Remi-Gau do you know any tricks for using MATLAB in containers/BIDS apps?

Remi-Gau commented 1 month ago

Yeah. Make sure the code is Octave compatible and use Octave. Otherwise you are down the road of compiling Matlab code... Where is the Nordic code base? If it's the one I am thinking of I may have "opinions" about it...

tsalo commented 1 month ago

This one is the one I was planning to use, since it's the one others seem to be using. I don't know if it's Octave-compatible though. It does rely on the nifti/20130306 libary.

tsalo commented 2 weeks ago

It looks like someone has been working on Nipype interfaces for NORDIC (https://github.com/SteenMoeller/NORDIC_Raw/pull/21).

tsalo commented 2 weeks ago

@MoniDoerig have you had a chance to test out the NORDIC Nipype interfaces you wrote in your PR? Do you know what else might need to go into the Docker image to make it work?

MoniDoerig commented 1 week ago

@tsalo Yes, I've tested the Nipype interface for the NIFTI_NORDIC script both on lab and open-source data, specifically 7T event-related fMRI data. The tests were conducted on Neurodesk Version 24-04-04.

You can find a Jupyter Notebook showcasing the usage and changes I made to the NIFTI_NORDIC script to make it compatible with Nipype, along with the Nipype interface itself here.

The Nipype interface is specifically for NIFTI_NORDIC, which, unlike the original NORDIC, does not require a noise-scan or the g-factor map. Also, it uses additional parmeters that can be adjusted. If no additional parameters are provided, the interface uses the default values. These could be hard-coded (e.g., using magnitude images only, specifying output format) to simplify the interface and remove reliance on an additional parameter struct. However, this would reduce flexibility in case other configurations are needed.

Regarding the Docker image:

tsalo commented 1 week ago

Thank you @MoniDoerig. It sounds like the best move forward on fMRIPrep's end would be to fork NORDIC_Raw with your changes, compile it into a standalone application with MATLAB Runtime, release that so it can be downloaded easily, and then add it to the fMRIPrep Dockerfile. @effigies does that sound right to you?

bpinsard commented 2 days ago

When I created an image for NORDIC with MCR it ended up being very large, not sure if that was because I had a licence with all the extensions. I don't think there are not many options to make MCR images much lighter, I tried to track all files used when running the MCR compiled files and removing the one unnecessary but it broke the MCR. Not sure if we want to make fMRIPrep docker images that heavier. And maybe we should try to work with the python implementation above that I just found about here.

tsalo commented 17 hours ago

Agreed. @Remi-Gau reached out to the Python version's author and he's willing to work through bugs and such.