 |
 |
Hi Michael, hmm - I was told by Siemens. However, you are right the the patient coordinate system depends on the registering which determines the relation of the patient coordinate system to XYZ and PRS. In any case, there is a fixed relation of the three, i.e. you must know which coordinate system you are operating in but can go from one to the other. There is a fix in VB17 in how the values are estimated from the b matrix. I have found MRIconvert and dcm2nii to be generally correct (in VB15 there could arise intances of an invers solution). Maybe you should ask Siemens directly? Please let me know and keep me posted. The text file (if you used one) that specifices the gradient directions has the option to defines these in PRS but that should not affect the DICOM entry. Hmm. Keep me posted, ok? Cheers, Andreas ________________________________________ Von: FSL - FMRIB's Software Library [[log in to unmask]] im Auftrag von Michael Harms [[log in to unmask]] Gesendet: Mittwoch, 23. März 2011 18:05 An: [log in to unmask] Betreff: Re: [FSL] AW: [FSL] DTI bvecs - dcm2nii vs. mriconvert vs. dtistudio vs. siemens VB15 official tables Hello Andreas (and any others that want to chime in), I'd like to revive this thread to ask for clarification on something you wrote. You wrote: "Siemens follows the DICOM conventions, i.e. all data are stored in the patient coordinate system (as opposed to the magnet's XYZ or the sequence's PRS). Normally, diffusion gradients are applied in XYZ, therefore Siemens values from the DICOM header ARE ALREADY rotated according to the slice angulation." In particular, my understanding is that the final aspect of that statement is not correct. Namely, my understanding is that the DICOM "patient coordinate system" is a +LPS coordinate system, which is still aligned with the physical magnet/gradient axes but with axes flipped as necessary depending on how the patient was registered as laying on the table (e.g., "head-first-supine" vs. "head-first-prone"). That is, I would NOT expect the diffusion gradients reported in the DICOMs for Siemen's VB13-VB17 software to be already rotated for slice angulation in the case of oblique acquisitions. (That is not what "patient coordinate system" implies, again as I understand it). This is easy enough to test empirically, and indeed when I did that, my findings were consistent with the reported gradient directions (from the DiffusionGradientDirection private field entry in the DICOM) NOT being rotated into the phase-read-slice axes of the imaging grid for an oblique acquisition, but rather being aligned with the XYZ axes of the physical magnet/gradient axes. Best, -MH On Wed, 2010-05-26 at 21:27 -0400, Fred Tam wrote: > Thanks Andreas. Your explanation is similar to what Susumu Mori just > replied on the DTIStudio list. So I won't worry about the "official" > table I received from Siemens. > > Do you happen to know what circumstances cause wrong diffusion vectors > to be stored in the DICOMs under VB15? We have not yet updated to VB17, > and we have loads of old and unanalyzed data too. > > I will try to find out more about the other question I had about > dcm2nii's inconsistency with MRIConvert and DTIStudio. I'm just writing > an email to Chris Rorden right now. > > Fred > > > On Wed, 2010-05-26 at 14:43 +0200, Andreas Bartsch wrote: > > Hi Fred, > > > > the diffusion vector data in Siemen's DICOM header are 'back' calculated from the b-matrix. Prior to VB17 this could in some occasions lead to a 'wrong' inverse solution. It has been fixed from VB17 on. Small differences between the Siemens solution and the other software are due to the fact that Siemens accounts for the impact of the imaging gradients on the effective b-matrix. Thus, anything stored in the DICOM header from VB17 on should be authorative and the best available solution. I think Jolinda's MRIConvert now uses these entries. > > Also: Siemens follows the DICOM conventions, i.e. all data are stored in the patient coordinate system (as opposed to the magnet's XYZ or the sequence's PRS). Normally, diffusion gradients are applied in XYZ, therefore Siemens values from the DICOM header ARE ALREADY rotated according to the slice angulation. > > Does that make sense? > > Cheers- > > Andreas > > > > ________________________________________ > > Von: FSL - FMRIB's Software Library [[log in to unmask]] im Auftrag von Fred Tam [[log in to unmask]] > > Gesendet: Mittwoch, 26. Mai 2010 03:03 > > An: [log in to unmask] > > Betreff: [FSL] DTI bvecs - dcm2nii vs. mriconvert vs. dtistudio vs. siemens VB15 official tables > > > > Hello, list. I've asked about the following on the DTIStudio email list, > > but the discussion may be a little more appropriate here because it > > points at a possible problem with applying dcm2nii to extract bvecs from > > Siemens VB15 DTI data (and probably VB17), when the acquisition is > > oblique. I understand dcm2nii and MRIConvert are two popular choices > > among FSL users, so I wonder if any of you have noticed this? > > > > (context: in the FSL email list archive, I notice a discussion back in > > April called "which bvecs to trust?" which started along these same > > lines but didn't come to a conclusion.) > > > > I'm trying to understand better why the "standard" vectors supplied by > > the vendor do not match the DICOM header, and what to do about it. > > According to what I read in the DTIStudio email list archive, all the > > major MRI vendors generate DICOM headers containing gradient tables that > > are already rotated to account for oblique acquisitions. This includes > > Siemens VB15 and above (although not the older Siemens versions). The > > bvecs certainly change when you rotate the scan plane on our VB15 > > system, so it's probably true. However.... > > > > What's strange: If my acquisition is straight axial (not oblique), the > > gradient table retrieved by dcm2nii/mriconvert/DTIStudio from the DICOM > > header still does not match the gradient table supplied by Siemens. They > > are close, but not close enough to call them equal. Any idea why? > > > > Even worse: More discrepancies turn up when comparing the bvecs from > > dcm2nii, MRIConvert, and DTIStudio (with/without "Rotate gradients if > > applicable" option), running them against both straight axial and > > oblique scans (30-direction MDDW): > > > > Straight Axial Scan > > -------------------- > > dcm2nii = mriconvert = dtistudio(read dicom) = dtistudio(read dicom + > > rotate) > > <> > > dtistudio(siemens + rotate) = siemens > > > > Oblique Scan (T>C30>S20,inplane10) > > ----------------------------------- > > dcm2nii = dtistudio(read dicom + rotate) > > <> > > dtistudio(read dicom) = mriconvert > > <> > > dtistudio(siemens + rotate) > > <> > > siemens > > > > Also, none of the gradient tables for the straight axial scan match the > > corresponding ones for the oblique scan, so obviously the gradient table > > is being adjusted somehow by Siemens before it is stored in the DICOM > > header. If that is the case, and we trust the Siemens DICOM field (which > > is not clear), we should *not* select the "Rotate gradients if > > applicable" option in DTIStudio for Siemens VB15 data. > > > > Similarly, we should not use dcm2nii for VB15, because that would rotate > > the bvecs unnecessarily. MRIConvert seems to pass along the bvecs from > > the DICOM header untouched. In fact, looking at the revision history of > > MRIConvert, one of the bug fixes made a year ago was "bvecs for latest > > syngo not incorrectly rotated", and a year before that "GE DTI sequences > > no longer correct the bvecs for rotation (which was incorrect)." dcm2nii > > probably needs a similar fix. I notice the example DTI dataset posted on > > the web site with dcm2nii is a VB13 dataset, which *would* have needed a > > rotation. Does this sound reasonable? > > > > However, if that is true, then dcm2nii should have caused problems for > > other Siemens users. Has anyone noticed? > > > > This doesn't account for the mismatch with the official Siemens tables, > > but I suppose I should ask them about it, unless one of you already has. > > > > My tests above were just looking at bvecs generated by the different > > software. I have time to scan a human subject this week a) > > straight-axially and b) at a large angle like T>C30>S30+inplane30, if > > that would clear up anything. > > > > Thanks in advance for any input, > > Fred