Upon inspection, registration between the functional and anatomical image seems to be failing for 1 run (of 12). The BOLD data looks shifted/cut off when overlaid (see attached photo). This is only occurring for 1 run, and the raw data for the run looks normal.
Has anyone encountered this issue? If so, do you recommend re-running everything again, or is there a specific step I should target?
Either the .html report (with the figures folder with is located at sub-<id>/figures/) or the figure about coregistration (you’ll find a link to it in the html report under the figure).
The only difference in the nifti headers between runs is in the minimum and maximum display range of the image intensity. This differs between all runs though, and doesn’t seem a likely culprit.
The orientation and the translation are the same across runs.
I redownloaded the data from flywheel, double checked all the json files and verified BIDS formatting, ran again last night-- same outcome. Let me know if you have any thoughts on how to troubleshoot this!
So I could check headers are the same, and only differ on the cal_max/cal_min values - which should not cause this issue.
The only potential problem I could pick up is that the run you labelled as “bad” has a pretty unfortunate FoV prescription, cutting out a good portion at the top of the brain. I would agree that should not drive co-registration adrift but it might just be the case.
Could you share the T1w image, metadata and the reverse encoding references for me to replicate? Maybe give me access on Sherlock?
I tried to run the subject with this flag and it errors out after ~1 min, with the message:
traits.trait_errors.TraitError: The ‘tr’ trait of a FunctionalSummaryInputSpec instance must be a float, but a value of None <class ‘NoneType’> was specified.
I’m not sure why this would happen all of a sudden- do you think it is related?
Might be totally off-base here, but I know at our site there have been some issues with Flywheel intermittently reaping parts of the nifti headers for some vols w/in a scan and not others, and then spitting out info that confuses the conversion to nifti and downstream (someone just uncovered this a few days ago).
I might try it with data that hasn’t gone through Flywheel, just straight from the scanner? Unless @oesteban thinks he has some idea behind the issue.