I just noticed this hadn’t been answered, thought I’d follow up in case you were still stuck?
I’m not sure exactly what you’ve done (it would be better to copy & paste the exact commands used and their full output so we can avoid any confusion), but it looks like you’ve essentially only run warpinit using the nonlinear_acpc_dc2standard.nii.gz file as the template, and then provided that file as the warp information to tcknormalise. This won’t do anything, since the warpinit command only generates an identity warp (i.e. no warp as such) in the same space as its template argument - at this stage there is no warp information at all.
Normally, you’d need to follow the instructions on this page - but this requires access to the software used to perform the registration in the first place. However, in this case you might be able to use the transformation information provided directly, although that’ll depend on exactly what information is contained in that transformation file.
The file you refer to seems to be MNINonLinear/xfms/acpc_dc2standard.nii.gz (?), and appears to consists of a displacement field. Thankfully, recent versions of MRtrix3 include the warpconvert command, which can convert that to the requisite deformation field required by tcknormalise. However, what I’m not sure about is the exact convention assumed for the HCP-supplied displacement map. Specifically: is the displacement in millimeters or voxel units? is the displacement vector relative to the image axes, or to scanner standard space? I couldn’t find a clear description from a quick cursory look through.
Thankfully, this image seems to be scanner aligned, so there should be no difference between scanner and image space (at least on the example I’ve looked at). Note the identity transform in the output of mrinfo:
$ mrinfo acpc_dc2standard.nii.gz
************************************************
Image: "acpc_dc2standard.nii.gz"
************************************************
Dimensions: 91 x 109 x 91 x 3
Voxel size: 2 x 2 x 2 x 1
Data strides: [ -1 2 3 4 ]
Format: NIfTI-1.1 (GZip compressed)
Data type: 32 bit float (little endian)
Intensity scaling: offset = 0, multiplier = 1
Transform: 1 0 0 -90
-0 1 0 -126
-0 0 1 -72
comments: FSL5.0
However, there may be a inversion for the x component, depending on exactly what the convention is (due to the reversed stride for the x axis). Also, the voxel size is 2mm in this image, so displacements may be off by a factor of 2 is they are assumed to be in voxel units (since warpconvert will assume they are provided in millimeter units).
So if the acpc_dc2standard.nii.gz image does provide displacements in scanner space, in units of millimeters, all you’d need to do is:
warpconvert acpc_dc2standard.nii.gz -type displacement2deformation warp.nii
and use the resulting warp.nii image as the transformation for tcknormalise. However, if the displacements are actually in voxel units, you’d need to scale them by a factor of 2 first:
mrcalc acpc_dc2standard.nii.gz 2 -mult - | warpconvert - -type displacement2deformation warp.nii
If the x direction is inverted, you’d need to invert the x component of the displacement field first. Simplest way to do that would probably be:
mrconvert acpc_dc2standard.nii.gz tmp-[].nii
mv tmp-0.nii x.nii
mrcalc x.nii -neg tmp-0.nii
then:
warpconvert tmp-[].nii -type displacement2deformation warp.nii
or if on top of that the displacements are in voxel units:
mrcalc tmp-[].nii 2 -mult - | warpconvert - -type displacement2deformation warp.nii
So you’d need to try some of these commands and see whether the resulting normalised tracks correspond to what you’d expect…