forked from rordenlab/dcm2niix
-
Notifications
You must be signed in to change notification settings - Fork 1
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge commit 'v1.0.20171215-29-ga662295' into debian
* commit 'v1.0.20171215-29-ga662295': Update GE and PAR/REC notes. Add warnings for novel PARREC data, use GE proprietary sliceorder Restore support for PAR/REC dwi with included ADC/Isotropic Use ImageType (0008,0008) to split phase and magnitude (rordenlab#170) Improved GE support Further PARREC tuning Improved Philips PARREC support Better PAR/REC error reporting 0020,9157 does not necessarily index gradient directions from 1..n (e.g. 2...37 for ADNI 018_S_4868) Preliminary attempt to support PAR/REC with arbitrary slice orders (e.g. order reconstructed, not acquired) Restore support for compressed DICOM (Jon Clayden) Restore ability to handle DICOMs files with Icon Image Fixes for Philips rordenlab#165 rordenlab#170 ENH: minor - consistent formatting (%?=description) of template keywords for -f More Philips enhanced support Partial solution for rordenlab#165 Experimental SQ skipping: Philips private use of public tags rordenlab#165 Fix for rordenlab#168 Remove GCC version >= 7.1.0 warning: snprintf output between 1 and 256 bytes into a destination of size 24 Fix for rordenlab#157
- Loading branch information
Showing
9 changed files
with
1,461 additions
and
272 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,120 @@ | ||
| ## About | ||
|
|
||
| dcm2niix attempts to convert GE DICOM format images to NIfTI. | ||
|
|
||
| ## dcm2niix Notes | ||
|
|
||
| In addition to reading the | ||
|
|
||
|
|
||
| In addition to the public DICOM tags, dcm2niix attempts to decode the proprietary GE Protocol Data Block (0025,101B). This is essentially a [GZip format](http://www.onicos.com/staff/iz/formats/gzip.html) file embedded inside the DICOM header. Here are comments regarding the usage of this data block: | ||
|
|
||
| - The VIEWORDER tag is used to set the polarity of the BIDS tag PhaseEncodingDirection, with VIEWORDER of 1 suggesting bottom up phase encoding. | ||
| - The SLICEORDER tag is used to set the SliceTiming for the BIDS tag PhaseEncodingDirection, with a SLICEORDER of 1 suggesting interleaved acquisition. Note that current versions of dcm2niix do not detect multiband for GE datasets. Therefore, the slice timing reported in the BIDS header will be incorrect for multiband acquisitions. | ||
| - There are reports that newer versions of GE equipement (e.g. DISCOVERY MR750 / 24\MX\MR Software release:DV24.0_R01_1344.a) are now storing an [XML](https://groups.google.com/forum/#!msg/comp.protocols.dicom/mxnCkv8A-i4/W_uc6SxLwHQJ) file within the Protocolo Data Block (compressed). Since the developers of dcm2niix have not had access to any of these files, dcm2niix should generate a warning when it encounters any of these images. | ||
|
|
||
| ``` | ||
| POSITION "Supine" | ||
| ENTRY "Head First" | ||
| CLINICALCOIL "C-GE_32Ch Head" | ||
| COIL "32Ch Head" | ||
| COILCOMPONENT "32 Ch Head Coil" | ||
| PLANE "AXIAL" | ||
| SEDESC "Axial rsfMRI (Eyes Open)" | ||
| HOS "0" | ||
| IMODE "2D" | ||
| PSEQ "Gradient Echo" | ||
| IOPT "MPh, EPI" | ||
| PLUG "9" | ||
| IEC_ACCEPT "ON" | ||
| FILTCHOICE "None" | ||
| BWRT "-1" | ||
| TRICKSIMG "1" | ||
| TAG_SPACE "7" | ||
| TAG_TYPE "None" | ||
| USERCV0 "1.00" | ||
| USERCV_MASK "1" | ||
| USERCV_MASK2 "0" | ||
| NUMBVALUE "1" | ||
| REOPT "1" | ||
| FLIPANG "90" | ||
| TE "30.0" | ||
| NECHO "1" | ||
| TR "3000.0" | ||
| NUMSHOTS "1" | ||
| BPMMODE "0" | ||
| AUTOTRGTYPE "0" | ||
| INITSTATE "0" | ||
| PSDTRIG "0" | ||
| SLICEORDER "1" | ||
| VIEWORDER "1" | ||
| TRREST "0" | ||
| TRACTIVE "0" | ||
| SLPERLOC "200" | ||
| ACQORDER "0" | ||
| DELACQ "Minimum" | ||
| DELACQNOAV "2" | ||
| SEPSERIES "0" | ||
| AUTOTRIGWIN "0" | ||
| FOV "22.0" | ||
| SLTHICK "3.4" | ||
| SPC "0.0" | ||
| GRXOPT "0" | ||
| SLOC1 "R0.5" | ||
| SLOC2 "A27.0" | ||
| SLOC3 "I63.3" | ||
| ELOC1 "R0.5" | ||
| ELOC2 "A27.0" | ||
| ELOC3 "S96.5" | ||
| FOVCNT1 "R0.5" | ||
| FOVCNT2 "A27.0" | ||
| NOSLC "48" | ||
| SL3PLANE "0" | ||
| SL3PLANE1 "0" | ||
| SL3PLANE2 "0" | ||
| SL3PLANE3 "0" | ||
| SPCPERPLANE1 "0.0" | ||
| SPCPERPLANE2 "0.0" | ||
| SPCPERPLANE3 "0.0" | ||
| MATRIXX "64" | ||
| MATRIXY "64" | ||
| SWAPPF "R/L" | ||
| NEX "1.00" | ||
| CONTRAST "No" | ||
| CONTAM "Yes " | ||
| TBLDELTA "0.00" | ||
| PHASEFOV "1.00" | ||
| AUTOSHIM "Off" | ||
| PHASECORR "Yes" | ||
| PAUSEDELMASKACQ "1" | ||
| GRIP_SLGROUP1 "0.500000 26.985256 16.641255 0.000000 0.000000 1.000000 0.000000 1.000000 0.000000 1.000000 0.000000 0.000000 48 0.000000 1 0.000000 0" | ||
| GRIP_NUMSLGROUPS "1" | ||
| GRIP_TRACKER "0" | ||
| GRIP_SPECTRO "0" | ||
| GRIP_NUMPSCVOL "0" | ||
| GRIP_PSCVOL1 "0" | ||
| GRIP_PSCVOL2 "0" | ||
| GRIP_PSCVOLFOV "0.000000" | ||
| GRIP_PSCVOLTHICK "0.000000" | ||
| GRIP_IRBAND_A "0" | ||
| GRIP_IRBAND_B "0" | ||
| AUTOSUBOPTIONS "0" | ||
| AUTOSCIC "0" | ||
| AUTOVOICE "0" | ||
| PRESETDELAY "0.0" | ||
| MASKPHASE "0" | ||
| MASKPAUSE "0" | ||
| GRXLOCSAVE "0" | ||
| AUTOCOIL "0" | ||
| ONETOUCHREG "0" | ||
| TEMPORALPHASES "4" | ||
| MEGFREQ "60" | ||
| DRIVERAMP "50" | ||
| MEGDIR "4" | ||
| DRIVERFREQ "60" | ||
| RFDRIVEMODE "Quadrature" | ||
| INRANGETR "0" | ||
| NAVPSCPAUSE "0" | ||
| EXCITATIONMODE "Selective" | ||
| ANATOMY "SRT%5CNone%5CT-A0100" | ||
| ``` |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,11 @@ | ||
| ## About | ||
|
|
||
| dcm2niix attempts to convert Philips PAR/REC format images to NIfTI. While this format remains popular with users, it is slowly being superceded by Philips enhanced DICOM format as well as the direct NIfTI export that Philips provides for users. | ||
|
|
||
| ## dcm2niix Limitations | ||
|
|
||
| None of the major contributors to the dcm2niix source code have access to Philips hardware. Therefore, one should be cautious when converting Philips PAR/REC data. Two situations will generate error reports from the current version of dcm2niix. If you encounter any of these situations you may want to consider filing a GitHub issue or trying an alternative such as [dicm2nii](https://www.mathworks.com/matlabcentral/fileexchange/42997-dicom-to-nifti-converter--nifti-tool-and-viewer) or [r2agui](http://r2agui.sourceforge.net/). | ||
|
|
||
| - dcm2niix assumes that the data is stored in complete 3D volumes. It will not convert datasets where the scan is interrupted mid-volume (e.g. where the number of 2D slices is not divisible by the number of slices in a volume). | ||
| - dcm2niix is aware of phase maps and magnitude maps. In theory (though we have never seen any examples), the format can also store real, imaginary and subsequent calculations such as B1. These may or may not be converted correctly. | ||
|
|
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,46 @@ | ||
| ## About | ||
|
|
||
| dcm2niix attempts to convert all DICOM images to NIfTI. The Philips enhanced DICOM images are elegantly able to save all images from a series as a single file. However, this format is necessarily complex. The usage of this format has evolved over time, and can become further complicated when DICOM are handled by DICOM tools (for example, anonymization, transfer which converts explicit VRs to implicit VRs, etc.). | ||
|
|
||
| This web page describes some of the strategies handle these images. However, users should be vigilant when handling these datasets. If you encounter problems using dcm2niix you can explore [https://github.com/rordenlab/dcm2niix competing DICOM to NIfTI converters] or [ [https://github.com/rordenlab/dcm2niix report an issue]. | ||
|
|
||
| ## Image Patient Position | ||
|
|
||
| The Image Patient Position (0020,0032) tag is required to determine the position of the slices with respect to each other (and with respect to the scanner bore). Philips scans often report two conflicting IPPs for each single slice: with one stored in the private sequence (SQ) 2005,140F while the other is in the public sequence. This is unusual, but is [ftp://medical.nema.org/medical/dicom/final/cp758_ft.pdf legal]. | ||
|
|
||
| In practice, this complication has several major implications. First, not all software translate private SQs well. One potential problem is when the implicit VRs are saved as implicit VRs. This can obscure the fact that 2005,140F is an SQ. Indeed, some tools will convert the private SQ type as a "UN" unknown type and add another public sequence. This can confuse reading software. | ||
|
|
||
| Furthermore, in the real world there are many Philips DICOM images that ONLY contain IPP inside SQ 2005,140F. These situations appear to reflect modifications applied by a PACS to the DICOM data or attempts to anonymize the DICOM images (e.g. using simple Matlab scripts). Note that the private IPP differs from the public one by half a voxel. Therefore, in theory if one only has the private IPP, one can infer the public IPP location. Current versions of dcm2niix do not do this: the error is assumed small enough that it will not impact image processing steps such as coregistration. | ||
|
|
||
| In general it is recommended that you archive and convert DICOM images as they are created from the scanner. If one does use an export tool such as the excellent dcmtk, it is recommended that you preserve the explicit VR, as implicit VR has the potential of obscuring private sequence (SQ) tags. Be aware that subsequent processing of DICOM data can disrupt data conversion. | ||
|
|
||
| Therefore, dcm2niix will ignore the IPP enclosed in 2005,140F unless no alternative exists. | ||
|
|
||
| ## Derived parametric maps stored with raw diffusion data | ||
|
|
||
| Some Philips diffusion DICOM images include derived image(s) along with the images. Other manufacturers save these derived images as a separate series number, and the DICOM standard seems ambiguous on whether it is allowable to mix raw and derived data in the same series (see PS 3.3-2008, C.7.6.1.1.2-3). In practice, many Philips diffusion images append [derived parametric maps](http://www.revisemri.com/blog/2008/diffusion-tensor-imaging/) with the original data. For example, ADC, Trace and Isotropic images can all be derived from the raw scans. As scientists, we want to discard these derived images, as they will disrupt data processing and we can generate better parametric maps after we have applied undistortion methods such as [Eddy and Topup](https://fsl.fmrib.ox.ac.uk/fsl/fslwiki/eddy/UsersGuide). The current version of dcm2niix uses the Diffusion Directionality (0018,9075) tag to detect B=0 unweighted ("NONE"), B-weighted ("DIRECTIONAL"), and derived ("ISOTROPIC") images. Note that the Dimension Index Values (0020,9157) tag provides an alternative approach to discriminate these images. Here are sample tags from a Philips enhanced image that includes and derived map (3rd dimension is "1" while the other images set this to "2"). | ||
|
|
||
| ``` | ||
| (0018,9075) CS [DIRECTIONAL] | ||
| (0018,9089) FD 1\0\0 | ||
| (0018,9087) FD 1000 | ||
| (0020,9157) UL 1\1\2\32 | ||
| ... | ||
| (0018,9075) CS [ISOTROPIC] | ||
| (0018,9087) FD 1000 | ||
| (0020,9157) UL 1\2\1\33 | ||
| ... | ||
| (0018,9075) CS [NONE] | ||
| (0018,9087) FD 0 | ||
| (0020,9157) UL 1\1\2\33 | ||
| ``` | ||
|
|
||
| ## Diffusion Direction | ||
|
|
||
| Proper Philips enhanced scans use tag 0018,9089 to report the 3 gradient directions. However, in the wild, other files from Philips (presumably using older versions of Philips software) use the tags 2005,10b0, 2005,10b1, 2005,10b2. In general, dcm2niix will use the values that most closely precede the Dimension Index Values (0020,9157). | ||
|
|
||
| The current version of dcm2niix uses Dimension Index Values (0020,9157) to determine gradient number, which can also be found in (2005,1413). However, while 2005,1413 is always indexed from one, this is not necessarily the case for 0020,9157. For example, the ADNI DWI dataset for participant 018_S_4868 has values of 2005,1413 that range from 1..36 for the 36 directions, while 0020,9157 ranges from 2..37. The current version of dcm2niix compensates for this by re-indexing the values of 0020,9157 after all the volumes have been read. | ||
|
|
||
| ## General variations | ||
|
|
||
| Prior versions of dcm2niix used different methods to sort images. However, these have proved unreliable The undocumented tags SliceNumberMrPhilips (2001,100A), NumberOfSlicesMrPhilips (2001,1018) are not always present. In theory, InStackPositionNumber (0020,9057) should be present in all enhanced files, but has not proved reliable (perhaps not in older Philips images or DICOM images that were modified after leaving the scanner). MRImageGradientOrientationNumber (2005,1413) is complicated by the inclusion of derived images.Therefore, current versions of dcm2niix do not depend on any of these. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.