[Mrtrix-discussion] Re: Mrtrix-discussion Digest, Vol 30, Issue 7

[Michael Zeineh]

Very helpful Donald and Thijs! Thank you.
 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Tue, 7 Jun 2011 10:40:40 +1000
> From: Donald Tournier <d.tournier at brain.org.au>
> Subject: Re: [Mrtrix-discussion] curvature
> To: Thijs Dhollander <thijs.dhollander at uzleuven.be>
> Cc: "mrtrix-discussion at public.nitrc.org"
> 	<mrtrix-discussion at public.nitrc.org>
> Message-ID: <BANLkTinAx3gXkSM1mB_Mae1FvN6jWY7RgA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
> 
> Hi Michael,
> 
> Thijs is right on the money with his explanation. Just for reference, the
> actual expression relating step-size and radius of curvature to the angle
> between successive steps is (src/dwi/tractography/tracker/base.h, line 83):
> 
> angle = 2 * asin (S / (2*R))
> 
> where:
>  S = step-size
>  R = radius of curvature
> 
> Hope that helps.
> Cheers,
> 
> Donald.
> 
> 
> On 6 June 2011 19:26, Thijs Dhollander <thijs.dhollander at uzleuven.be> wrote:
> 
>> One extra warning though (just popped into my mind): this does of course
>> not mean that the stepsize has no impact at all on the final result!  Here
>> goes a clear (and quite recent) example concerning the effect of the
>> stepsize om probabilistic tractography:
>> 
>> http://submissions.miracd.com/ismrm2011/proceedings/files/2019.pdf
>> 
>> Kind regards,
>> Thijs
>> 
>> -----Original Message-----
>> From: mrtrix-discussion-bounces at public.nitrc.org [mailto:
>> mrtrix-discussion-bounces at public.nitrc.org] On Behalf Of Thijs Dhollander
>> Sent: maandag 6 juni 2011 11:01
>> To: mrtrix-discussion at public.nitrc.org
>> Subject: RE: [Mrtrix-discussion] curvature
>> 
>> Hi Michael,
>> 
>> Imposing a certain curvature radius threshold on the tracks means that they
>> cannot bend in a sharper way than a circle (or a sphere) with that
>> particular radius does.  If the curvature radius threshold is smaller,
>> tracks are allowed to bend sharper.  (also see
>> http://en.wikipedia.org/wiki/Curvature for some figures)
>> 
>> My guess as to why MRtrix offers this option instead of an "angle
>> threshold", is that the curvature radius has the advantage of defining the
>> maximum "sharpness" of the tracks independently from the stepsize.
>> For example, if you were to impose an angle threshold of 40 degrees, this
>> number by itself does not define how sharp your tracks can globally bend: if
>> your stepsize would be 1mm, the tracks could bend sharper as compared to a
>> stepsize of 2mm.  But, if you specify a certain curvature radius threshold,
>> you can still play around freely with the stepsize without changing the
>> maximum bending properties of your tracks.
>> 
>> I hope this explanation is somewhat clear. :-)
>> 
>> Kind regards,
>> Thijs
>> 
>> 
>> Thijs Dhollander
>> PhD Student
>> 
>> thijs.dhollander at uz.kuleuven.ac.be
>> tel. +32 16 34 90 37
>> gsm. +32 475 36 44 27
>> 
>> Medical Image Computing (K.U.Leuven, ESAT/PSI, MIC)
>> Medical Imaging Research Center | UZ Gasthuisberg | Herestraat 49 - bus
>> 7003 | B-3000 Leuven | http://www.medicalimagingcenter.be
>> 
>> 
>> -----Original Message-----
>> From: mrtrix-discussion-bounces at public.nitrc.org [mailto:
>> mrtrix-discussion-bounces at public.nitrc.org] On Behalf Of Michael Zeineh
>> Sent: maandag 6 juni 2011 5:18
>> To: mrtrix-discussion at public.nitrc.org
>> Subject: [Mrtrix-discussion] curvature
>> 
>> Question re the curvature parameter in streamtrack.
>> 
>> I am familiar with curvature being a threshold such that a track won't make
>> a turn of more than 40 degrees or whatever threshold is chosen.
>> 
>> How does "curvature radius" in mm translate in the above conventional
>> angular terms as used in streamtrack?
>> 
>> Thank you,
>> Michael Zeineh
>> 
>> _______________________________________________
>> Mrtrix-discussion mailing list
>> Mrtrix-discussion at www.nitrc.org
>> http://www.nitrc.org/mailman/listinfo/mrtrix-discussion
>> _______________________________________________
>> Mrtrix-discussion mailing list
>> Mrtrix-discussion at www.nitrc.org
>> http://www.nitrc.org/mailman/listinfo/mrtrix-discussion
>> _______________________________________________
>> Mrtrix-discussion mailing list
>> Mrtrix-discussion at www.nitrc.org
>> http://www.nitrc.org/mailman/listinfo/mrtrix-discussion
>> 
> 
> 
> 
> -- 
> Jacques-Donald Tournier (PhD)
> Brain Research Institute, Melbourne, Australia
> Tel: +61 (0)3 9035 7033
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://www.nitrc.org/pipermail/mrtrix-discussion/attachments/20110607/85dbcc2f/attachment-0001.html
> 
> ------------------------------
> 
> Message: 2
> Date: Tue, 7 Jun 2011 10:45:39 +1000
> From: Donald Tournier <d.tournier at brain.org.au>
> Subject: Re: [Mrtrix-discussion] Can MRTRIX perform a probabilistic
> 	fibert	tracking using the residual bootstrap with CSD?
> To: Yong Li <yongli86 at gmail.com>
> Cc: mrtrix-discussion at www.nitrc.org
> Message-ID: <BANLkTikBj_6vuoXgdF9OZxDXrYBQZ8REsg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
> 
> Hi Yong,
> 
> Currently this is not possible. It might be available as part of exploreDTI,
> but I'm not sure. As to whether it'll be part of a future release of MRtrix:
> if there's enough demand for it, possibly. It's just a matter of finding the
> time to code it up within MRtrix. If anyone wants to give it a try, they're
> more than welcome, I'm open to contributions... :)
> 
> Cheers,
> 
> Donald.
> 
> 
> On 3 June 2011 21:56, Yong Li <yongli86 at gmail.com> wrote:
> 
>> Dear Ben & Donald,
>> 
>> Can MRTRIX perform a probabilistic fiber tracking using the residual
>> bootstrap with CSD? Or the next update? I am highly interested in explore
>> this application in the near future. Thank you very much to develop this
>> method!
>> 
>> Nice weekend!
>> 
>> Best regards,
>> 
>> Yong
>> 
>> _______________________________________________
>> Mrtrix-discussion mailing list
>> Mrtrix-discussion at www.nitrc.org
>> http://www.nitrc.org/mailman/listinfo/mrtrix-discussion
>> 
>> 
> 
> 
> -- 
> Jacques-Donald Tournier (PhD)
> Brain Research Institute, Melbourne, Australia
> Tel: +61 (0)3 9035 7033
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://www.nitrc.org/pipermail/mrtrix-discussion/attachments/20110607/b2cb9cbc/attachment-0001.html
> 
> ------------------------------
> 
> Message: 3
> Date: Tue, 7 Jun 2011 10:55:02 +1000
> From: Donald Tournier <d.tournier at brain.org.au>
> Subject: Re: [Mrtrix-discussion] Installation on CentoOS 5.6
> To: romain valabregue <romain.valabregue at upmc.fr>
> Cc: mrtrix-discussion at public.nitrc.org
> Message-ID: <BANLkTinz0aRX+Jif=bh5JULUQbPj7VDwNQ at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
> 
> Hi Romain,
> 
> I've also found it very difficult to install on CentOS. For some reason,
> even the latest version contains libraries that are at least 3-4 years
> old...
> 
> Anyway, I found that you can get it to work eventually by removing all
> references to the tooltips. This means you won't get all these helpful
> little hints popping up when you hover the mouse, which I'm guessing is
> something you can live with. I think that's all I needed to do, but there
> may be a few others I've forgotten about...
> 
> If you run:
> $ grep -rin --exclude=\*.svn\* --include=\*.h --include=\*.cpp tooltip .
> 
> within the MRtrix folder, you'll get a listing of all the lines to get rid
> off. Note it probably won't be just a matter of deleting those lines,
> there's a few associated functions to get rid of too, hopefully they'll be
> easy to spot.
> 
> Good luck,
> 
> Donald.
> 
> 
> 
> On 6 June 2011 19:05, romain valabregue <romain.valabregue at upmc.fr> wrote:
> 
>> Hello
>> 
>> Sorry if this question has already been posted.
>> I can not install mrtrix on an centos 5.6 64 bit server. (it seems that the
>> standard library are too old .. glib gtk+ ...)
>> Does any one ever succed ?
>> 
>> Thank for you help
>> _______________________________________________
>> Mrtrix-discussion mailing list
>> Mrtrix-discussion at www.nitrc.org
>> http://www.nitrc.org/mailman/listinfo/mrtrix-discussion
>> 
> 
> 
> 
> -- 
> Jacques-Donald Tournier (PhD)
> Brain Research Institute, Melbourne, Australia
> Tel: +61 (0)3 9035 7033
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://www.nitrc.org/pipermail/mrtrix-discussion/attachments/20110607/26c0a3af/attachment-0001.html
> 
> ------------------------------
> 
> Message: 4
> Date: Tue, 7 Jun 2011 17:23:14 +0200
> From: Luis Mor?s <luis.moris.fernandez at gmail.com>
> Subject: Re: [Mrtrix-discussion] tracks2prob, sample and resample
> 	doubts
> To: mrtrix-discussion at www.nitrc.org
> Message-ID: <BANLkTimmrGpcMEsvfOhi=TQt2xBw=q6rxQ at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> Hi Donald,
> 
> I've been digging a bit more in the rounding problem.
> 
> It doesn't seem to be a problem of rounding. I modified a bit the
> source code so I was able to see through which voxels the streamlines
> goes.
> 
> And discovered that my problem was the offset in the srow matrix in
> the nifti was wrongly calculated. In my case my original image voxel
> size  is a 1.25, 1.25, 2.5 mm. If I'd like to reduce the voxel size to
> 1 mm and my transform matrix is as follows:
> 
> Tm [0][0] Tm [0][1] Tm [0][2] Tm[0][3]
> Tm [1][0] Tm [1][1] Tm [1][2] Tm[1][3]
> Tm [2][0] Tm [2][1] Tm [2][2] Tm[2][3]
> 
> I only have to change the field refering to images dimensions by
> multplying it by the previous voxel size, and dividing it by the new
> voxel size. In this case the first dimension multiplied by 1.25 and
> divided by 1. And so for the rest of dimensions.
> 
> But I have to update the offset values in the transform matrix Tm
> [*][3] in some way cos as I've seen the values in the images produced
> by tracks2prob differs from the ones present in the template used (not
> so much just, between 0.125 and 0.75). So my question is if you could
> give a hand on this update and how is it supposed to be done.
> 
> 
> And my other inquiry is that I modified the code and now I'm able to
> see the voxel traversed by a streamline I found a curious fact.
> 
> I used your info function to print the voxel coordinates in:
> 
> TrackMapper<Voxel>::voxelise (...) definition. (tracks2prob.cpp line 295)
> 
> I print the coordinates returned by ->  interp.R2P(*i);
> 
> 
> 
> And I checked everything with my matlab function and they are
> identical. But, here comes the tricky part, all the coordinates in the
> nifti image are one unit bigger than the ones captured before.
> 
> If I track just one streamline and use tracks2prob, all the voxels
> which its value is one are the voxels traversed by the streamline so:
> 
> ie:
> 
> Capture coordinates in TrackMapper...
> 
> 
> x = 170, y = 30, z =3
> x = 170, y = 30, z =3
> x = 170, y = 31, z =3
> x = 170, y = 30, z =3
> x = 170, y = 30, z =4
> 
> Voxels with value 1
> 
> x= 171, y=31, z=4
> x= 171 y= 32, z=4
> x=171, y= 31, z=5
> 
> All the coordinates are one unit bigger. Does it make any sense? Have
> I captured the voxel coordinates in the wrong place?
> 
> 
> Best,
> 
> Luis.
> 
> On Fri, Jun 3, 2011 at 9:29 AM, Luis Morís
> <luis.moris.fernandez at gmail.com> wrote:
>> Hi Donald,
>> 
>> Thanks a lot for your help.
>> 
>> I have checked, and interpolation is set to 1, step size is default
>> 0.2 and voxel size of the map is 1 mm. So initially that's not the
>> problem.
>> 
>> The maps are really similar but not identical. Big picture is the
>> same, but when you go and check voxel values, they are different. So
>> maybe it's due to rounding errors.
>> 
>> Thanks again for your help, it has made things much more clear for me.
>> 
>> Best,
>> 
>> Luis.
>> 
>> On Fri, Jun 3, 2011 at 7:15 AM, Donald Tournier <d.tournier at brain.org.au> wrote:
>>> Hi Luis,
>>>> 
>>>> I'm trying to do a study with the streamlines produced by mrtrix.
>>>> 
>>>> My idea is to create an image similar to the one produced by
>>>> tracks2prob, but I have bumped into some problems.
>>>> 
>>>> I have created a function similar to tracks2prob into matlab. The idea
>>>> is really simple take the coordinates provided by streamtrack, and
>>>> load them into matlab (no problem here). Afterwards transform these
>>>> coordinates into voxel space, by using the transform matrix in the dwi
>>>> image, I round up the values and have the correct voxel coordinates.
>>>> But here I get a similar, but not identical, image as the one provided
>>>> by tracks2prob, I have checked the source code and it seems that this
>>>> process is not so straightforward, because some interpolation is made
>>>> along the way.
>>>> 
>>>> Could you explain the differences between my process and your process?
>>>> Is my idea correct or interpolation is a must fot the image to be
>>>> correct?
>>> 
>>> It sounds like you've got the right idea. I expect the differences you see
>>> are minimal? If not, then it could be due to the interpolation aspects.
>>> Basically, the interpolation that takes places is a resampling of the
>>> tracks, and by default it only happens if the step size is larger than half
>>> the voxel size. This is to avoid voxels being missed due to the sampling of
>>> the tracks being too coarse. You can check if this happening in your case by
>>> running the command with the "-info" option. It should then display a line
>>> stating what interpolation factor is actually being used (1 is no
>>> interpolation).
>>> If you weren't using interpolation, then there shouldn't be any difference
>>> between your output and tracks2prob's, apart potentially from slight
>>> differences caused by rounding errors. MRtrix operates on 32-bit floats,
>>> whereas I'd expect Matlab to operate on 64-bit doubles. This may cause
>>> slight differences which would be enough for some of the points to be
>>> assigned to different voxels. So basically, if the differences are limited
>>> to the odd voxel here and there, that's probably what the problem is.
>>> Otherwise, I'm not too sure...
>>> 
>>>> 
>>>> Is there a way of knowing which tracks are going through which voxel?
>>> 
>>> If you're asking, is there a command in MRtrix to do this, the answer is no,
>>> there is no such application.
>>> 
>>>> 
>>>> Or wich voxels do a track pass trough?
>>> 
>>> To find out which voxels a track pass through can be done using tracks2prob,
>>> if you can generate a track file with just the track you're interested in.
>>> You might be able to do this with a combination of "track_info -ascii" and
>>> "import_tracks".
>>> 
>>>> 
>>>> One of the parts of my study is related not only to the density of
>>>> tracks in a voxel, but with some scalars that will weight this density
>>>> or the contrary these scalar will be weighted by the track density.
>>>> i.e. Something similar to "The average pathlength map: a diffusion MRI
>>>> tractography-derived index for studying brain pathology. Pannek et
>>>> al." But for this purpose if I'm not wrong I need to know which tracks
>>>> pass through which voxel in order to calculate the average length of
>>>> the tracks that goes through a given voxel.
>>> 
>>> We've recently submitted a manuscript on a similar topic. You're right, to
>>> do this you'll need to know which tracks go through each voxel.
>>> 
>>>> 
>>>> So that's why I ask if there's some way of getting this information
>>>> with mrtrix. I can do it with matlab, but as far as my method is not
>>>> similar to the one you use I want to make sure my approach is correct.
>>> 
>>> Glad to hear it - this would be much better done in Matlab than using a
>>> combination of existing MRtrix commands...
>>> 
>>>> 
>>>> And a last question about sample and resample, if I have another image
>>>> for example Linear Anisotropy, I can use sample_tracks to obtain the
>>>> interpolated value of LA on each of the points of the track. And then
>>>> calculate for example the average LA in a given track. But as I've
>>>> read on the doc sample_tracks should be used with tracks produced by
>>>> resample_tracks to ensure even sampling. Why is that? Does not the
>>>> step size of 0.2 mm in streamtrack provide an even sampling? If I set
>>>> the -num (number of samples) parameter in resample_tracks to 100, All
>>>> tracks will have 100 points? Does that not do uneven sampling on
>>>> different size tracks? I mean do a 20 mm track have 100 samples, and a
>>>> 200 mm track also 100 samples?
>>> 
>>> There is no problem with using "sample_tracks" if you're simply interested
>>> in the average value over the tracks. The "resample_tracks" application just
>>> tries to ensure that for a set of tracks, all the sampling points are
>>> roughly equivalent in terms of their position along the track. This is of
>>> interest if you're interested in averaging values across tracks at
>>> corresponding positions. Not a problem in your case. I might amend the
>>> documentation for sample_tracks to avoid any further confusion...
>>> Cheers,
>>> Donald.
>>> 
>>> --
>>> Jacques-Donald Tournier (PhD)
>>> Brain Research Institute, Melbourne, Australia
>>> Tel: +61 (0)3 9035 7033
>>> 
>>> 
>> 
> 
> 
> ------------------------------
> 
> _______________________________________________
> Mrtrix-discussion mailing list
> Mrtrix-discussion at www.nitrc.org
> http://www.nitrc.org/mailman/listinfo/mrtrix-discussion
> 
> 
> End of Mrtrix-discussion Digest, Vol 30, Issue 7
> ************************************************