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