On Jan 28, 2009, at 3:20 PM, Siddharth Srivastava wrote:
freesurfer-Linux-centos4_x86_64-stable-pub-v4.1.0
On Wed, Jan 28, 2009 at 12:12 PM, Krish Subramaniam <krish@nmr.mgh.harvard.edu> wrote:
Hi Siddharth
Looks like Bruce fixed the bug. Can you tell me your platform? The output of
cat build-stamp.txt
Krish
On Jan 27, 2009, at 10:42 PM, Siddharth Srivastava wrote:
Hi Nick, Bruce,
Can you atleast suggest an alternative to get the average volumes, that
can be used for some VBM in freesurfer. My work is kinda stuck
because of this error... Or maybe a word or 2 about the progress on this front?
sid.
On Tue, Jan 27, 2009 at 1:44 PM, Siddharth Srivastava <siddys@gmail.com> wrote:
Hi Nick, Bruce,
Just wondering if you were able to find something out regarding
the cropping...
thanks,
sid.
On Mon, Jan 26, 2009 at 11:16 AM, Siddharth Srivastava <siddys@gmail.com> wrote:
just a correction: cropping happens when orig.mgz is operated by mri_convert to
give orig-RO8NormVC .. (not on 001.mgz as mentioned earlier)
sid.
On Mon, Jan 26, 2009 at 10:57 AM, Siddharth Srivastava <siddys@gmail.com> wrote:
Hi Nick,
Thanks for looking into this. I am pasting the dump of mri_info on the files:
1) mri_info orig/oo1.mgz
------------------------------------------------
Volume information for 001.mgz
type: MGH
dimensions: 256 x 256 x 160
voxel sizes: 1.0000, 1.0000, 1.0000
type: SHORT (4)
fov: 256.000
dof: 0
xstart: -128.0, xend: 128.0
ystart: -128.0, yend: 128.0
zstart: -80.0, zend: 80.0
TR: 1820.00 msec, TE: 2.93 msec, TI: 1100.00 msec, flip angle: 12.00 degrees
nframes: 1
ras xform present
xform info: x_r = -0.9981, y_r = -0.0000, z_r = -0.0618, c_r = -1.9246
: x_a = 0.0098, y_a = -0.9874, z_a = -0.1581, c_a = 50.0265
: x_s = -0.0610, y_s = -0.1584, z_s = 0.9855, c_s = 48.4401
talairach xfm :
Orientation : LPS
Primary Slice Direction: axial
voxel to ras transform:
-0.9981 -0.0000 -0.0618 130.7745
0.0098 -0.9874 -0.1581 187.8058
-0.0610 -0.1584 0.9855 -2.3123
0.0000 0.0000 0.0000 1.0000
voxel-to-ras determinant 1
ras to voxel transform:
-0.9981 0.0098 -0.0610 128.5450
-0.0000 -0.9874 -0.1584 185.0682
-0.0618 -0.1581 0.9855 40.0535
0.0000 0.0000 0.0000 1.0000
------------------------------------------------
2) mri_info on orig.mgz
----------------------------------------------------
Volume information for orig.mgz
type: MGH
dimensions: 256 x 256 x 256
voxel sizes: 1.0000, 1.0000, 1.0000
type: UCHAR (0)
fov: 256.000
dof: 0
xstart: -128.0, xend: 128.0
ystart: -128.0, yend: 128.0
zstart: -128.0, zend: 128.0
TR: 1820.00 msec, TE: 2.93 msec, TI: 1100.00 msec, flip angle: 12.00 degrees
nframes: 1
ras xform present
xform info: x_r = -1.0000, y_r = 0.0000, z_r = -0.0000, c_r = -1.9246
: x_a = 0.0000, y_a = 0.0000, z_a = 1.0000, c_a = 50.0265
: x_s = 0.0000, y_s = -1.0000, z_s = -0.0000, c_s = 48.4401
talairach xfm : /share/data0/ssrivastava/processed/RO28NormVC/mri/transforms/talairach.xfm
Orientation : LIA
Primary Slice Direction: coronal
voxel to ras transform:
-1.0000 0.0000 -0.0000 126.0754
0.0000 0.0000 1.0000 -77.9735
0.0000 -1.0000 -0.0000 176.4401
0.0000 0.0000 0.0000 1.0000
voxel-to-ras determinant -1
ras to voxel transform:
-1.0000 -0.0000 0.0000 126.0754
-0.0000 -0.0000 -1.0000 176.4401
-0.0000 1.0000 -0.0000 77.9735
0.0000 0.0000 0.0000 1.0000
----------------------------------------------------
The fov in both cases is 256. Can i just mention (again), that this happens only
during "make_average_volumes" when the orig/001.mgz passes through mri_convert.
regards,
sid.
On Mon, Jan 26, 2009 at 10:43 AM, Nick Schmansky <nicks@nmr.mgh.harvard.edu> wrote:
Sid,
What is the field-of-view size? Use:
mri_info orig.mgz
and look for the 'fov' output. It should be 256. What is the fov of
the input files in subj/mri/orig? If it is greater than 256, that might
be the problem, but the cropping problem we have seen with that occurs
during the original recons, not during make_average_subject. If it is
>256, then the -cropsize256 flag should be added to recon-all.
Nick
On Sat, 2009-01-24 at 15:21 -0800, Siddharth Srivastava wrote:
> Hi bruce,
> This happens for every orig.mgz that passes through
> mri_convert at the start of
> make_average_volumes. The files are 9M each, is there a drop-area
> where i can upload
> them? I just made some checks: my orig/001.mgz files are LPS (primary-
> >axial), while
> the converted files are LIA (coronal). Can this effect the result? In
> any case, if you send
> me the link to the drop area, i will put an example mgz.
> thanks,
> sid.
>
> 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.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Freesurfer mailing list
> Freesurfer@nmr.mgh.harvard.edu
> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
_______________________________________________
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
_______________________________________________
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer