Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Software internship projects #2420

Open
Lestropie opened this issue Jan 10, 2022 · 0 comments
Open

Software internship projects #2420

Lestropie opened this issue Jan 10, 2022 · 0 comments
Labels
good first issue good for first time contributors internship Issues suitable for student projects

Comments

@Lestropie
Copy link
Member

Lestropie commented Jan 10, 2022

The purpose of this Issue is to provide a list of software projects that could feasibly be attempted:

  • By someone with requisite software engineering or computer science skills, without necessarily having any prior experience in neuroimaging, diffusion MRI, or MRtrix3
  • As a ~ 175-350 hour project (Google Summer of Code is 175 or 350 hours; University of Melbourne Masters internships are >= 340 hours)
  • That do not immediately involve novel scientific contribution; i.e. can be attempted as purely software engineering in the absence of nontrivial scientific novelty

Each project should have at least a one-paragraph description here, since many existing Issue listings are written with existing developers as the only target audience.

@MRtrix3/mrtrix3-devs: Please append as you see fit.


Edit:

Posting now in part due to GSoC 2022 notification: https://summerofcode.withgoogle.com/

Suggestions from GSoC regarding project listing: https://google.github.io/gsocguides/mentor/defining-a-project-ideas-list
Primary content (to be updated for this Issue):

a) a project title/description
b) more detailed description of the project (2-5 sentences)
c) expected outcomes
d) skills required/preferred
e) possible mentors
f) expected size of project (175 or 350 hour).
And if possible, an easy, medium or hard rating of each project.


Projects

  • Support for soft parcellations in all "label"-related commands, + smoothing capability, + tck2connectome: ENH *label*: Support both hard & soft parcellations #2376

    Language: C++

    The structural connectivity of the brain is frequently analysed by sub-dividing the grey matter into discrete regions, and quantifying the connectivity between all pairs of regions. The typically arbitrary nature of this sub-division, combined with the manifestation of errors in reconstruction, can lead to undesirably high inter-subject variability. A proposed strategy for combatting this is to utilise a smoothed, continous-rather-than-discrete version of the parcellation. This project would involve generalising various MRtrix3 commands that operate on such data to be compatible with both formats of such data.

  • Augment mrview with visual indication of scanner vs. image axes orientations & signs, and notification of camera change: Alert user when switching between images with lock to grid on. #452

    Language: C++, GLSL

    Visualisation of 3D neuroimaging data can become complex due to the potential for the voxel grid to be in any arbitrary orientation relative to the native axes of the MRI hardware. Some orientation information may be encoded relative to one or the other, and it is possible to visualise data from different images that may have been acquired on different grids. This can be misleading during certain visualisation manipulations. We would like to add to the MRtrix3 visualisation tool a plugin that shows visually the relative orientations of these axes, and appropriately notifies the user under certain use cases where that information is pertinent.

  • mrview: Convert ROI tool to operate in 3D: 3D roi tool #1208 (+ ROI tool: Wishlist #155)

    Language: C++, GLSL

    The visualisation command in MRtrix3 includes a tool for editing binary 3D images ("masks" / "Regions Of Interest (ROIs)"). This tool currently enables editing within a fixed 2D plane only. It would be desirable to modify this tool in order to enable editing in both 2D and 3D modes.

  • Tractography: Support multiple file formats through format handlers, and add support for TRX format, add support for piping: Track files: Implement file format handlers #411 & ENH Support TRX format #2241

    Language: C++

    "Tractography" is a method for reconstructing the white matter pathways in the brain. The data are stored as ordered sets of 3D vertices ("streamlines"). It is additionally possible to capture sidecar data that may provide quantitative data per vertex, or quantitative data per streamline. In MRtrix3 we have a dedicated file format for the vertex data, and another dedicated format for quantitative data per vertex; there are also other formats in use by other software packages, and a novel format being designed by the community. We would like to implement back-end support for multiple formats such that any MRtrix3 command utilising streamlines data is compatible with multiple file formats, as well as support the capability of utilising Unix pipes to pass such data from one command to another without writing the core data to disk.

  • Data validation commands: Data validation commands #2418

    Language: C++

    MRtrix3 involves commands that operate on a wide range of different intrinsic data types, whether width (e.g. binary / integer / floating-point), dimensionality (3D vs. 4D), imaging modality (e.g. diffusion MRI vs. anatomical contrast imaging), outcomes of white matter reconstructions, and others. Indeed many MRtrix3 commands are named based on the types of data they receive as input / produce as output. In many instances, software issues reported by users turned out to be caused by data that somehow did not conform to the expected format. We would like to have a set of commands that more exhaustively validate the various formats involved, and additionally have other commands perform these checks if executed with the corresponding debugging flag.

    (For this project, some experience with neuroimaging data may be beneficial)

  • Automated quality control? (for raw data only)

    Language: C++

    Many questions posed to the MRtrix3 developers relate to the quality of data acquired and their applicability to the methods provided in MRtrix3. Many such questions would be addressed by having a script for initial quality assurance of diffusion MRI data, which would produce a report summarising details of the acquisition and attempt to quantify the image quality prior to any analysis taking place.

    (For this project, some experience with diffusion MRI would be required)

  • Advanced non-parametric shuffling structure: ENH *stats: Advanced shuffling #2419

    Language: C++

    In neuroimaging analysis, statistical inference is commonly performed using non-parametric techniques, as they require minimal assumptions about the statistical properties of the data. This involves shuffling of the data themselves in order to obtain an estimate of the observed data in the absence of a genuine effect (the "null distribution"). The way in which this shuffling must be performed depends on the nature of the particular experiment performed. With more advanced scientific hypotheses, the structure of this shuffling becomes more complex. A mechanism for specification of such hierarchical shuffling structure has been proposed elsewhere. We wish to implement within MRtrix3 the ability to import such data and internally generate the requisite data shuffling, particularly given that an ongoing experiment suggests that future revision of recommendations to the community is going to necessitate such a capability.

  • Modify interface for ADC calculation without invoking the tensor model: ENH dwi2adc: Support general DWI input #2195

    Language: C++

    Despite the focus of MRtrix3 on CSD and advanced analyses, generation of ADC maps is still of utility clinically. We do have a command dwi2adc to do this. However there could be some improvement in this process. Firstly, the command-line interface is quite unusual: the required data are different to that expected given the name of the command and the nature of the operation, generation of those data requires an additional processing step that shouldn't be necessary, and it typically requires manual intervention to produce the requisite metadata. Secondly, it should be possible for the mathematical calculation of ADC to be done in a superior way to how it is currently done.

  • DWI drift detection & correction: dwicat: Potential enhancements #1741

    Language: Python & C++

    The overall intensity of each sequential DWI volume could vary slowly. This "drift" could be detected & corrected by generating for each volume a predicted image based on all other volumes, comparing the intensity of the predicted volume to the empirical image data, finding a smooth representation of the unwanted intensity fluctuation over time, and compensating for that fluctuation by increasing or decreasing the intensity of each volume accordingly. This would augment the existing dwicat command, which only deals with intensity differences between multiple DWI series based on changes in the overall b=0 intensity but does not consider either changes in intensity through the duration of each series or any data other than the b=0 volumes.

  • New command maskmath: New command: maskmath #417

    Language: C++

    This would involve taking the existing mrmath command, which performs basic mathematical operations either across images or across a specific axis of an image, and modifying it to operate exclusively on bitwise mask data, providing command-line options that are specifically applicable to binary image data. So for instance, maskmath in1.mif in2.mif and out.mif would compute the intersection of the two mask images (there are other ways to do it, using mrmath or mrcalc, but this may be more intuitive for some users).

  • Automatic determination of #include's: Automated determination of #include's #2579

    Language: Python

    Include what you use is a tool for automatically determining the set of header files that should be included as dependencies for the compilation for any given C++ source / header files. This could be used to standardise the definitions of these headers at the top of all C++ source / header files throughout the repository. The project would involve writing a script to execute this tool across the MRtrix3 code base and integration of that script into the Continuous Integration (CI) tests.

@Lestropie Lestropie assigned Lestropie and unassigned Lestropie Jan 10, 2022
@jdtournier jdtournier added internship Issues suitable for student projects good first issue good for first time contributors labels Mar 2, 2022
@Lestropie Lestropie changed the title Internship projects Software internship projects Dec 12, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue good for first time contributors internship Issues suitable for student projects
Projects
None yet
Development

No branches or pull requests

2 participants