hello,
I didn't realise that you images contain exactly the
same data. In that case send us a copy of the header
contents (use avwhd) and we can see what the difference
is.
the following displays the headers for
VolumeA, the volume that registers
successfully with the standard volume.
VolumeA was created by an internal
philips-to-avw conversion c program:
% avwhd VolumeA.hdr
filename VolumeA.hdr
sizeof_hdr 348
data_type
db_name
extents 16384
session_error 0
regular r
hkey_un0
dim0 4
dim1 128
dim2 128
dim3 37
dim4 99
dim5 0
dim6 0
dim7 0
vox_units
cal_units
unused1 0
datatype 4
bitpix 16
pixdim0 0.0000000000
pixdim1 1.8999999762
pixdim2 1.8999999762
pixdim3 4.0000000000
pixdim4 2000.0000000000
pixdim5 0.0000000000
pixdim6 0.0000000000
pixdim7 0.0000000000
vox_offset 0.0000
funused1 0.0000
funused2 0.0000
funused3 0.0000
cal_max 0.0000
cal_min 0.0000
compressed 0
verified 0
glmax 1508
glmin 0
descrip
aux_file FM Kirby Research Center
orient 0
originator
origin1 0
origin2 0
origin3 0
generated FM Kirby R
scannum #-#/g1/lcu
patient_id XXXXXX,XXX
exp_date 2004.08.30
exp_time 14:17:03
hist_un0
views 0
vols_added 0
start_field 0
field_skip 0
omax 0
omin 0
smin 0
smin 0
the following displays the headers for
VolumeB, the volume that does not
register successfully with the
standard volume.
VolumeB was created by an internal
matlab conversion program which uses darren weber's robust, thorough
and easy-to-use mri_toolbox:
% avwhd VolumeB.hdr
filename VolumeB.hdr
sizeof_hdr 348
data_type
db_name
extents 16384
session_error 0
regular r
hkey_un0
dim0 4
dim1 128
dim2 128
dim3 37
dim4 99
dim5 0
dim6 0
dim7 0
vox_units mm
cal_units
unused1 0
datatype 16
bitpix 32
pixdim0 4.0000000000
pixdim1 1.8999999762
pixdim2 1.8999999762
pixdim3 3.0000000000
pixdim4 1.0000000000
pixdim5 0.0000000000
pixdim6 0.0000000000
pixdim7 0.0000000000
vox_offset 0.0000
funused1 1.0000
funused2 0.0000
funused3 0.0000
cal_max 0.0000
cal_min 0.0000
compressed 0
verified 0
glmax 2576
glmin 0
descrip Lit-Visual SENSE|TR=2|FOV=[240 147 240]|scanRez=[80
80]|slgap=1
aux_file
orient 0
originator
origin1 8224
origin2 8224
origin3 8224
generated mri_toolbx
scannum
patient_id
exp_date 10-09-2004
exp_time 21-16-17.3
hist_un0
views 0
vols_added 0
start_field 0
field_skip 0
omax 0
omin 0
smin 0
smin 0
i changed some fields, one-by-one, in
VolumeB to see if that made a
difference in registration. nope -- not at all. the immediate
differences are:
vox_units, datatype, bitpix, pixdim0,
pixdim3 (this had been corrected),
pixdim4, funused1
(roi_scale in
mri_toolbox), glmax,
descrip, origin1, origin2, origin3
(mri_toolbox sets
originator to
[spaces] therefore
origin1,2,3 are the integer values of
[space][space]),
generated, scannum, patient_id, exp_date,
exp_time.
the majority of these fields are ascii descriptor fields. please note
specifically that header field orient
is the same between the two volumes -- 0. since FSL does not
interpret that field, it does not matter anyway.
i am in the process of reading thru graham wideman's incredibly
informative pages about the analyze format
(http://www.wideman-one.com/gw/brain/analyze/index.htm). i have not
yet looked at VolumeA and
VolumeB through another display
package as a double-check with MEDx's "Raw Generic" option.
i send this header info just in case the community sees something
obvious that i am overlooking.
many thanks to all involved,
- bettyann
