# Response function estimation for quality control

**URL:** <https://community.mrtrix.org/t/response-function-estimation-for-quality-control/193>\
**Category:** Uncategorized\
**Created:** [May 1, 2016, 11:05am UTC](https://community.mrtrix.org/t/response-function-estimation-for-quality-control/193 "2016-05-01T11:05:46Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![TCsquared](https://community.mrtrix.org/letter_avatar_proxy/v4/letter/t/7993a0/32.png) [@TCsquared](https://community.mrtrix.org/u/TCsquared)\
**Post date:** [May 1, 2016, 11:05am UTC](https://community.mrtrix.org/t/response-function-estimation-for-quality-control/193/1 "2016-05-01T11:05:47Z")

</div>

Dear MRtrix3 experts,

I am fairly new to using MRtrix3, so please excuse a fairly basic technical question:

I visualized the response function estimation of my dti data (b=1500, 2x64 directions) with the values 303.4892197 -153.3113817 47.84516512 -10.20100441 1.233455441.

It looks flat and broadest in the axial plane (as I guess it is supposed to).

My question is:  
Are there “normal values” (depending on gradient strength / directions) to check the quality of my (individual) DTI data?  
Would that even be sensible / intended?

Maybe I did not understand the concept of the response function correctly, so any insights would be appreciated.

---

<div class="post-metadata">

**Author:** ![rsmith](https://community.mrtrix.org/user_avatar/community.mrtrix.org/rsmith/32/2672_2.png) [@rsmith](https://community.mrtrix.org/u/rsmith)\
**Post date:** [May 3, 2016, 7:01am UTC](https://community.mrtrix.org/t/response-function-estimation-for-quality-control/193/2 "2016-05-03T07:01:07Z")

</div>

Hi,

So there are certain expectations regarding how the response function ‘should’ look; for instance:

- The magnitude of the first term should be approximately the mean DWI image intensity in the white matter.
- From left to right, the values generally decrease by a factor of ~ 3-5, and switch sign between alternate values.
- Ideally, the magnitude should decrease monotonically from the X-Y plane toward the Z axis, though it’s not uncommon for there to be a little ‘bulb’ along the Z axis.

Regarding the appearance itself, the example that comes to mind is [Donald’s paper](http://onlinelibrary.wiley.com/doi/10.1002/nbm.3017/abstract), where one of the figures shows estimated responses from _b_=1000-5000 - but as angular plots rather than surfaces.

We’ve toyed with the idea of providing pre-defined response functions for particular _b_-values, as we expect the shape to be dependent on the _b_-value only; though receiver coil gain and SNR may also play a part.

Probably the more appropriate test to do for the sake of quality control is to check the locations of the voxels used to estimate the response function (`-voxels` option in the `dwi2response` script). These should make sense anatomically as single-fibre regions, and should appear to contain a single fibre following application of CSD.

Rob

---

<div class="post-metadata">

**Author:** ![ThijsDhollander](https://community.mrtrix.org/user_avatar/community.mrtrix.org/thijsdhollander/32/1617_2.png) [@ThijsDhollander](https://community.mrtrix.org/u/ThijsDhollander)\
**Post date:** [May 3, 2016, 8:29am UTC](https://community.mrtrix.org/t/response-function-estimation-for-quality-control/193/3 "2016-05-03T08:29:17Z")

</div>

Hi @TCsquared,

I’ve cross checked the SH coefficients of your response function with those from Donald’s paper (one eye closed, and engineering-wise interpolating a bit between the b=1000 and b=2000 responses in there), and the values definitely sit in the right ballpark!

The shape that you describe is indeed the correct one: the response should look like a softly blown up disk. I’d say, give it a shot and throw your data and response function at `dwi2fod`: if the FODs look sensible and not too corrupted by false spurious peaks, you should be good.

Cheers,  
Thijs

---

<div class="post-metadata">

**Author:** ![TCsquared](https://community.mrtrix.org/letter_avatar_proxy/v4/letter/t/7993a0/32.png) [@TCsquared](https://community.mrtrix.org/u/TCsquared)\
**Post date:** [May 3, 2016, 6:00pm UTC](https://community.mrtrix.org/t/response-function-estimation-for-quality-control/193/4 "2016-05-03T18:00:15Z")

</div>

Dear Rob and Thijs,

Thank you both for your helpful advice! Donald’s paper indeed helped clarifying my questions too!

I a designing a pipeline for data processing and will include a step just to visually check the response function.

Again, thank you for your advice!  
Bastian

---

<div class="post-metadata">

**Author:** ![zeydabadi](https://community.mrtrix.org/user_avatar/community.mrtrix.org/zeydabadi/32/1425_2.png) [@zeydabadi](https://community.mrtrix.org/u/zeydabadi)\
**Post date:** [May 15, 2019, 3:49pm UTC](https://community.mrtrix.org/t/response-function-estimation-for-quality-control/193/5 "2019-05-15T15:49:28Z")

</div>

Hi Rob and Thijs,

Using the currently available `dhollander` algorithm on a single shell data (b0 + b=700) I get the following response\_wm.txt:

```auto
1459.49618465773 0 0 0 0 0
774.990944178362 -204.206544862093 27.5709543467232 -3.01704665781447 -0.0572831028918161 0.303581684085567

```

Which the second row looks like this:  
 ![plot](https://community.mrtrix.org/uploads/default/original/2X/3/30734e2195ecf59430e5d59077377786bf0253d3.png)

The drop from first to the second term is about 3 times but afterward is more than 5 times and the last element has a bigger magnitude compared to the one before it.

Is this completely wrong?

---

<div class="post-metadata">

**Author:** ![ThijsDhollander](https://community.mrtrix.org/user_avatar/community.mrtrix.org/thijsdhollander/32/1617_2.png) [@ThijsDhollander](https://community.mrtrix.org/u/ThijsDhollander)\
**Post date:** [May 21, 2019, 7:52am UTC](https://community.mrtrix.org/t/response-function-estimation-for-quality-control/193/6 "2019-05-21T07:52:05Z")

</div>

> [@zeydabadi](#):
>
> Is this completely wrong?

Nope, it’s perfectly fine. Take a look at it using `shview` to confirm: I’ve checked, and it looks good.

---

<div class="post-metadata">

**Author:** ![rsmith](https://community.mrtrix.org/user_avatar/community.mrtrix.org/rsmith/32/2672_2.png) [@rsmith](https://community.mrtrix.org/u/rsmith)\
**Post date:** [May 28, 2019, 3:06pm UTC](https://community.mrtrix.org/t/response-function-estimation-for-quality-control/193/7 "2019-05-28T15:06:00Z")

</div>

> Is this completely wrong?

Generally what you’re looking for in a response function is:

- Decrease in magnitude from one term to the next.

- Switching of sign from one term to the next.

These data fail to follow the expected shape beyond _l_=6, which is unsurprising given the lower _b_-value. What I’ve not had access to data to test is whether or not it is detrimental to retain those higher degree coefficients for spherical deconvolution nevertheless, or whether it would actually be preferable to truncate the response function; feel free to muck around with this.

---

<div class="post-metadata">

**Author:** ![ThijsDhollander](https://community.mrtrix.org/user_avatar/community.mrtrix.org/thijsdhollander/32/1617_2.png) [@ThijsDhollander](https://community.mrtrix.org/u/ThijsDhollander)\
**Post date:** [May 29, 2019, 2:24am UTC](https://community.mrtrix.org/t/response-function-estimation-for-quality-control/193/8 "2019-05-29T02:24:19Z")

</div>

> [@rsmith](#):
>
> Generally what you’re looking for in a response function is:
> 
> - Decrease in magnitude from one term to the next.
> - Switching of sign from one term to the next.

In a lot of scenarios, that’s what would typically come out, but I wouldn’t personally call it “what you’re generally looking for” in all cases. In low b-value data such as @zeydabadi’s, I’ve observed exactly what Mahmoud obtained here as well. I’m not surprised here; the response furthermore does show the expected shape in the amplitude domain. Including these coefficients in CSD, in my experience, is not detrimental. Due to the low b-value and thus low angular frequencies dominating anyway, the difference is naturally so small that you can barely observe it in the outcome. That said, theoretically, it’s in your favour to not truncate, to avoid other (theoretical) artifacts. That said again, I should probably mostly stress that in practice, you won’t notice any substantial difference though.

Long story short: Mahmoud, I’ve actually inspected the response function you provided here, there’s no reason to worry about it. Note that, by default in any CSD algorithm now, the very last coefficient there won’t even be used (see [CSD on standard DWI data - #5 by ThijsDhollander](http://community.mrtrix.org/t/csd-on-standard-dwi-data/2499/5) and [No lmax=8 cap in dwi2fod msmt\_csd · Issue #899 · MRtrix3/mrtrix3 · GitHub](https://github.com/MRtrix3/mrtrix3/issues/899)). Further do note that, the lmax=10 coefficient, even though seemingly discarded later on given all defaults, does serve a role in response function estimation (see [ZSH & amp2response by Lestropie · Pull Request #786 · MRtrix3/mrtrix3 · GitHub](https://github.com/MRtrix3/mrtrix3/pull/786#issuecomment-265947475) and [Integrating amp2response in dwi2response scripts by thijsdhollander · Pull Request #862 · MRtrix3/mrtrix3 · GitHub](https://github.com/MRtrix3/mrtrix3/pull/862) where this was implemented and brought about some other stuff). Omitting lmax=10 at that (response estimation) step is not the same as truncating it down the track: in the response estimation, it can avoid the monotonicity and other constraints to otherwise potentially bias the estimation of (some of) the response ZSH coefficients.

For intuition, you should mainly check your response functions in the amplitude domain, using `shview`. use the `left` and `right` arrow keys on your keyboard to switch between b-values, e.g., to switch from the b=0 to the b=700 part of the response. Use the `Escape` key to rescale the visualisation if due to switching b-values, the visualisation would appear too small (when switching to a higher b-value) or too large (when switching back again to a lower b-value).
