[Mrtrix-discussion] MRtrix version 0.2.6 released - PLEASE UPGRADE NOW

[Donald Tournier]

Dear MRtrix users,

Kerstin Pannek has just alerted me to a major bug in the MRtrix
"streamtrack" program, which causes incorrect tracking results for any
DWI data set acquired at an angle to the scanner axes. Basically, this
causes the tracks to veer off course by an angle equivalent to the
angle applied to the image axes. Since few DWI data sets are ever
acquired in a strongly oblique plane, this issue has gone unnoticed
until now.

This problem is now fixed in the new release. Users are STRONGLY urged
to upgrade immediately, and to regenerate any tracking results
produced from data sets acquired obliquely. I apologise for any
inconvenience this may cause. I have included a few instructions below
to ease the process.


This release also includes a few other minor bug fixes, as well as
some performance enhancements, including:

- parallel processing support for streamtrack (see the documentation
for instructions on how to configure your system to use
multi-threading);
- enhanced performance for tracks2prob;
- reduced memory usage when displaying tracks;
- a new screen capture feature in the viewer.

The new release can be downloaded from here:
http://www.nitrc.org/frs/?group_id=128&release_id=435


To find out which data sets were acquired obliquely, use the mrinfo command:

> mrinfo dwi.mif

and look at the "transform" entry. For an unaffected data set, the
diagonal entries would be "1", and would look like this:
  Transform:               1          0           0                 -116.1
                        0           1           0       -89.44
                        0           0           1       -64.27
                        0           0           0           1

whereas for an oblique data set, the transform might like this:
  Transform:               0.9999   6.887e-09    -0.01564      -116.1
                        -0.001242      0.9968    -0.07943      -89.44
                          0.01559     0.07944      0.9967      -64.27
                                0           0           0           1

There is no need to regenerate the CSD results, since these are not
affected. The *.tck files will need to be regenerated though, along
with any other data derived from them. You can find out what
parameters where used to produce the tracks using the "track_info"
command, for example:

> track_info whole_brain.tck
***********************************
  Tracks file: "whole_brain.tck"
    count:                100000
    init_threshold:       0.2
    lmax:                 10
    max_dist:             200
    max_num_tracks:       100000would
    max_trials:           50
    method:               SD_PROB
    min_curv:             1
    min_dist:             10
    sh_precomputed:       1
    source:               CSD10.mif
    step_size:            0.2
    threshold:            0.1
    total_count:          117518
    unidirectional:       0
    ROI:                  seed wm.mif
    ROI:                  mask mask.mif

Hopefully this will supply enough information to regenerate the tracks.


Although I hope that in practice this issue will not affect most
people's results significantly, I do think it is necessary to
regenerate the results, if only to verify the validity of the original
results.

With all my apologies,

Donald.


-- 
Jacques-Donald Tournier (PhD)
Brain Research Institute, Melbourne, Australia
Tel: +61 (0)3 9496 4078