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_ */