* Scott, Doug the debabeler conversion now gives the same coordinates as
mri_convert for this image. thats great thanks a lot to you both.
* Doug Greve: Here's our C source file that has our code. There's a lot of stuff there, but hopefully you can piece it together.
* Hi Doug,
Thanks for sharing; you've obviously invested a lot of time in figuring out what's going on.
I've been reading through the set of rules you posted, but I don't have enough experience (or test files) to correct the Debabeler translation. I can see Y and Z corrections that involve dPhaseFOV * sNormal.dCor, but it is not clear to me how it all comes together.
I was wondering if you'd be willing to share a snipet of code that explains how to code it?
Thanks for considering this request,
Scott
* Doug Greve: 20,32 is where the first vox would have been had you collected a single slice centered at the center of the mosaic. So if the mosaic is 1.2 meters wide, then the 1st vox will be centered 0.6m from the center of the mosaic (and so outside of the scanner). I have put the full set of rules that I use here:
http://www.nmr.mgh.harvard.edu/~greve/dicom-unpack
* Doug Greve: I put quite a bit of
effort into getting mri_convert to accurately reflect the geometry. The
way that I test this is to collect multiple volumes at different
resolutions, FoVs, and slice prescriptions. If the geometry is accurate
(and the subject has not moved), then the matrix to map one volume to
another can be completely predicted from the geometry of the volumes.
This can be checked with tkregister2:
tkregister2 --targ f1.nii --mov f2.nii --regheader --reg /tmp/blah
I've run this hundreds of times, and it is always extremely accurate. I
consider this test to be definitive. If you do not consider this a good
test or find a place where it fails, then please let me know. Until
then, I will assume that debabler is incorrect (meaning that I will
leave y'all to resolve the differences :).
I can tell you one more thing to help you though. As you point out, the
offsets given by the debabbler below are way outside of the FOV. Am I
right in assuming that this is data from a Siemens scanner and that the
volume has been mosaiced? If so, then you should know that the location
of the first voxel (tag 20 32) is incorrect. That value is where the
first voxel would have been had you collected a single slice the size of
the mosaic.
* I am endeavouring to make a DICOM -> NIFTI file conversion. The Scanner is a SIEMENS 3T scanner and I am converting mosaiced images. I am using two tools: FreeSurfer / mri_convert - out of the box; LONI / debabler (V 2.5) - not out of the box. What we did was combine a Mapping file which handles our mosaics when converting to analyze and a Mapping file that handles our non-mosaiced images when converting to nifti into a mapping file that handles our mosaics for nifti. All we think we have done is deal with the framework, not the actual coordinate
conversion code.
The two conversions give different results regarding coordinates.
Topic permissions
| 