Rician Noise Transform

[lyndonboone]

Description

Added a Rician noise transform for modeling noise in MRI.

closes #2054

Status

ready

Types of changes

• Non-breaking change (fix or new feature that would not break existing functionality).
• Breaking change (fix or new feature that would cause existing functionality to change).
• New tests added to cover the changes.
• Integration tests passed locally by running ./runtests.sh -f -u --net --coverage.
• Quick tests passed locally by running ./runtests.sh --quick --unittests.
• In-line docstrings updated.
• Documentation updated, tested make html command in the docs/ folder.

[wyli]

thanks, it looks nice! just a few minor things to improve:

• add a paper reference in the docstring
• add two unit tests like test/test_rand_gaussian_noise.py and test/test_rand_gaussian_noised.py, so that we know the expected behaviour of these transforms
• fix the flake8 issue https://github.com/Project-MONAI/MONAI/pull/2066/checks?check_run_id=2403627264#step:7:340 (could remove the type hints if the errors don't make sense)

[lyndonboone]

@wyli thanks for the comments! I added a couple of unit tests that closely resemble tests/test_rand_gaussian_noise.py and tests/test_rand_gaussian_noised.py.

These test the default options for the Rician noise transform, which make it act the same as the current Gaussian noise transform. I also added a couple of additional options to the Rician noise transform:

• relative allows the std to be specified relative to the image intensity histogram's standard deviation.
• channel_wise allows the above to be done channel-wise, or with different values per channel (mechanics based on the NormalizeIntensity transform).
• sample_std toggles whether the std of the applied noise is sampled from a uniform distribution (as in the current Gaussian noise transform) or is left as specified. The first case would be typical during training/augmentation but the second case may be useful if the user would like the same degree of noise to be applied each time for some reason (e.g. perhaps doing some experiments at test time).

Whenever you get a chance, let me know what you think of these options and whether I should include unit tests for them. I'm fairly new to writing unit tests but I'll do my best to figure it out if necessary.

I'll also try to take a look at the flake8 issue over the weekend or early next week.

[wyli]

the PR looks good to me, just need to fix the flake8 issue, and keep the branch uptodate with the master branch then I'll merge it. Many thanks!

[lyndonboone]

@wyli thanks! When I run the mypy tests on my local machine I get the error below, which is preventing me from getting to the typing errors. Any ideas on how I might be able to get around this?

[rijobro]

What OS are you on?

[lyndonboone]

Thanks for the reply @rijobro. I'm using WSL2

[wyli]

the PR looks good to me, thank you!

[lyndonboone]

No problem, thanks @wyli !

@rijobro the problem I was having seems to be related to this issue in mypy: python/mypy#7281. I temporarily moved the BlockArgs class definition to outside the _decode_block_list function in efficientnet.py which allowed me to get at the typing errors.