ERROR: talairach_afd: Talairach Transform: transforms/talairach.xfm ***FAILED*** (p=0.0000, pval=0.0000 < threshold=0.0050

[chrisgorgo]

#--------------------------------------------
#@# Talairach Failure Detection Fri Jun 16 02:55:05 UTC 2017
/output/data/freesurfer/sub-09/mri

 talairach_afd -T 0.005 -xfm transforms/talairach.xfm 

ERROR: talairach_afd: Talairach Transform: transforms/talairach.xfm ***FAILED*** (p=0.0000, pval=0.0000 < threshold=0.0050)

Manual Talairach alignment may be necessary, or
include the -notal-check flag to skip this test,
making sure the -notal-check flag follows -all
or -autorecon1 in the command string.
See:

http://surfer.nmr.mgh.harvard.edu/fswiki/FsTutorial/Talairach


ERROR: Talairach failed!

Linux 23248aa48e5f 4.4.51-40.58.amzn1.x86_64 #1 SMP Tue Feb 28 21:57:17 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

recon-all -s sub-09 exited with ERRORS at Fri Jun 16 02:55:05 UTC 2017

For more details, see the log file /output/data/freesurfer/sub-09/scripts/recon-all.log
To report a problem, see http://surfer.nmr.mgh.harvard.edu/fswiki/BugReporting


Standard error:

Return code: 1
Interface ReconAll failed to run. 
INFO: transform src into the like-volume: orig.mgz
170616-02:55:05,846 workflow INFO:
	 ***********************************
170616-02:55:05,846 workflow ERROR:
	 could not run node: fmriprep_wf.single_subject_09_wf.anat_preproc_wf.surface_recon_wf.autorecon1
170616-02:55:05,846 workflow INFO:
	 crashfile: /output/data/fmriprep/sub-09/log/20170615-235823_9a07d737-404e-4210-9dd0-68c2f053ebb7/crash-20170616-025505-root-autorecon1-8022ed41-454e-4a1e-862d-faefba145cd2.pklz
170616-02:55:05,846 workflow INFO:
	 ***********************************

ds114 subjects 07 and 09 only. This did not happen with 0.4.5. More info: http://openneuro.dev.sqm.io/datasets/ds000118/versions/00001?app=fmriprep&version=14&job=050a6e62-7f12-48cb-bf8d-8e3e76f739c4

[effigies]

I don't think I have a login to that site. Are you able to test again on 0.4.5? Because there should have been no change in FreeSurfer between versions. The timestamps on the dist server are still January.

[chrisgorgo]

I run it before on 0.4.5 and did not get that error. I can run it again.

My reasoning is that the the new harmonization method must've changed something about the headers that is throwing freesurfer off.

[effigies]

Oh... good call.

…

-------- Original message -------- From: Chris Filo Gorgolewski <notifications@github.com> Date: 6/16/17 12:46 (GMT-05:00) To: poldracklab/fmriprep <fmriprep@noreply.github.com> Cc: Christopher Markiewicz <markiewicz@stanford.edu>, Comment <comment@noreply.github.com> Subject: Re: [poldracklab/fmriprep] ERROR: talairach_afd: Talairach Transform: transforms/talairach.xfm ***FAILED*** (p=0.0000, pval=0.0000 < threshold=0.0050 (#562) I run it before on 0.4.5 and did not get that error. I can run it again. My reasoning is that the the new harmonization method must've changed something about the headers that is throwing freesurfer off. — You are receiving this because you commented. Reply to this email directly, view it on GitHub<#562 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AAFF8rP5SCBYEdO7VQ0P3ILrR_wncW0Gks5sErFzgaJpZM4N8m7B>.

[effigies]

My first thought on this is we can go back to passing all T1w images to recon-all, rather than merging and then passing. It means doubling up on the mri_robust_template step, but that's not very significant compared to the overall run time.

But I'm grabbing these subjects so I can look at the results. If Talairach is failing, I'm guessing there's going to be a visible issue in the merged T1w images.

[effigies]

Here's the change in header between the original image and the conformed image. (For sub-07, only sub-07_ses-test_T1w.nii.gz changed.)

1c1
< filename       /data/bids/ds000114/sub-07/ses-test/anat/sub-07_ses-test_T1w.nii.gz
---
> filename       sub-07_ses-test_T1w_ras.nii.gz
13,14c13,14
< vox_units      mm
< time_units     s
---
> vox_units      Unknown
> time_units     Unknown
20,25c20,25
< pixdim2        1.300629
< pixdim3        1.000000
< pixdim4        0.009628
< pixdim5        0.000000
< pixdim6        0.000000
< pixdim7        0.000000
---
> pixdim2        1.300291
> pixdim3        0.999999
> pixdim4        1.000000
> pixdim5        1.000000
> pixdim6        1.000000
> pixdim7        1.000000
46,50c46,50
< qform_name     Scanner Anat
< qform_code     1
< qto_xyz:1      0.999861  0.009812  0.014875  -134.640289
< qto_xyz:2      -0.008270  1.298998  0.049379  -84.381409
< qto_xyz:3      -0.014484  -0.064375  0.998669  -147.122208
---
> qform_name     Unknown
> qform_code     0
> qto_xyz:1      1.000000  0.000000  0.000000  0.000000
> qto_xyz:2      0.000000  1.300291  0.000000  0.000000
> qto_xyz:3      0.000000  0.000000  0.999999  0.000000
55,56c55,56
< sform_name     Scanner Anat
< sform_code     1
---
> sform_name     Aligned Anat
> sform_code     2
58c58
< sto_xyz:2      -0.008271  1.298998  0.049380  -84.381409
---
> sto_xyz:2      -0.008268  1.298659  0.049367  -84.381409
66c66
< descrip        FSL5.0
---
> descrip

Points of concern:

1. Header missing mm/s units. This should be fixable, but since this is the assumption of pretty much all software, I doubt this is the source of our problem.
2. qform: marked invalid, which should be fine...
3. sform: aligned? I'm not sure whether that should cause an issue.

In any event, I think we should set a tolerance (e.g. >0.05mm difference in zoom) to consider significant enough to rescale. But do you see any reason these header differences should cause issues?

[chrisgorgo]

All of them could be problematic - it's hard to say. Might be worth passing the header from the original file when creating the new one.

…

On Fri, Jun 16, 2017 at 11:16 AM, Chris Markiewicz ***@***.*** > wrote: Here's the change in header between the original image and the conformed image. (For sub-07, only sub-07_ses-test_T1w.nii.gz changed.) 1c1< filename /data/bids/ds000114/sub-07/ses-test/anat/sub-07_ses-test_T1w.nii.gz---> filename sub-07_ses-test_T1w_ras.nii.gz13,14c13,14< vox_units mm< time_units s---> vox_units Unknown> time_units Unknown20,25c20,25< pixdim2 1.300629< pixdim3 1.000000< pixdim4 0.009628< pixdim5 0.000000< pixdim6 0.000000< pixdim7 0.000000---> pixdim2 1.300291> pixdim3 0.999999> pixdim4 1.000000> pixdim5 1.000000> pixdim6 1.000000> pixdim7 1.00000046,50c46,50< qform_name Scanner Anat< qform_code 1< qto_xyz:1 0.999861 0.009812 0.014875 -134.640289< qto_xyz:2 -0.008270 1.298998 0.049379 -84.381409< qto_xyz:3 -0.014484 -0.064375 0.998669 -147.122208---> qform_name Unknown> qform_code 0> qto_xyz:1 1.000000 0.000000 0.000000 0.000000> qto_xyz:2 0.000000 1.300291 0.000000 0.000000> qto_xyz:3 0.000000 0.000000 0.999999 0.00000055,56c55,56< sform_name Scanner Anat< sform_code 1---> sform_name Aligned Anat> sform_code 258c58< sto_xyz:2 -0.008271 1.298998 0.049380 -84.381409---> sto_xyz:2 -0.008268 1.298659 0.049367 -84.38140966c66< descrip FSL5.0---> descrip Points of concern: 1. Header missing mm/s units. This should be fixable, but since this is the assumption of pretty much all software, I doubt this is the source of our problem. 2. qform: marked invalid, which should be fine... 3. sform: aligned? I'm not sure whether that should cause an issue. In any event, I think we should set a tolerance (e.g. >0.05mm difference in zoom) to consider significant enough to rescale. But do you see any reason these header differences should cause issues? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#562 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAOkp9HaX9l6cH2ZEgWeaALSWgp-sjXvks5sEsaQgaJpZM4N8m7B> .

[effigies]

Seems reasonable. Here's the result:

1c1
< filename       /data/bids/ds000114/sub-07/ses-test/anat/sub-07_ses-test_T1w.nii.gz
---
> filename       sub-07_ses-test_T1w_ras.nii.gz
20,21c20,21
< pixdim2        1.300629
< pixdim3        1.000000
---
> pixdim2        1.300291
> pixdim3        0.999999
46,50c46,50
< qform_name     Scanner Anat
< qform_code     1
< qto_xyz:1      0.999861  0.009812  0.014875  -134.640289
< qto_xyz:2      -0.008270  1.298998  0.049379  -84.381409
< qto_xyz:3      -0.014484  -0.064375  0.998669  -147.122208
---
> qform_name     Unknown
> qform_code     0
> qto_xyz:1      1.000000  0.000000  0.000000  0.000000
> qto_xyz:2      0.000000  1.300291  0.000000  0.000000
> qto_xyz:3      0.000000  0.000000  0.999999  0.000000
55,56c55,56
< sform_name     Scanner Anat
< sform_code     1
---
> sform_name     Aligned Anat
> sform_code     2
58c58
< sto_xyz:2      -0.008271  1.298998  0.049380  -84.381409
---
> sto_xyz:2      -0.008268  1.298659  0.049367  -84.381409

So qform and sform changes are part of nibabel machinery. Given that it works for images that are resampled from 1.3mm -> 1.0mm (sub-02, I think?), I suspect it might be a resampling issue; such a tiny change is probably a real edge case.

Here's an image of orig - conformed (black-white is approximately -50 to +50):

[effigies]

Also, running autorecon1 on the merged result when copying the header. Will report back.

[effigies]

Update: Copying the header doesn't resolve the issue.

I think the issue may be being originating within FreeSurfer's bias-field (nu) correction. Compare freesurfer/sub-07/mri/orig/001.mgz and freesurfer/sub-07/orig.mgz (have to download because Papaya can't handle .mgz). I think what might be going on is that the tiny shifts in the image above are resulting in image statistics that are being interpreted as a bias field effect, which then produces a weird image when "corrected".

In which case the correct course of action is to set that threshold for resampling. I chose .05 earlier since that's the rounding distance for .1mm, which is almost always the resolution that people are shooting for in the scanner.

[chrisgorgo]

That sounds reasonable.

…

On Fri, Jun 16, 2017 at 1:02 PM, Chris Markiewicz ***@***.***> wrote: Update: Copying the header doesn't resolve the issue. I think the issue may be being originating within FreeSurfer's bias-field (nu) correction. Compare freesurfer/sub-07/mri/orig/001.mgz and freesurfer/sub-07/orig.mgz (have to download because Papaya can't handle .mgz). I *think* what might be going on is that the tiny shifts in the image above are resulting in image statistics that are being interpreted as a bias field effect, which then produces a weird image when "corrected". In which case the correct course of action is to set that threshold for resampling. I chose .05 earlier since that's the rounding distance for .1mm, which is almost always the resolution that people are shooting for in the scanner. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#562 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAOkpyWrDbCJdi7pYKludEyX_-w79qj_ks5sEt9SgaJpZM4N8m7B> .