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