nifti1_io
nifti1.h
Go to the documentation of this file.
1 
16 #ifndef _NIFTI_HEADER_
17 #define _NIFTI_HEADER_
18 
19 /*****************************************************************************
20  ** This file defines the "NIFTI-1" header format. **
21  ** It is derived from 2 meetings at the NIH (31 Mar 2003 and **
22  ** 02 Sep 2003) of the Data Format Working Group (DFWG), **
23  ** chartered by the NIfTI (Neuroimaging Informatics Technology **
24  ** Initiative) at the National Institutes of Health (NIH). **
25  **--------------------------------------------------------------**
26  ** Neither the National Institutes of Health (NIH), the DFWG, **
27  ** nor any of the members or employees of these institutions **
28  ** imply any warranty of usefulness of this material for any **
29  ** purpose, and do not assume any liability for damages, **
30  ** incidental or otherwise, caused by any use of this document. **
31  ** If these conditions are not acceptable, do not use this! **
32  **--------------------------------------------------------------**
33  ** Author: Robert W Cox (NIMH, Bethesda) **
34  ** Advisors: John Ashburner (FIL, London), **
35  ** Stephen Smith (FMRIB, Oxford), **
36  ** Mark Jenkinson (FMRIB, Oxford) **
37 ******************************************************************************/
38 
39 /*---------------------------------------------------------------------------*/
40 /* Note that the ANALYZE 7.5 file header (dbh.h) is
41  (c) Copyright 1986-1995
42  Biomedical Imaging Resource
43  Mayo Foundation
44  Incorporation of components of dbh.h are by permission of the
45  Mayo Foundation.
46 
47  Changes from the ANALYZE 7.5 file header in this file are released to the
48  public domain, including the functional comments and any amusing asides.
49 -----------------------------------------------------------------------------*/
50 
51 /*---------------------------------------------------------------------------*/
119 /*---------------------------------------------------------------------------*/
120 /* HEADER STRUCT DECLARATION:
121  -------------------------
122  In the comments below for each field, only NIFTI-1 specific requirements
123  or changes from the ANALYZE 7.5 format are described. For convenience,
124  the 348 byte header is described as a single struct, rather than as the
125  ANALYZE 7.5 group of 3 substructs.
126 
127  Further comments about the interpretation of various elements of this
128  header are after the data type definition itself. Fields that are
129  marked as ++UNUSED++ have no particular interpretation in this standard.
130  (Also see the UNUSED FIELDS comment section, far below.)
131 
132  The presumption below is that the various C types have particular sizes:
133  sizeof(int) = sizeof(float) = 4 ; sizeof(short) = 2
134 -----------------------------------------------------------------------------*/
135 
136 /*=================*/
137 #ifdef __cplusplus
138 extern "C" {
139 #endif
140 /*=================*/
141 
147  /*************************/ /************************/
148 struct nifti_1_header { /* NIFTI-1 usage */ /* ANALYZE 7.5 field(s) */
149  /*************************/ /************************/
150 
151  /*--- was header_key substruct ---*/
152  int sizeof_hdr; /* int sizeof_hdr; */
153  char data_type[10]; /* char data_type[10]; */
154  char db_name[18]; /* char db_name[18]; */
155  int extents; /* int extents; */
156  short session_error; /* short session_error; */
157  char regular; /* char regular; */
158  char dim_info; /* char hkey_un0; */
159 
160  /*--- was image_dimension substruct ---*/
161  short dim[8]; /* short dim[8]; */
162  float intent_p1 ; /* short unused8; */
163  /* short unused9; */
164  float intent_p2 ; /* short unused10; */
165  /* short unused11; */
166  float intent_p3 ; /* short unused12; */
167  /* short unused13; */
168  short intent_code ; /* short unused14; */
169  short datatype; /* short datatype; */
170  short bitpix; /* short bitpix; */
171  short slice_start; /* short dim_un0; */
172  float pixdim[8]; /* float pixdim[8]; */
173  float vox_offset; /* float vox_offset; */
174  float scl_slope ; /* float funused1; */
175  float scl_inter ; /* float funused2; */
176  short slice_end; /* float funused3; */
177  char slice_code ;
178  char xyzt_units ;
179  float cal_max; /* float cal_max; */
180  float cal_min; /* float cal_min; */
181  float slice_duration; /* float compressed; */
182  float toffset; /* float verified; */
183  int glmax; /* int glmax; */
184  int glmin; /* int glmin; */
185 
186  /*--- was data_history substruct ---*/
187  char descrip[80]; /* char descrip[80]; */
188  char aux_file[24]; /* char aux_file[24]; */
189 
190  short qform_code ; /*-- all ANALYZE 7.5 ---*/
191  short sform_code ; /* fields below here */
192  /* are replaced */
193  float quatern_b ;
194  float quatern_c ;
195  float quatern_d ;
196  float qoffset_x ;
197  float qoffset_y ;
198  float qoffset_z ;
200  float srow_x[4] ;
201  float srow_y[4] ;
202  float srow_z[4] ;
204  char intent_name[16];
206  char magic[4] ;
208 } ; /**** 348 bytes total ****/
209 
210 typedef struct nifti_1_header nifti_1_header ;
211 
212 /*---------------------------------------------------------------------------*/
213 /* HEADER EXTENSIONS:
214  -----------------
215  After the end of the 348 byte header (e.g., after the magic field),
216  the next 4 bytes are a char array field named "extension". By default,
217  all 4 bytes of this array should be set to zero. In a .nii file, these
218  4 bytes will always be present, since the earliest start point for
219  the image data is byte #352. In a separate .hdr file, these bytes may
220  or may not be present. If not present (i.e., if the length of the .hdr
221  file is 348 bytes), then a NIfTI-1 compliant program should use the
222  default value of extension={0,0,0,0}. The first byte (extension[0])
223  is the only value of this array that is specified at present. The other
224  3 bytes are reserved for future use.
225 
226  If extension[0] is nonzero, it indicates that extended header information
227  is present in the bytes following the extension array. In a .nii file,
228  this extended header data is before the image data (and vox_offset
229  must be set correctly to allow for this). In a .hdr file, this extended
230  data follows extension and proceeds (potentially) to the end of the file.
231 
232  The format of extended header data is weakly specified. Each extension
233  must be an integer multiple of 16 bytes long. The first 8 bytes of each
234  extension comprise 2 integers:
235  int esize , ecode ;
236  These values may need to be byte-swapped, as indicated by dim[0] for
237  the rest of the header.
238  * esize is the number of bytes that form the extended header data
239  + esize must be a positive integral multiple of 16
240  + this length includes the 8 bytes of esize and ecode themselves
241  * ecode is a non-negative integer that indicates the format of the
242  extended header data that follows
243  + different ecode values are assigned to different developer groups
244  + at present, the "registered" values for code are
245  = 0 = unknown private format (not recommended!)
246  = 2 = DICOM format (i.e., attribute tags and values)
247  = 4 = AFNI group (i.e., ASCII XML-ish elements)
248  In the interests of interoperability (a primary rationale for NIfTI),
249  groups developing software that uses this extension mechanism are
250  encouraged to document and publicize the format of their extensions.
251  To this end, the NIfTI DFWG will assign even numbered codes upon request
252  to groups submitting at least rudimentary documentation for the format
253  of their extension; at present, the contact is mailto:rwcox@nih.gov.
254  The assigned codes and documentation will be posted on the NIfTI
255  website. All odd values of ecode (and 0) will remain unassigned;
256  at least, until the even ones are used up, when we get to 2,147,483,646.
257 
258  Note that the other contents of the extended header data section are
259  totally unspecified by the NIfTI-1 standard. In particular, if binary
260  data is stored in such a section, its byte order is not necessarily
261  the same as that given by examining dim[0]; it is incumbent on the
262  programs dealing with such data to determine the byte order of binary
263  extended header data.
264 
265  Multiple extended header sections are allowed, each starting with an
266  esize,ecode value pair. The first esize value, as described above,
267  is at bytes #352-355 in the .hdr or .nii file (files start at byte #0).
268  If this value is positive, then the second (esize2) will be found
269  starting at byte #352+esize1 , the third (esize3) at byte #352+esize1+esize2,
270  et cetera. Of course, in a .nii file, the value of vox_offset must
271  be compatible with these extensions. If a malformed file indicates
272  that an extended header data section would run past vox_offset, then
273  the entire extended header section should be ignored. In a .hdr file,
274  if an extended header data section would run past the end-of-file,
275  that extended header data should also be ignored.
276 
277  With the above scheme, a program can successively examine the esize
278  and ecode values, and skip over each extended header section if the
279  program doesn't know how to interpret the data within. Of course, any
280  program can simply ignore all extended header sections simply by jumping
281  straight to the image data using vox_offset.
282 -----------------------------------------------------------------------------*/
283 
291 struct nifti1_extender { char extension[4] ; } ;
292 typedef struct nifti1_extender nifti1_extender ;
293 
298  int esize ;
299  int ecode ;
300  char * edata ;
301 } ;
302 typedef struct nifti1_extension nifti1_extension ;
303 
304 /*---------------------------------------------------------------------------*/
305 /* DATA DIMENSIONALITY (as in ANALYZE 7.5):
306  ---------------------------------------
307  dim[0] = number of dimensions;
308  - if dim[0] is outside range 1..7, then the header information
309  needs to be byte swapped appropriately
310  - ANALYZE supports dim[0] up to 7, but NIFTI-1 reserves
311  dimensions 1,2,3 for space (x,y,z), 4 for time (t), and
312  5,6,7 for anything else needed.
313 
314  dim[i] = length of dimension #i, for i=1..dim[0] (must be positive)
315  - also see the discussion of intent_code, far below
316 
317  pixdim[i] = voxel width along dimension #i, i=1..dim[0] (positive)
318  - cf. ORIENTATION section below for use of pixdim[0]
319  - the units of pixdim can be specified with the xyzt_units
320  field (also described far below).
321 
322  Number of bits per voxel value is in bitpix, which MUST correspond with
323  the datatype field. The total number of bytes in the image data is
324  dim[1] * ... * dim[dim[0]] * bitpix / 8
325 
326  In NIFTI-1 files, dimensions 1,2,3 are for space, dimension 4 is for time,
327  and dimension 5 is for storing multiple values at each spatiotemporal
328  voxel. Some examples:
329  - A typical whole-brain FMRI experiment's time series:
330  - dim[0] = 4
331  - dim[1] = 64 pixdim[1] = 3.75 xyzt_units = NIFTI_UNITS_MM
332  - dim[2] = 64 pixdim[2] = 3.75 | NIFTI_UNITS_SEC
333  - dim[3] = 20 pixdim[3] = 5.0
334  - dim[4] = 120 pixdim[4] = 2.0
335  - A typical T1-weighted anatomical volume:
336  - dim[0] = 3
337  - dim[1] = 256 pixdim[1] = 1.0 xyzt_units = NIFTI_UNITS_MM
338  - dim[2] = 256 pixdim[2] = 1.0
339  - dim[3] = 128 pixdim[3] = 1.1
340  - A single slice EPI time series:
341  - dim[0] = 4
342  - dim[1] = 64 pixdim[1] = 3.75 xyzt_units = NIFTI_UNITS_MM
343  - dim[2] = 64 pixdim[2] = 3.75 | NIFTI_UNITS_SEC
344  - dim[3] = 1 pixdim[3] = 5.0
345  - dim[4] = 1200 pixdim[4] = 0.2
346  - A 3-vector stored at each point in a 3D volume:
347  - dim[0] = 5
348  - dim[1] = 256 pixdim[1] = 1.0 xyzt_units = NIFTI_UNITS_MM
349  - dim[2] = 256 pixdim[2] = 1.0
350  - dim[3] = 128 pixdim[3] = 1.1
351  - dim[4] = 1 pixdim[4] = 0.0
352  - dim[5] = 3 intent_code = NIFTI_INTENT_VECTOR
353  - A single time series with a 3x3 matrix at each point:
354  - dim[0] = 5
355  - dim[1] = 1 xyzt_units = NIFTI_UNITS_SEC
356  - dim[2] = 1
357  - dim[3] = 1
358  - dim[4] = 1200 pixdim[4] = 0.2
359  - dim[5] = 9 intent_code = NIFTI_INTENT_GENMATRIX
360  - intent_p1 = intent_p2 = 3.0 (indicates matrix dimensions)
361 -----------------------------------------------------------------------------*/
362 
363 /*---------------------------------------------------------------------------*/
364 /* DATA STORAGE:
365  ------------
366  If the magic field is "n+1", then the voxel data is stored in the
367  same file as the header. In this case, the voxel data starts at offset
368  (int)vox_offset into the header file. Thus, vox_offset=352.0 means that
369  the data starts immediately after the NIFTI-1 header. If vox_offset is
370  greater than 352, the NIFTI-1 format does not say much about the
371  contents of the dataset file between the end of the header and the
372  start of the data.
373 
374  FILES:
375  -----
376  If the magic field is "ni1", then the voxel data is stored in the
377  associated ".img" file, starting at offset 0 (i.e., vox_offset is not
378  used in this case, and should be set to 0.0).
379 
380  When storing NIFTI-1 datasets in pairs of files, it is customary to name
381  the files in the pattern "name.hdr" and "name.img", as in ANALYZE 7.5.
382  When storing in a single file ("n+1"), the file name should be in
383  the form "name.nii" (the ".nft" and ".nif" suffixes are already taken;
384  cf. http://www.icdatamaster.com/n.html ).
385 
386  BYTE ORDERING:
387  -------------
388  The byte order of the data arrays is presumed to be the same as the byte
389  order of the header (which is determined by examining dim[0]).
390 
391  Floating point types are presumed to be stored in IEEE-754 format.
392 -----------------------------------------------------------------------------*/
393 
394 /*---------------------------------------------------------------------------*/
395 /* DETAILS ABOUT vox_offset:
396  ------------------------
397  In a .nii file, the vox_offset field value is interpreted as the start
398  location of the image data bytes in that file. In a .hdr/.img file pair,
399  the vox_offset field value is the start location of the image data
400  bytes in the .img file.
401  * If vox_offset is less than 352 in a .nii file, it is equivalent
402  to 352 (i.e., image data never starts before byte #352 in a .nii file).
403  * The default value for vox_offset in a .nii file is 352.
404  * In a .hdr file, the default value for vox_offset is 0.
405  * vox_offset should be an integer multiple of 16; otherwise, some
406  programs may not work properly (e.g., SPM). This is to allow
407  memory-mapped input to be properly byte-aligned.
408  Note that since vox_offset is an IEEE-754 32 bit float (for compatibility
409  with the ANALYZE-7.5 format), it effectively has a 24 bit mantissa. All
410  integers from 0 to 2^24 can be represented exactly in this format, but not
411  all larger integers are exactly storable as IEEE-754 32 bit floats. However,
412  unless you plan to have vox_offset be potentially larger than 16 MB, this
413  should not be an issue. (Actually, any integral multiple of 16 up to 2^27
414  can be represented exactly in this format, which allows for up to 128 MB
415  of random information before the image data. If that isn't enough, then
416  perhaps this format isn't right for you.)
417 
418  In a .img file (i.e., image data stored separately from the NIfTI-1
419  header), data bytes between #0 and #vox_offset-1 (inclusive) are completely
420  undefined and unregulated by the NIfTI-1 standard. One potential use of
421  having vox_offset > 0 in the .hdr/.img file pair storage method is to make
422  the .img file be a copy of (or link to) a pre-existing image file in some
423  other format, such as DICOM; then vox_offset would be set to the offset of
424  the image data in this file. (It may not be possible to follow the
425  "multiple-of-16 rule" with an arbitrary external file; using the NIfTI-1
426  format in such a case may lead to a file that is incompatible with software
427  that relies on vox_offset being a multiple of 16.)
428 
429  In a .nii file, data bytes between #348 and #vox_offset-1 (inclusive) may
430  be used to store user-defined extra information; similarly, in a .hdr file,
431  any data bytes after byte #347 are available for user-defined extra
432  information. The (very weak) regulation of this extra header data is
433  described elsewhere.
434 -----------------------------------------------------------------------------*/
435 
436 /*---------------------------------------------------------------------------*/
437 /* DATA SCALING:
438  ------------
439  If the scl_slope field is nonzero, then each voxel value in the dataset
440  should be scaled as
441  y = scl_slope * x + scl_inter
442  where x = voxel value stored
443  y = "true" voxel value
444  Normally, we would expect this scaling to be used to store "true" floating
445  values in a smaller integer datatype, but that is not required. That is,
446  it is legal to use scaling even if the datatype is a float type (crazy,
447  perhaps, but legal).
448  - However, the scaling is to be ignored if datatype is DT_RGB24.
449  - If datatype is a complex type, then the scaling is to be
450  applied to both the real and imaginary parts.
451 
452  The cal_min and cal_max fields (if nonzero) are used for mapping (possibly
453  scaled) dataset values to display colors:
454  - Minimum display intensity (black) corresponds to dataset value cal_min.
455  - Maximum display intensity (white) corresponds to dataset value cal_max.
456  - Dataset values below cal_min should display as black also, and values
457  above cal_max as white.
458  - Colors "black" and "white", of course, may refer to any scalar display
459  scheme (e.g., a color lookup table specified via aux_file).
460  - cal_min and cal_max only make sense when applied to scalar-valued
461  datasets (i.e., dim[0] < 5 or dim[5] = 1).
462 -----------------------------------------------------------------------------*/
463 
464 /*---------------------------------------------------------------------------*/
465 /* TYPE OF DATA (acceptable values for datatype field):
466  ---------------------------------------------------
467  Values of datatype smaller than 256 are ANALYZE 7.5 compatible.
468  Larger values are NIFTI-1 additions. These are all multiples of 256, so
469  that no bits below position 8 are set in datatype. But there is no need
470  to use only powers-of-2, as the original ANALYZE 7.5 datatype codes do.
471 
472  The additional codes are intended to include a complete list of basic
473  scalar types, including signed and unsigned integers from 8 to 64 bits,
474  floats from 32 to 128 bits, and complex (float pairs) from 64 to 256 bits.
475 
476  Note that most programs will support only a few of these datatypes!
477  A NIFTI-1 program should fail gracefully (e.g., print a warning message)
478  when it encounters a dataset with a type it doesn't like.
479 -----------------------------------------------------------------------------*/
480 
481 #undef DT_UNKNOWN /* defined in dirent.h on some Unix systems */
482 
487  /*--- the original ANALYZE 7.5 type codes ---*/
488 #define DT_NONE 0
489 #define DT_UNKNOWN 0 /* what it says, dude */
490 #define DT_BINARY 1 /* binary (1 bit/voxel) */
491 #define DT_UNSIGNED_CHAR 2 /* unsigned char (8 bits/voxel) */
492 #define DT_SIGNED_SHORT 4 /* signed short (16 bits/voxel) */
493 #define DT_SIGNED_INT 8 /* signed int (32 bits/voxel) */
494 #define DT_FLOAT 16 /* float (32 bits/voxel) */
495 #define DT_COMPLEX 32 /* complex (64 bits/voxel) */
496 #define DT_DOUBLE 64 /* double (64 bits/voxel) */
497 #define DT_RGB 128 /* RGB triple (24 bits/voxel) */
498 #define DT_ALL 255 /* not very useful (?) */
499 
500  /*----- another set of names for the same ---*/
501 #define DT_UINT8 2
502 #define DT_INT16 4
503 #define DT_INT32 8
504 #define DT_FLOAT32 16
505 #define DT_COMPLEX64 32
506 #define DT_FLOAT64 64
507 #define DT_RGB24 128
508 
509  /*------------------- new codes for NIFTI ---*/
510 #define DT_INT8 256 /* signed char (8 bits) */
511 #define DT_UINT16 512 /* unsigned short (16 bits) */
512 #define DT_UINT32 768 /* unsigned int (32 bits) */
513 #define DT_INT64 1024 /* long long (64 bits) */
514 #define DT_UINT64 1280 /* unsigned long long (64 bits) */
515 #define DT_FLOAT128 1536 /* long double (128 bits) */
516 #define DT_COMPLEX128 1792 /* double pair (128 bits) */
517 #define DT_COMPLEX256 2048 /* long double pair (256 bits) */
518 #define DT_RGBA32 2304 /* 4 byte RGBA (32 bits/voxel) */
519 /* @} */
520 
521 
522  /*------- aliases for all the above codes ---*/
523 
529 #define NIFTI_TYPE_UINT8 2
530 
531 #define NIFTI_TYPE_INT16 4
532 
533 #define NIFTI_TYPE_INT32 8
534 
535 #define NIFTI_TYPE_FLOAT32 16
536 
537 #define NIFTI_TYPE_COMPLEX64 32
538 
539 #define NIFTI_TYPE_FLOAT64 64
540 
541 #define NIFTI_TYPE_RGB24 128
542 
543 #define NIFTI_TYPE_INT8 256
544 
545 #define NIFTI_TYPE_UINT16 512
546 
547 #define NIFTI_TYPE_UINT32 768
548 
549 #define NIFTI_TYPE_INT64 1024
550 
551 #define NIFTI_TYPE_UINT64 1280
552 
553 #define NIFTI_TYPE_FLOAT128 1536
554 
555 #define NIFTI_TYPE_COMPLEX128 1792
556 
557 #define NIFTI_TYPE_COMPLEX256 2048
558 
559 #define NIFTI_TYPE_RGBA32 2304
560 /* @} */
561 
562  /*-------- sample typedefs for complicated types ---*/
563 #if 0
564 typedef struct { float r,i; } complex_float ;
565 typedef struct { double r,i; } complex_double ;
566 typedef struct { long double r,i; } complex_longdouble ;
567 typedef struct { unsigned char r,g,b; } rgb_byte ;
568 #endif
569 
570 /*---------------------------------------------------------------------------*/
571 /* INTERPRETATION OF VOXEL DATA:
572  ----------------------------
573  The intent_code field can be used to indicate that the voxel data has
574  some particular meaning. In particular, a large number of codes is
575  given to indicate that the the voxel data should be interpreted as
576  being drawn from a given probability distribution.
577 
578  VECTOR-VALUED DATASETS:
579  ----------------------
580  The 5th dimension of the dataset, if present (i.e., dim[0]=5 and
581  dim[5] > 1), contains multiple values (e.g., a vector) to be stored
582  at each spatiotemporal location. For example, the header values
583  - dim[0] = 5
584  - dim[1] = 64
585  - dim[2] = 64
586  - dim[3] = 20
587  - dim[4] = 1 (indicates no time axis)
588  - dim[5] = 3
589  - datatype = DT_FLOAT
590  - intent_code = NIFTI_INTENT_VECTOR
591  mean that this dataset should be interpreted as a 3D volume (64x64x20),
592  with a 3-vector of floats defined at each point in the 3D grid.
593 
594  A program reading a dataset with a 5th dimension may want to reformat
595  the image data to store each voxels' set of values together in a struct
596  or array. This programming detail, however, is beyond the scope of the
597  NIFTI-1 file specification! Uses of dimensions 6 and 7 are also not
598  specified here.
599 
600  STATISTICAL PARAMETRIC DATASETS (i.e., SPMs):
601  --------------------------------------------
602  Values of intent_code from NIFTI_FIRST_STATCODE to NIFTI_LAST_STATCODE
603  (inclusive) indicate that the numbers in the dataset should be interpreted
604  as being drawn from a given distribution. Most such distributions have
605  auxiliary parameters (e.g., NIFTI_INTENT_TTEST has 1 DOF parameter).
606 
607  If the dataset DOES NOT have a 5th dimension, then the auxiliary parameters
608  are the same for each voxel, and are given in header fields intent_p1,
609  intent_p2, and intent_p3.
610 
611  If the dataset DOES have a 5th dimension, then the auxiliary parameters
612  are different for each voxel. For example, the header values
613  - dim[0] = 5
614  - dim[1] = 128
615  - dim[2] = 128
616  - dim[3] = 1 (indicates a single slice)
617  - dim[4] = 1 (indicates no time axis)
618  - dim[5] = 2
619  - datatype = DT_FLOAT
620  - intent_code = NIFTI_INTENT_TTEST
621  mean that this is a 2D dataset (128x128) of t-statistics, with the
622  t-statistic being in the first "plane" of data and the degrees-of-freedom
623  parameter being in the second "plane" of data.
624 
625  If the dataset 5th dimension is used to store the voxel-wise statistical
626  parameters, then dim[5] must be 1 plus the number of parameters required
627  by that distribution (e.g., intent_code=NIFTI_INTENT_TTEST implies dim[5]
628  must be 2, as in the example just above).
629 
630  Note: intent_code values 2..10 are compatible with AFNI 1.5x (which is
631  why there is no code with value=1, which is obsolescent in AFNI).
632 
633  OTHER INTENTIONS:
634  ----------------
635  The purpose of the intent_* fields is to help interpret the values
636  stored in the dataset. Some non-statistical values for intent_code
637  and conventions are provided for storing other complex data types.
638 
639  The intent_name field provides space for a 15 character (plus 0 byte)
640  'name' string for the type of data stored. Examples:
641  - intent_code = NIFTI_INTENT_ESTIMATE; intent_name = "T1";
642  could be used to signify that the voxel values are estimates of the
643  NMR parameter T1.
644  - intent_code = NIFTI_INTENT_TTEST; intent_name = "House";
645  could be used to signify that the voxel values are t-statistics
646  for the significance of 'activation' response to a House stimulus.
647  - intent_code = NIFTI_INTENT_DISPVECT; intent_name = "ToMNI152";
648  could be used to signify that the voxel values are a displacement
649  vector that transforms each voxel (x,y,z) location to the
650  corresponding location in the MNI152 standard brain.
651  - intent_code = NIFTI_INTENT_SYMMATRIX; intent_name = "DTI";
652  could be used to signify that the voxel values comprise a diffusion
653  tensor image.
654 
655  If no data name is implied or needed, intent_name[0] should be set to 0.
656 -----------------------------------------------------------------------------*/
657 
660 #define NIFTI_INTENT_NONE 0
661 
662  /*-------- These codes are for probability distributions ---------------*/
663  /* Most distributions have a number of parameters,
664  below denoted by p1, p2, and p3, and stored in
665  - intent_p1, intent_p2, intent_p3 if dataset doesn't have 5th dimension
666  - image data array if dataset does have 5th dimension
667 
668  Functions to compute with many of the distributions below can be found
669  in the CDF library from U Texas.
670 
671  Formulas for and discussions of these distributions can be found in the
672  following books:
673 
674  [U] Univariate Discrete Distributions,
675  NL Johnson, S Kotz, AW Kemp.
676 
677  [C1] Continuous Univariate Distributions, vol. 1,
678  NL Johnson, S Kotz, N Balakrishnan.
679 
680  [C2] Continuous Univariate Distributions, vol. 2,
681  NL Johnson, S Kotz, N Balakrishnan. */
682  /*----------------------------------------------------------------------*/
683 
692 #define NIFTI_INTENT_CORREL 2
693 
696 #define NIFTI_INTENT_TTEST 3
697 
701 #define NIFTI_INTENT_FTEST 4
702 
705 #define NIFTI_INTENT_ZSCORE 5
706 
710 #define NIFTI_INTENT_CHISQ 6
711 
715 #define NIFTI_INTENT_BETA 7
716 
721 #define NIFTI_INTENT_BINOM 8
722 
727 #define NIFTI_INTENT_GAMMA 9
728 
732 #define NIFTI_INTENT_POISSON 10
733 
737 #define NIFTI_INTENT_NORMAL 11
738 
743 #define NIFTI_INTENT_FTEST_NONC 12
744 
748 #define NIFTI_INTENT_CHISQ_NONC 13
749 
754 #define NIFTI_INTENT_LOGISTIC 14
755 
760 #define NIFTI_INTENT_LAPLACE 15
761 
764 #define NIFTI_INTENT_UNIFORM 16
765 
769 #define NIFTI_INTENT_TTEST_NONC 17
770 
776 #define NIFTI_INTENT_WEIBULL 18
777 
784 #define NIFTI_INTENT_CHI 19
785 
791 #define NIFTI_INTENT_INVGAUSS 20
792 
797 #define NIFTI_INTENT_EXTVAL 21
798 
801 #define NIFTI_INTENT_PVAL 22
802 
809 #define NIFTI_INTENT_LOGPVAL 23
810 
816 #define NIFTI_INTENT_LOG10PVAL 24
817 
820 #define NIFTI_FIRST_STATCODE 2
821 
824 #define NIFTI_LAST_STATCODE 24
825 
826  /*---------- these values for intent_code aren't for statistics ----------*/
827 
832 #define NIFTI_INTENT_ESTIMATE 1001
833 
838 #define NIFTI_INTENT_LABEL 1002
839 
843 #define NIFTI_INTENT_NEURONAME 1003
844 
857 #define NIFTI_INTENT_GENMATRIX 1004
858 
870 #define NIFTI_INTENT_SYMMATRIX 1005
871 
879 #define NIFTI_INTENT_DISPVECT 1006 /* specifically for displacements */
880 #define NIFTI_INTENT_VECTOR 1007 /* for any other type of vector */
881 
893 #define NIFTI_INTENT_POINTSET 1008
894 
906 #define NIFTI_INTENT_TRIANGLE 1009
907 
915 #define NIFTI_INTENT_QUATERNION 1010
916 
920 #define NIFTI_INTENT_DIMLESS 1011
921 
922  /*---------- these values apply to GIFTI datasets ----------*/
923 
926 #define NIFTI_INTENT_TIME_SERIES 2001
927 
931 #define NIFTI_INTENT_NODE_INDEX 2002
932 
942 #define NIFTI_INTENT_RGB_VECTOR 2003
943 
953 #define NIFTI_INTENT_RGBA_VECTOR 2004
954 
958 #define NIFTI_INTENT_SHAPE 2005
959 
969 #define NIFTI_INTENT_FSL_FNIRT_DISPLACEMENT_FIELD 2006
970 #define NIFTI_INTENT_FSL_CUBIC_SPLINE_COEFFICIENTS 2007
971 #define NIFTI_INTENT_FSL_DCT_COEFFICIENTS 2008
972 #define NIFTI_INTENT_FSL_QUADRATIC_SPLINE_COEFFICIENTS 2009
973 
983 #define NIFTI_INTENT_FSL_TOPUP_CUBIC_SPLINE_COEFFICIENTS 2016
984 #define NIFTI_INTENT_FSL_TOPUP_QUADRATIC_SPLINE_COEFFICIENTS 2017
985 #define NIFTI_INTENT_FSL_TOPUP_FIELD 2018
986 
987 /* @} */
988 
989 /*---------------------------------------------------------------------------*/
990 /* 3D IMAGE (VOLUME) ORIENTATION AND LOCATION IN SPACE:
991  ---------------------------------------------------
992  There are 3 different methods by which continuous coordinates can
993  attached to voxels. The discussion below emphasizes 3D volumes, and
994  the continuous coordinates are referred to as (x,y,z). The voxel
995  index coordinates (i.e., the array indexes) are referred to as (i,j,k),
996  with valid ranges:
997  i = 0 .. dim[1]-1
998  j = 0 .. dim[2]-1 (if dim[0] >= 2)
999  k = 0 .. dim[3]-1 (if dim[0] >= 3)
1000  The (x,y,z) coordinates refer to the CENTER of a voxel. In methods
1001  2 and 3, the (x,y,z) axes refer to a subject-based coordinate system,
1002  with
1003  +x = Right +y = Anterior +z = Superior.
1004  This is a right-handed coordinate system. However, the exact direction
1005  these axes point with respect to the subject depends on qform_code
1006  (Method 2) and sform_code (Method 3).
1007 
1008  N.B.: The i index varies most rapidly, j index next, k index slowest.
1009  Thus, voxel (i,j,k) is stored starting at location
1010  (i + j*dim[1] + k*dim[1]*dim[2]) * (bitpix/8)
1011  into the dataset array.
1012 
1013  N.B.: The ANALYZE 7.5 coordinate system is
1014  +x = Left +y = Anterior +z = Superior
1015  which is a left-handed coordinate system. This backwardness is
1016  too difficult to tolerate, so this NIFTI-1 standard specifies the
1017  coordinate order which is most common in functional neuroimaging.
1018 
1019  N.B.: The 3 methods below all give the locations of the voxel centers
1020  in the (x,y,z) coordinate system. In many cases, programs will wish
1021  to display image data on some other grid. In such a case, the program
1022  will need to convert its desired (x,y,z) values into (i,j,k) values
1023  in order to extract (or interpolate) the image data. This operation
1024  would be done with the inverse transformation to those described below.
1025 
1026  N.B.: Method 2 uses a factor 'qfac' which is either -1 or 1; qfac is
1027  stored in the otherwise unused pixdim[0]. If pixdim[0]=0.0 (which
1028  should not occur), we take qfac=1. Of course, pixdim[0] is only used
1029  when reading a NIFTI-1 header, not when reading an ANALYZE 7.5 header.
1030 
1031  N.B.: The units of (x,y,z) can be specified using the xyzt_units field.
1032 
1033  METHOD 1 (the "old" way, used only when qform_code = 0):
1034  -------------------------------------------------------
1035  The coordinate mapping from (i,j,k) to (x,y,z) is the ANALYZE
1036  7.5 way. This is a simple scaling relationship:
1037 
1038  x = pixdim[1] * i
1039  y = pixdim[2] * j
1040  z = pixdim[3] * k
1041 
1042  No particular spatial orientation is attached to these (x,y,z)
1043  coordinates. (NIFTI-1 does not have the ANALYZE 7.5 orient field,
1044  which is not general and is often not set properly.) This method
1045  is not recommended, and is present mainly for compatibility with
1046  ANALYZE 7.5 files.
1047 
1048  METHOD 2 (used when qform_code > 0, which should be the "normal" case):
1049  ---------------------------------------------------------------------
1050  The (x,y,z) coordinates are given by the pixdim[] scales, a rotation
1051  matrix, and a shift. This method is intended to represent
1052  "scanner-anatomical" coordinates, which are often embedded in the
1053  image header (e.g., DICOM fields (0020,0032), (0020,0037), (0028,0030),
1054  and (0018,0050)), and represent the nominal orientation and location of
1055  the data. This method can also be used to represent "aligned"
1056  coordinates, which would typically result from some post-acquisition
1057  alignment of the volume to a standard orientation (e.g., the same
1058  subject on another day, or a rigid rotation to true anatomical
1059  orientation from the tilted position of the subject in the scanner).
1060  The formula for (x,y,z) in terms of header parameters and (i,j,k) is:
1061 
1062  [ x ] [ R11 R12 R13 ] [ pixdim[1] * i ] [ qoffset_x ]
1063  [ y ] = [ R21 R22 R23 ] [ pixdim[2] * j ] + [ qoffset_y ]
1064  [ z ] [ R31 R32 R33 ] [ qfac * pixdim[3] * k ] [ qoffset_z ]
1065 
1066  The qoffset_* shifts are in the NIFTI-1 header. Note that the center
1067  of the (i,j,k)=(0,0,0) voxel (first value in the dataset array) is
1068  just (x,y,z)=(qoffset_x,qoffset_y,qoffset_z).
1069 
1070  The rotation matrix R is calculated from the quatern_* parameters.
1071  This calculation is described below.
1072 
1073  The scaling factor qfac is either 1 or -1. The rotation matrix R
1074  defined by the quaternion parameters is "proper" (has determinant 1).
1075  This may not fit the needs of the data; for example, if the image
1076  grid is
1077  i increases from Left-to-Right
1078  j increases from Anterior-to-Posterior
1079  k increases from Inferior-to-Superior
1080  Then (i,j,k) is a left-handed triple. In this example, if qfac=1,
1081  the R matrix would have to be
1082 
1083  [ 1 0 0 ]
1084  [ 0 -1 0 ] which is "improper" (determinant = -1).
1085  [ 0 0 1 ]
1086 
1087  If we set qfac=-1, then the R matrix would be
1088 
1089  [ 1 0 0 ]
1090  [ 0 -1 0 ] which is proper.
1091  [ 0 0 -1 ]
1092 
1093  This R matrix is represented by quaternion [a,b,c,d] = [0,1,0,0]
1094  (which encodes a 180 degree rotation about the x-axis).
1095 
1096  METHOD 3 (used when sform_code > 0):
1097  -----------------------------------
1098  The (x,y,z) coordinates are given by a general affine transformation
1099  of the (i,j,k) indexes:
1100 
1101  x = srow_x[0] * i + srow_x[1] * j + srow_x[2] * k + srow_x[3]
1102  y = srow_y[0] * i + srow_y[1] * j + srow_y[2] * k + srow_y[3]
1103  z = srow_z[0] * i + srow_z[1] * j + srow_z[2] * k + srow_z[3]
1104 
1105  The srow_* vectors are in the NIFTI_1 header. Note that no use is
1106  made of pixdim[] in this method.
1107 
1108  WHY 3 METHODS?
1109  --------------
1110  Method 1 is provided only for backwards compatibility. The intention
1111  is that Method 2 (qform_code > 0) represents the nominal voxel locations
1112  as reported by the scanner, or as rotated to some fiducial orientation and
1113  location. Method 3, if present (sform_code > 0), is to be used to give
1114  the location of the voxels in some standard space. The sform_code
1115  indicates which standard space is present. Both methods 2 and 3 can be
1116  present, and be useful in different contexts (method 2 for displaying the
1117  data on its original grid; method 3 for displaying it on a standard grid).
1118 
1119  In this scheme, a dataset would originally be set up so that the
1120  Method 2 coordinates represent what the scanner reported. Later,
1121  a registration to some standard space can be computed and inserted
1122  in the header. Image display software can use either transform,
1123  depending on its purposes and needs.
1124 
1125  In Method 2, the origin of coordinates would generally be whatever
1126  the scanner origin is; for example, in MRI, (0,0,0) is the center
1127  of the gradient coil.
1128 
1129  In Method 3, the origin of coordinates would depend on the value
1130  of sform_code; for example, for the Talairach coordinate system,
1131  (0,0,0) corresponds to the Anterior Commissure.
1132 
1133  QUATERNION REPRESENTATION OF ROTATION MATRIX (METHOD 2)
1134  -------------------------------------------------------
1135  The orientation of the (x,y,z) axes relative to the (i,j,k) axes
1136  in 3D space is specified using a unit quaternion [a,b,c,d], where
1137  a*a+b*b+c*c+d*d=1. The (b,c,d) values are all that is needed, since
1138  we require that a = sqrt(1.0-(b*b+c*c+d*d)) be nonnegative. The (b,c,d)
1139  values are stored in the (quatern_b,quatern_c,quatern_d) fields.
1140 
1141  The quaternion representation is chosen for its compactness in
1142  representing rotations. The (proper) 3x3 rotation matrix that
1143  corresponds to [a,b,c,d] is
1144 
1145  [ a*a+b*b-c*c-d*d 2*b*c-2*a*d 2*b*d+2*a*c ]
1146  R = [ 2*b*c+2*a*d a*a+c*c-b*b-d*d 2*c*d-2*a*b ]
1147  [ 2*b*d-2*a*c 2*c*d+2*a*b a*a+d*d-c*c-b*b ]
1148 
1149  [ R11 R12 R13 ]
1150  = [ R21 R22 R23 ]
1151  [ R31 R32 R33 ]
1152 
1153  If (p,q,r) is a unit 3-vector, then rotation of angle h about that
1154  direction is represented by the quaternion
1155 
1156  [a,b,c,d] = [cos(h/2), p*sin(h/2), q*sin(h/2), r*sin(h/2)].
1157 
1158  Requiring a >= 0 is equivalent to requiring -Pi <= h <= Pi. (Note that
1159  [-a,-b,-c,-d] represents the same rotation as [a,b,c,d]; there are 2
1160  quaternions that can be used to represent a given rotation matrix R.)
1161  To rotate a 3-vector (x,y,z) using quaternions, we compute the
1162  quaternion product
1163 
1164  [0,x',y',z'] = [a,b,c,d] * [0,x,y,z] * [a,-b,-c,-d]
1165 
1166  which is equivalent to the matrix-vector multiply
1167 
1168  [ x' ] [ x ]
1169  [ y' ] = R [ y ] (equivalence depends on a*a+b*b+c*c+d*d=1)
1170  [ z' ] [ z ]
1171 
1172  Multiplication of 2 quaternions is defined by the following:
1173 
1174  [a,b,c,d] = a*1 + b*I + c*J + d*K
1175  where
1176  I*I = J*J = K*K = -1 (I,J,K are square roots of -1)
1177  I*J = K J*K = I K*I = J
1178  J*I = -K K*J = -I I*K = -J (not commutative!)
1179  For example
1180  [a,b,0,0] * [0,0,0,1] = [0,0,-b,a]
1181  since this expands to
1182  (a+b*I)*(K) = (a*K+b*I*K) = (a*K-b*J).
1183 
1184  The above formula shows how to go from quaternion (b,c,d) to
1185  rotation matrix and direction cosines. Conversely, given R,
1186  we can compute the fields for the NIFTI-1 header by
1187 
1188  a = 0.5 * sqrt(1+R11+R22+R33) (not stored)
1189  b = 0.25 * (R32-R23) / a => quatern_b
1190  c = 0.25 * (R13-R31) / a => quatern_c
1191  d = 0.25 * (R21-R12) / a => quatern_d
1192 
1193  If a=0 (a 180 degree rotation), alternative formulas are needed.
1194  See the nifti1_io.c function mat44_to_quatern() for an implementation
1195  of the various cases in converting R to [a,b,c,d].
1196 
1197  Note that R-transpose (= R-inverse) would lead to the quaternion
1198  [a,-b,-c,-d].
1199 
1200  The choice to specify the qoffset_x (etc.) values in the final
1201  coordinate system is partly to make it easy to convert DICOM images to
1202  this format. The DICOM attribute "Image Position (Patient)" (0020,0032)
1203  stores the (Xd,Yd,Zd) coordinates of the center of the first voxel.
1204  Here, (Xd,Yd,Zd) refer to DICOM coordinates, and Xd=-x, Yd=-y, Zd=z,
1205  where (x,y,z) refers to the NIFTI coordinate system discussed above.
1206  (i.e., DICOM +Xd is Left, +Yd is Posterior, +Zd is Superior,
1207  whereas +x is Right, +y is Anterior , +z is Superior. )
1208  Thus, if the (0020,0032) DICOM attribute is extracted into (px,py,pz), then
1209  qoffset_x = -px qoffset_y = -py qoffset_z = pz
1210  is a reasonable setting when qform_code=NIFTI_XFORM_SCANNER_ANAT.
1211 
1212  That is, DICOM's coordinate system is 180 degrees rotated about the z-axis
1213  from the neuroscience/NIFTI coordinate system. To transform between DICOM
1214  and NIFTI, you just have to negate the x- and y-coordinates.
1215 
1216  The DICOM attribute (0020,0037) "Image Orientation (Patient)" gives the
1217  orientation of the x- and y-axes of the image data in terms of 2 3-vectors.
1218  The first vector is a unit vector along the x-axis, and the second is
1219  along the y-axis. If the (0020,0037) attribute is extracted into the
1220  value (xa,xb,xc,ya,yb,yc), then the first two columns of the R matrix
1221  would be
1222  [ -xa -ya ]
1223  [ -xb -yb ]
1224  [ xc yc ]
1225  The negations are because DICOM's x- and y-axes are reversed relative
1226  to NIFTI's. The third column of the R matrix gives the direction of
1227  displacement (relative to the subject) along the slice-wise direction.
1228  This orientation is not encoded in the DICOM standard in a simple way;
1229  DICOM is mostly concerned with 2D images. The third column of R will be
1230  either the cross-product of the first 2 columns or its negative. It is
1231  possible to infer the sign of the 3rd column by examining the coordinates
1232  in DICOM attribute (0020,0032) "Image Position (Patient)" for successive
1233  slices. However, this method occasionally fails for reasons that I
1234  (RW Cox) do not understand.
1235 -----------------------------------------------------------------------------*/
1236 
1237  /* [qs]form_code value: */ /* x,y,z coordinate system refers to: */
1238  /*-----------------------*/ /*---------------------------------------*/
1239 
1246 #define NIFTI_XFORM_UNKNOWN 0
1250 #define NIFTI_XFORM_SCANNER_ANAT 1
1255 #define NIFTI_XFORM_ALIGNED_ANAT 2
1260 #define NIFTI_XFORM_TALAIRACH 3
1264 #define NIFTI_XFORM_MNI_152 4
1270 #define NIFTI_XFORM_TEMPLATE_OTHER 5
1272 /* @} */
1273 
1274 /*---------------------------------------------------------------------------*/
1275 /* UNITS OF SPATIAL AND TEMPORAL DIMENSIONS:
1276  ----------------------------------------
1277  The codes below can be used in xyzt_units to indicate the units of pixdim.
1278  As noted earlier, dimensions 1,2,3 are for x,y,z; dimension 4 is for
1279  time (t).
1280  - If dim[4]=1 or dim[0] < 4, there is no time axis.
1281  - A single time series (no space) would be specified with
1282  - dim[0] = 4 (for scalar data) or dim[0] = 5 (for vector data)
1283  - dim[1] = dim[2] = dim[3] = 1
1284  - dim[4] = number of time points
1285  - pixdim[4] = time step
1286  - xyzt_units indicates units of pixdim[4]
1287  - dim[5] = number of values stored at each time point
1288 
1289  Bits 0..2 of xyzt_units specify the units of pixdim[1..3]
1290  (e.g., spatial units are values 1..7).
1291  Bits 3..5 of xyzt_units specify the units of pixdim[4]
1292  (e.g., temporal units are multiples of 8).
1293 
1294  This compression of 2 distinct concepts into 1 byte is due to the
1295  limited space available in the 348 byte ANALYZE 7.5 header. The
1296  macros XYZT_TO_SPACE and XYZT_TO_TIME can be used to mask off the
1297  undesired bits from the xyzt_units fields, leaving "pure" space
1298  and time codes. Inversely, the macro SPACE_TIME_TO_XYZT can be
1299  used to assemble a space code (0,1,2,...,7) with a time code
1300  (0,8,16,32,...,56) into the combined value for xyzt_units.
1301 
1302  Note that codes are provided to indicate the "time" axis units are
1303  actually frequency in Hertz (_HZ), in part-per-million (_PPM)
1304  or in radians-per-second (_RADS).
1305 
1306  The toffset field can be used to indicate a nonzero start point for
1307  the time axis. That is, time point #m is at t=toffset+m*pixdim[4]
1308  for m=0..dim[4]-1.
1309 -----------------------------------------------------------------------------*/
1310 
1317 #define NIFTI_UNITS_UNKNOWN 0
1321 #define NIFTI_UNITS_METER 1
1323 #define NIFTI_UNITS_MM 2
1325 #define NIFTI_UNITS_MICRON 3
1329 #define NIFTI_UNITS_SEC 8
1331 #define NIFTI_UNITS_MSEC 16
1333 #define NIFTI_UNITS_USEC 24
1335  /*** These units are for spectral data: ***/
1337 #define NIFTI_UNITS_HZ 32
1339 #define NIFTI_UNITS_PPM 40
1341 #define NIFTI_UNITS_RADS 48
1342 /* @} */
1343 
1344 #undef XYZT_TO_SPACE
1345 #undef XYZT_TO_TIME
1346 #define XYZT_TO_SPACE(xyzt) ( (xyzt) & 0x07 )
1347 #define XYZT_TO_TIME(xyzt) ( (xyzt) & 0x38 )
1348 
1349 #undef SPACE_TIME_TO_XYZT
1350 #define SPACE_TIME_TO_XYZT(ss,tt) ( (((char)(ss)) & 0x07) \
1351  | (((char)(tt)) & 0x38) )
1352 
1353 /*---------------------------------------------------------------------------*/
1354 /* MRI-SPECIFIC SPATIAL AND TEMPORAL INFORMATION:
1355  ---------------------------------------------
1356  A few fields are provided to store some extra information
1357  that is sometimes important when storing the image data
1358  from an FMRI time series experiment. (After processing such
1359  data into statistical images, these fields are not likely
1360  to be useful.)
1361 
1362  { freq_dim } = These fields encode which spatial dimension (1,2, or 3)
1363  { phase_dim } = corresponds to which acquisition dimension for MRI data.
1364  { slice_dim } =
1365  Examples:
1366  Rectangular scan multi-slice EPI:
1367  freq_dim = 1 phase_dim = 2 slice_dim = 3 (or some permutation)
1368  Spiral scan multi-slice EPI:
1369  freq_dim = phase_dim = 0 slice_dim = 3
1370  since the concepts of frequency- and phase-encoding directions
1371  don't apply to spiral scan
1372 
1373  slice_duration = If this is positive, AND if slice_dim is nonzero,
1374  indicates the amount of time used to acquire 1 slice.
1375  slice_duration*dim[slice_dim] can be less than pixdim[4]
1376  with a clustered acquisition method, for example.
1377 
1378  slice_code = If this is nonzero, AND if slice_dim is nonzero, AND
1379  if slice_duration is positive, indicates the timing
1380  pattern of the slice acquisition. The following codes
1381  are defined:
1382  NIFTI_SLICE_SEQ_INC == sequential increasing
1383  NIFTI_SLICE_SEQ_DEC == sequential decreasing
1384  NIFTI_SLICE_ALT_INC == alternating increasing
1385  NIFTI_SLICE_ALT_DEC == alternating decreasing
1386  NIFTI_SLICE_ALT_INC2 == alternating increasing #2
1387  NIFTI_SLICE_ALT_DEC2 == alternating decreasing #2
1388  { slice_start } = Indicates the start and end of the slice acquisition
1389  { slice_end } = pattern, when slice_code is nonzero. These values
1390  are present to allow for the possible addition of
1391  "padded" slices at either end of the volume, which
1392  don't fit into the slice timing pattern. If there
1393  are no padding slices, then slice_start=0 and
1394  slice_end=dim[slice_dim]-1 are the correct values.
1395  For these values to be meaningful, slice_start must
1396  be non-negative and slice_end must be greater than
1397  slice_start. Otherwise, they should be ignored.
1398 
1399  The following table indicates the slice timing pattern, relative to
1400  time=0 for the first slice acquired, for some sample cases. Here,
1401  dim[slice_dim]=7 (there are 7 slices, labeled 0..6), slice_duration=0.1,
1402  and slice_start=1, slice_end=5 (1 padded slice on each end).
1403 
1404  slice
1405  index SEQ_INC SEQ_DEC ALT_INC ALT_DEC ALT_INC2 ALT_DEC2
1406  6 : n/a n/a n/a n/a n/a n/a n/a = not applicable
1407  5 : 0.4 0.0 0.2 0.0 0.4 0.2 (slice time offset
1408  4 : 0.3 0.1 0.4 0.3 0.1 0.0 doesn't apply to
1409  3 : 0.2 0.2 0.1 0.1 0.3 0.3 slices outside
1410  2 : 0.1 0.3 0.3 0.4 0.0 0.1 the range
1411  1 : 0.0 0.4 0.0 0.2 0.2 0.4 slice_start ..
1412  0 : n/a n/a n/a n/a n/a n/a slice_end)
1413 
1414  The SEQ slice_codes are sequential ordering (uncommon but not unknown),
1415  either increasing in slice number or decreasing (INC or DEC), as
1416  illustrated above.
1417 
1418  The ALT slice codes are alternating ordering. The 'standard' way for
1419  these to operate (without the '2' on the end) is for the slice timing
1420  to start at the edge of the slice_start .. slice_end group (at slice_start
1421  for INC and at slice_end for DEC). For the 'ALT_*2' slice_codes, the
1422  slice timing instead starts at the first slice in from the edge (at
1423  slice_start+1 for INC2 and at slice_end-1 for DEC2). This latter
1424  acquisition scheme is found on some Siemens scanners.
1425 
1426  The fields freq_dim, phase_dim, slice_dim are all squished into the single
1427  byte field dim_info (2 bits each, since the values for each field are
1428  limited to the range 0..3). This unpleasantness is due to lack of space
1429  in the 348 byte allowance.
1430 
1431  The macros DIM_INFO_TO_FREQ_DIM, DIM_INFO_TO_PHASE_DIM, and
1432  DIM_INFO_TO_SLICE_DIM can be used to extract these values from the
1433  dim_info byte.
1434 
1435  The macro FPS_INTO_DIM_INFO can be used to put these 3 values
1436  into the dim_info byte.
1437 -----------------------------------------------------------------------------*/
1438 
1439 #undef DIM_INFO_TO_FREQ_DIM
1440 #undef DIM_INFO_TO_PHASE_DIM
1441 #undef DIM_INFO_TO_SLICE_DIM
1442 
1443 #define DIM_INFO_TO_FREQ_DIM(di) ( ((di) ) & 0x03 )
1444 #define DIM_INFO_TO_PHASE_DIM(di) ( ((di) >> 2) & 0x03 )
1445 #define DIM_INFO_TO_SLICE_DIM(di) ( ((di) >> 4) & 0x03 )
1446 
1447 #undef FPS_INTO_DIM_INFO
1448 #define FPS_INTO_DIM_INFO(fd,pd,sd) ( ( ( ((char)(fd)) & 0x03) ) | \
1449  ( ( ((char)(pd)) & 0x03) << 2 ) | \
1450  ( ( ((char)(sd)) & 0x03) << 4 ) )
1451 
1457 #define NIFTI_SLICE_UNKNOWN 0
1458 #define NIFTI_SLICE_SEQ_INC 1
1459 #define NIFTI_SLICE_SEQ_DEC 2
1460 #define NIFTI_SLICE_ALT_INC 3
1461 #define NIFTI_SLICE_ALT_DEC 4
1462 #define NIFTI_SLICE_ALT_INC2 5 /* 05 May 2005: RWCox */
1463 #define NIFTI_SLICE_ALT_DEC2 6 /* 05 May 2005: RWCox */
1464 /* @} */
1465 
1466 /*---------------------------------------------------------------------------*/
1467 /* UNUSED FIELDS:
1468  -------------
1469  Some of the ANALYZE 7.5 fields marked as ++UNUSED++ may need to be set
1470  to particular values for compatibility with other programs. The issue
1471  of interoperability of ANALYZE 7.5 files is a murky one -- not all
1472  programs require exactly the same set of fields. (Unobscuring this
1473  murkiness is a principal motivation behind NIFTI-1.)
1474 
1475  Some of the fields that may need to be set for other (non-NIFTI aware)
1476  software to be happy are:
1477 
1478  extents dbh.h says this should be 16384
1479  regular dbh.h says this should be the character 'r'
1480  glmin, } dbh.h says these values should be the min and max voxel
1481  glmax } values for the entire dataset
1482 
1483  It is best to initialize ALL fields in the NIFTI-1 header to 0
1484  (e.g., with calloc()), then fill in what is needed.
1485 -----------------------------------------------------------------------------*/
1486 
1487 /*---------------------------------------------------------------------------*/
1488 /* MISCELLANEOUS C MACROS
1489 -----------------------------------------------------------------------------*/
1490 
1491 /*.................*/
1495 #define NIFTI_VERSION(h) \
1496  ( ( (h).magic[0]=='n' && (h).magic[3]=='\0' && \
1497  ( (h).magic[1]=='i' || (h).magic[1]=='+' ) && \
1498  ( (h).magic[2]>='1' && (h).magic[2]<='9' ) ) \
1499  ? (h).magic[2]-'0' : 0 )
1500 
1501 /*.................*/
1506 #define NIFTI_ONEFILE(h) ( (h).magic[1] == '+' )
1508 /*.................*/
1512 #define NIFTI_NEEDS_SWAP(h) ( (h).dim[0] < 0 || (h).dim[0] > 7 )
1514 /*.................*/
1518 #define NIFTI_5TH_DIM(h) ( ((h).dim[0]>4 && (h).dim[5]>1) ? (h).dim[5] : 0 )
1520 /*****************************************************************************/
1521 
1522 /*=================*/
1523 #ifdef __cplusplus
1524 }
1525 #endif
1526 /*=================*/
1527 
1528 #endif /* _NIFTI_HEADER_ */
nifti_1_header::intent_p1
float intent_p1
Definition: nifti1.h:162
nifti_1_header::descrip
char descrip[80]
Definition: nifti1.h:187
nifti_1_header::regular
char regular
Definition: nifti1.h:157
nifti_1_header::srow_z
float srow_z[4]
Definition: nifti1.h:202
nifti_1_header::glmin
int glmin
Definition: nifti1.h:184
nifti1_extension::ecode
int ecode
Definition: nifti1.h:299
nifti_1_header::slice_code
char slice_code
Definition: nifti1.h:177
nifti_1_header::intent_name
char intent_name[16]
Definition: nifti1.h:204
nifti_1_header::slice_start
short slice_start
Definition: nifti1.h:171
nifti_1_header::quatern_c
float quatern_c
Definition: nifti1.h:194
nifti_1_header::extents
int extents
Definition: nifti1.h:155
nifti_1_header::pixdim
float pixdim[8]
Definition: nifti1.h:172
nifti_1_header::db_name
char db_name[18]
Definition: nifti1.h:154
nifti_1_header::slice_duration
float slice_duration
Definition: nifti1.h:181
nifti_1_header::scl_inter
float scl_inter
Definition: nifti1.h:175
nifti_1_header::session_error
short session_error
Definition: nifti1.h:156
nifti_1_header::quatern_b
float quatern_b
Definition: nifti1.h:193
nifti_1_header::scl_slope
float scl_slope
Definition: nifti1.h:174
nifti_1_header::sizeof_hdr
int sizeof_hdr
Definition: nifti1.h:152
nifti_1_header::slice_end
short slice_end
Definition: nifti1.h:176
nifti_1_header
Data structure defining the fields in the nifti1 header. This binary header should be found at the be...
Definition: nifti1.h:148
nifti_1_header::srow_y
float srow_y[4]
Definition: nifti1.h:201
nifti_1_header::quatern_d
float quatern_d
Definition: nifti1.h:195
nifti_1_header::data_type
char data_type[10]
Definition: nifti1.h:153
nifti_1_header::toffset
float toffset
Definition: nifti1.h:182
nifti1_extension::edata
char * edata
Definition: nifti1.h:300
nifti_1_header::intent_p3
float intent_p3
Definition: nifti1.h:166
nifti_1_header::glmax
int glmax
Definition: nifti1.h:183
nifti_1_header::vox_offset
float vox_offset
Definition: nifti1.h:173
nifti_1_header::qoffset_x
float qoffset_x
Definition: nifti1.h:196
nifti_1_header::srow_x
float srow_x[4]
Definition: nifti1.h:200
nifti_1_header::bitpix
short bitpix
Definition: nifti1.h:170
nifti_1_header::qoffset_y
float qoffset_y
Definition: nifti1.h:197
nifti_1_header::cal_min
float cal_min
Definition: nifti1.h:180
nifti_1_header::xyzt_units
char xyzt_units
Definition: nifti1.h:178
nifti1_extension::esize
int esize
Definition: nifti1.h:298
nifti_1_header::cal_max
float cal_max
Definition: nifti1.h:179
nifti1_extender
This structure represents a 4-byte string that should follow the binary nifti_1_header data in a NIFT...
Definition: nifti1.h:291
nifti_1_header::sform_code
short sform_code
Definition: nifti1.h:191
nifti_1_header::datatype
short datatype
Definition: nifti1.h:169
nifti_1_header::qoffset_z
float qoffset_z
Definition: nifti1.h:198
nifti_1_header::intent_code
short intent_code
Definition: nifti1.h:168
nifti1_extension
Data structure defining the fields of a header extension.
Definition: nifti1.h:297
nifti_1_header::dim_info
char dim_info
Definition: nifti1.h:158
nifti_1_header::aux_file
char aux_file[24]
Definition: nifti1.h:188
nifti_1_header::qform_code
short qform_code
Definition: nifti1.h:190
nifti_1_header::dim
short dim[8]
Definition: nifti1.h:161
nifti_1_header::magic
char magic[4]
Definition: nifti1.h:206
nifti_1_header::intent_p2
float intent_p2
Definition: nifti1.h:164