nifti nrrd

nifti-nrrd

Or - things that nifti can learn from NRRD.

These notes are from reading through the NRRD definition.

They are very draftey.

JSON might improve over the very raw 'field: value' format of NRRD by allowing nesting.

Detached header

NRRD can act as a header for raw data files or DICOMS on disk. Nifti doesn't cover this case (as far as I know). By putting the list of files (datafile: field in NRRD) into the header extension, nifti could also cover this case. Is that really worthwhile given that NRRD covers this already?

If we do try and add this, then we could also / should also add encoding and line skip. Byte skip is covered by nifti's vox_offset.

Space

Defining the output space of the image. There may be less output space dimensions than input dimensions of some of the input dimensions are e.g. RGB vectors - i.e. not space.

Fields are:

• space
• space dimension
• space units
• space origin
• space directions

Note that nifti has codes for output xyzt units, which can therefore only be (m, mm, microm, sec, msec, microsec, hz, ppm, rads, unknown). We should probably try and write the nifti header correctly, and raise an error if the nifti record clashes with the extension (nifti says something other than unknown, and extension has another of the known values but not the same as the nifti).

Suggest something on lines of:

{"space": {
"name": "RAS",
"output_axes": [
    {"units": "mm",
    "origin": 0.0,
    "direction", [1,0,0],
    "measurement_direction", [0, 1, 0]
    },
    {"units": "mm",
    "origin": 1.0,
    "direction", [0,1,0],
    "measurement_direction", [1, 0, 0]
    },
    {"units": "mm",
    "origin": 0.3,
    "direction", [0,0,1],
    "measurement_direction", [0, 0, 1]
    },
]
}

Gordon - did I understand that correctly?

Types

Is the block type supported in nifti? The block is a binary bit of data of a certain length, forming the element of the array. For example an array of c structs. There's no direct way to signal this in a nifti file, other than making the first axis (fastest changing) have length block size: and have the type be uchar or similar. And that would make a mess because the first axis has to be spatial in the nifti standard.

So block: probably cannot be supported with a valid nifti.

Content

We could have a content: field which allows a string of arbitrary length instead of the nifti 80 character descrip.

Min / max

• min
• max
• oldmin
• oldmax

Not in standard nifti. There are nifti glmin and glmax, and calmin and calmax. The gl variables are marked as "UNUSED" - but I guess we could use them. The cal variables are recorded as being for display.

Sample units

• sampleunits

nifti has the intent code, but it seems to cover statistics in the main (t tests etc). So the intent can tell you the scalars are t values, but not that the scalars are ml min-1 or similar.

Per axis

Covered by nifti:

• sizes (dim)
• spacings (voxdim)

Not covered, and probably best handled in a JSON array (one entry per axis):

{"input_axes": [
    {"min": -72.0,
    "max": 72.0,
    "centering": "node",
    "labels": ["X", "phase"],
    "units", "mm",
    "kind", "space",
    },
    {"min": -80.0,
    "max": 60.0,
    "centering": "node",
    "labels": ["Y", "frequency"],
    "units", "mm",
    "kind", "space",
    },
    {"thickness": 2.4,
    "min": -40.0,
    "max": 64.0,
    "centering": "node",
    "labels": ["Z", "slice"],
    "units", "mm",
    "kind", "space",
    },
    {"min": 0.0,
    "centering": "node",
    "labels": ["time", "t"],
    "units", "sec",
    "kind", "time",
    },
]
}

There is some overlap with the interpretations of the various slice-related fields in nifti - which can give information that constrains how long a volume should take. The nifti toffset field is the same as the min field in the last entry in the JSON above. The nifti dim_info code allows the nifti to say which is the slice, frequency and phase axes in the first three axes. NRRD here is obviously more expressive.