'Tckedit -mask' issue

1

Dear experts,
First of all lI would like to greet the whole MRtrix community. Since I am new here, I hope I will not compromise myself already with first post.
The issue I encountered is quite simple - the discrepancy in the reported and true number of streamlines in file after ‘tckedit’ command execution - however I did not find a solution neither in documentation nor in any of topics.

Ad rem:
I have a file with 4136 streamlines (according to tckinfo, double checked with tckedit and tckedit -inverse)
I do run the tckinfo command with -mask option

tckedit File.tck -mask ../truncate.mif Truncated_file.tck
tckedit: [done]     4136 read,     4126 written

Seems fine. However number of streamlines reported by the tckinfo differs from given 4126.

tckinfo Truncated_file.tck 
***********************************
  Tracks file: "Truncated_file.tck"
    count:                5569
    downsample_factor:    3
    fod_power:            0.25
    init_threshold:       variable
    lmax:                 8
    max_angle:            variable
    max_dist:             149.098
    max_num_attempts:     100000000
    max_num_tracks:       1000000
    max_seed_attempts:    50
    max_trials:           1000
    method:               iFOD2
    min_dist:             10
    mrtrix_version:       0.3.12-1058-ga251a1ae
    output_step_size:     0.2
    rk4:                  0
    samples_per_step:     4
    seed_dynamic:         /.../fiber_orientation_distribution.nii
    sh_precomputed:       1
    sift_mu:              0.0187893
    source:               /.../fiber_orientation_distribution.nii
    step_size:            0.2
    stop_on_all_include:  0
    threshold:            variable
    timestamp:            1465815990.7710771561
    total_count:          5579
    unidirectional:       0
    ROI:                  mask ../truncate.mif
    ROI:                  mask ../truncate.mif

To make things more interesting, when I further edit the Truncated_file.tck, I have an access to 2368 streamlines

tckedit Truncated_file.tck -number 3000 something.tck 
tckedit: [.   ]        0 read,        0 written
tckedit: [WARNING] User requested 3000 streamlines, but only 2368 were written to file
tckedit: [done]     5569 read,     2368 written

I will be very thankful should someone explain me what is actually happening. I know this is simple issue and it is possible made somewhere mistake, but since I am trying to do the quantitative analysis it is important for me to have the numbers right.

2

Hi there,

The -mask option can behave slightly differently to the other available options in tckedit. This is because it’s possible for an individual streamline to enter and exit the mask region(s) more than once, and therefore produce more than one output streamline per input streamline. The code is written explicitly to deal with this situation; but it’s possible that either the running count provided in the progress message by tckedit is not properly reflecting this, or the streamlines data is not being correctly formatted in the output file, or possibly both. Indeed the fact that your second call to tckedit is writing less tracks than it reads would suggest that the output when using the -mask option contains some empty tracks.

I’ll look into this and get back to you.

Rob

3

OK, so I found a couple of little bugs in how tckedit was applying the masking. This was affecting how many tracks were being written to the output file, over and above the discrepancy introduced by chopping individual streamlines into multiple segments. Re-checking the track file subsequently using tckedit was also being deceiving, as the original minimum length criterion from tracking was being re-applied even though nothing was specified at the command-line, and many of the cropped track segments were not long enough. I’ve also made tckedit provide the number of track ‘segments’ written to the output file as part of its progress message.

Alternatives for checking the contents of track files include tckinfo -count (which will manually check the number of tracks in the file, over and above what’s reported in the header), and tckstats (which calculates statistics on streamlines length, and will also warn about the presence of null streamlines, which is often indicative of an error).

Thanks for the report; the fixes will be included as part of a reasonably-sized update that will hopefully get pushed out within the next 24 hours.

Rob

4

Dear Rob,
thank You very much for so swift looking into this issue. I should have figured out the reason for possible increase in output file streamlines count, but this minimum length criterion bug is quite tricky. Thank You for providing an explanation and hints for future checking - I will remember about those commands.
I also would like to mention that I really admire the effort You all put in MRtrix development and I appreciate Your responsiveness a lot.
Glad that the report of mine could be of help.

1 Like