AFNI coregistration of a searchlight decoding map from native to standard

Dear AFNI List,

We are unable to successfully coregister the results of a searchlight analyses from native space. To clarify, the coregistration works when I do it on the example_func_deoblique, but it does not work on the searchlight decoding result output that we got using nilearninstead?

The relevant files can be found here
https://drive.google.com/drive/folders/1X7PZWgCllZHtMSJfKzovc2wV9vi8UIMA?usp=sharing

and here it is an explanation of each:
A reference scan (example_func_deoblique)
The participant’s T1 scan (output_brain, with non-brain structures already removed)
The searchlight decoding map (dice2decnef)
The bash script that I use for the coregistration.

Any help would be much appreciated!! thanks so much for your attention

best,

david

Howdy-

Hmm, one issue is that there is a header problem with dice2decnef_searchlight_resuls_logistic_probs_radius_4.niii.

The shorter 3dinfo error message:

3dinfo dice2decnef_searchlight_resuls_logistic_probs_radius_4.nii 
++ 3dinfo: AFNI version=AFNI_25.0.06 (Feb 18 2025) [64-bit]
** nifti_header_version: bad sizeof_hdr = 134777631
** nifti_image_read: bad nifti im header version -1
** FATAL ERROR: Can't open dataset dice2decnef_searchlight_resuls_logistic_probs_radius_4.nii
** Program compile date = Feb 18 2025

... and the longer nifti_tool one:

nifti_tool -disp_hdr -infiles dice2decnef_searchlight_resuls_logistic_probs_radius_4.nii 
** nifti_header_version: bad sizeof_hdr = 134777631
** dice2decnef_searchlight_resuls_logistic_probs_radius_4.nii: bad nifti header version -1
** resetting invalid NIFTI version to 1

N-1 header file 'dice2decnef_searchlight_resuls_logistic_probs_radius_4.nii', num_fields = 43

all fields:
  name                offset  nvals  values
  ------------------- ------  -----  ------
  sizeof_hdr             0      1    134777631
  data_type              4     10    ?g?dice
  db_name               14     18    2decnef_searchligh
  extents               32      1    1701994356
  session_error         36      1    30067
  regular               38      1    l
  dim_info              39      1    115
  dim                   40      8    27743 26479 29545 26996 24419 29296 25199 24435
  intent_p1             56      1    17255953709362388144226304.000000
  intent_p2             60      1    0.0
  intent_p3             64      1    17637501552096978082463744.000000
  intent_code           68      1    -5120
  datatype              70      1    2525
  bitpix                72      1    22072
  slice_start           74      1    -9381
  pixdim                76      8    0.0 -0.0 3124.407227 63619358261248.0 -0.0 0.0 -0.0 0.0
  vox_offset           108      1    0.0
  scl_slope            112      1    2441637.25
  scl_inter            116      1    1268334135364763089108992.000000
  slice_end            120      1    -12322
  slice_code           122      1    68
  xyzt_units           123      1    42
  cal_max              124      1    -2931143481311426742937073688827133952.000000
  cal_min              128      1    -0.499968
  slice_duration       132      1    2319615996799001568832373908433797120.000000
  toffset              136      1    -15733.451172
  glmax                140      1    -372335369
  glmin                144      1    1659329774
  descrip              148     80    ?g?{??m????{???D~??13
                                                          -?~???~h?????"DD?_??_????Kf???????D?Ϧ?F????8e???
  aux_file             228     24    ?9?{??????????????{???
  qform_code           252      1    -25602
  sform_code           254      1    -2245
  quatern_b            256      1    -511.738251
  quatern_c            260      1    -569704871826030592.0
  quatern_d            264      1    nan
  qoffset_x            268      1    0.0
  qoffset_y            272      1    2.312576
  qoffset_z            276      1    0.0
  srow_x               280      4    0.0 2.312576 0.0 0.0
  srow_y               296      4    2.312576 0.0 0.0 2.312576
  srow_z               312      4    0.0 0.0 2.312576 0.0
  intent_name          328     16    @@@@@
  magic                344      4    @@

Hmm, and output_brain also has obliquity in it:

3dinfo -obliquity -prefix output_brain.nii ./example_func_deoblique_brain.nii 
5.593	                output_brain.nii
0.000	example_func_deoblique_brain.nii

Normally when processing, we deoblique the anatomical before we start, because different software deal with it differently and it also complicates visualization. We often are fine with leaving obliquity in the EPI before running afni_proc.py, because that program deals with it fine during processing.

-pt

Just in case, alignment doesn't work well with data that is not "brain-like" intensity variations like most of the data that comes out of MRI scanners (T1,T2,EPI,...). Derived data like statistical maps or atlases rarely align well by themselves. In those cases, we align data with the MRI scans and apply the transformations to these kinds of follower data.

Hi Daniel, Paul,

Just to clarify that the scripts do compute the spatial transformations from the EPI to the MNI152 template using align_epi_anat.py and @auto_warp.py, 3dNwarpApply commands. These steps are fine with the standard EPI image.

However, as Paul indicates, I think the main issue is the header of dice2decnef_searchlight_resuls_logistic_probs_radius_4.niii

Do you know how to make it valid again?

Thanks very much,
César

Hi, César-

The method of fixing the header depends on knowing how it is broken, which I am not sure of.

Do you know how the header information is being propagated? Are you explicitly using nibabel to copy it? Is a nilearn function managing it?

--pt

thanks for following this up! the data is preprocessed with afni and then it is fed to nilearn, which manages the loading and concatenation of the relevant scans across runs and then performs the searchlight decoding.

perhaps we can copy the header using this nilearn function and then re run the coregistration in afni?

So it seems like this data is simply compressed, meaning it should have been named with .nii.gz.

cp dice2decnef_searchlight_resuls_logistic_probs_radius_4.nii dice.nii.gz
3dinfo dice.nii.gz

-rick

And the "misalignment" seems to be just because output_brain.nii is still oblique, while dice.nii.gz is not. So they look misaligned in afni because it does not want to resample the data. Just to test:

3dWarp -deoblique -prefix anat_warped.nii.gz output_brain.nii

That is aligned with dice.nii.gz.
-rick

it works, thanks!!