Print

Print


That was so fast!  I really appreciate it.  It leads me to 2 other
questions:

1) Is there a time estimate on when the "fix" to bedpost will be ready (the
one that will reduce the number of iterations from 5000 to 1250)?

2) I am baffled. How exactly did Tim recognize that the z-direction
component was backwards in the data I sent?  My slices are inferior to
superior...is that an issue? How would I figure this out myself?

Thankyou SO much as always....what incredible software and incredible
support!

Dianne


On 8/21/07, Matt Glasser <[log in to unmask]> wrote:
>
>  Yes to all three. J
>
>
> Peace,
>
>
>
> Matt.
>
>
>  ------------------------------
>
> *From:* FSL - FMRIB's Software Library [mailto:[log in to unmask]] *On
> Behalf Of *Dianne Patterson
> *Sent:* Tuesday, August 21, 2007 12:58 PM
> *To:* [log in to unmask]
> *Subject:* Re: [FSL] new bedpost questions
>
>
>
> Wow, thankyou Tim, for the evaluation!
> If I may ask for clarification, however:
> 1) The z-vector is the third row in my bvecs (correct?)
> 2) So, you are suggesting that I switch the sign of each value there, like
> so:
> If these are my values now: -0.840197 0.64528 -0.177358
> Then I switch to: 0.840197 -0.64528 0.177358
> Is that correct?
> 3) Should I also rerun dtifit and bedpost after repairing bvecs?
>
> -Dianne
>
> On 8/21/07, *Tim Behrens* <[log in to unmask]> wrote:
>
> Hi Dianne -
>
> I am glad it looks better.
>
> However, I was looking at your data and I noticed that something wasn't
> quite right.
>
>
>
> I think the reason you have been successful in tracking the dorsal portion
> of the SLF, is that this pathway lies predominantly in the XY-plane. I think
> if you tried any pathway that had a reasonable Z component, you would find
> that your results looked very odd indeed (for example the SLF III does not
> descend into the temporal lobe as it often does).
>
>
>
> I think the reason for this is that you have defined your Z-component of
> your bvec in the opposite way from the way that FSL defines it.
>
>
>
> I think if you flipped this around (just take the negative of all the z
> directions in bvecs) that you would find that your results were even more
> impressive.
>
>
>
> I think this is also the reason that the second (and first..) directions
> do not quite line up as they should.
>
>
>
> Cheers
>
>
>
> T
>
>
>
> On 20 Aug 2007, at 20:41, Dianne Patterson wrote:
>
>
>
>  The upload *DP.tar.gz* is 155213.
> It contains a single and double fiber Feeds run and my bedpostx
> directory.
> It has a couple of layers of tar files...whose names should be fairly
> transparent.
>
> Additionally, I sent *SLF_Prob.tar.gz* which contains the 2 probability
> trackings for the superior longitudinal fasciculus which I described in an
> email the the listserve a few minutes ago:
>
> Dear group,
>
> Just to share what I consider a great success:
>
> Here we compare the old fsl 3.3 analysis with one fiber path (called
> onefdt_paths.nii.gz)
> to the new fiber track (fdt_paths.nii.gz) created with the same slf28a
> mask and the default
> of 2 fiber paths.
>
> dpat% fslstats onefdt_paths.nii.gz -V -M
> 2423 42.637.746094 1225.950887
>
> dpat% fslstats fdt_paths.nii.gz -V -M
> 8593 151.211.781250 461.366694
>
> Note the new area resulting from probtrackx is triple the size...
> It covers all the old territory that the single fiber tracking identified,
> AND it identifies more real white matter as seen in the FA.
> It identifies longer paths and more branches of the slf
> than the original single fiber analysis.
>
> The data is 25 directions at B=1000 and 3 B0 images
> gathered on a GE 3.0 T scanner with parallel imaging and an 8 channel
> coil.
> The matrix was 128x128 with roughly isotropic voxels of 2.6x2.6x2.6
> Rough calculations suggest a SNR of about 20.
>
> I hope I haven't left out any crucial details!!
>
> -Dianne
>
> Dianne
> =================
>
> On 8/20/07, *Tim Behrens* < [log in to unmask]> wrote:
>
> Hi Dianne - If you would like to upload the bedpostX directory of your
> data - we can have a quick look.
>
>
>
> While you're at it, if you upload the bedpostX directory from the course
> data, it will save me running it before the FSL course :)
>
>
>
> www.fmrib.ox.ac.uk/cgi-bin/upload.cgi
>
>
>
> Cheers
>
>
>
> Tim
>
>
>
>
>
> On 17 Aug 2007, at 20:42, Dianne Patterson wrote:
>
>
>
>
>
> On 8/17/07, *Tim Behrens* < [log in to unmask] > wrote:
>
>
>
>  For 30 directions,  It looks good in simulation for voxels where the
> fibres are very separated, but simulation is simulation!
>
>
>
> Johannes Klein, in our lab, wanted to use it for clinical populations, and
> seemed happy with its performance with 30 direction data (do you remember
> anything else about the protocol, J?).
>
>
>
> Good to know, thankyou...my output LOOKS pretty...is there any other way
> to evaluate it?
>
>
>
>  I suppose you could compare the 2nd directions with a 60 direction
> dataset (e.g. the FSL course data).
>
>
>
> I think if the 2nd fibre orientations line up to make pathways, you should
> think of this as impressive - there is no reason why they would if you were
> just looking at noise.
>
>
> Okay I ran bedpostX on the feeds data and tried to align that slice with
> my data to compare...my subjective impression is that the 60 direction data
> has more coherent paths, but I have some in my data...though the paths tend
> to be shorter in my data and perhaps not quite so consistently pointing in
> the same direction as their partners...(of course you all are welcome to
> pictures or the data files if you'd like, but I imagine you are a tad busy
> with changes that follow on a new release...so I'll just keep plugging away
> with probability tracking and see if I can compare results.
> --
> Dianne Patterson, Ph.D.
> [log in to unmask]
> ERP Lab
> University of Arizona
> 621-3256 (Office)
>
>
>
>
>
>
> --
> Dianne Patterson, Ph.D.
> [log in to unmask]
> ERP Lab
> University of Arizona
> 621-3256 (Office)
>
>
>
>
>
>
> --
> Dianne Patterson, Ph.D.
> [log in to unmask]
> ERP Lab
> University of Arizona
> 621-3256 (Office)
>



-- 
Dianne Patterson, Ph.D.
[log in to unmask]
ERP Lab
University of Arizona
621-3256 (Office)