Hi Luis,<div><br>I've been digging a bit more in the rounding problem.<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
It doesn't seem to be a problem of rounding. I modified a bit the<br>
source code so I was able to see through which voxels the streamlines<br>
goes.<br></blockquote><div><br></div><div>Good to hear.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
And discovered that my problem was the offset in the srow matrix in<br>
the nifti was wrongly calculated. In my case my original image voxel<br>
size is a 1.25, 1.25, 2.5 mm. If I'd like to reduce the voxel size to<br>
1 mm and my transform matrix is as follows:<br>
<br>
Tm [0][0] Tm [0][1] Tm [0][2] Tm[0][3]<br>
Tm [1][0] Tm [1][1] Tm [1][2] Tm[1][3]<br>
Tm [2][0] Tm [2][1] Tm [2][2] Tm[2][3]<br>
<br>
I only have to change the field refering to images dimensions by<br>
multplying it by the previous voxel size, and dividing it by the new<br>
voxel size. In this case the first dimension multiplied by 1.25 and<br>
divided by 1. And so for the rest of dimensions.<br>
<br>
But I have to update the offset values in the transform matrix Tm<br>
[*][3] in some way cos as I've seen the values in the images produced<br>
by tracks2prob differs from the ones present in the template used (not<br>
so much just, between 0.125 and 0.75). So my question is if you could<br>
give a hand on this update and how is it supposed to be done.<br></blockquote><div><br></div><div>Yes, dealing with transform matrices also gives me a headache. In your case, I think the answer is thankfully pretty simple. Assuming you're sticking to the same origin (i.e. the bottom corner of your dataset is still in the same place with respect to real space), then the offset you're seeing is due to the fact that technically the offset field provides the displacement from the origin to the <i>middle</i> of the voxel at (0,0,0). If the actual corner is to remain the same, you need to adjust the offset slightly to account for that. </div>
<div><br></div><div>Basically, you want the outside edges of the voxel at (0,0,0) to remain the same. These are at (-Vx/2, -Vy/2, -Vz/2), where Vx, Vy, Vz are your voxel sizes. So to maintain this position after a change of voxel size, the offset needs to change by (Vx/2-Vx'/2, Vy/2-Vy'/2, Vz/2-Vz'/2), where Vx', Vy', Vz' are the new voxel sizes. Given your voxel dimensions, this equate to a correction of (0.125, 0.125, 0.75). which is precisely what you're seeing.</div>
<meta http-equiv="content-type" content="text/html; charset=utf-8"><meta http-equiv="content-type" content="text/html; charset=utf-8"><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
And my other inquiry is that I modified the code and now I'm able to<br>
see the voxel traversed by a streamline I found a curious fact.<br>
<br>
I used your info function to print the voxel coordinates in:<br>
<br>
TrackMapper<Voxel>::voxelise (...) definition. (tracks2prob.cpp line 295)<br>
<br>
I print the coordinates returned by -> interp.R2P(*i);<br>
<br>
<br>
<br>
And I checked everything with my matlab function and they are<br>
identical. But, here comes the tricky part, all the coordinates in the<br>
nifti image are one unit bigger than the ones captured before.<br>
<br>
If I track just one streamline and use tracks2prob, all the voxels<br>
which its value is one are the voxels traversed by the streamline so:<br>
<br>
ie:<br>
<br>
Capture coordinates in TrackMapper...<br>
<br>
<br>
x = 170, y = 30, z =3<br>
x = 170, y = 30, z =3<br>
x = 170, y = 31, z =3<br>
x = 170, y = 30, z =3<br>
x = 170, y = 30, z =4<br>
<br>
Voxels with value 1<br>
<br>
x= 171, y=31, z=4<br>
x= 171 y= 32, z=4<br>
x=171, y= 31, z=5<br>
<br>
All the coordinates are one unit bigger. Does it make any sense? Have<br>
I captured the voxel coordinates in the wrong place?<br><br></blockquote><div><br></div><div>This depends on how you're displaying the coordinates in your Matlab function. In MRtrix, everything is indexed from zero, whereas in Matlab, indices start from 1. Does that explain the difference? </div>
<div><br></div><div>Cheers,</div><div><br></div><div>Donald.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Best,<br>
<font color="#888888"><br>
Luis.<br>
</font><div><div></div><div class="h5"><br>
On Fri, Jun 3, 2011 at 9:29 AM, Luis Morís<br>
<<a href="mailto:luis.moris.fernandez@gmail.com">luis.moris.fernandez@gmail.com</a>> wrote:<br>
> Hi Donald,<br>
><br>
> Thanks a lot for your help.<br>
><br>
> I have checked, and interpolation is set to 1, step size is default<br>
> 0.2 and voxel size of the map is 1 mm. So initially that's not the<br>
> problem.<br>
><br>
> The maps are really similar but not identical. Big picture is the<br>
> same, but when you go and check voxel values, they are different. So<br>
> maybe it's due to rounding errors.<br>
><br>
> Thanks again for your help, it has made things much more clear for me.<br>
><br>
> Best,<br>
><br>
> Luis.<br>
><br>
> On Fri, Jun 3, 2011 at 7:15 AM, Donald Tournier <<a href="mailto:d.tournier@brain.org.au">d.tournier@brain.org.au</a>> wrote:<br>
>> Hi Luis,<br>
>>><br>
>>> I'm trying to do a study with the streamlines produced by mrtrix.<br>
>>><br>
>>> My idea is to create an image similar to the one produced by<br>
>>> tracks2prob, but I have bumped into some problems.<br>
>>><br>
>>> I have created a function similar to tracks2prob into matlab. The idea<br>
>>> is really simple take the coordinates provided by streamtrack, and<br>
>>> load them into matlab (no problem here). Afterwards transform these<br>
>>> coordinates into voxel space, by using the transform matrix in the dwi<br>
>>> image, I round up the values and have the correct voxel coordinates.<br>
>>> But here I get a similar, but not identical, image as the one provided<br>
>>> by tracks2prob, I have checked the source code and it seems that this<br>
>>> process is not so straightforward, because some interpolation is made<br>
>>> along the way.<br>
>>><br>
>>> Could you explain the differences between my process and your process?<br>
>>> Is my idea correct or interpolation is a must fot the image to be<br>
>>> correct?<br>
>><br>
>> It sounds like you've got the right idea. I expect the differences you see<br>
>> are minimal? If not, then it could be due to the interpolation aspects.<br>
>> Basically, the interpolation that takes places is a resampling of the<br>
>> tracks, and by default it only happens if the step size is larger than half<br>
>> the voxel size. This is to avoid voxels being missed due to the sampling of<br>
>> the tracks being too coarse. You can check if this happening in your case by<br>
>> running the command with the "-info" option. It should then display a line<br>
>> stating what interpolation factor is actually being used (1 is no<br>
>> interpolation).<br>
>> If you weren't using interpolation, then there shouldn't be any difference<br>
>> between your output and tracks2prob's, apart potentially from slight<br>
>> differences caused by rounding errors. MRtrix operates on 32-bit floats,<br>
>> whereas I'd expect Matlab to operate on 64-bit doubles. This may cause<br>
>> slight differences which would be enough for some of the points to be<br>
>> assigned to different voxels. So basically, if the differences are limited<br>
>> to the odd voxel here and there, that's probably what the problem is.<br>
>> Otherwise, I'm not too sure...<br>
>><br>
>>><br>
>>> Is there a way of knowing which tracks are going through which voxel?<br>
>><br>
>> If you're asking, is there a command in MRtrix to do this, the answer is no,<br>
>> there is no such application.<br>
>><br>
>>><br>
>>> Or wich voxels do a track pass trough?<br>
>><br>
>> To find out which voxels a track pass through can be done using tracks2prob,<br>
>> if you can generate a track file with just the track you're interested in.<br>
>> You might be able to do this with a combination of "track_info -ascii" and<br>
>> "import_tracks".<br>
>><br>
>>><br>
>>> One of the parts of my study is related not only to the density of<br>
>>> tracks in a voxel, but with some scalars that will weight this density<br>
>>> or the contrary these scalar will be weighted by the track density.<br>
>>> i.e. Something similar to "The average pathlength map: a diffusion MRI<br>
>>> tractography-derived index for studying brain pathology. Pannek et<br>
>>> al." But for this purpose if I'm not wrong I need to know which tracks<br>
>>> pass through which voxel in order to calculate the average length of<br>
>>> the tracks that goes through a given voxel.<br>
>><br>
>> We've recently submitted a manuscript on a similar topic. You're right, to<br>
>> do this you'll need to know which tracks go through each voxel.<br>
>><br>
>>><br>
>>> So that's why I ask if there's some way of getting this information<br>
>>> with mrtrix. I can do it with matlab, but as far as my method is not<br>
>>> similar to the one you use I want to make sure my approach is correct.<br>
>><br>
>> Glad to hear it - this would be much better done in Matlab than using a<br>
>> combination of existing MRtrix commands...<br>
>><br>
>>><br>
>>> And a last question about sample and resample, if I have another image<br>
>>> for example Linear Anisotropy, I can use sample_tracks to obtain the<br>
>>> interpolated value of LA on each of the points of the track. And then<br>
>>> calculate for example the average LA in a given track. But as I've<br>
>>> read on the doc sample_tracks should be used with tracks produced by<br>
>>> resample_tracks to ensure even sampling. Why is that? Does not the<br>
>>> step size of 0.2 mm in streamtrack provide an even sampling? If I set<br>
>>> the -num (number of samples) parameter in resample_tracks to 100, All<br>
>>> tracks will have 100 points? Does that not do uneven sampling on<br>
>>> different size tracks? I mean do a 20 mm track have 100 samples, and a<br>
>>> 200 mm track also 100 samples?<br>
>><br>
>> There is no problem with using "sample_tracks" if you're simply interested<br>
>> in the average value over the tracks. The "resample_tracks" application just<br>
>> tries to ensure that for a set of tracks, all the sampling points are<br>
>> roughly equivalent in terms of their position along the track. This is of<br>
>> interest if you're interested in averaging values across tracks at<br>
>> corresponding positions. Not a problem in your case. I might amend the<br>
>> documentation for sample_tracks to avoid any further confusion...<br>
>> Cheers,<br>
>> Donald.<br>
>><br>
>> --<br>
>> Jacques-Donald Tournier (PhD)<br>
>> Brain Research Institute, Melbourne, Australia<br>
>> Tel: +61 (0)3 9035 7033<br>
>><br>
>><br>
><br>
</div></div><div><div></div><div class="h5">_______________________________________________<br>
Mrtrix-discussion mailing list<br>
<a href="mailto:Mrtrix-discussion@www.nitrc.org">Mrtrix-discussion@www.nitrc.org</a><br>
<a href="http://www.nitrc.org/mailman/listinfo/mrtrix-discussion" target="_blank">http://www.nitrc.org/mailman/listinfo/mrtrix-discussion</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Jacques-Donald Tournier (PhD)<br>Brain Research Institute, Melbourne, Australia<br>Tel: +61 (0)3 9035 7033<br>
</div>