tckmap options

1

Hi,
I am using tckmap for my analysis. I couldn’t find the meaning/difference between the options ‘scalar_map’ and ‘scalar_map_count’. Please suggest if there is any documentation that explains these options.

-contrast type define the desired form of contrast for the output image
Options are: tdi, length, invlength, scalar_map, scalar_map_count, fod_amp, curvature, vector_file (default: tdi)

2

Welcome Tonima!

Yes that difference is not very well communicated. The latter is only really in place to permit masking when performing the TW-FC method. Basically:

  • “scalar_map” samples values from an associated image and (in conjunction with the track-wise statistic) provides each streamline with a scalar value reflecting the image values underlying the streamline trajectory;

  • “scalar_map_count” instead assigns to each streamline either a 1 or a 0 depending on whether or not a non-zero value is measured from that image anywhere along the streamline, and can therefore be used to generate an image reflecting the “count” of streamlines that actually contribute to an image generated using the former.

However I’ve never been happy with this interface in the slightest. In retrospect the latter should have instead been achieved as a track-wise statistic within the TWI framework. Longer-term I’m intending on changing the relevant parts of the tckmap interface more drastically; but hopefully that at least explains the options that are there now.

Cheers
Rob

1 Like
3

Hi Rob, thanks for the explanation. I am back with another question now :slight_smile:

For the -fwhm_tck option for tckmap, how are the voxels handled that correspond to the end of tracks? I am interested about the tckmap generated contrast (using scalar images) where the fibre tracks end at the WM-GM interface. Does this option consider the voxel at the centre of the smoothing kernel? What would teh operation be if that is at the end of track?

Many thanks,
Tonima

4

For the -fwhm_tck option for tckmap, how are the voxels handled that correspond to the end of tracks?

Firstly, to be clear, the operation underlying the -fwhm_tck option does not operate on voxels; it operates on the streamline itself. Whatever quantitative value is derived per vertex is smoothed based on the distances between vertices; it is only once each vertex is then mapped to a voxel that this smoothed value “comes along for the ride” in order to contribute appropriately to the final image.

So following this, at the streamline endpoints (not the voxels they are assigned to), the smoothing kernel that is centred at that vertex simply has half of the kernel truncated, so looks like a half-normal distribution, The resulting values are still smooth rather than decreasing in magnitude toward the streamline ends, because the integral of the applied kernel is used to normalise the resulting value at each vertex code.

Hope that answers your question; there’s bits in there that don’t quite make sense to me, so if there’s something out standing you might need to try to rephrase.
Rob

5

Hi Rob,
Thanks for your reply.

Many thanks for your answer, that’s what I was assuming.

I have one more question on this. When using the “ends_only” option for tckmap,

  • does it do the trackmapping for the full length of track and projects the values only at the endpoints of tract or
  • does it only show the values at the end points from the contrast provided and do no do any track mapping?

Many thanks,
Tonima

6

I have one more question on this. When using the “ends_only” option for tckmap,

  • does it do the trackmapping for the full length of track and projects the values only at the endpoints of tract or
  • does it only show the values at the end points from the contrast provided and do no do any track mapping?

That’s … actually a really good question. I’d never even recognised the ambiguity here.

So what will happen currently is:

  1. The whole streamline will be used when sampling from an underlying image;
  2. If -stat_tck gaussian is used, smoothing will be applied to data across the whole streamline; if not, the single scalar TWI factor for each streamline (as specified by -stat_tck) will be computed based on data from the entire streamline;
  3. Only at the point of mapping streamlines to voxels does the influence of -ends_only kick in, with only the two endpoints of each streamline being mapped to the voxel grid rather than the entire streamline (and this is the case both for -stat_tck gaussian and for all other use cases).

There are dedicated -stat_tck options for only sampling quantitative values at the streamline endpoints in the derivation of the TWI factor per streamline. So that does at least give some indication that the -ends_only option applies only to the mapping to the voxel grid, and not to the derivation of the TWI factors per streamline. But it’s certainly not obvious.

This question actually gives credence to my proposed software changes here. By demanding that the TWI factors be pre-computed before running tckmap, the exact manner in which those values are derived is wholly under user control. tckmap is no longer responsible for deriving such factors, and is only responsible for the mapping to the voxel grid, in which case the influence of requesting that only the endpoints be “used” is more clear.

Cheers
Rob

7

Thanks Rob! That helps a lot :slight_smile: