|
86 | 86 | Philips XML header files, and some previous experience, suggest that the REC
|
87 | 87 | data is always stored as 8 or 16 bit unsigned integers - see
|
88 | 88 | https://github.com/nipy/nibabel/issues/275
|
| 89 | +
|
| 90 | +Data Sorting |
| 91 | +############ |
| 92 | +
|
| 93 | +PAR/REC files have a large number of potential image dimensions. To handle |
| 94 | +sorting of volumes in PAR/REC files based on these fields and not the order |
| 95 | +slices first appear in the PAR file, the ``strict_sort`` flag of |
| 96 | +``nibabel.load`` (or ``parrec.load``) should be set to ``True``. The fields |
| 97 | +that are taken into account during sorting are: |
| 98 | +
|
| 99 | + - slice number |
| 100 | + - echo number |
| 101 | + - cardiac phase number |
| 102 | + - gradient orientation number |
| 103 | + - diffusion b value number |
| 104 | + - label type (ASL tag vs. control) |
| 105 | + - dynamic scan number |
| 106 | + - image_type_mr (Re, Im, Mag, Phase) |
| 107 | +
|
| 108 | +Slices are sorted into the third dimension and the |
| 109 | +order of preference for sorting along the 4th dimension corresponds to the |
| 110 | +order in the list above. If the image data has more than 4 dimensions these |
| 111 | +will all be concatenated along the 4th dimension. For example, for a scan with |
| 112 | +two echos and two dynamics, the 4th dimension will have both echos of dynamic 1 |
| 113 | +prior to the two echos for dynamic 2. |
| 114 | +
|
| 115 | +The``get_volume_labels`` method of the header returns a dictionary containing |
| 116 | +the PAR field labels for this 4th dimension. |
| 117 | +
|
| 118 | +The volume sorting described above can be enabled in the parrec2nii command |
| 119 | +utility via the option "--strict-sort". The dimension info can be exported |
| 120 | +to a CSV file by adding the option "--volume-info". |
89 | 121 | """
|
90 | 122 | from __future__ import print_function, division
|
91 | 123 |
|
|
0 commit comments