Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Philips enhanced vs classic - different positioning of image #507

Closed
baxpr opened this issue Apr 15, 2021 · 4 comments
Closed

Philips enhanced vs classic - different positioning of image #507

baxpr opened this issue Apr 15, 2021 · 4 comments

Comments

@baxpr
Copy link

baxpr commented Apr 15, 2021

Describe the bug
We have (somehow) cajoled one of our scanners into producing both the usual classic series (26k files) and an enhanced DICOM of the same series. When the .nii produced by v1.0.20210317 are viewed in fsleyes, the image position is different by one voxel in the left/right dimension. The qform/sform of the two nifti files are the same.

To Reproduce
dcm2niix v1.0.20210317, no options

Expected behavior
I'd expect identical niftis for the two dicoms.

Output Log

ImagePositionPatient:
Enhanced first frame: -114.55773750040  -156.50354454573  -5.1988021554425
Classic first frame:  -114.5577375004   -156.50354454573  -5.1988021554425

** Version (please complete the following information):**
Chris Rorden's dcm2niiX version v1.0.20210317 Clang12.0.0 x86-64 (64-bit MacOS)

Most recent commit on development branch is ccf263d - it produces the same result.
Chris Rorden's dcm2niiX version v1.0.20210403 Clang12.0.0 x86-64 (64-bit MacOS)

@neurolabusc
Copy link
Collaborator

neurolabusc commented Apr 16, 2021

@baxpr please confirm this is fixed in the latest commit to the development branch. The issue was specific to enhanced DICOM images that store extremely large and verbose headers.

The issue is that the NIfTI header stores vox_offset (offset from start of file to image data) as a 32-bit (single precision) floating point value. Floats have poor accuracy for large integers.

In Matlab (which has the handy flintmax function):

>> f32 = single(53543146)
f32 =
  single
    53543144
>>flintmax('single')
ans =
  single
    16777216

The analogous C code (which prints 53543146 -> 53543144.00):

uint32_t ii = 53543146;
float fi = ii;
printf("%d -> %8.2f\n", ii, fi);

The updated code uses an integer to store the DICOM voxel offset.

@baxpr
Copy link
Author

baxpr commented Apr 16, 2021

@neurolabusc wow, that's pretty out there. Yet another fun quirk of our recent forays into multiband fmri. Results from the d8a46aa look good to me - I get matching .nii from either set of DICOM. I get one difference in the files, here, don't know its significance:

$ cmp -b classic/*nii enhanced/*nii
classic/classic.nii enhanced/enhanced.nii differ: byte 163, line 2 is  61 1  60 0

@neurolabusc
Copy link
Collaborator

An offset at 163 would be in the descrip text field. You could use fslhd to report this value. It should look something like TE=35;Time=152005.26 and any differences presumably reflect round errors in different DICOM header forms fro these values.

@baxpr
Copy link
Author

baxpr commented Apr 16, 2021

Just so. Thanks!

descrip		TE=35;Time=152120.880
descrip		TE=35;Time=152005.260

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants