-
Notifications
You must be signed in to change notification settings - Fork 182
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New command dwi2noise
#3035
Comments
@tsalo Regarding the NORDIC approach of estimating the noise level via no-RF volumes as mentioned in nipreps/fmriprep#3395: There's already a bit of a misnomer here, the existing 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. |
@Lestropie I know you closed this since you implemented a dwi2noise command, but I just reviewed the NORDIC code and here's how it seems to work:
|
I figured it was probably something relatively simple like that. I don't know enough about it to know how it is that they derive the g-factor term. For the rest of it, there doesn't strictly need to be a named command to serve that purpose, it can be done using a one-liner (admittedly a complex one).
mrcalc \
$( \
mrstats -allvolumes -output std \
$( \
mrcat \
$( \
mrconvert <fMRI_series> -coord 3 0 - | mrcalc - -real - \
) \
$( \
mrconvert <fMRI_series> -coord 3 0 - | mrcalc - -imag - \
) -axis 3 - \
) \
) 2 -sqrt -div The option of providing as input not a noise map, but just a fixed noise level, should be trivial: #3051. From the data I've been working with I'm a little pessimistic about such an assumption, but there's little harm in having it available. |
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.The text was updated successfully, but these errors were encountered: