[ENH]: Smoothing images as a preprocessing step

[synchon]

Are you requiring a new dataset or marker?

• I understand this is not a marker or dataset request

Which feature do you want to include?

One standard preprocessing step in a lot of MRI analyses (that is not applied by fMRIprep) is smoothing images after confound regression. It would be good to have this as an additional inbuilt preprocessing step.

How do you imagine this integrated in junifer?

The easiest way will probably be using the nilearn function for smooting images, although one can also use AFNI, but I dont expect that to yield very different results.

Do you have a sample code that implements this outside of junifer?

No response

Anything else to say?

No response

[LeSasse]

One particular smoothing function that is quite different from others is FSL's SUSAN. This is particularly interesting because it is the smoothing function used by XCP engine. If we do want to implement this (as an additional dependency...) then the nipype function create_susan_smooth may be of interest. This blogpost shows how to use it. Command line GUI/wiki for SUSAN is here. There is also a wrapper for the susan command in python

[synchon]

@LeSasse Do you already have a use-case for this? Will help to check the implementation(s) on real-world usage.

[LeSasse]

So, I have a use case where I would like to test the current pipeline without SUSAN and compare it with the results when using SUSAN. In addition, I have equivalent data preprocessed with xcpengine which uses SUSAN so we can also compare it to that.

[synchon]

Sounds good, will let you know when I have something concrete.

[synchon]

@LeSasse @fraimondo I think we can have either (i) 1 class handling 1/2/3 "backends" (nilearn, AFNI, FSL) or (ii) 3 classes named accordingly. Having 1 class will of course bloat it but keep it in one piece. I personally prefer (ii) but if (i) is better from usage POV, I don't mind it either.

[synchon]

@LeSasse @fraimondo I think we can have either (i) 1 class handling 1/2/3 "backends" (nilearn, AFNI, FSL) or (ii) 3 classes named accordingly. Having 1 class will of course bloat it but keep it in one piece. I personally prefer (ii) but if (i) is better from usage POV, I don't mind it either.

Since, there's no agreement or disagreement, I'll proceed with (ii).

[github-actions]

PR Preview Action v1.4.7
Preview removed because the pull request was closed.
2024-04-09 14:35 UTC

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 100.00%. Comparing base (c36165b) to head (9054ff4).

Additional details and impacted files

@@            Coverage Diff            @@
##              main      #161   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files            1         1           
  Lines            1         1           
=========================================
  Hits             1         1           

Flag	Coverage Δ
docs	100.00% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

[fraimondo]

If there is no "common" API that the different "backends" use, then having one single class can be difficult (e.g. yield too many optional parameters conditional to the backend).

In that case, I would KISS with (ii).

[fraimondo]

For me, different backends should not alter the result, rather than the kind of tool used. If the result is not the same, then it should not be a backend, but a different class.

[synchon]

For me, different backends should not alter the result, rather than the kind of tool used. If the result is not the same, then it should not be a backend, but a different class.

After looking at the implementations, they don't exactly do the same thing in the sense that they have different parameters which affect the result so having distinct classes make sense.

[LeSasse]

@LeSasse @fraimondo I think we can have either (i) 1 class handling 1/2/3 "backends" (nilearn, AFNI, FSL) or (ii) 3 classes named accordingly. Having 1 class will of course bloat it but keep it in one piece. I personally prefer (ii) but if (i) is better from usage POV, I don't mind it either.

Since, there's no agreement or disagreement, I'll proceed with (ii).

sounds good to me

[synchon]

@LeSasse This PR works for you right? Before merging, would be cool if we can check your pipeline comparison works as expected.

[LeSasse]

@LeSasse This PR works for you right? Before merging, would be cool if we can check your pipeline comparison works as expected.

Saw this just now, yeah works smoothly on my side. Consider it approved!

[LeSasse]

LGTM