CSDSI creates weirdly "scrambled" outputs, but did once on the same input data?

I am trying to use csdsi_3dshore recon to reconstruct DSI data into HCP-like shelled data to use with MRtrix, but the output is “scrambled” (“Output2” bottom right). I know this pipeline is listed as experimental, so I might have just given up, but one time when I ran it, it seemed to have worked? (“Output1” bottom left)

I was messing with so many things trying to debug various aspects of this dataset that I can’t tell what magically caused it to work that time but never since. The preproc outputs in output/qsiprep/, which are supposedly the inputs to the “recon_shore” node do not look identical, but neither one is obviously corrupted or anything like that (Input1 and Input2). The other input options listed for that node in its work directory are identical for both runs.

Does anybody here have any insight into what combination of options or preprocessing might cause csdsi_shore to fail in this way? Or maybe provide some guidance for how I could find the difference based on my output/work directories?

Both of the outputs shown were created using qsiprep 0.20.0. I’m running 0.21.3 and 0.21.4 now to check, though it required some patching, so we’ll see if it crashes.

the scrambled brain here looks like what happens when there is a problem getting the model results back into a 3d volume. Sometimes this can happen when there’s an NA or Inf somewhere. Maybe there is a difference in the brain masks?

It isnt “fully” scrambled though. You can still see the hyperintensity in orbitofrontal, and the cleft between cerebellum and occipital lobe, for example.

Those are probably early in the results vector, where there isn’t as much of a chance to get very scrambled in space

It seems to be something deeper. The values in csdsi_3dshore/recon_shore/sub-01_ses-31_space-T1w_desc-preproc_dwi_r2.nii.gz are all between 0 and -50 for the “bad” case. And all between 0.9 an 1.0 for the “good” case.

For completeness, this dataset is cartesian sampled DSI with a phasediff fieldmap. I’ve tried running all 4 combinations of --hmc-model {3dSHORE,eddy} and --denoise-method {dwidenoise,none}, just in case it had something to do with those, with no success so far.

You can skip some of these combinations, eddy won’t work on Cartesian sampling schemes. It’s worth taking a look at how bad the realignment is when a Cartesian scheme is provided.