Closed Lestropie closed 4 days ago
@tsalo Regarding the NORDIC approach of estimating the noise level via no-RF volumes as mentioned in https://github.com/nipreps/fmriprep/pull/3395:
There's already a bit of a misnomer here, the existing dwidenoise
command technically doesn't operate exclusively on DWI data as one would expect given the name (which we've been quite pedantic about elsewhere). I think we can nevertheless extend that naming to a dwi2noise
in the case where the same PCA-based noise level estimation is happening. However for utilisation of the no-RF volumes for noise level estimation it's probably straying too far away from a "this command operates on DWI data" label. So it might warrant a different command.
Do you have any capability for contributing toward such? I've never seen or acquired no-RF volumes, so don't have any particular vested interest in it, and I've suddenly generated a whole lot of other changes I'd like to make to denoising (#3023); but if there's anyone interested in taking it on I'm happy to assist in doing so within the MRtrix3 API to keep it all together.
Strongly related to #2274.
In the scenario where one fully intends to perform a two-pass operation, one to estimate the noise level and then one to denoise based on a (possibly filtered in an intermediate phase) noise level input map, it would be wasteful to necessitate use of the
dwidenoise
command for the first step. It would involve reconstructing and writing a denoised DWI series that is to be discarded. Further, there are likely a few command-line options fordwidenoise
that would be entirely inapplicable for the first step.What I'd like to do is move much of the denoising code into
src/
, and then have two commands,dwi2noise
anddwidenoise
. The former would be constrained to noise level estimation and exporting of features such as rank. For the second, the noise level for denoising would either be provided via command-line option, or operate using the same mechanism asdwi2noise
if not provided.