JiscMail Logo
Email discussion lists for the UK Education and Research communities

Help for MRICRO Archives


MRICRO Archives

MRICRO Archives


MRICRO@JISCMAIL.AC.UK


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

MRICRO Home

MRICRO Home

MRICRO  April 2012

MRICRO April 2012

Options

Subscribe or Unsubscribe

Subscribe or Unsubscribe

Log In

Log In

Get Password

Get Password

Subject:

Re: Correct b-vectors for Philips Achieva scanner?

From:

Ed Gronenschild <[log in to unmask]>

Reply-To:

MRIcro users support list <[log in to unmask]>

Date:

Tue, 10 Apr 2012 15:00:35 +0200

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (344 lines)

Hi Harm,

I compared the derived set of vi vectors with the output
from dcm2nii and not directly with the set stored in
the DICOM header, because I don't know where to find it.
Apart from small differences and the used coordinate
system these were the same.
So, the final conclusion is that dcm2nii produces a
correct set of b-vectors for the three types of scanners
used, viz., Siemens, Philips, and GE.

Cheers,
Ed


On 5 Apr 2012, at 18:46, Michael Harms wrote:

>
> Hi Ed,
> What you did sounds reasonable.  (I believe that "M" is frequently
> defined as the transpose of how you formed it, but transpose(M) =  
> inv(M)
> in this case, so it doesn't matter in your calculation of the rotated
> ("vi") bvecs).  Note that your resulting "vi" bvecs would still have
> been in the +LPS DICOM orientation, so if your DICOM to NIFTI  
> conversion
> software returned a more typical +LAS or +RAS orientation, you'd  
> need to
> take account of that as well.
>
> I think I missed one step in what you did:  Are you saying that you
> compared your "vs" and "vi" versions of the bvecs to those stored  
> in the
> DICOM header?  If so, then what you did makes sense to me.
>
> I know that dcm2nii gives users control over whether the bvecs  
> stored in
> the DICOM header are rotated or not for Siemens data (with the default
> being to rotate).  What was the default behavior of dcm2nii for  
> your GE
> Signa HDxt and Philips Achieva DICOMs?
>
> As for small differences in your "vi" (rotated) bvecs and those  
> returned
> by dcm2nii, the bvecs stored by Siemens in their DICOMs includes the
> impact of both the diffusion and imaging-related gradients on the bvec
> calculation.  Thus, the bvecs returned by dcm2nii (which are a rotated
> version of what is in the DICOM) are technically a bit more accurate
> than simply yourself rotating the original diffusion-only gradient
> table.
>
> cheers,
> -MH
>
>
> On Thu, 2012-04-05 at 11:06 +0200, Ed Gronenschild wrote:
>> Hi Harm,
>>
>>
>> I may have solved the problem by doing the following exercise.
>> For each scanned individual I extracted the ImageOrientationPatient
>> atribute (tag 20,37) from the DICOM header and converted this
>> into a 3 x 3 matrix M:
>>
>>
>> - first 3 elements representing the read direction go into
>> the first row of M
>> - last 3 elements representing the phase direction go into
>> the second row of M
>> - cross product of both go into the third row of M.
>>
>>
>> From each institute I got the table of b-vecs with reference to the
>> scanner bore ("vs"). To get the b-vecs with reference to the imaging
>> plane ("vi") I took the product
>>
>>
>> vi = M-1 * vs,
>>
>>
>> where M-1 is the inverse of M.
>> Correct me if this is wrong. What I noticed is that there are small
>> differences with the b-vecs dcm2nii outputs. I don't know why.
>>
>>
>> I went through all scanned individuals for each scanner type and
>> selected the one with the largest angulation. Then I computed
>> two sets of tensors + eigenvectors + FA with FSL, one set with
>> the vectors vs and one set with the vectors vi, and viewed the
>> first eigenvector field on top of FA.
>> Especially the cingulum is very sensitive and from the comparison
>> between these two it is very easily to find out which set of b-vecs
>> should be used (at least for an angulation of > 25 degrees)
>> Results:
>>
>>
>> GE (Signa HDxt):
>> vectors should not be rotated, the scanner does it. So the b-vecs
>> stored in the DICOM header are always with reference to the
>> imaging plane.
>>
>>
>> Philips (Achieva) and Siemens (TrioTim):
>> vectors should be rotated, they are stored in the DICOM header
>> with reference to the scanner bore.
>>
>>
>> So this method could be an alternative to the method you described
>> and which requires additional scans. Unforunately, these additional
>> scans could not be made anymore (project is finished), so that's why
>> I had recourse to this method.
>>
>>
>> Cheers,
>> Ed
>>
>>
>> On 16 Mar 2012, at 10:10, Michael Harms wrote:
>>
>>
>>>
>>>
>>> Date:    Fri, 16 Mar 2012 10:10:33 -0500
>>> From:    Michael Harms <[log in to unmask]>
>>> Subject: Re: Correct b-vectors for Philips Achieva scanner?
>>>
>>>
>>> Hi Ed,
>>> Sorry, but I can't be of much help on Philips specific questions.
>>> You'll have to talk with your local Philips experts and/or MR
>>> physicist,
>>> or network with other Philips sites.  Those individuals should be
>>> able
>>> to also point you to how/where Philips codes the bvec info in their
>>> DICOMs, so that you'll then be able to compare to the output of
>>> dcm2nii.
>>>
>>>
>>> You haven't clarified whether all the various acquisitions were
>>> acquired
>>> in an oblique plane or not.
>>>
>>>
>>> Regarding GE: If you have oblique acquisitions, and get the same b-
>>> vec
>>> for each individual, that *could* mean that GE is itself rotating
>>> the
>>> bvecs into the imaging axes, or it *could* instead simply mean that
>>> the
>>> bvecs are always played out in the frame of the gradients, and
>>> reported
>>> in those axes as well.  The fact that they are the same across
>>> individuals doesn't allow you to in itself distinguish between these
>>> two
>>> very different situations.
>>>
>>>
>>> Further complicating the situation, I don't know what it is like for
>>> GE,
>>> but on the Siemen's, the user actually has low-level control as to
>>> whether the bvecs are played out in the gradient frame or the
>>> imaging
>>> axes frame.  The "frame" that the directions are then saved in the
>>> DICOMs is a further, entirely different matter, adding further
>>> complication.
>>>
>>>
>>> There really is so much potentially at play at all these various
>>> levels
>>> that I'd suggest you just do the empirical testing that we outlined
>>> for
>>> each scanner platform and software version for which you are using
>>> data.
>>> The tests that we proposed in that document for oblique acquisitions
>>> are
>>> relatively simple, and the benefit is that you know your results are
>>> applicable to the specific combination of scanner, sequence, and
>>> software version that you're using.
>>>
>>>
>>> Sorry I can't be of more specific help for the Philips and GE
>>> platforms,
>>> but as I said, this whole area is a mess, because to my knowledge
>>> there
>>> is no standard convention across platforms.
>>>
>>>
>>> BTW: For Siemen's data, the "bvecs_old" returned by dcm2nii are the
>>> bvecs prior to rotation into the imaging axes, and should match what
>>> is
>>> stored as the bvec info in the Siemens DICOMs.
>>>
>>>
>>> cheers,
>>> -MH
>>>
>>>
>>>
>>>
>>> On Fri, 2012-03-16 at 12:20 +0100, Ed Gronenschild wrote:
>>>> Hi Harm,
>>>>
>>>>
>>>>
>>>>
>>>> I'm sorry to bother you with all these questions.
>>>> Perhaps I formulated my question not so well.
>>>> What I would like to know is if dcm2nii is able
>>>> to correctly extract the b-vectors from the DICOM
>>>> header produced by this model of Philips scanners.
>>>> Let me clarify this.
>>>>
>>>>
>>>>
>>>>
>>>> With regards to the GE scanner (model Signa HDxt):
>>>> all extracted b-vectors are the same for each individual,
>>>> although each time the angulation of the imaging plane
>>>> differs. So I guess that GE co-rotates the vectors with the
>>>> slice direction before the actual scan is made.
>>>>
>>>>
>>>>
>>>>
>>>> Could it be that Philips Achieva does the same? Is there
>>>> perhaps someone who analysed test datasets from this
>>>> scanner the way you described in one of your documents?
>>>> Anywhay, what I notice is that for each individual the
>>>> extracted vectors differ. From the read and phase direction
>>>> info in the DICOM header I constructed the transformation
>>>> matrix and if I apply that to the vectors put into the scan
>>>> protocol (so referring to the scanner bore; I got these from
>>>> a technician) I get exactly the same vectors as dcm2nii
>>>> yields. So that looks good, but...is that really what happens
>>>> in this scanner?
>>>>
>>>>
>>>>
>>>>
>>>> By the way: I have no idea how the vectors are coded
>>>> into the DICOM header because I don't know these
>>>> private Philips tags.
>>>>
>>>>
>>>>
>>>>
>>>> Another related question: when I apply dcm2nii to
>>>> Siemens data I get a list with vectors and directions.
>>>> What does "bvecs_old" mean?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Cheers,
>>>> Ed
>>>>
>>>>
>>>> On 15 Mar 2012, at 12:12, Michael Harms wrote:
>>>>
>>>>
>>>>> Date:    Thu, 15 Mar 2012 12:12:55 -0500
>>>>>
>>>>>
>>>>> From:    Michael Harms <[log in to unmask]>
>>>>>
>>>>>
>>>>> Subject: Re: Correct b-vectors for Philips Achieva scanner?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Hi Ed,
>>>>>
>>>>>
>>>>> As I wrote previously, the "correct" frame for your bvecs will
>>>>> depend on
>>>>>
>>>>>
>>>>> a variety of factors, including potentially the software that
>>>>> you
>>>>> are
>>>>>
>>>>>
>>>>> using for the processing.  Do the bvecs as returned by dcm2nii
>>>>> differ
>>>>>
>>>>>
>>>>> from those that Philips codes into the DICOM header?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> cheers,
>>>>>
>>>>>
>>>>> -MH
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Thu, 2012-03-15 at 18:05 +0100, Ed Gronenschild wrote:
>>>>>
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> We are using a Philips Achieva scanner and I'm wondering if
>>>>>> dcm2nii
>>>>>>
>>>>>>
>>>>>> will extract the correct b-vectors from the DICOM headers of
>>>>>> the
>>>>>>
>>>>>>
>>>>>> DTI data?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>>
>>>>>> Ed
>>>>>>
>>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> ------------------------------
>>>
>>>
>>> End of MRICRO Digest - 15 Mar 2012 to 16 Mar 2012 (#2012-10)
>>> ************************************************************
>>
>

Top of Message | Previous Page | Permalink

JISCMail Tools


RSS Feeds and Sharing


Advanced Options


Archives

April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
September 2013
August 2013
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
July 2012
May 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
August 2011
July 2011
June 2011
May 2011
April 2011
March 2011
February 2011
December 2010
November 2010
October 2010
August 2010
July 2010
June 2010
March 2010
February 2010
January 2010
December 2009
November 2009
October 2009
September 2009
August 2009
July 2009
June 2009
May 2009
April 2009
March 2009
February 2009
January 2009
December 2008
November 2008
October 2008
September 2008
August 2008
July 2008
June 2008
May 2008
April 2008
March 2008
February 2008
January 2008
December 2007
November 2007
October 2007
September 2007
August 2007
July 2007
June 2007
May 2007
April 2007
March 2007
February 2007
January 2007
2006
2005
2004
2003


WWW.JISCMAIL.AC.UK

Secured by F-Secure Anti-Virus CataList Email List Search Powered by the LISTSERV Email List Manager