Hi Mark,
you were absolutely right. the -s option without the brainstem and accumbens worked.
I agree this is a resolution problem. Some of the images are 7mm thick and resolution is not that good.
There are some structures that have missing voxels-- I guess that volume calculation would be affected in those structures?
many thanks for your help,
aj
--- On Fri, 1/29/10, Mark Jenkinson <[log in to unmask]> wrote:
> From: Mark Jenkinson <[log in to unmask]>
> Subject: Re: [FSL] problem with FIRST
> To: [log in to unmask]
> Date: Friday, January 29, 2010, 10:30 AM
> Hi,
>
> If you have a look at the contents you'll see problems in
> three of the
> basic first.e* files - the ones for structures 1, 9 and
> 17. These are
> the left and right accumbens and the brainstem. The
> messages for
> the accumbens indicate that FIRST found a very small
> structure and
> could not find any interior voxels. Is your
> resolution poor in these
> images? The error for the brainstem showed that it
> crashed, which
> can happen if you FOV is too small (doesn't go low enough
> to cover
> the whole brainstem).
>
> If you are not particularly interested in any of these
> structures, then
> I suggest you re-run FIRST without these structures, which
> should work.
> You can do this just by adding:
> -s
> L_Amyg,L_Caud,L_Hipp,L_Late,L_Pall,L_Puta,L_Thal,R_Amyg,R_Caud,R_Hipp,R_Late,R_Pall,R_Puta,R_Thal
> to your run_first_all command.
>
> If you are interested in the accumbens or brainstem then we
> will
> need to investigate your images further.
>
> All the best,
> Mark
>
>
> On 29 Jan 2010, at 15:06, Adil Javed wrote:
>
> > Than you so much for your help.
> > Here are the *.e* files from the First logs
> directory. I actually don't even see the
> *_origsegs.nii.gz file. Just the original T1 image,
> *.bvars,*.vtk, *com, *std_sub.mat, *std_sub.nii.gz, and logs
> directory. That's it.
> > again, many thanks.
> > aj
> >
> >
> > --- On Fri, 1/29/10, Mark Jenkinson <[log in to unmask]>
> wrote:
> >
> >> From: Mark Jenkinson <[log in to unmask]>
> >> Subject: Re: [FSL] problem with FIRST
> >> To: [log in to unmask]
> >> Date: Friday, January 29, 2010, 2:09 AM
> >> Hi,
> >>
> >> The recommended way of getting the volume is to
> use
> >> fslstats on the
> >> *_firstseg.nii.gz volume, as described in:
> >> http://www.fmrib.ox.ac.uk/fsl/first/index.html
> >>
> >> If you do not get this output image then that is a
> serious
> >> problem
> >> and needs to be fixed before trying anything
> else.
> >>
> >> Can you please look at the *.e* files in your log
> directory
> >> and
> >> send us the contents (giving the name of the file
> it comes
> >> from)
> >> so that we can try and diagnose your problem?
> >>
> >> One thing we have found before is that for images
> with a
> >> limited
> >> FOV, the brainstem and/or cerebellum segmentation
> can
> >> cause
> >> problems. If this is the case you should be
> able to
> >> see it in the
> >> individual segmentation outputs (the
> *_origsegs.nii.gz
> >> file).
> >> Have you checked this file? Do the
> segmentations all
> >> look correct?
> >> And have you checked that the registrations have
> all
> >> worked?
> >>
> >> Let us know the answers to the above questions.
> >> All the best,
> >> Mark
> >>
> >>
> >> On 29 Jan 2010, at 07:24, Adil Javed wrote:
> >>
> >>> Hi,
> >>> I am running the script run_first_all on my
> T1
> >> images. This script does not always
> generates the
> >> all_fast_firstseg.nii.gz file, which I need to do
> the
> >> volumetric analysis of subcortical
> structures. It does
> >> generate all the other .vtk, bvars, and .com
> files.
> >>> Ant ideas why this happens?
> >>>
> >>> Also, can I use the .vtk file to get the
> volume info?
> >>> for example: first_utils --meshToVol -m
> mesh.vtk -i
> >> t1_image.nii.gz -l fill_value -o output_name
> >>>
> >>> and then get the volume by:
> >>> fslstats output_name -l 16.5 -u 17.5 -V ?
> >>>
> >>> I tried volume analysis using both .vtk and
> >> all_fast_firstseg.nii.gz files on one of the
> subjects, but
> >> these two methods five different results. not sure
> why this
> >> ocurs?
> >>>
> >>> Any ideas?
> >>>
> >>> Tx so much for your help,
> >>>
> >>> aj
> >>>
> > <log.zip>
>
|