List of seeds | -seed_sphere | multiple seeds

Dear all,

I would like to generate multiple tracts from spherical seeds in the same participant using the -seed_sphere option in tckgen.

Is there any way to input a list of seeds rather than having the command loop? A loop causes all of the files to load in and out of memory every time, it feels as though there should be a more efficient way of doing this.


No, I’m afraid not. However:

Actually, the loop probably is just as efficient, provided one condition is met: that your data are suitable for direct memory-mapping, obviating the need for an explicit load to RAM. For tckgen, the data will be memory-mapped if:

  • the data reside in a single file;
  • the data are not compressed;
  • the data are in native-endian 32-bit floating-point format;
  • the data are stored in volume-contiguous order.

To do this, convert your data to .mif with these options:

$ mrconvert fod_in.mif -datatype float32 -stride 2,3,4,1 fod_out.mif

Then try running tckgen on that - you should find there is no data load overhead whatsoever.

thanks very much for the info!

One last question on this topic:
I use a .nii file as an exclusion mask, can I just do the same to that?

mrconvert exclusion_mask.nii -datatype float32 -stride 2,3,4,1 exclusion_out.mif

Also, in general, do I need to ensure that all images have the same strides or is MRTrix capable of recognizing any combination?

I think this may have been slightly mis-interpreted:

Is there any way to input a list of seeds rather than having the command loop?

No, I’m afraid not.

I think what @jdtournier means is that you can’t provide “a list of seeds” as in “a list of points in 3D space”. However I suspect @cbajada’s intent was a list of spherical seeds.

So instead of:

tckgen FODs.mif tracks1.tck -mask mask.mif -seed_sphere x1,y1,z1,r1
tckgen FODs.mif tracks2.tck -mask mask.mif -seed_sphere x2,y2,z2,r2
tckgen FODs.mif tracks3.tck -mask mask.mif -seed_sphere x3,y3,z3,r3
tckedit tracks1.tck tracks2.tck tracks3.tck all_tracks.tck

, you can, if you want to, just do:

tckgen FODs.mif all_tracks.tck -mask mask.mif -seed_sphere x3,y3,z3,r3 -seed_sphere x2,y2,z2,r2 -seed_sphere x3,y3,z3,r3

The relative number of seed points drawn from each input seed mechanism is proportional to the volume of each seed. You can even mix & match spherical & image-based seeds if you want to.

mrconvert exclusion_mask.nii -datatype float32 -stride 2,3,4,1 exclusion_out.mif

Not really, for a few reasons:

  • The purpose of the “-stride 2,3,4,1” option is to make volumes contiguous in memory, but a processing mask should only contain a single volume;
  • Mask images should be interpreted by the code as bitwise data, so saving as floating-point is not useful;
  • Mask images specifically within tckgen are always explicitly loaded into RAM. They are handled slightly differently to the standard image back-end code.

Also, in general, do I need to ensure that all images have the same strides or is MRTrix capable of recognizing any combination?

It’ll accept mixed images, as long as the axes obey the RAS coordinate convention (if the images don’t agree on which direction is positive, you’re at risk of getting erroneous behaviour). The strides simply determine how the image data are arranged into a 1D list of numbers, which is how they are stored on file / in RAM. Indeed in many MRtrix3 commands (including tckgen), different images don’t even have to be defined on the same image grid: They can have different dimensions / transforms / voxel sizes.

Indeed, if the intention is to seed from multiple (spherical) ROIs to generate a single track file, then these ROIs can simply all be provided in the same command - I use that trick quite often to quickly generate streamlines from more extended regions that can’t easily be represented as a single spherical ROI.

However, given the OP’s original question:

I understood that to mean that the task is to generate individual track files, each seeded from a different spherical ROI, while avoiding the potentially large overhead of a full data preload. I guess by now we’ve covered all possibilities… :wink:

@rsmith covered that already, but I’d just like to add a couple of clarifications:

Probably more accurate to state they will be re-cast into boolean images internally - tckgen will accept floating-point images as ROIs, and assume voxels with intensity above 0.5 are true, the rest false. But as @rsmith says, there’s no point in converting your ROIs to float…

MRtrix should interpret all images correctly, without exception - as long as they conform to their respective standard. The only potential exception to this, alluded to by @rsmith here, are old-style Analyze images (.hdr/.img), because that standard is poorly defined. SPM used to assume a left->right (neurological; RAS) storage convention, whereas Analyze (the orignal package from the Mayo clinic) and FSL assumed a right->left (radiological; LAS) storage convention. There’s no way to determine which convention was used from the image alone, which made using the format very problematic (some information about this here for the interested reader). The NIfTI standard (which builds on the Analyze format) is very specific about its storage convention: it has to be RAS (neurological), so there’s no problem there.

Indeed, you have now covered all possible interpretations of my question, thanks very much. However, @jdtournier did interpret the question correctly. Thanks once again!