Hi Dianne,
Concerning your 1st question, we've done some simulations (see the
NeuroImage paper on crossing fibres), and it seems that for the bvalue
you're using, you can detect 2 fibres if they're well separated (above 60
degrees, say). Also, it seems that doubling the number of gradient
directions, or increasing the snr by averaging gives the same result,
although this is only based on the _ability_ to detect the second fibre,
and not on the bias or uncertainty you would get on its orientation. This
would certainly benefit from having less noise..
For the second question, I wouldn't expect any memory leak in bedpostx. As
Steve said, more voxels in a slice lead to more computational time. as you
have 57 slices, could you let us know what happens with the second half,
if it's faster towards the end (assuming you have less voxels in your mask
in those slices).
Cheers,
Saad
> Thankyou,
> The B-value is 1000
> -Dianne
>
> On 8/16/07, Steve Smith <[log in to unmask]> wrote:
>>
>> Hi Dianne,
>>
>> Yes, bedpostx does a lot more calculations than bedpost if you run the
>> default crossing-fibre modelling.
>>
>> It's possible that there is a memory-leak-like issue, though is it
>> alternatively possible that the number of relevant voxels is
>> increasing as the slice number goes up, so there's more voxels to
>> process in each slice?
>>
>> Wrt Q1, what is your b-value?
>>
>> Cheers, Steve.
>>
>>
>> On 16 Aug 2007, at 19:50, Dianne Patterson wrote:
>>
>> > Hi All,
>> > I just want to run some values past you and see if you think they
>> are normal. My concern is that there might be a memory leak in my
>> bedpost.
>> >
>> > -I am running OS X Tiger (fully updated) on an Intel mac pro with 4
>> gb of ram and 4 processors at ~2.6 Ghz....this should function as a
>> 64 bit system.
>> > -My DTI data set is 25 directions, 57 slices, +3 B0 images, a
>> > 128x128 matrix with 2.6 mm thick slices
>> > -By using the standard deviation of the signal /standard deviation
>> of the noise in one of the b-weighted images,
>> > I get a SNR of about 20. (If I use the mean signal over the mean
>> noise, I get about 56)
>> >
>> > I have 2 questions:
>> > Data Quality
>> > 1) Is this dataset of sufficient richness to take advantage of the
>> fiber crossing algorithms?
>> > I do get 2 sets of images and if I display both sets of dyads as
>> lines, I see beautiful crossing fibers at many voxels (COOL!)...
>> >
>> > 2) Total Time to Run:
>> > FSL 3.3 ran bedpost in 2 hours on this system with this dataset. FSL
>> 4.0 with the default bedpost settings (thus 2 sets of crossing
>> fibers if I understand correctly),
>> > took 13+ hours to finish (started Aug 14 14:45 and finished Aug 15
>> at 4:08).
>> > I might have naively assumed it would take twice as much time as
>> doing one set of fibers...
>> > What I noticed that concerned me in the 4 hours I watched is that
>> each data_slice took roughly 1 minute longer to complete than its
>> predecessor...and this reminded me of memory leaks:
>> >
>> > drwxr-xr-x 15 dpat admin 510 Aug 14 14:45 data_slice_0000
>> > drwxr-xr-x 15 dpat admin 510 Aug 14 14:46 data_slice_0001
>> > drwxr-xr-x 15 dpat admin 510 Aug 14 14:48 data_slice_0002
>> > drwxr-xr-x 15 dpat admin 510 Aug 14 14:51 data_slice_0003
>> > drwxr-xr-x 15 dpat admin 510 Aug 14 14:56 data_slice_0004
>> > drwxr-xr-x 15 dpat admin 510 Aug 14 15:01 data_slice_0005
>> > drwxr-xr-x 15 dpat admin 510 Aug 14 15:07 data_slice_0006
>> > drwxr-xr-x 15 dpat admin 510 Aug 14 15:14 data_slice_0007
>> > drwxr-xr-x 15 dpat admin 510 Aug 14 15:21 data_slice_0008
>> > drwxr-xr-x 15 dpat admin 510 Aug 14 15:29 data_slice_0009
>> > drwxr-xr-x 15 dpat admin 510 Aug 14 15:37 data_slice_0010
>> > drwxr-xr-x 15 dpat admin 510 Aug 14 15:47 data_slice_0011
>> > drwxr-xr-x 15 dpat admin 510 Aug 14 15:57 data_slice_0012
>> > drwxr-xr-x 15 dpat admin 510 Aug 14 16:09 data_slice_0013
>> > drwxr-xr-x 15 dpat admin 510 Aug 14 16:21 data_slice_0014
>> > drwxr-xr-x 15 dpat admin 510 Aug 14 16:35 data_slice_0015
>> > drwxr-xr-x 15 dpat admin 510 Aug 14 16:51 data_slice_0016
>> > drwxr-xr-x 15 dpat admin 510 Aug 14 17:07 data_slice_0017
>> > drwxr-xr-x 15 dpat admin 510 Aug 14 17:24 data_slice_0018
>> > drwxr-xr-x 15 dpat admin 510 Aug 14 17:41 data_slice_0019
>> > drwxr-xr-x 15 dpat admin 510 Aug 14 17:59 data_slice_0020
>> > drwxr-xr-x 15 dpat admin 510 Aug 14 18:18 data_slice_0021
>> > drwxr-xr-x 15 dpat admin 510 Aug 14 18:37 data_slice_0022
>> > drwxr-xr-x 15 dpat admin 510 Aug 14 18:58 data_slice_0023
>> > drwxr-xr-x 15 dpat admin 510 Aug 14 19:20 data_slice_0024
>> > drwxr-xr-x 15 dpat admin 510 Aug 14 19:43 data_slice_0025
>> > drwxr-xr-x 15 dpat admin 510 Aug 14 20:06 data_slice_0026
>> > drwxr-xr-x 3 dpat admin 102 Aug 14 20:06 data_slice_0027
>> >
>> > Does the time to run behavior of the new bedpost seem correct, given
>> the time of the old bedpost...and the gradual creep of time to run
>> each consecutive data slice?
>> > ---------------------
>> > Thanks for your time and thankyou for the lovely new toy!
>> >
>> > Dianne
>> >
>> > --
>> > 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)
>>
>>
>> ------------------------------------------------------------------------
>> ---
>> Stephen M. Smith, Professor of Biomedical Engineering
>> Associate Director, Oxford University FMRIB Centre
>>
>> FMRIB, JR Hospital, Headington, Oxford OX3 9DU, UK
>> +44 (0) 1865 222726 (fax 222717)
>> [log in to unmask] http://www.fmrib.ox.ac.uk/~steve
>> ------------------------------------------------------------------------
>> ---
>>
>>
>
>
> --
> Dianne Patterson, Ph.D.
> [log in to unmask]
> ERP Lab
> University of Arizona
> 621-3256 (Office)
|