False warning in 3dWarpDrive: base and input grid offsets don't match!

AFNI Message Board
1

When I tried to use 3dWarpDrive to align a NifTI file to an AFNI BRIK file or vice versa, 3dWarpDrive would warn about the mismatch in grid offset.
This is weird because both files are generated by td3d with identical parameters except output format. I could even see the two offset being identical in base and input. 3dvolreg and 3dAllineate don’t have this misbehavior.

2

What is the output of:


3dinfo -same_grid DSET1 DSET2

?
(see 3dinfo’s help, searching for “Options requiring dataset pairing at input”.)

And more informatively, what is the output of:


3dinfo -orient -d3 -nijk -o3 -space -prefix DSET1 DSET2

?

3

ptaylor Wrote:

What is the output of:


> 3dinfo -same_grid DSET1 DSET2
>

Output:
1
1

(see 3dinfo’s help, searching for “Options
requiring dataset pairing at input”.)

And more informatively, what is the output of:


> 3dinfo -orient -d3 -nijk -o3 -space -prefix DSET1
> DSET2
>

Output:
RSP 0.453125 -0.453125 -0.453125 2097152 -28.773438 28.773438 28.773438 ORIG NIFTI
RSP 0.453125 -0.453125 -0.453125 2097152 -28.773439 28.773439 28.773439 ORIG BRIK

FOV: 58^3 mm^3
Matrix: 128^3
The real position should be 28.7734375. If rounded, it should be 28.773438, not 28.773439. Something not right about the BRIk converted by to3d.

Here is the command I used to convert NIFTI and BRIK
to3d -spgr -xFOV 29R-L -yFOV 29S-I -zFOV 29P-A -nofloatscan -prefix NIFT.nii.gz 3D:0:0:128:128:128:XX/XXX
to3d -spgr -xFOV 29R-L -yFOV 29S-I -zFOV 29P-A -nofloatscan -prefix BRIK 3D:0:0:128:128:128:XX/XXX

4

I am not certain, just looking at that, unfortunately.

I wonder if you have tried using the (much) newer dcm2niix_afni to convert the dicoms to nifti? That might help. Basically, try:


dcm2niix_afni -f [OUTPUT PREFIX] -o [OUTPUT LOCATION] [DIRECTORY HOLDING DICOMS]

or


dcm2niix_afni -f PREFIX_%p_%z -o [OUTPUT LOCATION] [DIRECTORY HOLDING DICOMS]

where, in the 2nd case, the [DIRECTORY HOLDING DICOMS] could hold several sets of dicoms, and the program will reconstruct each volume separately, sticking in the protocol and sequence name into the output nifti file name, for ease of recognition.

-pt

5

We used to3d to convert raw file from Bruker to BRIK or NIFTI. So, we don’t have DICOM files.

This bug is independent of the binary file. Because, when the input are the same raw file and parameters, the output BRIK/HEAD and NIFTI doesn’t have the same resolution. It is probably rounding problems, which is very small. But, it’s annoying to see the the warning in 3dwarpdrive.

6

Do you see the same problem if you try to force the same geometry with “to3d -geomparent firstdset …” ?

7

Okay, looking at the code for 3dWarpDrive.c, I see that it is too stringent in checking for offset differences. I will fix that.

However, this message is just a WARNING, which doesn’t stop the program from running. Did the results look good?

8

RWCox Wrote:

Okay, looking at the code for 3dWarpDrive.c, I see
that it is too stringent in checking for offset
differences. I will fix that.

However, this message is just a WARNING, which
doesn’t stop the program from running. Did the
results look good?

Thanks! It doesn’t affect the results. Just felt weird to see the warning for two file formats with identical image.

It will be interesting to check why to3d round the resolution differently for BRIK/HEAD and NIFTI.

9

Daniel Glen Wrote:

Do you see the same problem if you try to force
the same geometry with “to3d -geomparent firstdset
…” ?

I tried


to3d -geomparent NIFTI -spgr -xFOV 29R-L -yFOV 29S-I -zFOV 29P-A -nofloatscan -prefix newBRIK 3D:0:0:128:128:128:XXX/XXX

The result is the same.


3dinfo -orient -d3 -nijk -o3 -space -prefix newBRIK

RSP 0.453125 -0.453125 -0.453125 2097152 -28.773439 28.773439 28.773439 ORIG

The real position is 28.7734375, which rounded to 28.773438, not 28.773439
I think this bug is reproducible for any binary file in to3d’s conversion.