2dImreg - 'Dataset does not have square slices' - how to fix

josef_ling · March 20, 2024, 3:16pm

Jun 24 2022 (Version AFNI_22.1.14 'Antoninus Pius')

When running 2dImReg I get the following error:
Notice 2dImreg: nx=82 ny=82 nz=56 dx=3.024390 dy=-3.024391 dz=3.000000

Dataset does not have square slices

I'd like to identify where 2dImReg.c code is failing and how to fix the dimensions so 2dImReg will run. AFNI tools don't have sufficient precision to tell me what is wrong.

2dImReg.c

nx = old_dset->daxes->nxx ; dx = old_dset->daxes->xxdel ;
ny = old_dset->daxes->nyy ; dy = old_dset->daxes->yydel ; npix = nx*ny ;
nz = old_dset->daxes->nzz ; dz = old_dset->daxes->zzdel ;

if( nx != ny || fabs(dx) != fabs(dy) ){

 /*     No need to quit, works fine.  ZSS 07
  *     Only if nx >= ny (so fix might be easy).  12 Jan 2010 [rickr] */
 if (opt->debug)
 fprintf(stderr,"\nNotice 2dImreg: nx=%d ny=%d nz=%d  dx=%f dy=%f dz=%f\n",
       nx,ny,nz,dx,dy,dz ) ;

  return "***********************************\n"
         "Dataset does not have square slices\n"
         "***********************************"  ;

Results from original dicom header of the bold data:

dicom_hdr
0018 1310 8 [7970 ] // ACQ Acquisition Matrix// 82 0 0 82
0028 0030 32 [9272 ] // IMG Pixel Spacing//3.0243902206421\3.0243902206421

So, square out to 13 places?

nifti_tool -disp_hdr
dim 40 8 4 82 82 56 572 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 0
datatype 70 1 512
bitpix 72 1 16
slice_start 74 1 0
pixdim 76 8 -1.0 3.02439 3.02439 3.0 0.48 0.0 0.0 0.0

nifti_tool -disp_nim
dim 64 8 4 82 82 56 572 1 1 1
nvox 128 1 215383168
nbyper 136 1 2
datatype 140 1 512
dx 144 1 3.02439
dy 152 1 3.02439
dz 160 1 3.0
dt 168 1 0.48
du 176 1 0.0
dv 184 1 0.0
dw 192 1 0.0
pixdim 200 8 0.0 3.02439 3.02439 3.0 0.48 0.0 0.0 0.0

I have tried to fix with AFNI tools with no success:

nifti_tool -mod_nim -prefix mod_nim_dx_dy -infiles bold.nii.gz -mod_field dx 3.0243902206421 -mod_field dy 3.0243902206421 -mod_field pixdim '0.0 3.0243902206421 3.0243902206421 3.0 0.48 0.0 0.0 0.0'

2dImReg -input mod_nim_dx_dy.nii -prefix test.nii.gz -debug
Notice 2dImreg: nx=82 ny=82 nz=56 dx=3.024390 dy=-3.024391 dz=3.000000

Dataset does not have square slices

Seems like the issue could be in the THD_3dim_dataset code.
Could you help me identify where and why 'dy' becomes '3.024391' so I can fix it?

thanks

rickr · March 20, 2024, 3:48pm

Hello,

It is not quite clear why the -mod_field method is not producing identical floats, but it is worth noting that 3.0243902206421 cannot be stored EXACTLY as a float (particularly only 32-bit ones). If you accept around a 0.01% size error (which might accumulate to around a 0.03 mm difference across the entire image), then you could round that to precisely representable binary values, like pooooooossibly 3.0244140625, or more likely 3.0234375.

On the flip side, we could alter the program to not require that dx and dy are exactly equal, but that can be a bit dangerous, too. For example, we could have it fail only if (dx-dy)/dx > 0.00001, which ought to allow for these sorts of floating point truncation issues.

rick

josef_ling · March 20, 2024, 3:51pm

This doesn't work either:
nifti_tool -mod_nim -prefix mod_nim_dx_dy -infiles bold.nii.gz -mod_field dx 3.0243902 -mod_field dy 3.0243902

Notice 2dImreg: nx=82 ny=82 nz=56 dx=3.024390 dy=-3.024391 dz=3.000000

Dataset does not have square slices

josef_ling · March 20, 2024, 3:52pm

Why does it fail for dy but not dx if the inputs are identical?

rickr · March 20, 2024, 3:53pm

It might be performing a computation on the dimensions that leads to the inconsistency. Let me take a quick look...

Do you build yourself (build_afni.py), or do you use precompiled binaries?

rick

josef_ling · March 20, 2024, 3:55pm

Precompiled binary linux_ubuntu_16_64: Jun 24 2022 (Version AFNI_22.1.14 'Antoninus Pius')

rickr · March 20, 2024, 4:29pm

Actually, maybe the problem is that you are modifying the pixdim fields and it has an sform or qform. In that case, the pixdim might be completely ignored. Try running this first:

3drefit -xdel 3.0243902206421 -ydel 3.0243902206421 bold.nii.gz

rick

josef_ling · March 20, 2024, 6:48pm

Yes, after doing that 2dImReg stops complaining. But this deobliques the header.

rickr · March 20, 2024, 8:04pm

Ah, so that was part of what I was wondering with respect to the values being a computation. Since the volumes are oblique, the transformation is stored as a 4x4 matrix, and the dimensions have to be computed from that. Such a computation has its own truncation issues.

Anyway, maybe I will stick in that |dx-dy|/dx > 0.0001 test and you can see if that helps. If you were compiling locally with build_afni.py, you could try it yourself.

rick

josef_ling · March 20, 2024, 8:34pm

I guess I could build 2dImReg once and copy it in each time we upgrade AFNI.
Since I'm using a basefile, 3drefit won't work for me unless I deoblique both datasets and then repair the sform/qform header data in my 2dImReg output.

My vote would be for your "square-ish" check in the 2dImReg code

josef_ling · March 20, 2024, 8:39pm

What did Ziad mean in 2007 when he said "No need to quit, works fine. ZSS 07"

rickr · March 21, 2024, 12:50am

Based on my reply comment, I would guess that Ziad tested the nx != ny case, and found that it seemed to work out. But apparently I looked it over and thought that there might still be a problem if ny > nx, though it could be easy to fix.

Anyway, I put in an update for dx being close to dy. I will run a build, so this should be available in a few hours (AFNI_24.0.15).

Thanks,

rick

josef_ling · March 21, 2024, 4:19pm

Thanks. I grabbed that version and ran it.

Here is what I got:

-- want : |dx-dy|=6.048781  <  |0.000100*dx|=0.000302

***********************************
Dataset does not have square slices
***********************************

i think you had it right in your first response above:
(dx-dy)/dx > 0.00001
(dx-dy)/dx > 0.001

rickr · March 21, 2024, 4:32pm

Oh, we need ||dx|-|dy|| there, sorry. Apparently yours have different signs, but my test case did not.

rick

rickr · March 22, 2024, 1:42pm

We indeed did another build last night, so there should be updated binaries to handle the differential signs. Sorry I missed that bit.

r

josef_ling · March 22, 2024, 3:35pm

This is great progress.
However, since I'm using the -basefile flag I think your change may need to be applied to the basefile as well. The basefile in my case is the SBREF image of the CMRR MB sequence.


Notice 2dImreg: nx=82 ny=82 nz=56  dx=3.024391 dy=-3.024390 dz=3.000000

IMREG: Input Dataset:
nx=82 ny=82 nz=56  dx=3.024391 dy=-3.024390 dz=3.000000

IMREG: Base Dataset:
nx=82 ny=82 nz=56  dx=3.024390 dy=-3.024391 dz=3.000000
*************************************************
Base Dataset is not compatible with Input Dataset
*************************************************

rickr · March 22, 2024, 3:57pm

Okay, this is a bit of working in the dark. What is the actual command that you are running? And what is the output of 3dinfo -orient on the datasets?

Thanks,

rick

josef_ling · March 22, 2024, 4:10pm

Sorry for the trouble. Happy to also send you first image of bold series and sbref if that helps.

2dImReg
-input bold.nii.gz
-basefile sbref.nii.gz
-base 0
-prefix 2dreg.nii.gz
-dprefix 2dreg

> 3dinfo -orient bold.nii.gz
RPI


> 3dinfo -orient sbref.nii.gz
RPI



> nifti_tool -disp_hdr -infile bold.nii.gz
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    r
dim_info              39      1    48
dim                   40      8    4 82 82 56 572 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    0
datatype              70      1    16
bitpix                72      1    32
slice_start           74      1    0
pixdim                76      8    -1.0 3.02439 3.024391 3.0 0.48 0.0 0.0 0.0
vox_offset           108      1    13504.0
scl_slope            112      1    0.0
scl_inter            116      1    0.0
slice_end            120      1    55
slice_code           122      1    0
xyzt_units           123      1    10
cal_max              124      1    0.0
cal_min              128      1    0.0
slice_duration       132      1    0.0
toffset              136      1    0.0
glmax                140      1    0
glmin                144      1    0
descrip              148     80
aux_file             228     24
qform_code           252      1    1
sform_code           254      1    1
quatern_b            256      1    0.012232
quatern_c            260      1    0.964999
quatern_d            264      1    0.261449
qoffset_x            268      1    122.569641
qoffset_y            272      1    -71.347855
qoffset_z            276      1    -117.53495
srow_x               280      4    -3.021846 0.045361 -0.114514 122.569603
srow_y               296      4    0.097434 2.610017 -1.512582 -71.347847
srow_z               312      4    -0.076757 1.527315 2.58824 -117.535004
intent_name          328     16
magic                344      4    n+1


> nifti_tool -disp_hdr -infile sbref.nii.gz
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    r
dim_info              39      1    57
dim                   40      8    3 82 82 56 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    0
datatype              70      1    512
bitpix                72      1    16
slice_start           74      1    0
pixdim                76      8    -1.0 3.02439 3.02439 3.0 0.48 0.0 0.0 0.0
vox_offset           108      1    352.0
scl_slope            112      1    1.0
scl_inter            116      1    0.0
slice_end            120      1    0
slice_code           122      1    1
xyzt_units           123      1    10
cal_max              124      1    0.0
cal_min              128      1    0.0
slice_duration       132      1    0.0
toffset              136      1    0.0
glmax                140      1    0
glmin                144      1    0
descrip              148     80    TE=29;Time=164342.547;phase=1
aux_file             228     24    Single-band reference
qform_code           252      1    1
sform_code           254      1    1
quatern_b            256      1    0.012232
quatern_c            260      1    0.964999
quatern_d            264      1    0.261449
qoffset_x            268      1    122.569641
qoffset_y            272      1    -71.347855
qoffset_z            276      1    -117.53495
srow_x               280      4    -3.021846 0.045361 -0.114514 122.569641
srow_y               296      4    0.097434 2.610017 -1.512582 -71.347855
srow_z               312      4    -0.076757 1.527315 2.58824 -117.53495
intent_name          328     16
magic                344      4    n+1

rickr · March 22, 2024, 4:25pm

Sure, it would be helpful to verify with the exact data. I will send you a private message, thanks.

rick

rickr · March 22, 2024, 5:12pm

Ok, this is in. Hopefully the third time is the charm...
Thanks for the test case.

rick