search

MRtrix3 / mrtrix3

MRtrix3 provides a set of tools to perform various advanced diffusion MRI analyses, including constrained spherical deconvolution (CSD), probabilistic tractography, track-density imaging, and apparent fibre density
http://www.mrtrix.org
Mozilla Public License 2.0
281 stars 176 forks source link

OHBM Hackathon projects #1964

Open Lestropie opened 4 years ago

Lestropie commented 4 years ago

I'm hoping to again attend the hackathon that runs prior to OHBM. This time around, I'd like to pre-register project ideas on their site well ahead of the event, to hopefully attract some interest and have some team members essentially ready to go from the start of the event.

Ideal projects would be those that:

Open to ideas for either assignment of existing issues, or new ideas.

Initial list:

maxpietsch commented 4 years ago
Lestropie commented 4 years ago

Given the difficulty of the dwi2mask task, having a script algorithm interface probably makes sense; the existing algorithm would not I expect be hard to re-implement in Python. For a registration-based method, having cross-correlation in mrregister would be preferable. DeepBrain looks like it's T1w only; HD-BET apparently works on high-resolution T2-weighted, but would want to test it manually on some difficult DWIs before committing to wrapping it.

I should at some point try to write down the algorithm in my head, see if it's got any chance of working...

Lestropie commented 4 years ago

Bumping as registration just opened.

Lestropie commented 4 years ago

Bumping again as the hackathon repository is open for project proposals. It would be preferable for people to be able to read any proposals prior to the event next week.

Other things that came in from Twitter:

Personally I'm concerned about the scope of most of the suggestions that have been listed: I'm limited in how much I can do myself in a given period of time, and a lot of proposals don't give a whole lot of opportunity for those not already developing with MRtrix3 to contribute.

Whether or not any other @MRtrix3/mrtrix3-devs are taking part may have an influence here.

maxpietsch commented 4 years ago
thijsdhollander commented 4 years ago

Good to get to know API & nice new command (maybe more exciting than integration in existing commands? I don't know, just an idea.): mrnew, a command to create a new empty image. Would e.g. come with a range of options to set basic properties (dimensions, sizes of dimensions, voxel size, transform, any other header entry, etc.. similar to the range of things you can change with mrconvert for existing images), and option(s) to adopt these or some of these from header of a given other existing image. Maybe also option(s) to fill the new image with a single intensity. Guessing that would be the scope of it, as beyond that, you could imagine mredit "takes over". I can imagine a lot of useful applications of such a command in scripting; so it would be a nice addition to the toolkit. From hackathon point of view: it's pretty generic, doesn't require too much intricate or arcane diffusion MRI knowledge; also pretty flexible scope for hackathon, as there's a basic functionality but also a range of improvements possible, depending on time. Hope it helps.

thijsdhollander commented 4 years ago

Actually, now that I think of it, mrcheckerboardmask's pattern could be one of the options to set the initial intensity.

dchristiaens commented 4 years ago

mrnew, a command to create a new empty image. Would e.g. come with a range of options to set basic properties (dimensions, sizes of dimensions, voxel size, transform, etc.), and option(s) to adopt these or some of these from header of a given other existing image.

When you have an existing "template" header, you can achieve this in a one-liner with mrcalc in.mif 0 -mult new.mif, followed by the appropriate mrconvert / mrgrid / mredit calls.

I can imagine a lot of useful applications of such a command in scripting; so it would be a nice addition to the toolkit.

Can you think of any where you would not already have a template header to start from?

maxpietsch commented 4 years ago
dchristiaens commented 4 years ago
  • brain masking.

This could be a good "educational" project, and very useful given the issues we encounter regularly.

  • not very exciting application but good to get to know the API: deprecate mrcheckerboardmask and integrate into mredit

It's a nice idea and very manageable in scope, but I agree it's not particularly thrilling.

Other things that came in from Twitter:

  • FC Yeh's bundle shape analysis
  • Vanderbilt MASI Lab WM atlases, preprocessing, labeling
  • Vertex-wise cortical similarity from a tractogram

It sounds fun if there's already community interest for these. Do you have a preference and can you elaborate on the scope? Sorry I missed the Twitter discussion you refer to.

Personally I'm concerned about the scope of most of the suggestions that have been listed: I'm limited in how much I can do myself in a given period of time, and a lot of proposals don't give a whole lot of opportunity for those not already developing with MRtrix3 to contribute.

Whether or not any other @MRtrix3/mrtrix3-devs are taking part may have an influence here.

I would be happy to take part, but also limited in the time I can commit. I'm not sure I understand how it's going to work with the time zones. Presumably, you will sign up in the Asia/Pacific time "hacktrack"?

thijsdhollander commented 4 years ago

When you have an existing "template" header, you can achieve this in a one-liner with mrcalc in.mif 0 -mult new.mif, followed by the appropriate mrconvert / mrgrid / mredit calls.

Sure, as is the case for a lot of other functionality as well. The argument comes up every once in a while, and can be used at one's convenience to argue either way: "it's technically also possible with..." versus discoverability and common sense. Distracts from what could be a constructive exploration of an idea.

Can you think of any where you would not already have a template header to start from?

Many. I'll provide an example contributed by Max:

an ODF simulation interface that uses a .csv file as input: location, amplitude and orientation to map SH delta functions to create ODFs. can be used to make pretty images or for debugging, research, DWI signal simulation, ...

More broadly, anything to do with research and testing things via artificial data or similar experiments. Either an mrnew (alternative name: mrcreate, maybe fits better thematically with existing mredit) command could create the empty image only, or it could come with categories of options to create (mrcreate does sound nice) stuff. E.g. SH delta functions from .csv file, tensors from .csv file, raw intensities from .csv file, etc... etc... When providing some data from .csv files, it could in some cases even not (have to) require either template image or given dimensions (they might sometimes be implied from the .csv data, e.g. simple conversion of intensities from .csv to a new .mif. People could leverage it to write scripts to generate entire phantoms, etc... Similar to e.g. commands like mrcalc, it's also naturally very extendable towards the future.

Each and every time I have to do this or get the question, I (recommend to) resort to the matlab export tool to generate a "new" image. Or work with pre-generated "new" images that are kept around just for this purpose; quite messy.

Finally, mrcheckerboardmask fits nicely in it. Most straightforward way to see why it fits better with an mrcreate rather than in mredit is to read its synopsis.

I think that would address your questions. It's just a suggestion, because suggestions were welcomed..

brain masking.

FSL BET on the average b=0, for datasets where dwi2mask doesn't work well. This works quite well for a lot of datasets. (side note: can also be used to initialise dwibiascorrect, if bias fields were the cause of dwi2mask struggling, and then follow up with dwi2mask)

You could make a dwifslbet script. Then again, this is also possible with a one-liner followed by a BET call. Not sure if that matters though.

Lestropie commented 4 years ago

Visual QA.

Topic has come up a couple of times on the forum, with people looking for something akin to FSL's slicesdir; more recently I'm thinking of fmriprep's HTML output, and eddyqc.

With 3.0.0, the ability to export directly to PNG means that there's a reasonable amount that could be done even on a headless system without ever invoking mrview; there are however more advanced things that could be done with mrview if possible.

Unfortunately this sort of thing would be much better posed if the outputs of processing were stored in a BIDS Derivatives format, such that it'd be easy to find all the various bits of data. Without that you're relying on the command-line interface to provide whatever data are deemed requisite.

This topic could also be viewed at two different analysis levels:

Even for those not adept at coding there's potentially a fair bit of scope here for coming up with different ideas.

maxpietsch commented 4 years ago
thijsdhollander commented 4 years ago

a tool to view .mif or any other supported file directly in the terminal

That would be very useful.

Lestropie commented 4 years ago

I must admit before my eyes got to the "existing png support" bit I thought you were talking about spitting out ASCII art from image data :man_facepalming:

Would be fractionally concerned about stepping on the shoes of niicat, it's not that old and a unique idea. Plus eventually people would ask for it to be interactive :grimacing:

maxpietsch commented 4 years ago

Yes, don't want to step on any shoes either. On the other side, niicat inherits key parts from other packages as well https://github.com/vnckppl/niipre https://github.com/fastai/fastai/blob/master/fastai/sixel.py. I think for us the step to display a png on the terminal is quite small as we have the file type and plotting support already built-in. In any case, I'd ask Jakob how he feels about incorporating this into MRtrix.

Alternatively, niicat supports displaying png. So a thin wrapper around niicat would also work, in particular as niicat currently has no options on what to display (centre of first volume) so that could be done with the wrapper. This makes it slightly harder to maintain and bundle though.

image

Another alternative is to add .mif support to nibabel. That'd make niicat compatible with .mif

Plus eventually people would ask for it to be interactive

That's an expectation management problem and if people need more functionality, adding options to the script would be a relatively easy way to contribute to MRtrix.

thijsdhollander commented 4 years ago

In any case, I'd ask Jakob how he feels about incorporating this into MRtrix.

@wasserth, how do you feel about incorporating this into MRtrix?

wasserth commented 4 years ago

I am happy to hear that you find niicat useful. I also started using niicat a lot more since I am in home office. Generally speaking it would be really nice to add .mif support to nibabel. Then niicat could easily load it. I am working a lot in python and using nibabel to load images. If I come across a .mif I always have to convert first which is a bit painful. So support in nibabel would be awesome.

If you want to wrap niicat in Mrtrix I am fine with that (as long as you mention where it comes from). You can also copy the code. It is not a lot. But I would still maintain the niicat pip package. If I am on a new server and want to view an image it is just a lot easier to quickly do pip install niicat instead of having to install complete mrtrix.

Interactivity would be amazing but I do not really know how to do that. I guess that's not so easy.

wasserth commented 4 years ago

Converting a mif to a png does not look too difficult. I could integrate this into niicat. But then it would only show one volume. Plotting from three different orientations and getting all the metadata from a mif would be a bit more work since I am not so familiar with mif. If you create a pull request or send me some code I would be happy to look over it. I guess the cleanest approach would be to add mif loading to nibabel. Not sure how much work that is.

maxpietsch commented 4 years ago

@dchristiaens has implemented a .mif IO python package https://github.com/dchristiaens/mrtrix3-pyio. It is currently not integrated into nibabel and from a quick glance at their code, I'd say it requires some time to figure out and adapt to nibabel's class structure.

Branching based on filetype is somewhat cumbersome but if you wanted to support .mif with Daan's package, it is pretty straightforward to use:

image = load_mrtrix(iFile)
data = image.data  # numpy array
lX, lY, lZ = data.shape[:3]
sX, sY, sZ = image.vox[:3]
transform = np.round(image.transform, decimals=2)
dchristiaens commented 4 years ago

@dchristiaens has implemented a .mif IO python package https://github.com/dchristiaens/mrtrix3-pyio. It is currently not integrated into nibabel and from a quick glance at their code, I'd say it requires some time to figure out and adapt to nibabel's class structure.

I agree that having .mif support in nibabel would be nice. I briefly looked into this at the time I wrote the IO package (this must have been 2012/13), but ultimately opted for an independent package modelled on the MRtrix Matlab read/write functions. I remember also finding the class structure in nibabel difficult to wrap my head around (entirely my fault, I am sure), and I was concerned about supporting custom header fields. The nibabel code has probably evolved a great deal since, so it could be worth having another look.