Hi,
Sounds like these two bits of software are not
playing happily together. As FSLView shows
images in the orientation which is stored on
disk (normally the original scanner orientation,
but with this amount of processing by other
things it could be anything). However, other
software will re-orient their images on the
fly using the nifti sform and qform information.
So this would explain why you can get two
different views and different behaviours from
the same image. What is most important is that
FSLView shows the labels in the correct places.
If that is true then that scan is OK.
I would also never expect matrices produced
by different packages to be at all comparable.
Sad, but true.
I think that if you want to keep your FSL steps
at the beginning and also do the third-party
tractography then you'll need to apply the FLIRT
matrix to the tractography output using FSL
tools, as that is what mapped the B0 to the
3D. If you do that it will probably work.
Of course you could also do the lot in FSL! :)
All the best,
Mark
On 22 Feb 2010, at 10:49, Danilo Scelfo wrote:
> ... hi there!
>
> It's been a while I'm trying to flush a challenging issue out for
> you (!) ...
> ... and finally I got it!
> Now, close this topic and come back with a cup of the during your
> coffee
> break and challenge yourself.
> (TEN points to first resolverman!)
>
> It's a matter of acpc registration and fiber tracking on 3dacpc
> visualization (actually, much simplier, it's a matter of left/right
> software's interface misunderstanding... but I manage to worsen
> simple issue!).
>
> Well, I'm going to show you the steps I'm used to perform to process
> MRI-DW
> data and anatomical images.
> Processed data are about a patient with a RIGHT neurological lesion.
>
> I'm going to show the different steps performed:
>
> I - 3D acpc alignment (using Mipav)
> Performing such a step I get a register volume (i.e. 3D_acpc.nii, by
> default) and a text file with, among all, the simple rotation matrix
> coefficient. Mipav output (3D_acpc.nii) is shown with the same
> orientation
> of the starting 3D volume (i.e. lesion on the LEFT - as it is in
> radiological format - and "anterior (A)" upwards). Transformation
> matrix
> shows a slight rotation close to (1 0 0, 0 1 0, 0 0 1);
>
> II - checking Mipav output (3Dacpc.nii) with FSLView...
> ...first surprise! Even though FSLView correctly recognizes image
> orientations (correct A-P, correct I-S, correct R(lesion)-L), it
> shows A
> downwards in axial view, and "leftwards" in sagittal view, i.e.
> exactly the
> opposite behaviour in visualizing 3D.nii originary file (i.e. A
> upwards in
> axial view and rightwards in sagittal view). Thanx God I-S direction
> are
> preserved!
>
> III - B0 and 3Dacpc registration (using FSL-FLIRT)
> To perform the registration, FLIRT applies to B0 volume a 180 degrees
> roto-translation about z-axis (second surprise). It seems like it
> detects
> 3Dacpc.nii wrong 180 degrees rotation reveiled by FSLView in the
> previous
> step. Tranformation matrix, indeed, it's something close to M = (-1
> 0 0, 0
> -1 0, 0 0 1). Such a processing, however, brings to a correct overlay
> between B0 and 3Dacpc, as verified using FSLView;
>
> IV - DT reconstruction and fiber tracking (using Diffusion Toolkit
> of TrackVis)
> Performing fiber tracking using DWI.nii acquisition dataset to get
> dti.trk
> fiber recostruction file;
>
> V - fiber tracking on 3D registration (using Tools of Diffusion
> Toolkit)
> At this point I perform dti.trk roto-translation using M
> registration matrix
> in 3Dacpc.mat file (step III output), in order to get fiber tracking
> and
> 3Dacpc.nii registered and.........
>
> VI - eventually, fiber tracking on 3Dacpc visualization (using
> TrackVis)...
> ... BOOM!!!!! Third surprise (linearly independent from previous
> ones!): it
> shows a wrong visualization of fiber tracts on the 3Cacpc volume. I.e.
> whilst 3Dacpc is well oriented (as FSLView did, that is in
> radiological
> format: A upwards on axial and R(lesion) on the left hand side), the
> tractography is wrongly superimposed, showing tracts of lesion
> emisphere on
> the right, that is upon sane emisphere.
>
> At this point I performed steps from III to VI without I and II,
> that is
> using 3D.nii originary dataset instead of performing acpc alignment.
> Astonishingly, final result of such a process is a correct
> visualization and
> superimposition on tracts on 3D volume.
>
> Now, TIME TO GUESS!!!
> It's seems clear to me that acpc alignment on step I performed by
> Mipav
> causes some kind of misund...orienting operation. Such operation is
> detected
> by FSLView at step II and by FLIRT at step III. Consequent
> registration at
> step III would suggest a 180 degrees rotation to TrackVis at step V
> but...
> TrackVis refuses to 180 degrees rotate tractography about z-axis
> (wrong
> operation, by the way), allowing only a y inversion, i.e. flipping
> right and
> left of trattography (even worst operation).
>
> Now, TIME FOR QUESTION...
>
> ... Is anybody out there?!?
>
|