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
|