Full lazy resampling implementation

[atbenmurray]

Refactor of compose, transforms and related functionality deliver full lazy resampling functionality. This PR reworks the spatial transforms to decouple the description of the transform from the execution of the transform, as per the design specified in #4855. It also decouples compose from various sources of modification to a sequence of transforms that may occur due to multi-sampling, lazy execution, caching, and potential other augmentations, through the provision of a compose compiler.

Description

Key: n - not done, p - partial, c - code complete

Refactored transforms:

• [p] spatial
  • [n] SpatialResample/ResampleToMatch
  • [c] Spacing
  • [p] Orientation
  • [c] Flip/RandFlip/RandAxisFlip
  • [c] Resize
  • [c] Rotate/RandRotate
  • [c] Zoom/RandZoom
  • [c] Rotate90/RandRotate90
  • [n] Affine/RandAffine
  • [n] AffineGrid/RandAffineGrid
  • [n] Resample (NA?)
  • [p] Rand2DElastic
  • [p] Rand3DElastic
  • [n] GridDistortion/RandGridDistortion
• [p] croppad
  • [c] CropPad (new)
  • [c] RandomCropPad (new)
  • [c] RandomCropPadMultiSample (new)
  • [n] Others

Compose

• [p] Modified compose
• [c] Compose compiler
  • [c] lazy compilation
  • [p] multi-sample compilation (may not be required)
  • [p] cached compilation

Consolidated resample

• [p] Resampler
  • [p] matrix analysis
  • [p] matrix feature extraction
  • [n] orthogonal resample path
  • [n] affine matrix resample
  • [c] affine grid resample

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 --disttests.
• In-line docstrings updated.
• Documentation updated, tested make html command in the docs/ folder.

[Nic-Ma]

Hi @atbenmurray ,

Sorry I didn't follow all the previous discussions, could you please help provide a typical usage example of your proposal?
I don't quite understand how to use the ComposeCompiler.
Seems it refactored several important components of MONAI: multi-sampling, caching and lazy-resampling? I think we should avoid breaking change as we are already in v1.1, especially the user API.

Thanks in advance.

[atbenmurray]

Let me prepare something to illustrate how it can work. For now I'll say the following: The ultimate goal of compose compiler is to take a number of disparate mechanisms in different areas of the code base and make them more easily able to work together because they make use of common mechanisms. The way it does this is to modify the user-provided sequence of transforms using transforms designed for that purpose. Each of the features that compose compile implements can be "switched on" independently: 1. Lazy resampling is needed right away: what it does is add ApplyResample objects where they are needed in the pipeline 2. Multi-sampling modifies the pipeline so that the transforms downstream of a multisample transform are contained within a Transform that can run those multiple samples efficiently. Initially I thought it might be required to not increase the required memory, but it looks like it might not be 3. Caching modifies the pipeline so that the cacheable transforms are separated from the remaining transforms and put into a CachedTransform object. This isn't needed at all unless we are happy that the replacement functionality is fully ready I'm more than happy to talk you through the various mechanisms, of course. Best, Ben

…

On Thu, 16 Feb 2023 at 12:08, Nic Ma ***@***.***> wrote: Hi @atbenmurray <https://github.com/atbenmurray> , Sorry I didn't follow all the previous discussions, could you please help provide a typical usage example of your proposal? I don't quite understand how to use the ComposeCompiler. Seems it refactored several important components of MONAI: multi-sampling, caching and lazy-resampling? I think we should avoid breaking change as we are already in v1.1, especially the user API. Thanks in advance. — Reply to this email directly, view it on GitHub <#6011 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAUU3YMSFMMIRYTY3W5WIJDWXYKDPANCNFSM6AAAAAAU56EVUM> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[wyli]

could you please clean up the unused LR related branches @atbenmurray ? https://github.com/Project-MONAI/MONAI/branches

[atbenmurray]

Yep, there are a few that can go

[wyli]

Yep, there are a few that can go

sure, thanks, all of us use forks to develop instead of creating branches in this primary repo. I'll make a backup of these branches and remove them.

[wyli]

Closing this PR, as the initial prototype design is already on the dev branch, and this branch diverged. (This branch is backed up here https://github.com/wyli/MONAI/tree/lr_development)

[atbenmurray]

@wyli. This pr and branch should not have been closed and deleted. This is ongoing work that was paused to ensure that the 1.2 lazy resampling was ready for release. This could easily have been handled by asking me if this branch was still relevant. This work is still the v+1 (full) lazy resampling implementation and is still the ultimate design goal for it.

[wyli]

Could you please start from your fork?

[atbenmurray]

@wyli, if you would like me to move this branch to my fork for further development (as I understand we are moving a purely fork-based contribution model) then I am happy to do so. I will then delete this branch subsequent to doing so.

[atbenmurray]

Please leave the development branch intact for the time being, until I have ensured that the fork is intact and up to date.

[wyli]

Sure, I'll keep the branch till the end of this month. And then remove it to avoid any confusions.

[atbenmurray]

I'll remove it later today when I am happy that the fork is fine.