Spherical Harmonics
For Spherical Deconvolution (SD) as implemented in MRtrix, processing is done in the Spherical Harmonic (SH) basis; this mathematical formulation provides a smooth representation of data distributed on the sphere. When we do SD, the resulting Fibre Orientation Distributions (FODs) are written to an image. These FOD images contain coefficients in this SH basis, that when interpreted correctly, produce the FOD butterflies we all know and love. If you’ve ever looked at the raw image volumes from an FOD image, you’ll know that all but the first one are basically not interpretable.
What are Spherical Harmonics?
Spherical harmonics are special functions defined on the surface of a sphere. They form a complete orthonormal set and can therefore be used to represent any well-behaved spherical function. In many ways, they are the equivalent to the Fourier series for functions defined over spherical (rather than Cartesian) coordinates. They are defined as:
with integer order \(l\) and phase \(m\), where \(l \geq 0\) and \(-l \leq m \leq l\) (note that the terms degree and order are also commonly used to denote \(l\) & \(m\) respectively), and associated Legendre polynomials \(P_l^m\). The harmonic order \(l\) corresponds to the angular frequency of the basis function; for example, all \(l=2\) SH basis functions feature 2 full oscillations around some equator on the sphere. The harmonic phase \(m\) correspond to different orthogonal modes at this frequency; e.g. where the oscillations occur around a different plane.
Any well-behaved function on the sphere \(f(\theta,\phi)\) can be expressed as its spherical harmonic expansion:
For smooth functions that have negligible high angular frequency content, the series can be truncated at some suitable maximum harmonic order \(l_\text{max}\) with little to no loss of accuracy:
The spherical harmonic series therefore provides a compact represention for smooth functions on the sphere. Moreover, due to its formulation, it has many compelling mathematical properties that simplify otherwise complex operations, including notably spherical (de)convolution.
Formulation used in MRtrix3
Due to the nature of the problems addressed in diffusion MRI, in MRtrix3 a simplified version of the SH series is used:
The data involved are real (the phase information is invariably discarded due to its instability to motion), so we can use a real basis with no imaginary components.
The problems involved all exhibit antipodal symmetry (i.e. symmetry about the origin, \(f(\mathbf{x}) = f(-\mathbf{x})\)), so we can ignore all odd order terms in the series (since these correspond to strictly antisymmetric terms).
The SH basis functions \(Y_{lm}(\theta,\phi)\) used in MRtrix3 are therefore:
Storage conventions
Images that contain spherical harmonic coefficients are stored as 4-dimensional images, with each voxel’s coefficients stored along the fourth axis. Only the even degree coefficients are stored (since odd \(l\) coefficients are assumed to be zero).
The SH coefficients \(c_{lm}\) corresponding to the basis functions \(Y_{lm}(\theta,\phi)\) are stored in the corresponding image volume at index \(V_{lm}\) according to the following equation:
\(V_{lm} = \frac{1}{2} l(l+1) + m\)
The first few volumes of the image therefore correspond to SH coefficients as follows:
Volume \(V_{lm}\) |
\(c_{lm}\) |
---|---|
0 |
\(l=0\), \(m=0\) |
1 |
\(l=2\), \(m=-2\) |
2 |
\(l=2\), \(m=-1\) |
3 |
\(l=2\), \(m=0\) |
4 |
\(l=2\), \(m=1\) |
5 |
\(l=2\), \(m=2\) |
6 |
\(l=4\), \(m=-4\) |
7 |
\(l=4\), \(m=-3\) |
… |
… |
The total number of volumes N in the image depends on the highest angular frequency band included in the series, referred to as the maximal spherical harmonic order \(l_\text{max}\):
\(N= \frac{1}{2} (l_\text{max}+1) (l_\text{max}+2)\)
\(l_\text{max}\) |
\(N\) |
---|---|
0 |
1 |
2 |
6 |
4 |
15 |
6 |
28 |
8 |
45 |
10 |
66 |
12 |
91 |
… |
… |
Representation of response functions
The response functions required when performing spherical (de)convolution correspond to axially symmetric kernels (they typically represent the ideal signal for a coherently aligned bundle of fibres aligned with the \(z\) axis). Due to this symmetry, all \(m \neq 0\) coefficients can be assumed to be zero. Therefore, response functions can be fully represented using only their even order \(l\), zero phase \(m=0\) coefficients (the so-called zonal harmonics).
Response functions are stored in plain text files. A vector of values stored on one row of such a file are interpreted as these even \(l\), \(m=0\) terms. The number of coefficients stored for a response function of a given maximal harmonic order \(l_\text{max}\) is \(1+l_\text{max}/2\).
Response files can contain multiple rows, in which case they are assumed to represent a multi-shell response, with one set of coefficients per b-value, in order of increasing b-value (i.e. the first row would normally correspond to the \(b=0\) ‘shell’, with all \(l>0\) terms set to zero). The b-values themselves are not stored in the response file, but are assumed to match the values in the DW encoding of the diffusion MRI dataset to be processed.
Differences with previous version of MRtrix
An important difference between the old (0.2.x) and new (0.3.x and 3.x.x) versions of MRtrix is a change to the Spherical Harmonic (SH) basis functions. This change has important consequences for data that may be used interchangeably between the two versions.
Important: note that although it is possible to use and display FODs generated using MRtrix 0.2.x in the newer MRtrix3 applications (and vice-versa), the FODs will NOT be correct. Moreover, it is very difficult to tell the difference by simple visual inspection - the FODs may still look reasonable, but will give incorrect results if used for tractography or in quantitative analyses. To ensure your images are correct, you should use the shbasis application included in MRtrix3, as described below.
The problem
Here’s where it gets tricky. In all previous versions of MRtrix, there was a ‘bug’ in the SH basis functions. Mathematically, the basis was ‘non-orthonormal’ (although still orthogonal), due to the ommission of the \(\sqrt{2}\) terms in the definitions above. You don’t necessarily need to know what this means, just appreciate that this formulation of the basis, although entirely self-consistent, was not optimal for some operations.
This ‘bug’ didn’t actually cause any problems; the previous version of MRtrix was self-consistent in its handling of the issue throughout the code. It was annoying for any users transferring data between MRtrix and other packages though. For the release of the new MRtrix3, we have decided to correct the underlying error in the SH basis once and for all, as there are various mathematical operations that are greatly simplified when the basis is orthonormal. This does however introduce a problem for anyone that has done prior image processing using the old MRtrix 0.2 and wants to be able to use that data with MRtrix3: if you have image data that was generated using the old SH basis, but read it using MRtrix code that was compiled using the new SH basis, the data will not be interpreted correctly.
The solution
There is a solution, but it takes a bit of manual labour on your part.
We have provided a new command called shbasis
. This command
will read your image data, and tell you which SH basis it thinks your
image data are stored in (or if it’s unable to make this decision).
Furthermore, it includes a command-line option for changing the SH
basis of the underlying image data: -convert
. The most important
choice for this option is -convert native
. This option identifies
the SH basis that MRtrix3 is compiled for (this is the
new orthonormal basis by default); and if the image data is not
currently stored in this basis, it modifies the image data in-place so
that it conforms to the correct basis.
Any data that you generate after this update has occurred will
automatically be produced in the new SH basis, and therefore will not
need to be converted using shbasis
. However if you are uncertain
whether or not a particular image does or does not need to be converted,
shbasis
can always be used to verify whether or not the image data
are in the correct SH basis; and if you provide the -convert native
option despite the image data already being in the new SH basis, no
modification of the image data will take place.
My recommendation is therefore as follows. When you commit to using the
new version of MRtrix, you should go through all of your diffusion
image data on all systems that you use, and run
shbasis -convert native
on all images that contain spherical
harmonic data (only FOD images; raw DWIs / response functions / TDIs /
etc. do not need to be converted).
Also: Remember that data previously generated will not be
interpreted correctly by MRtrix3 commands without the SH basis
conversion? The same applies in the other direction. So if you load
FOD images that have either been generated using MRtrix, or have
been previously converted using shbasis
, commands from the previous
version of MRtrix (0.2) won’t interpret them correctly. We hope that
once we have feature completeness in MRtrix3, the old version
will no longer be necessary, and therefore this will not be a problem.
Dealing with problematic data
In some circumstances, the shbasis
command will give an error
something like this:
shbasis [WARNING]: Cannot make unambiguous decision on SH basis of image csd.mif (power ratio regressed to l=0 is 1.58446)
shbasis
uses a data-driven approach to automatically determine the
SH basis that the image data are currently stored in; however a number
of issues can arise that lead to a breakdown of the numerical assumption
that it is based on, and it can no longer make this decision.
If this occurs, but you are confident that your image data are in the
old non-orthonormal basis and need to be converted to the new
orthonormal basis, you can run:
shbasis <image> -convert force_oldtonew
. This will inform
shbasis
that even though it’s unable to determine the current SH
basis, you’re confident that you do know it, and therefore it should
perform the conversion anyway. It will give you a couple of loud
warnings just to make sure you appreciate the danger in what you’re
doing, so you should only ever use this setting for problematic data;
for the vast majority of conversions, -convert native
is much
better.