On Sat, Jan 24, 2009 at 12:40 PM, Bruce Fischl
<fischl@nmr.mgh.harvard.edu> wrote:
Hi Sid,
can you send us the volume that has this happen? I think it's just a display problem and won't affect anything else, but if you give us the example we'll fix it.
Bruce
On Sat, 24 Jan 2009, Siddharth Srivastava wrote:
Hi everyone,
Has anyone faced this problem before? Is there an
alternative
to mri_convert than i can try to get the transformation, and then run the
subsequent steps? Why are k_ras components approaching zero, and not
exactly zero. make_average_surface works fine, no clipping, i have spent the
last 20 or so odd hours checking each surf directory. This happens only for
the
structurals that pass through mri_convert. Tried changing the -oc
values, there is a shift, as expected, but the clipping remains fixed at
this level (hence more brain gets cropped if the -oc values shift the
brain posteriorly.
sid.
On Fri, Jan 23, 2009 at 11:37 AM, Siddharth Srivastava <siddys@gmail.com>wrote:
Hi bruce,
I think the offending command is
mri_convert /../../orig.mgz /../../orig-subject.mgh --apply_transform
/../../mri/transforms/talairach.xfm -oc 0 0 0
I am attaching the pre- and post mri_convert as tiffs. I have also attached
the pial_avg surface in the
posterior view, for you comments.
The folowing is the screen dump (patient name deleted):
----------------------------------------------------------------------------------------------------
$Id: mri_convert.c,v 1.146.2.3 2008/08/11 22:18:58 nicks Exp $
reading from /../subject/mri/orig.mgz...
TR=1820.00, TE=2.93, TI=1100.00, flip angle=12.00
i_ras = (-1, 0, 0)
j_ras = (0, 0, -1)
k_ras = (-9.31323e-10, 1, -1.49012e-08)
INFO: Applying transformation from file
/../subject/mri/transforms/talairach.xfm...
Reading transform with LTAreadEx()
---------------------------------
INFO: Transform Matrix (linear_ras_to_ras)
1.026 0.084 0.079 -9.471;
-0.105 1.048 0.228 -84.640;
-0.106 -0.174 1.165 -38.874;
0.000 0.000 0.000 1.000;
---------------------------------
Applying LTAtransformInterp (resample_type 1)
INFO: Transform dst volume info is not used (valid flag = 0).
applying the vox to vox linear transform
1.026 0.079 -0.084 -1.205;
-0.106 1.165 0.174 9.576;
0.105 -0.228 1.048 -61.401;
0.000 0.000 0.000 1.000;
writing to /../../orig-subject.mgh...
----------------------------------------------------------------------
does this help in any way?
thanks,
sid.
On Fri, Jan 23, 2009 at 11:01 AM, Bruce Fischl <fischl@nmr.mgh.harvard.edu
wrote:
Hi Sid,
have you looked through the individual datasets? That's where the cropping
would be, which would have caused big errors in your surfaces. I assume that
is not the case.
Bruce
On Fri, 23 Jan 2009, Siddharth Srivastava wrote:
Hi Bruce,
I just realised that the cropping at the posterior aspect is
similar to the
cropping usually done for the inferior aspect in a saggital view (to get
rid
of the
neck etc..) . Could it be (remotely) possible that the cropping was done
in
a different
orientation (nose pointing up in the sagittal view), and then oriented to
the views
that we see now? I have only used the basic commands
"make_average_subject"
with no special flags except --force
sid.
On Fri, Jan 23, 2009 at 10:33 AM, Bruce Fischl
<fischl@nmr.mgh.harvard.edu>wrote:
I'm not really sure. Doug or Nick: any ideas?
On Fri, 23 Jan 2009, Siddharth Srivastava wrote:
Hi Bruce,
please find attached a tiff file generated by mri_concat
--mean on the original mprages.
Here i can see the full view, and i think no registration has been
performed
as yet on these
images... Regarding exploring the dataset for 1 image, is it possible
that
just 1 rouge image
can cause this problem? The clipping has a sharp border, almost as if
the
bounding box
itself has been cropped at that level. the intensity in these posterior
slices is zero.
thanks,
sid.
On Fri, Jan 23, 2009 at 9:51 AM, Bruce Fischl <
fischl@nmr.mgh.harvard.edu
wrote:
if you can find a small set (1?) of subjects that generate the same
image,
then maybe you can just send us that subject and your commandline
On Fri, 23 Jan 2009, Siddharth Srivastava wrote:
ok.. i will try that and let you know... what other image/logs can i
provide
for
localizing the source of the error?
sid.
On Fri, Jan 23, 2009 at 9:04 AM, Bruce Fischl <
fischl@nmr.mgh.harvard.edu
wrote:
not really, it seems like there is a bug. If you can localize it to
just
one or a few subjects it would a lot easier to track down
On Fri, 23 Jan 2009, Siddharth Srivastava wrote:
Hi Bruce,
These are about 28 images. I have not tried fewer...do you
think there
are some images with incorrect orientation in the cohort? That
would
show
up
in the other location in the average i think...
sid.
On Fri, Jan 23, 2009 at 8:46 AM, Bruce Fischl <
fischl@nmr.mgh.harvard.edu
wrote:
I don't think so. How many subjects? Have you tried fewer?
On Fri, 23 Jan 2009, Siddharth Srivastava wrote:
The surfaces look all right. It happens only to T1. It cant be a
display
problem, can it??
sid.
On Fri, Jan 23, 2009 at 5:58 AM, Bruce Fischl <
fischl@nmr.mgh.harvard.edu
wrote:
that is strange. Do the surfaces look ok? How many subjects are
you
averaging? Does this happen if you only average one or a few?
On Thu, 22 Jan 2009, Siddharth Srivastava wrote:
Hi everyone,
I am attaching a tiff file showing the tkmedit view
of
the average
T1 that freesurfer created during make_average_subject. I am a
bit
concerned
about the cropping that is evident at the posterior aspect of
the
brain.
The
individual T1's are complete and ok, so i am guessing that
something
went
wrong during the transform of the individual brain during the
process.
Can
anyone help me find out the problem ? The average surfaces also
look
all
right.
thanks,
sid.