Some QSIRecon runs encountering CsdNanResponseError in PyAFQ

Small non-update update – a few lab members and I looked through all the image acquisition notes and can’t discern any sort of pattern related to image acquisition (which 3T scanner (there are 2, but scanner is consistent within each participant), time of day of scan, date of scan, scan operators, order of images/randomization, etc…). I looked at my scripts again and there is no pattern relative to the order of subject IDs I listed (it’s not like the first or last 8 fail or something). I also looked at all the images (DWI and fieldmap) again and they all look as expected. I can’t find any typos or anything in any .txt files or .json files. Also, the 8 who keep failing don’t have any better or worse motion than the 16 who pass – according to QSIprep motion parameters. If anyone has any further thoughts on anything else I should check, I am all ears!

@Ariel_Rokem looking forward to any thoughts you might have!!

Thank you all so so much!! I’m truly so grateful. Thank you!!

Hello,

Sorry - this is a bit hard to diagnose without the data in hand, but let me try to provide some helpful context for why these errors show up and think about ways forward in your case.

The error message that you are seeing indicates that pyAFQ tried to automatically compute a CSD response function from the data using the DIPY auto_response_ssst function and that process failed.

First of all, you might be wondering why pyAFQ is even using CSD in the first place, since you are using mrtrix for tractography.This happens because your recon spec file specified the (default value) power_map for reg_subject_spec. In that case, pyAFQ uses the CSD model to calculate an anisotropic power map for the purpose of registration of the diffusion data to the MNI T1w template.

Further into the details of this error: the automated response function calculation relies on finding a set of voxels in the corpus callosum that have high FA and modeling the CSD single-fiber response function after the signal in those voxels. In some cases, that function doesn’t find any voxels that fit the criteria, and then this error is raised. This can happen for a variety of reasons that include generally low FA in the CC, or a subject who is not oriented in the scanner in the way that this function expects.

One way around this in your case would be to use different reg_subject_spec and reg_template_spec values. I would suggest:

        reg_subject_spec: b0
        reg_template_spec: mni_T2

which would not rely on this particular step. Something we might also want to do longer-term is to allow using a subject T1-weighted image as a registration target, rather than APM. We are currently doing some development on pyAFQ 3.0, which aligns well with such a change, but that’s not something that you’ll have off-the-shelf soon.

So, for now, I would recommend trying to change the recon spec as suggested and seeing whether that resolves your issues (without creating new ones…).

Cheers,
Ariel

1 Like

Hi @Ariel_Rokem ! Thank you so very much for this detailed reply full of helpful explanations and for your helpful suggestions.

I will go ahead and change my recon_spec file such that I use these values:

    reg_subject_spec: b0
    reg_template_spec: mni_T2

I do have a b0, but I don’t have a T2 image… is that ok? Just confirming mni_T2 isn’t referring to a T2 image I should be providing, because I don’t have one!

Just launched this job on our computing cluster…stay tuned!!

Hi @emilymharriott,

It is using the MNI T2 bundled with DIPY. B0 images (like those that you have in your DWI) have T2-like contrast, so they can be used to register to a T2 reference.

Best,
Steven

1 Like

IT WORKED!! 24/24 successfully processed and everything looks ok/as expected!! WOOHOO!! Thank you!

Confirming - is it ok to use these b0 and mni_T2 fields on all 24 scans, not just the 8 scans that failed? for consistency?

1 Like

Oh, that’s great. Glad that worked out. And yes, it makes sense to use the same setting for everyone.

1 Like