[Mrtrix-discussion] fibre tracts format

Tue Jun 8 23:33:36 PDT 2010

Hello again,

Yes, I agree that's not exactly the expected result. Your response function
seems a little 'podgy'. Have you checked your single-fibre mask to make sure
it includes only deep white-matter, high-FA (i.e. single-fibre) voxels?
That's the most likely source of error for that step. You may need to try
different thresholds for that step, and/or edit it manually if need be
(instructions for doing that in MRView are in the documentation). Using a
better response is also likely to significantly improve the CSD part...
Cheers,

Donald.

On 9 June 2010 02:15, Philip G Batchelor <philip.batchelor at kcl.ac.uk> wrote:

>  Hi again
>
> following going to debugging mode, and your instructions about 34 datasets,
> the crash disappeared (??), and I was able to run CSD, but the CSD file is
> clearly not right, lots of non-convergence messages, and image looks
> corrupted (see screenshot). For info, standard DTI looks fine.
>
> I guess the response function estimation is not correct? (NB: I tried
> changing order but didn't improve)
>
>
> Ph
>
>
>
> On 05/06/10 01:50, Donald Tournier wrote:
>
> OK, I'm really stumped... The only place in the code where that error
> message could have come from is in accessing the image for an MRtrix format
> (.mif) file. The "mrinfo" commands that you ran also will have run through
> those sections of code, but neither of them crashed... The actual headers
> for both images look fine to me. Guess we're going to have to dig deeper...
>
>  By the way, I doubt that the extra 34th volume is the issue, although you
> might need to deal with that separately - more on that later.
>
>  For now, let's try this. Copy these commands into a terminal (and amend
> as required), and then copy/paste the entire terminal session and post it
> back here:
>
>  # build debug version of code:
> $ cd <MRtrix source folder>
> $ ./build clean
> $ ./build -debug
>  $ export PATH=`pwd`/bin:$PATH
> $ export LD_LIBRARY_PATH=`pwd`/lib
>
>  # check that you're running the freshly built version (build date should
> be today):
> $ mrinfo --version
>
>  # first cut:
> $ cd <your data folder>
> $ estimate_response dwi.mif sf.mif  response.txt -debug
>
>  # debugger output:
> $ gdb --args dwi.mif sf.mif  response.txt -debug
> (gdb) run
> (gdb) bt full
>
>  If after all this, I still can't figure it out, you might want to send me
> the data so I can have a look at it...
>
>
>  Back to the extra 34th dataset issue: it shouldn't affect the CSD and
> tracking processes directly, but it will affect the DT calculations. That
> will affect the estimate_response stage, since it uses the highest FA voxels
> as 'single-fibre' voxels, and uses the primary eigenvector as the primary
> orientation. So you'll need to take care of that manually. Here's how:
>
>  # extract the DW scheme from the DWI:
> $ mrinfo dwi.mif -grad encoding.b
>
>  # remove the last volume from the DWI:
> $ mrconvert dwi.mif -coord 3 0:32 dwi2.mif
>
>  # remove the last line from the encoding file:
> $ head -n 33 encoding.b > encoding2.b
>
>  # use the amended DWI and encoding files whenever requried, e.g.:
> $ dwi2tensor dwi2.mif -grad encoding2.b dti.mif
>
>
>  OK, that should do for now...
> Cheers,
>
>  Donald.
>
>
>
>
>  On 5 June 2010 01:50, Philip G Batchelor <philip.batchelor at kcl.ac.uk>wrote:
>
>>  Hi
>>
>> thanks, output is attached, I see it has recognised the data as being DTI
>> which is good. On the other hand, it's a 32 directions scan with one b=0,
>> and I see
>> dim: 112,112,60*,34*
>>
>> could it be that it has fallen foul of the cheeky 34th dataset which
>> Philips add, an isotropic DW image? caused issues with quite a few of our
>> codes, ppl always forget about it.
>>
>> Ph
>>
>>
>> On 04/06/10 05:54, Donald Tournier wrote:
>>
>> Hi Philip,
>>
>>  Sounds a bit odd. To narrow things down a bit, could you post the output
>> of the following:
>>
>>  $ mrinfo dwi.mif
>> $ mrinfo sf.mif
>>  $ awk '{ if ($0=="END") exit 0; print $0 }' dwi.mif
>>  $ awk '{ if ($0=="END") exit 0; print $0 }' sf.mif
>> $ ls -l dwi.mif sf.mif
>>
>>  That should give me a bit more info...
>> Cheers,
>>
>>  Donald.
>>
>>
>> On 3 June 2010 01:49, Philip G Batchelor <philip.batchelor at kcl.ac.uk>wrote:
>>
>>> On 12/03/10 00:38, Donald Tournier wrote:
>>>
>>> This message has been archived.  View the original item
>>> <https://kclev.kcl.ac.uk/EnterpriseVault/ViewMessage.asp?VaultId=1CFCE6957FBD5654F8CCD18F833B7A6301110000kcl-evsite01&SavesetId=730000000000000%7E201003120038120000%7E0%7EE7E2A350A97B45AD91183E4EEB3B887>
>>>  Hi Philip, Sorry, there is currently no documentation on that file
>>> format... It is quite simple, though. It consists of a text header, followed
>>> by binary data. The first line of the text header
>>>  Attachments:
>>>   read_mrtrix_tracks.m
>>> <https://kclev.kcl.ac.uk/EnterpriseVault/ViewMessage.asp?VaultId=1CFCE6957FBD5654F8CCD18F833B7A6301110000kcl-evsite01&SavesetId=730000000000000%7E201003120038120000%7E0%7EE7E2A350A97B45AD91183E4EEB3B887&AttachmentId=1> (2
>>> KB)
>>>
>>>
>>>
>>> Hi
>>>
>>> am trying to process some of the Philips DICOM we acquired, in order to
>>> perform CSD. At the estimate_response stage it crashes, something went wrong
>>> with 'axes specification' but nore sure what. Here is the sequence of
>>> operation I go though:
>>>
>>>     $ mrconvert -info DICOM/ ./mrtrix-data/dwi.mif
>>>     [...]
>>>
>>>     $ mrconvert dwi.mif -coord 3 0 - | threshold - - | median3D - - |
>>> median3D - mask.mif
>>>      [...]
>>>
>>>     $ dwi2tensor dwi.mif dti.mif
>>>     [...]
>>>
>>>     $ tensor2FA dti.mif - | mrmult - mask.mif fa.mif
>>>     $ erode mask.mif - | erode - - | mrmult fa.mif - - | threshold - -abs
>>> 0.6 sf.mif
>>>     $ estimate_response dwi.mif sf.mif  response.txt
>>>
>>>       estimate_response: incorrect number of axes in axes specification
>>> "-0,-1,+2,+3"
>>>       *** glibc detected *** estimate_response: free(): invalid next size
>>> (fast): 0x000000000194c420 ***
>>>       ======= Backtrace: =========
>>>      /lib/libc.so.6(+0x775b6)[0x7f4f4d5065b6]
>>>     /lib/libc.so.6(cfree+0x73)[0x7f4f4d50ce53]
>>>     etc...
>>>
>>> Am trying to diagnose if I'm doing some basic error, or if there's  a
>>> problem with the way the axes are read from the DICOMS?
>>> Any suggestion?
>>>
>>> Ph
>>>
>>
>>
>>
>> --
>> Jacques-Donald Tournier (PhD)
>> Brain Research Institute, Melbourne, Australia
>> Tel: +61 (0)3 9496 4078
>>
>>
>>
>
>
> --
> Jacques-Donald Tournier (PhD)
> Brain Research Institute, Melbourne, Australia
> Tel: +61 (0)3 9496 4078
>
>
>

-- 
Jacques-Donald Tournier (PhD)
Brain Research Institute, Melbourne, Australia
Tel: +61 (0)3 9496 4078
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.nitrc.org/pipermail/mrtrix-discussion/attachments/20100609/5f7defd0/attachment.html