Transformation on Subvolume for mri3d_subvolume_segmentation_dataset

[cakester]

Checklist

GitHub

• I've given this PR a concise, self-descriptive, and meaningful title
• I've linked relevant issues in the PR body
• I've applied the relevant labels to this PR
• I've assigned a reviewer

PR contents

• I've consulted ivadomed's internal developer documentation to ensure my contribution is in line with any relevant design decisions
• I've added relevant tests for my contribution
• I've updated the relevant documentation for my changes, including argparse descriptions, docstrings, and ReadTheDocs tutorial pages

Description

transformation on subvolume for mri3d_subvolume_segmentation_dataset instead of full volume

Linked issues

resolves #993

[cakester]

following https://github.com/ivadomed/ivadomed/pull/982/files

[coveralls]

Pull Request Test Coverage Report for Build 2605683149

• 39 of 44 (88.64%) changed or added relevant lines in 2 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.08%) to 74.153%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
ivadomed/loader/mri3d_subvolume_segmentation_dataset.py	26	31	83.87%

Totals
Change from base Build 2578332769:	0.08%
Covered Lines:	4530
Relevant Lines:	6109

---

💛 - Coveralls

[lifetheater57]

If I understand correctly, the current code changes don't change what is transformed are still the full size pairs (Related to @dyt811 comment.).

Also, if I understood correctly, previously we would have:

1. Take full volume -> 2. Apply transformation -> 3. Take subvolume -> 4. Do something with subvolume

Is the intent of this PR to get the same transformed subvolume to do 4?

If we do:

1. Take subvolume -> 2. Apply transformation -> 3. Do something with subvolume

Depending on the transformation applied, we may get a different result because some transformations are sensitive to the change in coordinates.

To, keep the same transformation given the change in coordinates, we might want to do something like:

1. Take subvolume -> 2. Transform the transformation -> 3. Apply transformed transformation -> 4. Do something with subvolume

[dyt811]

Lucy's feedback a few days ago posted on Slack:

The order of image processing pipeline of doing subvolume transformation instead of full volume transformation do affect the transformation result. For spacial transfer such as flip, rotate, etc, the result wouldn’t change. But for image smoothing/blur, elastic-transfromation, etc, because a convolution kernel is used, the transformation result is different. For ML training propers, I don’t think this difference matters. However, if the transformation is k-space transform, you definitely CANNOT apply k-space transformation on subvolume.

So overall, I agree that we may have to make this path mandatory and full volume augmentation optional?

[lifetheater57]

I approve this PR since there is no more functional work to do given my understanding. However, I suggest to do the changes related to the keywords usage for maintainability reasons and the changes related to the ranges to ease the code analysis.