3dinfo on nifti file gives segmentation fault

maitra · May 23, 2020, 5:27pm

HI,

I am sorry: this may be a straightforward question but I can not figure out why 3dinfo is crashing with a segmentation fault.

This file is an activation map obtained by the FAST-fMRI algorithm in our R package (RFASTfMRI). What RFASTfMRI does is creates an activation map and as an array. We have multiplied the activation map with the Z map to only have the Z map wherever there is activation, it is 0 otherwise. We convert it do nifti using the R package oro.nifti.

However, I get:


$ 3dinfo -verb Bstand2-int-FAST-death-negative.nii.gz 
++ 3dinfo: AFNI version=AFNI_20.1.07 (May 21 2020) [64-bit]

Fatal Signal 11 (SIGSEGV) received
     THD_open_nifti
    THD_open_one_dataset
   THD_open_dataset
  3dinfo main
 Bottom of Debug Stack
** AFNI version = AFNI_20.1.07  Compile date = May 21 2020
** [[Precompiled binary linux_openmp_64: May 21 2020]]
** Program Death **
** If you report this crash to the AFNI message board,
** please copy the error messages EXACTLY, and give
** the command line you used to run the program, and
** any other information needed to repeat the problem.
** You may later be asked to upload data to help debug.
** Crash log is appended to file .afni.crashlog

The AFNI crash log file is here:


$ m ~/.afni.crashlog 

*********------ CRASH LOG ------------------------------***********
Fatal Signal 11 (SIGSEGV) received
.......... recent internal history .........................................
++3dinfo main [2]: {ENTRY (file=3dinfo.c line=340) from Bottom of Debug Stack {0
 ms}
+++AFNI_process_environ [3]: {ENTRY (file=afni_environ.c line=155) from 3dinfo m
ain {0 ms}
++++AFNI_suck_file [4]: {ENTRY (file=afni_environ.c line=64) from AFNI_process_e
nviron {0 ms}
----AFNI_suck_file [4]: EXIT} (file=afni_environ.c line=84) to AFNI_process_envi
ron {0 ms}
---AFNI_process_environ [3]: EXIT} (file=afni_environ.c line=240) to 3dinfo main
 {1 ms}
+++THD_open_dataset [3]: {ENTRY (file=thd_mastery.c line=31) from 3dinfo main {1
 ms}
++++THD_open_one_dataset [4]: {ENTRY (file=thd_opendset.c line=149) from THD_ope
n_dataset {1 ms}
+++++THD_open_nifti [5]: {ENTRY (file=thd_niftiread.c line=49) from THD_open_one
_dataset {1 ms}
............................................................................
     THD_open_nifti
    THD_open_one_dataset
   THD_open_dataset
  3dinfo main
** AFNI compile date = May 21 2020
** [[Precompiled binary linux_openmp_64: May 21 2020]]
** Program Crash *

Now, this may not be relevant, but the oro.nifti package in R reads the file as I intend it to be:


readNIfTI(fname = "Bstand2-int-FAST-death-negative.nii.gz")
  NIfTI-1 format
  Type            : nifti
  Data Type       : 16 (FLOAT32)
  Bits per Pixel  : 32
  Slice Code      : 0 (Unknown)
  Intent Code     : 5 (Zscore)
  Qform Code      : 4 (MNI_152)
  Sform Code      : 4 (MNI_152)
  Dimension       : 50 x 61 x 23
  Pixel Dimension : 3.5 x 3.5 x 6
  Voxel Units     : mm
  Time Units      : Unknown

Is there something that is not right in the saving for this segmentation fault to happen?

One issue that is bothersome and may be relevant is that oro.nifti in R appears to work with NIfTI-1 format. Is this the issue?
Btw, given a 3D or 4D array, is it possible to convert it into nifti format using afni tools?

Many thanks for your help and suggestions.
Ranjan

rickr · May 23, 2020, 6:15pm

Hi Ranjan,

It might be helpful if I could see the dataset. If that is a possibility, I will send you a PM with upload instructions.

What does nifti_tool say about it?

nifti_tool -disp_hdr -infile Bstand2-int-FAST-death-negative.nii.gz

rick

maitra · May 23, 2020, 6:52pm

Rick,

Yes, of course, I am happy to send it to you. Let me know where.

Here is the output of nifti_tool:


$ nifti_tool -disp_hdr -infile Bstand2-int-FAST-death-negative.nii.gz 
N-1 header file 'Bstand2-int-FAST-death-negative.nii.gz', num_fields = 43

all fields:
  name                offset  nvals  values
  ------------------- ------  -----  ------
  sizeof_hdr             0      1    348
  data_type              4     10    
  db_name               14     18    
  extents               32      1    0
  session_error         36      1    0
  regular               38      1    
  dim_info              39      1    0
  dim                   40      8    3 50 61 23 1 1 1 1
  intent_p1             56      1    0.0
  intent_p2             60      1    0.0
  intent_p3             64      1    0.0
  intent_code           68      1    5
  datatype              70      1    16
  bitpix                72      1    32
  slice_start           74      1    0
  pixdim                76      8    3.0 3.5 3.5 6.0 1.0 1.0 1.0 1.0
  vox_offset           108      1    352.0
 scl_slope            112      1    0.0
  scl_inter            116      1    0.0
  slice_end            120      1    0
  slice_code           122      1    0
  xyzt_units           123      1    2
  cal_max              124      1    8.818847
  cal_min              128      1    -0.33843
  slice_duration       132      1    0.0
  toffset              136      1    0.0
  glmax                140      1    8
  glmin                144      1    0
  descrip              148     80    
  aux_file             228     24    
  qform_code           252      1    4
  sform_code           254      1    4
  quatern_b            256      1    0.0
  quatern_c            260      1    0.0
  quatern_d            264      1    0.0
  qoffset_x            268      1    0.0
  qoffset_y            272      1    0.0
  qoffset_z            276      1    0.0
  srow_x               280      4    0.0 0.0 0.0 0.0
  srow_y               296      4    0.0 0.0 0.0 0.0
  srow_z               312      4    0.0 0.0 0.0 0.0
  intent_name          328     16    
  magic                344      4    n+1
-

Many thanks and best wishes,
Ranjan

maitra · May 23, 2020, 7:44pm

I guess Rick already sent me details and I have uploaded the file in the location asked.

rickr · May 23, 2020, 10:32pm

Yes, I have it and will take a look soon. I wonder if the problem is related to the illegal pixdim[0] value, we’ll see…

Thanks,

rick

rickr · May 24, 2020, 6:36pm

I think the real problem is having sform_code == 5, yet having no sform matrix. But still, the program should not crash, it should just whine at you.

If possible, the sform_code should be left as zero, if there is no actual transformation.

rick

maitra · May 24, 2020, 11:44pm

Rick,

Thank you, I was putting the sform_code to be 4 (because as per the authors of the dataset, the coordinates are in MNI space).

Btw, if I save the sform and qform codes to be 0 then I do not get anything to show up at all on SUMA. However, the slices are activated, as in the attached screenshot.

With AFNI and SUMA, I used:


afni -niml&
suma -spec suma_mni/N27_both.spec -sv suma_mni/MNI_N27+tlrc.

(The two programs are talking to each other, and I have verified this in the context of other nii files.)

So, as you can see, the three slices show activation, but nothing on the SUMA. What am I doing wrong?

Many thanks and best wishes,
Ranjan

rickr · May 25, 2020, 2:41pm

I’ll look at this in more detail later, but try leaving the qform_code as it was, and just clear the sform_code.

rick

maitra · May 25, 2020, 11:44pm

Rick,

Thanks very much! I had originally tried what you suggested, but my activation regions are coming to be outside the brain. This is a mismatch. (I have attached the figure.)

Here are the parameters that I used while saving (in R):


y <- nifti(x, pixdim = c(3,3.5,3.5,6), qform.code = 4, sform.code = 4, intent.code = 5, xyzt.units = c("mm", "mm", "mm"), datatype = 16)
##
## no idea why pixdim[1] = 0 and the codes do not get picked up
## 

y@sform_code <- 0
y@qform_code  <- 4
y@intent_code <- 5
y@pixdim[1] <- 3
y@xyzt_units <- 2 # 2 stands for mm
writeNIfTI(nim = y, file = "Bstand2-int-FAST-death-negative", verbose = TRUE)

I will put the new file up also, with a slightly different name, in case the old one gets wiped out by this upload.

Many thanks again, and I am sorry for all the trouble.

Best wishes,
Ranjan

rickr · May 28, 2020, 3:56pm

Sorry for not keeping up with this.

The only spatial information in this dataset is pixdim which specifies the voxel size, along with the qform_code=4 claim that the coordinates are in MNI space. But there are no actual coordinates specified (e.g. stating where 0,0,0 should actually be), and there is no orientation information (stating which direction is left vs anterior, for example). Right now, the software assumes an identity matrix, scaled by the pixdim values, but that is surely inappropriate.

If your software inputs a NIFTI dataset, it would be good to preserve all of the spatial attributes of that input when writing the output (which could include the sform again).

rick

maitra · May 28, 2020, 6:37pm

Rick,

Thanks, very much for looking into this. I am really grateful. Unfortunately, the dataset is made available here: http://www.ccbi.cmu.edu/Suicidal-ideation-NATHUMBEH2017/Just-NatHumBeh2017-data-and-code.html
It just has the values stored as an array, and they say it is in NMI space so that is what we have proceeded with. I guess that the infomation is not enough for spatial display then. I think that the authors used SPM in their analysis/displays and I was using SUMA/AFNI.

Many thanks again, and best wishes,
Ranjan