mrtrix3 / mrtrix3 Goto Github PK

Allow a separate track scalar file to be used to threshold the tracks in the current view. This will fix some interpolation issues at the edges of tracks.

Just trying to build on CentOS 5 (x86_64) with:

ARCH=core2 ./configure

Configure gets as far as:
Checking for zlib compression library: 1.2.3
Checking for POSIX threads: yes
Checking for GNU Scientific Library: Traceback (most recent call last):
File "./configure", line 665, in
''', cpp_flags + gsl_cflags, ld_flags + gsl_ldflags)
File "./configure", line 320, in compile
execute (cmd, CompileError)
File "./configure", line 287, in execute
process = subprocess.Popen (cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE, cwd=cwd)
File "/usr/local/lib/python2.7/subprocess.py", line 679, in init
errread, errwrite)
File "/usr/local/lib/python2.7/subprocess.py", line 1228, in _execute_child
raise child_exception
TypeError: execv() arg 2 must contain only strings

And when I look in configure.log I see:

EXEC <<
CMD: g++ -c -fPIC -march=core2 -DMRTRIX_WORD64 -DMRTRIX_USE_TR1 -^@i^@/^@U^@s^@r^@/^@l^@o^@c^@A^@l^@/^@i^@n^@c^@l^@U^@d^@e^@ /tmp/tmpHlKvb6.cpp -o /tmp/tmpHlKvb6.o
error deleting temporary file "/tmp/tmpHlKvb6.o": No such file or directory

I've no idea where the spurious ^@ characters are coming from.

If I execute 'gsl-config --cflags' on the command line there's no spurious characters:

gsl-config --cflags
-I/usr/local/include

so they must somehow be being introduced somewhere in the script.

Can you help?
Thx.

This is despite the presence of optimisations in MRtrix 0.3 that are not present in 0.2.
Also: iFOD1 is slower than iFOD2 in 0.3.

In addition to selecting a colour map for each overlay, it would be nice to be able to set a colour for each overlay. This would just be an RGB multiplier of the image data greyscale value.

(direct copy from previous discussion)

I've been thinking for a while now that it would be good to use a different license than the GPL to allow integration of MRtrix into other projects, whether proprietary or that simply use different licenses. Something like the Mozilla Public License or even MIT/BSD. This would require stripping out all GSL dependencies - it's the only GPL component used in MRtrix.

I've had a quick look through to find which bits would need to be modified. Obviously all the linear algebra stuff would need to be modified. For this, I've just come across the FLENS project, which is basically a templated C++ header-only implementation of all of BLAS and LAPACK, which is perfect. That would basically replace a lot of the lib/math folder in one go...

Other things that would need re-implementation are actually not too bad. I'd already re-implemented the SH & Legendre functions, so that's no issue. The FFT stuff is currently not used in the main branch, but it would be trivial to use something like kissFFT if needed. The only other sticking point is a decent multidimensional optimiser, which is currently only used in gendir, so no big deal. I've come across one decent-looking implementation of the BFGS conjugate gradient optimiser, which looks relatively simple to adapt to our needs.

So all in all, nothing too difficult to do, but would nonetheless require a fair bit of work. Question is, is this something that we'd consider important, and if so, is this something that we want done before release, or are we happy to wait till later...?

It might also be worth looking into the boost library. In particular the Math, Random and uBLAS parts might be useful. Math has special functions implemented, but apparently you already coded those. uBlas provides templated c++ BLAS. As fas as I know LAPACK is not included though... Also Eigen might be interesting for linear algebra. Pretty sure it will cover most of your linear algebra needs... Not sure if it's license is liberal enough.

Eigen looks good - it's C++98, while FLENS uses C++11 features. I'd like to move to C++11, there's a lot of features that we could use straight away, for example the Mersenne Twister random number generator, which is what we use with the GSL currently. Only issue with moving to C++11 is that it might prevent deployment on older clusters and HPC setups - but then they can always compile static binaries if required. Maybe it's time we tried it...

Otherwise, Eigen is MPL, which is what I was leaning towards anyway. We'll need to discuss the best license at some point if we're going to switch. In the short term though, I think we'll need to release under the GPL to get the software out...

As to FLENS, the license seems very relaxed. The other advantage is it's header-only, so we can simply include it within the MRtrix code if we want. I'm slightly concerned about the level of support though - it looks like Eigen has a bigger community around it, which is definitely a big advantage...

Eigen is header-only as well. I haven't used it myself, but some of our colleagues here are using it and I hear nothing but good stories.

This gives two benefits in the context of the generalised orientation overlay tool (Issue #11):

• Allow to automatically determine whether loaded image is SH with lmax=2 (6 volumes) or a tensor image (now 7 volumes)
• Allow more options in scaling of tensor glyphs

The scale and offset factors read from the headers are not applied consistently as they should be. This stems from the fact that the copy constructor for the Image::Header resets these fields to (1,0) to prevent these factors being carried through to the output data set. Unfortunately, this seems to also cause the factors to be ignored at various points...

Currently the translate option in screen capture mode operates in scanner space coordinates. This makes it unnecessarily difficult to generate a movie that e.g. rasters through the slice stack, which was the main application for this feature in 0.2.

A check box should be adequate to flag that the desired translation is provided in voxel space rather than real space. Though this still requires multiplication of the voxel size with the number of slices to get the desired effect...

Introduce my old 0.2 code for doing this; since some of the in-built direction schemes are based on this, it'd be nice to be self-consistent.

Note that these schemes shouldn't be used for DWI acquisition; the density of the distribution is not as good. Their advantage is that the definition of adjacency is superior to that of schemes derived using electrostatic repulsion.

Strange issue causing the focus crosshairs to appear behind the slice for two of the three orthoview panes, which only happens under these circumstances:

• in orthoview mode
• when displaying tracks
• with the orientation labels not shown
• when the focus is below isocentre (bottom pane) or behind isocentre (top-left pane).

To show several slices at once of the same axis. Could be useful take a quick screen shot of results for meetings etc.

Features could include:

• User defined number of windows in x and y
• User defined spacing between slices rendered in each window
• User can still scroll through the image (ie, the image would therefore be seen to move * from one window to the next)

So FODs are not the only type of intra-voxel orientation information that one may wish to display. Some possibiliities:

• FODs
• Tensors
• Output from SH2peaks / FSL (i.e. set of XYZ vectors per voxel)
• Fixel-based outputs using sparse data format
• Dixel-based data

The theory is to have a master 'orientation overlay' tool that has the file list, 3D preview window for the selected voxel, any options that are common for all types of orientation data, and an 'orientation data type' selector that toggles between the above. The appropriate additional tools then appear depending on the type of orientation overlay selected for the currently active file. Some examples:

General options: Toggle lighting & access lighting options, preview window snap to image axes / interpolation / show axes, scaling (preview window & overlay), toggle overlay

Options specific to different types of overlay:

• FODs: lmax (preview window & overlay), LOD, hide negative lobes
• Tensors: LOD, manual colour / colour by direction / colour by first eigenvector, scale by B0 / Mean ADC / none
• XYZ vectors: Line thickness, vectors defined in real / image space
• Fixel-based data: geometry (e.g. lines, thick lines, 3D cylinders/arrows, ...), colour by direction/amplitude/value, scale by amplitude/value/unity, lower/upper threshold by amplitude/value, colour mapping
• Dixel data: basis directions source (built-in / external file / DW table; can visualise the DW shell data directly without mapping to SH first), geometry (lines / mesh surface), colour mapping

As reported by Samuel Groschel

Script does not allow passing AP / PA images as 4D images with axis 3 having dimension 1. This should be permitted; test for this and just strip the final entry from the axis dimension list, it should then not affect any further processing, and mrcat should work without a problem.

Traceback (most recent call last):
  File "/opt/mrtrix3/scripts/revpe_distcorr", line 113, in <module>
    crop_option += ' -axis ' + str(axis) + ' 1 ' + str(axis_dim-1)
TypeError: unsupported operand type(s) for -: 'str' and 'int'

Pretty sure this just needs an int() call around axis_dim, but need to test on both Python 2 and 3.

It would be nice to be able to do B1 field inhomogeneity correction within MRtrix; in particular so that eventually AFD analysis can be done entirely using MRtrix commands, but it should also ideally be used if SIFT is to be applied.

Main capabilities:

• Handle multiple ROIs in a file list
• Assign colour to each ROI, either manually or random
• Transparency (per ROI?)
• Global on/off switch & individual ROI on/off switches
• Create ROI from template image (make sure to handle 4D images sensibly - perhaps if the template image is 4D prompt the user as to whether they want a 3D or 4D mask)

Editing:

• Adjustable brush size
• Adjustable 2D / 3D brush
• Adjustable square/circular (cubic / spherical) brush
• Extra buttons e.g. undo / redo, copy contents to slice above/below, fill function

Remaining / unresolved discussion (will do my best to condense what has been discussed in length on this topic):
Need to decide how to properly handle editing of ROIs either when the view is not snap-focused, or when the ROI does not match the displayed image.
Suggestions include:

• Making the ROI the main image, using the reference image as an overlay, and potentially modifying the render order so that the ROI is not 'underneath' the reference image
• Have a button in the ROI tool that snaps the camera position to the ROI image axes to allow editing; don't allow ROI editing if the ROI image does not align with the main reference image / this explicit alignment step has not been applied

Technically MRtrix's tensor tracking isn't actually FACT, it's Euler integration. FACT implies nearest-neighbour interpolation.

In some cases it is useful to output a slice of an image volume to an image file at native resolution, rather than using the mrview screenshot tool. This can also simplify ensuring that the intensity scaling between different images is consistent.

Desired features:

• Either receive a pre-cropped image from mrconvert, or user provides -coord options to specify where they want the slice(s) to be
• If input is 4D and the 4th axis has dimension 3, output as RGB colour image
• Option to manually specify minimum / maximum image intensity (useful for outputting multiple images that should have a common colour bar, even if they don't all have the same dynamic range). Otherwise the intensity range is determined from the image data.
• Output as .tga; this won't require any code dependencies, and should be supported by more software than .pgm & .ppm
• Apply colour bar mapping to image on output
• Options to flip / swap axes (maybe a comma-separated list providing x,y axes for output image as +/- input axis indices)

This one may be a little hard to track down... Initially I thought it was only a Windows thing (get the error popup window after closing), but now it looks like Linux is segfaulting on close as well.

There's a chance that the problem is buried deep within QT somewhere; I get a lot of "Conditional jump or move depends on uninitialised value(s)" within shared libraries. Backtrace on gdb is completely useless.

Thought I'd just list what little we have, so maybe an idea comes out of it.

Got this from valgrind on Linux:

==9519== Thread 2 QXcbEventReader:
==9519== Jump to the invalid address stated on the next line
==9519==    at 0xEF562B9: ???
==9519==  Address 0xef562b9 is not stack'd, malloc'd or (recently) free'd
==9519== 
==9519== 
==9519== Process terminating with default action of signal 11 (SIGSEGV)
==9519==  Access not within mapped region at address 0xEF562B9
==9519==    at 0xEF562B9: ???

Had noticed at one point (think it was on my home Windows machine) that I'd get the crash window popping up if I opened MRview on its own, but if I provided an image path on the command-line, I wouldn't get the error window...?

May have come from moving from QT4 to QT5; I certainly wasn't getting segfaults on my work machine previously. And I seem to recall when I did my first Windows installation that I used a pre-built QT4, and I wasn't getting the error popup on close like Donald said he had with a Windows install. Edit: Yup, no segfault on QT4. Do get a whole lot of invalid reads deep within QT code though.

I've just built mrtrix3 on CentOS 6 and get the following error when launching mrview:

GLSL log [vertex shader]: 0:1(10): error: GLSL 3.30 is not supported. Supported versions are: 1.10, and 1.20

mrview [ERROR]: error compiling vertex shader

which seems a bit surprising given that OpenGL version > 3 is a requirement.

Any pointers?

I can provide the list of libraries the binary links to if required.

This option exists in 0.2's streamtrack, and needs to be ported over.

When using GM-WM interface seeding, it's possible to get bright streaks in the TDIs along the interface, due to the determination of the seed points themselves converging on particular sub-voxel locations.

It may be possible to mitigate this by perturbing each seed point by a random distance (up to, say, 1 voxel) along the plane normal to the interface, and re-optimising to find the interface again. Would have to balance the benefits of this approach against the processing overhead.

Currently, mrcalc uses a stack-based processing interface. So for instance, the command to compute the function exp(2-in.mif/4.7) is:
$ mrcalc 2 in.mif 4.7 -div -sub -exp out.mif

This could be replaced with:
$ mrcalc "exp(2-a/4.7)" in.mif out.mif

Syntax parsing could be based on the shunting yard algorithm or similar.

Functions that would need explicit handling:

• Ternary operator: test?iftrue:iffalse
• Complex numbers: a+b*i

Currently, if a multi-threading pipe functor returns false, it causes that instance of the pipe functor to terminate and unregister from the queues. This isn't necessarily useful behaviour; if there's something seriously wrong that needs to cease processing an Exception could be thrown instead.

The alternative is to re-interpret the return value of the pipe functor to mean 'don't send anything to the output queue'. This may be different behaviour to source and sink functor returns, but the current pipe behaviour is not actually of any use.

Listing this here so that people know I'm aware of the issue and don't waste their time trying to explain it.

If SIFT is used to filter a tractogram, and a high-resolution TDI is then generated based on the filtered tractogram, there's an unusual grid-like artefact where the TDI is brighter along the diffusion voxel edges than through the middle of the voxels. It's particularly prominent anywhere where the streamlines run parallel to the diffusion voxel grid.

Some observations I've made in trying to find the source of this problem:

• Initially thought it might be related to the streamline-to-voxel mapping code, specifically the quantification of length through the voxel. E.g. if this quantification is wrong, a streamline that cuts through half of two voxels may appear longer than a streamline that cuts through all of one voxel. Upgraded the mapping code to do an accurate chordal approximation of length, and have quadruple-checked the mapping code for bugs (in particular making sure that if a streamline leaves and re-enters a voxel, both segments contribute).
• If the SIFT model cost function is changed from quadratic from linear, i.e.
  PM.(u.TD - FOD)^2 to PM.|u.TD - FOD|, the problem essentially disappears; this is however detrimental to the filtering process itself. Initially I thought this was related to the fact that the cost function change was calculated using a finite difference approach rather than partial derivatives, but changing to the latter didn't fix the problem either.
• If the streamline lengths through the voxels is ignored entirely (i.e. every streamline contributes unary length to every voxel it traverses), the problem is vastly reduced; but again, this is detrimental to the filtering.
• It's not related to the word-sharing used to reduce RAM usage in storing the streamline visitations.
• Resorting to an old-school Hermite upsampling of the streamline and counting points within each voxel rather than the voxel-edge mapping and length quantification doesn't solve the problem.
• Removing the scaling of the cost function gradient per unit streamline length before sorting the gradient vector doesn't solve the problem.
• Adding or subtracting streamline length from every voxel traversed (trying to find a bias toward streamlines encountering many voxel edges and therefore traversing more voxels) doesn't influence the artefact.

Along with the author and usage information printed on each command's help page, it should be possible to add an optional REFERENCES field; any journal article(s) that should be citing based on the usage of the command (or even due to usage of a particular command-line option) could be documented here.

Not really going to be required for diffusion applications as far as I can tell; but that won't stop someone from trying to load one and probably causing a segfault.

It's just a modified header with longer integer / float lengths, no added fields, so shouldn't be too hard to support.

http://www.nitrc.org/forum/message.php?msg_id=3738 http://nifti.nimh.nih.gov/nifti-2

This returns a bool; but currently it's true if outside the image bounds, and false if inside.

Need to be very careful that all invoking code is updated correctly.

• Extra checkbox on the interface to toggle the geometry type
• Control point size using 'line thickness' slider

Hello!

I just encountered this issue on OSX 10.9.1 with QT 5.2.0:

Congratulations on the release, everything looks great!

I see the wlogfit is no longer an option for the DTI fit.

Our recent paper (http://www.ncbi.nlm.nih.gov/pubmed/23684865) shows that if the weights are set based on an unweighted fit and not based on the raw DWI data, the wlogfit in most cases outperforms the nonlinear DTI fit and is much faster.

It might make sense to include this as the default, instead of the nonlinear fit.

There is currently no centralised (or otherwise) documentation of the myriad config file options that have been added over time. I'm thinking this could be fixed by adding easily-parsed comments, as we do for the MRView batch commands (see cmd/mrview.cpp, line 25). This could be piped straight into a header file, e.g. src/doc/config_options.h for inclusion in the documentation.

Currently mrconvert uses cfloat internally to perform the copy from input to output images. This may result in a loss of precision in some rare use cases. It should be possible to either template the buffer creation, or simply code branch, based on the output data type.

Currently any provided streamline weights are loaded into a local Math::Vector before processing can commence. This can cause a long pause at the start of a program, and unnecessarily takes up RAM.

Might be better to just construct a std::ifstream, and load one weight at a time as the reader's functor is called.

It will mean that the number of weights can't be compared to the count from the .tck file header information, but that situation can just be downgraded from an exception to a WARN() once that point in the data is reached.

The majority of ProgressBar calls add trailing dots to the text message. However in a few spurious cases this is not done, and it kinda looks weird at the command line.

Move the concatenation of the trailing dots to the string to within the ProgressBar class, and remove from all constructor calls.

mrconvert with the -coord option is often used to extract a single volume from a 4D image series. In this case one is left with a 4D image, where the dimension of the fourth axis is 1. Am wondering if the default behaviour should be to remove trailing unary axes.

• Command is still using the old multi-threading interface.
• It seems to be using the one normalisation boolean flag both for b=0 normalisation on image load, and min-max normalisation after FRT. These should be two different options.

As mentioned by Romain Valabregue on the MRtrix mailing list, the ordering is not preserved for certain operations. For example:

mrinfo data_B2000.nii 
  Data strides:      [ -1 2 3 4 ]

dwi2tensor data_B2000.nii -grad grad.b dti.nii

mrinfo dti.nii 
  Data strides:      [ 2 3 1 4 ]

which is clearly not what was expected.

Options:

• Automatically output DW scheme in bvecs/bvals format if present in the image header on output file creation
• Automatically load DW scheme into header if bvecs/bvals are found and the number of image volumes matches the number of gradient directions (alternatively, get_DW_scheme() could be moved from an explicit function call to being part of Image::Header construction)

When installing on a new machine, following the exact Wiki instructions, the viewer and other Qt-based components won't build.

From what I figured out, the precompiled version of Qt 5.2.1 (the most recent version, hence the default install), is configured for mac 10.8, whereas some of it's components don't link under 10.9 unless you explicitly configure the correct path for the build. (See this and this article)

The problem is easily fixed by opening up the config.default file and manually changing ".../.../MacOSX10.8.sdk" into ".../.../MacOSX10.9.sdk" in both the qt_cflags and qt_ldflags variables. However, I have no clue whatsoever on how to set this permanently (?).

Alternatively, users can work with Qt 5.2.0, in which the issue does not occur.

Current implementation will search for files called bvecs/bvals co-located with the DWI data, and use them if found. Otherwise, it'll look for files with the same prefix as the DWI image and the _bvecs/_bvals suffix. This is fine, but there is actually no set convention as to what these files are called. This means there is no way to supply an FSL encoding if the name doesn't match that expected. Maybe we should add an additional option like -fslgrad to supply both filenames, which would get around the problem. It would also allow us to remove the autodetection steps currently taken to try to discover these encoding files, which would simplify the code somewhat and reduce the chances of any unexpected side effects...

This could either be an extension of the .mif format to allow delimited text, a new image format & handler that imports the text data into a local BufferScratch for access using an Image::Voxel class, or a binary that converts raw text into a supported image format.

Just been reading up on this myself; bits of it look like coding nightmares, other bits look super useful. Disadvantage (apart from the work in going through and updating relevant code) is that HPCs may not compile it, but static compiles could be used instead.

The current vector plot only renders when snap-to-axes is on. This is because off axis rendering of fixels is not possible due to lack of interpolation.

If a vector/fixel image is overlaid on an image of different resolution or orientation, we currently get undesired results (since vector/fixel rendering is indexed by slice).

Do we need to support the ability to overlay vector plots on other images? Rendering on an image of different resolution is easy, however when the image has a different grid orientation it is problematic.

One option would be to somehow have a snap-to-vector-image-grid option and interpolate the image underneath, however this might be a little unintuitive to use.

I guess if people really want to overlay vectors on another image, then they could just regrid that image at the vector image resolution.

Any thoughts?

Currently, the DICOM import code will scale the b-value by the squared amplitude of the DW gradient. This is to allow correct interpretation of the DW scheme when using custom multi-shell diffusion encodings (on Siemens in particular). However, in the latest version of the DICOM standard (particularly the multi-frame extension), the interpretation is clearly that the gradients specify the direction, and the b-value should be the actual b-value. These two interpretations clearly clash, so we need to do something about it...

I think the simplest is to move the b-value scaling operation out of the DICOM import code, and into the get_valid_DW_scheme() function. This would at least ensure that the information in the converted headers is a faithful representation of what was in the original DICOM headers, so other (possibly 3rd party) applications have the most accurate information. If people need to tweak the DW encoding manually, they can also do so in the knowledge that what they've been provided with hasn't been modified.

As to how to handle these schemes in MRtrix, I think we can add an additional command-line option to the DW gradient OptionGroup to specify whether b-values should be scaled by the gradient amplitude or not. The gradient amplitudes will always be normalised either way. For those cases where applications need access to the unmodified DW scheme, we'll make sure the get_DW_scheme() function returns just that.

How does that sound?

The copyright notice on all project files date back to the original release of MRtrix in 2008. They probably need to updated when this new version is released. Not sure how it's supposed to be done - maybe:

Copyright 2008,2013 Brain Research Institute, Melbourne, Australia and King's College London, UK

But when the time comes, the simplest thing to do will probably be to strip out all of these comments and preprend the same updated notice to all files...

(As reported by Daan Christiaens)

1. Tractography panel: setting the line thickness does not work, no matter what I do with the slider.
2. If I load a new track file in the GUI, it doesn't appear until I select it in the list. The box to the left of the file name is checked, but it only shows up if I click on the name.
3. If I load a track file on launching the viewer, using mrview image.mif -run tractography.load tracks.tck (really great that we can do this now!), I get an error:

mrview [ERROR]: /mrtrix/mrtrix3/blob/master/unknown format for image "tracks.tck"
mrview [ERROR]: /mrtrix/mrtrix3/blob/master/error opening image "tracks.tck"
mrview [WARNING]: /mrtrix/mrtrix3/blob/master/batch command "tractography.load" unclaimed by main window or any active tool - ignored

1. ODF display works only up to order 8. For order 10, I get nothing but a mess of black lines in the side panel.
2. With the apple "magic mouse", I can't scroll from one slice to the next. The arrow keys and an old non-apple mouse work fine. Despite that, I found the viewer very useable with the magic mouse, thanks to the separate "mouse modes". Definitely a large improvement over mrtrix2 :)
3. If I mistakenly hold the Ctrl button while using the mouse, the terminal fills with messages "QNSView mouseDragged: Internal mouse button tracking invalid (missing Qt::LeftButton)". Due to the keyboard layout on Mac, I get this quite a lot and it can get a little annoying.

Think the main feature here to port across will be the cropping based on a mask image.