/root/nifticlib-0.4/niftilib/nifti1.h

Go to the documentation of this file.
00001 
00005 #ifndef _NIFTI_HEADER_
00006 #define _NIFTI_HEADER_
00007 
00008 /*****************************************************************************
00009       ** This file defines the "NIFTI-1" header format.               **
00010       ** It is derived from 2 meetings at the NIH (31 Mar 2003 and    **
00011       ** 02 Sep 2003) of the Data Format Working Group (DFWG),        **
00012       ** chartered by the NIfTI (Neuroimaging Informatics Technology  **
00013       ** Initiative) at the National Institutes of Health (NIH).      **
00014       **--------------------------------------------------------------**
00015       ** Neither the National Institutes of Health (NIH), the DFWG,   **
00016       ** nor any of the members or employees of these institutions    **
00017       ** imply any warranty of usefulness of this material for any    **
00018       ** purpose, and do not assume any liability for damages,        **
00019       ** incidental or otherwise, caused by any use of this document. **
00020       ** If these conditions are not acceptable, do not use this!     **
00021       **--------------------------------------------------------------**
00022       ** Author:   Robert W Cox (NIMH, Bethesda)                      **
00023       ** Advisors: John Ashburner (FIL, London),                      **
00024       **           Stephen Smith (FMRIB, Oxford),                     **
00025       **           Mark Jenkinson (FMRIB, Oxford)                     **
00026 ******************************************************************************/
00027 
00028 /*---------------------------------------------------------------------------*/
00029 /* Note that the ANALYZE 7.5 file header (dbh.h) is
00030          (c) Copyright 1986-1995
00031          Biomedical Imaging Resource
00032          Mayo Foundation
00033    Incorporation of components of dbh.h are by permission of the
00034    Mayo Foundation.
00035 
00036    Changes from the ANALYZE 7.5 file header in this file are released to the
00037    public domain, including the functional comments and any amusing asides.
00038 -----------------------------------------------------------------------------*/
00039 
00040 /*---------------------------------------------------------------------------*/
00108 /*---------------------------------------------------------------------------*/
00109 /* HEADER STRUCT DECLARATION:
00110    -------------------------
00111    In the comments below for each field, only NIFTI-1 specific requirements
00112    or changes from the ANALYZE 7.5 format are described.  For convenience,
00113    the 348 byte header is described as a single struct, rather than as the
00114    ANALYZE 7.5 group of 3 substructs.
00115 
00116    Further comments about the interpretation of various elements of this
00117    header are after the data type definition itself.  Fields that are
00118    marked as ++UNUSED++ have no particular interpretation in this standard.
00119    (Also see the UNUSED FIELDS comment section, far below.)
00120 
00121    The presumption below is that the various C types have particular sizes:
00122      sizeof(int) = sizeof(float) = 4 ;  sizeof(short) = 2
00123 -----------------------------------------------------------------------------*/
00124 
00125 /*=================*/
00126 #ifdef  __cplusplus
00127 extern "C" {
00128 #endif
00129 /*=================*/
00130 
00136                         /*************************/  /************************/
00137 struct nifti_1_header { /* NIFTI-1 usage         */  /* ANALYZE 7.5 field(s) */
00138                         /*************************/  /************************/
00139 
00140                                            /*--- was header_key substruct ---*/
00141  int   sizeof_hdr;      /* int sizeof_hdr;      */
00142  char  data_type[10];   /* char data_type[10];  */
00143  char  db_name[18];     /* char db_name[18];    */
00144  int   extents;         /* int extents;         */
00145  short session_error;   /* short session_error; */
00146  char  regular;         /* char regular;        */
00147  char  dim_info;        /* char hkey_un0;       */
00148 
00149                                       /*--- was image_dimension substruct ---*/
00150  short dim[8];          /* short dim[8];        */
00151  float intent_p1 ;      /* short unused8;       */
00152                                                      /* short unused9;       */
00153  float intent_p2 ;      /* short unused10;      */
00154                                                      /* short unused11;      */
00155  float intent_p3 ;      /* short unused12;      */
00156                                                      /* short unused13;      */
00157  short intent_code ;    /* short unused14;      */
00158  short datatype;        /* short datatype;      */
00159  short bitpix;          /* short bitpix;        */
00160  short slice_start;     /* short dim_un0;       */
00161  float pixdim[8];       /* float pixdim[8];     */
00162  float vox_offset;      /* float vox_offset;    */
00163  float scl_slope ;      /* float funused1;      */
00164  float scl_inter ;      /* float funused2;      */
00165  short slice_end;       /* float funused3;      */
00166  char  slice_code ;   
00167  char  xyzt_units ;   
00168  float cal_max;         /* float cal_max;       */
00169  float cal_min;         /* float cal_min;       */
00170  float slice_duration;  /* float compressed;    */
00171  float toffset;         /* float verified;      */
00172  int   glmax;           /* int glmax;           */
00173  int   glmin;           /* int glmin;           */
00174 
00175                                          /*--- was data_history substruct ---*/
00176  char  descrip[80];     /* char descrip[80];    */
00177  char  aux_file[24];    /* char aux_file[24];   */
00178 
00179  short qform_code ;     /*-- all ANALYZE 7.5 ---*/
00180  short sform_code ;     /*   fields below here  */
00181                                                      /*   are replaced       */
00182  float quatern_b ;    
00183  float quatern_c ;    
00184  float quatern_d ;    
00185  float qoffset_x ;    
00186  float qoffset_y ;    
00187  float qoffset_z ;    
00189  float srow_x[4] ;    
00190  float srow_y[4] ;    
00191  float srow_z[4] ;    
00193  char intent_name[16];
00195  char magic[4] ;      
00197 } ;                   /**** 348 bytes total ****/
00198 
00199 typedef struct nifti_1_header nifti_1_header ;
00200 
00201 /*---------------------------------------------------------------------------*/
00202 /* HEADER EXTENSIONS:
00203    -----------------
00204    After the end of the 348 byte header (e.g., after the magic field),
00205    the next 4 bytes are a char array field named "extension". By default,
00206    all 4 bytes of this array should be set to zero. In a .nii file, these
00207    4 bytes will always be present, since the earliest start point for
00208    the image data is byte #352. In a separate .hdr file, these bytes may
00209    or may not be present. If not present (i.e., if the length of the .hdr
00210    file is 348 bytes), then a NIfTI-1 compliant program should use the
00211    default value of extension={0,0,0,0}. The first byte (extension[0])
00212    is the only value of this array that is specified at present. The other
00213    3 bytes are reserved for future use.
00214 
00215    If extension[0] is nonzero, it indicates that extended header information
00216    is present in the bytes following the extension array. In a .nii file,
00217    this extended header data is before the image data (and vox_offset
00218    must be set correctly to allow for this). In a .hdr file, this extended
00219    data follows extension and proceeds (potentially) to the end of the file.
00220 
00221    The format of extended header data is weakly specified. Each extension
00222    must be an integer multiple of 16 bytes long. The first 8 bytes of each
00223    extension comprise 2 integers:
00224       int esize , ecode ;
00225    These values may need to be byte-swapped, as indicated by dim[0] for
00226    the rest of the header.
00227      * esize is the number of bytes that form the extended header data
00228        + esize must be a positive integral multiple of 16
00229        + this length includes the 8 bytes of esize and ecode themselves
00230      * ecode is a non-negative integer that indicates the format of the
00231        extended header data that follows
00232        + different ecode values are assigned to different developer groups
00233        + at present, the "registered" values for code are
00234          = 0 = unknown private format (not recommended!)
00235          = 2 = DICOM format (i.e., attribute tags and values)
00236          = 4 = AFNI group (i.e., ASCII XML-ish elements)
00237    In the interests of interoperability (a primary rationale for NIfTI),
00238    groups developing software that uses this extension mechanism are
00239    encouraged to document and publicize the format of their extensions.
00240    To this end, the NIfTI DFWG will assign even numbered codes upon request
00241    to groups submitting at least rudimentary documentation for the format
00242    of their extension; at present, the contact is mailto:rwcox@nih.gov.
00243    The assigned codes and documentation will be posted on the NIfTI
00244    website. All odd values of ecode (and 0) will remain unassigned;
00245    at least, until the even ones are used up, when we get to 2,147,483,646.
00246 
00247    Note that the other contents of the extended header data section are
00248    totally unspecified by the NIfTI-1 standard. In particular, if binary
00249    data is stored in such a section, its byte order is not necessarily
00250    the same as that given by examining dim[0]; it is incumbent on the
00251    programs dealing with such data to determine the byte order of binary
00252    extended header data.
00253 
00254    Multiple extended header sections are allowed, each starting with an
00255    esize,ecode value pair. The first esize value, as described above,
00256    is at bytes #352-355 in the .hdr or .nii file (files start at byte #0).
00257    If this value is positive, then the second (esize2) will be found
00258    starting at byte #352+esize1 , the third (esize3) at byte #352+esize1+esize2,
00259    et cetera.  Of course, in a .nii file, the value of vox_offset must
00260    be compatible with these extensions. If a malformed file indicates
00261    that an extended header data section would run past vox_offset, then
00262    the entire extended header section should be ignored. In a .hdr file,
00263    if an extended header data section would run past the end-of-file,
00264    that extended header data should also be ignored.
00265 
00266    With the above scheme, a program can successively examine the esize
00267    and ecode values, and skip over each extended header section if the
00268    program doesn't know how to interpret the data within. Of course, any
00269    program can simply ignore all extended header sections simply by jumping
00270    straight to the image data using vox_offset.
00271 -----------------------------------------------------------------------------*/
00272    
00280 struct nifti1_extender { char extension[4] ; } ;
00281 typedef struct nifti1_extender nifti1_extender ;
00282 
00286 struct nifti1_extension {
00287    int    esize ; 
00288    int    ecode ; 
00289    char * edata ; 
00290 } ;
00291 typedef struct nifti1_extension nifti1_extension ;
00292 
00293 /*---------------------------------------------------------------------------*/
00294 /* DATA DIMENSIONALITY (as in ANALYZE 7.5):
00295    ---------------------------------------
00296      dim[0] = number of dimensions;
00297               - if dim[0] is outside range 1..7, then the header information
00298                 needs to be byte swapped appropriately
00299               - ANALYZE supports dim[0] up to 7, but NIFTI-1 reserves
00300                 dimensions 1,2,3 for space (x,y,z), 4 for time (t), and
00301                 5,6,7 for anything else needed.
00302 
00303      dim[i] = length of dimension #i, for i=1..dim[0]  (must be positive)
00304               - also see the discussion of intent_code, far below
00305 
00306      pixdim[i] = voxel width along dimension #i, i=1..dim[0] (positive)
00307                  - cf. ORIENTATION section below for use of pixdim[0]
00308                  - the units of pixdim can be specified with the xyzt_units
00309                    field (also described far below).
00310 
00311    Number of bits per voxel value is in bitpix, which MUST correspond with
00312    the datatype field.  The total number of bytes in the image data is
00313      dim[1] * ... * dim[dim[0]] * bitpix / 8
00314 
00315    In NIFTI-1 files, dimensions 1,2,3 are for space, dimension 4 is for time,
00316    and dimension 5 is for storing multiple values at each spatiotemporal
00317    voxel.  Some examples:
00318      - A typical whole-brain FMRI experiment's time series:
00319         - dim[0] = 4
00320         - dim[1] = 64   pixdim[1] = 3.75 xyzt_units =  NIFTI_UNITS_MM
00321         - dim[2] = 64   pixdim[2] = 3.75             | NIFTI_UNITS_SEC
00322         - dim[3] = 20   pixdim[3] = 5.0
00323         - dim[4] = 120  pixdim[4] = 2.0
00324      - A typical T1-weighted anatomical volume:
00325         - dim[0] = 3
00326         - dim[1] = 256  pixdim[1] = 1.0  xyzt_units = NIFTI_UNITS_MM
00327         - dim[2] = 256  pixdim[2] = 1.0
00328         - dim[3] = 128  pixdim[3] = 1.1
00329      - A single slice EPI time series:
00330         - dim[0] = 4
00331         - dim[1] = 64   pixdim[1] = 3.75 xyzt_units =  NIFTI_UNITS_MM
00332         - dim[2] = 64   pixdim[2] = 3.75             | NIFTI_UNITS_SEC
00333         - dim[3] = 1    pixdim[3] = 5.0
00334         - dim[4] = 1200 pixdim[4] = 0.2
00335      - A 3-vector stored at each point in a 3D volume:
00336         - dim[0] = 5
00337         - dim[1] = 256  pixdim[1] = 1.0  xyzt_units = NIFTI_UNITS_MM
00338         - dim[2] = 256  pixdim[2] = 1.0
00339         - dim[3] = 128  pixdim[3] = 1.1
00340         - dim[4] = 1    pixdim[4] = 0.0
00341         - dim[5] = 3                     intent_code = NIFTI_INTENT_VECTOR
00342      - A single time series with a 3x3 matrix at each point:
00343         - dim[0] = 5
00344         - dim[1] = 1                     xyzt_units = NIFTI_UNITS_SEC
00345         - dim[2] = 1
00346         - dim[3] = 1
00347         - dim[4] = 1200 pixdim[4] = 0.2
00348         - dim[5] = 9                     intent_code = NIFTI_INTENT_GENMATRIX
00349         - intent_p1 = intent_p2 = 3.0    (indicates matrix dimensions)
00350 -----------------------------------------------------------------------------*/
00351 
00352 /*---------------------------------------------------------------------------*/
00353 /* DATA STORAGE:
00354    ------------
00355    If the magic field is "n+1", then the voxel data is stored in the
00356    same file as the header.  In this case, the voxel data starts at offset
00357    (int)vox_offset into the header file.  Thus, vox_offset=352.0 means that
00358    the data starts immediately after the NIFTI-1 header.  If vox_offset is
00359    greater than 352, the NIFTI-1 format does not say much about the
00360    contents of the dataset file between the end of the header and the
00361    start of the data.
00362 
00363    FILES:
00364    -----
00365    If the magic field is "ni1", then the voxel data is stored in the
00366    associated ".img" file, starting at offset 0 (i.e., vox_offset is not
00367    used in this case, and should be set to 0.0).
00368 
00369    When storing NIFTI-1 datasets in pairs of files, it is customary to name
00370    the files in the pattern "name.hdr" and "name.img", as in ANALYZE 7.5.
00371    When storing in a single file ("n+1"), the file name should be in
00372    the form "name.nii" (the ".nft" and ".nif" suffixes are already taken;
00373    cf. http://www.icdatamaster.com/n.html ).
00374 
00375    BYTE ORDERING:
00376    -------------
00377    The byte order of the data arrays is presumed to be the same as the byte
00378    order of the header (which is determined by examining dim[0]).
00379 
00380    Floating point types are presumed to be stored in IEEE-754 format.
00381 -----------------------------------------------------------------------------*/
00382 
00383 /*---------------------------------------------------------------------------*/
00384 /* DETAILS ABOUT vox_offset:
00385    ------------------------
00386    In a .nii file, the vox_offset field value is interpreted as the start
00387    location of the image data bytes in that file. In a .hdr/.img file pair,
00388    the vox_offset field value is the start location of the image data
00389    bytes in the .img file.
00390     * If vox_offset is less than 352 in a .nii file, it is equivalent
00391       to 352 (i.e., image data never starts before byte #352 in a .nii file).
00392     * The default value for vox_offset in a .nii file is 352.
00393     * In a .hdr file, the default value for vox_offset is 0.
00394     * vox_offset should be an integer multiple of 16; otherwise, some
00395       programs may not work properly (e.g., SPM). This is to allow
00396       memory-mapped input to be properly byte-aligned.
00397    Note that since vox_offset is an IEEE-754 32 bit float (for compatibility
00398    with the ANALYZE-7.5 format), it effectively has a 24 bit mantissa. All
00399    integers from 0 to 2^24 can be represented exactly in this format, but not
00400    all larger integers are exactly storable as IEEE-754 32 bit floats. However,
00401    unless you plan to have vox_offset be potentially larger than 16 MB, this
00402    should not be an issue. (Actually, any integral multiple of 16 up to 2^27
00403    can be represented exactly in this format, which allows for up to 128 MB
00404    of random information before the image data.  If that isn't enough, then
00405    perhaps this format isn't right for you.)
00406 
00407    In a .img file (i.e., image data stored separately from the NIfTI-1
00408    header), data bytes between #0 and #vox_offset-1 (inclusive) are completely
00409    undefined and unregulated by the NIfTI-1 standard. One potential use of
00410    having vox_offset > 0 in the .hdr/.img file pair storage method is to make
00411    the .img file be a copy of (or link to) a pre-existing image file in some
00412    other format, such as DICOM; then vox_offset would be set to the offset of
00413    the image data in this file. (It may not be possible to follow the
00414    "multiple-of-16 rule" with an arbitrary external file; using the NIfTI-1
00415    format in such a case may lead to a file that is incompatible with software
00416    that relies on vox_offset being a multiple of 16.)
00417 
00418    In a .nii file, data bytes between #348 and #vox_offset-1 (inclusive) may
00419    be used to store user-defined extra information; similarly, in a .hdr file,
00420    any data bytes after byte #347 are available for user-defined extra
00421    information. The (very weak) regulation of this extra header data is
00422    described elsewhere.
00423 -----------------------------------------------------------------------------*/
00424 
00425 /*---------------------------------------------------------------------------*/
00426 /* DATA SCALING:
00427    ------------
00428    If the scl_slope field is nonzero, then each voxel value in the dataset
00429    should be scaled as
00430       y = scl_slope * x + scl_inter
00431    where x = voxel value stored
00432          y = "true" voxel value
00433    Normally, we would expect this scaling to be used to store "true" floating
00434    values in a smaller integer datatype, but that is not required.  That is,
00435    it is legal to use scaling even if the datatype is a float type (crazy,
00436    perhaps, but legal).
00437     - However, the scaling is to be ignored if datatype is DT_RGB24.
00438     - If datatype is a complex type, then the scaling is to be
00439       applied to both the real and imaginary parts.
00440 
00441    The cal_min and cal_max fields (if nonzero) are used for mapping (possibly
00442    scaled) dataset values to display colors:
00443     - Minimum display intensity (black) corresponds to dataset value cal_min.
00444     - Maximum display intensity (white) corresponds to dataset value cal_max.
00445     - Dataset values below cal_min should display as black also, and values
00446       above cal_max as white.
00447     - Colors "black" and "white", of course, may refer to any scalar display
00448       scheme (e.g., a color lookup table specified via aux_file).
00449     - cal_min and cal_max only make sense when applied to scalar-valued
00450       datasets (i.e., dim[0] < 5 or dim[5] = 1).
00451 -----------------------------------------------------------------------------*/
00452 
00453 /*---------------------------------------------------------------------------*/
00454 /* TYPE OF DATA (acceptable values for datatype field):
00455    ---------------------------------------------------
00456    Values of datatype smaller than 256 are ANALYZE 7.5 compatible.
00457    Larger values are NIFTI-1 additions.  These are all multiples of 256, so
00458    that no bits below position 8 are set in datatype.  But there is no need
00459    to use only powers-of-2, as the original ANALYZE 7.5 datatype codes do.
00460 
00461    The additional codes are intended to include a complete list of basic
00462    scalar types, including signed and unsigned integers from 8 to 64 bits,
00463    floats from 32 to 128 bits, and complex (float pairs) from 64 to 256 bits.
00464 
00465    Note that most programs will support only a few of these datatypes!
00466    A NIFTI-1 program should fail gracefully (e.g., print a warning message)
00467    when it encounters a dataset with a type it doesn't like.
00468 -----------------------------------------------------------------------------*/
00469 
00470 #undef DT_UNKNOWN  /* defined in dirent.h on some Unix systems */
00471 
00476                             /*--- the original ANALYZE 7.5 type codes ---*/
00477 #define DT_NONE                    0
00478 #define DT_UNKNOWN                 0     /* what it says, dude           */
00479 #define DT_BINARY                  1     /* binary (1 bit/voxel)         */
00480 #define DT_UNSIGNED_CHAR           2     /* unsigned char (8 bits/voxel) */
00481 #define DT_SIGNED_SHORT            4     /* signed short (16 bits/voxel) */
00482 #define DT_SIGNED_INT              8     /* signed int (32 bits/voxel)   */
00483 #define DT_FLOAT                  16     /* float (32 bits/voxel)        */
00484 #define DT_COMPLEX                32     /* complex (64 bits/voxel)      */
00485 #define DT_DOUBLE                 64     /* double (64 bits/voxel)       */
00486 #define DT_RGB                   128     /* RGB triple (24 bits/voxel)   */
00487 #define DT_ALL                   255     /* not very useful (?)          */
00488 
00489                             /*----- another set of names for the same ---*/
00490 #define DT_UINT8                   2
00491 #define DT_INT16                   4
00492 #define DT_INT32                   8
00493 #define DT_FLOAT32                16
00494 #define DT_COMPLEX64              32
00495 #define DT_FLOAT64                64
00496 #define DT_RGB24                 128
00497 
00498                             /*------------------- new codes for NIFTI ---*/
00499 #define DT_INT8                  256     /* signed char (8 bits)         */
00500 #define DT_UINT16                512     /* unsigned short (16 bits)     */
00501 #define DT_UINT32                768     /* unsigned int (32 bits)       */
00502 #define DT_INT64                1024     /* long long (64 bits)          */
00503 #define DT_UINT64               1280     /* unsigned long long (64 bits) */
00504 #define DT_FLOAT128             1536     /* long double (128 bits)       */
00505 #define DT_COMPLEX128           1792     /* double pair (128 bits)       */
00506 #define DT_COMPLEX256           2048     /* long double pair (256 bits)  */
00507 /* @} */
00508 
00509 
00510                             /*------- aliases for all the above codes ---*/
00511 
00517 #define NIFTI_TYPE_UINT8           2
00518 
00519 #define NIFTI_TYPE_INT16           4
00520 
00521 #define NIFTI_TYPE_INT32           8
00522 
00523 #define NIFTI_TYPE_FLOAT32        16
00524 
00525 #define NIFTI_TYPE_COMPLEX64      32
00526 
00527 #define NIFTI_TYPE_FLOAT64        64
00528 
00529 #define NIFTI_TYPE_RGB24         128
00530 
00531 #define NIFTI_TYPE_INT8          256
00532 
00533 #define NIFTI_TYPE_UINT16        512
00534 
00535 #define NIFTI_TYPE_UINT32        768
00536 
00537 #define NIFTI_TYPE_INT64        1024
00538 
00539 #define NIFTI_TYPE_UINT64       1280
00540 
00541 #define NIFTI_TYPE_FLOAT128     1536
00542 
00543 #define NIFTI_TYPE_COMPLEX128   1792
00544 
00545 #define NIFTI_TYPE_COMPLEX256   2048
00546 /* @} */
00547 
00548                      /*-------- sample typedefs for complicated types ---*/
00549 #if 0
00550 typedef struct { float       r,i;     } complex_float ;
00551 typedef struct { double      r,i;     } complex_double ;
00552 typedef struct { long double r,i;     } complex_longdouble ;
00553 typedef struct { unsigned char r,g,b; } rgb_byte ;
00554 #endif
00555 
00556 /*---------------------------------------------------------------------------*/
00557 /* INTERPRETATION OF VOXEL DATA:
00558    ----------------------------
00559    The intent_code field can be used to indicate that the voxel data has
00560    some particular meaning.  In particular, a large number of codes is
00561    given to indicate that the the voxel data should be interpreted as
00562    being drawn from a given probability distribution.
00563 
00564    VECTOR-VALUED DATASETS:
00565    ----------------------
00566    The 5th dimension of the dataset, if present (i.e., dim[0]=5 and
00567    dim[5] > 1), contains multiple values (e.g., a vector) to be stored
00568    at each spatiotemporal location.  For example, the header values
00569     - dim[0] = 5
00570     - dim[1] = 64
00571     - dim[2] = 64
00572     - dim[3] = 20
00573     - dim[4] = 1     (indicates no time axis)
00574     - dim[5] = 3
00575     - datatype = DT_FLOAT
00576     - intent_code = NIFTI_INTENT_VECTOR
00577    mean that this dataset should be interpreted as a 3D volume (64x64x20),
00578    with a 3-vector of floats defined at each point in the 3D grid.
00579 
00580    A program reading a dataset with a 5th dimension may want to reformat
00581    the image data to store each voxels' set of values together in a struct
00582    or array.  This programming detail, however, is beyond the scope of the
00583    NIFTI-1 file specification!  Uses of dimensions 6 and 7 are also not
00584    specified here.
00585 
00586    STATISTICAL PARAMETRIC DATASETS (i.e., SPMs):
00587    --------------------------------------------
00588    Values of intent_code from NIFTI_FIRST_STATCODE to NIFTI_LAST_STATCODE
00589    (inclusive) indicate that the numbers in the dataset should be interpreted
00590    as being drawn from a given distribution.  Most such distributions have
00591    auxiliary parameters (e.g., NIFTI_INTENT_TTEST has 1 DOF parameter).
00592 
00593    If the dataset DOES NOT have a 5th dimension, then the auxiliary parameters
00594    are the same for each voxel, and are given in header fields intent_p1,
00595    intent_p2, and intent_p3.
00596 
00597    If the dataset DOES have a 5th dimension, then the auxiliary parameters
00598    are different for each voxel.  For example, the header values
00599     - dim[0] = 5
00600     - dim[1] = 128
00601     - dim[2] = 128
00602     - dim[3] = 1      (indicates a single slice)
00603     - dim[4] = 1      (indicates no time axis)
00604     - dim[5] = 2
00605     - datatype = DT_FLOAT
00606     - intent_code = NIFTI_INTENT_TTEST
00607    mean that this is a 2D dataset (128x128) of t-statistics, with the
00608    t-statistic being in the first "plane" of data and the degrees-of-freedom
00609    parameter being in the second "plane" of data.
00610 
00611    If the dataset 5th dimension is used to store the voxel-wise statistical
00612    parameters, then dim[5] must be 1 plus the number of parameters required
00613    by that distribution (e.g., intent_code=NIFTI_INTENT_TTEST implies dim[5]
00614    must be 2, as in the example just above).
00615 
00616    Note: intent_code values 2..10 are compatible with AFNI 1.5x (which is
00617    why there is no code with value=1, which is obsolescent in AFNI).
00618 
00619    OTHER INTENTIONS:
00620    ----------------
00621    The purpose of the intent_* fields is to help interpret the values
00622    stored in the dataset.  Some non-statistical values for intent_code
00623    and conventions are provided for storing other complex data types.
00624 
00625    The intent_name field provides space for a 15 character (plus 0 byte)
00626    'name' string for the type of data stored. Examples:
00627     - intent_code = NIFTI_INTENT_ESTIMATE; intent_name = "T1";
00628        could be used to signify that the voxel values are estimates of the
00629        NMR parameter T1.
00630     - intent_code = NIFTI_INTENT_TTEST; intent_name = "House";
00631        could be used to signify that the voxel values are t-statistics
00632        for the significance of 'activation' response to a House stimulus.
00633     - intent_code = NIFTI_INTENT_DISPVECT; intent_name = "ToMNI152";
00634        could be used to signify that the voxel values are a displacement
00635        vector that transforms each voxel (x,y,z) location to the
00636        corresponding location in the MNI152 standard brain.
00637     - intent_code = NIFTI_INTENT_SYMMATRIX; intent_name = "DTI";
00638        could be used to signify that the voxel values comprise a diffusion
00639        tensor image.
00640 
00641    If no data name is implied or needed, intent_name[0] should be set to 0.
00642 -----------------------------------------------------------------------------*/
00643 
00646 #define NIFTI_INTENT_NONE        0
00647 
00648     /*-------- These codes are for probability distributions ---------------*/
00649     /* Most distributions have a number of parameters,
00650        below denoted by p1, p2, and p3, and stored in
00651         - intent_p1, intent_p2, intent_p3 if dataset doesn't have 5th dimension
00652         - image data array                if dataset does have 5th dimension
00653 
00654        Functions to compute with many of the distributions below can be found
00655        in the CDF library from U Texas.
00656 
00657        Formulas for and discussions of these distributions can be found in the
00658        following books:
00659 
00660         [U] Univariate Discrete Distributions,
00661             NL Johnson, S Kotz, AW Kemp.
00662 
00663         [C1] Continuous Univariate Distributions, vol. 1,
00664              NL Johnson, S Kotz, N Balakrishnan.
00665 
00666         [C2] Continuous Univariate Distributions, vol. 2,
00667              NL Johnson, S Kotz, N Balakrishnan.                            */
00668     /*----------------------------------------------------------------------*/
00669 
00678 #define NIFTI_INTENT_CORREL      2
00679 
00682 #define NIFTI_INTENT_TTEST       3
00683 
00687 #define NIFTI_INTENT_FTEST       4
00688 
00691 #define NIFTI_INTENT_ZSCORE      5
00692 
00696 #define NIFTI_INTENT_CHISQ       6
00697 
00701 #define NIFTI_INTENT_BETA        7
00702 
00707 #define NIFTI_INTENT_BINOM       8
00708 
00713 #define NIFTI_INTENT_GAMMA       9
00714 
00718 #define NIFTI_INTENT_POISSON    10
00719 
00723 #define NIFTI_INTENT_NORMAL     11
00724 
00729 #define NIFTI_INTENT_FTEST_NONC 12
00730 
00734 #define NIFTI_INTENT_CHISQ_NONC 13
00735 
00740 #define NIFTI_INTENT_LOGISTIC   14
00741 
00746 #define NIFTI_INTENT_LAPLACE    15
00747 
00750 #define NIFTI_INTENT_UNIFORM    16
00751 
00755 #define NIFTI_INTENT_TTEST_NONC 17
00756 
00762 #define NIFTI_INTENT_WEIBULL    18
00763 
00770 #define NIFTI_INTENT_CHI        19
00771 
00777 #define NIFTI_INTENT_INVGAUSS   20
00778 
00783 #define NIFTI_INTENT_EXTVAL     21
00784 
00787 #define NIFTI_INTENT_PVAL       22
00788 
00795 #define NIFTI_INTENT_LOGPVAL    23
00796 
00802 #define NIFTI_INTENT_LOG10PVAL  24
00803 
00806 #define NIFTI_FIRST_STATCODE     2
00807 
00810 #define NIFTI_LAST_STATCODE     24
00811 
00812  /*---------- these values for intent_code aren't for statistics ----------*/
00813 
00818 #define NIFTI_INTENT_ESTIMATE  1001
00819 
00824 #define NIFTI_INTENT_LABEL     1002
00825 
00829 #define NIFTI_INTENT_NEURONAME 1003
00830 
00843 #define NIFTI_INTENT_GENMATRIX 1004
00844 
00856 #define NIFTI_INTENT_SYMMATRIX 1005
00857 
00865 #define NIFTI_INTENT_DISPVECT  1006   /* specifically for displacements */
00866 #define NIFTI_INTENT_VECTOR    1007   /* for any other type of vector */
00867 
00879 #define NIFTI_INTENT_POINTSET  1008
00880 
00892 #define NIFTI_INTENT_TRIANGLE  1009
00893 
00901 #define NIFTI_INTENT_QUATERNION 1010
00902 
00906 #define NIFTI_INTENT_DIMLESS    1011
00907 /* @} */
00908 
00909 /*---------------------------------------------------------------------------*/
00910 /* 3D IMAGE (VOLUME) ORIENTATION AND LOCATION IN SPACE:
00911    ---------------------------------------------------
00912    There are 3 different methods by which continuous coordinates can
00913    attached to voxels.  The discussion below emphasizes 3D volumes, and
00914    the continuous coordinates are referred to as (x,y,z).  The voxel
00915    index coordinates (i.e., the array indexes) are referred to as (i,j,k),
00916    with valid ranges:
00917      i = 0 .. dim[1]-1
00918      j = 0 .. dim[2]-1  (if dim[0] >= 2)
00919      k = 0 .. dim[3]-1  (if dim[0] >= 3)
00920    The (x,y,z) coordinates refer to the CENTER of a voxel.  In methods
00921    2 and 3, the (x,y,z) axes refer to a subject-based coordinate system,
00922    with
00923      +x = Right  +y = Anterior  +z = Superior.
00924    This is a right-handed coordinate system.  However, the exact direction
00925    these axes point with respect to the subject depends on qform_code
00926    (Method 2) and sform_code (Method 3).
00927 
00928    N.B.: The i index varies most rapidly, j index next, k index slowest.
00929     Thus, voxel (i,j,k) is stored starting at location
00930       (i + j*dim[1] + k*dim[1]*dim[2]) * (bitpix/8)
00931     into the dataset array.
00932 
00933    N.B.: The ANALYZE 7.5 coordinate system is
00934       +x = Left  +y = Anterior  +z = Superior
00935     which is a left-handed coordinate system.  This backwardness is
00936     too difficult to tolerate, so this NIFTI-1 standard specifies the
00937     coordinate order which is most common in functional neuroimaging.
00938 
00939    N.B.: The 3 methods below all give the locations of the voxel centers
00940     in the (x,y,z) coordinate system.  In many cases, programs will wish
00941     to display image data on some other grid.  In such a case, the program
00942     will need to convert its desired (x,y,z) values into (i,j,k) values
00943     in order to extract (or interpolate) the image data.  This operation
00944     would be done with the inverse transformation to those described below.
00945 
00946    N.B.: Method 2 uses a factor 'qfac' which is either -1 or 1; qfac is
00947     stored in the otherwise unused pixdim[0].  If pixdim[0]=0.0 (which
00948     should not occur), we take qfac=1.  Of course, pixdim[0] is only used
00949     when reading a NIFTI-1 header, not when reading an ANALYZE 7.5 header.
00950 
00951    N.B.: The units of (x,y,z) can be specified using the xyzt_units field.
00952 
00953    METHOD 1 (the "old" way, used only when qform_code = 0):
00954    -------------------------------------------------------
00955    The coordinate mapping from (i,j,k) to (x,y,z) is the ANALYZE
00956    7.5 way.  This is a simple scaling relationship:
00957 
00958      x = pixdim[1] * i
00959      y = pixdim[2] * j
00960      z = pixdim[3] * k
00961 
00962    No particular spatial orientation is attached to these (x,y,z)
00963    coordinates.  (NIFTI-1 does not have the ANALYZE 7.5 orient field,
00964    which is not general and is often not set properly.)  This method
00965    is not recommended, and is present mainly for compatibility with
00966    ANALYZE 7.5 files.
00967 
00968    METHOD 2 (used when qform_code > 0, which should be the "normal" case):
00969    ---------------------------------------------------------------------
00970    The (x,y,z) coordinates are given by the pixdim[] scales, a rotation
00971    matrix, and a shift.  This method is intended to represent
00972    "scanner-anatomical" coordinates, which are often embedded in the
00973    image header (e.g., DICOM fields (0020,0032), (0020,0037), (0028,0030),
00974    and (0018,0050)), and represent the nominal orientation and location of
00975    the data.  This method can also be used to represent "aligned"
00976    coordinates, which would typically result from some post-acquisition
00977    alignment of the volume to a standard orientation (e.g., the same
00978    subject on another day, or a rigid rotation to true anatomical
00979    orientation from the tilted position of the subject in the scanner).
00980    The formula for (x,y,z) in terms of header parameters and (i,j,k) is:
00981 
00982      [ x ]   [ R11 R12 R13 ] [        pixdim[1] * i ]   [ qoffset_x ]
00983      [ y ] = [ R21 R22 R23 ] [        pixdim[2] * j ] + [ qoffset_y ]
00984      [ z ]   [ R31 R32 R33 ] [ qfac * pixdim[3] * k ]   [ qoffset_z ]
00985 
00986    The qoffset_* shifts are in the NIFTI-1 header.  Note that the center
00987    of the (i,j,k)=(0,0,0) voxel (first value in the dataset array) is
00988    just (x,y,z)=(qoffset_x,qoffset_y,qoffset_z).
00989 
00990    The rotation matrix R is calculated from the quatern_* parameters.
00991    This calculation is described below.
00992 
00993    The scaling factor qfac is either 1 or -1.  The rotation matrix R
00994    defined by the quaternion parameters is "proper" (has determinant 1).
00995    This may not fit the needs of the data; for example, if the image
00996    grid is
00997      i increases from Left-to-Right
00998      j increases from Anterior-to-Posterior
00999      k increases from Inferior-to-Superior
01000    Then (i,j,k) is a left-handed triple.  In this example, if qfac=1,
01001    the R matrix would have to be
01002 
01003      [  1   0   0 ]
01004      [  0  -1   0 ]  which is "improper" (determinant = -1).
01005      [  0   0   1 ]
01006 
01007    If we set qfac=-1, then the R matrix would be
01008 
01009      [  1   0   0 ]
01010      [  0  -1   0 ]  which is proper.
01011      [  0   0  -1 ]
01012 
01013    This R matrix is represented by quaternion [a,b,c,d] = [0,1,0,0]
01014    (which encodes a 180 degree rotation about the x-axis).
01015 
01016    METHOD 3 (used when sform_code > 0):
01017    -----------------------------------
01018    The (x,y,z) coordinates are given by a general affine transformation
01019    of the (i,j,k) indexes:
01020 
01021      x = srow_x[0] * i + srow_x[1] * j + srow_x[2] * k + srow_x[3]
01022      y = srow_y[0] * i + srow_y[1] * j + srow_y[2] * k + srow_y[3]
01023      z = srow_z[0] * i + srow_z[1] * j + srow_z[2] * k + srow_z[3]
01024 
01025    The srow_* vectors are in the NIFTI_1 header.  Note that no use is
01026    made of pixdim[] in this method.
01027 
01028    WHY 3 METHODS?
01029    --------------
01030    Method 1 is provided only for backwards compatibility.  The intention
01031    is that Method 2 (qform_code > 0) represents the nominal voxel locations
01032    as reported by the scanner, or as rotated to some fiducial orientation and
01033    location.  Method 3, if present (sform_code > 0), is to be used to give
01034    the location of the voxels in some standard space.  The sform_code
01035    indicates which standard space is present.  Both methods 2 and 3 can be
01036    present, and be useful in different contexts (method 2 for displaying the
01037    data on its original grid; method 3 for displaying it on a standard grid).
01038 
01039    In this scheme, a dataset would originally be set up so that the
01040    Method 2 coordinates represent what the scanner reported.  Later,
01041    a registration to some standard space can be computed and inserted
01042    in the header.  Image display software can use either transform,
01043    depending on its purposes and needs.
01044 
01045    In Method 2, the origin of coordinates would generally be whatever
01046    the scanner origin is; for example, in MRI, (0,0,0) is the center
01047    of the gradient coil.
01048 
01049    In Method 3, the origin of coordinates would depend on the value
01050    of sform_code; for example, for the Talairach coordinate system,
01051    (0,0,0) corresponds to the Anterior Commissure.
01052 
01053    QUATERNION REPRESENTATION OF ROTATION MATRIX (METHOD 2)
01054    -------------------------------------------------------
01055    The orientation of the (x,y,z) axes relative to the (i,j,k) axes
01056    in 3D space is specified using a unit quaternion [a,b,c,d], where
01057    a*a+b*b+c*c+d*d=1.  The (b,c,d) values are all that is needed, since
01058    we require that a = sqrt(1.0-(b*b+c*c+d*d)) be nonnegative.  The (b,c,d)
01059    values are stored in the (quatern_b,quatern_c,quatern_d) fields.
01060 
01061    The quaternion representation is chosen for its compactness in
01062    representing rotations. The (proper) 3x3 rotation matrix that
01063    corresponds to [a,b,c,d] is
01064 
01065          [ a*a+b*b-c*c-d*d   2*b*c-2*a*d       2*b*d+2*a*c     ]
01066      R = [ 2*b*c+2*a*d       a*a+c*c-b*b-d*d   2*c*d-2*a*b     ]
01067          [ 2*b*d-2*a*c       2*c*d+2*a*b       a*a+d*d-c*c-b*b ]
01068 
01069          [ R11               R12               R13             ]
01070        = [ R21               R22               R23             ]
01071          [ R31               R32               R33             ]
01072 
01073    If (p,q,r) is a unit 3-vector, then rotation of angle h about that
01074    direction is represented by the quaternion
01075 
01076      [a,b,c,d] = [cos(h/2), p*sin(h/2), q*sin(h/2), r*sin(h/2)].
01077 
01078    Requiring a >= 0 is equivalent to requiring -Pi <= h <= Pi.  (Note that
01079    [-a,-b,-c,-d] represents the same rotation as [a,b,c,d]; there are 2
01080    quaternions that can be used to represent a given rotation matrix R.)
01081    To rotate a 3-vector (x,y,z) using quaternions, we compute the
01082    quaternion product
01083 
01084      [0,x',y',z'] = [a,b,c,d] * [0,x,y,z] * [a,-b,-c,-d]
01085 
01086    which is equivalent to the matrix-vector multiply
01087 
01088      [ x' ]     [ x ]
01089      [ y' ] = R [ y ]   (equivalence depends on a*a+b*b+c*c+d*d=1)
01090      [ z' ]     [ z ]
01091 
01092    Multiplication of 2 quaternions is defined by the following:
01093 
01094      [a,b,c,d] = a*1 + b*I + c*J + d*K
01095      where
01096        I*I = J*J = K*K = -1 (I,J,K are square roots of -1)
01097        I*J =  K    J*K =  I    K*I =  J
01098        J*I = -K    K*J = -I    I*K = -J  (not commutative!)
01099      For example
01100        [a,b,0,0] * [0,0,0,1] = [0,0,-b,a]
01101      since this expands to
01102        (a+b*I)*(K) = (a*K+b*I*K) = (a*K-b*J).
01103 
01104    The above formula shows how to go from quaternion (b,c,d) to
01105    rotation matrix and direction cosines.  Conversely, given R,
01106    we can compute the fields for the NIFTI-1 header by
01107 
01108      a = 0.5  * sqrt(1+R11+R22+R33)    (not stored)
01109      b = 0.25 * (R32-R23) / a       => quatern_b
01110      c = 0.25 * (R13-R31) / a       => quatern_c
01111      d = 0.25 * (R21-R12) / a       => quatern_d
01112 
01113    If a=0 (a 180 degree rotation), alternative formulas are needed.
01114    See the nifti1_io.c function mat44_to_quatern() for an implementation
01115    of the various cases in converting R to [a,b,c,d].
01116 
01117    Note that R-transpose (= R-inverse) would lead to the quaternion
01118    [a,-b,-c,-d].
01119 
01120    The choice to specify the qoffset_x (etc.) values in the final
01121    coordinate system is partly to make it easy to convert DICOM images to
01122    this format.  The DICOM attribute "Image Position (Patient)" (0020,0032)
01123    stores the (Xd,Yd,Zd) coordinates of the center of the first voxel.
01124    Here, (Xd,Yd,Zd) refer to DICOM coordinates, and Xd=-x, Yd=-y, Zd=z,
01125    where (x,y,z) refers to the NIFTI coordinate system discussed above.
01126    (i.e., DICOM +Xd is Left, +Yd is Posterior, +Zd is Superior,
01127         whereas +x is Right, +y is Anterior  , +z is Superior. )
01128    Thus, if the (0020,0032) DICOM attribute is extracted into (px,py,pz), then
01129      qoffset_x = -px   qoffset_y = -py   qoffset_z = pz
01130    is a reasonable setting when qform_code=NIFTI_XFORM_SCANNER_ANAT.
01131 
01132    That is, DICOM's coordinate system is 180 degrees rotated about the z-axis
01133    from the neuroscience/NIFTI coordinate system.  To transform between DICOM
01134    and NIFTI, you just have to negate the x- and y-coordinates.
01135 
01136    The DICOM attribute (0020,0037) "Image Orientation (Patient)" gives the
01137    orientation of the x- and y-axes of the image data in terms of 2 3-vectors.
01138    The first vector is a unit vector along the x-axis, and the second is
01139    along the y-axis.  If the (0020,0037) attribute is extracted into the
01140    value (xa,xb,xc,ya,yb,yc), then the first two columns of the R matrix
01141    would be
01142               [ -xa  -ya ]
01143               [ -xb  -yb ]
01144               [  xc   yc ]
01145    The negations are because DICOM's x- and y-axes are reversed relative
01146    to NIFTI's.  The third column of the R matrix gives the direction of
01147    displacement (relative to the subject) along the slice-wise direction.
01148    This orientation is not encoded in the DICOM standard in a simple way;
01149    DICOM is mostly concerned with 2D images.  The third column of R will be
01150    either the cross-product of the first 2 columns or its negative.  It is
01151    possible to infer the sign of the 3rd column by examining the coordinates
01152    in DICOM attribute (0020,0032) "Image Position (Patient)" for successive
01153    slices.  However, this method occasionally fails for reasons that I
01154    (RW Cox) do not understand.
01155 -----------------------------------------------------------------------------*/
01156 
01157    /* [qs]form_code value:  */      /* x,y,z coordinate system refers to:    */
01158    /*-----------------------*/      /*---------------------------------------*/
01159 
01166 #define NIFTI_XFORM_UNKNOWN      0
01167 
01170 #define NIFTI_XFORM_SCANNER_ANAT 1
01171 
01175 #define NIFTI_XFORM_ALIGNED_ANAT 2
01176 
01180 #define NIFTI_XFORM_TALAIRACH    3
01181 
01184 #define NIFTI_XFORM_MNI_152      4
01185 /* @} */
01186 
01187 /*---------------------------------------------------------------------------*/
01188 /* UNITS OF SPATIAL AND TEMPORAL DIMENSIONS:
01189    ----------------------------------------
01190    The codes below can be used in xyzt_units to indicate the units of pixdim.
01191    As noted earlier, dimensions 1,2,3 are for x,y,z; dimension 4 is for
01192    time (t).
01193     - If dim[4]=1 or dim[0] < 4, there is no time axis.
01194     - A single time series (no space) would be specified with
01195       - dim[0] = 4 (for scalar data) or dim[0] = 5 (for vector data)
01196       - dim[1] = dim[2] = dim[3] = 1
01197       - dim[4] = number of time points
01198       - pixdim[4] = time step
01199       - xyzt_units indicates units of pixdim[4]
01200       - dim[5] = number of values stored at each time point
01201 
01202    Bits 0..2 of xyzt_units specify the units of pixdim[1..3]
01203     (e.g., spatial units are values 1..7).
01204    Bits 3..5 of xyzt_units specify the units of pixdim[4]
01205     (e.g., temporal units are multiples of 8).
01206 
01207    This compression of 2 distinct concepts into 1 byte is due to the
01208    limited space available in the 348 byte ANALYZE 7.5 header.  The
01209    macros XYZT_TO_SPACE and XYZT_TO_TIME can be used to mask off the
01210    undesired bits from the xyzt_units fields, leaving "pure" space
01211    and time codes.  Inversely, the macro SPACE_TIME_TO_XYZT can be
01212    used to assemble a space code (0,1,2,...,7) with a time code
01213    (0,8,16,32,...,56) into the combined value for xyzt_units.
01214 
01215    Note that codes are provided to indicate the "time" axis units are
01216    actually frequency in Hertz (_HZ), in part-per-million (_PPM)
01217    or in radians-per-second (_RADS).
01218 
01219    The toffset field can be used to indicate a nonzero start point for
01220    the time axis.  That is, time point #m is at t=toffset+m*pixdim[4]
01221    for m=0..dim[4]-1.
01222 -----------------------------------------------------------------------------*/
01223 
01230 #define NIFTI_UNITS_UNKNOWN 0
01231 
01234 #define NIFTI_UNITS_METER   1
01235 
01236 #define NIFTI_UNITS_MM      2
01237 
01238 #define NIFTI_UNITS_MICRON  3
01239 
01242 #define NIFTI_UNITS_SEC     8
01243 
01244 #define NIFTI_UNITS_MSEC   16
01245 
01246 #define NIFTI_UNITS_USEC   24
01247 
01248                                /*** These units are for spectral data: ***/
01250 #define NIFTI_UNITS_HZ     32
01251 
01252 #define NIFTI_UNITS_PPM    40
01253 
01254 #define NIFTI_UNITS_RADS   48
01255 /* @} */
01256 
01257 #undef  XYZT_TO_SPACE
01258 #undef  XYZT_TO_TIME
01259 #define XYZT_TO_SPACE(xyzt)       ( (xyzt) & 0x07 )
01260 #define XYZT_TO_TIME(xyzt)        ( (xyzt) & 0x38 )
01261 
01262 #undef  SPACE_TIME_TO_XYZT
01263 #define SPACE_TIME_TO_XYZT(ss,tt) (  (((char)(ss)) & 0x07)   \
01264                                    | (((char)(tt)) & 0x38) )
01265 
01266 /*---------------------------------------------------------------------------*/
01267 /* MRI-SPECIFIC SPATIAL AND TEMPORAL INFORMATION:
01268    ---------------------------------------------
01269    A few fields are provided to store some extra information
01270    that is sometimes important when storing the image data
01271    from an FMRI time series experiment.  (After processing such
01272    data into statistical images, these fields are not likely
01273    to be useful.)
01274 
01275   { freq_dim  } = These fields encode which spatial dimension (1,2, or 3)
01276   { phase_dim } = corresponds to which acquisition dimension for MRI data.
01277   { slice_dim } =
01278     Examples:
01279       Rectangular scan multi-slice EPI:
01280         freq_dim = 1  phase_dim = 2  slice_dim = 3  (or some permutation)
01281       Spiral scan multi-slice EPI:
01282         freq_dim = phase_dim = 0  slice_dim = 3
01283         since the concepts of frequency- and phase-encoding directions
01284         don't apply to spiral scan
01285 
01286     slice_duration = If this is positive, AND if slice_dim is nonzero,
01287                      indicates the amount of time used to acquire 1 slice.
01288                      slice_duration*dim[slice_dim] can be less than pixdim[4]
01289                      with a clustered acquisition method, for example.
01290 
01291     slice_code = If this is nonzero, AND if slice_dim is nonzero, AND
01292                  if slice_duration is positive, indicates the timing
01293                  pattern of the slice acquisition.  The following codes
01294                  are defined:
01295                    NIFTI_SLICE_SEQ_INC  == sequential increasing
01296                    NIFTI_SLICE_SEQ_DEC  == sequential decreasing
01297                    NIFTI_SLICE_ALT_INC  == alternating increasing
01298                    NIFTI_SLICE_ALT_DEC  == alternating decreasing
01299                    NIFTI_SLICE_ALT_INC2 == alternating increasing #2
01300                    NIFTI_SLICE_ALT_DEC2 == alternating decreasing #2
01301   { slice_start } = Indicates the start and end of the slice acquisition
01302   { slice_end   } = pattern, when slice_code is nonzero.  These values
01303                     are present to allow for the possible addition of
01304                     "padded" slices at either end of the volume, which
01305                     don't fit into the slice timing pattern.  If there
01306                     are no padding slices, then slice_start=0 and
01307                     slice_end=dim[slice_dim]-1 are the correct values.
01308                     For these values to be meaningful, slice_start must
01309                     be non-negative and slice_end must be greater than
01310                     slice_start.  Otherwise, they should be ignored.
01311 
01312   The following table indicates the slice timing pattern, relative to
01313   time=0 for the first slice acquired, for some sample cases.  Here,
01314   dim[slice_dim]=7 (there are 7 slices, labeled 0..6), slice_duration=0.1,
01315   and slice_start=1, slice_end=5 (1 padded slice on each end).
01316 
01317   slice
01318   index  SEQ_INC SEQ_DEC ALT_INC ALT_DEC ALT_INC2 ALT_DEC2
01319     6  :   n/a     n/a     n/a     n/a    n/a      n/a    n/a = not applicable
01320     5  :   0.4     0.0     0.2     0.0    0.4      0.2    (slice time offset
01321     4  :   0.3     0.1     0.4     0.3    0.1      0.0     doesn't apply to
01322     3  :   0.2     0.2     0.1     0.1    0.3      0.3     slices outside
01323     2  :   0.1     0.3     0.3     0.4    0.0      0.1     the range
01324     1  :   0.0     0.4     0.0     0.2    0.2      0.4     slice_start ..
01325     0  :   n/a     n/a     n/a     n/a    n/a      n/a     slice_end)
01326 
01327   The SEQ slice_codes are sequential ordering (uncommon but not unknown),
01328   either increasing in slice number or decreasing (INC or DEC), as
01329   illustrated above.
01330 
01331   The ALT slice codes are alternating ordering.  The 'standard' way for
01332   these to operate (without the '2' on the end) is for the slice timing
01333   to start at the edge of the slice_start .. slice_end group (at slice_start
01334   for INC and at slice_end for DEC).  For the 'ALT_*2' slice_codes, the
01335   slice timing instead starts at the first slice in from the edge (at
01336   slice_start+1 for INC2 and at slice_end-1 for DEC2).  This latter
01337   acquisition scheme is found on some Siemens scanners.
01338 
01339   The fields freq_dim, phase_dim, slice_dim are all squished into the single
01340   byte field dim_info (2 bits each, since the values for each field are
01341   limited to the range 0..3).  This unpleasantness is due to lack of space
01342   in the 348 byte allowance.
01343 
01344   The macros DIM_INFO_TO_FREQ_DIM, DIM_INFO_TO_PHASE_DIM, and
01345   DIM_INFO_TO_SLICE_DIM can be used to extract these values from the
01346   dim_info byte.
01347 
01348   The macro FPS_INTO_DIM_INFO can be used to put these 3 values
01349   into the dim_info byte.
01350 -----------------------------------------------------------------------------*/
01351 
01352 #undef  DIM_INFO_TO_FREQ_DIM
01353 #undef  DIM_INFO_TO_PHASE_DIM
01354 #undef  DIM_INFO_TO_SLICE_DIM
01355 
01356 #define DIM_INFO_TO_FREQ_DIM(di)   ( ((di)     ) & 0x03 )
01357 #define DIM_INFO_TO_PHASE_DIM(di)  ( ((di) >> 2) & 0x03 )
01358 #define DIM_INFO_TO_SLICE_DIM(di)  ( ((di) >> 4) & 0x03 )
01359 
01360 #undef  FPS_INTO_DIM_INFO
01361 #define FPS_INTO_DIM_INFO(fd,pd,sd) ( ( ( ((char)(fd)) & 0x03)      ) |  \
01362                                       ( ( ((char)(pd)) & 0x03) << 2 ) |  \
01363                                       ( ( ((char)(sd)) & 0x03) << 4 )  )
01364 
01370 #define NIFTI_SLICE_UNKNOWN   0
01371 #define NIFTI_SLICE_SEQ_INC   1
01372 #define NIFTI_SLICE_SEQ_DEC   2
01373 #define NIFTI_SLICE_ALT_INC   3
01374 #define NIFTI_SLICE_ALT_DEC   4
01375 #define NIFTI_SLICE_ALT_INC2  5  /* 05 May 2005: RWCox */
01376 #define NIFTI_SLICE_ALT_DEC2  6  /* 05 May 2005: RWCox */
01377 /* @} */
01378 
01379 /*---------------------------------------------------------------------------*/
01380 /* UNUSED FIELDS:
01381    -------------
01382    Some of the ANALYZE 7.5 fields marked as ++UNUSED++ may need to be set
01383    to particular values for compatibility with other programs.  The issue
01384    of interoperability of ANALYZE 7.5 files is a murky one -- not all
01385    programs require exactly the same set of fields.  (Unobscuring this
01386    murkiness is a principal motivation behind NIFTI-1.)
01387 
01388    Some of the fields that may need to be set for other (non-NIFTI aware)
01389    software to be happy are:
01390 
01391      extents    dbh.h says this should be 16384
01392      regular    dbh.h says this should be the character 'r'
01393      glmin,   } dbh.h says these values should be the min and max voxel
01394       glmax   }  values for the entire dataset
01395 
01396    It is best to initialize ALL fields in the NIFTI-1 header to 0
01397    (e.g., with calloc()), then fill in what is needed.
01398 -----------------------------------------------------------------------------*/
01399 
01400 /*---------------------------------------------------------------------------*/
01401 /* MISCELLANEOUS C MACROS
01402 -----------------------------------------------------------------------------*/
01403 
01404 /*.................*/
01408 #define NIFTI_VERSION(h)                               \
01409  ( ( (h).magic[0]=='n' && (h).magic[3]=='\0'    &&     \
01410      ( (h).magic[1]=='i' || (h).magic[1]=='+' ) &&     \
01411      ( (h).magic[2]>='1' && (h).magic[2]<='9' )   )    \
01412  ? (h).magic[2]-'0' : 0 )
01413 
01414 /*.................*/
01419 #define NIFTI_ONEFILE(h) ( (h).magic[1] == '+' )
01420 
01421 /*.................*/
01425 #define NIFTI_NEEDS_SWAP(h) ( (h).dim[0] < 0 || (h).dim[0] > 7 )
01426 
01427 /*.................*/
01431 #define NIFTI_5TH_DIM(h) ( ((h).dim[0]>4 && (h).dim[5]>1) ? (h).dim[5] : 0 )
01432 
01433 /*****************************************************************************/
01434 
01435 /*=================*/
01436 #ifdef  __cplusplus
01437 }
01438 #endif
01439 /*=================*/
01440 
01441 #endif /* _NIFTI_HEADER_ */

Generated on Fri Sep 15 18:18:22 2006 for nifti1_io by  doxygen 1.4.7