html file:
fmriprep has worked for the vast majority of my dataset, but a couple participants show strange registration results that I’m having trouble finding the origin of. I’ve uploaded the html file and a zip file containing the original data. If anyone could point me in the right direction, I would appreciate it a lot!
-James
Wow, that’s quite a distortion. I can try to look at this, but one thing you can do in the meantime is to look at the actual registration command, and find the input images and output registration matrices. Look at the inputs to make sure they aren’t distorted, and then the registered file.
If that’s the problem, you can try setting --bold2t1w-dof 6, to disable scaling in bbregister.
Hi James,
I’ve been looking into this. I didn’t see the scaling issue with --bold2t1w-dof 6, but the alignment is still not great (see report), and that seems to be due to low gray/white contrast in your BOLD series.
We try to use non-steady-state volumes, or the median of several volumes, to establish the reference BOLD image, but there really just doesn’t seem to be enough contrast here. There are a couple approaches we’ve been considering to better handle BOLD series that don’t produce good reference images (#253 and #620), but neither is ready to go.
If you threw away non-steady-state volumes from your BOLD series before passing them to FMRIPREP, you should try restoring those volumes. Otherwise, I can only suggest trying to get higher-contrast images with your future acquisitions. We don’t currently support single-band reference images, but that would be a relatively minor fix, if there’s no way to improve the contrast in the acquired BOLD series.
Chris
I think there is a permission issue with the report.
It would be also worth checking if the problem is caused by an interaction of poor contrast and boundary based registration (BBR). I did hear on a couple of occasions that BBR can perform worse than voxelwise coregistration when tissue contrast is low.
True. We could add an option (--no-bbr?) to use the flt_bbr_init registration as the final registration. Or is there a better second-pass?
That would be indeed the easiest solution, but lets first confirm it would indeed solve the problem.
The alignment of brain boundaries is noticeably improved by skipping the BBR step in the FLIRT pipeline.
No noticeable difference w/ 9-dof
Great - do you think there would be a reliable way to automatically decided based on the input data whether or not to use BBR on a case by case basis?
I wonder if the FWHM calculated by AFNI would reliably answer that question. Then we can also compute gradients and quantify them.
It is not surprising BBR does not work when the target volume has weak gradients, by the theory behind BBR (active contours with edges).
we do typically throw away the first couple volumes to replicate how our older SIEMENS scanner handled image acquisition, I can talk with our techs toward seeing that being changed with our newer GE scanner
MANAGED BY INCF
