dwi2mask overhaul (replacement PR)

[Lestropie]

#2088 is broken due to me wiping my fork (completely forgetting that that's where the dwi2mask updates were...) and GitHub refusing to re-establish the PR link; so relisting.

Given that the other OHBM Hackathon MRtrix3 project has matured to a preview release and should become a part of 3.1.0, I wanted to clear this off of my desk; there's also been a couple of private discussion threads where having this finalised would be beneficial. Listing as a full PR rather than a draft in the hope of getting some fresh eyes & opinions on it, but I will probably try to make some test data before merging.

There's some brain masking approaches that I tried to get working as a dwi2mask algorithm but couldn't get anything reasonable out of them, I still have the code if anyone wants to try themselves:
https://github.com/GUR9000/Deep_MRI_brain_extraction
https://pypi.org/project/deepbrain/
I'm open to implementing further algorithms to wrap existing approaches, but such approaches need to be compatible with T2-weighted images, and many newer brain extraction approaches are T1w tailored.

Because it's coming from my fork I don't have things set up to preview the documentation, but you can see the relevant raw pages:
https://github.com/Lestropie/mrtrix3/blob/dwi2mask/docs/dwi_preprocessing/masking.rst
https://github.com/Lestropie/mrtrix3/blob/dwi2mask/docs/reference/commands/dwi2mask.rst

@jdtournier: I thought about having hyperlinks in the dwi2mask help pages to the new dedicated docs page on the topic. But this would require parallel gymnastics to those used for getting version-matched hyperlinks into the SH-related binaries prior to tagging. Want to do it anyway?
Edit: If doing so, should also add links to the dwi2response docs page in the dwi2response help pages.

Tagging @wtsyeda and @RicardoRios46 so that they're aware of the progress given their contributions.

[Lestropie]

Now includes content of Lestropie#2.

Would like to merge and encourage more widespread evaluation prior to 3.1.0.

[Lestropie]

One other thing to confirm that nobody's unhappy with here is the naming of the additional maskfilter operation "bigblob". This integrates [ largest connected component -> inversion -> largest connected component -> inversion ] into a single operation, since it's a common chain. But open to suggestions for a better name.

[jdtournier]

One other thing to confirm that nobody's unhappy with here is the naming of the additional maskfilter operation "bigblob". This integrates [ largest connected component -> inversion -> largest connected component -> inversion ] into a single operation, since it's a common chain. But open to suggestions for a better name.

Not sold on the 'bigblob' name - though it does have a certain appeal.

Just a thought, but given its mode of operation and the intention behind it, might it not be more appropriate to make that available as an option within the connected component filter, simply by adding -fill to the options alongside -largest...? Just an idea, but I reckon a command like:

maskfilter in.mif connect -largest -fill out.mif

would make sense?

[Lestropie]

... as an option within the connected component filter, simply by adding -fill to the options alongside -largest

As long as -fill additionally applies to the connect filter without -largest, I think that works better. -largest is already slightly awkward in that it changes the nature of the output image from integer to bitwise; if -fill would then additionally be only applicable in instances where -largest is already used. you'd end up with two degrees of separation from the default filter operation. But if -fill and -largest are effectively independent, I'm good with that.

Just need to think about what to do if the filling of one component results in inclusion of voxels that are already in another component (e.g. concentric shells), since that result can't be stored as an integer label image.

[Lestropie]

So it turns out there's more gymnastics involved in adding a fill operation to the connected component algorithm than foreseen, the implementation code ends up branching between fill and not moreso than the overlap if wanting to support filling in the absence of -largest.

So I think it in fact makes more sense to remove maskfilter bigblob and instead have a new filter fill, and just have various dwi2mask algorithms use ... - | maskfilter connect -largest - | maskfilter - fill - | .... If somebody wants to spatially fill multiple connected components, that can be done in a loop with maskfilter connect; mrcalc $INDEX -eq - | maskfilter - fill - | ..., and then they can themselves choose to not deal with the prospect of resulting overlaps.