1 /** \file nifti1.h 2 \brief Official definition of the nifti1 header. Written by Bob Cox, SSCC, NIMH. 3 4 HISTORY: 5 6 29 Nov 2007 [rickr] 7 - added DT_RGBA32 and NIFTI_TYPE_RGBA32 8 - added NIFTI_INTENT codes: 9 TIME_SERIES, NODE_INDEX, RGB_VECTOR, RGBA_VECTOR, SHAPE 10 */ 11 12 #ifndef _MIRTK_NIFTI_HEADER_ 13 #define _MIRTK_NIFTI_HEADER_ 14 15 /***************************************************************************** 16 ** This file defines the "NIFTI-1" header format. ** 17 ** It is derived from 2 meetings at the NIH (31 Mar 2003 and ** 18 ** 02 Sep 2003) of the Data Format Working Group (DFWG), ** 19 ** chartered by the NIfTI (Neuroimaging Informatics Technology ** 20 ** Initiative) at the National Institutes of Health (NIH). ** 21 **--------------------------------------------------------------** 22 ** Neither the National Institutes of Health (NIH), the DFWG, ** 23 ** nor any of the members or employees of these institutions ** 24 ** imply any warranty of usefulness of this material for any ** 25 ** purpose, and do not assume any liability for damages, ** 26 ** incidental or otherwise, caused by any use of this document. ** 27 ** If these conditions are not acceptable, do not use this! ** 28 **--------------------------------------------------------------** 29 ** Author: Robert W Cox (NIMH, Bethesda) ** 30 ** Advisors: John Ashburner (FIL, London), ** 31 ** Stephen Smith (FMRIB, Oxford), ** 32 ** Mark Jenkinson (FMRIB, Oxford) ** 33 ******************************************************************************/ 34 35 /*---------------------------------------------------------------------------*/ 36 /* Note that the ANALYZE 7.5 file header (dbh.h) is 37 (c) Copyright 1986-1995 38 Biomedical Imaging Resource 39 Mayo Foundation 40 Incorporation of components of dbh.h are by permission of the 41 Mayo Foundation. 42 43 Changes from the ANALYZE 7.5 file header in this file are released to the 44 public domain, including the functional comments and any amusing asides. 45 -----------------------------------------------------------------------------*/ 46 47 /*---------------------------------------------------------------------------*/ 48 /*! INTRODUCTION TO NIFTI-1: 49 ------------------------ 50 The twin (and somewhat conflicting) goals of this modified ANALYZE 7.5 51 format are: 52 (a) To add information to the header that will be useful for functional 53 neuroimaging data analysis and display. These additions include: 54 - More basic data types. 55 - Two affine transformations to specify voxel coordinates. 56 - "Intent" codes and parameters to describe the meaning of the data. 57 - Affine scaling of the stored data values to their "true" values. 58 - Optional storage of the header and image data in one file (.nii). 59 (b) To maintain compatibility with non-NIFTI-aware ANALYZE 7.5 compatible 60 software (i.e., such a program should be able to do something useful 61 with a NIFTI-1 dataset -- at least, with one stored in a traditional 62 .img/.hdr file pair). 63 64 Most of the unused fields in the ANALYZE 7.5 header have been taken, 65 and some of the lesser-used fields have been co-opted for other purposes. 66 Notably, most of the data_history substructure has been co-opted for 67 other purposes, since the ANALYZE 7.5 format describes this substructure 68 as "not required". 69 70 NIFTI-1 FLAG (MAGIC STRINGS): 71 ---------------------------- 72 To flag such a struct as being conformant to the NIFTI-1 spec, the last 4 73 bytes of the header must be either the C String "ni1" or "n+1"; 74 in hexadecimal, the 4 bytes 75 6E 69 31 00 or 6E 2B 31 00 76 (in any future version of this format, the '1' will be upgraded to '2', 77 etc.). Normally, such a "magic number" or flag goes at the start of the 78 file, but trying to avoid clobbering widely-used ANALYZE 7.5 fields led to 79 putting this marker last. However, recall that "the last shall be first" 80 (Matthew 20:16). 81 82 If a NIFTI-aware program reads a header file that is NOT marked with a 83 NIFTI magic string, then it should treat the header as an ANALYZE 7.5 84 structure. 85 86 NIFTI-1 FILE STORAGE: 87 -------------------- 88 "ni1" means that the image data is stored in the ".img" file corresponding 89 to the header file (starting at file offset 0). 90 91 "n+1" means that the image data is stored in the same file as the header 92 information. We recommend that the combined header+data filename suffix 93 be ".nii". When the dataset is stored in one file, the first byte of image 94 data is stored at byte location (int)vox_offset in this combined file. 95 The minimum allowed value of vox_offset is 352; for compatibility with 96 some software, vox_offset should be an integral multiple of 16. 97 98 GRACE UNDER FIRE: 99 ---------------- 100 Most NIFTI-aware programs will only be able to handle a subset of the full 101 range of datasets possible with this format. All NIFTI-aware programs 102 should take care to check if an input dataset conforms to the program's 103 needs and expectations (e.g., check datatype, intent_code, etc.). If the 104 input dataset can't be handled by the program, the program should fail 105 gracefully (e.g., print a useful warning; not crash). 106 107 SAMPLE CODES: 108 ------------ 109 The associated files nifti1_io.h and nifti1_io.c provide a sample 110 implementation in C of a set of functions to read, write, and manipulate 111 NIFTI-1 files. The file nifti1_test.c is a sample program that uses 112 the nifti1_io.c functions. 113 -----------------------------------------------------------------------------*/ 114 115 /*---------------------------------------------------------------------------*/ 116 /* HEADER STRUCT DECLARATION: 117 ------------------------- 118 In the comments below for each field, only NIFTI-1 specific requirements 119 or changes from the ANALYZE 7.5 format are described. For convenience, 120 the 348 byte header is described as a single struct, rather than as the 121 ANALYZE 7.5 group of 3 substructs. 122 123 Further comments about the interpretation of various elements of this 124 header are after the data type definition itself. Fields that are 125 marked as ++UNUSED++ have no particular interpretation in this standard. 126 (Also see the UNUSED FIELDS comment section, far below.) 127 128 The presumption below is that the various C types have particular sizes: 129 sizeof(int) = sizeof(float) = 4 ; sizeof(short) = 2 130 -----------------------------------------------------------------------------*/ 131 132 namespace mirtk { 133 134 135 /*! \struct nifti_1_header 136 \brief Data structure defining the fields in the nifti1 header. 137 This binary header should be found at the beginning of a valid 138 NIFTI-1 header file. 139 */ 140 /*************************/ /************************/ 141 struct nifti_1_header { /* NIFTI-1 usage */ /* ANALYZE 7.5 field(s) */ 142 /*************************/ /************************/ 143 144 /*--- was header_key substruct ---*/ 145 int sizeof_hdr; /*!< MUST be 348 */ /* int sizeof_hdr; */ 146 char data_type[10]; /*!< ++UNUSED++ */ /* char data_type[10]; */ 147 char db_name[18]; /*!< ++UNUSED++ */ /* char db_name[18]; */ 148 int extents; /*!< ++UNUSED++ */ /* int extents; */ 149 short session_error; /*!< ++UNUSED++ */ /* short session_error; */ 150 char regular; /*!< ++UNUSED++ */ /* char regular; */ 151 char dim_info; /*!< MRI slice ordering. */ /* char hkey_un0; */ 152 153 /*--- was image_dimension substruct ---*/ 154 short dim[8]; /*!< Data array dimensions.*/ /* short dim[8]; */ 155 float intent_p1 ; /*!< 1st intent parameter. */ /* short unused8; */ 156 /* short unused9; */ 157 float intent_p2 ; /*!< 2nd intent parameter. */ /* short unused10; */ 158 /* short unused11; */ 159 float intent_p3 ; /*!< 3rd intent parameter. */ /* short unused12; */ 160 /* short unused13; */ 161 short intent_code ; /*!< NIFTI_INTENT_* code. */ /* short unused14; */ 162 short datatype; /*!< Defines data type! */ /* short datatype; */ 163 short bitpix; /*!< Number bits/voxel. */ /* short bitpix; */ 164 short slice_start; /*!< First slice index. */ /* short dim_un0; */ 165 float pixdim[8]; /*!< Grid spacings. */ /* float pixdim[8]; */ 166 float vox_offset; /*!< Offset into .nii file */ /* float vox_offset; */ 167 float scl_slope ; /*!< Data scaling: slope. */ /* float funused1; */ 168 float scl_inter ; /*!< Data scaling: offset. */ /* float funused2; */ 169 short slice_end; /*!< Last slice index. */ /* float funused3; */ 170 char slice_code ; /*!< Slice timing order. */ 171 char xyzt_units ; /*!< Units of pixdim[1..4] */ 172 float cal_max; /*!< Max display intensity */ /* float cal_max; */ 173 float cal_min; /*!< Min display intensity */ /* float cal_min; */ 174 float slice_duration;/*!< Time for 1 slice. */ /* float compressed; */ 175 float toffset; /*!< Time axis shift. */ /* float verified; */ 176 int glmax; /*!< ++UNUSED++ */ /* int glmax; */ 177 int glmin; /*!< ++UNUSED++ */ /* int glmin; */ 178 179 /*--- was data_history substruct ---*/ 180 char descrip[80]; /*!< any text you like. */ /* char descrip[80]; */ 181 char aux_file[24]; /*!< auxiliary filename. */ /* char aux_file[24]; */ 182 183 short qform_code ; /*!< NIFTI_XFORM_* code. */ /*-- all ANALYZE 7.5 ---*/ 184 short sform_code ; /*!< NIFTI_XFORM_* code. */ /* fields below here */ 185 /* are replaced */ 186 float quatern_b ; /*!< Quaternion b param. */ 187 float quatern_c ; /*!< Quaternion c param. */ 188 float quatern_d ; /*!< Quaternion d param. */ 189 float qoffset_x ; /*!< Quaternion x shift. */ 190 float qoffset_y ; /*!< Quaternion y shift. */ 191 float qoffset_z ; /*!< Quaternion z shift. */ 192 193 float srow_x[4] ; /*!< 1st row affine transform. */ 194 float srow_y[4] ; /*!< 2nd row affine transform. */ 195 float srow_z[4] ; /*!< 3rd row affine transform. */ 196 197 char intent_name[16];/*!< 'name' or meaning of data. */ 198 199 char magic[4] ; /*!< MUST be "ni1\0" or "n+1\0". */ 200 201 } ; /**** 348 bytes total ****/ 202 203 typedef struct nifti_1_header nifti_1_header ; 204 205 /*---------------------------------------------------------------------------*/ 206 /* HEADER EXTENSIONS: 207 ----------------- 208 After the end of the 348 byte header (e.g., after the magic field), 209 the next 4 bytes are a char array field named "extension". By default, 210 all 4 bytes of this array should be set to zero. In a .nii file, these 211 4 bytes will always be present, since the earliest start point for 212 the image data is byte #352. In a separate .hdr file, these bytes may 213 or may not be present. If not present (i.e., if the length of the .hdr 214 file is 348 bytes), then a NIfTI-1 compliant program should use the 215 default value of extension={0,0,0,0}. The first byte (extension[0]) 216 is the only value of this array that is specified at present. The other 217 3 bytes are reserved for future use. 218 219 If extension[0] is nonzero, it indicates that extended header information 220 is present in the bytes following the extension array. In a .nii file, 221 this extended header data is before the image data (and vox_offset 222 must be set correctly to allow for this). In a .hdr file, this extended 223 data follows extension and proceeds (potentially) to the end of the file. 224 225 The format of extended header data is weakly specified. Each extension 226 must be an integer multiple of 16 bytes long. The first 8 bytes of each 227 extension comprise 2 integers: 228 int esize , ecode ; 229 These values may need to be byte-swapped, as indicated by dim[0] for 230 the rest of the header. 231 * esize is the number of bytes that form the extended header data 232 + esize must be a positive integral multiple of 16 233 + this length includes the 8 bytes of esize and ecode themselves 234 * ecode is a non-negative integer that indicates the format of the 235 extended header data that follows 236 + different ecode values are assigned to different developer groups 237 + at present, the "registered" values for code are 238 = 0 = unknown private format (not recommended!) 239 = 2 = DICOM format (i.e., attribute tags and values) 240 = 4 = AFNI group (i.e., ASCII XML-ish elements) 241 In the interests of interoperability (a primary rationale for NIfTI), 242 groups developing software that uses this extension mechanism are 243 encouraged to document and publicize the format of their extensions. 244 To this end, the NIfTI DFWG will assign even numbered codes upon request 245 to groups submitting at least rudimentary documentation for the format 246 of their extension; at present, the contact is mailto:rwcox@nih.gov. 247 The assigned codes and documentation will be posted on the NIfTI 248 website. All odd values of ecode (and 0) will remain unassigned; 249 at least, until the even ones are used up, when we get to 2,147,483,646. 250 251 Note that the other contents of the extended header data section are 252 totally unspecified by the NIfTI-1 standard. In particular, if binary 253 data is stored in such a section, its byte order is not necessarily 254 the same as that given by examining dim[0]; it is incumbent on the 255 programs dealing with such data to determine the byte order of binary 256 extended header data. 257 258 Multiple extended header sections are allowed, each starting with an 259 esize,ecode value pair. The first esize value, as described above, 260 is at bytes #352-355 in the .hdr or .nii file (files start at byte #0). 261 If this value is positive, then the second (esize2) will be found 262 starting at byte #352+esize1 , the third (esize3) at byte #352+esize1+esize2, 263 et cetera. Of course, in a .nii file, the value of vox_offset must 264 be compatible with these extensions. If a malformed file indicates 265 that an extended header data section would run past vox_offset, then 266 the entire extended header section should be ignored. In a .hdr file, 267 if an extended header data section would run past the end-of-file, 268 that extended header data should also be ignored. 269 270 With the above scheme, a program can successively examine the esize 271 and ecode values, and skip over each extended header section if the 272 program doesn't know how to interpret the data within. Of course, any 273 program can simply ignore all extended header sections simply by jumping 274 straight to the image data using vox_offset. 275 -----------------------------------------------------------------------------*/ 276 277 /*! \struct nifti1_extender 278 \brief This structure represents a 4-byte string that should follow the 279 binary nifti_1_header data in a NIFTI-1 header file. If the char 280 values are {1,0,0,0}, the file is expected to contain extensions, 281 values of {0,0,0,0} imply the file does not contain extensions. 282 Other sequences of values are not currently defined. 283 */ 284 struct nifti1_extender { char extension[4] ; } ; 285 typedef struct nifti1_extender nifti1_extender ; 286 287 /*! \struct nifti1_extension 288 \brief Data structure defining the fields of a header extension. 289 */ 290 struct nifti1_extension { 291 int esize ; /*!< size of extension, in bytes (must be multiple of 16) */ 292 int ecode ; /*!< extension code, one of the NIFTI_ECODE_ values */ 293 char * edata ; /*!< raw data, with no byte swapping (length is esize-8) */ 294 } ; 295 typedef struct nifti1_extension nifti1_extension ; 296 297 /*---------------------------------------------------------------------------*/ 298 /* DATA DIMENSIONALITY (as in ANALYZE 7.5): 299 --------------------------------------- 300 dim[0] = number of dimensions; 301 - if dim[0] is outside range 1..7, then the header information 302 needs to be byte swapped appropriately 303 - ANALYZE supports dim[0] up to 7, but NIFTI-1 reserves 304 dimensions 1,2,3 for space (x,y,z), 4 for time (t), and 305 5,6,7 for anything else needed. 306 307 dim[i] = length of dimension #i, for i=1..dim[0] (must be positive) 308 - also see the discussion of intent_code, far below 309 310 pixdim[i] = voxel width along dimension #i, i=1..dim[0] (positive) 311 - cf. ORIENTATION section below for use of pixdim[0] 312 - the units of pixdim can be specified with the xyzt_units 313 field (also described far below). 314 315 Number of bits per voxel value is in bitpix, which MUST correspond with 316 the datatype field. The total number of bytes in the image data is 317 dim[1] * ... * dim[dim[0]] * bitpix / 8 318 319 In NIFTI-1 files, dimensions 1,2,3 are for space, dimension 4 is for time, 320 and dimension 5 is for storing multiple values at each spatiotemporal 321 voxel. Some examples: 322 - A typical whole-brain FMRI experiment's time series: 323 - dim[0] = 4 324 - dim[1] = 64 pixdim[1] = 3.75 xyzt_units = NIFTI_UNITS_MM 325 - dim[2] = 64 pixdim[2] = 3.75 | NIFTI_UNITS_SEC 326 - dim[3] = 20 pixdim[3] = 5.0 327 - dim[4] = 120 pixdim[4] = 2.0 328 - A typical T1-weighted anatomical volume: 329 - dim[0] = 3 330 - dim[1] = 256 pixdim[1] = 1.0 xyzt_units = NIFTI_UNITS_MM 331 - dim[2] = 256 pixdim[2] = 1.0 332 - dim[3] = 128 pixdim[3] = 1.1 333 - A single slice EPI time series: 334 - dim[0] = 4 335 - dim[1] = 64 pixdim[1] = 3.75 xyzt_units = NIFTI_UNITS_MM 336 - dim[2] = 64 pixdim[2] = 3.75 | NIFTI_UNITS_SEC 337 - dim[3] = 1 pixdim[3] = 5.0 338 - dim[4] = 1200 pixdim[4] = 0.2 339 - A 3-vector stored at each point in a 3D volume: 340 - dim[0] = 5 341 - dim[1] = 256 pixdim[1] = 1.0 xyzt_units = NIFTI_UNITS_MM 342 - dim[2] = 256 pixdim[2] = 1.0 343 - dim[3] = 128 pixdim[3] = 1.1 344 - dim[4] = 1 pixdim[4] = 0.0 345 - dim[5] = 3 intent_code = NIFTI_INTENT_VECTOR 346 - A single time series with a 3x3 matrix at each point: 347 - dim[0] = 5 348 - dim[1] = 1 xyzt_units = NIFTI_UNITS_SEC 349 - dim[2] = 1 350 - dim[3] = 1 351 - dim[4] = 1200 pixdim[4] = 0.2 352 - dim[5] = 9 intent_code = NIFTI_INTENT_GENMATRIX 353 - intent_p1 = intent_p2 = 3.0 (indicates matrix dimensions) 354 -----------------------------------------------------------------------------*/ 355 356 /*---------------------------------------------------------------------------*/ 357 /* DATA STORAGE: 358 ------------ 359 If the magic field is "n+1", then the voxel data is stored in the 360 same file as the header. In this case, the voxel data starts at offset 361 (int)vox_offset into the header file. Thus, vox_offset=352.0 means that 362 the data starts immediately after the NIFTI-1 header. If vox_offset is 363 greater than 352, the NIFTI-1 format does not say much about the 364 contents of the dataset file between the end of the header and the 365 start of the data. 366 367 FILES: 368 ----- 369 If the magic field is "ni1", then the voxel data is stored in the 370 associated ".img" file, starting at offset 0 (i.e., vox_offset is not 371 used in this case, and should be set to 0.0). 372 373 When storing NIFTI-1 datasets in pairs of files, it is customary to name 374 the files in the pattern "name.hdr" and "name.img", as in ANALYZE 7.5. 375 When storing in a single file ("n+1"), the file name should be in 376 the form "name.nii" (the ".nft" and ".nif" suffixes are already taken; 377 cf. http://www.icdatamaster.com/n.html ). 378 379 BYTE ORDERING: 380 ------------- 381 The byte order of the data arrays is presumed to be the same as the byte 382 order of the header (which is determined by examining dim[0]). 383 384 Floating point types are presumed to be stored in IEEE-754 format. 385 -----------------------------------------------------------------------------*/ 386 387 /*---------------------------------------------------------------------------*/ 388 /* DETAILS ABOUT vox_offset: 389 ------------------------ 390 In a .nii file, the vox_offset field value is interpreted as the start 391 location of the image data bytes in that file. In a .hdr/.img file pair, 392 the vox_offset field value is the start location of the image data 393 bytes in the .img file. 394 * If vox_offset is less than 352 in a .nii file, it is equivalent 395 to 352 (i.e., image data never starts before byte #352 in a .nii file). 396 * The default value for vox_offset in a .nii file is 352. 397 * In a .hdr file, the default value for vox_offset is 0. 398 * vox_offset should be an integer multiple of 16; otherwise, some 399 programs may not work properly (e.g., SPM). This is to allow 400 memory-mapped input to be properly byte-aligned. 401 Note that since vox_offset is an IEEE-754 32 bit float (for compatibility 402 with the ANALYZE-7.5 format), it effectively has a 24 bit mantissa. All 403 integers from 0 to 2^24 can be represented exactly in this format, but not 404 all larger integers are exactly storable as IEEE-754 32 bit floats. However, 405 unless you plan to have vox_offset be potentially larger than 16 MB, this 406 should not be an issue. (Actually, any integral multiple of 16 up to 2^27 407 can be represented exactly in this format, which allows for up to 128 MB 408 of random information before the image data. If that isn't enough, then 409 perhaps this format isn't right for you.) 410 411 In a .img file (i.e., image data stored separately from the NIfTI-1 412 header), data bytes between #0 and #vox_offset-1 (inclusive) are completely 413 undefined and unregulated by the NIfTI-1 standard. One potential use of 414 having vox_offset > 0 in the .hdr/.img file pair storage method is to make 415 the .img file be a copy of (or link to) a pre-existing image file in some 416 other format, such as DICOM; then vox_offset would be set to the offset of 417 the image data in this file. (It may not be possible to follow the 418 "multiple-of-16 rule" with an arbitrary external file; using the NIfTI-1 419 format in such a case may lead to a file that is incompatible with software 420 that relies on vox_offset being a multiple of 16.) 421 422 In a .nii file, data bytes between #348 and #vox_offset-1 (inclusive) may 423 be used to store user-defined extra information; similarly, in a .hdr file, 424 any data bytes after byte #347 are available for user-defined extra 425 information. The (very weak) regulation of this extra header data is 426 described elsewhere. 427 -----------------------------------------------------------------------------*/ 428 429 /*---------------------------------------------------------------------------*/ 430 /* DATA SCALING: 431 ------------ 432 If the scl_slope field is nonzero, then each voxel value in the dataset 433 should be scaled as 434 y = scl_slope * x + scl_inter 435 where x = voxel value stored 436 y = "true" voxel value 437 Normally, we would expect this scaling to be used to store "true" floating 438 values in a smaller integer datatype, but that is not required. That is, 439 it is legal to use scaling even if the datatype is a float type (crazy, 440 perhaps, but legal). 441 - However, the scaling is to be ignored if datatype is DT_RGB24. 442 - If datatype is a complex type, then the scaling is to be 443 applied to both the real and imaginary parts. 444 445 The cal_min and cal_max fields (if nonzero) are used for mapping (possibly 446 scaled) dataset values to display colors: 447 - Minimum display intensity (black) corresponds to dataset value cal_min. 448 - Maximum display intensity (white) corresponds to dataset value cal_max. 449 - Dataset values below cal_min should display as black also, and values 450 above cal_max as white. 451 - Colors "black" and "white", of course, may refer to any scalar display 452 scheme (e.g., a color lookup table specified via aux_file). 453 - cal_min and cal_max only make sense when applied to scalar-valued 454 datasets (i.e., dim[0] < 5 or dim[5] = 1). 455 -----------------------------------------------------------------------------*/ 456 457 /*---------------------------------------------------------------------------*/ 458 /* TYPE OF DATA (acceptable values for datatype field): 459 --------------------------------------------------- 460 Values of datatype smaller than 256 are ANALYZE 7.5 compatible. 461 Larger values are NIFTI-1 additions. These are all multiples of 256, so 462 that no bits below position 8 are set in datatype. But there is no need 463 to use only powers-of-2, as the original ANALYZE 7.5 datatype codes do. 464 465 The additional codes are intended to include a complete list of basic 466 scalar types, including signed and unsigned integers from 8 to 64 bits, 467 floats from 32 to 128 bits, and complex (float pairs) from 64 to 256 bits. 468 469 Note that most programs will support only a few of these datatypes! 470 A NIFTI-1 program should fail gracefully (e.g., print a warning message) 471 when it encounters a dataset with a type it doesn't like. 472 -----------------------------------------------------------------------------*/ 473 474 #undef DT_UNKNOWN /* defined in dirent.h on some Unix systems */ 475 476 /*! \defgroup NIFTI1_DATATYPES 477 \brief nifti1 datatype codes 478 @{ 479 */ 480 /*--- the original ANALYZE 7.5 type codes ---*/ 481 #define DT_NONE 0 482 #define DT_UNKNOWN 0 /* what it says, dude */ 483 #define DT_BINARY 1 /* binary (1 bit/voxel) */ 484 #define DT_UNSIGNED_CHAR 2 /* unsigned char (8 bits/voxel) */ 485 #define DT_SIGNED_SHORT 4 /* signed short (16 bits/voxel) */ 486 #define DT_SIGNED_INT 8 /* signed int (32 bits/voxel) */ 487 #define DT_FLOAT 16 /* float (32 bits/voxel) */ 488 #define DT_COMPLEX 32 /* complex (64 bits/voxel) */ 489 #define DT_DOUBLE 64 /* double (64 bits/voxel) */ 490 #define DT_RGB 128 /* RGB triple (24 bits/voxel) */ 491 #define DT_ALL 255 /* not very useful (?) */ 492 493 /*----- another set of names for the same ---*/ 494 #define DT_UINT8 2 495 #define DT_INT16 4 496 #define DT_INT32 8 497 #define DT_FLOAT32 16 498 #define DT_COMPLEX64 32 499 #define DT_FLOAT64 64 500 #define DT_RGB24 128 501 502 /*------------------- new codes for NIFTI ---*/ 503 #define DT_INT8 256 /* signed char (8 bits) */ 504 #define DT_UINT16 512 /* unsigned short (16 bits) */ 505 #define DT_UINT32 768 /* unsigned int (32 bits) */ 506 #define DT_INT64 1024 /* long long (64 bits) */ 507 #define DT_UINT64 1280 /* unsigned long long (64 bits) */ 508 #define DT_FLOAT128 1536 /* long double (128 bits) */ 509 #define DT_COMPLEX128 1792 /* double pair (128 bits) */ 510 #define DT_COMPLEX256 2048 /* long double pair (256 bits) */ 511 #define DT_RGBA32 2304 /* 4 byte RGBA (32 bits/voxel) */ 512 /* @} */ 513 514 515 /*------- aliases for all the above codes ---*/ 516 517 /*! \defgroup NIFTI1_DATATYPE_ALIASES 518 \brief aliases for the nifti1 datatype codes 519 @{ 520 */ 521 #ifndef NO_NIFTI_TYPE_DEFINES 522 523 /*! unsigned char. */ 524 #define NIFTI_TYPE_UINT8 2 525 /*! signed short. */ 526 #define NIFTI_TYPE_INT16 4 527 /*! signed int. */ 528 #define NIFTI_TYPE_INT32 8 529 /*! 32 bit float. */ 530 #define NIFTI_TYPE_FLOAT32 16 531 /*! 64 bit complex = 2 32 bit floats. */ 532 #define NIFTI_TYPE_COMPLEX64 32 533 /*! 64 bit float = double. */ 534 #define NIFTI_TYPE_FLOAT64 64 535 /*! 3 8 bit bytes. */ 536 #define NIFTI_TYPE_RGB24 128 537 /*! signed char. */ 538 #define NIFTI_TYPE_INT8 256 539 /*! unsigned short. */ 540 #define NIFTI_TYPE_UINT16 512 541 /*! unsigned int. */ 542 #define NIFTI_TYPE_UINT32 768 543 /*! signed long long. */ 544 #define NIFTI_TYPE_INT64 1024 545 /*! unsigned long long. */ 546 #define NIFTI_TYPE_UINT64 1280 547 /*! 128 bit float = long double. */ 548 #define NIFTI_TYPE_FLOAT128 1536 549 /*! 128 bit complex = 2 64 bit floats. */ 550 #define NIFTI_TYPE_COMPLEX128 1792 551 /*! 256 bit complex = 2 128 bit floats */ 552 #define NIFTI_TYPE_COMPLEX256 2048 553 /*! 4 8 bit bytes. */ 554 #define NIFTI_TYPE_RGBA32 2304 555 556 #endif // NO_NIFTI_TYPE_DEFINES 557 /* @} */ 558 559 /*-------- sample typedefs for complicated types ---*/ 560 #if 0 561 typedef struct { float r,i; } complex_float ; 562 typedef struct { double r,i; } complex_double ; 563 typedef struct { long double r,i; } complex_longdouble ; 564 typedef struct { unsigned char r,g,b; } rgb_byte ; 565 #endif 566 567 /*---------------------------------------------------------------------------*/ 568 /* INTERPRETATION OF VOXEL DATA: 569 ---------------------------- 570 The intent_code field can be used to indicate that the voxel data has 571 some particular meaning. In particular, a large number of codes is 572 given to indicate that the the voxel data should be interpreted as 573 being drawn from a given probability distribution. 574 575 VECTOR-VALUED DATASETS: 576 ---------------------- 577 The 5th dimension of the dataset, if present (i.e., dim[0]=5 and 578 dim[5] > 1), contains multiple values (e.g., a vector) to be stored 579 at each spatiotemporal location. For example, the header values 580 - dim[0] = 5 581 - dim[1] = 64 582 - dim[2] = 64 583 - dim[3] = 20 584 - dim[4] = 1 (indicates no time axis) 585 - dim[5] = 3 586 - datatype = DT_FLOAT 587 - intent_code = NIFTI_INTENT_VECTOR 588 mean that this dataset should be interpreted as a 3D volume (64x64x20), 589 with a 3-vector of floats defined at each point in the 3D grid. 590 591 A program reading a dataset with a 5th dimension may want to reformat 592 the image data to store each voxels' set of values together in a struct 593 or array. This programming detail, however, is beyond the scope of the 594 NIFTI-1 file specification! Uses of dimensions 6 and 7 are also not 595 specified here. 596 597 STATISTICAL PARAMETRIC DATASETS (i.e., SPMs): 598 -------------------------------------------- 599 Values of intent_code from NIFTI_FIRST_STATCODE to NIFTI_LAST_STATCODE 600 (inclusive) indicate that the numbers in the dataset should be interpreted 601 as being drawn from a given distribution. Most such distributions have 602 auxiliary parameters (e.g., NIFTI_INTENT_TTEST has 1 DOF parameter). 603 604 If the dataset DOES NOT have a 5th dimension, then the auxiliary parameters 605 are the same for each voxel, and are given in header fields intent_p1, 606 intent_p2, and intent_p3. 607 608 If the dataset DOES have a 5th dimension, then the auxiliary parameters 609 are different for each voxel. For example, the header values 610 - dim[0] = 5 611 - dim[1] = 128 612 - dim[2] = 128 613 - dim[3] = 1 (indicates a single slice) 614 - dim[4] = 1 (indicates no time axis) 615 - dim[5] = 2 616 - datatype = DT_FLOAT 617 - intent_code = NIFTI_INTENT_TTEST 618 mean that this is a 2D dataset (128x128) of t-statistics, with the 619 t-statistic being in the first "plane" of data and the degrees-of-freedom 620 parameter being in the second "plane" of data. 621 622 If the dataset 5th dimension is used to store the voxel-wise statistical 623 parameters, then dim[5] must be 1 plus the number of parameters required 624 by that distribution (e.g., intent_code=NIFTI_INTENT_TTEST implies dim[5] 625 must be 2, as in the example just above). 626 627 Note: intent_code values 2..10 are compatible with AFNI 1.5x (which is 628 why there is no code with value=1, which is obsolescent in AFNI). 629 630 OTHER INTENTIONS: 631 ---------------- 632 The purpose of the intent_* fields is to help interpret the values 633 stored in the dataset. Some non-statistical values for intent_code 634 and conventions are provided for storing other complex data types. 635 636 The intent_name field provides space for a 15 character (plus 0 byte) 637 'name' string for the type of data stored. Examples: 638 - intent_code = NIFTI_INTENT_ESTIMATE; intent_name = "T1"; 639 could be used to signify that the voxel values are estimates of the 640 NMR parameter T1. 641 - intent_code = NIFTI_INTENT_TTEST; intent_name = "House"; 642 could be used to signify that the voxel values are t-statistics 643 for the significance of 'activation' response to a House stimulus. 644 - intent_code = NIFTI_INTENT_DISPVECT; intent_name = "ToMNI152"; 645 could be used to signify that the voxel values are a displacement 646 vector that transforms each voxel (x,y,z) location to the 647 corresponding location in the MNI152 standard brain. 648 - intent_code = NIFTI_INTENT_SYMMATRIX; intent_name = "DTI"; 649 could be used to signify that the voxel values comprise a diffusion 650 tensor image. 651 652 If no data name is implied or needed, intent_name[0] should be set to 0. 653 -----------------------------------------------------------------------------*/ 654 #ifndef NO_NIFTI_INTENT_DEFINES 655 656 /*! default: no intention is indicated in the header. */ 657 658 #define NIFTI_INTENT_NONE 0 659 660 /*-------- These codes are for probability distributions ---------------*/ 661 /* Most distributions have a number of parameters, 662 below denoted by p1, p2, and p3, and stored in 663 - intent_p1, intent_p2, intent_p3 if dataset doesn't have 5th dimension 664 - image data array if dataset does have 5th dimension 665 666 Functions to compute with many of the distributions below can be found 667 in the CDF library from U Texas. 668 669 Formulas for and discussions of these distributions can be found in the 670 following books: 671 672 [U] Univariate Discrete Distributions, 673 NL Johnson, S Kotz, AW Kemp. 674 675 [C1] Continuous Univariate Distributions, vol. 1, 676 NL Johnson, S Kotz, N Balakrishnan. 677 678 [C2] Continuous Univariate Distributions, vol. 2, 679 NL Johnson, S Kotz, N Balakrishnan. */ 680 /*----------------------------------------------------------------------*/ 681 682 /*! [C2, chap 32] Correlation coefficient R (1 param): 683 p1 = degrees of freedom 684 R/sqrt(1-R*R) is t-distributed with p1 DOF. */ 685 686 /*! \defgroup NIFTI1_INTENT_CODES 687 \brief nifti1 intent codes, to describe intended meaning of dataset contents 688 @{ 689 */ 690 #define NIFTI_INTENT_CORREL 2 691 692 /*! [C2, chap 28] Student t statistic (1 param): p1 = DOF. */ 693 694 #define NIFTI_INTENT_TTEST 3 695 696 /*! [C2, chap 27] Fisher F statistic (2 params): 697 p1 = numerator DOF, p2 = denominator DOF. */ 698 699 #define NIFTI_INTENT_FTEST 4 700 701 /*! [C1, chap 13] Standard normal (0 params): Density = N(0,1). */ 702 703 #define NIFTI_INTENT_ZSCORE 5 704 705 /*! [C1, chap 18] Chi-squared (1 param): p1 = DOF. 706 Density(x) proportional to exp(-x/2) * x^(p1/2-1). */ 707 708 #define NIFTI_INTENT_CHISQ 6 709 710 /*! [C2, chap 25] Beta distribution (2 params): p1=a, p2=b. 711 Density(x) proportional to x^(a-1) * (1-x)^(b-1). */ 712 713 #define NIFTI_INTENT_BETA 7 714 715 /*! [U, chap 3] Binomial distribution (2 params): 716 p1 = number of trials, p2 = probability per trial. 717 Prob(x) = (p1 choose x) * p2^x * (1-p2)^(p1-x), for x=0,1,...,p1. */ 718 719 #define NIFTI_INTENT_BINOM 8 720 721 /*! [C1, chap 17] Gamma distribution (2 params): 722 p1 = shape, p2 = scale. 723 Density(x) proportional to x^(p1-1) * exp(-p2*x). */ 724 725 #define NIFTI_INTENT_GAMMA 9 726 727 /*! [U, chap 4] Poisson distribution (1 param): p1 = mean. 728 Prob(x) = exp(-p1) * p1^x / x! , for x=0,1,2,.... */ 729 730 #define NIFTI_INTENT_POISSON 10 731 732 /*! [C1, chap 13] Normal distribution (2 params): 733 p1 = mean, p2 = standard deviation. */ 734 735 #define NIFTI_INTENT_NORMAL 11 736 737 /*! [C2, chap 30] Noncentral F statistic (3 params): 738 p1 = numerator DOF, p2 = denominator DOF, 739 p3 = numerator noncentrality parameter. */ 740 741 #define NIFTI_INTENT_FTEST_NONC 12 742 743 /*! [C2, chap 29] Noncentral chi-squared statistic (2 params): 744 p1 = DOF, p2 = noncentrality parameter. */ 745 746 #define NIFTI_INTENT_CHISQ_NONC 13 747 748 /*! [C2, chap 23] Logistic distribution (2 params): 749 p1 = location, p2 = scale. 750 Density(x) proportional to sech^2((x-p1)/(2*p2)). */ 751 752 #define NIFTI_INTENT_LOGISTIC 14 753 754 /*! [C2, chap 24] Laplace distribution (2 params): 755 p1 = location, p2 = scale. 756 Density(x) proportional to exp(-abs(x-p1)/p2). */ 757 758 #define NIFTI_INTENT_LAPLACE 15 759 760 /*! [C2, chap 26] Uniform distribution: p1 = lower end, p2 = upper end. */ 761 762 #define NIFTI_INTENT_UNIFORM 16 763 764 /*! [C2, chap 31] Noncentral t statistic (2 params): 765 p1 = DOF, p2 = noncentrality parameter. */ 766 767 #define NIFTI_INTENT_TTEST_NONC 17 768 769 /*! [C1, chap 21] Weibull distribution (3 params): 770 p1 = location, p2 = scale, p3 = power. 771 Density(x) proportional to 772 ((x-p1)/p2)^(p3-1) * exp(-((x-p1)/p2)^p3) for x > p1. */ 773 774 #define NIFTI_INTENT_WEIBULL 18 775 776 /*! [C1, chap 18] Chi distribution (1 param): p1 = DOF. 777 Density(x) proportional to x^(p1-1) * exp(-x^2/2) for x > 0. 778 p1 = 1 = 'half normal' distribution 779 p1 = 2 = Rayleigh distribution 780 p1 = 3 = Maxwell-Boltzmann distribution. */ 781 782 #define NIFTI_INTENT_CHI 19 783 784 /*! [C1, chap 15] Inverse Gaussian (2 params): 785 p1 = mu, p2 = lambda 786 Density(x) proportional to 787 exp(-p2*(x-p1)^2/(2*p1^2*x)) / x^3 for x > 0. */ 788 789 #define NIFTI_INTENT_INVGAUSS 20 790 791 /*! [C2, chap 22] Extreme value type I (2 params): 792 p1 = location, p2 = scale 793 cdf(x) = exp(-exp(-(x-p1)/p2)). */ 794 795 #define NIFTI_INTENT_EXTVAL 21 796 797 /*! Data is a 'p-value' (no params). */ 798 799 #define NIFTI_INTENT_PVAL 22 800 801 /*! Data is ln(p-value) (no params). 802 To be safe, a program should compute p = exp(-abs(this_value)). 803 The nifti_stats.c library returns this_value 804 as positive, so that this_value = -log(p). */ 805 806 807 #define NIFTI_INTENT_LOGPVAL 23 808 809 /*! Data is log10(p-value) (no params). 810 To be safe, a program should compute p = pow(10.,-abs(this_value)). 811 The nifti_stats.c library returns this_value 812 as positive, so that this_value = -log10(p). */ 813 814 #define NIFTI_INTENT_LOG10PVAL 24 815 816 /*! Smallest intent_code that indicates a statistic. */ 817 818 #define NIFTI_FIRST_STATCODE 2 819 820 /*! Largest intent_code that indicates a statistic. */ 821 822 #define NIFTI_LAST_STATCODE 24 823 824 /*---------- these values for intent_code aren't for statistics ----------*/ 825 826 /*! To signify that the value at each voxel is an estimate 827 of some parameter, set intent_code = NIFTI_INTENT_ESTIMATE. 828 The name of the parameter may be stored in intent_name. */ 829 830 #define NIFTI_INTENT_ESTIMATE 1001 831 832 /*! To signify that the value at each voxel is an index into 833 some set of labels, set intent_code = NIFTI_INTENT_LABEL. 834 The filename with the labels may stored in aux_file. */ 835 836 #define NIFTI_INTENT_LABEL 1002 837 838 /*! To signify that the value at each voxel is an index into the 839 NeuroNames labels set, set intent_code = NIFTI_INTENT_NEURONAME. */ 840 841 #define NIFTI_INTENT_NEURONAME 1003 842 843 /*! To store an M x N matrix at each voxel: 844 - dataset must have a 5th dimension (dim[0]=5 and dim[5]>1) 845 - intent_code must be NIFTI_INTENT_GENMATRIX 846 - dim[5] must be M*N 847 - intent_p1 must be M (in float format) 848 - intent_p2 must be N (ditto) 849 - the matrix values A[i][[j] are stored in row-order: 850 - A[0][0] A[0][1] ... A[0][N-1] 851 - A[1][0] A[1][1] ... A[1][N-1] 852 - etc., until 853 - A[M-1][0] A[M-1][1] ... A[M-1][N-1] */ 854 855 #define NIFTI_INTENT_GENMATRIX 1004 856 857 /*! To store an NxN symmetric matrix at each voxel: 858 - dataset must have a 5th dimension 859 - intent_code must be NIFTI_INTENT_SYMMATRIX 860 - dim[5] must be N*(N+1)/2 861 - intent_p1 must be N (in float format) 862 - the matrix values A[i][[j] are stored in row-order: 863 - A[0][0] 864 - A[1][0] A[1][1] 865 - A[2][0] A[2][1] A[2][2] 866 - etc.: row-by-row */ 867 868 #define NIFTI_INTENT_SYMMATRIX 1005 869 870 /*! To signify that the vector value at each voxel is to be taken 871 as a displacement field or vector: 872 - dataset must have a 5th dimension 873 - intent_code must be NIFTI_INTENT_DISPVECT 874 - dim[5] must be the dimensionality of the displacment 875 vector (e.g., 3 for spatial displacement, 2 for in-plane) */ 876 877 #define NIFTI_INTENT_DISPVECT 1006 /* specifically for displacements */ 878 #define NIFTI_INTENT_VECTOR 1007 /* for any other type of vector */ 879 880 /*! To signify that the vector value at each voxel is really a 881 spatial coordinate (e.g., the vertices or nodes of a surface mesh): 882 - dataset must have a 5th dimension 883 - intent_code must be NIFTI_INTENT_POINTSET 884 - dim[0] = 5 885 - dim[1] = number of points 886 - dim[2] = dim[3] = dim[4] = 1 887 - dim[5] must be the dimensionality of space (e.g., 3 => 3D space). 888 - intent_name may describe the object these points come from 889 (e.g., "pial", "gray/white" , "EEG", "MEG"). */ 890 891 #define NIFTI_INTENT_POINTSET 1008 892 893 /*! To signify that the vector value at each voxel is really a triple 894 of indexes (e.g., forming a triangle) from a pointset dataset: 895 - dataset must have a 5th dimension 896 - intent_code must be NIFTI_INTENT_TRIANGLE 897 - dim[0] = 5 898 - dim[1] = number of triangles 899 - dim[2] = dim[3] = dim[4] = 1 900 - dim[5] = 3 901 - datatype should be an integer type (preferably DT_INT32) 902 - the data values are indexes (0,1,...) into a pointset dataset. */ 903 904 #define NIFTI_INTENT_TRIANGLE 1009 905 906 /*! To signify that the vector value at each voxel is a quaternion: 907 - dataset must have a 5th dimension 908 - intent_code must be NIFTI_INTENT_QUATERNION 909 - dim[0] = 5 910 - dim[5] = 4 911 - datatype should be a floating point type */ 912 913 #define NIFTI_INTENT_QUATERNION 1010 914 915 /*! Dimensionless value - no params - although, as in _ESTIMATE 916 the name of the parameter may be stored in intent_name. */ 917 918 #define NIFTI_INTENT_DIMLESS 1011 919 920 /*---------- these values apply to GIFTI datasets ----------*/ 921 922 /*! To signify that the value at each location is from a time series. */ 923 924 #define NIFTI_INTENT_TIME_SERIES 2001 925 926 /*! To signify that the value at each location is a node index, from 927 a complete surface dataset. */ 928 929 #define NIFTI_INTENT_NODE_INDEX 2002 930 931 /*! To signify that the vector value at each location is an RGB triplet, 932 of whatever type. 933 - dataset must have a 5th dimension 934 - dim[0] = 5 935 - dim[1] = number of nodes 936 - dim[2] = dim[3] = dim[4] = 1 937 - dim[5] = 3 938 */ 939 940 #define NIFTI_INTENT_RGB_VECTOR 2003 941 942 /*! To signify that the vector value at each location is a 4 valued RGBA 943 vector, of whatever type. 944 - dataset must have a 5th dimension 945 - dim[0] = 5 946 - dim[1] = number of nodes 947 - dim[2] = dim[3] = dim[4] = 1 948 - dim[5] = 4 949 */ 950 951 #define NIFTI_INTENT_RGBA_VECTOR 2004 952 953 /*! To signify that the value at each location is a shape value, such 954 as the curvature. */ 955 956 #define NIFTI_INTENT_SHAPE 2005 957 958 #endif // NO_NIFTI_INTENT_DEFINES 959 /* @} */ 960 961 /*---------------------------------------------------------------------------*/ 962 /* 3D IMAGE (VOLUME) ORIENTATION AND LOCATION IN SPACE: 963 --------------------------------------------------- 964 There are 3 different methods by which continuous coordinates can 965 attached to voxels. The discussion below emphasizes 3D volumes, and 966 the continuous coordinates are referred to as (x,y,z). The voxel 967 index coordinates (i.e., the array indexes) are referred to as (i,j,k), 968 with valid ranges: 969 i = 0 .. dim[1]-1 970 j = 0 .. dim[2]-1 (if dim[0] >= 2) 971 k = 0 .. dim[3]-1 (if dim[0] >= 3) 972 The (x,y,z) coordinates refer to the CENTER of a voxel. In methods 973 2 and 3, the (x,y,z) axes refer to a subject-based coordinate system, 974 with 975 +x = Right +y = Anterior +z = Superior. 976 This is a right-handed coordinate system. However, the exact direction 977 these axes point with respect to the subject depends on qform_code 978 (Method 2) and sform_code (Method 3). 979 980 N.B.: The i index varies most rapidly, j index next, k index slowest. 981 Thus, voxel (i,j,k) is stored starting at location 982 (i + j*dim[1] + k*dim[1]*dim[2]) * (bitpix/8) 983 into the dataset array. 984 985 N.B.: The ANALYZE 7.5 coordinate system is 986 +x = Left +y = Anterior +z = Superior 987 which is a left-handed coordinate system. This backwardness is 988 too difficult to tolerate, so this NIFTI-1 standard specifies the 989 coordinate order which is most common in functional neuroimaging. 990 991 N.B.: The 3 methods below all give the locations of the voxel centers 992 in the (x,y,z) coordinate system. In many cases, programs will wish 993 to display image data on some other grid. In such a case, the program 994 will need to convert its desired (x,y,z) values into (i,j,k) values 995 in order to extract (or interpolate) the image data. This operation 996 would be done with the inverse transformation to those described below. 997 998 N.B.: Method 2 uses a factor 'qfac' which is either -1 or 1; qfac is 999 stored in the otherwise unused pixdim[0]. If pixdim[0]=0.0 (which 1000 should not occur), we take qfac=1. Of course, pixdim[0] is only used 1001 when reading a NIFTI-1 header, not when reading an ANALYZE 7.5 header. 1002 1003 N.B.: The units of (x,y,z) can be specified using the xyzt_units field. 1004 1005 METHOD 1 (the "old" way, used only when qform_code = 0): 1006 ------------------------------------------------------- 1007 The coordinate mapping from (i,j,k) to (x,y,z) is the ANALYZE 1008 7.5 way. This is a simple scaling relationship: 1009 1010 x = pixdim[1] * i 1011 y = pixdim[2] * j 1012 z = pixdim[3] * k 1013 1014 No particular spatial orientation is attached to these (x,y,z) 1015 coordinates. (NIFTI-1 does not have the ANALYZE 7.5 orient field, 1016 which is not general and is often not set properly.) This method 1017 is not recommended, and is present mainly for compatibility with 1018 ANALYZE 7.5 files. 1019 1020 METHOD 2 (used when qform_code > 0, which should be the "normal" case): 1021 --------------------------------------------------------------------- 1022 The (x,y,z) coordinates are given by the pixdim[] scales, a rotation 1023 matrix, and a shift. This method is intended to represent 1024 "scanner-anatomical" coordinates, which are often embedded in the 1025 image header (e.g., DICOM fields (0020,0032), (0020,0037), (0028,0030), 1026 and (0018,0050)), and represent the nominal orientation and location of 1027 the data. This method can also be used to represent "aligned" 1028 coordinates, which would typically result from some post-acquisition 1029 alignment of the volume to a standard orientation (e.g., the same 1030 subject on another day, or a rigid rotation to true anatomical 1031 orientation from the tilted position of the subject in the scanner). 1032 The formula for (x,y,z) in terms of header parameters and (i,j,k) is: 1033 1034 [ x ] [ R11 R12 R13 ] [ pixdim[1] * i ] [ qoffset_x ] 1035 [ y ] = [ R21 R22 R23 ] [ pixdim[2] * j ] + [ qoffset_y ] 1036 [ z ] [ R31 R32 R33 ] [ qfac * pixdim[3] * k ] [ qoffset_z ] 1037 1038 The qoffset_* shifts are in the NIFTI-1 header. Note that the center 1039 of the (i,j,k)=(0,0,0) voxel (first value in the dataset array) is 1040 just (x,y,z)=(qoffset_x,qoffset_y,qoffset_z). 1041 1042 The rotation matrix R is calculated from the quatern_* parameters. 1043 This calculation is described below. 1044 1045 The scaling factor qfac is either 1 or -1. The rotation matrix R 1046 defined by the quaternion parameters is "proper" (has determinant 1). 1047 This may not fit the needs of the data; for example, if the image 1048 grid is 1049 i increases from Left-to-Right 1050 j increases from Anterior-to-Posterior 1051 k increases from Inferior-to-Superior 1052 Then (i,j,k) is a left-handed triple. In this example, if qfac=1, 1053 the R matrix would have to be 1054 1055 [ 1 0 0 ] 1056 [ 0 -1 0 ] which is "improper" (determinant = -1). 1057 [ 0 0 1 ] 1058 1059 If we set qfac=-1, then the R matrix would be 1060 1061 [ 1 0 0 ] 1062 [ 0 -1 0 ] which is proper. 1063 [ 0 0 -1 ] 1064 1065 This R matrix is represented by quaternion [a,b,c,d] = [0,1,0,0] 1066 (which encodes a 180 degree rotation about the x-axis). 1067 1068 METHOD 3 (used when sform_code > 0): 1069 ----------------------------------- 1070 The (x,y,z) coordinates are given by a general affine transformation 1071 of the (i,j,k) indexes: 1072 1073 x = srow_x[0] * i + srow_x[1] * j + srow_x[2] * k + srow_x[3] 1074 y = srow_y[0] * i + srow_y[1] * j + srow_y[2] * k + srow_y[3] 1075 z = srow_z[0] * i + srow_z[1] * j + srow_z[2] * k + srow_z[3] 1076 1077 The srow_* vectors are in the NIFTI_1 header. Note that no use is 1078 made of pixdim[] in this method. 1079 1080 WHY 3 METHODS? 1081 -------------- 1082 Method 1 is provided only for backwards compatibility. The intention 1083 is that Method 2 (qform_code > 0) represents the nominal voxel locations 1084 as reported by the scanner, or as rotated to some fiducial orientation and 1085 location. Method 3, if present (sform_code > 0), is to be used to give 1086 the location of the voxels in some standard space. The sform_code 1087 indicates which standard space is present. Both methods 2 and 3 can be 1088 present, and be useful in different contexts (method 2 for displaying the 1089 data on its original grid; method 3 for displaying it on a standard grid). 1090 1091 In this scheme, a dataset would originally be set up so that the 1092 Method 2 coordinates represent what the scanner reported. Later, 1093 a registration to some standard space can be computed and inserted 1094 in the header. Image display software can use either transform, 1095 depending on its purposes and needs. 1096 1097 In Method 2, the origin of coordinates would generally be whatever 1098 the scanner origin is; for example, in MRI, (0,0,0) is the center 1099 of the gradient coil. 1100 1101 In Method 3, the origin of coordinates would depend on the value 1102 of sform_code; for example, for the Talairach coordinate system, 1103 (0,0,0) corresponds to the Anterior Commissure. 1104 1105 QUATERNION REPRESENTATION OF ROTATION MATRIX (METHOD 2) 1106 ------------------------------------------------------- 1107 The orientation of the (x,y,z) axes relative to the (i,j,k) axes 1108 in 3D space is specified using a unit quaternion [a,b,c,d], where 1109 a*a+b*b+c*c+d*d=1. The (b,c,d) values are all that is needed, since 1110 we require that a = sqrt(1.0-(b*b+c*c+d*d)) be nonnegative. The (b,c,d) 1111 values are stored in the (quatern_b,quatern_c,quatern_d) fields. 1112 1113 The quaternion representation is chosen for its compactness in 1114 representing rotations. The (proper) 3x3 rotation matrix that 1115 corresponds to [a,b,c,d] is 1116 1117 [ a*a+b*b-c*c-d*d 2*b*c-2*a*d 2*b*d+2*a*c ] 1118 R = [ 2*b*c+2*a*d a*a+c*c-b*b-d*d 2*c*d-2*a*b ] 1119 [ 2*b*d-2*a*c 2*c*d+2*a*b a*a+d*d-c*c-b*b ] 1120 1121 [ R11 R12 R13 ] 1122 = [ R21 R22 R23 ] 1123 [ R31 R32 R33 ] 1124 1125 If (p,q,r) is a unit 3-vector, then rotation of angle h about that 1126 direction is represented by the quaternion 1127 1128 [a,b,c,d] = [cos(h/2), p*sin(h/2), q*sin(h/2), r*sin(h/2)]. 1129 1130 Requiring a >= 0 is equivalent to requiring -Pi <= h <= Pi. (Note that 1131 [-a,-b,-c,-d] represents the same rotation as [a,b,c,d]; there are 2 1132 quaternions that can be used to represent a given rotation matrix R.) 1133 To rotate a 3-vector (x,y,z) using quaternions, we compute the 1134 quaternion product 1135 1136 [0,x',y',z'] = [a,b,c,d] * [0,x,y,z] * [a,-b,-c,-d] 1137 1138 which is equivalent to the matrix-vector multiply 1139 1140 [ x' ] [ x ] 1141 [ y' ] = R [ y ] (equivalence depends on a*a+b*b+c*c+d*d=1) 1142 [ z' ] [ z ] 1143 1144 Multiplication of 2 quaternions is defined by the following: 1145 1146 [a,b,c,d] = a*1 + b*I + c*J + d*K 1147 where 1148 I*I = J*J = K*K = -1 (I,J,K are square roots of -1) 1149 I*J = K J*K = I K*I = J 1150 J*I = -K K*J = -I I*K = -J (not commutative!) 1151 For example 1152 [a,b,0,0] * [0,0,0,1] = [0,0,-b,a] 1153 since this expands to 1154 (a+b*I)*(K) = (a*K+b*I*K) = (a*K-b*J). 1155 1156 The above formula shows how to go from quaternion (b,c,d) to 1157 rotation matrix and direction cosines. Conversely, given R, 1158 we can compute the fields for the NIFTI-1 header by 1159 1160 a = 0.5 * sqrt(1+R11+R22+R33) (not stored) 1161 b = 0.25 * (R32-R23) / a => quatern_b 1162 c = 0.25 * (R13-R31) / a => quatern_c 1163 d = 0.25 * (R21-R12) / a => quatern_d 1164 1165 If a=0 (a 180 degree rotation), alternative formulas are needed. 1166 See the nifti1_io.c function mat44_to_quatern() for an implementation 1167 of the various cases in converting R to [a,b,c,d]. 1168 1169 Note that R-transpose (= R-inverse) would lead to the quaternion 1170 [a,-b,-c,-d]. 1171 1172 The choice to specify the qoffset_x (etc.) values in the final 1173 coordinate system is partly to make it easy to convert DICOM images to 1174 this format. The DICOM attribute "Image Position (Patient)" (0020,0032) 1175 stores the (Xd,Yd,Zd) coordinates of the center of the first voxel. 1176 Here, (Xd,Yd,Zd) refer to DICOM coordinates, and Xd=-x, Yd=-y, Zd=z, 1177 where (x,y,z) refers to the NIFTI coordinate system discussed above. 1178 (i.e., DICOM +Xd is Left, +Yd is Posterior, +Zd is Superior, 1179 whereas +x is Right, +y is Anterior , +z is Superior. ) 1180 Thus, if the (0020,0032) DICOM attribute is extracted into (px,py,pz), then 1181 qoffset_x = -px qoffset_y = -py qoffset_z = pz 1182 is a reasonable setting when qform_code=NIFTI_XFORM_SCANNER_ANAT. 1183 1184 That is, DICOM's coordinate system is 180 degrees rotated about the z-axis 1185 from the neuroscience/NIFTI coordinate system. To transform between DICOM 1186 and NIFTI, you just have to negate the x- and y-coordinates. 1187 1188 The DICOM attribute (0020,0037) "Image Orientation (Patient)" gives the 1189 orientation of the x- and y-axes of the image data in terms of 2 3-vectors. 1190 The first vector is a unit vector along the x-axis, and the second is 1191 along the y-axis. If the (0020,0037) attribute is extracted into the 1192 value (xa,xb,xc,ya,yb,yc), then the first two columns of the R matrix 1193 would be 1194 [ -xa -ya ] 1195 [ -xb -yb ] 1196 [ xc yc ] 1197 The negations are because DICOM's x- and y-axes are reversed relative 1198 to NIFTI's. The third column of the R matrix gives the direction of 1199 displacement (relative to the subject) along the slice-wise direction. 1200 This orientation is not encoded in the DICOM standard in a simple way; 1201 DICOM is mostly concerned with 2D images. The third column of R will be 1202 either the cross-product of the first 2 columns or its negative. It is 1203 possible to infer the sign of the 3rd column by examining the coordinates 1204 in DICOM attribute (0020,0032) "Image Position (Patient)" for successive 1205 slices. However, this method occasionally fails for reasons that I 1206 (RW Cox) do not understand. 1207 -----------------------------------------------------------------------------*/ 1208 1209 /* [qs]form_code value: */ /* x,y,z coordinate system refers to: */ 1210 /*-----------------------*/ /*---------------------------------------*/ 1211 1212 /*! \defgroup NIFTI1_XFORM_CODES 1213 \brief nifti1 xform codes to describe the "standard" coordinate system 1214 @{ 1215 */ 1216 #ifndef NO_NIFTI_XFORM_DEFINES 1217 1218 /*! Arbitrary coordinates (Method 1). */ 1219 1220 #define NIFTI_XFORM_UNKNOWN 0 1221 1222 /*! Scanner-based anatomical coordinates */ 1223 1224 #define NIFTI_XFORM_SCANNER_ANAT 1 1225 1226 /*! Coordinates aligned to another file's, 1227 or to anatomical "truth". */ 1228 1229 #define NIFTI_XFORM_ALIGNED_ANAT 2 1230 1231 /*! Coordinates aligned to Talairach- 1232 Tournoux Atlas; (0,0,0)=AC, etc. */ 1233 1234 #define NIFTI_XFORM_TALAIRACH 3 1235 1236 /*! MNI 152 normalized coordinates. */ 1237 1238 #define NIFTI_XFORM_MNI_152 4 1239 1240 1241 #endif // NO_NIFTI_XFORM_DEFINES 1242 /* @} */ 1243 1244 /*---------------------------------------------------------------------------*/ 1245 /* UNITS OF SPATIAL AND TEMPORAL DIMENSIONS: 1246 ---------------------------------------- 1247 The codes below can be used in xyzt_units to indicate the units of pixdim. 1248 As noted earlier, dimensions 1,2,3 are for x,y,z; dimension 4 is for 1249 time (t). 1250 - If dim[4]=1 or dim[0] < 4, there is no time axis. 1251 - A single time series (no space) would be specified with 1252 - dim[0] = 4 (for scalar data) or dim[0] = 5 (for vector data) 1253 - dim[1] = dim[2] = dim[3] = 1 1254 - dim[4] = number of time points 1255 - pixdim[4] = time step 1256 - xyzt_units indicates units of pixdim[4] 1257 - dim[5] = number of values stored at each time point 1258 1259 Bits 0..2 of xyzt_units specify the units of pixdim[1..3] 1260 (e.g., spatial units are values 1..7). 1261 Bits 3..5 of xyzt_units specify the units of pixdim[4] 1262 (e.g., temporal units are multiples of 8). 1263 1264 This compression of 2 distinct concepts into 1 byte is due to the 1265 limited space available in the 348 byte ANALYZE 7.5 header. The 1266 macros XYZT_TO_SPACE and XYZT_TO_TIME can be used to mask off the 1267 undesired bits from the xyzt_units fields, leaving "pure" space 1268 and time codes. Inversely, the macro SPACE_TIME_TO_XYZT can be 1269 used to assemble a space code (0,1,2,...,7) with a time code 1270 (0,8,16,32,...,56) into the combined value for xyzt_units. 1271 1272 Note that codes are provided to indicate the "time" axis units are 1273 actually frequency in Hertz (_HZ), in part-per-million (_PPM) 1274 or in radians-per-second (_RADS). 1275 1276 The toffset field can be used to indicate a nonzero start point for 1277 the time axis. That is, time point #m is at t=toffset+m*pixdim[4] 1278 for m=0..dim[4]-1. 1279 -----------------------------------------------------------------------------*/ 1280 1281 /*! \defgroup NIFTI1_UNITS 1282 \brief nifti1 units codes to describe the unit of measurement for 1283 each dimension of the dataset 1284 @{ 1285 */ 1286 #ifndef NO_NIFTI_UNITS_DEFINES 1287 1288 /*! NIFTI code for unspecified units. */ 1289 #define NIFTI_UNITS_UNKNOWN 0 1290 1291 /** Space codes are multiples of 1. **/ 1292 /*! NIFTI code for meters. */ 1293 #define NIFTI_UNITS_METER 1 1294 /*! NIFTI code for millimeters. */ 1295 #define NIFTI_UNITS_MM 2 1296 /*! NIFTI code for micrometers. */ 1297 #define NIFTI_UNITS_MICRON 3 1298 1299 /** Time codes are multiples of 8. **/ 1300 /*! NIFTI code for seconds. */ 1301 #define NIFTI_UNITS_SEC 8 1302 /*! NIFTI code for milliseconds. */ 1303 #define NIFTI_UNITS_MSEC 16 1304 /*! NIFTI code for microseconds. */ 1305 #define NIFTI_UNITS_USEC 24 1306 1307 /*** These units are for spectral data: ***/ 1308 /*! NIFTI code for Hertz. */ 1309 #define NIFTI_UNITS_HZ 32 1310 /*! NIFTI code for ppm. */ 1311 #define NIFTI_UNITS_PPM 40 1312 /*! NIFTI code for radians per second. */ 1313 #define NIFTI_UNITS_RADS 48 1314 1315 #endif // NO_NIFTI_UNITS_DEFINES 1316 /* @} */ 1317 1318 #undef XYZT_TO_SPACE 1319 #undef XYZT_TO_TIME 1320 #define XYZT_TO_SPACE(xyzt) ( (xyzt) & 0x07 ) 1321 #define XYZT_TO_TIME(xyzt) ( (xyzt) & 0x38 ) 1322 1323 #undef SPACE_TIME_TO_XYZT 1324 #define SPACE_TIME_TO_XYZT(ss,tt) ( (((char)(ss)) & 0x07) \ 1325 | (((char)(tt)) & 0x38) ) 1326 1327 /*---------------------------------------------------------------------------*/ 1328 /* MRI-SPECIFIC SPATIAL AND TEMPORAL INFORMATION: 1329 --------------------------------------------- 1330 A few fields are provided to store some extra information 1331 that is sometimes important when storing the image data 1332 from an FMRI time series experiment. (After processing such 1333 data into statistical images, these fields are not likely 1334 to be useful.) 1335 1336 { freq_dim } = These fields encode which spatial dimension (1,2, or 3) 1337 { phase_dim } = corresponds to which acquisition dimension for MRI data. 1338 { slice_dim } = 1339 Examples: 1340 Rectangular scan multi-slice EPI: 1341 freq_dim = 1 phase_dim = 2 slice_dim = 3 (or some permutation) 1342 Spiral scan multi-slice EPI: 1343 freq_dim = phase_dim = 0 slice_dim = 3 1344 since the concepts of frequency- and phase-encoding directions 1345 don't apply to spiral scan 1346 1347 slice_duration = If this is positive, AND if slice_dim is nonzero, 1348 indicates the amount of time used to acquire 1 slice. 1349 slice_duration*dim[slice_dim] can be less than pixdim[4] 1350 with a clustered acquisition method, for example. 1351 1352 slice_code = If this is nonzero, AND if slice_dim is nonzero, AND 1353 if slice_duration is positive, indicates the timing 1354 pattern of the slice acquisition. The following codes 1355 are defined: 1356 NIFTI_SLICE_SEQ_INC == sequential increasing 1357 NIFTI_SLICE_SEQ_DEC == sequential decreasing 1358 NIFTI_SLICE_ALT_INC == alternating increasing 1359 NIFTI_SLICE_ALT_DEC == alternating decreasing 1360 NIFTI_SLICE_ALT_INC2 == alternating increasing #2 1361 NIFTI_SLICE_ALT_DEC2 == alternating decreasing #2 1362 { slice_start } = Indicates the start and end of the slice acquisition 1363 { slice_end } = pattern, when slice_code is nonzero. These values 1364 are present to allow for the possible addition of 1365 "padded" slices at either end of the volume, which 1366 don't fit into the slice timing pattern. If there 1367 are no padding slices, then slice_start=0 and 1368 slice_end=dim[slice_dim]-1 are the correct values. 1369 For these values to be meaningful, slice_start must 1370 be non-negative and slice_end must be greater than 1371 slice_start. Otherwise, they should be ignored. 1372 1373 The following table indicates the slice timing pattern, relative to 1374 time=0 for the first slice acquired, for some sample cases. Here, 1375 dim[slice_dim]=7 (there are 7 slices, labeled 0..6), slice_duration=0.1, 1376 and slice_start=1, slice_end=5 (1 padded slice on each end). 1377 1378 slice 1379 index SEQ_INC SEQ_DEC ALT_INC ALT_DEC ALT_INC2 ALT_DEC2 1380 6 : n/a n/a n/a n/a n/a n/a n/a = not applicable 1381 5 : 0.4 0.0 0.2 0.0 0.4 0.2 (slice time offset 1382 4 : 0.3 0.1 0.4 0.3 0.1 0.0 doesn't apply to 1383 3 : 0.2 0.2 0.1 0.1 0.3 0.3 slices outside 1384 2 : 0.1 0.3 0.3 0.4 0.0 0.1 the range 1385 1 : 0.0 0.4 0.0 0.2 0.2 0.4 slice_start .. 1386 0 : n/a n/a n/a n/a n/a n/a slice_end) 1387 1388 The SEQ slice_codes are sequential ordering (uncommon but not unknown), 1389 either increasing in slice number or decreasing (INC or DEC), as 1390 illustrated above. 1391 1392 The ALT slice codes are alternating ordering. The 'standard' way for 1393 these to operate (without the '2' on the end) is for the slice timing 1394 to start at the edge of the slice_start .. slice_end group (at slice_start 1395 for INC and at slice_end for DEC). For the 'ALT_*2' slice_codes, the 1396 slice timing instead starts at the first slice in from the edge (at 1397 slice_start+1 for INC2 and at slice_end-1 for DEC2). This latter 1398 acquisition scheme is found on some Siemens scanners. 1399 1400 The fields freq_dim, phase_dim, slice_dim are all squished into the single 1401 byte field dim_info (2 bits each, since the values for each field are 1402 limited to the range 0..3). This unpleasantness is due to lack of space 1403 in the 348 byte allowance. 1404 1405 The macros DIM_INFO_TO_FREQ_DIM, DIM_INFO_TO_PHASE_DIM, and 1406 DIM_INFO_TO_SLICE_DIM can be used to extract these values from the 1407 dim_info byte. 1408 1409 The macro FPS_INTO_DIM_INFO can be used to put these 3 values 1410 into the dim_info byte. 1411 -----------------------------------------------------------------------------*/ 1412 1413 #undef DIM_INFO_TO_FREQ_DIM 1414 #undef DIM_INFO_TO_PHASE_DIM 1415 #undef DIM_INFO_TO_SLICE_DIM 1416 1417 #define DIM_INFO_TO_FREQ_DIM(di) ( ((di) ) & 0x03 ) 1418 #define DIM_INFO_TO_PHASE_DIM(di) ( ((di) >> 2) & 0x03 ) 1419 #define DIM_INFO_TO_SLICE_DIM(di) ( ((di) >> 4) & 0x03 ) 1420 1421 #undef FPS_INTO_DIM_INFO 1422 #define FPS_INTO_DIM_INFO(fd,pd,sd) ( ( ( ((char)(fd)) & 0x03) ) | \ 1423 ( ( ((char)(pd)) & 0x03) << 2 ) | \ 1424 ( ( ((char)(sd)) & 0x03) << 4 ) ) 1425 1426 /*! \defgroup NIFTI1_SLICE_ORDER 1427 \brief nifti1 slice order codes, describing the acquisition order 1428 of the slices 1429 @{ 1430 */ 1431 #ifndef NO_NIFTI_SLICE_DEFINES 1432 #define NIFTI_SLICE_UNKNOWN 0 1433 #define NIFTI_SLICE_SEQ_INC 1 1434 #define NIFTI_SLICE_SEQ_DEC 2 1435 #define NIFTI_SLICE_ALT_INC 3 1436 #define NIFTI_SLICE_ALT_DEC 4 1437 #define NIFTI_SLICE_ALT_INC2 5 /* 05 May 2005: RWCox */ 1438 #define NIFTI_SLICE_ALT_DEC2 6 /* 05 May 2005: RWCox */ 1439 #endif // NO_NIFTI_SLICE_DEFINES 1440 /* @} */ 1441 1442 /*---------------------------------------------------------------------------*/ 1443 /* UNUSED FIELDS: 1444 ------------- 1445 Some of the ANALYZE 7.5 fields marked as ++UNUSED++ may need to be set 1446 to particular values for compatibility with other programs. The issue 1447 of interoperability of ANALYZE 7.5 files is a murky one -- not all 1448 programs require exactly the same set of fields. (Unobscuring this 1449 murkiness is a principal motivation behind NIFTI-1.) 1450 1451 Some of the fields that may need to be set for other (non-NIFTI aware) 1452 software to be happy are: 1453 1454 extents dbh.h says this should be 16384 1455 regular dbh.h says this should be the character 'r' 1456 glmin, } dbh.h says these values should be the min and max voxel 1457 glmax } values for the entire dataset 1458 1459 It is best to initialize ALL fields in the NIFTI-1 header to 0 1460 (e.g., with calloc()), then fill in what is needed. 1461 -----------------------------------------------------------------------------*/ 1462 1463 /*---------------------------------------------------------------------------*/ 1464 /* MISCELLANEOUS C MACROS 1465 -----------------------------------------------------------------------------*/ 1466 1467 /*.................*/ 1468 /*! Given a nifti_1_header struct, check if it has a good magic number. 1469 Returns NIFTI version number (1..9) if magic is good, 0 if it is not. */ 1470 1471 #define NIFTI_VERSION(h) \ 1472 ( ( (h).magic[0]=='n' && (h).magic[3]=='\0' && \ 1473 ( (h).magic[1]=='i' || (h).magic[1]=='+' ) && \ 1474 ( (h).magic[2]>='1' && (h).magic[2]<='9' ) ) \ 1475 ? (h).magic[2]-'0' : 0 ) 1476 1477 /*.................*/ 1478 /*! Check if a nifti_1_header struct says if the data is stored in the 1479 same file or in a separate file. Returns 1 if the data is in the same 1480 file as the header, 0 if it is not. */ 1481 1482 #define NIFTI_ONEFILE(h) ( (h).magic[1] == '+' ) 1483 1484 /*.................*/ 1485 /*! Check if a nifti_1_header struct needs to be byte swapped. 1486 Returns 1 if it needs to be swapped, 0 if it does not. */ 1487 1488 #define NIFTI_NEEDS_SWAP(h) ( (h).dim[0] < 0 || (h).dim[0] > 7 ) 1489 1490 /*.................*/ 1491 /*! Check if a nifti_1_header struct contains a 5th (vector) dimension. 1492 Returns size of 5th dimension if > 1, returns 0 otherwise. */ 1493 1494 #define NIFTI_5TH_DIM(h) ( ((h).dim[0]>4 && (h).dim[5]>1) ? (h).dim[5] : 0 ) 1495 1496 /*****************************************************************************/ 1497 1498 1499 } // namespace mirtk 1500 1501 #endif /* _MIRTK_NIFTI_HEADER_ */ 1502