bids-table_ver-1.10.0dev.json

{"anat": [{"entities": {"subject": {"name": "sub", "display_name": "Subject", "description": "<p>A person or animal participating in the study.</p>", "type": "string", "format": "label", "required": "required"}, "session": {"name": "ses", "display_name": "Session", "description": "<p>A logical grouping of neuroimaging and behavioral data consistent across subjects.\nSession can (but doesn't have to) be synonymous to a visit in a longitudinal study.\nIn general, subjects will stay in the scanner during one session.\nHowever, for example, if a subject has to leave the scanner room and then\nbe re-positioned on the scanner bed, the set of MRI acquisitions will still\nbe considered as a session and match sessions acquired in other subjects.\nSimilarly, in situations where different data types are obtained over\nseveral visits (for example fMRI on one day followed by DWI the day after)\nthose can be grouped in one session.</p>\n<p>Defining multiple sessions is appropriate when several identical or similar\ndata acquisitions are planned and performed on all -or most- subjects,\noften in the case of some intervention between sessions\n(for example, training).</p>", "type": "string", "format": "label", "required": "optional"}, "task": {"name": "task", "display_name": "Task", "description": "<p>A set of structured activities performed by the participant.\nTasks are usually accompanied by stimuli and responses, and can greatly vary in complexity.</p>\n<p>In the context of brain scanning, a task is always tied to one data acquisition.\nTherefore, even if during one acquisition the subject performed multiple conceptually different behaviors\n(with different sets of instructions) they will be considered one (combined) task.</p>\n<p>While tasks may be repeated across multiple acquisitions,\na given task may have different sets of stimuli (for example, randomized order) and participant responses\nacross subjects, sessions, and runs.</p>\n<p>The <code>task-&lt;label&gt;</code> MUST be consistent across subjects and sessions.</p>\n<p>Files with the <code>task-&lt;label&gt;</code> entity SHOULD have an associated\n<a href=\"SPEC_ROOT/modality-specific-files/task-events.md#task-events\">events file</a>,\nas well as certain metadata fields in the associated JSON file.</p>\n<p>For the purpose of this specification we consider the so-called \"resting state\" a task,\nalthough events files are not expected for resting state data.\nAdditionally, a common convention in the specification is to include the word \"rest\" in\nthe <code>task</code> label for resting state files (for example, <code>task-rest</code>).</p>", "type": "string", "format": "label", "required": "optional"}, "acquisition": {"name": "acq", "display_name": "Acquisition", "description": "<p>The <code>acq-&lt;label&gt;</code> entity corresponds to a custom label the user MAY use to distinguish\na different set of parameters used for acquiring the same modality.</p>\n<p>For example, this should be used when a study includes two T1w images -\none full brain low resolution and one restricted field of view but high resolution.\nIn such case two files could have the following names:\n<code>sub-01_acq-highres_T1w.nii.gz</code> and <code>sub-01_acq-lowres_T1w.nii.gz</code>;\nhowever, the user is free to choose any other label than <code>highres</code> and <code>lowres</code> as long\nas they are consistent across subjects and sessions.</p>\n<p>In case different sequences are used to record the same modality\n(for example, <code>RARE</code> and <code>FLASH</code> for T1w)\nthis field can also be used to make that distinction.\nThe level of detail at which the distinction is made\n(for example, just between <code>RARE</code> and <code>FLASH</code>, or between <code>RARE</code>, <code>FLASH</code>, and <code>FLASHsubsampled</code>)\nremains at the discretion of the researcher.</p>", "type": "string", "format": "label", "required": "optional"}, "ceagent": {"name": "ce", "display_name": "Contrast Enhancing Agent", "description": "<p>The <code>ce-&lt;label&gt;</code> entity can be used to distinguish sequences using different contrast enhanced images.\nThe label is the name of the contrast agent.</p>\n<p>This entity represents the <code>\"ContrastBolusIngredient\"</code> metadata field.\nTherefore, if the <code>ce-&lt;label&gt;</code> entity is present in a filename,\n<code>\"ContrastBolusIngredient\"</code> MAY also be added in the JSON file, with the same label.</p>", "type": "string", "format": "label", "required": "optional"}, "reconstruction": {"name": "rec", "display_name": "Reconstruction", "description": "<p>The <code>rec-&lt;label&gt;</code> entity can be used to distinguish different reconstruction algorithms\n(for example, <code>MoCo</code> for the ones using motion correction).</p>", "type": "string", "format": "label", "required": "optional"}, "run": {"name": "run", "display_name": "Run", "description": "<p>The <code>run-&lt;index&gt;</code> entity is used to distinguish separate data acquisitions with the same acquisition parameters\nand (other) entities.</p>\n<p>If several data acquisitions (for example, MRI scans or EEG recordings)\nwith the same acquisition parameters are acquired in the same session,\nthey MUST be indexed with the <a href=\"SPEC_ROOT/appendices/entities.md#run\"><code>run-&lt;index&gt;</code></a> entity:\n<code>_run-1</code>, <code>_run-2</code>, <code>_run-3</code>, and so on\n(only nonnegative integers are allowed as run indices).</p>\n<p>If different entities apply,\nsuch as a different session indicated by [<code>ses-&lt;label&gt;</code>][SPEC_ROOT/appendices/entities.md#ses),\nor different acquisition parameters indicated by\n<a href=\"SPEC_ROOT/appendices/entities.md#acq\"><code>acq-&lt;label&gt;</code></a>,\nthen <code>run</code> is not needed to distinguish the scans and MAY be omitted.</p>", "type": "string", "format": "index", "required": "optional"}, "echo": {"name": "echo", "display_name": "Echo", "description": "<p>If files belonging to an entity-linked file collection are acquired at different\necho times, the <code>echo-&lt;index&gt;</code> entity MUST be used to distinguish individual files.</p>\n<p>This entity represents the <code>\"EchoTime\"</code> metadata field.\nTherefore, if the <code>echo-&lt;index&gt;</code> entity is present in a filename,\n<code>\"EchoTime\"</code> MUST be defined in the associated metadata.\nPlease note that the <code>&lt;index&gt;</code> denotes the number/index (in the form of a nonnegative integer),\nnot the <code>\"EchoTime\"</code> value of the separate JSON file.</p>", "type": "string", "format": "index", "required": "optional"}, "part": {"name": "part", "display_name": "Part", "description": "<p>This entity is used to indicate which component of the complex\nrepresentation of the MRI signal is represented in voxel data.\nThe <code>part-&lt;label&gt;</code> entity is associated with the DICOM Tag\n<code>0008, 9208</code>.\nAllowed label values for this entity are <code>phase</code>, <code>mag</code>, <code>real</code> and <code>imag</code>,\nwhich are typically used in <code>part-mag</code>/<code>part-phase</code> or\n<code>part-real</code>/<code>part-imag</code> pairs of files.</p>\n<p>Phase images MAY be in radians or in arbitrary units.\nThe sidecar JSON file MUST include the <code>\"Units\"</code> of the <code>phase</code> image.\nThe possible options are <code>\"rad\"</code> or <code>\"arbitrary\"</code>.</p>\n<p>When there is only a magnitude image of a given type, the <code>part</code> entity MAY be\nomitted.</p>", "type": "string", "format": "label", "enum": ["mag", "phase", "real", "imag"], "required": "optional"}, "chunk": {"name": "chunk", "display_name": "Chunk", "description": "<p>The <code>chunk-&lt;index&gt;</code> key/value pair is used to distinguish between images of\nthe same physical sample with different fields of view acquired in the same\nimaging experiment.\nThis entity applies to collections of 2D images, 3D volumes or 4D volume series\n(for example, diffusion weighted images), and may be used to indicate different\nanatomical structures or regions of the same structure.</p>", "type": "string", "format": "index", "required": "optional"}}, "value": "T1w", "display_name": "T1-weighted image", "description": "<p>In arbitrary units (arbitrary).\nThe contrast of these images is mainly determined by spatial variations in\nthe longitudinal relaxation time of the imaged specimen.\nIn spin-echo sequences this contrast is achieved at relatively short\nrepetition and echo times.\nTo achieve this weighting in gradient-echo images, again, short repetition\nand echo times are selected; however, at relatively large flip angles.\nAnother common approach to increase T1 weighting in gradient-echo images is\nto add an inversion preparation block to the beginning of the imaging\nsequence (for example, <code>TurboFLASH</code> or <code>MP-RAGE</code>).</p>\n<br><code>nonparametric</code>", "unit": "arbitrary"}, {"entities": {"subject": {"name": "sub", "display_name": "Subject", "description": "<p>A person or animal participating in the study.</p>", "type": "string", "format": "label", "required": "required"}, "session": {"name": "ses", "display_name": "Session", "description": "<p>A logical grouping of neuroimaging and behavioral data consistent across subjects.\nSession can (but doesn't have to) be synonymous to a visit in a longitudinal study.\nIn general, subjects will stay in the scanner during one session.\nHowever, for example, if a subject has to leave the scanner room and then\nbe re-positioned on the scanner bed, the set of MRI acquisitions will still\nbe considered as a session and match sessions acquired in other subjects.\nSimilarly, in situations where different data types are obtained over\nseveral visits (for example fMRI on one day followed by DWI the day after)\nthose can be grouped in one session.</p>\n<p>Defining multiple sessions is appropriate when several identical or similar\ndata acquisitions are planned and performed on all -or most- subjects,\noften in the case of some intervention between sessions\n(for example, training).</p>", "type": "string", "format": "label", "required": "optional"}, "task": {"name": "task", "display_name": "Task", "description": "<p>A set of structured activities performed by the participant.\nTasks are usually accompanied by stimuli and responses, and can greatly vary in complexity.</p>\n<p>In the context of brain scanning, a task is always tied to one data acquisition.\nTherefore, even if during one acquisition the subject performed multiple conceptually different behaviors\n(with different sets of instructions) they will be considered one (combined) task.</p>\n<p>While tasks may be repeated across multiple acquisitions,\na given task may have different sets of stimuli (for example, randomized order) and participant responses\nacross subjects, sessions, and runs.</p>\n<p>The <code>task-&lt;label&gt;</code> MUST be consistent across subjects and sessions.</p>\n<p>Files with the <code>task-&lt;label&gt;</code> entity SHOULD have an associated\n<a href=\"SPEC_ROOT/modality-specific-files/task-events.md#task-events\">events file</a>,\nas well as certain metadata fields in the associated JSON file.</p>\n<p>For the purpose of this specification we consider the so-called \"resting state\" a task,\nalthough events files are not expected for resting state data.\nAdditionally, a common convention in the specification is to include the word \"rest\" in\nthe <code>task</code> label for resting state files (for example, <code>task-rest</code>).</p>", "type": "string", "format": "label", "required": "optional"}, "acquisition": {"name": "acq", "display_name": "Acquisition", "description": "<p>The <code>acq-&lt;label&gt;</code> entity corresponds to a custom label the user MAY use to distinguish\na different set of parameters used for acquiring the same modality.</p>\n<p>For example, this should be used when a study includes two T1w images -\none full brain low resolution and one restricted field of view but high resolution.\nIn such case two files could have the following names:\n<code>sub-01_acq-highres_T1w.nii.gz</code> and <code>sub-01_acq-lowres_T1w.nii.gz</code>;\nhowever, the user is free to choose any other label than <code>highres</code> and <code>lowres</code> as long\nas they are consistent across subjects and sessions.</p>\n<p>In case different sequences are used to record the same modality\n(for example, <code>RARE</code> and <code>FLASH</code> for T1w)\nthis field can also be used to make that distinction.\nThe level of detail at which the distinction is made\n(for example, just between <code>RARE</code> and <code>FLASH</code>, or between <code>RARE</code>, <code>FLASH</code>, and <code>FLASHsubsampled</code>)\nremains at the discretion of the researcher.</p>", "type": "string", "format": "label", "required": "optional"}, "ceagent": {"name": "ce", "display_name": "Contrast Enhancing Agent", "description": "<p>The <code>ce-&lt;label&gt;</code> entity can be used to distinguish sequences using different contrast enhanced images.\nThe label is the name of the contrast agent.</p>\n<p>This entity represents the <code>\"ContrastBolusIngredient\"</code> metadata field.\nTherefore, if the <code>ce-&lt;label&gt;</code> entity is present in a filename,\n<code>\"ContrastBolusIngredient\"</code> MAY also be added in the JSON file, with the same label.</p>", "type": "string", "format": "label", "required": "optional"}, "reconstruction": {"name": "rec", "display_name": "Reconstruction", "description": "<p>The <code>rec-&lt;label&gt;</code> entity can be used to distinguish different reconstruction algorithms\n(for example, <code>MoCo</code> for the ones using motion correction).</p>", "type": "string", "format": "label", "required": "optional"}, "run": {"name": "run", "display_name": "Run", "description": "<p>The <code>run-&lt;index&gt;</code> entity is used to distinguish separate data acquisitions with the same acquisition parameters\nand (other) entities.</p>\n<p>If several data acquisitions (for example, MRI scans or EEG recordings)\nwith the same acquisition parameters are acquired in the same session,\nthey MUST be indexed with the <a href=\"SPEC_ROOT/appendices/entities.md#run\"><code>run-&lt;index&gt;</code></a> entity:\n<code>_run-1</code>, <code>_run-2</code>, <code>_run-3</code>, and so on\n(only nonnegative integers are allowed as run indices).</p>\n<p>If different entities apply,\nsuch as a different session indicated by [<code>ses-&lt;label&gt;</code>][SPEC_ROOT/appendices/entities.md#ses),\nor different acquisition parameters indicated by\n<a href=\"SPEC_ROOT/appendices/entities.md#acq\"><code>acq-&lt;label&gt;</code></a>,\nthen <code>run</code> is not needed to distinguish the scans and MAY be omitted.</p>", "type": "string", "format": "index", "required": "optional"}, "echo": {"name": "echo", "display_name": "Echo", "description": "<p>If files belonging to an entity-linked file collection are acquired at different\necho times, the <code>echo-&lt;index&gt;</code> entity MUST be used to distinguish individual files.</p>\n<p>This entity represents the <code>\"EchoTime\"</code> metadata field.\nTherefore, if the <code>echo-&lt;index&gt;</code> entity is present in a filename,\n<code>\"EchoTime\"</code> MUST be defined in the associated metadata.\nPlease note that the <code>&lt;index&gt;</code> denotes the number/index (in the form of a nonnegative integer),\nnot the <code>\"EchoTime\"</code> value of the separate JSON file.</p>", "type": "string", "format": "index", "required": "optional"}, "part": {"name": "part", "display_name": "Part", "description": "<p>This entity is used to indicate which component of the complex\nrepresentation of the MRI signal is represented in voxel data.\nThe <code>part-&lt;label&gt;</code> entity is associated with the DICOM Tag\n<code>0008, 9208</code>.\nAllowed label values for this entity are <code>phase</code>, <code>mag</code>, <code>real</code> and <code>imag</code>,\nwhich are typically used in <code>part-mag</code>/<code>part-phase</code> or\n<code>part-real</code>/<code>part-imag</code> pairs of files.</p>\n<p>Phase images MAY be in radians or in arbitrary units.\nThe sidecar JSON file MUST include the <code>\"Units\"</code> of the <code>phase</code> image.\nThe possible options are <code>\"rad\"</code> or <code>\"arbitrary\"</code>.</p>\n<p>When there is only a magnitude image of a given type, the <code>part</code> entity MAY be\nomitted.</p>", "type": "string", "format": "label", "enum": ["mag", "phase", "real", "imag"], "required": "optional"}, "chunk": {"name": "chunk", "display_name": "Chunk", "description": "<p>The <code>chunk-&lt;index&gt;</code> key/value pair is used to distinguish between images of\nthe same physical sample with different fields of view acquired in the same\nimaging experiment.\nThis entity applies to collections of 2D images, 3D volumes or 4D volume series\n(for example, diffusion weighted images), and may be used to indicate different\nanatomical structures or regions of the same structure.</p>", "type": "string", "format": "index", "required": "optional"}}, "value": "T2w", "display_name": "T2-weighted image", "description": "<p>In arbitrary units (arbitrary).\nThe contrast of these images is mainly determined by spatial variations in\nthe (true) transverse relaxation time of the imaged specimen.\nIn spin-echo sequences this contrast is achieved at relatively long\nrepetition and echo times.\nGenerally, gradient echo sequences are not the most suitable option for\nachieving T2 weighting, as their contrast natively depends on T2-star rather\nthan on T2.</p>\n<br><code>nonparametric</code>", "unit": "arbitrary"}, {"entities": {"subject": {"name": "sub", "display_name": "Subject", "description": "<p>A person or animal participating in the study.</p>", "type": "string", "format": "label", "required": "required"}, "session": {"name": "ses", "display_name": "Session", "description": "<p>A logical grouping of neuroimaging and behavioral data consistent across subjects.\nSession can (but doesn't have to) be synonymous to a visit in a longitudinal study.\nIn general, subjects will stay in the scanner during one session.\nHowever, for example, if a subject has to leave the scanner room and then\nbe re-positioned on the scanner bed, the set of MRI acquisitions will still\nbe considered as a session and match sessions acquired in other subjects.\nSimilarly, in situations where different data types are obtained over\nseveral visits (for example fMRI on one day followed by DWI the day after)\nthose can be grouped in one session.</p>\n<p>Defining multiple sessions is appropriate when several identical or similar\ndata acquisitions are planned and performed on all -or most- subjects,\noften in the case of some intervention between sessions\n(for example, training).</p>", "type": "string", "format": "label", "required": "optional"}, "task": {"name": "task", "display_name": "Task", "description": "<p>A set of structured activities performed by the participant.\nTasks are usually accompanied by stimuli and responses, and can greatly vary in complexity.</p>\n<p>In the context of brain scanning, a task is always tied to one data acquisition.\nTherefore, even if during one acquisition the subject performed multiple conceptually different behaviors\n(with different sets of instructions) they will be considered one (combined) task.</p>\n<p>While tasks may be repeated across multiple acquisitions,\na given task may have different sets of stimuli (for example, randomized order) and participant responses\nacross subjects, sessions, and runs.</p>\n<p>The <code>task-&lt;label&gt;</code> MUST be consistent across subjects and sessions.</p>\n<p>Files with the <code>task-&lt;label&gt;</code> entity SHOULD have an associated\n<a href=\"SPEC_ROOT/modality-specific-files/task-events.md#task-events\">events file</a>,\nas well as certain metadata fields in the associated JSON file.</p>\n<p>For the purpose of this specification we consider the so-called \"resting state\" a task,\nalthough events files are not expected for resting state data.\nAdditionally, a common convention in the specification is to include the word \"rest\" in\nthe <code>task</code> label for resting state files (for example, <code>task-rest</code>).</p>", "type": "string", "format": "label", "required": "optional"}, "acquisition": {"name": "acq", "display_name": "Acquisition", "description": "<p>The <code>acq-&lt;label&gt;</code> entity corresponds to a custom label the user MAY use to distinguish\na different set of parameters used for acquiring the same modality.</p>\n<p>For example, this should be used when a study includes two T1w images -\none full brain low resolution and one restricted field of view but high resolution.\nIn such case two files could have the following names:\n<code>sub-01_acq-highres_T1w.nii.gz</code> and <code>sub-01_acq-lowres_T1w.nii.gz</code>;\nhowever, the user is free to choose any other label than <code>highres</code> and <code>lowres</code> as long\nas they are consistent across subjects and sessions.</p>\n<p>In case different sequences are used to record the same modality\n(for example, <code>RARE</code> and <code>FLASH</code> for T1w)\nthis field can also be used to make that distinction.\nThe level of detail at which the distinction is made\n(for example, just between <code>RARE</code> and <code>FLASH</code>, or between <code>RARE</code>, <code>FLASH</code>, and <code>FLASHsubsampled</code>)\nremains at the discretion of the researcher.</p>", "type": "string", "format": "label", "required": "optional"}, "ceagent": {"name": "ce", "display_name": "Contrast Enhancing Agent", "description": "<p>The <code>ce-&lt;label&gt;</code> entity can be used to distinguish sequences using different contrast enhanced images.\nThe label is the name of the contrast agent.</p>\n<p>This entity represents the <code>\"ContrastBolusIngredient\"</code> metadata field.\nTherefore, if the <code>ce-&lt;label&gt;</code> entity is present in a filename,\n<code>\"ContrastBolusIngredient\"</code> MAY also be added in the JSON file, with the same label.</p>", "type": "string", "format": "label", "required": "optional"}, "reconstruction": {"name": "rec", "display_name": "Reconstruction", "description": "<p>The <code>rec-&lt;label&gt;</code> entity can be used to distinguish different reconstruction algorithms\n(for example, <code>MoCo</code> for the ones using motion correction).</p>", "type": "string", "format": "label", "required": "optional"}, "run": {"name": "run", "display_name": "Run", "description": "<p>The <code>run-&lt;index&gt;</code> entity is used to distinguish separate data acquisitions with the same acquisition parameters\nand (other) entities.</p>\n<p>If several data acquisitions (for example, MRI scans or EEG recordings)\nwith the same acquisition parameters are acquired in the same session,\nthey MUST be indexed with the <a href=\"SPEC_ROOT/appendices/entities.md#run\"><code>run-&lt;index&gt;</code></a> entity:\n<code>_run-1</code>, <code>_run-2</code>, <code>_run-3</code>, and so on\n(only nonnegative integers are allowed as run indices).</p>\n<p>If different entities apply,\nsuch as a different session indicated by [<code>ses-&lt;label&gt;</code>][SPEC_ROOT/appendices/entities.md#ses),\nor different acquisition parameters indicated by\n<a href=\"SPEC_ROOT/appendices/entities.md#acq\"><code>acq-&lt;label&gt;</code></a>,\nthen <code>run</code> is not needed to distinguish the scans and MAY be omitted.</p>", "type": "string", "format": "index", "required": "optional"}, "echo": {"name": "echo", "display_name": "Echo", "description": "<p>If files belonging to an entity-linked file collection are acquired at different\necho times, the <code>echo-&lt;index&gt;</code> entity MUST be used to distinguish individual files.</p>\n<p>This entity represents the <code>\"EchoTime\"</code> metadata field.\nTherefore, if the <code>echo-&lt;index&gt;</code> entity is present in a filename,\n<code>\"EchoTime\"</code> MUST be defined in the associated metadata.\nPlease note that the <code>&lt;index&gt;</code> denotes the number/index (in the form of a nonnegative integer),\nnot the <code>\"EchoTime\"</code> value of the separate JSON file.</p>", "type": "string", "format": "index", "required": "optional"}, "part": {"name": "part", "display_name": "Part", "description": "<p>This entity is used to indicate which component of the complex\nrepresentation of the MRI signal is represented in voxel data.\nThe <code>part-&lt;label&gt;</code> entity is associated with the DICOM Tag\n<code>0008, 9208</code>.\nAllowed label values for this entity are <code>phase</code>, <code>mag</code>, <code>real</code> and <code>imag</code>,\nwhich are typically used in <code>part-mag</code>/<code>part-phase</code> or\n<code>part-real</code>/<code>part-imag</code> pairs of files.</p>\n<p>Phase images MAY be in radians or in arbitrary units.\nThe sidecar JSON file MUST include the <code>\"Units\"</code> of the <code>phase</code> image.\nThe possible options are <code>\"rad\"</code> or <code>\"arbitrary\"</code>.</p>\n<p>When there is only a magnitude image of a given type, the <code>part</code> entity MAY be\nomitted.</p>", "type": "string", "format": "label", "enum": ["mag", "phase", "real", "imag"], "required": "optional"}, "chunk": {"name": "chunk", "display_name": "Chunk", "description": "<p>The <code>chunk-&lt;index&gt;</code> key/value pair is used to distinguish between images of\nthe same physical sample with different fields of view acquired in the same\nimaging experiment.\nThis entity applies to collections of 2D images, 3D volumes or 4D volume series\n(for example, diffusion weighted images), and may be used to indicate different\nanatomical structures or regions of the same structure.</p>", "type": "string", "format": "index", "required": "optional"}}, "value": "PDw", "display_name": "Proton density (PD) weighted image", "description": "<p>In arbitrary units (arbitrary).\nThe contrast of these images is mainly determined by spatial variations in\nthe spin density (1H) of the imaged specimen.\nThis contrast is achieved at short echo times and long repetition times;\nfor gradient echo, this weighting is also possible with a short TR (TR&lt;&lt;T1) and a small flip angle.</p>\n<br><code>nonparametric</code>", "unit": "arbitrary"}, {"entities": {"subject": {"name": "sub", "display_name": "Subject", "description": "<p>A person or animal participating in the study.</p>", "type": "string", "format": "label", "required": "required"}, "session": {"name": "ses", "display_name": "Session", "description": "<p>A logical grouping of neuroimaging and behavioral data consistent across subjects.\nSession can (but doesn't have to) be synonymous to a visit in a longitudinal study.\nIn general, subjects will stay in the scanner during one session.\nHowever, for example, if a subject has to leave the scanner room and then\nbe re-positioned on the scanner bed, the set of MRI acquisitions will still\nbe considered as a session and match sessions acquired in other subjects.\nSimilarly, in situations where different data types are obtained over\nseveral visits (for example fMRI on one day followed by DWI the day after)\nthose can be grouped in one session.</p>\n<p>Defining multiple sessions is appropriate when several identical or similar\ndata acquisitions are planned and performed on all -or most- subjects,\noften in the case of some intervention between sessions\n(for example, training).</p>", "type": "string", "format": "label", "required": "optional"}, "task": {"name": "task", "display_name": "Task", "description": "<p>A set of structured activities performed by the participant.\nTasks are usually accompanied by stimuli and responses, and can greatly vary in complexity.</p>\n<p>In the context of brain scanning, a task is always tied to one data acquisition.\nTherefore, even if during one acquisition the subject performed multiple conceptually different behaviors\n(with different sets of instructions) they will be considered one (combined) task.</p>\n<p>While tasks may be repeated across multiple acquisitions,\na given task may have different sets of stimuli (for example, randomized order) and participant responses\nacross subjects, sessions, and runs.</p>\n<p>The <code>task-&lt;label&gt;</code> MUST be consistent across subjects and sessions.</p>\n<p>Files with the <code>task-&lt;label&gt;</code> entity SHOULD have an associated\n<a href=\"SPEC_ROOT/modality-specific-files/task-events.md#task-events\">events file</a>,\nas well as certain metadata fields in the associated JSON file.</p>\n<p>For the purpose of this specification we consider the so-called \"resting state\" a task,\nalthough events files are not expected for resting state data.\nAdditionally, a common convention in the specification is to include the word \"rest\" in\nthe <code>task</code> label for resting state files (for example, <code>task-rest</code>).</p>", "type": "string", "format": "label", "required": "optional"}, "acquisition": {"name": "acq", "display_name": "Acquisition", "description": "<p>The <code>acq-&lt;label&gt;</code> entity corresponds to a custom label the user MAY use to distinguish\na different set of parameters used for acquiring the same modality.</p>\n<p>For example, this should be used when a study includes two T1w images -\none full brain low resolution and one restricted field of view but high resolution.\nIn such case two files could have the following names:\n<code>sub-01_acq-highres_T1w.nii.gz</code> and <code>sub-01_acq-lowres_T1w.nii.gz</code>;\nhowever, the user is free to choose any other label than <code>highres</code> and <code>lowres</code> as long\nas they are consistent across subjects and sessions.</p>\n<p>In case different sequences are used to record the same modality\n(for example, <code>RARE</code> and <code>FLASH</code> for T1w)\nthis field can also be used to make that distinction.\nThe level of detail at which the distinction is made\n(for example, just between <code>RARE</code> and <code>FLASH</code>, or between <code>RARE</code>, <code>FLASH</code>, and <code>FLASHsubsampled</code>)\nremains at the discretion of the researcher.</p>", "type": "string", "format": "label", "required": "optional"}, "ceagent": {"name": "ce", "display_name": "Contrast Enhancing Agent", "description": "<p>The <code>ce-&lt;label&gt;</code> entity can be used to distinguish sequences using different contrast enhanced images.\nThe label is the name of the contrast agent.</p>\n<p>This entity represents the <code>\"ContrastBolusIngredient\"</code> metadata field.\nTherefore, if the <code>ce-&lt;label&gt;</code> entity is present in a filename,\n<code>\"ContrastBolusIngredient\"</code> MAY also be added in the JSON file, with the same label.</p>", "type": "string", "format": "label", "required": "optional"}, "reconstruction": {"name": "rec", "display_name": "Reconstruction", "description": "<p>The <code>rec-&lt;label&gt;</code> entity can be used to distinguish different reconstruction algorithms\n(for example, <code>MoCo</code> for the ones using motion correction).</p>", "type": "string", "format": "label", "required": "optional"}, "run": {"name": "run", "display_name": "Run", "description": "<p>The <code>run-&lt;index&gt;</code> entity is used to distinguish separate data acquisitions with the same acquisition parameters\nand (other) entities.</p>\n<p>If several data acquisitions (for example, MRI scans or EEG recordings)\nwith the same acquisition parameters are acquired in the same session,\nthey MUST be indexed with the <a href=\"SPEC_ROOT/appendices/entities.md#run\"><code>run-&lt;index&gt;</code></a> entity:\n<code>_run-1</code>, <code>_run-2</code>, <code>_run-3</code>, and so on\n(only nonnegative integers are allowed as run indices).</p>\n<p>If different entities apply,\nsuch as a different session indicated by [<code>ses-&lt;label&gt;</code>][SPEC_ROOT/appendices/entities.md#ses),\nor different acquisition parameters indicated by\n<a href=\"SPEC_ROOT/appendices/entities.md#acq\"><code>acq-&lt;label&gt;</code></a>,\nthen <code>run</code> is not needed to distinguish the scans and MAY be omitted.</p>", "type": "string", "format": "index", "required": "optional"}, "echo": {"name": "echo", "display_name": "Echo", "description": "<p>If files belonging to an entity-linked file collection are acquired at different\necho times, the <code>echo-&lt;index&gt;</code> entity MUST be used to distinguish individual files.</p>\n<p>This entity represents the <code>\"EchoTime\"</code> metadata field.\nTherefore, if the <code>echo-&lt;index&gt;</code> entity is present in a filename,\n<code>\"EchoTime\"</code> MUST be defined in the associated metadata.\nPlease note that the <code>&lt;index&gt;</code> denotes the number/index (in the form of a nonnegative integer),\nnot the <code>\"EchoTime\"</code> value of the separate JSON file.</p>", "type": "string", "format": "index", "required": "optional"}, "part": {"name": "part", "display_name": "Part", "description": "<p>This entity is used to indicate which component of the complex\nrepresentation of the MRI signal is represented in voxel data.\nThe <code>part-&lt;label&gt;</code> entity is associated with the DICOM Tag\n<code>0008, 9208</code>.\nAllowed label values for this entity are <code>phase</code>, <code>mag</code>, <code>real</code> and <code>imag</code>,\nwhich are typically used in <code>part-mag</code>/<code>part-phase</code> or\n<code>part-real</code>/<code>part-imag</code> pairs of files.</p>\n<p>Phase images MAY be in radians or in arbitrary units.\nThe sidecar JSON file MUST include the <code>\"Units\"</code> of the <code>phase</code> image.\nThe possible options are <code>\"rad\"</code> or <code>\"arbitrary\"</code>.</p>\n<p>When there is only a magnitude image of a given type, the <code>part</code> entity MAY be\nomitted.</p>", "type": "string", "format": "label", "enum": ["mag", "phase", "real", "imag"], "required": "optional"}, "chunk": {"name": "chunk", "display_name": "Chunk", "description": "<p>The <code>chunk-&lt;index&gt;</code> key/value pair is used to distinguish between images of\nthe same physical sample with different fields of view acquired in the same\nimaging experiment.\nThis entity applies to collections of 2D images, 3D volumes or 4D volume series\n(for example, diffusion weighted images), and may be used to indicate different\nanatomical structures or regions of the same structure.</p>", "type": "string", "format": "index", "required": "optional"}}, "value": "T2starw", "display_name": "T2star weighted image", "description": "<p>In arbitrary units (arbitrary).\nThe contrast of these images is mainly determined by spatial variations in\nthe (observed) transverse relaxation time of the imaged specimen.\nIn spin-echo sequences, this effect is negated as the excitation is followed\nby an inversion pulse.\nThe contrast of gradient-echo images natively depends on T2-star effects.\nHowever, for T2-star variation to dominate the image contrast,\ngradient-echo acquisitions are carried out at long repetition and echo times,\nand at small flip angles.</p>\n<br><code>nonparametric</code>", "unit": "arbitrary"}, {"entities": {"subject": {"name": "sub", "display_name": "Subject", "description": "<p>A person or animal participating in the study.</p>", "type": "string", "format": "label", "required": "required"}, "session": {"name": "ses", "display_name": "Session", "description": "<p>A logical grouping of neuroimaging and behavioral data consistent across subjects.\nSession can (but doesn't have to) be synonymous to a visit in a longitudinal study.\nIn general, subjects will stay in the scanner during one session.\nHowever, for example, if a subject has to leave the scanner room and then\nbe re-positioned on the scanner bed, the set of MRI acquisitions will still\nbe considered as a session and match sessions acquired in other subjects.\nSimilarly, in situations where different data types are obtained over\nseveral visits (for example fMRI on one day followed by DWI the day after)\nthose can be grouped in one session.</p>\n<p>Defining multiple sessions is appropriate when several identical or similar\ndata acquisitions are planned and performed on all -or most- subjects,\noften in the case of some intervention between sessions\n(for example, training).</p>", "type": "string", "format": "label", "required": "optional"}, "task": {"name": "task", "display_name": "Task", "description": "<p>A set of structured activities performed by the participant.\nTasks are usually accompanied by stimuli and responses, and can greatly vary in complexity.</p>\n<p>In the context of brain scanning, a task is always tied to one data acquisition.\nTherefore, even if during one acquisition the subject performed multiple conceptually different behaviors\n(with different sets of instructions) they will be considered one (combined) task.</p>\n<p>While tasks may be repeated across multiple acquisitions,\na given task may have different sets of stimuli (for example, randomized order) and participant responses\nacross subjects, sessions, and runs.</p>\n<p>The <code>task-&lt;label&gt;</code> MUST be consistent across subjects and sessions.</p>\n<p>Files with the <code>task-&lt;label&gt;</code> entity SHOULD have an associated\n<a href=\"SPEC_ROOT/modality-specific-files/task-events.md#task-events\">events file</a>,\nas well as certain metadata fields in the associated JSON file.</p>\n<p>For the purpose of this specification we consider the so-called \"resting state\" a task,\nalthough events files are not expected for resting state data.\nAdditionally, a common convention in the specification is to include the word \"rest\" in\nthe <code>task</code> label for resting state files (for example, <code>task-rest</code>).</p>", "type": "string", "format": "label", "required": "optional"}, "acquisition": {"name": "acq", "display_name": "Acquisition", "description": "<p>The <code>acq-&lt;label&gt;</code> entity corresponds to a custom label the user MAY use to distinguish\na different set of parameters used for acquiring the same modality.</p>\n<p>For example, this should be used when a study includes two T1w images -\none full brain low resolution and one restricted field of view but high resolution.\nIn such case two files could have the following names:\n<code>sub-01_acq-highres_T1w.nii.gz</code> and <code>sub-01_acq-lowres_T1w.nii.gz</code>;\nhowever, the user is free to choose any other label than <code>highres</code> and <code>lowres</code> as long\nas they are consistent across subjects and sessions.</p>\n<p>In case different sequences are used to record the same modality\n(for example, <code>RARE</code> and <code>FLASH</code> for T1w)\nthis field can also be used to make that distinction.\nThe level of detail at which the distinction is made\n(for example, just between <code>RARE</code> and <code>FLASH</code>, or between <code>RARE</code>, <code>FLASH</code>, and <code>FLASHsubsampled</code>)\nremains at the discretion of the researcher.</p>", "type": "string", "format": "label", "required": "optional"}, "ceagent": {"name": "ce", "display_name": "Contrast Enhancing Agent", "description": "<p>The <code>ce-&lt;label&gt;</code> entity can be used to distinguish sequences using different contrast enhanced images.\nThe label is the name of the contrast agent.</p>\n<p>This entity represents the <code>\"ContrastBolusIngredient\"</code> metadata field.\nTherefore, if the <code>ce-&lt;label&gt;</code> entity is present in a filename,\n<code>\"ContrastBolusIngredient\"</code> MAY also be added in the JSON file, with the same label.</p>", "type": "string", "format": "label", "required": "optional"}, "reconstruction": {"name": "rec", "display_name": "Reconstruction", "description": "<p>The <code>rec-&lt;label&gt;</code> entity can be used to distinguish different reconstruction algorithms\n(for example, <code>MoCo</code> for the ones using motion correction).</p>", "type": "string", "format": "label", "required": "optional"}, "run": {"name": "run", "display_name": "Run", "description": "<p>The <code>run-&lt;index&gt;</code> entity is used to distinguish separate data acquisitions with the same acquisition parameters\nand (other) entities.</p>\n<p>If several data acquisitions (for example, MRI scans or EEG recordings)\nwith the same acquisition parameters are acquired in the same session,\nthey MUST be indexed with the <a href=\"SPEC_ROOT/appendices/entities.md#run\"><code>run-&lt;index&gt;</code></a> entity:\n<code>_run-1</code>, <code>_run-2</code>, <code>_run-3</code>, and so on\n(only nonnegative integers are allowed as run indices).</p>\n<p>If different entities apply,\nsuch as a different session indicated by [<code>ses-&lt;label&gt;</code>][SPEC_ROOT/appendices/entities.md#ses),\nor different acquisition parameters indicated by\n<a href=\"SPEC_ROOT/appendices/entities.md#acq\"><code>acq-&lt;label&gt;</code></a>,\nthen <code>run</code> is not needed to distinguish the scans and MAY be omitted.</p>", "type": "string", "format": "index", "required": "optional"}, "echo": {"name": "echo", "display_name": "Echo", "description": "<p>If files belonging to an entity-linked file collection are acquired at different\necho times, the <code>echo-&lt;index&gt;</code> entity MUST be used to distinguish individual files.</p>\n<p>This entity represents the <code>\"EchoTime\"</code> metadata field.\nTherefore, if the <code>echo-&lt;index&gt;</code> entity is present in a filename,\n<code>\"EchoTime\"</code> MUST be defined in the associated metadata.\nPlease note that the <code>&lt;index&gt;</code> denotes the number/index (in the form of a nonnegative integer),\nnot the <code>\"EchoTime\"</code> value of the separate JSON file.</p>", "type": "string", "format": "index", "required": "optional"}, "part": {"name": "part", "display_name": "Part", "description": "<p>This entity is used to indicate which component of the complex\nrepresentation of the MRI signal is represented in voxel data.\nThe <code>part-&lt;label&gt;</code> entity is associated with the DICOM Tag\n<code>0008, 9208</code>.\nAllowed label values for this entity are <code>phase</code>, <code>mag</code>, <code>real</code> and <code>imag</code>,\nwhich are typically used in <code>part-mag</code>/<code>part-phase</code> or\n<code>part-real</code>/<code>part-imag</code> pairs of files.</p>\n<p>Phase images MAY be in radians or in arbitrary units.\nThe sidecar JSON file MUST include the <code>\"Units\"</code> of the <code>phase</code> image.\nThe possible options are <code>\"rad\"</code> or <code>\"arbitrary\"</code>.</p>\n<p>When there is only a magnitude image of a given type, the <code>part</code> entity MAY be\nomitted.</p>", "type": "string", "format": "label", "enum": ["mag", "phase", "real", "imag"], "required": "optional"}, "chunk": {"name": "chunk", "display_name": "Chunk", "description": "<p>The <code>chunk-&lt;index&gt;</code> key/value pair is used to distinguish between images of\nthe same physical sample with different fields of view acquired in the same\nimaging experiment.\nThis entity applies to collections of 2D images, 3D volumes or 4D volume series\n(for example, diffusion weighted images), and may be used to indicate different\nanatomical structures or regions of the same structure.</p>", "type": "string", "format": "index", "required": "optional"}}, "value": "FLAIR", "display_name": "Fluid attenuated inversion recovery image", "description": "<p>In arbitrary units (arbitrary).\nStructural images with predominant T2 contribution (also known as T2-FLAIR),\nin which signal from fluids (for example, CSF) is nulled out by adjusting\ninversion time, coupled with notably long repetition and echo times.</p>\n<br><code>nonparametric</code>", "unit": "arbitrary"}, {"entities": {"subject": {"name": "sub", "display_name": "Subject", "description": "<p>A person or animal participating in the study.</p>", "type": "string", "format": "label", "required": "required"}, "session": {"name": "ses", "display_name": "Session", "description": "<p>A logical grouping of neuroimaging and behavioral data consistent across subjects.\nSession can (but doesn't have to) be synonymous to a visit in a longitudinal study.\nIn general, subjects will stay in the scanner during one session.\nHowever, for example, if a subject has to leave the scanner room and then\nbe re-positioned on the scanner bed, the set of MRI acquisitions will still\nbe considered as a session and match sessions acquired in other subjects.\nSimilarly, in situations where different data types are obtained over\nseveral visits (for example fMRI on one day followed by DWI the day after)\nthose can be grouped in one session.</p>\n<p>Defining multiple sessions is appropriate when several identical or similar\ndata acquisitions are planned and performed on all -or most- subjects,\noften in the case of some intervention between sessions\n(for example, training).</p>", "type": "string", "format": "label", "required": "optional"}, "task": {"name": "task", "display_name": "Task", "description": "<p>A set of structured activities performed by the participant.\nTasks are usually accompanied by stimuli and responses, and can greatly vary in complexity.</p>\n<p>In the context of brain scanning, a task is always tied to one data acquisition.\nTherefore, even if during one acquisition the subject performed multiple conceptually different behaviors\n(with different sets of instructions) they will be considered one (combined) task.</p>\n<p>While tasks may be repeated across multiple acquisitions,\na given task may have different sets of stimuli (for example, randomized order) and participant responses\nacross subjects, sessions, and runs.</p>\n<p>The <code>task-&lt;label&gt;</code> MUST be consistent across subjects and sessions.</p>\n<p>Files with the <code>task-&lt;label&gt;</code> entity SHOULD have an associated\n<a href=\"SPEC_ROOT/modality-specific-files/task-events.md#task-events\">events file</a>,\nas well as certain metadata fields in the associated JSON file.</p>\n<p>For the purpose of this specification we consider the so-called \"resting state\" a task,\nalthough events files are not expected for resting state data.\nAdditionally, a common convention in the specification is to include the word \"rest\" in\nthe <code>task</code> label for resting state files (for example, <code>task-rest</code>).</p>", "type": "string", "format": "label", "required": "optional"}, "acquisition": {"name": "acq", "display_name": "Acquisition", "description": "<p>The <code>acq-&lt;label&gt;</code> entity corresponds to a custom label the user MAY use to distinguish\na different set of parameters used for acquiring the same modality.</p>\n<p>For example, this should be used when a study includes two T1w images -\none full brain low resolution and one restricted field of view but high resolution.\nIn such case two files could have the following names:\n<code>sub-01_acq-highres_T1w.nii.gz</code> and <code>sub-01_acq-lowres_T1w.nii.gz</code>;\nhowever, the user is free to choose any other label than <code>highres</code> and <code>lowres</code> as long\nas they are consistent across subjects and sessions.</p>\n<p>In case different sequences are used to record the same modality\n(for example, <code>RARE</code> and <code>FLASH</code> for T1w)\nthis field can also be used to make that distinction.\nThe level of detail at which the distinction is made\n(for example, just between <code>RARE</code> and <code>FLASH</code>, or between <code>RARE</code>, <code>FLASH</code>, and <code>FLASHsubsampled</code>)\nremains at the discretion of the researcher.</p>", "type": "string", "format": "label", "required": "optional"}, "ceagent": {"name": "ce", "display_name": "Contrast Enhancing Agent", "description": "<p>The <code>ce-&lt;label&gt;</code> entity can be used to distinguish sequences using different contrast enhanced images.\nThe label is the name of the contrast agent.</p>\n<p>This entity represents the <code>\"ContrastBolusIngredient\"</code> metadata field.\nTherefore, if the <code>ce-&lt;label&gt;</code> entity is present in a filename,\n<code>\"ContrastBolusIngredient\"</code> MAY also be added in the JSON file, with the same label.</p>", "type": "string", "format": "label", "required": "optional"}, "reconstruction": {"name": "rec", "display_name": "Reconstruction", "description": "<p>The <code>rec-&lt;label&gt;</code> entity can be used to distinguish different reconstruction algorithms\n(for example, <code>MoCo</code> for the ones using motion correction).</p>", "type": "string", "format": "label", "required": "optional"}, "run": {"name": "run", "display_name": "Run", "description": "<p>The <code>run-&lt;index&gt;</code> entity is used to distinguish separate data acquisitions with the same acquisition parameters\nand (other) entities.</p>\n<p>If several data acquisitions (for example, MRI scans or EEG recordings)\nwith the same acquisition parameters are acquired in the same session,\nthey MUST be indexed with the <a href=\"SPEC_ROOT/appendices/entities.md#run\"><code>run-&lt;index&gt;</code></a> entity:\n<code>_run-1</code>, <code>_run-2</code>, <code>_run-3</code>, and so on\n(only nonnegative integers are allowed as run indices).</p>\n<p>If different entities apply,\nsuch as a different session indicated by [<code>ses-&lt;label&gt;</code>][SPEC_ROOT/appendices/entities.md#ses),\nor different acquisition parameters indicated by\n<a href=\"SPEC_ROOT/appendices/entities.md#acq\"><code>acq-&lt;label&gt;</code></a>,\nthen <code>run</code> is not needed to distinguish the scans and MAY be omitted.</p>", "type": "string", "format": "index", "required": "optional"}, "echo": {"name": "echo", "display_name": "Echo", "description": "<p>If files belonging to an entity-linked file collection are acquired at different\necho times, the <code>echo-&lt;index&gt;</code> entity MUST be used to distinguish individual files.</p>\n<p>This entity represents the <code>\"EchoTime\"</code> metadata field.\nTherefore, if the <code>echo-&lt;index&gt;</code> entity is present in a filename,\n<code>\"EchoTime\"</code> MUST be defined in the associated metadata.\nPlease note that the <code>&lt;index&gt;</code> denotes the number/index (in the form of a nonnegative integer),\nnot the <code>\"EchoTime\"</code> value of the separate JSON file.</p>", "type": "string", "format": "index", "required": "optional"}, "part": {"name": "part", "display_name": "Part", "description": "<p>This entity is used to indicate which component of the complex\nrepresentation of the MRI signal is represented in voxel data.\nThe <code>part-&lt;label&gt;</code> entity is associated with the DICOM Tag\n<code>0008, 9208</code>.\nAllowed label values for this entity are <code>phase</code>, <code>mag</code>, <code>real</code> and <code>imag</code>,\nwhich are typically used in <code>part-mag</code>/<code>part-phase</code> or\n<code>part-real</code>/<code>part-imag</code> pairs of files.</p>\n<p>Phase images MAY be in radians or in arbitrary units.\nThe sidecar JSON file MUST include the <code>\"Units\"</code> of the <code>phase</code> image.\nThe possible options are <code>\"rad\"</code> or <code>\"arbitrary\"</code>.</p>\n<p>When there is only a magnitude image of a given type, the <code>part</code> entity MAY be\nomitted.</p>", "type": "string", "format": "label", "enum": ["mag", "phase", "real", "imag"], "required": "optional"}, "chunk": {"name": "chunk", "display_name": "Chunk", "description": "<p>The <code>chunk-&lt;index&gt;</code> key/value pair is used to distinguish between images of\nthe same physical sample with different fields of view acquired in the same\nimaging experiment.\nThis entity applies to collections of 2D images, 3D volumes or 4D volume series\n(for example, diffusion weighted images), and may be used to indicate different\nanatomical structures or regions of the same structure.</p>", "type": "string", "format": "index", "required": "optional"}}, "value": "inplaneT1", "display_name": "Inplane T1", "description": "<p>In arbitrary units (arbitrary).\nT1 weighted structural image matched to a functional (task) image.</p>\n<br><code>nonparametric</code>", "unit": "arbitrary"}, {"entities": {"subject": {"name": "sub", "display_name": "Subject", "description": "<p>A person or animal participating in the study.</p>", "type": "string", "format": "label", "required": "required"}, "session": {"name": "ses", "display_name": "Session", "description": "<p>A logical grouping of neuroimaging and behavioral data consistent across subjects.\nSession can (but doesn't have to) be synonymous to a visit in a longitudinal study.\nIn general, subjects will stay in the scanner during one session.\nHowever, for example, if a subject has to leave the scanner room and then\nbe re-positioned on the scanner bed, the set of MRI acquisitions will still\nbe considered as a session and match sessions acquired in other subjects.\nSimilarly, in situations where different data types are obtained over\nseveral visits (for example fMRI on one day followed by DWI the day after)\nthose can be grouped in one session.</p>\n<p>Defining multiple sessions is appropriate when several identical or similar\ndata acquisitions are planned and performed on all -or most- subjects,\noften in the case of some intervention between sessions\n(for example, training).</p>", "type": "string", "format": "label", "required": "optional"}, "task": {"name": "task", "display_name": "Task", "description": "<p>A set of structured activities performed by the participant.\nTasks are usually accompanied by stimuli and responses, and can greatly vary in complexity.</p>\n<p>In the context of brain scanning, a task is always tied to one data acquisition.\nTherefore, even if during one acquisition the subject performed multiple conceptually different behaviors\n(with different sets of instructions) they will be considered one (combined) task.</p>\n<p>While tasks may be repeated across multiple acquisitions,\na given task may have different sets of stimuli (for example, randomized order) and participant responses\nacross subjects, sessions, and runs.</p>\n<p>The <code>task-&lt;label&gt;</code> MUST be consistent across subjects and sessions.</p>\n<p>Files with the <code>task-&lt;label&gt;</code> entity SHOULD have an associated\n<a href=\"SPEC_ROOT/modality-specific-files/task-events.md#task-events\">events file</a>,\nas well as certain metadata fields in the associated JSON file.</p>\n<p>For the purpose of this specification we consider the so-called \"resting state\" a task,\nalthough events files are not expected for resting state data.\nAdditionally, a common convention in the specification is to include the word \"rest\" in\nthe <code>task</code> label for resting state files (for example, <code>task-rest</code>).</p>", "type": "string", "format": "label", "required": "optional"}, "acquisition": {"name": "acq", "display_name": "Acquisition", "description": "<p>The <code>acq-&lt;label&gt;</code> entity corresponds to a custom label the user MAY use to distinguish\na different set of parameters used for acquiring the same modality.</p>\n<p>For example, this should be used when a study includes two T1w images -\none full brain low resolution and one restricted field of view but high resolution.\nIn such case two files could have the following names:\n<code>sub-01_acq-highres_T1w.nii.gz</code> and <code>sub-01_acq-lowres_T1w.nii.gz</code>;\nhowever, the user is free to choose any other label than <code>highres</code> and <code>lowres</code> as long\nas they are consistent across subjects and sessions.</p>\n<p>In case different sequences are used to record the same modality\n(for example, <code>RARE</code> and <code>FLASH</code> for T1w)\nthis field can also be used to make that distinction.\nThe level of detail at which the distinction is made\n(for example, just between <code>RARE</code> and <code>FLASH</code>, or between <code>RARE</code>, <code>FLASH</code>, and <code>FLASHsubsampled</code>)\nremains at the discretion of the researcher.</p>", "type": "string", "format": "label", "required": "optional"}, "ceagent": {"name": "ce", "display_name": "Contrast Enhancing Agent", "description": "<p>The <code>ce-&lt;label&gt;</code> entity can be used to distinguish sequences using different contrast enhanced images.\nThe label is the name of the contrast agent.</p>\n<p>This entity represents the <code>\"ContrastBolusIngredient\"</code> metadata field.\nTherefore, if the <code>ce-&lt;label&gt;</code> entity is present in a filename,\n<code>\"ContrastBolusIngredient\"</code> MAY also be added in the JSON file, with the same label.</p>", "type": "string", "format": "label", "required": "optional"}, "reconstruction": {"name": "rec", "display_name": "Reconstruction", "description": "<p>The <code>rec-&lt;label&gt;</code> entity can be used to distinguish different reconstruction algorithms\n(for example, <code>MoCo</code> for the ones using motion correction).</p>", "type": "string", "format": "label", "required": "optional"}, "run": {"name": "run", "display_name": "Run", "description": "<p>The <code>run-&lt;index&gt;</code> entity is used to distinguish separate data acquisitions with the same acquisition parameters\nand (other) entities.</p>\n<p>If several data acquisitions (for example, MRI scans or EEG recordings)\nwith the same acquisition parameters are acquired in the same session,\nthey MUST be indexed with the <a href=\"SPEC_ROOT/appendices/entities.md#run\"><code>run-&lt;index&gt;</code></a> entity:\n<code>_run-1</code>, <code>_run-2</code>, <code>_run-3</code>, and so on\n(only nonnegative integers are allowed as run indices).</p>\n<p>If different entities apply,\nsuch as a different session indicated by [<code>ses-&lt;label&gt;</code>][SPEC_ROOT/appendices/entities.md#ses),\nor different acquisition parameters indicated by\n<a href=\"SPEC_ROOT/appendices/entities.md#acq\"><code>acq-&lt;label&gt;</code></a>,\nthen <code>run</code> is not needed to distinguish the scans and MAY be omitted.</p>", "type": "string", "format": "index", "required": "optional"}, "echo": {"name": "echo", "display_name": "Echo", "description": "<p>If files belonging to an entity-linked file collection are acquired at different\necho times, the <code>echo-&lt;index&gt;</code> entity MUST be used to distinguish individual files.</p>\n<p>This entity represents the <code>\"EchoTime\"</code> metadata field.\nTherefore, if the <code>echo-&lt;index&gt;</code> entity is present in a filename,\n<code>\"EchoTime\"</code> MUST be defined in the associated metadata.\nPlease note that the <code>&lt;index&gt;</code> denotes the number/index (in the form of a nonnegative integer),\nnot the <code>\"EchoTime\"</code> value of the separate JSON file.</p>", "type": "string", "format": "index", "required": "optional"}, "part": {"name": "part", "display_name": "Part", "description": "<p>This entity is used to indicate which component of the complex\nrepresentation of the MRI signal is represented in voxel data.\nThe <code>part-&lt;label&gt;</code> entity is associated with the DICOM Tag\n<code>0008, 9208</code>.\nAllowed label values for this entity are <code>phase</code>, <code>mag</code>, <code>real</code> and <code>imag</code>,\nwhich are typically used in <code>part-mag</code>/<code>part-phase</code> or\n<code>part-real</code>/<code>part-imag</code> pairs of files.</p>\n<p>Phase images MAY be in radians or in arbitrary units.\nThe sidecar JSON file MUST include the <code>\"Units\"</code> of the <code>phase</code> image.\nThe possible options are <code>\"rad\"</code> or <code>\"arbitrary\"</code>.</p>\n<p>When there is only a magnitude image of a given type, the <code>part</code> entity MAY be\nomitted.</p>", "type": "string", "format": "label", "enum": ["mag", "phase", "real", "imag"], "required": "optional"}, "chunk": {"name": "chunk", "display_name": "Chunk", "description": "<p>The <code>chunk-&lt;index&gt;</code> key/value pair is used to distinguish between images of\nthe same physical sample with different fields of view acquired in the same\nimaging experiment.\nThis entity applies to collections of 2D images, 3D volumes or 4D volume series\n(for example, diffusion weighted images), and may be used to indicate different\nanatomical structures or regions of the same structure.</p>", "type": "string", "format": "index", "required": "optional"}}, "value": "inplaneT2", "display_name": "Inplane T2", "description": "<p>In arbitrary units (arbitrary).\nT2 weighted structural image matched to a functional (task) image.</p>\n<br><code>nonparametric</code>", "unit": "arbitrary"}, {"entities": {"subject": {"name": "sub", "display_name": "Subject", "description": "<p>A person or animal participating in the study.</p>", "type": "string", "format": "label", "required": "required"}, "session": {"name": "ses", "display_name": "Session", "description": "<p>A logical grouping of neuroimaging and behavioral data consistent across subjects.\nSession can (but doesn't have to) be synonymous to a visit in a longitudinal study.\nIn general, subjects will stay in the scanner during one session.\nHowever, for example, if a subject has to leave the scanner room and then\nbe re-positioned on the scanner bed, the set of MRI acquisitions will still\nbe considered as a session and match sessions acquired in other subjects.\nSimilarly, in situations where different data types are obtained over\nseveral visits (for example fMRI on one day followed by DWI the day after)\nthose can be grouped in one session.</p>\n<p>Defining multiple sessions is appropriate when several identical or similar\ndata acquisitions are planned and performed on all -or most- subjects,\noften in the case of some intervention between sessions\n(for example, training).</p>", "type": "string", "format": "label", "required": "optional"}, "task": {"name": "task", "display_name": "Task", "description": "<p>A set of structured activities performed by the participant.\nTasks are usually accompanied by stimuli and responses, and can greatly vary in complexity.</p>\n<p>In the context of brain scanning, a task is always tied to one data acquisition.\nTherefore, even if during one acquisition the subject performed multiple conceptually different behaviors\n(with different sets of instructions) they will be considered one (combined) task.</p>\n<p>While tasks may be repeated across multiple acquisitions,\na given task may have different sets of stimuli (for example, randomized order) and participant responses\nacross subjects, sessions, and runs.</p>\n<p>The <code>task-&lt;label&gt;</code> MUST be consistent across subjects and sessions.</p>\n<p>Files with the <code>task-&lt;label&gt;</code> entity SHOULD have an associated\n<a href=\"SPEC_ROOT/modality-specific-files/task-events.md#task-events\">events file</a>,\nas well as certain metadata fields in the associated JSON file.</p>\n<p>For the purpose of this specification we consider the so-called \"resting state\" a task,\nalthough events files are not expected for resting state data.\nAdditionally, a common convention in the specification is to include the word \"rest\" in\nthe <code>task</code> label for resting state files (for example, <code>task-rest</code>).</p>", "type": "string", "format": "label", "required": "optional"}, "acquisition": {"name": "acq", "display_name": "Acquisition", "description": "<p>The <code>acq-&lt;label&gt;</code> entity corresponds to a custom label the user MAY use to distinguish\na different set of parameters used for acquiring the same modality.</p>\n<p>For example, this should be used when a study includes two T1w images -\none full brain low resolution and one restricted field of view but high resolution.\nIn such case two files could have the following names:\n<code>sub-01_acq-highres_T1w.nii.gz</code> and <code>sub-01_acq-lowres_T1w.nii.gz</code>;\nhowever, the user is free to choose any other label than <code>highres</code> and <code>lowres</code> as long\nas they are consistent across subjects and sessions.</p>\n<p>In case different sequences are used to record the same modality\n(for example, <code>RARE</code> and <code>FLASH</code> for T1w)\nthis field can also be used to make that distinction.\nThe level of detail at which the distinction is made\n(for example, just between <code>RARE</code> and <code>FLASH</code>, or between <code>RARE</code>, <code>FLASH</code>, and <code>FLASHsubsampled</code>)\nremains at the discretion of the researcher.</p>", "type": "string", "format": "label", "required": "optional"}, "ceagent": {"name": "ce", "display_name": "Contrast Enhancing Agent", "description": "<p>The <code>ce-&lt;label&gt;</code> entity can be used to distinguish sequences using different contrast enhanced images.\nThe label is the name of the contrast agent.</p>\n<p>This entity represents the <code>\"ContrastBolusIngredient\"</code> metadata field.\nTherefore, if the <code>ce-&lt;label&gt;</code> entity is present in a filename,\n<code>\"ContrastBolusIngredient\"</code> MAY also be added in the JSON file, with the same label.</p>", "type": "string", "format": "label", "required": "optional"}, "reconstruction": {"name": "rec", "display_name": "Reconstruction", "description": "<p>The <code>rec-&lt;label&gt;</code> entity can be used to distinguish different reconstruction algorithms\n(for example, <code>MoCo</code> for the ones using motion correction).</p>", "type": "string", "format": "label", "required": "optional"}, "run": {"name": "run", "display_name": "Run", "description": "<p>The <code>run-&lt;index&gt;</code> entity is used to distinguish separate data acquisitions with the same acquisition parameters\nand (other) entities.</p>\n<p>If several data acquisitions (for example, MRI scans or EEG recordings)\nwith the same acquisition parameters are acquired in the same session,\nthey MUST be indexed with the <a href=\"SPEC_ROOT/appendices/entities.md#run\"><code>run-&lt;index&gt;</code></a> entity:\n<code>_run-1</code>, <code>_run-2</code>, <code>_run-3</code>, and so on\n(only nonnegative integers are allowed as run indices).</p>\n<p>If different entities apply,\nsuch as a different session indicated by [<code>ses-&lt;label&gt;</code>][SPEC_ROOT/appendices/entities.md#ses),\nor different acquisition parameters indicated by\n<a href=\"SPEC_ROOT/appendices/entities.md#acq\"><code>acq-&lt;label&gt;</code></a>,\nthen <code>run</code> is not needed to distinguish the scans and MAY be omitted.</p>", "type": "string", "format": "index", "required": "optional"}, "echo": {"name": "echo", "display_name": "Echo", "description": "<p>If files belonging to an entity-linked file collection are acquired at different\necho times, the <code>echo-&lt;index&gt;</code> entity MUST be used to distinguish individual files.</p>\n<p>This entity represents the <code>\"EchoTime\"</code> metadata field.\nTherefore, if the <code>echo-&lt;index&gt;</code> entity is present in a filename,\n<code>\"EchoTime\"</code> MUST be defined in the associated metadata.\nPlease note that the <code>&lt;index&gt;</code> denotes the number/index (in the form of a nonnegative integer),\nnot the <code>\"EchoTime\"</code> value of the separate JSON file.</p>", "type": "string", "format": "index", "required": "optional"}, "part": {"name": "part", "display_name": "Part", "description": "<p>This entity is used to indicate which component of the complex\nrepresentation of the MRI signal is represented in voxel data.\nThe <code>part-&lt;label&gt;</code> entity is associated with the DICOM Tag\n<code>0008, 9208</code>.\nAllowed label values for this entity are <code>phase</code>, <code>mag</code>, <code>real</code> and <code>imag</code>,\nwhich are typically used in <code>part-mag</code>/<code>part-phase</code> or\n<code>part-real</code>/<code>part-imag</code> pairs of files.</p>\n<p>Phase images MAY be in radians or in arbitrary units.\nThe sidecar JSON file MUST include the <code>\"Units\"</code> of the <code>phase</code> image.\nThe possible options are <code>\"rad\"</code> or <code>\"arbitrary\"</code>.</p>\n<p>When there is only a magnitude image of a given type, the <code>part</code> entity MAY be\nomitted.</p>", "type": "string", "format": "label", "enum": ["mag", "phase", "real", "imag"], "required": "optional"}, "chunk": {"name": "chunk", "display_name": "Chunk", "description": "<p>The <code>chunk-&lt;index&gt;</code> key/value pair is used to distinguish between images of\nthe same physical sample with different fields of view acquired in the same\nimaging experiment.\nThis entity applies to collections of 2D images, 3D volumes or 4D volume series\n(for example, diffusion weighted images), and may be used to indicate different\nanatomical structures or regions of the same structure.</p>", "type": "string", "format": "index", "required": "optional"}}, "value": "PDT2", "display_name": "PD and T2 weighted image", "description": "<p>In arbitrary units (arbitrary).\nA two-volume 4D image, where the volumes are, respectively, PDw and T2w\nimages acquired simultaneously.\nIf separated into 3D volumes, the <code>PDw</code> and <code>T2w</code> suffixes SHOULD be used instead,\nand an acquisition entity MAY be used to distinguish the images from others with\nthe same suffix, for example, <code>acq-PDT2_PDw.nii</code> and <code>acq-PDT2_T2w.nii</code>.</p>\n<br><code>nonparametric</code>", "unit": "arbitrary"}, {"entities": {"subject": {"name": "sub", "display_name": "Subject", "description": "<p>A person or animal participating in the study.</p>", "type": "string", "format": "label", "required": "required"}, "session": {"name": "ses", "display_name": "Session", "description": "<p>A logical grouping of neuroimaging and behavioral data consistent across subjects.\nSession can (but doesn't have to) be synonymous to a visit in a longitudinal study.\nIn general, subjects will stay in the scanner during one session.\nHowever, for example, if a subject has to leave the scanner room and then\nbe re-positioned on the scanner bed, the set of MRI acquisitions will still\nbe considered as a session and match sessions acquired in other subjects.\nSimilarly, in situations where different data types are obtained over\nseveral visits (for example fMRI on one day followed by DWI the day after)\nthose can be grouped in one session.</p>\n<p>Defining multiple sessions is appropriate when several identical or similar\ndata acquisitions are planned and performed on all -or most- subjects,\noften in the case of some intervention between sessions\n(for example, training).</p>", "type": "string", "format": "label", "required": "optional"}, "task": {"name": "task", "display_name": "Task", "description": "<p>A set of structured activities performed by the participant.\nTasks are usually accompanied by stimuli and responses, and can greatly vary in complexity.</p>\n<p>In the context of brain scanning, a task is always tied to one data acquisition.\nTherefore, even if during one acquisition the subject performed multiple conceptually different behaviors\n(with different sets of instructions) they will be considered one (combined) task.</p>\n<p>While tasks may be repeated across multiple acquisitions,\na given task may have different sets of stimuli (for example, randomized order) and participant responses\nacross subjects, sessions, and runs.</p>\n<p>The <code>task-&lt;label&gt;</code> MUST be consistent across subjects and sessions.</p>\n<p>Files with the <code>task-&lt;label&gt;</code> entity SHOULD have an associated\n<a href=\"SPEC_ROOT/modality-specific-files/task-events.md#task-events\">events file</a>,\nas well as certain metadata fields in the associated JSON file.</p>\n<p>For the purpose of this specification we consider the so-called \"resting state\" a task,\nalthough events files are not expected for resting state data.\nAdditionally, a common convention in the specification is to include the word \"rest\" in\nthe <code>task</code> label for resting state files (for example, <code>task-rest</code>).</p>", "type": "string", "format": "label", "required": "optional"}, "acquisition": {"name": "acq", "display_name": "Acquisition", "description": "<p>The <code>acq-&lt;label&gt;</code> entity corresponds to a custom label the user MAY use to distinguish\na different set of parameters used for acquiring the same modality.</p>\n<p>For example, this should be used when a study includes two T1w images -\none full brain low resolution and one restricted field of view but high resolution.\nIn such case two files could have the following names:\n<code>sub-01_acq-highres_T1w.nii.gz</code> and <code>sub-01_acq-lowres_T1w.nii.gz</code>;\nhowever, the user is free to choose any other label than <code>highres</code> and <code>lowres</code> as long\nas they are consistent across subjects and sessions.</p>\n<p>In case different sequences are used to record the same modality\n(for example, <code>RARE</code> and <code>FLASH</code> for T1w)\nthis field can also be used to make that distinction.\nThe level of detail at which the distinction is made\n(for example, just between <code>RARE</code> and <code>FLASH</code>, or between <code>RARE</code>, <code>FLASH</code>, and <code>FLASHsubsampled</code>)\nremains at the discretion of the researcher.</p>", "type": "string", "format": "label", "required": "optional"}, "ceagent": {"name": "ce", "display_name": "Contrast Enhancing Agent", "description": "<p>The <code>ce-&lt;label&gt;</code> entity can be used to distinguish sequences using different contrast enhanced images.\nThe label is the name of the contrast agent.</p>\n<p>This entity represents the <code>\"ContrastBolusIngredient\"</code> metadata field.\nTherefore, if the <code>ce-&lt;label&gt;</code> entity is present in a filename,\n<code>\"ContrastBolusIngredient\"</code> MAY also be added in the JSON file, with the same label.</p>", "type": "string", "format": "label", "required": "optional"}, "reconstruction": {"name": "rec", "display_name": "Reconstruction", "description": "<p>The <code>rec-&lt;label&gt;</code> entity can be used to distinguish different reconstruction algorithms\n(for example, <code>MoCo</code> for the ones using motion correction).</p>", "type": "string", "format": "label", "required": "optional"}, "run": {"name": "run", "display_name": "Run", "description": "<p>The <code>run-&lt;index&gt;</code> entity is used to distinguish separate data acquisitions with the same acquisition parameters\nand (other) entities.</p>\n<p>If several data acquisitions (for example, MRI scans or EEG recordings)\nwith the same acquisition parameters are acquired in the same session,\nthey MUST be indexed with the <a href=\"SPEC_ROOT/appendices/entities.md#run\"><code>run-&lt;index&gt;</code></a> entity:\n<code>_run-1</code>, <code>_run-2</code>, <code>_run-3</code>, and so on\n(only nonnegative integers are allowed as run indices).</p>\n<p>If different entities apply,\nsuch as a different session indicated by [<code>ses-&lt;label&gt;</code>][SPEC_ROOT/appendices/entities.md#ses),\nor different acquisition parameters indicated by\n<a href=\"SPEC_ROOT/appendices/entities.md#acq\"><code>acq-&lt;label&gt;</code></a>,\nthen <code>run</code> is not needed to distinguish the scans and MAY be omitted.</p>", "type": "string", "format": "index", "required": "optional"}, "echo": {"name": "echo", "display_name": "Echo", "description": "<p>If files belonging to an entity-linked file collection are acquired at different\necho times, the <code>echo-&lt;index&gt;</code> entity MUST be used to distinguish individual files.</p>\n<p>This entity represents the <code>\"EchoTime\"</code> metadata field.\nTherefore, if the <code>echo-&lt;index&gt;</code> entity is present in a filename,\n<code>\"EchoTime\"</code> MUST be defined in the associated metadata.\nPlease note that the <code>&lt;index&gt;</code> denotes the number/index (in the form of a nonnegative integer),\nnot the <code>\"EchoTime\"</code> value of the separate JSON file.</p>", "type": "string", "format": "index", "required": "optional"}, "part": {"name": "part", "display_name": "Part", "description": "<p>This entity is used to indicate which component of the complex\nrepresentation of the MRI signal is represented in voxel data.\nThe <code>part-&lt;label&gt;</code> entity is associated with the DICOM Tag\n<code>0008, 9208</code>.\nAllowed label values for this entity are <code>phase</code>, <code>mag</code>, <code>real</code> and <code>imag</code>,\nwhich are typically used in <code>part-mag</code>/<code>part-phase</code> or\n<code>part-real</code>/<code>part-imag</code> pairs of files.</p>\n<p>Phase images MAY be in radians or in arbitrary units.\nThe sidecar JSON file MUST include the <code>\"Units\"</code> of the <code>phase</code> image.\nThe possible options are <code>\"rad\"</code> or <code>\"arbitrary\"</code>.</p>\n<p>When there is only a magnitude image of a given type, the <code>part</code> entity MAY be\nomitted.</p>", "type": "string", "format": "label", "enum": ["mag", "phase", "real", "imag"], "required": "optional"}, "chunk": {"name": "chunk", "display_name": "Chunk", "description": "<p>The <code>chunk-&lt;index&gt;</code> key/value pair is used to distinguish between images of\nthe same physical sample with different fields of view acquired in the same\nimaging experiment.\nThis entity applies to collections of 2D images, 3D volumes or 4D volume series\n(for example, diffusion weighted images), and may be used to indicate different\nanatomical structures or regions of the same structure.</p>", "type": "string", "format": "index", "required": "optional"}}, "value": "angio", "display_name": "Angiogram", "description": "<p>Magnetic resonance angiography sequences focus on enhancing the contrast of\nblood vessels (generally arteries, but sometimes veins) against other tissue\ntypes.</p>\n<br><code>nonparametric</code>"}, {"entities": {"subject": {"name": "sub", "display_name": "Subject", "description": "<p>A person or animal participating in the study.</p>", "type": "string", "format": "label", "required": "required"}, "session": {"name": "ses", "display_name": "Session", "description": "<p>A logical grouping of neuroimaging and behavioral data consistent across subjects.\nSession can (but doesn't have to) be synonymous to a visit in a longitudinal study.\nIn general, subjects will stay in the scanner during one session.\nHowever, for example, if a subject has to leave the scanner room and then\nbe re-positioned on the scanner bed, the set of MRI acquisitions will still\nbe considered as a session and match sessions acquired in other subjects.\nSimilarly, in situations where different data types are obtained over\nseveral visits (for example fMRI on one day followed by DWI the day after)\nthose can be grouped in one session.</p>\n<p>Defining multiple sessions is appropriate when several identical or similar\ndata acquisitions are planned and performed on all -or most- subjects,\noften in the case of some intervention between sessions\n(for example, training).</p>", "type": "string", "format": "label", "required": "optional"}, "task": {"name": "task", "display_name": "Task", "description": "<p>A set of structured activities performed by the participant.\nTasks are usually accompanied by stimuli and responses, and can greatly vary in complexity.</p>\n<p>In the context of brain scanning, a task is always tied to one data acquisition.\nTherefore, even if during one acquisition the subject performed multiple conceptually different behaviors\n(with different sets of instructions) they will be considered one (combined) task.</p>\n<p>While tasks may be repeated across multiple acquisitions,\na given task may have different sets of stimuli (for example, randomized order) and participant responses\nacross subjects, sessions, and runs.</p>\n<p>The <code>task-&lt;label&gt;</code> MUST be consistent across subjects and sessions.</p>\n<p>Files with the <code>task-&lt;label&gt;</code> entity SHOULD have an associated\n<a href=\"SPEC_ROOT/modality-specific-files/task-events.md#task-events\">events file</a>,\nas well as certain metadata fields in the associated JSON file.</p>\n<p>For the purpose of this specification we consider the so-called \"resting state\" a task,\nalthough events files are not expected for resting state data.\nAdditionally, a common convention in the specification is to include the word \"rest\" in\nthe <code>task</code> label for resting state files (for example, <code>task-rest</code>).</p>", "type": "string", "format": "label", "required": "optional"}, "acquisition": {"name": "acq", "display_name": "Acquisition", "description": "<p>The <code>acq-&lt;label&gt;</code> entity corresponds to a custom label the user MAY use to distinguish\na different set of parameters used for acquiring the same modality.</p>\n<p>For example, this should be used when a study includes two T1w images -\none full brain low resolution and one restricted field of view but high resolution.\nIn such case two files could have the following names:\n<code>sub-01_acq-highres_T1w.nii.gz</code> and <code>sub-01_acq-lowres_T1w.nii.gz</code>;\nhowever, the user is free to choose any other label than <code>highres</code> and <code>lowres</code> as long\nas they are consistent across subjects and sessions.</p>\n<p>In case different sequences are used to record the same modality\n(for example, <code>RARE</code> and <code>FLASH</code> for T1w)\nthis field can also be used to make that distinction.\nThe level of detail at which the distinction is made\n(for example, just between <code>RARE</code> and <code>FLASH</code>, or between <code>RARE</code>, <code>FLASH</code>, and <code>FLASHsubsampled</code>)\nremains at the discretion of the researcher.</p>", "type": "string", "format": "label", "required": "optional"}, "ceagent": {"name": "ce", "display_name": "Contrast Enhancing Agent", "description": "<p>The <code>ce-&lt;label&gt;</code> entity can be used to distinguish sequences using different contrast enhanced images.\nThe label is the name of the contrast agent.</p>\n<p>This entity represents the <code>\"ContrastBolusIngredient\"</code> metadata field.\nTherefore, if the <code>ce-&lt;label&gt;</code> entity is present in a filename,\n<code>\"ContrastBolusIngredient\"</code> MAY also be added in the JSON file, with the same label.</p>", "type": "string", "format": "label", "required": "optional"}, "reconstruction": {"name": "rec", "display_name": "Reconstruction", "description": "<p>The <code>rec-&lt;label&gt;</code> entity can be used to distinguish different reconstruction algorithms\n(for example, <code>MoCo</code> for the ones using motion correction).</p>", "type": "string", "format": "label", "required": "optional"}, "run": {"name": "run", "display_name": "Run", "description": "<p>The <code>run-&lt;index&gt;</code> entity is used to distinguish separate data acquisitions with the same acquisition parameters\nand (other) entities.</p>\n<p>If several data acquisitions (for example, MRI scans or EEG recordings)\nwith the same acquisition parameters are acquired in the same session,\nthey MUST be indexed with the <a href=\"SPEC_ROOT/appendices/entities.md#run\"><code>run-&lt;index&gt;</code></a> entity:\n<code>_run-1</code>, <code>_run-2</code>, <code>_run-3</code>, and so on\n(only nonnegative integers are allowed as run indices).</p>\n<p>If different entities apply,\nsuch as a different session indicated by [<code>ses-&lt;label&gt;</code>][SPEC_ROOT/appendices/entities.md#ses),\nor different acquisition parameters indicated by\n<a href=\"SPEC_ROOT/appendices/entities.md#acq\"><code>acq-&lt;label&gt;</code></a>,\nthen <code>run</code> is not needed to distinguish the scans and MAY be omitted.</p>", "type": "string", "format": "index", "required": "optional"}, "echo": {"name": "echo", "display_name": "Echo", "description": "<p>If files belonging to an entity-linked file collection are acquired at different\necho times, the <code>echo-&lt;index&gt;</code> entity MUST be used to distinguish individual files.</p>\n<p>This entity represents the <code>\"EchoTime\"</code> metadata field.\nTherefore, if the <code>echo-&lt;index&gt;</code> entity is present in a filename,\n<code>\"EchoTime\"</code> MUST be defined in the associated metadata.\nPlease note that the <code>&lt;index&gt;</code> denotes the number/index (in the form of a nonnegative integer),\nnot the <code>\"EchoTime\"</code> value of the separate JSON file.</p>", "type": "string", "format": "index", "required": "optional"}, "part": {"name": "part", "display_name": "Part", "description": "<p>This entity is used to indicate which component of the complex\nrepresentation of the MRI signal is represented in voxel data.\nThe <code>part-&lt;label&gt;</code> entity is associated with the DICOM Tag\n<code>0008, 9208</code>.\nAllowed label values for this entity are <code>phase</code>, <code>mag</code>, <code>real</code> and <code>imag</code>,\nwhich are typically used in <code>part-mag</code>/<code>part-phase</code> or\n<code>part-real</code>/<code>part-imag</code> pairs of files.</p>\n<p>Phase images MAY be in radians or in arbitrary units.\nThe sidecar JSON file MUST include the <code>\"Units\"</code> of the <code>phase</code> image.\nThe possible options are <code>\"rad\"</code> or <code>\"arbitrary\"</code>.</p>\n<p>When there is only a magnitude image of a given type, the <code>part</code> entity MAY be\nomitted.</p>", "type": "string", "format": "label", "enum": ["mag", "phase", "real", "imag"], "required": "optional"}, "chunk": {"name": "chunk", "display_name": "Chunk", "description": "<p>The <code>chunk-&lt;index&gt;</code> key/value pair is used to distinguish between images of\nthe same physical sample with different fields of view acquired in the same\nimaging experiment.\nThis entity applies to collections of 2D images, 3D volumes or 4D volume series\n(for example, diffusion weighted images), and may be used to indicate different\nanatomical structures or regions of the same structure.</p>", "type": "string", "format": "index", "required": "optional"}}, "value": "T2star", "display_name": "T2\\* image", "description": "<p>Ambiguous, may refer to a parametric image or to a conventional image.\n<strong>Change:</strong> Replaced by <code>T2starw</code> or <code>T2starmap</code>.</p>\n<br><code>nonparametric</code>", "anyOf": [{"unit": "arbitrary"}, {"unit": "s"}]}, {"entities": {"subject": {"name": "sub", "display_name": "Subject", "description": "<p>A person or animal participating in the study.</p>", "type": "string", "format": "label", "required": "required"}, "session": {"name": "ses", "display_name": "Session", "description": "<p>A logical grouping of neuroimaging and behavioral data consistent across subjects.\nSession can (but doesn't have to) be synonymous to a visit in a longitudinal study.\nIn general, subjects will stay in the scanner during one session.\nHowever, for example, if a subject has to leave the scanner room and then\nbe re-positioned on the scanner bed, the set of MRI acquisitions will still\nbe considered as a session and match sessions acquired in other subjects.\nSimilarly, in situations where different data types are obtained over\nseveral visits (for example fMRI on one day followed by DWI the day after)\nthose can be grouped in one session.</p>\n<p>Defining multiple sessions is appropriate when several identical or similar\ndata acquisitions are planned and performed on all -or most- subjects,\noften in the case of some intervention between sessions\n(for example, training).</p>", "type": "string", "format": "label", "required": "optional"}, "task": {"name": "task", "display_name": "Task", "description": "<p>A set of structured activities performed by the participant.\nTasks are usually accompanied by stimuli and responses, and can greatly vary in complexity.</p>\n<p>In the context of brain scanning, a task is always tied to one data acquisition.\nTherefore, even if during one acquisition the subject performed multiple conceptually different behaviors\n(with different sets of instructions) they will be considered one (combined) task.</p>\n<p>While tasks may be repeated across multiple acquisitions,\na given task may have different sets of stimuli (for example, randomized order) and participant responses\nacross subjects, sessions, and runs.</p>\n<p>The <code>task-&lt;label&gt;</code> MUST be consistent across subjects and sessions.</p>\n<p>Files with the <code>task-&lt;label&gt;</code> entity SHOULD have an associated\n<a href=\"SPEC_ROOT/modality-specific-files/task-events.md#task-events\">events file</a>,\nas well as certain metadata fields in the associated JSON file.</p>\n<p>For the purpose of this specification we consider the so-called \"resting state\" a task,\nalthough events files are not expected for resting state data.\nAdditionally, a common convention in the specification is to include the word \"rest\" in\nthe <code>task</code> label for resting state files (for example, <code>task-rest</code>).</p>", "type": "string", "format": "label", "required": "optional"}, "acquisition": {"name": "acq", "display_name": "Acquisition", "description": "<p>The <code>acq-&lt;label&gt;</code> entity corresponds to a custom label the user MAY use to distinguish\na different set of parameters used for acquiring the same modality.</p>\n<p>For example, this should be used when a study includes two T1w images -\none full brain low resolution and one restricted field of view but high resolution.\nIn such case two files could have the following names:\n<code>sub-01_acq-highres_T1w.nii.gz</code> and <code>sub-01_acq-lowres_T1w.nii.gz</code>;\nhowever, the user is free to choose any other label than <code>highres</code> and <code>lowres</code> as long\nas they are consistent across subjects and sessions.</p>\n<p>In case different sequences are used to record the same modality\n(for example, <code>RARE</code> and <code>FLASH</code> for T1w)\nthis field can also be used to make that distinction.\nThe level of detail at which the distinction is made\n(for example, just between <code>RARE</code> and <code>FLASH</code>, or between <code>RARE</code>, <code>FLASH</code>, and <code>FLASHsubsampled</code>)\nremains at the discretion of the researcher.</p>", "type": "string", "format": "label", "required": "optional"}, "ceagent": {"name": "ce", "display_name": "Contrast Enhancing Agent", "description": "<p>The <code>ce-&lt;label&gt;</code> entity can be used to distinguish sequences using different contrast enhanced images.\nThe label is the name of the contrast agent.</p>\n<p>This entity represents the <code>\"ContrastBolusIngredient\"</code> metadata field.\nTherefore, if the <code>ce-&lt;label&gt;</code> entity is present in a filename,\n<code>\"ContrastBolusIngredient\"</code> MAY also be added in the JSON file, with the same label.</p>", "type": "string", "format": "label", "required": "optional"}, "reconstruction": {"name": "rec", "display_name": "Reconstruction", "description": "<p>The <code>rec-&lt;label&gt;</code> entity can be used to distinguish different reconstruction algorithms\n(for example, <code>MoCo</code> for the ones using motion correction).</p>", "type": "string", "format": "label", "required": "optional"}, "run": {"name": "run", "display_name": "Run", "description": "<p>The <code>run-&lt;index&gt;</code> entity is used to distinguish separate data acquisitions with the same acquisition parameters\nand (other) entities.</p>\n<p>If several data acquisitions (for example, MRI scans or EEG recordings)\nwith the same acquisition parameters are acquired in the same session,\nthey MUST be indexed with the <a href=\"SPEC_ROOT/appendices/entities.md#run\"><code>run-&lt;index&gt;</code></a> entity:\n<code>_run-1</code>, <code>_run-2</code>, <code>_run-3</code>, and so on\n(only nonnegative integers are allowed as run indices).</p>\n<p>If different entities apply,\nsuch as a different session indicated by [<code>ses-&lt;label&gt;</code>][SPEC_ROOT/appendices/entities.md#ses),\nor different acquisition parameters indicated by\n<a href=\"SPEC_ROOT/appendices/entities.md#acq\"><code>acq-&lt;label&gt;</code></a>,\nthen <code>run</code> is not needed to distinguish the scans and MAY be omitted.</p>", "type": "string", "format": "index", "required": "optional"}, "echo": {"name": "echo", "display_name": "Echo", "description": "<p>If files belonging to an entity-linked file collection are acquired at different\necho times, the <code>echo-&lt;index&gt;</code> entity MUST be used to distinguish individual files.</p>\n<p>This entity represents the <code>\"EchoTime\"</code> metadata field.\nTherefore, if the <code>echo-&lt;index&gt;</code> entity is present in a filename,\n<code>\"EchoTime\"</code> MUST be defined in the associated metadata.\nPlease note that the <code>&lt;index&gt;</code> denotes the number/index (in the form of a nonnegative integer),\nnot the <code>\"EchoTime\"</code> value of the separate JSON file.</p>", "type": "string", "format": "index", "required": "optional"}, "part": {"name": "part", "display_name": "Part", "description": "<p>This entity is used to indicate which component of the complex\nrepresentation of the MRI signal is represented in voxel data.\nThe <code>part-&lt;label&gt;</code> entity is associated with the DICOM Tag\n<code>0008, 9208</code>.\nAllowed label values for this entity are <code>phase</code>, <code>mag</code>, <code>real</code> and <code>imag</code>,\nwhich are typically used in <code>part-mag</code>/<code>part-phase</code> or\n<code>part-real</code>/<code>part-imag</code> pairs of files.</p>\n<p>Phase images MAY be in radians or in arbitrary units.\nThe sidecar JSON file MUST include the <code>\"Units\"</code> of the <code>phase</code> image.\nThe possible options are <code>\"rad\"</code> or <code>\"arbitrary\"</code>.</p>\n<p>When there is only a magnitude image of a given type, the <code>part</code> entity MAY be\nomitted.</p>", "type": "string", "format": "label", "enum": ["mag", "phase", "real", "imag"], "required": "optional"}, "chunk": {"name": "chunk", "display_name": "Chunk", "description": "<p>The <code>chunk-&lt;index&gt;</code> key/value pair is used to distinguish between images of\nthe same physical sample with different fields of view acquired in the same\nimaging experiment.\nThis entity applies to collections of 2D images, 3D volumes or 4D volume series\n(for example, diffusion weighted images), and may be used to indicate different\nanatomical structures or regions of the same structure.</p>", "type": "string", "format": "index", "required": "optional"}}, "value": "FLASH", "display_name": "Fast-Low-Angle-Shot image", "description": "<p>FLASH (Fast-Low-Angle-Shot) is a vendor-specific implementation for spoiled\ngradient echo acquisition.\nIt is commonly used for rapid anatomical imaging and also for many different\nqMRI applications.\nWhen used for a single file, it does not convey any information about the\nimage contrast.\nWhen used in a file collection, it may result in conflicts across filenames of\ndifferent applications.\n<strong>Change:</strong> Removed from suffixes.</p>\n<br><code>nonparametric</code>"}, {"entities": {"subject": {"name": "sub", "display_name": "Subject", "description": "<p>A person or animal participating in the study.</p>", "type": "string", "format": "label", "required": "required"}, "session": {"name": "ses", "display_name": "Session", "description": "<p>A logical grouping of neuroimaging and behavioral data consistent across subjects.\nSession can (but doesn't have to) be synonymous to a visit in a longitudinal study.\nIn general, subjects will stay in the scanner during one session.\nHowever, for example, if a subject has to leave the scanner room and then\nbe re-positioned on the scanner bed, the set of MRI acquisitions will still\nbe considered as a session and match sessions acquired in other subjects.\nSimilarly, in situations where different data types are obtained over\nseveral visits (for example fMRI on one day followed by DWI the day after)\nthose can be grouped in one session.</p>\n<p>Defining multiple sessions is appropriate when several identical or similar\ndata acquisitions are planned and performed on all -or most- subjects,\noften in the case of some intervention between sessions\n(for example, training).</p>", "type": "string", "format": "label", "required": "optional"}, "task": {"name": "task", "display_name": "Task", "description": "<p>A set of structured activities performed by the participant.\nTasks are usually accompanied by stimuli and responses, and can greatly vary in complexity.</p>\n<p>In the context of brain scanning, a task is always tied to one data acquisition.\nTherefore, even if during one acquisition the subject performed multiple conceptually different behaviors\n(with different sets of instructions) they will be considered one (combined) task.</p>\n<p>While tasks may be repeated across multiple acquisitions,\na given task may have different sets of stimuli (for example, randomized order) and participant responses\nacross subjects, sessions, and runs.</p>\n<p>The <code>task-&lt;label&gt;</code> MUST be consistent across subjects and sessions.</p>\n<p>Files with the <code>task-&lt;label&gt;</code> entity SHOULD have an associated\n<a href=\"SPEC_ROOT/modality-specific-files/task-events.md#task-events\">events file</a>,\nas well as certain metadata fields in the associated JSON file.</p>\n<p>For the purpose of this specification we consider the so-called \"resting state\" a task,\nalthough events files are not expected for resting state data.\nAdditionally, a common convention in the specification is to include the word \"rest\" in\nthe <code>task</code> label for resting state files (for example, <code>task-rest</code>).</p>", "type": "string", "format": "label", "required": "optional"}, "acquisition": {"name": "acq", "display_name": "Acquisition", "description": "<p>The <code>acq-&lt;label&gt;</code> entity corresponds to a custom label the user MAY use to distinguish\na different set of parameters used for acquiring the same modality.</p>\n<p>For example, this should be used when a study includes two T1w images -\none full brain low resolution and one restricted field of view but high resolution.\nIn such case two files could have the following names:\n<code>sub-01_acq-highres_T1w.nii.gz</code> and <code>sub-01_acq-lowres_T1w.nii.gz</code>;\nhowever, the user is free to choose any other label than <code>highres</code> and <code>lowres</code> as long\nas they are consistent across subjects and sessions.</p>\n<p>In case different sequences are used to record the same modality\n(for example, <code>RARE</code> and <code>FLASH</code> for T1w)\nthis field can also be used to make that distinction.\nThe level of detail at which the distinction is made\n(for example, just between <code>RARE</code> and <code>FLASH</code>, or between <code>RARE</code>, <code>FLASH</code>, and <code>FLASHsubsampled</code>)\nremains at the discretion of the researcher.</p>", "type": "string", "format": "label", "required": "optional"}, "ceagent": {"name": "ce", "display_name": "Contrast Enhancing Agent", "description": "<p>The <code>ce-&lt;label&gt;</code> entity can be used to distinguish sequences using different contrast enhanced images.\nThe label is the name of the contrast agent.</p>\n<p>This entity represents the <code>\"ContrastBolusIngredient\"</code> metadata field.\nTherefore, if the <code>ce-&lt;label&gt;</code> entity is present in a filename,\n<code>\"ContrastBolusIngredient\"</code> MAY also be added in the JSON file, with the same label.</p>", "type": "string", "format": "label", "required": "optional"}, "reconstruction": {"name": "rec", "display_name": "Reconstruction", "description": "<p>The <code>rec-&lt;label&gt;</code> entity can be used to distinguish different reconstruction algorithms\n(for example, <code>MoCo</code> for the ones using motion correction).</p>", "type": "string", "format": "label", "required": "optional"}, "run": {"name": "run", "display_name": "Run", "description": "<p>The <code>run-&lt;index&gt;</code> entity is used to distinguish separate data acquisitions with the same acquisition parameters\nand (other) entities.</p>\n<p>If several data acquisitions (for example, MRI scans or EEG recordings)\nwith the same acquisition parameters are acquired in the same session,\nthey MUST be indexed with the <a href=\"SPEC_ROOT/appendices/entities.md#run\"><code>run-&lt;index&gt;</code></a> entity:\n<code>_run-1</code>, <code>_run-2</code>, <code>_run-3</code>, and so on\n(only nonnegative integers are allowed as run indices).</p>\n<p>If different entities apply,\nsuch as a different session indicated by [<code>ses-&lt;label&gt;</code>][SPEC_ROOT/appendices/entities.md#ses),\nor different acquisition parameters indicated by\n<a href=\"SPEC_ROOT/appendices/entities.md#acq\"><code>acq-&lt;label&gt;</code></a>,\nthen <code>run</code> is not needed to distinguish the scans and MAY be omitted.</p>", "type": "string", "format": "index", "required": "optional"}, "echo": {"name": "echo", "display_name": "Echo", "description": "<p>If files belonging to an entity-linked file collection are acquired at different\necho times, the <code>echo-&lt;index&gt;</code> entity MUST be used to distinguish individual files.</p>\n<p>This entity represents the <code>\"EchoTime\"</code> metadata field.\nTherefore, if the <code>echo-&lt;index&gt;</code> entity is present in a filename,\n<code>\"EchoTime\"</code> MUST be defined in the associated metadata.\nPlease note that the <code>&lt;index&gt;</code> denotes the number/index (in the form of a nonnegative integer),\nnot the <code>\"EchoTime\"</code> value of the separate JSON file.</p>", "type": "string", "format": "index", "required": "optional"}, "part": {"name": "part", "display_name": "Part", "description": "<p>This entity is used to indicate which component of the complex\nrepresentation of the MRI signal is represented in voxel data.\nThe <code>part-&lt;label&gt;</code> entity is associated with the DICOM Tag\n<code>0008, 9208</code>.\nAllowed label values for this entity are <code>phase</code>, <code>mag</code>, <code>real</code> and <code>imag</code>,\nwhich are typically used in <code>part-mag</code>/<code>part-phase</code> or\n<code>part-real</code>/<code>part-imag</code> pairs of files.</p>\n<p>Phase images MAY be in radians or in arbitrary units.\nThe sidecar JSON file MUST include the <code>\"Units\"</code> of the <code>phase</code> image.\nThe possible options are <code>\"rad\"</code> or <code>\"arbitrary\"</code>.</p>\n<p>When there is only a magnitude image of a given type, the <code>part</code> entity MAY be\nomitted.</p>", "type": "string", "format": "label", "enum": ["mag", "phase", "real", "imag"], "required": "optional"}, "chunk": {"name": "chunk", "display_name": "Chunk", "description": "<p>The <code>chunk-&lt;index&gt;</code> key/value pair is used to distinguish between images of\nthe same physical sample with different fields of view acquired in the same\nimaging experiment.\nThis entity applies to collections of 2D images, 3D volumes or 4D volume series\n(for example, diffusion weighted images), and may be used to indicate different\nanatomical structures or regions of the same structure.</p>", "type": "string", "format": "index", "required": "optional"}}, "value": "PD", "display_name": "Proton density image", "description": "<p>Ambiguous, may refer to a parametric image or to a conventional image.\n<strong>Change:</strong> Replaced by <code>PDw</code> or <code>PDmap</code>.</p>\n<br><code>nonparametric</code>", "unit": "arbitrary"}, {"entities": {"subject": {"name": "sub", "display_name": "Subject", "description": "<p>A person or animal participating in the study.</p>", "type": "string", "format": "label", "required": "required"}, "session": {"name": "ses", "display_name": "Session", "description": "<p>A logical grouping of neuroimaging and behavioral data consistent across subjects.\nSession can (but doesn't have to) be synonymous to a visit in a longitudinal study.\nIn general, subjects will stay in the scanner during one session.\nHowever, for example, if a subject has to leave the scanner room and then\nbe re-positioned on the scanner bed, the set of MRI acquisitions will still\nbe considered as a session and match sessions acquired in other subjects.\nSimilarly, in situations where different data types are obtained over\nseveral visits (for example fMRI on one day followed by DWI the day after)\nthose can be grouped in one session.</p>\n<p>Defining multiple sessions is appropriate when several identical or similar\ndata acquisitions are planned and performed on all -or most- subjects,\noften in the case of some intervention between sessions\n(for example, training).</p>", "type": "string", "format": "label", "required": "optional"}, "task": {"name": "task", "display_name": "Task", "description": "<p>A set of structured activities performed by the participant.\nTasks are usually accompanied by stimuli and responses, and can greatly vary in complexity.</p>\n<p>In the context of brain scanning, a task is always tied to one data acquisition.\nTherefore, even if during one acquisition the subject performed multiple conceptually different behaviors\n(with different sets of instructions) they will be considered one (combined) task.</p>\n<p>While tasks may be repeated across multiple acquisitions,\na given task may have different sets of stimuli (for example, randomized order) and participant responses\nacross subjects, sessions, and runs.</p>\n<p>The <code>task-&lt;label&gt;</code> MUST be consistent across subjects and sessions.</p>\n<p>Files with the <code>task-&lt;label&gt;</code> entity SHOULD have an associated\n<a href=\"SPEC_ROOT/modality-specific-files/task-events.md#task-events\">events file</a>,\nas well as certain metadata fields in the associated JSON file.</p>\n<p>For the purpose of this specification we consider the so-called \"resting state\" a task,\nalthough events files are not expected for resting state data.\nAdditionally, a common convention in the specification is to include the word \"rest\" in\nthe <code>task</code> label for resting state files (for example, <code>task-rest</code>).</p>", "type": "string", "format": "label", "required": "optional"}, "acquisition": {"name": "acq", "display_name": "Acquisition", "description": "<p>The <code>acq-&lt;label&gt;</code> entity corresponds to a custom label the user MAY use to distinguish\na different set of parameters used for acquiring the same modality.</p>\n<p>For example, this should be used when a study includes two T1w images -\none full brain low resolution and one restricted field of view but high resolution.\nIn such case two files could have the following names:\n<code>sub-01_acq-highres_T1w.nii.gz</code> and <code>sub-01_acq-lowres_T1w.nii.gz</code>;\nhowever, the user is free to choose any other label than <code>highres</code> and <code>lowres</code> as long\nas they are consistent across subjects and sessions.</p>\n<p>In case different sequences are used to record the same modality\n(for example, <code>RARE</code> and <code>FLASH</code> for T1w)\nthis field can also be used to make that distinction.\nThe level of detail at which the distinction is made\n(for example, just between <code>RARE</code> and <code>FLASH</code>, or between <code>RARE</code>, <code>FLASH</code>, and <code>FLASHsubsampled</code>)\nremains at the discretion of the researcher.</p>", "type": "string", "format": "label", "required": "optional"}, "ceagent": {"name": "ce", "display_name": "Contrast Enhancing Agent", "description": "<p>The <code>ce-&lt;label&gt;</code> entity can be used to distinguish sequences using different contrast enhanced images.\nThe label is the name of the contrast agent.</p>\n<p>This entity represents the <code>\"ContrastBolusIngredient\"</code> metadata field.\nTherefore, if the <code>ce-&lt;label&gt;</code> entity is present in a filename,\n<code>\"ContrastBolusIngredient\"</code> MAY also be added in the JSON file, with the same label.</p>", "type": "string", "format": "label", "required": "optional"}, "reconstruction": {"name": "rec", "display_name": "Reconstruction", "description": "<p>The <code>rec-&lt;label&gt;</code> entity can be used to distinguish different reconstruction algorithms\n(for example, <code>MoCo</code> for the ones using motion correction).</p>", "type": "string", "format": "label", "required": "optional"}, "run": {"name": "run", "display_name": "Run", "description": "<p>The <code>run-&lt;index&gt;</code> entity is used to distinguish separate data acquisitions with the same acquisition parameters\nand (other) entities.</p>\n<p>If several data acquisitions (for example, MRI scans or EEG recordings)\nwith the same acquisition parameters are acquired in the same session,\nthey MUST be indexed with the <a href=\"SPEC_ROOT/appendices/entities.md#run\"><code>run-&lt;index&gt;</code></a> entity:\n<code>_run-1</code>, <code>_run-2</code>, <code>_run-3</code>, and so on\n(only nonnegative integers are allowed as run indices).</p>\n<p>If different entities apply,\nsuch as a different session indicated by [<code>ses-&lt;label&gt;</code>][SPEC_ROOT/appendices/entities.md#ses),\nor different acquisition parameters indicated by\n<a href=\"SPEC_ROOT/appendices/entities.md#acq\"><code>acq-&lt;label&gt;</code></a>,\nthen <code>run</code> is not needed to distinguish the scans and MAY be omitted.</p>", "type": "string", "format": "index", "required": "optional"}, "chunk": {"name": "chunk", "display_name": "Chunk", "description": "<p>The <code>chunk-&lt;index&gt;</code> key/value pair is used to distinguish between images of\nthe same physical sample with different fields of view acquired in the same\nimaging experiment.\nThis entity applies to collections of 2D images, 3D volumes or 4D volume series\n(for example, diffusion weighted images), and may be used to indicate different\nanatomical structures or regions of the same structure.</p>", "type": "string", "format": "index", "required": "optional"}}, "value": "T1map", "display_name": "Longitudinal relaxation time image", "description": "<p>In seconds (s).\nT1 maps are REQUIRED to use this suffix regardless of the method used to\ngenerate them.\nSee <a href=\"https://qmrlab.org/t1_book/intro\">this interactive book on T1 mapping</a>\nfor further reading on T1-mapping.</p>\n<br><code>parametric</code>", "unit": "s"}, {"entities": {"subject": {"name": "sub", "display_name": "Subject", "description": "<p>A person or animal participating in the study.</p>", "type": "string", "format": "label", "required": "required"}, "session": {"name": "ses", "display_name": "Session", "description": "<p>A logical grouping of neuroimaging and behavioral data consistent across subjects.\nSession can (but doesn't have to) be synonymous to a visit in a longitudinal study.\nIn general, subjects will stay in the scanner during one session.\nHowever, for example, if a subject has to leave the scanner room and then\nbe re-positioned on the scanner bed, the set of MRI acquisitions will still\nbe considered as a session and match sessions acquired in other subjects.\nSimilarly, in situations where different data types are obtained over\nseveral visits (for example fMRI on one day followed by DWI the day after)\nthose can be grouped in one session.</p>\n<p>Defining multiple sessions is appropriate when several identical or similar\ndata acquisitions are planned and performed on all -or most- subjects,\noften in the case of some intervention between sessions\n(for example, training).</p>", "type": "string", "format": "label", "required": "optional"}, "task": {"name": "task", "display_name": "Task", "description": "<p>A set of structured activities performed by the participant.\nTasks are usually accompanied by stimuli and responses, and can greatly vary in complexity.</p>\n<p>In the context of brain scanning, a task is always tied to one data acquisition.\nTherefore, even if during one acquisition the subject performed multiple conceptually different behaviors\n(with different sets of instructions) they will be considered one (combined) task.</p>\n<p>While tasks may be repeated across multiple acquisitions,\na given task may have different sets of stimuli (for example, randomized order) and participant responses\nacross subjects, sessions, and runs.</p>\n<p>The <code>task-&lt;label&gt;</code> MUST be consistent across subjects and sessions.</p>\n<p>Files with the <code>task-&lt;label&gt;</code> entity SHOULD have an associated\n<a href=\"SPEC_ROOT/modality-specific-files/task-events.md#task-events\">events file</a>,\nas well as certain metadata fields in the associated JSON file.</p>\n<p>For the purpose of this specification we consider the so-called \"resting state\" a task,\nalthough events files are not expected for resting state data.\nAdditionally, a common convention in the specification is to include the word \"rest\" in\nthe <code>task</code> label for resting state files (for example, <code>task-rest</code>).</p>", "type": "string", "format": "label", "required": "optional"}, "acquisition": {"name": "acq", "display_name": "Acquisition", "description": "<p>The <code>acq-&lt;label&gt;</code> entity corresponds to a custom label the user MAY use to distinguish\na different set of parameters used for acquiring the same modality.</p>\n<p>For example, this should be used when a study includes two T1w images -\none full brain low resolution and one restricted field of view but high resolution.\nIn such case two files could have the following names:\n<code>sub-01_acq-highres_T1w.nii.gz</code> and <code>sub-01_acq-lowres_T1w.nii.gz</code>;\nhowever, the user is free to choose any other label than <code>highres</code> and <code>lowres</code> as long\nas they are consistent across subjects and sessions.</p>\n<p>In case different sequences are used to record the same modality\n(for example, <code>RARE</code> and <code>FLASH</code> for T1w)\nthis field can also be used to make that distinction.\nThe level of detail at which the distinction is made\n(for example, just between <code>RARE</code> and <code>FLASH</code>, or between <code>RARE</code>, <code>FLASH</code>, and <code>FLASHsubsampled</code>)\nremains at the discretion of the researcher.</p>", "type": "string", "format": "label", "required": "optional"}, "ceagent": {"name": "ce", "display_name": "Contrast Enhancing Agent", "description": "<p>The <code>ce-&lt;label&gt;</code> entity can be used to distinguish sequences using different contrast enhanced images.\nThe label is the name of the contrast agent.</p>\n<p>This entity represents the <code>\"ContrastBolusIngredient\"</code> metadata field.\nTherefore, if the <code>ce-&lt;label&gt;</code> entity is present in a filename,\n<code>\"ContrastBolusIngredient\"</code> MAY also be added in the JSON file, with the same label.</p>", "type": "string", "format": "label", "required": "optional"}, "reconstruction": {"name": "rec", "display_name": "Reconstruction", "description": "<p>The <code>rec-&lt;label&gt;</code> entity can be used to distinguish different reconstruction algorithms\n(for example, <code>MoCo</code> for the ones using motion correction).</p>", "type": "string", "format": "label", "required": "optional"}, "run": {"name": "run", "display_name": "Run", "description": "<p>The <code>run-&lt;index&gt;</code> entity is used to distinguish separate data acquisitions with the same acquisition parameters\nand (other) entities.</p>\n<p>If several data acquisitions (for example, MRI scans or EEG recordings)\nwith the same acquisition parameters are acquired in the same session,\nthey MUST be indexed with the <a href=\"SPEC_ROOT/appendices/entities.md#run\"><code>run-&lt;index&gt;</code></a> entity:\n<code>_run-1</code>, <code>_run-2</code>, <code>_run-3</code>, and so on\n(only nonnegative integers are allowed as run indices).</p>\n<p>If different entities apply,\nsuch as a different session indicated by [<code>ses-&lt;label&gt;</code>][SPEC_ROOT/appendices/entities.md#ses),\nor different acquisition parameters indicated by\n<a href=\"SPEC_ROOT/appendices/entities.md#acq\"><code>acq-&lt;label&gt;</code></a>,\nthen <code>run</code> is not needed to distinguish the scans and MAY be omitted.</p>", "type": "string", "format": "index", "required": "optional"}, "chunk": {"name": "chunk", "display_name": "Chunk", "description": "<p>The <code>chunk-&lt;index&gt;</code> key/value pair is used to distinguish between images of\nthe same physical sample with different fields of view acquired in the same\nimaging experiment.\nThis entity applies to collections of 2D images, 3D volumes or 4D volume series\n(for example, diffusion weighted images), and may be used to indicate different\nanatomical structures or regions of the same structure.</p>", "type": "string", "format": "index", "required": "optional"}}, "value": "T2map", "display_name": "True transverse relaxation time image", "description": "<p>In seconds (s).\nT2 maps are REQUIRED to use this suffix regardless of the method used to\ngenerate them.</p>\n<br><code>parametric</code>", "unit": "s"}, {"entities": {"subject": {"name": "sub", "display_name": "Subject", "description": "<p>A person or animal participating in the study.</p>", "type": "string", "format": "label", "required": "required"}, "session": {"name": "ses", "display_name": "Session", "description": "<p>A logical grouping of neuroimaging and behavioral data consistent across subjects.\nSession can (but doesn't have to) be synonymous to a visit in a longitudinal study.\nIn general, subjects will stay in the scanner during one session.\nHowever, for example, if a subject has to leave the scanner room and then\nbe re-positioned on the scanner bed, the set of MRI acquisitions will still\nbe considered as a session and match sessions acquired in other subjects.\nSimilarly, in situations where different data types are obtained over\nseveral visits (for example fMRI on one day followed by DWI the day after)\nthose can be grouped in one session.</p>\n<p>Defining multiple sessions is appropriate when several identical or similar\ndata acquisitions are planned and performed on all -or most- subjects,\noften in the case of some intervention between sessions\n(for example, training).</p>", "type": "string", "format": "label", "required": "optional"}, "task": {"name": "task", "display_name": "Task", "description": "<p>A set of structured activities performed by the participant.\nTasks are usually accompanied by stimuli and responses, and can greatly vary in complexity.</p>\n<p>In the context of brain scanning, a task is always tied to one data acquisition.\nTherefore, even if during one acquisition the subject performed multiple conceptually different behaviors\n(with different sets of instructions) they will be considered one (combined) task.</p>\n<p>While tasks may be repeated across multiple acquisitions,\na given task may have different sets of stimuli (for example, randomized order) and participant responses\nacross subjects, sessions, and runs.</p>\n<p>The <code>task-&lt;label&gt;</code> MUST be consistent across subjects and sessions.</p>\n<p>Files with the <code>task-&lt;label&gt;</code> entity SHOULD have an associated\n<a href=\"SPEC_ROOT/modality-specific-files/task-events.md#task-events\">events file</a>,\nas well as certain metadata fields in the associated JSON file.</p>\n<p>For the purpose of this specification we consider the so-called \"resting state\" a task,\nalthough events files are not expected for resting state data.\nAdditionally, a common convention in the specification is to include the word \"rest\" in\nthe <code>task</code> label for resting state files (for example, <code>task-rest</code>).</p>", "type": "string", "format": "label", "required": "optional"}, "acquisition": {"name": "acq", "display_name": "Acquisition", "description": "<p>The <code>acq-&lt;label&gt;</code> entity corresponds to a custom label the user MAY use to distinguish\na different set of parameters used for acquiring the same modality.</p>\n<p>For example, this should be used when a study includes two T1w images -\none full brain low resolution and one restricted field of view but high resolution.\nIn such case two files could have the following names:\n<code>sub-01_acq-highres_T1w.nii.gz</code> and <code>sub-01_acq-lowres_T1w.nii.gz</code>;\nhowever, the user is free to choose any other label than <code>highres</code> and <code>lowres</code> as long\nas they are consistent across subjects and sessions.</p>\n<p>In case different sequences are used to record the same modality\n(for example, <code>RARE</code> and <code>FLASH</code> for T1w)\nthis field can also be used to make that distinction.\nThe level of detail at which the distinction is made\n(for example, just between <code>RARE</code> and <code>FLASH</code>, or between <code>RARE</code>, <code>FLASH</code>, and <code>FLASHsubsampled</code>)\nremains at the discretion of the researcher.</p>", "type": "string", "format": "label", "required": "optional"}, "ceagent": {"name": "ce", "display_name": "Contrast Enhancing Agent", "description": "<p>The <code>ce-&lt;label&gt;</code> entity can be used to distinguish sequences using different contrast enhanced images.\nThe label is the name of the contrast agent.</p>\n<p>This entity represents the <code>\"ContrastBolusIngredient\"</code> metadata field.\nTherefore, if the <code>ce-&lt;label&gt;</code> entity is present in a filename,\n<code>\"ContrastBolusIngredient\"</code> MAY also be added in the JSON file, with the same label.</p>", "type": "string", "format": "label", "required": "optional"}, "reconstruction": {"name": "rec", "display_name": "Reconstruction", "description": "<p>The <code>rec-&lt;label&gt;</code> entity can be used to distinguish different reconstruction algorithms\n(for example, <code>MoCo</code> for the ones using motion correction).</p>", "type": "string", "format": "label", "required": "optional"}, "run": {"name": "run", "display_name": "Run", "description": "<p>The <code>run-&lt;index&gt;</code> entity is used to distinguish separate data acquisitions with the same acquisition parameters\nand (other) entities.</p>\n<p>If several data acquisitions (for example, MRI scans or EEG recordings)\nwith the same acquisition parameters are acquired in the same session,\nthey MUST be indexed with the <a href=\"SPEC_ROOT/appendices/entities.md#run\"><code>run-&lt;index&gt;</code></a> entity:\n<code>_run-1</code>, <code>_run-2</code>, <code>_run-3</code>, and so on\n(only nonnegative integers are allowed as run indices).</p>\n<p>If different entities apply,\nsuch as a different session indicated by [<code>ses-&lt;label&gt;</code>][SPEC_ROOT/appendices/entities.md#ses),\nor different acquisition parameters indicated by\n<a href=\"SPEC_ROOT/appendices/entities.md#acq\"><code>acq-&lt;label&gt;</code></a>,\nthen <code>run</code> is not needed to distinguish the scans and MAY be omitted.</p>", "type": "string", "format": "index", "required": "optional"}, "chunk": {"name": "chunk", "display_name": "Chunk", "description": "<p>The <code>chunk-&lt;index&gt;</code> key/value pair is used to distinguish between images of\nthe same physical sample with different fields of view acquired in the same\nimaging experiment.\nThis entity applies to collections of 2D images, 3D volumes or 4D volume series\n(for example, diffusion weighted images), and may be used to indicate different\nanatomical structures or regions of the same structure.</p>", "type": "string", "format": "index", "required": "optional"}}, "value": "T2starmap", "display_name": "Observed transverse relaxation time image", "description": "<p>In seconds (s).\nT2-star maps are REQUIRED to use this suffix regardless of the method used to\ngenerate them.</p>\n<br><code>parametric</code>", "unit": "s"}, {"entities": {"subject": {"name": "sub", "display_name": "Subject", "description": "<p>A person or animal participating in the study.</p>", "type": "string", "format": "label", "required": "required"}, "session": {"name": "ses", "display_name": "Session", "description": "<p>A logical grouping of neuroimaging and behavioral data consistent across subjects.\nSession can (but doesn't have to) be synonymous to a visit in a longitudinal study.\nIn general, subjects will stay in the scanner during one session.\nHowever, for example, if a subject has to leave the scanner room and then\nbe re-positioned on the scanner bed, the set of MRI acquisitions will still\nbe considered as a session and match sessions acquired in other subjects.\nSimilarly, in situations where different data types are obtained over\nseveral visits (for example fMRI on one day followed by DWI the day after)\nthose can be grouped in one session.</p>\n<p>Defining multiple sessions is appropriate when several identical or similar\ndata acquisitions are planned and performed on all -or most- subjects,\noften in the case of some intervention between sessions\n(for example, training).</p>", "type": "string", "format": "label", "required": "optional"}, "task": {"name": "task", "display_name": "Task", "description": "<p>A set of structured activities performed by the participant.\nTasks are usually accompanied by stimuli and responses, and can greatly vary in complexity.</p>\n<p>In the context of brain scanning, a task is always tied to one data acquisition.\nTherefore, even if during one acquisition the subject performed multiple conceptually different behaviors\n(with different sets of instructions) they will be considered one (combined) task.</p>\n<p>While tasks may be repeated across multiple acquisitions,\na given task may have different sets of stimuli (for example, randomized order) and participant responses\nacross subjects, sessions, and runs.</p>\n<p>The <code>task-&lt;label&gt;</code> MUST be consistent across subjects and sessions.</p>\n<p>Files with the <code>task-&lt;label&gt;</code> entity SHOULD have an associated\n<a href=\"SPEC_ROOT/modality-specific-files/task-events.md#task-events\">events file</a>,\nas well as certain metadata fields in the associated JSON file.</p>\n<p>For the purpose of this specification we consider the so-called \"resting state\" a task,\nalthough events files are not expected for resting state data.\nAdditionally, a common convention in the specification is to include the word \"rest\" in\nthe <code>task</code> label for resting state files (for example, <code>task-rest</code>).</p>", "type": "string", "format": "label", "required": "optional"}, "acquisition": {"name": "acq", "display_name": "Acquisition", "description": "<p>The <code>acq-&lt;label&gt;</code> entity corresponds to a custom label the user MAY use to distinguish\na different set of parameters used for acquiring the same modality.</p>\n<p>For example, this should be used when a study includes two T1w images -\none full brain low resolution and one restricted field of view but high resolution.\nIn such case two files could have the following names:\n<code>sub-01_acq-highres_T1w.nii.gz</code> and <code>sub-01_acq-lowres_T1w.nii.gz</code>;\nhowever, the user is free to choose any other label than <code>highres</code> and <code>lowres</code> as long\nas they are consistent across subjects and sessions.</p>\n<p>In case different sequences are used to record the same modality\n(for example, <code>RARE</code> and <code>FLASH</code> for T1w)\nthis field can also be used to make that distinction.\nThe level of detail at which the distinction is made\n(for example, just between <code>RARE</code> and <code>FLASH</code>, or between <code>RARE</code>, <code>FLASH</code>, and <code>FLASHsubsampled</code>)\nremains at the discretion of the researcher.</p>", "type": "string", "format": "label", "required": "optional"}, "ceagent": {"name": "ce", "display_name": "Contrast Enhancing Agent", "description": "<p>The <code>ce-&lt;label&gt;</code> entity can be used to distinguish sequences using different contrast enhanced images.\nThe label is the name of the contrast agent.</p>\n<p>This entity represents the <code>\"ContrastBolusIngredient\"</code> metadata field.\nTherefore, if the <code>ce-&lt;label&gt;</code> entity is present in a filename,\n<code>\"ContrastBolusIngredient\"</code> MAY also be added in the JSON file, with the same label.</p>", "type": "string", "format": "label", "required": "optional"}, "reconstruction": {"name": "rec", "display_name": "Reconstruction", "description": "<p>The <code>rec-&lt;label&gt;</code> entity can be used to distinguish different reconstruction algorithms\n(for example, <code>MoCo</code> for the ones using motion correction).</p>", "type": "string", "format": "label", "required": "optional"}, "run": {"name": "run", "display_name": "Run", "description": "<p>The <code>run-&lt;index&gt;</code> entity is used to distinguish separate data acquisitions with the same acquisition parameters\nand (other) entities.</p>\n<p>If several data acquisitions (for example, MRI scans or EEG recordings)\nwith the same acquisition parameters are acquired in the same session,\nthey MUST be indexed with the <a href=\"SPEC_ROOT/appendices/entities.md#run\"><code>run-&lt;index&gt;</code></a> entity:\n<code>_run-1</code>, <code>_run-2</code>, <code>_run-3</code>, and so on\n(only nonnegative integers are allowed as run indices).</p>\n<p>If different entities apply,\nsuch as a different session indicated by [<code>ses-&lt;label&gt;</code>][SPEC_ROOT/appendices/entities.md#ses),\nor different acquisition parameters indicated by\n<a href=\"SPEC_ROOT/appendices/entities.md#acq\"><code>acq-&lt;label&gt;</code></a>,\nthen <code>run</code> is not needed to distinguish the scans and MAY be omitted.</p>", "type": "string", "format": "index", "required": "optional"}, "chunk": {"name": "chunk", "display_name": "Chunk", "description": "<p>The <code>chunk-&lt;index&gt;</code> key/value pair is used to distinguish between images of\nthe same physical sample with different fields of view acquired in the same\nimaging experiment.\nThis entity applies to collections of 2D images, 3D volumes or 4D volume series\n(for example, diffusion weighted images), and may be used to indicate different\nanatomical structures or regions of the same structure.</p>", "type": "string", "format": "index", "required": "optional"}}, "value": "R1map", "display_name": "Longitudinal relaxation rate image", "description": "<p>In seconds<sup>-1</sup> (1/s).\nR1 maps (R1 = 1/T1) are REQUIRED to use this suffix regardless of the method\nused to generate them.</p>\n<br><code>parametric</code>", "unit": "1/s"}, {"entities": {"subject": {"name": "sub", "display_name": "Subject", "description": "<p>A person or animal participating in the study.</p>", "type": "string", "format": "label", "required": "required"}, "session": {"name": "ses", "display_name": "Session", "description": "<p>A logical grouping of neuroimaging and behavioral data consistent across subjects.\nSession can (but doesn't have to) be synonymous to a visit in a longitudinal study.\nIn general, subjects will stay in the scanner during one session.\nHowever, for example, if a subject has to leave the scanner room and then\nbe re-positioned on the scanner bed, the set of MRI acquisitions will still\nbe considered as a session and match sessions acquired in other subjects.\nSimilarly, in situations where different data types are obtained over\nseveral visits (for example fMRI on one day followed by DWI the day after)\nthose can be grouped in one session.</p>\n<p>Defining multiple sessions is appropriate when several identical or similar\ndata acquisitions are planned and performed on all -or most- subjects,\noften in the case of some intervention between sessions\n(for example, training).</p>", "type": "string", "format": "label", "required": "optional"}, "task": {"name": "task", "display_name": "Task", "description": "<p>A set of structured activities performed by the participant.\nTasks are usually accompanied by stimuli and responses, and can greatly vary in complexity.</p>\n<p>In the context of brain scanning, a task is always tied to one data acquisition.\nTherefore, even if during one acquisition the subject performed multiple conceptually different behaviors\n(with different sets of instructions) they will be considered one (combined) task.</p>\n<p>While tasks may be repeated across multiple acquisitions,\na given task may have different sets of stimuli (for example, randomized order) and participant responses\nacross subjects, sessions, and runs.</p>\n<p>The <code>task-&lt;label&gt;</code> MUST be consistent across subjects and sessions.</p>\n<p>Files with the <code>task-&lt;label&gt;</code> entity SHOULD have an associated\n<a href=\"SPEC_ROOT/modality-specific-files/task-events.md#task-events\">events file</a>,\nas well as certain metadata fields in the associated JSON file.</p>\n<p>For the purpose of this specification we consider the so-called \"resting state\" a task,\nalthough events files are not expected for resting state data.\nAdditionally, a common convention in the specification is to include the word \"rest\" in\nthe <code>task</code> label for resting state files (for example, <code>task-rest</code>).</p>", "type": "string", "format": "label", "required": "optional"}, "acquisition": {"name": "acq", "display_name": "Acquisition", "description": "<p>The <code>acq-&lt;label&gt;</code> entity corresponds to a custom label the user MAY use to distinguish\na different set of parameters used for acquiring the same modality.</p>\n<p>For example, this should be used when a study includes two T1w images -\none full brain low resolution and one restricted field of view but high resolution.\nIn such case two files could have the following names:\n<code>sub-01_acq-highres_T1w.nii.gz</code> and <code>sub-01_acq-lowres_T1w.nii.gz</code>;\nhowever, the user is free to choose any other label than <code>highres</code> and <code>lowres</code> as long\nas they are consistent across subjects and sessions.</p>\n<p>In case different sequences are used to record the same modality\n(for example, <code>RARE</code> and <code>FLASH</code> for T1w)\nthis field can also be used to make that distinction.\nThe level of detail at which the distinction is made\n(for example, just between <code>RARE</code> and <code>FLASH</code>, or between <code>RARE</code>, <code>FLASH</code>, and <code>FLASHsubsampled</code>)\nremains at the discretion of the researcher.</p>", "type": "string", "format": "label", "required": "optional"}, "ceagent": {"name": "ce", "display_name": "Contrast Enhancing Agent", "description": "<p>The <code>ce-&lt;label&gt;</code> entity can be used to distinguish sequences using different contrast enhanced images.\nThe label is the name of the contrast agent.</p>\n<p>This entity represents the <code>\"ContrastBolusIngredient\"</code> metadata field.\nTherefore, if the <code>ce-&lt;label&gt;</code> entity is present in a filename,\n<code>\"ContrastBolusIngredient\"</code> MAY also be added in the JSON file, with the same label.</p>", "type": "string", "format": "label", "required": "optional"}, "reconstruction": {"name": "rec", "display_name": "Reconstruction", "description": "<p>The <code>rec-&lt;label&gt;</code> entity can be used to distinguish different reconstruction algorithms\n(for example, <code>MoCo</code> for the ones using motion correction).</p>", "type": "string", "format": "label", "required": "optional"}, "run": {"name": "run", "display_name": "Run", "description": "<p>The <code>run-&lt;index&gt;</code> entity is used to distinguish separate data acquisitions with the same acquisition parameters\nand (other) entities.</p>\n<p>If several data acquisitions (for example, MRI scans or EEG recordings)\nwith the same acquisition parameters are acquired in the same session,\nthey MUST be indexed with the <a href=\"SPEC_ROOT/appendices/entities.md#run\"><code>run-&lt;index&gt;</code></a> entity:\n<code>_run-1</code>, <code>_run-2</code>, <code>_run-3</code>, and so on\n(only nonnegative integers are allowed as run indices).</p>\n<p>If different entities apply,\nsuch as a different session indicated by [<code>ses-&lt;label&gt;</code>][SPEC_ROOT/appendices/entities.md#ses),\nor different acquisition parameters indicated by\n<a href=\"SPEC_ROOT/appendices/entities.md#acq\"><code>acq-&lt;label&gt;</code></a>,\nthen <code>run</code> is not needed to distinguish the scans and MAY be omitted.</p>", "type": "string", "format": "index", "required": "optional"}, "chunk": {"name": "chunk", "display_name": "Chunk", "description": "<p>The <code>chunk-&lt;index&gt;</code> key/value pair is used to distinguish between images of\nthe same physical sample with different fields of view acquired in the same\nimaging experiment.\nThis entity applies to collections of 2D images, 3D volumes or 4D volume series\n(for example, diffusion weighted images), and may be used to indicate different\nanatomical structures or regions of the same structure.</p>", "type": "string", "format": "index", "required": "optional"}}, "value": "R2map", "display_name": "True transverse relaxation rate image", "description": "<p>In seconds<sup>-1</sup> (1/s).\nR2 maps (R2 = 1/T2) are REQUIRED to use this suffix regardless of the method\nused to generate them.</p>\n<br><code>parametric</code>", "unit": "1/s"}, {"entities": {"subject": {"name": "sub", "display_name": "Subject", "description": "<p>A person or animal participating in the study.</p>", "type": "string", "format": "label", "required": "required"}, "session": {"name": "ses", "display_name": "Session", "description": "<p>A logical grouping of neuroimaging and behavioral data consistent across subjects.\nSession can (but doesn't have to) be synonymous to a visit in a longitudinal study.\nIn general, subjects will stay in the scanner during one session.\nHowever, for example, if a subject has to leave the scanner room and then\nbe re-positioned on the scanner bed, the set of MRI acquisitions will still\nbe considered as a session and match sessions acquired in other subjects.\nSimilarly, in situations where different data types are obtained over\nseveral visits (for example fMRI on one day followed by DWI the day after)\nthose can be grouped in one session.</p>\n<p>Defining multiple sessions is appropriate when several identical or similar\ndata acquisitions are planned and performed on all -or most- subjects,\noften in the case of some intervention between sessions\n(for example, training).</p>", "type": "string", "format": "label", "required": "optional"}, "task": {"name": "task", "display_name": "Task", "description": "<p>A set of structured activities performed by the participant.\nTasks are usually accompanied by stimuli and responses, and can greatly vary in complexity.</p>\n<p>In the context of brain scanning, a task is always tied to one data acquisition.\nTherefore, even if during one acquisition the subject performed multiple conceptually different behaviors\n(with different sets of instructions) they will be considered one (combined) task.</p>\n<p>While tasks may be repeated across multiple acquisitions,\na given task may have different sets of stimuli (for example, randomized order) and participant responses\nacross subjects, sessions, and runs.</p>\n<p>The <code>task-&lt;label&gt;</code> MUST be consistent across subjects and sessions.</p>\n<p>Files with the <code>task-&lt;label&gt;</code> entity SHOULD have an associated\n<a href=\"SPEC_ROOT/modality-specific-files/task-events.md#task-events\">events file</a>,\nas well as certain metadata fields in the associated JSON file.</p>\n<p>For the purpose of this specification we consider the so-called \"resting state\" a task,\nalthough events files are not expected for resting state data.\nAdditionally, a common convention in the specification is to include the word \"rest\" in\nthe <code>task</code> label for resting state files (for example, <code>task-rest</code>).</p>", "type": "string", "format": "label", "required": "optional"}, "acquisition": {"name": "acq", "display_name": "Acquisition", "description": "<p>The <code>acq-&lt;label&gt;</code> entity corresponds to a custom label the user MAY use to distinguish\na different set of parameters used for acquiring the same modality.</p>\n<p>For example, this should be used when a study includes two T1w images -\none full brain low resolution and one restricted field of view but high resolution.\nIn such case two files could have the following names:\n<code>sub-01_acq-highres_T1w.nii.gz</code> and <code>sub-01_acq-lowres_T1w.nii.gz</code>;\nhowever, the user is free to choose any other label than <code>highres</code> and <code>lowres</code> as long\nas they are consistent across subjects and sessions.</p>\n<p>In case different sequences are used to record the same modality\n(for example, <code>RARE</code> and <code>FLASH</code> for T1w)\nthis field can also be used to make that distinction.\nThe level of detail at which the distinction is made\n(for example, just between <code>RARE</code> and <code>FLASH</code>, or between <code>RARE</code>, <code>FLASH</code>, and <code>FLASHsubsampled</code>)\nremains at the discretion of the researcher.</p>", "type": "string", "format": "label", "required": "optional"}, "ceagent": {"name": "ce", "display_name": "Contrast Enhancing Agent", "description": "<p>The <code>ce-&lt;label&gt;</code> entity can be used to distinguish sequences using different contrast enhanced images.\nThe label is the name of the contrast agent.</p>\n<p>This entity represents the <code>\"ContrastBolusIngredient\"</code> metadata field.\nTherefore, if the <code>ce-&lt;label&gt;</code> entity is present in a filename,\n<code>\"ContrastBolusIngredient\"</code> MAY also be added in the JSON file, with the same label.</p>", "type": "string", "format": "label", "required": "optional"}, "reconstruction": {"name": "rec", "display_name": "Reconstruction", "description": "<p>The <code>rec-&lt;label&gt;</code> entity can be used to distinguish different reconstruction algorithms\n(for example, <code>MoCo</code> for the ones using motion correction).</p>", "type": "string", "format": "label", "required": "optional"}, "run": {"name": "run", "display_name": "Run", "description": "<p>The <code>run-&lt;index&gt;</code> entity is used to distinguish separate data acquisitions with the same acquisition parameters\nand (other) entities.</p>\n<p>If several data acquisitions (for example, MRI scans or EEG recordings)\nwith the same acquisition parameters are acquired in the same session,\nthey MUST be indexed with the <a href=\"SPEC_ROOT/appendices/entities.md#run\"><code>run-&lt;index&gt;</code></a> entity:\n<code>_run-1</code>, <code>_run-2</code>, <code>_run-3</code>, and so on\n(only nonnegative integers are allowed as run indices).</p>\n<p>If different entities apply,\nsuch as a different session indicated by [<code>ses-&lt;label&gt;</code>][SPEC_ROOT/appendices/entities.md#ses),\nor different acquisition parameters indicated by\n<a href=\"SPEC_ROOT/appendices/entities.md#acq\"><code>acq-&lt;label&gt;</code></a>,\nthen <code>run</code> is not needed to distinguish the scans and MAY be omitted.</p>", "type": "string", "format": "index", "required": "optional"}, "chunk": {"name": "chunk", "display_name": "Chunk", "description": "<p>The <code>chunk-&lt;index&gt;</code> key/value pair is used to distinguish between images of\nthe same physical sample with different fields of view acquired in the same\nimaging experiment.\nThis entity applies to collections of 2D images, 3D volumes or 4D volume series\n(for example, diffusion weighted images), and may be used to indicate different\nanatomical structures or regions of the same structure.</p>", "type": "string", "format": "index", "required": "optional"}}, "value": "R2starmap", "display_name": "Observed transverse relaxation rate image", "description": "<p>In seconds<sup>-1</sup> (1/s).\nR2-star maps (R2star = 1/T2star) are REQUIRED to use this suffix regardless\nof the method used to generate them.</p>\n<br><code>parametric</code>", "unit": "1/s"}, {"entities": {"subject": {"name": "sub", "display_name": "Subject", "description": "<p>A person or animal participating in the study.</p>", "type": "string", "format": "label", "required": "required"}, "session": {"name": "ses", "display_name": "Session", "description": "<p>A logical grouping of neuroimaging and behavioral data consistent across subjects.\nSession can (but doesn't have to) be synonymous to a visit in a longitudinal study.\nIn general, subjects will stay in the scanner during one session.\nHowever, for example, if a subject has to leave the scanner room and then\nbe re-positioned on the scanner bed, the set of MRI acquisitions will still\nbe considered as a session and match sessions acquired in other subjects.\nSimilarly, in situations where different data types are obtained over\nseveral visits (for example fMRI on one day followed by DWI the day after)\nthose can be grouped in one session.</p>\n<p>Defining multiple sessions is appropriate when several identical or similar\ndata acquisitions are planned and performed on all -or most- subjects,\noften in the case of some intervention between sessions\n(for example, training).</p>", "type": "string", "format": "label", "required": "optional"}, "task": {"name": "task", "display_name": "Task", "description": "<p>A set of structured activities performed by the participant.\nTasks are usually accompanied by stimuli and responses, and can greatly vary in complexity.</p>\n<p>In the context of brain scanning, a task is always tied to one data acquisition.\nTherefore, even if during one acquisition the subject performed multiple conceptually different behaviors\n(with different sets of instructions) they will be considered one (combined) task.</p>\n<p>While tasks may be repeated across multiple acquisitions,\na given task may have different sets of stimuli (for example, randomized order) and participant responses\nacross subjects, sessions, and runs.</p>\n<p>The <code>task-&lt;label&gt;</code> MUST be consistent across subjects and sessions.</p>\n<p>Files with the <code>task-&lt;label&gt;</code> entity SHOULD have an associated\n<a href=\"SPEC_ROOT/modality-specific-files/task-events.md#task-events\">events file</a>,\nas well as certain metadata fields in the associated JSON file.</p>\n<p>For the purpose of this specification we consider the so-called \"resting state\" a task,\nalthough events files are not expected for resting state data.\nAdditionally, a common convention in the specification is to include the word \"rest\" in\nthe <code>task</code> label for resting state files (for example, <code>task-rest</code>).</p>", "type": "string", "format": "label", "required": "optional"}, "acquisition": {"name": "acq", "display_name": "Acquisition", "description": "<p>The <code>acq-&lt;label&gt;</code> entity corresponds to a custom label the user MAY use to distinguish\na different set of parameters used for acquiring the same modality.</p>\n<p>For example, this should be used when a study includes two T1w images -\none full brain low resolution and one restricted field of view but high resolution.\nIn such case two files could have the following names:\n<code>sub-01_acq-highres_T1w.nii.gz</code> and <code>sub-01_acq-lowres_T1w.nii.gz</code>;\nhowever, the user is free to choose any other label than <code>highres</code> and <code>lowres</code> as long\nas they are consistent across subjects and sessions.</p>\n<p>In case different sequences are used to record the same modality\n(for example, <code>RARE</code> and <code>FLASH</code> for T1w)\nthis field can also be used to make that distinction.\nThe level of detail at which the distinction is made\n(for example, just between <code>RARE</code> and <code>FLASH</code>, or between <code>RARE</code>, <code>FLASH</code>, and <code>FLASHsubsampled</code>)\nremains at the discretion of the researcher.</p>", "type": "string", "format": "label", "required": "optional"}, "ceagent": {"name": "ce", "display_name": "Contrast Enhancing Agent", "description": "<p>The <code>ce-&lt;label&gt;</code> entity can be used to distinguish sequences using different contrast enhanced images.\nThe label is the name of the contrast agent.</p>\n<p>This entity represents the <code>\"ContrastBolusIngredient\"</code> metadata field.\nTherefore, if the <code>ce-&lt;label&gt;</code> entity is present in a filename,\n<code>\"ContrastBolusIngredient\"</code> MAY also be added in the JSON file, with the same label.</p>", "type": "string", "format": "label", "required": "optional"}, "reconstruction": {"name": "rec", "display_name": "Reconstruction", "description": "<p>The <code>rec-&lt;label&gt;</code> entity can be used to distinguish different reconstruction algorithms\n(for example, <code>MoCo</code> for the ones using motion correction).</p>", "type": "string", "format": "label", "required": "optional"}, "run": {"name": "run", "display_name": "Run", "description": "<p>The <code>run-&lt;index&gt;</code> entity is used to distinguish separate data acquisitions with the same acquisition parameters\nand (other) entities.</p>\n<p>If several data acquisitions (for example, MRI scans or EEG recordings)\nwith the same acquisition parameters are acquired in the same session,\nthey MUST be indexed with the <a href=\"SPEC_ROOT/appendices/entities.md#run\"><code>run-&lt;index&gt;</code></a> entity:\n<code>_run-1</code>, <code>_run-2</code>, <code>_run-3</code>, and so on\n(only nonnegative integers are allowed as run indices).</p>\n<p>If different entities apply,\nsuch as a different session indicated by [<code>ses-&lt;label&gt;</code>][SPEC_ROOT/appendices/entities.md#ses),\nor different acquisition parameters indicated by\n<a href=\"SPEC_ROOT/appendices/entities.md#acq\"><code>acq-&lt;label&gt;</code></a>,\nthen <code>run</code> is not needed to distinguish the scans and MAY be omitted.</p>", "type": "string", "format": "index", "required": "optional"}, "chunk": {"name": "chunk", "display_name": "Chunk", "description": "<p>The <code>chunk-&lt;index&gt;</code> key/value pair is used to distinguish between images of\nthe same physical sample with different fields of view acquired in the same\nimaging experiment.\nThis entity applies to collections of 2D images, 3D volumes or 4D volume series\n(for example, diffusion weighted images), and may be used to indicate different\nanatomical structures or regions of the same structure.</p>", "type": "string", "format": "index", "required": "optional"}}, "value": "PDmap", "display_name": "Proton density image", "description": "<p>In arbitrary units (arbitrary).\nPD maps are REQUIRED to use this suffix regardless of the method used to\ngenerate them.</p>\n<br><code>parametric</code>", "unit": "arbitrary"}, {"entities": {"subject": {"name": "sub", "display_name": "Subject", "description": "<p>A person or animal participating in the study.</p>", "type": "string", "format": "label", "required": "required"}, "session": {"name": "ses", "display_name": "Session", "description": "<p>A logical grouping of neuroimaging and behavioral data consistent across subjects.\nSession can (but doesn't have to) be synonymous to a visit in a longitudinal study.\nIn general, subjects will stay in the scanner during one session.\nHowever, for example, if a subject has to leave the scanner room and then\nbe re-positioned on the scanner bed, the set of MRI acquisitions will still\nbe considered as a session and match sessions acquired in other subjects.\nSimilarly, in situations where different data types are obtained over\nseveral visits (for example fMRI on one day followed by DWI the day after)\nthose can be grouped in one session.</p>\n<p>Defining multiple sessions is appropriate when several identical or similar\ndata acquisitions are planned and performed on all -or most- subjects,\noften in the case of some intervention between sessions\n(for example, training).</p>", "type": "string", "format": "label", "required": "optional"}, "task": {"name": "task", "display_name": "Task", "description": "<p>A set of structured activities performed by the participant.\nTasks are usually accompanied by stimuli and responses, and can greatly vary in complexity.</p>\n<p>In the context of brain scanning, a task is always tied to one data acquisition.\nTherefore, even if during one acquisition the subject performed multiple conceptually different behaviors\n(with different sets of instructions) they will be considered one (combined) task.</p>\n<p>While tasks may be repeated across multiple acquisitions,\na given task may have different sets of stimuli (for example, randomized order) and participant responses\nacross subjects, sessions, and runs.</p>\n<p>The <code>task-&lt;label&gt;</code> MUST be consistent across subjects and sessions.</p>\n<p>Files with the <code>task-&lt;label&gt;</code> entity SHOULD have an associated\n<a href=\"SPEC_ROOT/modality-specific-files/task-events.md#task-events\">events file</a>,\nas well as certain metadata fields in the associated JSON file.</p>\n<p>For the purpose of this specification we consider the so-called \"resting state\" a task,\nalthough events files are not expected for resting state data.\nAdditionally, a common convention in the specification is to include the word \"rest\" in\nthe <code>task</code> label for resting state files (for example, <code>task-rest</code>).</p>", "type": "string", "format": "label", "required": "optional"}, "acquisition": {"name": "acq", "display_name": "Acquisition", "description": "<p>The <code>acq-&lt;label&gt;</code> entity corresponds to a custom label the user MAY use to distinguish\na different set of parameters used for acquiring the same modality.</p>\n<p>For example, this should be used when a study includes two T1w images -\none full brain low resolution and one restricted field of view but high resolution.\nIn such case two files could have the following names:\n<code>sub-01_acq-highres_T1w.nii.gz</code> and <code>sub-01_acq-lowres_T1w.nii.gz</code>;\nhowever, the user is free to choose any other label than <code>highres</code> and <code>lowres</code> as long\nas they are consistent across subjects and sessions.</p>\n<p>In case different sequences are used to record the same modality\n(for example, <code>RARE</code> and <code>FLASH</code> for T1w)\nthis field can also be used to make that distinction.\nThe level of detail at which the distinction is made\n(for example, just between <code>RARE</code> and <code>FLASH</code>, or between <code>RARE</code>, <code>FLASH</code>, and <code>FLASHsubsampled</code>)\nremains at the discretion of the researcher.</p>", "type": "string", "format": "label", "required": "optional"}, "ceagent": {"name": "ce", "display_name": "Contrast Enhancing Agent", "description": "<p>The <code>ce-&lt;label&gt;</code> entity can be used to distinguish sequences using different contrast enhanced images.\nThe label is the name of the contrast agent.</p>\n<p>This entity represents the <code>\"ContrastBolusIngredient\"</code> metadata field.\nTherefore, if the <code>ce-&lt;label&gt;</code> entity is present in a filename,\n<code>\"ContrastBolusIngredient\"</code> MAY also be added in the JSON file, with the same label.</p>", "type": "string", "format": "label", "required": "optional"}, "reconstruction": {"name": "rec", "display_name": "Reconstruction", "description": "<p>The <code>rec-&lt;label&gt;</code> entity can be used to distinguish different reconstruction algorithms\n(for example, <code>MoCo</code> for the ones using motion correction).</p>", "type": "string", "format": "label", "required": "optional"}, "run": {"name": "run", "display_name": "Run", "description": "<p>The <code>run-&lt;index&gt;</code> entity is used to distinguish separate data acquisitions with the same acquisition parameters\nand (other) entities.</p>\n<p>If several data acquisitions (for example, MRI scans or EEG recordings)\nwith the same acquisition parameters are acquired in the same session,\nthey MUST be indexed with the <a href=\"SPEC_ROOT/appendices/entities.md#run\"><code>run-&lt;index&gt;</code></a> entity:\n<code>_run-1</code>, <code>_run-2</code>, <code>_run-3</code>, and so on\n(only nonnegative integers are allowed as run indices).</p>\n<p>If different entities apply,\nsuch as a different session indicated by [<code>ses-&lt;label&gt;</code>][SPEC_ROOT/appendices/entities.md#ses),\nor different acquisition parameters indicated by\n<a href=\"SPEC_ROOT/appendices/entities.md#acq\"><code>acq-&lt;label&gt;</code></a>,\nthen <code>run</code> is not needed to distinguish the scans and MAY be omitted.</p>", "type": "string", "format": "index", "required": "optional"}, "chunk": {"name": "chunk", "display_name": "Chunk", "description": "<p>The <code>chunk-&lt;index&gt;</code> key/value pair is used to distinguish between images of\nthe same physical sample with different fields of view acquired in the same\nimaging experiment.\nThis entity applies to collections of 2D images, 3D volumes or 4D volume series\n(for example, diffusion weighted images), and may be used to indicate different\nanatomical structures or regions of the same structure.</p>", "type": "string", "format": "index", "required": "optional"}}, "value": "MTRmap", "display_name": "Magnetization transfer ratio image", "description": "<p>In arbitrary units (arbitrary).\nMTR maps are REQUIRED to use this suffix regardless of the method used to\ngenerate them.\nMTRmap intensity values are RECOMMENDED to be represented in percentage in\nthe range of 0-100%.</p>\n<br><code>parametric</code>", "unit": "arbitrary", "minValue": 0, "maxValue": 100}, {"entities": {"subject": {"name": "sub", "display_name": "Subject", "description": "<p>A person or animal participating in the study.</p>", "type": "string", "format": "label", "required": "required"}, "session": {"name": "ses", "display_name": "Session", "description": "<p>A logical grouping of neuroimaging and behavioral data consistent across subjects.\nSession can (but doesn't have to) be synonymous to a visit in a longitudinal study.\nIn general, subjects will stay in the scanner during one session.\nHowever, for example, if a subject has to leave the scanner room and then\nbe re-positioned on the scanner bed, the set of MRI acquisitions will still\nbe considered as a session and match sessions acquired in other subjects.\nSimilarly, in situations where different data types are obtained over\nseveral visits (for example fMRI on one day followed by DWI the day after)\nthose can be grouped in one session.</p>\n<p>Defining multiple sessions is appropriate when several identical or similar\ndata acquisitions are planned and performed on all -or most- subjects,\noften in the case of some intervention between sessions\n(for example, training).</p>", "type": "string", "format": "label", "required": "optional"}, "task": {"name": "task", "display_name": "Task", "description": "<p>A set of structured activities performed by the participant.\nTasks are usually accompanied by stimuli and responses, and can greatly vary in complexity.</p>\n<p>In the context of brain scanning, a task is always tied to one data acquisition.\nTherefore, even if during one acquisition the subject performed multiple conceptually different behaviors\n(with different sets of instructions) they will be considered one (combined) task.</p>\n<p>While tasks may be repeated across multiple acquisitions,\na given task may have different sets of stimuli (for example, randomized order) and participant responses\nacross subjects, sessions, and runs.</p>\n<p>The <code>task-&lt;label&gt;</code> MUST be consistent across subjects and sessions.</p>\n<p>Files with the <code>task-&lt;label&gt;</code> entity SHOULD have an associated\n<a href=\"SPEC_ROOT/modality-specific-files/task-events.md#task-events\">events file</a>,\nas well as certain metadata fields in the associated JSON file.</p>\n<p>For the purpose of this specification we consider the so-called \"resting state\" a task,\nalthough events files are not expected for resting state data.\nAdditionally, a common convention in the specification is to include the word \"rest\" in\nthe <code>task</code> label for resting state files (for example, <code>task-rest</code>).</p>", "type": "string", "format": "label", "required": "optional"}, "acquisition": {"name": "acq", "display_name": "Acquisition", "description": "<p>The <code>acq-&lt;label&gt;</code> entity corresponds to a custom label the user MAY use to distinguish\na different set of parameters used for acquiring the same modality.</p>\n<p>For example, this should be used when a study includes two T1w images -\none full brain low resolution and one restricted field of view but high resolution.\nIn such case two files could have the following names:\n<code>sub-01_acq-highres_T1w.nii.gz</code> and <code>sub-01_acq-lowres_T1w.nii.gz</code>;\nhowever, the user is free to choose any other label than <code>highres</code> and <code>lowres</code> as long\nas they are consistent across subjects and sessions.</p>\n<p>In case different sequences are used to record the same modality\n(for example, <code>RARE</code> and <code>FLASH</code> for T1w)\nthis field can also be used to make that distinction.\nThe level of detail at which the distinction is made\n(for example, just between <code>RARE</code> and <code>FLASH</code>, or between <code>RARE</code>, <code>FLASH</code>, and <code>FLASHsubsampled</code>)\nremains at the discretion of the researcher.</p>", "type": "string", "format": "label", "required": "optional"}, "ceagent": {"name": "ce", "display_name": "Contrast Enhancing Agent", "description": "<p>The <code>ce-&lt;label&gt;</code> entity can be used to distinguish sequences using different contrast enhanced images.\nThe label is the name of the contrast agent.</p>\n<p>This entity represents the <code>\"ContrastBolusIngredient\"</code> metadata field.\nTherefore, if the <code>ce-&lt;label&gt;</code> entity is present in a filename,\n<code>\"ContrastBolusIngredient\"</code> MAY also be added in the JSON file, with the same label.</p>", "type": "string", "format": "label", "required": "optional"}, "reconstruction": {"name": "rec", "display_name": "Reconstruction", "description": "<p>The <code>rec-&lt;label&gt;</code> entity can be used to distinguish different reconstruction algorithms\n(for example, <code>MoCo</code> for the ones using motion correction).</p>", "type": "string", "format": "label", "required": "optional"}, "run": {"name": "run", "display_name": "Run", "description": "<p>The <code>run-&lt;index&gt;</code> entity is used to distinguish separate data acquisitions with the same acquisition parameters\nand (other) entities.</p>\n<p>If several data acquisitions (for example, MRI scans or EEG recordings)\nwith the same acquisition parameters are acquired in the same session,\nthey MUST be indexed with the <a href=\"SPEC_ROOT/appendices/entities.md#run\"><code>run-&lt;index&gt;</code></a> entity:\n<code>_run-1</code>, <code>_run-2</code>, <code>_run-3</code>, and so on\n(only nonnegative integers are allowed as run indices).</p>\n<p>If different entities apply,\nsuch as a different session indicated by [<code>ses-&lt;label&gt;</code>][SPEC_ROOT/appendices/entities.md#ses),\nor different acquisition parameters indicated by\n<a href=\"SPEC_ROOT/appendices/entities.md#acq\"><code>acq-&lt;label&gt;</code></a>,\nthen <code>run</code> is not needed to distinguish the scans and MAY be omitted.</p>", "type": "string", "format": "index", "required": "optional"}, "chunk": {"name": "chunk", "display_name": "Chunk", "description": "<p>The <code>chunk-&lt;index&gt;</code> key/value pair is used to distinguish between images of\nthe same physical sample with different fields of view acquired in the same\nimaging experiment.\nThis entity applies to collections of 2D images, 3D volumes or 4D volume series\n(for example, diffusion weighted images), and may be used to indicate different\nanatomical structures or regions of the same structure.</p>", "type": "string", "format": "index", "required": "optional"}}, "value": "MTsat", "display_name": "Magnetization transfer saturation image", "description": "<p>In arbitrary units (arbitrary).\nMTsat maps are REQUIRED to use this suffix regardless of the method used to\ngenerate them.</p>\n<br><code>parametric</code>", "unit": "arbitrary"}, {"entities": {"subject": {"name": "sub", "display_name": "Subject", "description": "<p>A person or animal participating in the study.</p>", "type": "string", "format": "label", "required": "required"}, "session": {"name": "ses", "display_name": "Session", "description": "<p>A logical grouping of neuroimaging and behavioral data consistent across subjects.\nSession can (but doesn't have to) be synonymous to a visit in a longitudinal study.\nIn general, subjects will stay in the scanner during one session.\nHowever, for example, if a subject has to leave the scanner room and then\nbe re-positioned on the scanner bed, the set of MRI acquisitions will still\nbe considered as a session and match sessions acquired in other subjects.\nSimilarly, in situations where different data types are obtained over\nseveral visits (for example fMRI on one day followed by DWI the day after)\nthose can be grouped in one session.</p>\n<p>Defining multiple sessions is appropriate when several identical or similar\ndata acquisitions are planned and performed on all -or most- subjects,\noften in the case of some intervention between sessions\n(for example, training).</p>", "type": "string", "format": "label", "required": "optional"}, "task": {"name": "task", "display_name": "Task", "description": "<p>A set of structured activities performed by the participant.\nTasks are usually accompanied by stimuli and responses, and can greatly vary in complexity.</p>\n<p>In the context of brain scanning, a task is always tied to one data acquisition.\nTherefore, even if during one acquisition the subject performed multiple conceptually different behaviors\n(with different sets of instructions) they will be considered one (combined) task.</p>\n<p>While tasks may be repeated across multiple acquisitions,\na given task may have different sets of stimuli (for example, randomized order) and participant responses\nacross subjects, sessions, and runs.</p>\n<p>The <code>task-&lt;label&gt;</code> MUST be consistent across subjects and sessions.</p>\n<p>Files with the <code>task-&lt;label&gt;</code> entity SHOULD have an associated\n<a href=\"SPEC_ROOT/modality-specific-files/task-events.md#task-events\">events file</a>,\nas well as certain metadata fields in the associated JSON file.</p>\n<p>For the purpose of this specification we consider the so-called \"resting state\" a task,\nalthough events files are not expected for resting state data.\nAdditionally, a common convention in the specification is to include the word \"rest\" in\nthe <code>task</code> label for resting state files (for example, <code>task-rest</code>).</p>", "type": "string", "format": "label", "required": "optional"}, "acquisition": {"name": "acq", "display_name": "Acquisition", "description": "<p>The <code>acq-&lt;label&gt;</code> entity corresponds to a custom label the user MAY use to distinguish\na different set of parameters used for acquiring the same modality.</p>\n<p>For example, this should be used when a study includes two T1w images -\none full brain low resolution and one restricted field of view but high resolution.\nIn such case two files could have the following names:\n<code>sub-01_acq-highres_T1w.nii.gz</code> and <code>sub-01_acq-lowres_T1w.nii.gz</code>;\nhowever, the user is free to choose any other label than <code>highres</code> and <code>lowres</code> as long\nas they are consistent across subjects and sessions.</p>\n<p>In case different sequences are used to record the same modality\n(for example, <code>RARE</code> and <code>FLASH</code> for T1w)\nthis field can also be used to make that distinction.\nThe level of detail at which the distinction is made\n(for example, just between <code>RARE</code> and <code>FLASH</code>, or between <code>RARE</code>, <code>FLASH</code>, and <code>FLASHsubsampled</code>)\nremains at the discretion of the researcher.</p>", "type": "string", "format": "label", "required": "optional"}, "ceagent": {"name": "ce", "display_name": "Contrast Enhancing Agent", "description": "<p>The <code>ce-&lt;label&gt;</code> entity can be used to distinguish sequences using different contrast enhanced images.\nThe label is the name of the contrast agent.</p>\n<p>This entity represents the <code>\"ContrastBolusIngredient\"</code> metadata field.\nTherefore, if the <code>ce-&lt;label&gt;</code> entity is present in a filename,\n<code>\"ContrastBolusIngredient\"</code> MAY also be added in the JSON file, with the same label.</p>", "type": "string", "format": "label", "required": "optional"}, "reconstruction": {"name": "rec", "display_name": "Reconstruction", "description": "<p>The <code>rec-&lt;label&gt;</code> entity can be used to distinguish different reconstruction algorithms\n(for example, <code>MoCo</code> for the ones using motion correction).</p>", "type": "string", "format": "label", "required": "optional"}, "run": {"name": "run", "display_name": "Run", "description": "<p>The <code>run-&lt;index&gt;</code> entity is used to distinguish separate data acquisitions with the same acquisition parameters\nand (other) entities.</p>\n<p>If several data acquisitions (for example, MRI scans or EEG recordings)\nwith the same acquisition parameters are acquired in the same session,\nthey MUST be indexed with the <a href=\"SPEC_ROOT/appendices/entities.md#run\"><code>run-&lt;index&gt;</code></a> entity:\n<code>_run-1</code>, <code>_run-2</code>, <code>_run-3</code>, and so on\n(only nonnegative integers are allowed as run indices).</p>\n<p>If different entities apply,\nsuch as a different session indicated by [<code>ses-&lt;label&gt;</code>][SPEC_ROOT/appendices/entities.md#ses),\nor different acquisition parameters indicated by\n<a href=\"SPEC_ROOT/appendices/entities.md#acq\"><code>acq-&lt;label&gt;</code></a>,\nthen <code>run</code> is not needed to distinguish the scans and MAY be omitted.</p>", "type": "string", "format": "index", "required": "optional"}, "chunk": {"name": "chunk", "display_name": "Chunk", "description": "<p>The <code>chunk-&lt;index&gt;</code> key/value pair is used to distinguish between images of\nthe same physical sample with different fields of view acquired in the same\nimaging experiment.\nThis entity applies to collections of 2D images, 3D volumes or 4D volume series\n(for example, diffusion weighted images), and may be used to indicate different\nanatomical structures or regions of the same structure.</p>", "type": "string", "format": "index", "required": "optional"}}, "value": "UNIT1", "display_name": "Homogeneous (flat) T1-weighted MP2RAGE image", "description": "<p>In arbitrary units (arbitrary).\nUNIT1 images are REQUIRED to use this suffix regardless of the method used to\ngenerate them.\nNote that although this image is T1-weighted, regions without MR signal will\ncontain white salt-and-pepper noise that most segmentation algorithms will\nfail on.\nTherefore, it is important to dissociate it from <code>T1w</code>.\nPlease see <a href=\"SPEC_ROOT/appendices/qmri.md#unit1-images\"><code>MP2RAGE</code> specific notes</a>\nin the qMRI appendix for further information.</p>\n<br><code>parametric</code>"}, {"entities": {"subject": {"name": "sub", "display_name": "Subject", "description": "<p>A person or animal participating in the study.</p>", "type": "string", "format": "label", "required": "required"}, "session": {"name": "ses", "display_name": "Session", "description": "<p>A logical grouping of neuroimaging and behavioral data consistent across subjects.\nSession can (but doesn't have to) be synonymous to a visit in a longitudinal study.\nIn general, subjects will stay in the scanner during one session.\nHowever, for example, if a subject has to leave the scanner room and then\nbe re-positioned on the scanner bed, the set of MRI acquisitions will still\nbe considered as a session and match sessions acquired in other subjects.\nSimilarly, in situations where different data types are obtained over\nseveral visits (for example fMRI on one day followed by DWI the day after)\nthose can be grouped in one session.</p>\n<p>Defining multiple sessions is appropriate when several identical or similar\ndata acquisitions are planned and performed on all -or most- subjects,\noften in the case of some intervention between sessions\n(for example, training).</p>", "type": "string", "format": "label", "required": "optional"}, "task": {"name": "task", "display_name": "Task", "description": "<p>A set of structured activities performed by the participant.\nTasks are usually accompanied by stimuli and responses, and can greatly vary in complexity.</p>\n<p>In the context of brain scanning, a task is always tied to one data acquisition.\nTherefore, even if during one acquisition the subject performed multiple conceptually different behaviors\n(with different sets of instructions) they will be considered one (combined) task.</p>\n<p>While tasks may be repeated across multiple acquisitions,\na given task may have different sets of stimuli (for example, randomized order) and participant responses\nacross subjects, sessions, and runs.</p>\n<p>The <code>task-&lt;label&gt;</code> MUST be consistent across subjects and sessions.</p>\n<p>Files with the <code>task-&lt;label&gt;</code> entity SHOULD have an associated\n<a href=\"SPEC_ROOT/modality-specific-files/task-events.md#task-events\">events file</a>,\nas well as certain metadata fields in the associated JSON file.</p>\n<p>For the purpose of this specification we consider the so-called \"resting state\" a task,\nalthough events files are not expected for resting state data.\nAdditionally, a common convention in the specification is to include the word \"rest\" in\nthe <code>task</code> label for resting state files (for example, <code>task-rest</code>).</p>", "type": "string", "format": "label", "required": "optional"}, "acquisition": {"name": "acq", "display_name": "Acquisition", "description": "<p>The <code>acq-&lt;label&gt;</code> entity corresponds to a custom label the user MAY use to distinguish\na different set of parameters used for acquiring the same modality.</p>\n<p>For example, this should be used when a study includes two T1w images -\none full brain low resolution and one restricted field of view but high resolution.\nIn such case two files could have the following names:\n<code>sub-01_acq-highres_T1w.nii.gz</code> and <code>sub-01_acq-lowres_T1w.nii.gz</code>;\nhowever, the user is free to choose any other label than <code>highres</code> and <code>lowres</code> as long\nas they are consistent across subjects and sessions.</p>\n<p>In case different sequences are used to record the same modality\n(for example, <code>RARE</code> and <code>FLASH</code> for T1w)\nthis field can also be used to make that distinction.\nThe level of detail at which the distinction is made\n(for example, just between <code>RARE</code> and <code>FLASH</code>, or between <code>RARE</code>, <code>FLASH</code>, and <code>FLASHsubsampled</code>)\nremains at the discretion of the researcher.</p>", "type": "string", "format": "label", "required": "optional"}, "ceagent": {"name": "ce", "display_name": "Contrast Enhancing Agent", "description": "<p>The <code>ce-&lt;label&gt;</code> entity can be used to distinguish sequences using different contrast enhanced images.\nThe label is the name of the contrast agent.</p>\n<p>This entity represents the <code>\"ContrastBolusIngredient\"</code> metadata field.\nTherefore, if the <code>ce-&lt;label&gt;</code> entity is present in a filename,\n<code>\"ContrastBolusIngredient\"</code> MAY also be added in the JSON file, with the same label.</p>", "type": "string", "format": "label", "required": "optional"}, "reconstruction": {"name": "rec", "display_name": "Reconstruction", "description": "<p>The <code>rec-&lt;label&gt;</code> entity can be used to distinguish different reconstruction algorithms\n(for example, <code>MoCo</code> for the ones using motion correction).</p>", "type": "string", "format": "label", "required": "optional"}, "run": {"name": "run", "display_name": "Run", "description": "<p>The <code>run-&lt;index&gt;</code> entity is used to distinguish separate data acquisitions with the same acquisition parameters\nand (other) entities.</p>\n<p>If several data acquisitions (for example, MRI scans or EEG recordings)\nwith the same acquisition parameters are acquired in the same session,\nthey MUST be indexed with the <a href=\"SPEC_ROOT/appendices/entities.md#run\"><code>run-&lt;index&gt;</code></a> entity:\n<code>_run-1</code>, <code>_run-2</code>, <code>_run-3</code>, and so on\n(only nonnegative integers are allowed as run indices).</p>\n<p>If different entities apply,\nsuch as a different session indicated by [<code>ses-&lt;label&gt;</code>][SPEC_ROOT/appendices/entities.md#ses),\nor different acquisition parameters indicated by\n<a href=\"SPEC_ROOT/appendices/entities.md#acq\"><code>acq-&lt;label&gt;</code></a>,\nthen <code>run</code> is not needed to distinguish the scans and MAY be omitted.</p>", "type": "string", "format": "index", "required": "optional"}, "chunk": {"name": "chunk", "display_name": "Chunk", "description": "<p>The <code>chunk-&lt;index&gt;</code> key/value pair is used to distinguish between images of\nthe same physical sample with different fields of view acquired in the same\nimaging experiment.\nThis entity applies to collections of 2D images, 3D volumes or 4D volume series\n(for example, diffusion weighted images), and may be used to indicate different\nanatomical structures or regions of the same structure.</p>", "type": "string", "format": "index", "required": "optional"}}, "value": "T1rho", "display_name": "T1 in rotating frame (T1 rho) image", "description": "<p>In seconds (s).\nT1-rho maps are REQUIRED to use this suffix regardless of the method used to\ngenerate them.</p>\n<br><code>parametric</code>", "unit": "s"}, {"entities": {"subject": {"name": "sub", "display_name": "Subject", "description": "<p>A person or animal participating in the study.</p>", "type": "string", "format": "label", "required": "required"}, "session": {"name": "ses", "display_name": "Session", "description": "<p>A logical grouping of neuroimaging and behavioral data consistent across subjects.\nSession can (but doesn't have to) be synonymous to a visit in a longitudinal study.\nIn general, subjects will stay in the scanner during one session.\nHowever, for example, if a subject has to leave the scanner room and then\nbe re-positioned on the scanner bed, the set of MRI acquisitions will still\nbe considered as a session and match sessions acquired in other subjects.\nSimilarly, in situations where different data types are obtained over\nseveral visits (for example fMRI on one day followed by DWI the day after)\nthose can be grouped in one session.</p>\n<p>Defining multiple sessions is appropriate when several identical or similar\ndata acquisitions are planned and performed on all -or most- subjects,\noften in the case of some intervention between sessions\n(for example, training).</p>", "type": "string", "format": "label", "required": "optional"}, "task": {"name": "task", "display_name": "Task", "description": "<p>A set of structured activities performed by the participant.\nTasks are usually accompanied by stimuli and responses, and can greatly vary in complexity.</p>\n<p>In the context of brain scanning, a task is always tied to one data acquisition.\nTherefore, even if during one acquisition the subject performed multiple conceptually different behaviors\n(with different sets of instructions) they will be considered one (combined) task.</p>\n<p>While tasks may be repeated across multiple acquisitions,\na given task may have different sets of stimuli (for example, randomized order) and participant responses\nacross subjects, sessions, and runs.</p>\n<p>The <code>task-&lt;label&gt;</code> MUST be consistent across subjects and sessions.</p>\n<p>Files with the <code>task-&lt;label&gt;</code> entity SHOULD have an associated\n<a href=\"SPEC_ROOT/modality-specific-files/task-events.md#task-events\">events file</a>,\nas well as certain metadata fields in the associated JSON file.</p>\n<p>For the purpose of this specification we consider the so-called \"resting state\" a task,\nalthough events files are not expected for resting state data.\nAdditionally, a common convention in the specification is to include the word \"rest\" in\nthe <code>task</code> label for resting state files (for example, <code>task-rest</code>).</p>", "type": "string", "format": "label", "required": "optional"}, "acquisition": {"name": "acq", "display_name": "Acquisition", "description": "<p>The <code>acq-&lt;label&gt;</code> entity corresponds to a custom label the user MAY use to distinguish\na different set of parameters used for acquiring the same modality.</p>\n<p>For example, this should be used when a study includes two T1w images -\none full brain low resolution and one restricted field of view but high resolution.\nIn such case two files could have the following names:\n<code>sub-01_acq-highres_T1w.nii.gz</code> and <code>sub-01_acq-lowres_T1w.nii.gz</code>;\nhowever, the user is free to choose any other label than <code>highres</code> and <code>lowres</code> as long\nas they are consistent across subjects and sessions.</p>\n<p>In case different sequences are used to record the same modality\n(for example, <code>RARE</code> and <code>FLASH</code> for T1w)\nthis field can also be used to make that distinction.\nThe level of detail at which the distinction is made\n(for example, just between <code>RARE</code> and <code>FLASH</code>, or between <code>RARE</code>, <code>FLASH</code>, and <code>FLASHsubsampled</code>)\nremains at the discretion of the researcher.</p>", "type": "string", "format": "label", "required": "optional"}, "ceagent": {"name": "ce", "display_name": "Contrast Enhancing Agent", "description": "<p>The <code>ce-&lt;label&gt;</code> entity can be used to distinguish sequences using different contrast enhanced images.\nThe label is the name of the contrast agent.</p>\n<p>This entity represents the <code>\"ContrastBolusIngredient\"</code> metadata field.\nTherefore, if the <code>ce-&lt;label&gt;</code> entity is present in a filename,\n<code>\"ContrastBolusIngredient\"</code> MAY also be added in the JSON file, with the same label.</p>", "type": "string", "format": "label", "required": "optional"}, "reconstruction": {"name": "rec", "display_name": "Reconstruction", "description": "<p>The <code>rec-&lt;label&gt;</code> entity can be used to distinguish different reconstruction algorithms\n(for example, <code>MoCo</code> for the ones using motion correction).</p>", "type": "string", "format": "label", "required": "optional"}, "run": {"name": "run", "display_name": "Run", "description": "<p>The <code>run-&lt;index&gt;</code> entity is used to distinguish separate data acquisitions with the same acquisition parameters\nand (other) entities.</p>\n<p>If several data acquisitions (for example, MRI scans or EEG recordings)\nwith the same acquisition parameters are acquired in the same session,\nthey MUST be indexed with the <a href=\"SPEC_ROOT/appendices/entities.md#run\"><code>run-&lt;index&gt;</code></a> entity:\n<code>_run-1</code>, <code>_run-2</code>, <code>_run-3</code>, and so on\n(only nonnegative integers are allowed as run indices).</p>\n<p>If different entities apply,\nsuch as a different session indicated by [<code>ses-&lt;label&gt;</code>][SPEC_ROOT/appendices/entities.md#ses),\nor different acquisition parameters indicated by\n<a href=\"SPEC_ROOT/appendices/entities.md#acq\"><code>acq-&lt;label&gt;</code></a>,\nthen <code>run</code> is not needed to distinguish the scans and MAY be omitted.</p>", "type": "string", "format": "index", "required": "optional"}, "chunk": {"name": "chunk", "display_name": "Chunk", "description": "<p>The <code>chunk-&lt;index&gt;</code> key/value pair is used to distinguish between images of\nthe same physical sample with different fields of view acquired in the same\nimaging experiment.\nThis entity applies to collections of 2D images, 3D volumes or 4D volume series\n(for example, diffusion weighted images), and may be used to indicate different\nanatomical structures or regions of the same structure.</p>", "type": "string", "format": "index", "required": "optional"}}, "value": "MWFmap", "display_name": "Myelin water fraction image", "description": "<p>In arbitrary units (arbitrary).\nMWF maps are REQUIRED to use this suffix regardless of the method used to\ngenerate them.\nMWF intensity values are RECOMMENDED to be represented in percentage in the\nrange of 0-100%.</p>\n<br><code>parametric</code>", "unit": "arbitrary", "minValue": 0, "maxValue": 100}, {"entities": {"subject": {"name": "sub", "display_name": "Subject", "description": "<p>A person or animal participating in the study.</p>", "type": "string", "format": "label", "required": "required"}, "session": {"name": "ses", "display_name": "Session", "description": "<p>A logical grouping of neuroimaging and behavioral data consistent across subjects.\nSession can (but doesn't have to) be synonymous to a visit in a longitudinal study.\nIn general, subjects will stay in the scanner during one session.\nHowever, for example, if a subject has to leave the scanner room and then\nbe re-positioned on the scanner bed, the set of MRI acquisitions will still\nbe considered as a session and match sessions acquired in other subjects.\nSimilarly, in situations where different data types are obtained over\nseveral visits (for example fMRI on one day followed by DWI the day after)\nthose can be grouped in one session.</p>\n<p>Defining multiple sessions is appropriate when several identical or similar\ndata acquisitions are planned and performed on all -or most- subjects,\noften in the case of some intervention between sessions\n(for example, training).</p>", "type": "string", "format": "label", "required": "optional"}, "task": {"name": "task", "display_name": "Task", "description": "<p>A set of structured activities performed by the participant.\nTasks are usually accompanied by stimuli and responses, and can greatly vary in complexity.</p>\n<p>In the context of brain scanning, a task is always tied to one data acquisition.\nTherefore, even if during one acquisition the subject performed multiple conceptually different behaviors\n(with different sets of instructions) they will be considered one (combined) task.</p>\n<p>While tasks may be repeated across multiple acquisitions,\na given task may have different sets of stimuli (for example, randomized order) and participant responses\nacross subjects, sessions, and runs.</p>\n<p>The <code>task-&lt;label&gt;</code> MUST be consistent across subjects and sessions.</p>\n<p>Files with the <code>task-&lt;label&gt;</code> entity SHOULD have an associated\n<a href=\"SPEC_ROOT/modality-specific-files/task-events.md#task-events\">events file</a>,\nas well as certain metadata fields in the associated JSON file.</p>\n<p>For the purpose of this specification we consider the so-called \"resting state\" a task,\nalthough events files are not expected for resting state data.\nAdditionally, a common convention in the specification is to include the word \"rest\" in\nthe <code>task</code> label for resting state files (for example, <code>task-rest</code>).</p>", "type": "string", "format": "label", "required": "optional"}, "acquisition": {"name": "acq", "display_name": "Acquisition", "description": "<p>The <code>acq-&lt;label&gt;</code> entity corresponds to a custom label the user MAY use to distinguish\na different set of parameters used for acquiring the same modality.</p>\n<p>For example, this should be used when a study includes two T1w images -\none full brain low resolution and one restricted field of view but high resolution.\nIn such case two files could have the following names:\n<code>sub-01_acq-highres_T1w.nii.gz</code> and <code>sub-01_acq-lowres_T1w.nii.gz</code>;\nhowever, the user is free to choose any other label than <code>highres</code> and <code>lowres</code> as long\nas they are consistent across subjects and sessions.</p>\n<p>In case different sequences are used to record the same modality\n(for example, <code>RARE</code> and <code>FLASH</code> for T1w)\nthis field can also be used to make that distinction.\nThe level of detail at which the distinction is made\n(for example, just between <code>RARE</code> and <code>FLASH</code>, or between <code>RARE</code>, <code>FLASH</code>, and <code>FLASHsubsampled</code>)\nremains at the discretion of the researcher.</p>", "type": "string", "format": "label", "required": "optional"}, "ceagent": {"name": "ce", "display_name": "Contrast Enhancing Agent", "description": "<p>The <code>ce-&lt;label&gt;</code> entity can be used to distinguish sequences using different contrast enhanced images.\nThe label is the name of the contrast agent.</p>\n<p>This entity represents the <code>\"ContrastBolusIngredient\"</code> metadata field.\nTherefore, if the <code>ce-&lt;label&gt;</code> entity is present in a filename,\n<code>\"ContrastBolusIngredient\"</code> MAY also be added in the JSON file, with the same label.</p>", "type": "string", "format": "label", "required": "optional"}, "reconstruction": {"name": "rec", "display_name": "Reconstruction", "description": "<p>The <code>rec-&lt;label&gt;</code> entity can be used to distinguish different reconstruction algorithms\n(for example, <code>MoCo</code> for the ones using motion correction).</p>", "type": "string", "format": "label", "required": "optional"}, "run": {"name": "run", "display_name": "Run", "description": "<p>The <code>run-&lt;index&gt;</code> entity is used to distinguish separate data acquisitions with the same acquisition parameters\nand (other) entities.</p>\n<p>If several data acquisitions (for example, MRI scans or EEG recordings)\nwith the same acquisition parameters are acquired in the same session,\nthey MUST be indexed with the <a href=\"SPEC_ROOT/appendices/entities.md#run\"><code>run-&lt;index&gt;</code></a> entity:\n<code>_run-1</code>, <code>_run-2</code>, <code>_run-3</code>, and so on\n(only nonnegative integers are allowed as run indices).</p>\n<p>If different entities apply,\nsuch as a different session indicated by [<code>ses-&lt;label&gt;</code>][SPEC_ROOT/appendices/entities.md#ses),\nor different acquisition parameters indicated by\n<a href=\"SPEC_ROOT/appendices/entities.md#acq\"><code>acq-&lt;label&gt;</code></a>,\nthen <code>run</code> is not needed to distinguish the scans and MAY be omitted.</p>", "type": "string", "format": "index", "required": "optional"}, "chunk": {"name": "chunk", "display_name": "Chunk", "description": "<p>The <code>chunk-&lt;index&gt;</code> key/value pair is used to distinguish between images of\nthe same physical sample with different fields of view acquired in the same\nimaging experiment.\nThis entity applies to collections of 2D images, 3D volumes or 4D volume series\n(for example, diffusion weighted images), and may be used to indicate different\nanatomical structures or regions of the same structure.</p>", "type": "string", "format": "index", "required": "optional"}}, "value": "MTVmap", "display_name": "Macromolecular tissue volume (MTV) image", "description": "<p>In arbitrary units (arbitrary).\nMTV maps are REQUIRED to use this suffix regardless of the method used to\ngenerate them.</p>\n<br><code>parametric</code>", "unit": "arbitrary"}, {"entities": {"subject": {"name": "sub", "display_name": "Subject", "description": "<p>A person or animal participating in the study.</p>", "type": "string", "format": "label", "required": "required"}, "session": {"name": "ses", "display_name": "Session", "description": "<p>A logical grouping of neuroimaging and behavioral data consistent across subjects.\nSession can (but doesn't have to) be synonymous to a visit in a longitudinal study.\nIn general, subjects will stay in the scanner during one session.\nHowever, for example, if a subject has to leave the scanner room and then\nbe re-positioned on the scanner bed, the set of MRI acquisitions will still\nbe considered as a session and match sessions acquired in other subjects.\nSimilarly, in situations where different data types are obtained over\nseveral visits (for example fMRI on one day followed by DWI the day after)\nthose can be grouped in one session.</p>\n<p>Defining multiple sessions is appropriate when several identical or similar\ndata acquisitions are planned and performed on all -or most- subjects,\noften in the case of some intervention between sessions\n(for example, training).</p>", "type": "string", "format": "label", "required": "optional"}, "task": {"name": "task", "display_name": "Task", "description": "<p>A set of structured activities performed by the participant.\nTasks are usually accompanied by stimuli and responses, and can greatly vary in complexity.</p>\n<p>In the context of brain scanning, a task is always tied to one data acquisition.\nTherefore, even if during one acquisition the subject performed multiple conceptually different behaviors\n(with different sets of instructions) they will be considered one (combined) task.</p>\n<p>While tasks may be repeated across multiple acquisitions,\na given task may have different sets of stimuli (for example, randomized order) and participant responses\nacross subjects, sessions, and runs.</p>\n<p>The <code>task-&lt;label&gt;</code> MUST be consistent across subjects and sessions.</p>\n<p>Files with the <code>task-&lt;label&gt;</code> entity SHOULD have an associated\n<a href=\"SPEC_ROOT/modality-specific-files/task-events.md#task-events\">events file</a>,\nas well as certain metadata fields in the associated JSON file.</p>\n<p>For the purpose of this specification we consider the so-called \"resting state\" a task,\nalthough events files are not expected for resting state data.\nAdditionally, a common convention in the specification is to include the word \"rest\" in\nthe <code>task</code> label for resting state files (for example, <code>task-rest</code>).</p>", "type": "string", "format": "label", "required": "optional"}, "acquisition": {"name": "acq", "display_name": "Acquisition", "description": "<p>The <code>acq-&lt;label&gt;</code> entity corresponds to a custom label the user MAY use to distinguish\na different set of parameters used for acquiring the same modality.</p>\n<p>For example, this should be used when a study includes two T1w images -\none full brain low resolution and one restricted field of view but high resolution.\nIn such case two files could have the following names:\n<code>sub-01_acq-highres_T1w.nii.gz</code> and <code>sub-01_acq-lowres_T1w.nii.gz</code>;\nhowever, the user is free to choose any other label than <code>highres</code> and <code>lowres</code> as long\nas they are consistent across subjects and sessions.</p>\n<p>In case different sequences are used to record the same modality\n(for example, <code>RARE</code> and <code>FLASH</code> for T1w)\nthis field can also be used to make that distinction.\nThe level of detail at which the distinction is made\n(for example, just between <code>RARE</code> and <code>FLASH</code>, or between <code>RARE</code>, <code>FLASH</code>, and <code>FLASHsubsampled</code>)\nremains at the discretion of the researcher.</p>", "type": "string", "format": "label", "required": "optional"}, "ceagent": {"name": "ce", "display_name": "Contrast Enhancing Agent", "description": "<p>The <code>ce-&lt;label&gt;</code> entity can be used to distinguish sequences using different contrast enhanced images.\nThe label is the name of the contrast agent.</p>\n<p>This entity represents the <code>\"ContrastBolusIngredient\"</code> metadata field.\nTherefore, if the <code>ce-&lt;label&gt;</code> entity is present in a filename,\n<code>\"ContrastBolusIngredient\"</code> MAY also be added in the JSON file, with the same label.</p>", "type": "string", "format": "label", "required": "optional"}, "reconstruction": {"name": "rec", "display_name": "Reconstruction", "description": "<p>The <code>rec-&lt;label&gt;</code> entity can be used to distinguish different reconstruction algorithms\n(for example, <code>MoCo</code> for the ones using motion correction).</p>", "type": "string", "format": "label", "required": "optional"}, "run": {"name": "run", "display_name": "Run", "description": "<p>The <code>run-&lt;index&gt;</code> entity is used to distinguish separate data acquisitions with the same acquisition parameters\nand (other) entities.</p>\n<p>If several data acquisitions (for example, MRI scans or EEG recordings)\nwith the same acquisition parameters are acquired in the same session,\nthey MUST be indexed with the <a href=\"SPEC_ROOT/appendices/entities.md#run\"><code>run-&lt;index&gt;</code></a> entity:\n<code>_run-1</code>, <code>_run-2</code>, <code>_run-3</code>, and so on\n(only nonnegative integers are allowed as run indices).</p>\n<p>If different entities apply,\nsuch as a different session indicated by [<code>ses-&lt;label&gt;</code>][SPEC_ROOT/appendices/entities.md#ses),\nor different acquisition parameters indicated by\n<a href=\"SPEC_ROOT/appendices/entities.md#acq\"><code>acq-&lt;label&gt;</code></a>,\nthen <code>run</code> is not needed to distinguish the scans and MAY be omitted.</p>", "type": "string", "format": "index", "required": "optional"}, "chunk": {"name": "chunk", "display_name": "Chunk", "description": "<p>The <code>chunk-&lt;index&gt;</code> key/value pair is used to distinguish between images of\nthe same physical sample with different fields of view acquired in the same\nimaging experiment.\nThis entity applies to collections of 2D images, 3D volumes or 4D volume series\n(for example, diffusion weighted images), and may be used to indicate different\nanatomical structures or regions of the same structure.</p>", "type": "string", "format": "index", "required": "optional"}}, "value": "Chimap", "display_name": "Quantitative susceptibility map (QSM)", "description": "<p>In parts per million (ppm).\nQSM allows for determining the underlying magnetic susceptibility of tissue\n(Chi)\n(<a href=\"https://doi.org/10.1002/mrm.25358\">Wang &amp; Liu, 2014</a>).\nChi maps are REQUIRED to use this suffix regardless of the method used to\ngenerate them.</p>\n<br><code>parametric</code>", "unit": "ppm"}, {"entities": {"subject": {"name": "sub", "display_name": "Subject", "description": "<p>A person or animal participating in the study.</p>", "type": "string", "format": "label", "required": "required"}, "session": {"name": "ses", "display_name": "Session", "description": "<p>A logical grouping of neuroimaging and behavioral data consistent across subjects.\nSession can (but doesn't have to) be synonymous to a visit in a longitudinal study.\nIn general, subjects will stay in the scanner during one session.\nHowever, for example, if a subject has to leave the scanner room and then\nbe re-positioned on the scanner bed, the set of MRI acquisitions will still\nbe considered as a session and match sessions acquired in other subjects.\nSimilarly, in situations where different data types are obtained over\nseveral visits (for example fMRI on one day followed by DWI the day after)\nthose can be grouped in one session.</p>\n<p>Defining multiple sessions is appropriate when several identical or similar\ndata acquisitions are planned and performed on all -or most- subjects,\noften in the case of some intervention between sessions\n(for example, training).</p>", "type": "string", "format": "label", "required": "optional"}, "task": {"name": "task", "display_name": "Task", "description": "<p>A set of structured activities performed by the participant.\nTasks are usually accompanied by stimuli and responses, and can greatly vary in complexity.</p>\n<p>In the context of brain scanning, a task is always tied to one data acquisition.\nTherefore, even if during one acquisition the subject performed multiple conceptually different behaviors\n(with different sets of instructions) they will be considered one (combined) task.</p>\n<p>While tasks may be repeated across multiple acquisitions,\na given task may have different sets of stimuli (for example, randomized order) and participant responses\nacross subjects, sessions, and runs.</p>\n<p>The <code>task-&lt;label&gt;</code> MUST be consistent across subjects and sessions.</p>\n<p>Files with the <code>task-&lt;label&gt;</code> entity SHOULD have an associated\n<a href=\"SPEC_ROOT/modality-specific-files/task-events.md#task-events\">events file</a>,\nas well as certain metadata fields in the associated JSON file.</p>\n<p>For the purpose of this specification we consider the so-called \"resting state\" a task,\nalthough events files are not expected for resting state data.\nAdditionally, a common convention in the specification is to include the word \"rest\" in\nthe <code>task</code> label for resting state files (for example, <code>task-rest</code>).</p>", "type": "string", "format": "label", "required": "optional"}, "acquisition": {"name": "acq", "display_name": "Acquisition", "description": "<p>The <code>acq-&lt;label&gt;</code> entity corresponds to a custom label the user MAY use to distinguish\na different set of parameters used for acquiring the same modality.</p>\n<p>For example, this should be used when a study includes two T1w images -\none full brain low resolution and one restricted field of view but high resolution.\nIn such case two files could have the following names:\n<code>sub-01_acq-highres_T1w.nii.gz</code> and <code>sub-01_acq-lowres_T1w.nii.gz</code>;\nhowever, the user is free to choose any other label than <code>highres</code> and <code>lowres</code> as long\nas they are consistent across subjects and sessions.</p>\n<p>In case different sequences are used to record the same modality\n(for example, <code>RARE</code> and <code>FLASH</code> for T1w)\nthis field can also be used to make that distinction.\nThe level of detail at which the distinction is made\n(for example, just between <code>RARE</code> and <code>FLASH</code>, or between <code>RARE</code>, <code>FLASH</code>, and <code>FLASHsubsampled</code>)\nremains at the discretion of the researcher.</p>", "type": "string", "format": "label", "required": "optional"}, "ceagent": {"name": "ce", "display_name": "Contrast Enhancing Agent", "description": "<p>The <code>ce-&lt;label&gt;</code> entity can be used to distinguish sequences using different contrast enhanced images.\nThe label is the name of the contrast agent.</p>\n<p>This entity represents the <code>\"ContrastBolusIngredient\"</code> metadata field.\nTherefore, if the <code>ce-&lt;label&gt;</code> entity is present in a filename,\n<code>\"ContrastBolusIngredient\"</code> MAY also be added in the JSON file, with the same label.</p>", "type": "string", "format": "label", "required": "optional"}, "reconstruction": {"name": "rec", "display_name": "Reconstruction", "description": "<p>The <code>rec-&lt;label&gt;</code> entity can be used to distinguish different reconstruction algorithms\n(for example, <code>MoCo</code> for the ones using motion correction).</p>", "type": "string", "format": "label", "required": "optional"}, "run": {"name": "run", "display_name": "Run", "description": "<p>The <code>run-&lt;index&gt;</code> entity is used to distinguish separate data acquisitions with the same acquisition parameters\nand (other) entities.</p>\n<p>If several data acquisitions (for example, MRI scans or EEG recordings)\nwith the same acquisition parameters are acquired in the same session,\nthey MUST be indexed with the <a href=\"SPEC_ROOT/appendices/entities.md#run\"><code>run-&lt;index&gt;</code></a> entity:\n<code>_run-1</code>, <code>_run-2</code>, <code>_run-3</code>, and so on\n(only nonnegative integers are allowed as run indices).</p>\n<p>If different entities apply,\nsuch as a different session indicated by [<code>ses-&lt;label&gt;</code>][SPEC_ROOT/appendices/entities.md#ses),\nor different acquisition parameters indicated by\n<a href=\"SPEC_ROOT/appendices/entities.md#acq\"><code>acq-&lt;label&gt;</code></a>,\nthen <code>run</code> is not needed to distinguish the scans and MAY be omitted.</p>", "type": "string", "format": "index", "required": "optional"}, "chunk": {"name": "chunk", "display_name": "Chunk", "description": "<p>The <code>chunk-&lt;index&gt;</code> key/value pair is used to distinguish between images of\nthe same physical sample with different fields of view acquired in the same\nimaging experiment.\nThis entity applies to collections of 2D images, 3D volumes or 4D volume series\n(for example, diffusion weighted images), and may be used to indicate different\nanatomical structures or regions of the same structure.</p>", "type": "string", "format": "index", "required": "optional"}}, "value": "S0map", "display_name": "Observed signal amplitude (S0) image", "description": "<p>In arbitrary units (arbitrary).\nFor a multi-echo (typically fMRI) sequence, S0 maps index the baseline signal\nbefore exponential (T2-star) signal decay.\nIn other words: the exponential of the intercept for a linear decay model\nacross log-transformed echos. For more information, please see, for example,\n<a href=\"https://tedana.readthedocs.io/en/latest/\\\napproach.html#monoexponential-decay-model-fit\">the tedana documentation</a>.\nS0 maps are RECOMMENDED to use this suffix if derived from an ME-FMRI dataset.</p>\n<br><code>parametric</code>"}, {"entities": {"subject": {"name": "sub", "display_name": "Subject", "description": "<p>A person or animal participating in the study.</p>", "type": "string", "format": "label", "required": "required"}, "session": {"name": "ses", "display_name": "Session", "description": "<p>A logical grouping of neuroimaging and behavioral data consistent across subjects.\nSession can (but doesn't have to) be synonymous to a visit in a longitudinal study.\nIn general, subjects will stay in the scanner during one session.\nHowever, for example, if a subject has to leave the scanner room and then\nbe re-positioned on the scanner bed, the set of MRI acquisitions will still\nbe considered as a session and match sessions acquired in other subjects.\nSimilarly, in situations where different data types are obtained over\nseveral visits (for example fMRI on one day followed by DWI the day after)\nthose can be grouped in one session.</p>\n<p>Defining multiple sessions is appropriate when several identical or similar\ndata acquisitions are planned and performed on all -or most- subjects,\noften in the case of some intervention between sessions\n(for example, training).</p>", "type": "string", "format": "label", "required": "optional"}, "task": {"name": "task", "display_name": "Task", "description": "<p>A set of structured activities performed by the participant.\nTasks are usually accompanied by stimuli and responses, and can greatly vary in complexity.</p>\n<p>In the context of brain scanning, a task is always tied to one data acquisition.\nTherefore, even if during one acquisition the subject performed multiple conceptually different behaviors\n(with different sets of instructions) they will be considered one (combined) task.</p>\n<p>While tasks may be repeated across multiple acquisitions,\na given task may have different sets of stimuli (for example, randomized order) and participant responses\nacross subjects, sessions, and runs.</p>\n<p>The <code>task-&lt;label&gt;</code> MUST be consistent across subjects and sessions.</p>\n<p>Files with the <code>task-&lt;label&gt;</code> entity SHOULD have an associated\n<a href=\"SPEC_ROOT/modality-specific-files/task-events.md#task-events\">events file</a>,\nas well as certain metadata fields in the associated JSON file.</p>\n<p>For the purpose of this specification we consider the so-called \"resting state\" a task,\nalthough events files are not expected for resting state data.\nAdditionally, a common convention in the specification is to include the word \"rest\" in\nthe <code>task</code> label for resting state files (for example, <code>task-rest</code>).</p>", "type": "string", "format": "label", "required": "optional"}, "acquisition": {"name": "acq", "display_name": "Acquisition", "description": "<p>The <code>acq-&lt;label&gt;</code> entity corresponds to a custom label the user MAY use to distinguish\na different set of parameters used for acquiring the same modality.</p>\n<p>For example, this should be used when a study includes two T1w images -\none full brain low resolution and one restricted field of view but high resolution.\nIn such case two files could have the following names:\n<code>sub-01_acq-highres_T1w.nii.gz</code> and <code>sub-01_acq-lowres_T1w.nii.gz</code>;\nhowever, the user is free to choose any other label than <code>highres</code> and <code>lowres</code> as long\nas they are consistent across subjects and sessions.</p>\n<p>In case different sequences are used to record the same modality\n(for example, <code>RARE</code> and <code>FLASH</code> for T1w)\nthis field can also be used to make that distinction.\nThe level of detail at which the distinction is made\n(for example, just between <code>RARE</code> and <code>FLASH</code>, or between <code>RARE</code>, <code>FLASH</code>, and <code>FLASHsubsampled</code>)\nremains at the discretion of the researcher.</p>", "type": "string", "format": "label", "required": "optional"}, "ceagent": {"name": "ce", "display_name": "Contrast Enhancing Agent", "description": "<p>The <code>ce-&lt;label&gt;</code> entity can be used to distinguish sequences using different contrast enhanced images.\nThe label is the name of the contrast agent.</p>\n<p>This entity represents the <code>\"ContrastBolusIngredient\"</code> metadata field.\nTherefore, if the <code>ce-&lt;label&gt;</code> entity is present in a filename,\n<code>\"ContrastBolusIngredient\"</code> MAY also be added in the JSON file, with the same label.</p>", "type": "string", "format": "label", "required": "optional"}, "reconstruction": {"name": "rec", "display_name": "Reconstruction", "description": "<p>The <code>rec-&lt;label&gt;</code> entity can be used to distinguish different reconstruction algorithms\n(for example, <code>MoCo</code> for the ones using motion correction).</p>", "type": "string", "format": "label", "required": "optional"}, "run": {"name": "run", "display_name": "Run", "description": "<p>The <code>run-&lt;index&gt;</code> entity is used to distinguish separate data acquisitions with the same acquisition parameters\nand (other) entities.</p>\n<p>If several data acquisitions (for example, MRI scans or EEG recordings)\nwith the same acquisition parameters are acquired in the same session,\nthey MUST be indexed with the <a href=\"SPEC_ROOT/appendices/entities.md#run\"><code>run-&lt;index&gt;</code></a> entity:\n<code>_run-1</code>, <code>_run-2</code>, <code>_run-3</code>, and so on\n(only nonnegative integers are allowed as run indices).</p>\n<p>If different entities apply,\nsuch as a different session indicated by [<code>ses-&lt;label&gt;</code>][SPEC_ROOT/appendices/entities.md#ses),\nor different acquisition parameters indicated by\n<a href=\"SPEC_ROOT/appendices/entities.md#acq\"><code>acq-&lt;label&gt;</code></a>,\nthen <code>run</code> is not needed to distinguish the scans and MAY be omitted.</p>", "type": "string", "format": "index", "required": "optional"}, "chunk": {"name": "chunk", "display_name": "Chunk", "description": "<p>The <code>chunk-&lt;index&gt;</code> key/value pair is used to distinguish between images of\nthe same physical sample with different fields of view acquired in the same\nimaging experiment.\nThis entity applies to collections of 2D images, 3D volumes or 4D volume series\n(for example, diffusion weighted images), and may be used to indicate different\nanatomical structures or regions of the same structure.</p>", "type": "string", "format": "index", "required": "optional"}}, "value": "M0map", "display_name": "Equilibrium magnetization (M0) map", "description": "<p>In arbitrary units (arbitrary).\nA common quantitative MRI (qMRI) fitting variable that represents the amount\nof magnetization at thermal equilibrium.\nM0 maps are RECOMMENDED to use this suffix if generated by qMRI applications\n(for example, variable flip angle T1 mapping).</p>\n<br><code>parametric</code>", "unit": "arbitrary"}, {"entities": {"subject": {"name": "sub", "display_name": "Subject", "description": "<p>A person or animal participating in the study.</p>", "type": "string", "format": "label", "required": "required"}, "session": {"name": "ses", "display_name": "Session", "description": "<p>A logical grouping of neuroimaging and behavioral data consistent across subjects.\nSession can (but doesn't have to) be synonymous to a visit in a longitudinal study.\nIn general, subjects will stay in the scanner during one session.\nHowever, for example, if a subject has to leave the scanner room and then\nbe re-positioned on the scanner bed, the set of MRI acquisitions will still\nbe considered as a session and match sessions acquired in other subjects.\nSimilarly, in situations where different data types are obtained over\nseveral visits (for example fMRI on one day followed by DWI the day after)\nthose can be grouped in one session.</p>\n<p>Defining multiple sessions is appropriate when several identical or similar\ndata acquisitions are planned and performed on all -or most- subjects,\noften in the case of some intervention between sessions\n(for example, training).</p>", "type": "string", "format": "label", "required": "optional"}, "task": {"name": "task", "display_name": "Task", "description": "<p>A set of structured activities performed by the participant.\nTasks are usually accompanied by stimuli and responses, and can greatly vary in complexity.</p>\n<p>In the context of brain scanning, a task is always tied to one data acquisition.\nTherefore, even if during one acquisition the subject performed multiple conceptually different behaviors\n(with different sets of instructions) they will be considered one (combined) task.</p>\n<p>While tasks may be repeated across multiple acquisitions,\na given task may have different sets of stimuli (for example, randomized order) and participant responses\nacross subjects, sessions, and runs.</p>\n<p>The <code>task-&lt;label&gt;</code> MUST be consistent across subjects and sessions.</p>\n<p>Files with the <code>task-&lt;label&gt;</code> entity SHOULD have an associated\n<a href=\"SPEC_ROOT/modality-specific-files/task-events.md#task-events\">events file</a>,\nas well as certain metadata fields in the associated JSON file.</p>\n<p>For the purpose of this specification we consider the so-called \"resting state\" a task,\nalthough events files are not expected for resting state data.\nAdditionally, a common convention in the specification is to include the word \"rest\" in\nthe <code>task</code> label for resting state files (for example, <code>task-rest</code>).</p>", "type": "string", "format": "label", "required": "optional"}, "acquisition": {"name": "acq", "display_name": "Acquisition", "description": "<p>The <code>acq-&lt;label&gt;</code> entity corresponds to a custom label the user MAY use to distinguish\na different set of parameters used for acquiring the same modality.</p>\n<p>For example, this should be used when a study includes two T1w images -\none full brain low resolution and one restricted field of view but high resolution.\nIn such case two files could have the following names:\n<code>sub-01_acq-highres_T1w.nii.gz</code> and <code>sub-01_acq-lowres_T1w.nii.gz</code>;\nhowever, the user is free to choose any other label than <code>highres</code> and <code>lowres</code> as long\nas they are consistent across subjects and sessions.</p>\n<p>In case different sequences are used to record the same modality\n(for example, <code>RARE</code> and <code>FLASH</code> for T1w)\nthis field can also be used to make that distinction.\nThe level of detail at which the distinction is made\n(for example, just between <code>RARE</code> and <code>FLASH</code>, or between <code>RARE</code>, <code>FLASH</code>, and <code>FLASHsubsampled</code>)\nremains at the discretion of the researcher.</p>", "type": "string", "format": "label", "required": "optional"}, "ceagent": {"name": "ce", "display_name": "Contrast Enhancing Agent", "description": "<p>The <code>ce-&lt;label&gt;</code> entity can be used to distinguish sequences using different contrast enhanced images.\nThe label is the name of the contrast agent.</p>\n<p>This entity represents the <code>\"ContrastBolusIngredient\"</code> metadata field.\nTherefore, if the <code>ce-&lt;label&gt;</code> entity is present in a filename,\n<code>\"ContrastBolusIngredient\"</code> MAY also be added in the JSON file, with the same label.</p>", "type": "string", "format": "label", "required": "optional"}, "reconstruction": {"name": "rec", "display_name": "Reconstruction", "description": "<p>The <code>rec-&lt;label&gt;</code> entity can be used to distinguish different reconstruction algorithms\n(for example, <code>MoCo</code> for the ones using motion correction).</p>", "type": "string", "format": "label", "required": "optional"}, "run": {"name": "run", "display_name": "Run", "description": "<p>The <code>run-&lt;index&gt;</code> entity is used to distinguish separate data acquisitions with the same acquisition parameters\nand (other) entities.</p>\n<p>If several data acquisitions (for example, MRI scans or EEG recordings)\nwith the same acquisition parameters are acquired in the same session,\nthey MUST be indexed with the <a href=\"SPEC_ROOT/appendices/entities.md#run\"><code>run-&lt;index&gt;</code></a> entity:\n<code>_run-1</code>, <code>_run-2</code>, <code>_run-3</code>, and so on\n(only nonnegative integers are allowed as run indices).</p>\n<p>If different entities apply,\nsuch as a different session indicated by [<code>ses-&lt;label&gt;</code>][SPEC_ROOT/appendices/entities.md#ses),\nor different acquisition parameters indicated by\n<a href=\"SPEC_ROOT/appendices/entities.md#acq\"><code>acq-&lt;label&gt;</code></a>,\nthen <code>run</code> is not needed to distinguish the scans and MAY be omitted.</p>", "type": "string", "format": "index", "required": "optional"}, "modality": {"name": "mod", "display_name": "Corresponding Modality", "description": "<p>The <code>mod-&lt;label&gt;</code> entity corresponds to modality label for defacing\nmasks, for example, T1w, inplaneT1, referenced by a defacemask image.\nFor example, <code>sub-01_mod-T1w_defacemask.nii.gz</code>.</p>", "type": "string", "format": "label", "required": "optional"}, "chunk": {"name": "chunk", "display_name": "Chunk", "description": "<p>The <code>chunk-&lt;index&gt;</code> key/value pair is used to distinguish between images of\nthe same physical sample with different fields of view acquired in the same\nimaging experiment.\nThis entity applies to collections of 2D images, 3D volumes or 4D volume series\n(for example, diffusion weighted images), and may be used to indicate different\nanatomical structures or regions of the same structure.</p>", "type": "string", "format": "index", "required": "optional"}}, "value": "defacemask", "display_name": "Defacing Mask", "description": "<p>A binary mask that was used to remove facial features from an anatomical MRI\nimage.</p>\n<br><code>defacemask</code>"}, {"entities": {"subject": {"name": "sub", "display_name": "Subject", "description": "<p>A person or animal participating in the study.</p>", "type": "string", "format": "label", "required": "required"}, "session": {"name": "ses", "display_name": "Session", "description": "<p>A logical grouping of neuroimaging and behavioral data consistent across subjects.\nSession can (but doesn't have to) be synonymous to a visit in a longitudinal study.\nIn general, subjects will stay in the scanner during one session.\nHowever, for example, if a subject has to leave the scanner room and then\nbe re-positioned on the scanner bed, the set of MRI acquisitions will still\nbe considered as a session and match sessions acquired in other subjects.\nSimilarly, in situations where different data types are obtained over\nseveral visits (for example fMRI on one day followed by DWI the day after)\nthose can be grouped in one session.</p>\n<p>Defining multiple sessions is appropriate when several identical or similar\ndata acquisitions are planned and performed on all -or most- subjects,\noften in the case of some intervention between sessions\n(for example, training).</p>", "type": "string", "format": "label", "required": "optional"}, "task": {"name": "task", "display_name": "Task", "description": "<p>A set of structured activities performed by the participant.\nTasks are usually accompanied by stimuli and responses, and can greatly vary in complexity.</p>\n<p>In the context of brain scanning, a task is always tied to one data acquisition.\nTherefore, even if during one acquisition the subject performed multiple conceptually different behaviors\n(with different sets of instructions) they will be considered one (combined) task.</p>\n<p>While tasks may be repeated across multiple acquisitions,\na given task may have different sets of stimuli (for example, randomized order) and participant responses\nacross subjects, sessions, and runs.</p>\n<p>The <code>task-&lt;label&gt;</code> MUST be consistent across subjects and sessions.</p>\n<p>Files with the <code>task-&lt;label&gt;</code> entity SHOULD have an associated\n<a href=\"SPEC_ROOT/modality-specific-files/task-events.md#task-events\">events file</a>,\nas well as certain metadata fields in the associated JSON file.</p>\n<p>For the purpose of this specification we consider the so-called \"resting state\" a task,\nalthough events files are not expected for resting state data.\nAdditionally, a common convention in the specification is to include the word \"rest\" in\nthe <code>task</code> label for resting state files (for example, <code>task-rest</code>).</p>", "type": "string", "format": "label", "required": "optional"}, "acquisition": {"name": "acq", "display_name": "Acquisition", "description": "<p>The <code>acq-&lt;label&gt;</code> entity corresponds to a custom label the user MAY use to distinguish\na different set of parameters used for acquiring the same modality.</p>\n<p>For example, this should be used when a study includes two T1w images -\none full brain low resolution and one restricted field of view but high resolution.\nIn such case two files could have the following names:\n<code>sub-01_acq-highres_T1w.nii.gz</code> and <code>sub-01_acq-lowres_T1w.nii.gz</code>;\nhowever, the user is free to choose any other label than <code>highres</code> and <code>lowres</code> as long\nas they are consistent across subjects and sessions.</p>\n<p>In case different sequences are used to record the same modality\n(for example, <code>RARE</code> and <code>FLASH</code> for T1w)\nthis field can also be used to make that distinction.\nThe level of detail at which the distinction is made\n(for example, just between <code>RARE</code> and <code>FLASH</code>, or between <code>RARE</code>, <code>FLASH</code>, and <code>FLASHsubsampled</code>)\nremains at the discretion of the researcher.</p>", "type": "string", "format": "label", "required": "optional"}, "ceagent": {"name": "ce", "display_name": "Contrast Enhancing Agent", "description": "<p>The <code>ce-&lt;label&gt;</code> entity can be used to distinguish sequences using different contrast enhanced images.\nThe label is the name of the contrast agent.</p>\n<p>This entity represents the <code>\"ContrastBolusIngredient\"</code> metadata field.\nTherefore, if the <code>ce-&lt;label&gt;</code> entity is present in a filename,\n<code>\"ContrastBolusIngredient\"</code> MAY also be added in the JSON file, with the same label.</p>", "type": "string", "format": "label", "required": "optional"}, "reconstruction": {"name": "rec", "display_name": "Reconstruction", "description": "<p>The <code>rec-&lt;label&gt;</code> entity can be used to distinguish different reconstruction algorithms\n(for example, <code>MoCo</code> for the ones using motion correction).</p>", "type": "string", "format": "label", "required": "optional"}, "run": {"name": "run", "display_name": "Run", "description": "<p>The <code>run-&lt;index&gt;</code> entity is used to distinguish separate data acquisitions with the same acquisition parameters\nand (other) entities.</p>\n<p>If several data acquisitions (for example, MRI scans or EEG recordings)\nwith the same acquisition parameters are acquired in the same session,\nthey MUST be indexed with the <a href=\"SPEC_ROOT/appendices/entities.md#run\"><code>run-&lt;index&gt;</code></a> entity:\n<code>_run-1</code>, <code>_run-2</code>, <code>_run-3</code>, and so on\n(only nonnegative integers are allowed as run indices).</p>\n<p>If different entities apply,\nsuch as a different session indicated by [<code>ses-&lt;label&gt;</code>][SPEC_ROOT/appendices/entities.md#ses),\nor different acquisition parameters indicated by\n<a href=\"SPEC_ROOT/appendices/entities.md#acq\"><code>acq-&lt;label&gt;</code></a>,\nthen <code>run</code> is not needed to distinguish the scans and MAY be omitted.</p>", "type": "string", "format": "index", "required": "optional"}, "echo": {"name": "echo", "display_name": "Echo", "description": "<p>If files belonging to an entity-linked file collection are acquired at different\necho times, the <code>echo-&lt;index&gt;</code> entity MUST be used to distinguish individual files.</p>\n<p>This entity represents the <code>\"EchoTime\"</code> metadata field.\nTherefore, if the <code>echo-&lt;index&gt;</code> entity is present in a filename,\n<code>\"EchoTime\"</code> MUST be defined in the associated metadata.\nPlease note that the <code>&lt;index&gt;</code> denotes the number/index (in the form of a nonnegative integer),\nnot the <code>\"EchoTime\"</code> value of the separate JSON file.</p>", "type": "string", "format": "index", "required": "required"}, "part": {"name": "part", "display_name": "Part", "description": "<p>This entity is used to indicate which component of the complex\nrepresentation of the MRI signal is represented in voxel data.\nThe <code>part-&lt;label&gt;</code> entity is associated with the DICOM Tag\n<code>0008, 9208</code>.\nAllowed label values for this entity are <code>phase</code>, <code>mag</code>, <code>real</code> and <code>imag</code>,\nwhich are typically used in <code>part-mag</code>/<code>part-phase</code> or\n<code>part-real</code>/<code>part-imag</code> pairs of files.</p>\n<p>Phase images MAY be in radians or in arbitrary units.\nThe sidecar JSON file MUST include the <code>\"Units\"</code> of the <code>phase</code> image.\nThe possible options are <code>\"rad\"</code> or <code>\"arbitrary\"</code>.</p>\n<p>When there is only a magnitude image of a given type, the <code>part</code> entity MAY be\nomitted.</p>", "type": "string", "format": "label", "enum": ["mag", "phase", "real", "imag"], "required": "optional"}, "chunk": {"name": "chunk", "display_name": "Chunk", "description": "<p>The <code>chunk-&lt;index&gt;</code> key/value pair is used to distinguish between images of\nthe same physical sample with different fields of view acquired in the same\nimaging experiment.\nThis entity applies to collections of 2D images, 3D volumes or 4D volume series\n(for example, diffusion weighted images), and may be used to indicate different\nanatomical structures or regions of the same structure.</p>", "type": "string", "format": "index", "required": "optional"}}, "value": "MESE", "display_name": "Multi-echo Spin Echo", "description": "<p>The MESE method involves multiple spin echo images acquired at different echo\ntimes and is primarily used for T2 mapping.\nPlease note that this suffix is not intended for the logical grouping of\nimages acquired using an Echo Planar Imaging (EPI) readout.</p>\n<br><code>multiecho</code>"}, {"entities": {"subject": {"name": "sub", "display_name": "Subject", "description": "<p>A person or animal participating in the study.</p>", "type": "string", "format": "label", "required": "required"}, "session": {"name": "ses", "display_name": "Session", "description": "<p>A logical grouping of neuroimaging and behavioral data consistent across subjects.\nSession can (but doesn't have to) be synonymous to a visit in a longitudinal study.\nIn general, subjects will stay in the scanner during one session.\nHowever, for example, if a subject has to leave the scanner room and then\nbe re-positioned on the scanner bed, the set of MRI acquisitions will still\nbe considered as a session and match sessions acquired in other subjects.\nSimilarly, in situations where different data types are obtained over\nseveral visits (for example fMRI on one day followed by DWI the day after)\nthose can be grouped in one session.</p>\n<p>Defining multiple sessions is appropriate when several identical or similar\ndata acquisitions are planned and performed on all -or most- subjects,\noften in the case of some intervention between sessions\n(for example, training).</p>", "type": "string", "format": "label", "required": "optional"}, "task": {"name": "task", "display_name": "Task", "description": "<p>A set of structured activities performed by the participant.\nTasks are usually accompanied by stimuli and responses, and can greatly vary in complexity.</p>\n<p>In the context of brain scanning, a task is always tied to one data acquisition.\nTherefore, even if during one acquisition the subject performed multiple conceptually different behaviors\n(with different sets of instructions) they will be considered one (combined) task.</p>\n<p>While tasks may be repeated across multiple acquisitions,\na given task may have different sets of stimuli (for example, randomized order) and participant responses\nacross subjects, sessions, and runs.</p>\n<p>The <code>task-&lt;label&gt;</code> MUST be consistent across subjects and sessions.</p>\n<p>Files with the <code>task-&lt;label&gt;</code> entity SHOULD have an associated\n<a href=\"SPEC_ROOT/modality-specific-files/task-events.md#task-events\">events file</a>,\nas well as certain metadata fields in the associated JSON file.</p>\n<p>For the purpose of this specification we consider the so-called \"resting state\" a task,\nalthough events files are not expected for resting state data.\nAdditionally, a common convention in the specification is to include the word \"rest\" in\nthe <code>task</code> label for resting state files (for example, <code>task-rest</code>).</p>", "type": "string", "format": "label", "required": "optional"}, "acquisition": {"name": "acq", "display_name": "Acquisition", "description": "<p>The <code>acq-&lt;label&gt;</code> entity corresponds to a custom label the user MAY use to distinguish\na different set of parameters used for acquiring the same modality.</p>\n<p>For example, this should be used when a study includes two T1w images -\none full brain low resolution and one restricted field of view but high resolution.\nIn such case two files could have the following names:\n<code>sub-01_acq-highres_T1w.nii.gz</code> and <code>sub-01_acq-lowres_T1w.nii.gz</code>;\nhowever, the user is free to choose any other label than <code>highres</code> and <code>lowres</code> as long\nas they are consistent across subjects and sessions.</p>\n<p>In case different sequences are used to record the same modality\n(for example, <code>RARE</code> and <code>FLASH</code> for T1w)\nthis field can also be used to make that distinction.\nThe level of detail at which the distinction is made\n(for example, just between <code>RARE</code> and <code>FLASH</code>, or between <code>RARE</code>, <code>FLASH</code>, and <code>FLASHsubsampled</code>)\nremains at the discretion of the researcher.</p>", "type": "string", "format": "label", "required": "optional"}, "ceagent": {"name": "ce", "display_name": "Contrast Enhancing Agent", "description": "<p>The <code>ce-&lt;label&gt;</code> entity can be used to distinguish sequences using different contrast enhanced images.\nThe label is the name of the contrast agent.</p>\n<p>This entity represents the <code>\"ContrastBolusIngredient\"</code> metadata field.\nTherefore, if the <code>ce-&lt;label&gt;</code> entity is present in a filename,\n<code>\"ContrastBolusIngredient\"</code> MAY also be added in the JSON file, with the same label.</p>", "type": "string", "format": "label", "required": "optional"}, "reconstruction": {"name": "rec", "display_name": "Reconstruction", "description": "<p>The <code>rec-&lt;label&gt;</code> entity can be used to distinguish different reconstruction algorithms\n(for example, <code>MoCo</code> for the ones using motion correction).</p>", "type": "string", "format": "label", "required": "optional"}, "run": {"name": "run", "display_name": "Run", "description": "<p>The <code>run-&lt;index&gt;</code> entity is used to distinguish separate data acquisitions with the same acquisition parameters\nand (other) entities.</p>\n<p>If several data acquisitions (for example, MRI scans or EEG recordings)\nwith the same acquisition parameters are acquired in the same session,\nthey MUST be indexed with the <a href=\"SPEC_ROOT/appendices/entities.md#run\"><code>run-&lt;index&gt;</code></a> entity:\n<code>_run-1</code>, <code>_run-2</code>, <code>_run-3</code>, and so on\n(only nonnegative integers are allowed as run indices).</p>\n<p>If different entities apply,\nsuch as a different session indicated by [<code>ses-&lt;label&gt;</code>][SPEC_ROOT/appendices/entities.md#ses),\nor different acquisition parameters indicated by\n<a href=\"SPEC_ROOT/appendices/entities.md#acq\"><code>acq-&lt;label&gt;</code></a>,\nthen <code>run</code> is not needed to distinguish the scans and MAY be omitted.</p>", "type": "string", "format": "index", "required": "optional"}, "echo": {"name": "echo", "display_name": "Echo", "description": "<p>If files belonging to an entity-linked file collection are acquired at different\necho times, the <code>echo-&lt;index&gt;</code> entity MUST be used to distinguish individual files.</p>\n<p>This entity represents the <code>\"EchoTime\"</code> metadata field.\nTherefore, if the <code>echo-&lt;index&gt;</code> entity is present in a filename,\n<code>\"EchoTime\"</code> MUST be defined in the associated metadata.\nPlease note that the <code>&lt;index&gt;</code> denotes the number/index (in the form of a nonnegative integer),\nnot the <code>\"EchoTime\"</code> value of the separate JSON file.</p>", "type": "string", "format": "index", "required": "required"}, "part": {"name": "part", "display_name": "Part", "description": "<p>This entity is used to indicate which component of the complex\nrepresentation of the MRI signal is represented in voxel data.\nThe <code>part-&lt;label&gt;</code> entity is associated with the DICOM Tag\n<code>0008, 9208</code>.\nAllowed label values for this entity are <code>phase</code>, <code>mag</code>, <code>real</code> and <code>imag</code>,\nwhich are typically used in <code>part-mag</code>/<code>part-phase</code> or\n<code>part-real</code>/<code>part-imag</code> pairs of files.</p>\n<p>Phase images MAY be in radians or in arbitrary units.\nThe sidecar JSON file MUST include the <code>\"Units\"</code> of the <code>phase</code> image.\nThe possible options are <code>\"rad\"</code> or <code>\"arbitrary\"</code>.</p>\n<p>When there is only a magnitude image of a given type, the <code>part</code> entity MAY be\nomitted.</p>", "type": "string", "format": "label", "enum": ["mag", "phase", "real", "imag"], "required": "optional"}, "chunk": {"name": "chunk", "display_name": "Chunk", "description": "<p>The <code>chunk-&lt;index&gt;</code> key/value pair is used to distinguish between images of\nthe same physical sample with different fields of view acquired in the same\nimaging experiment.\nThis entity applies to collections of 2D images, 3D volumes or 4D volume series\n(for example, diffusion weighted images), and may be used to indicate different\nanatomical structures or regions of the same structure.</p>", "type": "string", "format": "index", "required": "optional"}}, "value": "MEGRE", "display_name": "Multi-echo Gradient Recalled Echo", "description": "<p>Anatomical gradient echo images acquired at different echo times.\nPlease note that this suffix is not intended for the logical grouping of\nimages acquired using an Echo Planar Imaging (EPI) readout.</p>\n<br><code>multiecho</code>"}, {"entities": {"subject": {"name": "sub", "display_name": "Subject", "description": "<p>A person or animal participating in the study.</p>", "type": "string", "format": "label", "required": "required"}, "session": {"name": "ses", "display_name": "Session", "description": "<p>A logical grouping of neuroimaging and behavioral data consistent across subjects.\nSession can (but doesn't have to) be synonymous to a visit in a longitudinal study.\nIn general, subjects will stay in the scanner during one session.\nHowever, for example, if a subject has to leave the scanner room and then\nbe re-positioned on the scanner bed, the set of MRI acquisitions will still\nbe considered as a session and match sessions acquired in other subjects.\nSimilarly, in situations where different data types are obtained over\nseveral visits (for example fMRI on one day followed by DWI the day after)\nthose can be grouped in one session.</p>\n<p>Defining multiple sessions is appropriate when several identical or similar\ndata acquisitions are planned and performed on all -or most- subjects,\noften in the case of some intervention between sessions\n(for example, training).</p>", "type": "string", "format": "label", "required": "optional"}, "task": {"name": "task", "display_name": "Task", "description": "<p>A set of structured activities performed by the participant.\nTasks are usually accompanied by stimuli and responses, and can greatly vary in complexity.</p>\n<p>In the context of brain scanning, a task is always tied to one data acquisition.\nTherefore, even if during one acquisition the subject performed multiple conceptually different behaviors\n(with different sets of instructions) they will be considered one (combined) task.</p>\n<p>While tasks may be repeated across multiple acquisitions,\na given task may have different sets of stimuli (for example, randomized order) and participant responses\nacross subjects, sessions, and runs.</p>\n<p>The <code>task-&lt;label&gt;</code> MUST be consistent across subjects and sessions.</p>\n<p>Files with the <code>task-&lt;label&gt;</code> entity SHOULD have an associated\n<a href=\"SPEC_ROOT/modality-specific-files/task-events.md#task-events\">events file</a>,\nas well as certain metadata fields in the associated JSON file.</p>\n<p>For the purpose of this specification we consider the so-called \"resting state\" a task,\nalthough events files are not expected for resting state data.\nAdditionally, a common convention in the specification is to include the word \"rest\" in\nthe <code>task</code> label for resting state files (for example, <code>task-rest</code>).</p>", "type": "string", "format": "label", "required": "optional"}, "acquisition": {"name": "acq", "display_name": "Acquisition", "description": "<p>The <code>acq-&lt;label&gt;</code> entity corresponds to a custom label the user MAY use to distinguish\na different set of parameters used for acquiring the same modality.</p>\n<p>For example, this should be used when a study includes two T1w images -\none full brain low resolution and one restricted field of view but high resolution.\nIn such case two files could have the following names:\n<code>sub-01_acq-highres_T1w.nii.gz</code> and <code>sub-01_acq-lowres_T1w.nii.gz</code>;\nhowever, the user is free to choose any other label than <code>highres</code> and <code>lowres</code> as long\nas they are consistent across subjects and sessions.</p>\n<p>In case different sequences are used to record the same modality\n(for example, <code>RARE</code> and <code>FLASH</code> for T1w)\nthis field can also be used to make that distinction.\nThe level of detail at which the distinction is made\n(for example, just between <code>RARE</code> and <code>FLASH</code>, or between <code>RARE</code>, <code>FLASH</code>, and <code>FLASHsubsampled</code>)\nremains at the discretion of the researcher.</p>", "type": "string", "format": "label", "required": "optional"}, "ceagent": {"name": "ce", "display_name": "Contrast Enhancing Agent", "description": "<p>The <code>ce-&lt;label&gt;</code> entity can be used to distinguish sequences using different contrast enhanced images.\nThe label is the name of the contrast agent.</p>\n<p>This entity represents the <code>\"ContrastBolusIngredient\"</code> metadata field.\nTherefore, if the <code>ce-&lt;label&gt;</code> entity is present in a filename,\n<code>\"ContrastBolusIngredient\"</code> MAY also be added in the JSON file, with the same label.</p>", "type": "string", "format": "label", "required": "optional"}, "reconstruction": {"name": "rec", "display_name": "Reconstruction", "description": "<p>The <code>rec-&lt;label&gt;</code> entity can be used to distinguish different reconstruction algorithms\n(for example, <code>MoCo</code> for the ones using motion correction).</p>", "type": "string", "format": "label", "required": "optional"}, "run": {"name": "run", "display_name": "Run", "description": "<p>The <code>run-&lt;index&gt;</code> entity is used to distinguish separate data acquisitions with the same acquisition parameters\nand (other) entities.</p>\n<p>If several data acquisitions (for example, MRI scans or EEG recordings)\nwith the same acquisition parameters are acquired in the same session,\nthey MUST be indexed with the <a href=\"SPEC_ROOT/appendices/entities.md#run\"><code>run-&lt;index&gt;</code></a> entity:\n<code>_run-1</code>, <code>_run-2</code>, <code>_run-3</code>, and so on\n(only nonnegative integers are allowed as run indices).</p>\n<p>If different entities apply,\nsuch as a different session indicated by [<code>ses-&lt;label&gt;</code>][SPEC_ROOT/appendices/entities.md#ses),\nor different acquisition parameters indicated by\n<a href=\"SPEC_ROOT/appendices/entities.md#acq\"><code>acq-&lt;label&gt;</code></a>,\nthen <code>run</code> is not needed to distinguish the scans and MAY be omitted.</p>", "type": "string", "format": "index", "required": "optional"}, "echo": {"name": "echo", "display_name": "Echo", "description": "<p>If files belonging to an entity-linked file collection are acquired at different\necho times, the <code>echo-&lt;index&gt;</code> entity MUST be used to distinguish individual files.</p>\n<p>This entity represents the <code>\"EchoTime\"</code> metadata field.\nTherefore, if the <code>echo-&lt;index&gt;</code> entity is present in a filename,\n<code>\"EchoTime\"</code> MUST be defined in the associated metadata.\nPlease note that the <code>&lt;index&gt;</code> denotes the number/index (in the form of a nonnegative integer),\nnot the <code>\"EchoTime\"</code> value of the separate JSON file.</p>", "type": "string", "format": "index", "required": "optional"}, "flip": {"name": "flip", "display_name": "Flip Angle", "description": "<p>If files belonging to an entity-linked file collection are acquired at different\nflip angles, the <code>_flip-&lt;index&gt;</code> entity pair MUST be used to distinguish\nindividual files.</p>\n<p>This entity represents the <code>\"FlipAngle\"</code> metadata field.\nTherefore, if the <code>flip-&lt;index&gt;</code> entity is present in a filename,\n<code>\"FlipAngle\"</code> MUST be defined in the associated metadata.\nPlease note that the <code>&lt;index&gt;</code> denotes the number/index (in the form of a nonnegative integer),\nnot the <code>\"FlipAngle\"</code> value of the separate JSON file.</p>", "type": "string", "format": "index", "required": "required"}, "part": {"name": "part", "display_name": "Part", "description": "<p>This entity is used to indicate which component of the complex\nrepresentation of the MRI signal is represented in voxel data.\nThe <code>part-&lt;label&gt;</code> entity is associated with the DICOM Tag\n<code>0008, 9208</code>.\nAllowed label values for this entity are <code>phase</code>, <code>mag</code>, <code>real</code> and <code>imag</code>,\nwhich are typically used in <code>part-mag</code>/<code>part-phase</code> or\n<code>part-real</code>/<code>part-imag</code> pairs of files.</p>\n<p>Phase images MAY be in radians or in arbitrary units.\nThe sidecar JSON file MUST include the <code>\"Units\"</code> of the <code>phase</code> image.\nThe possible options are <code>\"rad\"</code> or <code>\"arbitrary\"</code>.</p>\n<p>When there is only a magnitude image of a given type, the <code>part</code> entity MAY be\nomitted.</p>", "type": "string", "format": "label", "enum": ["mag", "phase", "real", "imag"], "required": "optional"}, "chunk": {"name": "chunk", "display_name": "Chunk", "description": "<p>The <code>chunk-&lt;index&gt;</code> key/value pair is used to distinguish between images of\nthe same physical sample with different fields of view acquired in the same\nimaging experiment.\nThis entity applies to collections of 2D images, 3D volumes or 4D volume series\n(for example, diffusion weighted images), and may be used to indicate different\nanatomical structures or regions of the same structure.</p>", "type": "string", "format": "index", "required": "optional"}}, "value": "VFA", "display_name": "Variable flip angle", "description": "<p>The VFA method involves at least two spoiled gradient echo (SPGR) of\nsteady-state free precession (SSFP) images acquired at different flip angles.\nDepending on the provided metadata fields and the sequence type,\ndata may be eligible for DESPOT1, DESPOT2 and their variants\n(<a href=\"https://doi.org/10.1002/mrm.20314\">Deoni et al. 2005</a>).</p>\n<br><code>multiflip</code>"}, {"entities": {"subject": {"name": "sub", "display_name": "Subject", "description": "<p>A person or animal participating in the study.</p>", "type": "string", "format": "label", "required": "required"}, "session": {"name": "ses", "display_name": "Session", "description": "<p>A logical grouping of neuroimaging and behavioral data consistent across subjects.\nSession can (but doesn't have to) be synonymous to a visit in a longitudinal study.\nIn general, subjects will stay in the scanner during one session.\nHowever, for example, if a subject has to leave the scanner room and then\nbe re-positioned on the scanner bed, the set of MRI acquisitions will still\nbe considered as a session and match sessions acquired in other subjects.\nSimilarly, in situations where different data types are obtained over\nseveral visits (for example fMRI on one day followed by DWI the day after)\nthose can be grouped in one session.</p>\n<p>Defining multiple sessions is appropriate when several identical or similar\ndata acquisitions are planned and performed on all -or most- subjects,\noften in the case of some intervention between sessions\n(for example, training).</p>", "type": "string", "format": "label", "required": "optional"}, "task": {"name": "task", "display_name": "Task", "description": "<p>A set of structured activities performed by the participant.\nTasks are usually accompanied by stimuli and responses, and can greatly vary in complexity.</p>\n<p>In the context of brain scanning, a task is always tied to one data acquisition.\nTherefore, even if during one acquisition the subject performed multiple conceptually different behaviors\n(with different sets of instructions) they will be considered one (combined) task.</p>\n<p>While tasks may be repeated across multiple acquisitions,\na given task may have different sets of stimuli (for example, randomized order) and participant responses\nacross subjects, sessions, and runs.</p>\n<p>The <code>task-&lt;label&gt;</code> MUST be consistent across subjects and sessions.</p>\n<p>Files with the <code>task-&lt;label&gt;</code> entity SHOULD have an associated\n<a href=\"SPEC_ROOT/modality-specific-files/task-events.md#task-events\">events file</a>,\nas well as certain metadata fields in the associated JSON file.</p>\n<p>For the purpose of this specification we consider the so-called \"resting state\" a task,\nalthough events files are not expected for resting state data.\nAdditionally, a common convention in the specification is to include the word \"rest\" in\nthe <code>task</code> label for resting state files (for example, <code>task-rest</code>).</p>", "type": "string", "format": "label", "required": "optional"}, "acquisition": {"name": "acq", "display_name": "Acquisition", "description": "<p>The <code>acq-&lt;label&gt;</code> entity corresponds to a custom label the user MAY use to distinguish\na different set of parameters used for acquiring the same modality.</p>\n<p>For example, this should be used when a study includes two T1w images -\none full brain low resolution and one restricted field of view but high resolution.\nIn such case two files could have the following names:\n<code>sub-01_acq-highres_T1w.nii.gz</code> and <code>sub-01_acq-lowres_T1w.nii.gz</code>;\nhowever, the user is free to choose any other label than <code>highres</code> and <code>lowres</code> as long\nas they are consistent across subjects and sessions.</p>\n<p>In case different sequences are used to record the same modality\n(for example, <code>RARE</code> and <code>FLASH</code> for T1w)\nthis field can also be used to make that distinction.\nThe level of detail at which the distinction is made\n(for example, just between <code>RARE</code> and <code>FLASH</code>, or between <code>RARE</code>, <code>FLASH</code>, and <code>FLASHsubsampled</code>)\nremains at the discretion of the researcher.</p>", "type": "string", "format": "label", "required": "optional"}, "ceagent": {"name": "ce", "display_name": "Contrast Enhancing Agent", "description": "<p>The <code>ce-&lt;label&gt;</code> entity can be used to distinguish sequences using different contrast enhanced images.\nThe label is the name of the contrast agent.</p>\n<p>This entity represents the <code>\"ContrastBolusIngredient\"</code> metadata field.\nTherefore, if the <code>ce-&lt;label&gt;</code> entity is present in a filename,\n<code>\"ContrastBolusIngredient\"</code> MAY also be added in the JSON file, with the same label.</p>", "type": "string", "format": "label", "required": "optional"}, "reconstruction": {"name": "rec", "display_name": "Reconstruction", "description": "<p>The <code>rec-&lt;label&gt;</code> entity can be used to distinguish different reconstruction algorithms\n(for example, <code>MoCo</code> for the ones using motion correction).</p>", "type": "string", "format": "label", "required": "optional"}, "run": {"name": "run", "display_name": "Run", "description": "<p>The <code>run-&lt;index&gt;</code> entity is used to distinguish separate data acquisitions with the same acquisition parameters\nand (other) entities.</p>\n<p>If several data acquisitions (for example, MRI scans or EEG recordings)\nwith the same acquisition parameters are acquired in the same session,\nthey MUST be indexed with the <a href=\"SPEC_ROOT/appendices/entities.md#run\"><code>run-&lt;index&gt;</code></a> entity:\n<code>_run-1</code>, <code>_run-2</code>, <code>_run-3</code>, and so on\n(only nonnegative integers are allowed as run indices).</p>\n<p>If different entities apply,\nsuch as a different session indicated by [<code>ses-&lt;label&gt;</code>][SPEC_ROOT/appendices/entities.md#ses),\nor different acquisition parameters indicated by\n<a href=\"SPEC_ROOT/appendices/entities.md#acq\"><code>acq-&lt;label&gt;</code></a>,\nthen <code>run</code> is not needed to distinguish the scans and MAY be omitted.</p>", "type": "string", "format": "index", "required": "optional"}, "inversion": {"name": "inv", "display_name": "Inversion Time", "description": "<p>If files belonging to an entity-linked file collection are acquired at different inversion times,\nthe <code>inv-&lt;index&gt;</code> entity MUST be used to distinguish individual files.</p>\n<p>This entity represents the <code>\"InversionTime</code> metadata field.\nTherefore, if the <code>inv-&lt;index&gt;</code> entity is present in a filename,\n<code>\"InversionTime\"</code> MUST be defined in the associated metadata.\nPlease note that the <code>&lt;index&gt;</code> denotes the number/index (in the form of a nonnegative integer),\nnot the <code>\"InversionTime\"</code> value of the separate JSON file.</p>", "type": "string", "format": "index", "required": "required"}, "part": {"name": "part", "display_name": "Part", "description": "<p>This entity is used to indicate which component of the complex\nrepresentation of the MRI signal is represented in voxel data.\nThe <code>part-&lt;label&gt;</code> entity is associated with the DICOM Tag\n<code>0008, 9208</code>.\nAllowed label values for this entity are <code>phase</code>, <code>mag</code>, <code>real</code> and <code>imag</code>,\nwhich are typically used in <code>part-mag</code>/<code>part-phase</code> or\n<code>part-real</code>/<code>part-imag</code> pairs of files.</p>\n<p>Phase images MAY be in radians or in arbitrary units.\nThe sidecar JSON file MUST include the <code>\"Units\"</code> of the <code>phase</code> image.\nThe possible options are <code>\"rad\"</code> or <code>\"arbitrary\"</code>.</p>\n<p>When there is only a magnitude image of a given type, the <code>part</code> entity MAY be\nomitted.</p>", "type": "string", "format": "label", "enum": ["mag", "phase", "real", "imag"], "required": "optional"}, "chunk": {"name": "chunk", "display_name": "Chunk", "description": "<p>The <code>chunk-&lt;index&gt;</code> key/value pair is used to distinguish between images of\nthe same physical sample with different fields of view acquired in the same\nimaging experiment.\nThis entity applies to collections of 2D images, 3D volumes or 4D volume series\n(for example, diffusion weighted images), and may be used to indicate different\nanatomical structures or regions of the same structure.</p>", "type": "string", "format": "index", "required": "optional"}}, "value": "IRT1", "display_name": "Inversion recovery T1 mapping", "description": "<p>The IRT1 method involves multiple inversion recovery spin-echo images\nacquired at different inversion times\n(<a href=\"https://doi.org/10.1002/mrm.22497\">Barral et al. 2010</a>).</p>\n<br><code>multiinversion</code>"}, {"entities": {"subject": {"name": "sub", "display_name": "Subject", "description": "<p>A person or animal participating in the study.</p>", "type": "string", "format": "label", "required": "required"}, "session": {"name": "ses", "display_name": "Session", "description": "<p>A logical grouping of neuroimaging and behavioral data consistent across subjects.\nSession can (but doesn't have to) be synonymous to a visit in a longitudinal study.\nIn general, subjects will stay in the scanner during one session.\nHowever, for example, if a subject has to leave the scanner room and then\nbe re-positioned on the scanner bed, the set of MRI acquisitions will still\nbe considered as a session and match sessions acquired in other subjects.\nSimilarly, in situations where different data types are obtained over\nseveral visits (for example fMRI on one day followed by DWI the day after)\nthose can be grouped in one session.</p>\n<p>Defining multiple sessions is appropriate when several identical or similar\ndata acquisitions are planned and performed on all -or most- subjects,\noften in the case of some intervention between sessions\n(for example, training).</p>", "type": "string", "format": "label", "required": "optional"}, "task": {"name": "task", "display_name": "Task", "description": "<p>A set of structured activities performed by the participant.\nTasks are usually accompanied by stimuli and responses, and can greatly vary in complexity.</p>\n<p>In the context of brain scanning, a task is always tied to one data acquisition.\nTherefore, even if during one acquisition the subject performed multiple conceptually different behaviors\n(with different sets of instructions) they will be considered one (combined) task.</p>\n<p>While tasks may be repeated across multiple acquisitions,\na given task may have different sets of stimuli (for example, randomized order) and participant responses\nacross subjects, sessions, and runs.</p>\n<p>The <code>task-&lt;label&gt;</code> MUST be consistent across subjects and sessions.</p>\n<p>Files with the <code>task-&lt;label&gt;</code> entity SHOULD have an associated\n<a href=\"SPEC_ROOT/modality-specific-files/task-events.md#task-events\">events file</a>,\nas well as certain metadata fields in the associated JSON file.</p>\n<p>For the purpose of this specification we consider the so-called \"resting state\" a task,\nalthough events files are not expected for resting state data.\nAdditionally, a common convention in the specification is to include the word \"rest\" in\nthe <code>task</code> label for resting state files (for example, <code>task-rest</code>).</p>", "type": "string", "format": "label", "required": "optional"}, "acquisition": {"name": "acq", "display_name": "Acquisition", "description": "<p>The <code>acq-&lt;label&gt;</code> entity corresponds to a custom label the user MAY use to distinguish\na different set of parameters used for acquiring the same modality.</p>\n<p>For example, this should be used when a study includes two T1w images -\none full brain low resolution and one restricted field of view but high resolution.\nIn such case two files could have the following names:\n<code>sub-01_acq-highres_T1w.nii.gz</code> and <code>sub-01_acq-lowres_T1w.nii.gz</code>;\nhowever, the user is free to choose any other label than <code>highres</code> and <code>lowres</code> as long\nas they are consistent across subjects and sessions.</p>\n<p>In case different sequences are used to record the same modality\n(for example, <code>RARE</code> and <code>FLASH</code> for T1w)\nthis field can also be used to make that distinction.\nThe level of detail at which the distinction is made\n(for example, just between <code>RARE</code> and <code>FLASH</code>, or between <code>RARE</code>, <code>FLASH</code>, and <code>FLASHsubsampled</code>)\nremains at the discretion of the researcher.</p>", "type": "string", "format": "label", "required": "optional"}, "ceagent": {"name": "ce", "display_name": "Contrast Enhancing Agent", "description": "<p>The <code>ce-&lt;label&gt;</code> entity can be used to distinguish sequences using different contrast enhanced images.\nThe label is the name of the contrast agent.</p>\n<p>This entity represents the <code>\"ContrastBolusIngredient\"</code> metadata field.\nTherefore, if the <code>ce-&lt;label&gt;</code> entity is present in a filename,\n<code>\"ContrastBolusIngredient\"</code> MAY also be added in the JSON file, with the same label.</p>", "type": "string", "format": "label", "required": "optional"}, "reconstruction": {"name": "rec", "display_name": "Reconstruction", "description": "<p>The <code>rec-&lt;label&gt;</code> entity can be used to distinguish different reconstruction algorithms\n(for example, <code>MoCo</code> for the ones using motion correction).</p>", "type": "string", "format": "label", "required": "optional"}, "run": {"name": "run", "display_name": "Run", "description": "<p>The <code>run-&lt;index&gt;</code> entity is used to distinguish separate data acquisitions with the same acquisition parameters\nand (other) entities.</p>\n<p>If several data acquisitions (for example, MRI scans or EEG recordings)\nwith the same acquisition parameters are acquired in the same session,\nthey MUST be indexed with the <a href=\"SPEC_ROOT/appendices/entities.md#run\"><code>run-&lt;index&gt;</code></a> entity:\n<code>_run-1</code>, <code>_run-2</code>, <code>_run-3</code>, and so on\n(only nonnegative integers are allowed as run indices).</p>\n<p>If different entities apply,\nsuch as a different session indicated by [<code>ses-&lt;label&gt;</code>][SPEC_ROOT/appendices/entities.md#ses),\nor different acquisition parameters indicated by\n<a href=\"SPEC_ROOT/appendices/entities.md#acq\"><code>acq-&lt;label&gt;</code></a>,\nthen <code>run</code> is not needed to distinguish the scans and MAY be omitted.</p>", "type": "string", "format": "index", "required": "optional"}, "echo": {"name": "echo", "display_name": "Echo", "description": "<p>If files belonging to an entity-linked file collection are acquired at different\necho times, the <code>echo-&lt;index&gt;</code> entity MUST be used to distinguish individual files.</p>\n<p>This entity represents the <code>\"EchoTime\"</code> metadata field.\nTherefore, if the <code>echo-&lt;index&gt;</code> entity is present in a filename,\n<code>\"EchoTime\"</code> MUST be defined in the associated metadata.\nPlease note that the <code>&lt;index&gt;</code> denotes the number/index (in the form of a nonnegative integer),\nnot the <code>\"EchoTime\"</code> value of the separate JSON file.</p>", "type": "string", "format": "index", "required": "optional"}, "flip": {"name": "flip", "display_name": "Flip Angle", "description": "<p>If files belonging to an entity-linked file collection are acquired at different\nflip angles, the <code>_flip-&lt;index&gt;</code> entity pair MUST be used to distinguish\nindividual files.</p>\n<p>This entity represents the <code>\"FlipAngle\"</code> metadata field.\nTherefore, if the <code>flip-&lt;index&gt;</code> entity is present in a filename,\n<code>\"FlipAngle\"</code> MUST be defined in the associated metadata.\nPlease note that the <code>&lt;index&gt;</code> denotes the number/index (in the form of a nonnegative integer),\nnot the <code>\"FlipAngle\"</code> value of the separate JSON file.</p>", "type": "string", "format": "index", "required": "optional"}, "inversion": {"name": "inv", "display_name": "Inversion Time", "description": "<p>If files belonging to an entity-linked file collection are acquired at different inversion times,\nthe <code>inv-&lt;index&gt;</code> entity MUST be used to distinguish individual files.</p>\n<p>This entity represents the <code>\"InversionTime</code> metadata field.\nTherefore, if the <code>inv-&lt;index&gt;</code> entity is present in a filename,\n<code>\"InversionTime\"</code> MUST be defined in the associated metadata.\nPlease note that the <code>&lt;index&gt;</code> denotes the number/index (in the form of a nonnegative integer),\nnot the <code>\"InversionTime\"</code> value of the separate JSON file.</p>", "type": "string", "format": "index", "required": "required"}, "part": {"name": "part", "display_name": "Part", "description": "<p>This entity is used to indicate which component of the complex\nrepresentation of the MRI signal is represented in voxel data.\nThe <code>part-&lt;label&gt;</code> entity is associated with the DICOM Tag\n<code>0008, 9208</code>.\nAllowed label values for this entity are <code>phase</code>, <code>mag</code>, <code>real</code> and <code>imag</code>,\nwhich are typically used in <code>part-mag</code>/<code>part-phase</code> or\n<code>part-real</code>/<code>part-imag</code> pairs of files.</p>\n<p>Phase images MAY be in radians or in arbitrary units.\nThe sidecar JSON file MUST include the <code>\"Units\"</code> of the <code>phase</code> image.\nThe possible options are <code>\"rad\"</code> or <code>\"arbitrary\"</code>.</p>\n<p>When there is only a magnitude image of a given type, the <code>part</code> entity MAY be\nomitted.</p>", "type": "string", "format": "label", "enum": ["mag", "phase", "real", "imag"], "required": "optional"}, "chunk": {"name": "chunk", "display_name": "Chunk", "description": "<p>The <code>chunk-&lt;index&gt;</code> key/value pair is used to distinguish between images of\nthe same physical sample with different fields of view acquired in the same\nimaging experiment.\nThis entity applies to collections of 2D images, 3D volumes or 4D volume series\n(for example, diffusion weighted images), and may be used to indicate different\nanatomical structures or regions of the same structure.</p>", "type": "string", "format": "index", "required": "optional"}}, "value": "MP2RAGE", "display_name": "Magnetization Prepared Two Gradient Echoes", "description": "<p>The MP2RAGE method is a special protocol that collects several images at\ndifferent flip angles and inversion times to create a parametric T1map by\ncombining the magnitude and phase images\n(<a href=\"https://doi.org/10.1016/j.neuroimage.2009.10.002\">Marques et al. 2010</a>).</p>\n<br><code>mp2rage</code>"}, {"entities": {"subject": {"name": "sub", "display_name": "Subject", "description": "<p>A person or animal participating in the study.</p>", "type": "string", "format": "label", "required": "required"}, "session": {"name": "ses", "display_name": "Session", "description": "<p>A logical grouping of neuroimaging and behavioral data consistent across subjects.\nSession can (but doesn't have to) be synonymous to a visit in a longitudinal study.\nIn general, subjects will stay in the scanner during one session.\nHowever, for example, if a subject has to leave the scanner room and then\nbe re-positioned on the scanner bed, the set of MRI acquisitions will still\nbe considered as a session and match sessions acquired in other subjects.\nSimilarly, in situations where different data types are obtained over\nseveral visits (for example fMRI on one day followed by DWI the day after)\nthose can be grouped in one session.</p>\n<p>Defining multiple sessions is appropriate when several identical or similar\ndata acquisitions are planned and performed on all -or most- subjects,\noften in the case of some intervention between sessions\n(for example, training).</p>", "type": "string", "format": "label", "required": "optional"}, "task": {"name": "task", "display_name": "Task", "description": "<p>A set of structured activities performed by the participant.\nTasks are usually accompanied by stimuli and responses, and can greatly vary in complexity.</p>\n<p>In the context of brain scanning, a task is always tied to one data acquisition.\nTherefore, even if during one acquisition the subject performed multiple conceptually different behaviors\n(with different sets of instructions) they will be considered one (combined) task.</p>\n<p>While tasks may be repeated across multiple acquisitions,\na given task may have different sets of stimuli (for example, randomized order) and participant responses\nacross subjects, sessions, and runs.</p>\n<p>The <code>task-&lt;label&gt;</code> MUST be consistent across subjects and sessions.</p>\n<p>Files with the <code>task-&lt;label&gt;</code> entity SHOULD have an associated\n<a href=\"SPEC_ROOT/modality-specific-files/task-events.md#task-events\">events file</a>,\nas well as certain metadata fields in the associated JSON file.</p>\n<p>For the purpose of this specification we consider the so-called \"resting state\" a task,\nalthough events files are not expected for resting state data.\nAdditionally, a common convention in the specification is to include the word \"rest\" in\nthe <code>task</code> label for resting state files (for example, <code>task-rest</code>).</p>", "type": "string", "format": "label", "required": "optional"}, "acquisition": {"name": "acq", "display_name": "Acquisition", "description": "<p>The <code>acq-&lt;label&gt;</code> entity corresponds to a custom label the user MAY use to distinguish\na different set of parameters used for acquiring the same modality.</p>\n<p>For example, this should be used when a study includes two T1w images -\none full brain low resolution and one restricted field of view but high resolution.\nIn such case two files could have the following names:\n<code>sub-01_acq-highres_T1w.nii.gz</code> and <code>sub-01_acq-lowres_T1w.nii.gz</code>;\nhowever, the user is free to choose any other label than <code>highres</code> and <code>lowres</code> as long\nas they are consistent across subjects and sessions.</p>\n<p>In case different sequences are used to record the same modality\n(for example, <code>RARE</code> and <code>FLASH</code> for T1w)\nthis field can also be used to make that distinction.\nThe level of detail at which the distinction is made\n(for example, just between <code>RARE</code> and <code>FLASH</code>, or between <code>RARE</code>, <code>FLASH</code>, and <code>FLASHsubsampled</code>)\nremains at the discretion of the researcher.</p>", "type": "string", "format": "label", "required": "optional"}, "ceagent": {"name": "ce", "display_name": "Contrast Enhancing Agent", "description": "<p>The <code>ce-&lt;label&gt;</code> entity can be used to distinguish sequences using different contrast enhanced images.\nThe label is the name of the contrast agent.</p>\n<p>This entity represents the <code>\"ContrastBolusIngredient\"</code> metadata field.\nTherefore, if the <code>ce-&lt;label&gt;</code> entity is present in a filename,\n<code>\"ContrastBolusIngredient\"</code> MAY also be added in the JSON file, with the same label.</p>", "type": "string", "format": "label", "required": "optional"}, "reconstruction": {"name": "rec", "display_name": "Reconstruction", "description": "<p>The <code>rec-&lt;label&gt;</code> entity can be used to distinguish different reconstruction algorithms\n(for example, <code>MoCo</code> for the ones using motion correction).</p>", "type": "string", "format": "label", "required": "optional"}, "run": {"name": "run", "display_name": "Run", "description": "<p>The <code>run-&lt;index&gt;</code> entity is used to distinguish separate data acquisitions with the same acquisition parameters\nand (other) entities.</p>\n<p>If several data acquisitions (for example, MRI scans or EEG recordings)\nwith the same acquisition parameters are acquired in the same session,\nthey MUST be indexed with the <a href=\"SPEC_ROOT/appendices/entities.md#run\"><code>run-&lt;index&gt;</code></a> entity:\n<code>_run-1</code>, <code>_run-2</code>, <code>_run-3</code>, and so on\n(only nonnegative integers are allowed as run indices).</p>\n<p>If different entities apply,\nsuch as a different session indicated by [<code>ses-&lt;label&gt;</code>][SPEC_ROOT/appendices/entities.md#ses),\nor different acquisition parameters indicated by\n<a href=\"SPEC_ROOT/appendices/entities.md#acq\"><code>acq-&lt;label&gt;</code></a>,\nthen <code>run</code> is not needed to distinguish the scans and MAY be omitted.</p>", "type": "string", "format": "index", "required": "optional"}, "echo": {"name": "echo", "display_name": "Echo", "description": "<p>If files belonging to an entity-linked file collection are acquired at different\necho times, the <code>echo-&lt;index&gt;</code> entity MUST be used to distinguish individual files.</p>\n<p>This entity represents the <code>\"EchoTime\"</code> metadata field.\nTherefore, if the <code>echo-&lt;index&gt;</code> entity is present in a filename,\n<code>\"EchoTime\"</code> MUST be defined in the associated metadata.\nPlease note that the <code>&lt;index&gt;</code> denotes the number/index (in the form of a nonnegative integer),\nnot the <code>\"EchoTime\"</code> value of the separate JSON file.</p>", "type": "string", "format": "index", "required": "optional"}, "flip": {"name": "flip", "display_name": "Flip Angle", "description": "<p>If files belonging to an entity-linked file collection are acquired at different\nflip angles, the <code>_flip-&lt;index&gt;</code> entity pair MUST be used to distinguish\nindividual files.</p>\n<p>This entity represents the <code>\"FlipAngle\"</code> metadata field.\nTherefore, if the <code>flip-&lt;index&gt;</code> entity is present in a filename,\n<code>\"FlipAngle\"</code> MUST be defined in the associated metadata.\nPlease note that the <code>&lt;index&gt;</code> denotes the number/index (in the form of a nonnegative integer),\nnot the <code>\"FlipAngle\"</code> value of the separate JSON file.</p>", "type": "string", "format": "index", "required": "required"}, "mtransfer": {"name": "mt", "display_name": "Magnetization Transfer", "description": "<p>If files belonging to an entity-linked file collection are acquired at different\nmagnetization transfer (MT) states, the <code>_mt-&lt;label&gt;</code> entity MUST be used to\ndistinguish individual files.</p>\n<p>This entity represents the <code>\"MTState\"</code> metadata field.\nTherefore, if the <code>mt-&lt;label&gt;</code> entity is present in a filename,\n<code>\"MTState\"</code> MUST be defined in the associated metadata.\nAllowed label values for this entity are <code>on</code> and <code>off</code>,\nfor images acquired in presence and absence of an MT pulse, respectively.</p>", "type": "string", "format": "label", "enum": ["on", "off"], "required": "required"}, "part": {"name": "part", "display_name": "Part", "description": "<p>This entity is used to indicate which component of the complex\nrepresentation of the MRI signal is represented in voxel data.\nThe <code>part-&lt;label&gt;</code> entity is associated with the DICOM Tag\n<code>0008, 9208</code>.\nAllowed label values for this entity are <code>phase</code>, <code>mag</code>, <code>real</code> and <code>imag</code>,\nwhich are typically used in <code>part-mag</code>/<code>part-phase</code> or\n<code>part-real</code>/<code>part-imag</code> pairs of files.</p>\n<p>Phase images MAY be in radians or in arbitrary units.\nThe sidecar JSON file MUST include the <code>\"Units\"</code> of the <code>phase</code> image.\nThe possible options are <code>\"rad\"</code> or <code>\"arbitrary\"</code>.</p>\n<p>When there is only a magnitude image of a given type, the <code>part</code> entity MAY be\nomitted.</p>", "type": "string", "format": "label", "enum": ["mag", "phase", "real", "imag"], "required": "optional"}, "chunk": {"name": "chunk", "display_name": "Chunk", "description": "<p>The <code>chunk-&lt;index&gt;</code> key/value pair is used to distinguish between images of\nthe same physical sample with different fields of view acquired in the same\nimaging experiment.\nThis entity applies to collections of 2D images, 3D volumes or 4D volume series\n(for example, diffusion weighted images), and may be used to indicate different\nanatomical structures or regions of the same structure.</p>", "type": "string", "format": "index", "required": "optional"}}, "value": "MPM", "display_name": "Multi-parametric Mapping", "description": "<p>The MPM approaches (a.k.a hMRI) involves the acquisition of highly-similar\nanatomical images that differ in terms of application of a magnetization\ntransfer RF pulse (MTon or MToff), flip angle and (optionally) echo time and\nmagnitue/phase parts\n(<a href=\"https://doi.org/10.3389/fnins.2013.00095\">Weiskopf et al. 2013</a>).\nSee <a href=\"https://owncloud.gwdg.de/index.php/s/iv2TOQwGy4FGDDZ\">here</a> for\nsuggested MPM acquisition protocols.</p>\n<br><code>vfamt</code>"}, {"entities": {"subject": {"name": "sub", "display_name": "Subject", "description": "<p>A person or animal participating in the study.</p>", "type": "string", "format": "label", "required": "required"}, "session": {"name": "ses", "display_name": "Session", "description": "<p>A logical grouping of neuroimaging and behavioral data consistent across subjects.\nSession can (but doesn't have to) be synonymous to a visit in a longitudinal study.\nIn general, subjects will stay in the scanner during one session.\nHowever, for example, if a subject has to leave the scanner room and then\nbe re-positioned on the scanner bed, the set of MRI acquisitions will still\nbe considered as a session and match sessions acquired in other subjects.\nSimilarly, in situations where different data types are obtained over\nseveral visits (for example fMRI on one day followed by DWI the day after)\nthose can be grouped in one session.</p>\n<p>Defining multiple sessions is appropriate when several identical or similar\ndata acquisitions are planned and performed on all -or most- subjects,\noften in the case of some intervention between sessions\n(for example, training).</p>", "type": "string", "format": "label", "required": "optional"}, "task": {"name": "task", "display_name": "Task", "description": "<p>A set of structured activities performed by the participant.\nTasks are usually accompanied by stimuli and responses, and can greatly vary in complexity.</p>\n<p>In the context of brain scanning, a task is always tied to one data acquisition.\nTherefore, even if during one acquisition the subject performed multiple conceptually different behaviors\n(with different sets of instructions) they will be considered one (combined) task.</p>\n<p>While tasks may be repeated across multiple acquisitions,\na given task may have different sets of stimuli (for example, randomized order) and participant responses\nacross subjects, sessions, and runs.</p>\n<p>The <code>task-&lt;label&gt;</code> MUST be consistent across subjects and sessions.</p>\n<p>Files with the <code>task-&lt;label&gt;</code> entity SHOULD have an associated\n<a href=\"SPEC_ROOT/modality-specific-files/task-events.md#task-events\">events file</a>,\nas well as certain metadata fields in the associated JSON file.</p>\n<p>For the purpose of this specification we consider the so-called \"resting state\" a task,\nalthough events files are not expected for resting state data.\nAdditionally, a common convention in the specification is to include the word \"rest\" in\nthe <code>task</code> label for resting state files (for example, <code>task-rest</code>).</p>", "type": "string", "format": "label", "required": "optional"}, "acquisition": {"name": "acq", "display_name": "Acquisition", "description": "<p>The <code>acq-&lt;label&gt;</code> entity corresponds to a custom label the user MAY use to distinguish\na different set of parameters used for acquiring the same modality.</p>\n<p>For example, this should be used when a study includes two T1w images -\none full brain low resolution and one restricted field of view but high resolution.\nIn such case two files could have the following names:\n<code>sub-01_acq-highres_T1w.nii.gz</code> and <code>sub-01_acq-lowres_T1w.nii.gz</code>;\nhowever, the user is free to choose any other label than <code>highres</code> and <code>lowres</code> as long\nas they are consistent across subjects and sessions.</p>\n<p>In case different sequences are used to record the same modality\n(for example, <code>RARE</code> and <code>FLASH</code> for T1w)\nthis field can also be used to make that distinction.\nThe level of detail at which the distinction is made\n(for example, just between <code>RARE</code> and <code>FLASH</code>, or between <code>RARE</code>, <code>FLASH</code>, and <code>FLASHsubsampled</code>)\nremains at the discretion of the researcher.</p>", "type": "string", "format": "label", "required": "optional"}, "ceagent": {"name": "ce", "display_name": "Contrast Enhancing Agent", "description": "<p>The <code>ce-&lt;label&gt;</code> entity can be used to distinguish sequences using different contrast enhanced images.\nThe label is the name of the contrast agent.</p>\n<p>This entity represents the <code>\"ContrastBolusIngredient\"</code> metadata field.\nTherefore, if the <code>ce-&lt;label&gt;</code> entity is present in a filename,\n<code>\"ContrastBolusIngredient\"</code> MAY also be added in the JSON file, with the same label.</p>", "type": "string", "format": "label", "required": "optional"}, "reconstruction": {"name": "rec", "display_name": "Reconstruction", "description": "<p>The <code>rec-&lt;label&gt;</code> entity can be used to distinguish different reconstruction algorithms\n(for example, <code>MoCo</code> for the ones using motion correction).</p>", "type": "string", "format": "label", "required": "optional"}, "run": {"name": "run", "display_name": "Run", "description": "<p>The <code>run-&lt;index&gt;</code> entity is used to distinguish separate data acquisitions with the same acquisition parameters\nand (other) entities.</p>\n<p>If several data acquisitions (for example, MRI scans or EEG recordings)\nwith the same acquisition parameters are acquired in the same session,\nthey MUST be indexed with the <a href=\"SPEC_ROOT/appendices/entities.md#run\"><code>run-&lt;index&gt;</code></a> entity:\n<code>_run-1</code>, <code>_run-2</code>, <code>_run-3</code>, and so on\n(only nonnegative integers are allowed as run indices).</p>\n<p>If different entities apply,\nsuch as a different session indicated by [<code>ses-&lt;label&gt;</code>][SPEC_ROOT/appendices/entities.md#ses),\nor different acquisition parameters indicated by\n<a href=\"SPEC_ROOT/appendices/entities.md#acq\"><code>acq-&lt;label&gt;</code></a>,\nthen <code>run</code> is not needed to distinguish the scans and MAY be omitted.</p>", "type": "string", "format": "index", "required": "optional"}, "echo": {"name": "echo", "display_name": "Echo", "description": "<p>If files belonging to an entity-linked file collection are acquired at different\necho times, the <code>echo-&lt;index&gt;</code> entity MUST be used to distinguish individual files.</p>\n<p>This entity represents the <code>\"EchoTime\"</code> metadata field.\nTherefore, if the <code>echo-&lt;index&gt;</code> entity is present in a filename,\n<code>\"EchoTime\"</code> MUST be defined in the associated metadata.\nPlease note that the <code>&lt;index&gt;</code> denotes the number/index (in the form of a nonnegative integer),\nnot the <code>\"EchoTime\"</code> value of the separate JSON file.</p>", "type": "string", "format": "index", "required": "optional"}, "flip": {"name": "flip", "display_name": "Flip Angle", "description": "<p>If files belonging to an entity-linked file collection are acquired at different\nflip angles, the <code>_flip-&lt;index&gt;</code> entity pair MUST be used to distinguish\nindividual files.</p>\n<p>This entity represents the <code>\"FlipAngle\"</code> metadata field.\nTherefore, if the <code>flip-&lt;index&gt;</code> entity is present in a filename,\n<code>\"FlipAngle\"</code> MUST be defined in the associated metadata.\nPlease note that the <code>&lt;index&gt;</code> denotes the number/index (in the form of a nonnegative integer),\nnot the <code>\"FlipAngle\"</code> value of the separate JSON file.</p>", "type": "string", "format": "index", "required": "required"}, "mtransfer": {"name": "mt", "display_name": "Magnetization Transfer", "description": "<p>If files belonging to an entity-linked file collection are acquired at different\nmagnetization transfer (MT) states, the <code>_mt-&lt;label&gt;</code> entity MUST be used to\ndistinguish individual files.</p>\n<p>This entity represents the <code>\"MTState\"</code> metadata field.\nTherefore, if the <code>mt-&lt;label&gt;</code> entity is present in a filename,\n<code>\"MTState\"</code> MUST be defined in the associated metadata.\nAllowed label values for this entity are <code>on</code> and <code>off</code>,\nfor images acquired in presence and absence of an MT pulse, respectively.</p>", "type": "string", "format": "label", "enum": ["on", "off"], "required": "required"}, "part": {"name": "part", "display_name": "Part", "description": "<p>This entity is used to indicate which component of the complex\nrepresentation of the MRI signal is represented in voxel data.\nThe <code>part-&lt;label&gt;</code> entity is associated with the DICOM Tag\n<code>0008, 9208</code>.\nAllowed label values for this entity are <code>phase</code>, <code>mag</code>, <code>real</code> and <code>imag</code>,\nwhich are typically used in <code>part-mag</code>/<code>part-phase</code> or\n<code>part-real</code>/<code>part-imag</code> pairs of files.</p>\n<p>Phase images MAY be in radians or in arbitrary units.\nThe sidecar JSON file MUST include the <code>\"Units\"</code> of the <code>phase</code> image.\nThe possible options are <code>\"rad\"</code> or <code>\"arbitrary\"</code>.</p>\n<p>When there is only a magnitude image of a given type, the <code>part</code> entity MAY be\nomitted.</p>", "type": "string", "format": "label", "enum": ["mag", "phase", "real", "imag"], "required": "optional"}, "chunk": {"name": "chunk", "display_name": "Chunk", "description": "<p>The <code>chunk-&lt;index&gt;</code> key/value pair is used to distinguish between images of\nthe same physical sample with different fields of view acquired in the same\nimaging experiment.\nThis entity applies to collections of 2D images, 3D volumes or 4D volume series\n(for example, diffusion weighted images), and may be used to indicate different\nanatomical structures or regions of the same structure.</p>", "type": "string", "format": "index", "required": "optional"}}, "value": "MTS", "display_name": "Magnetization transfer saturation", "description": "<p>This method is to calculate a semi-quantitative magnetization transfer\nsaturation index map.\nThe MTS method involves three sets of anatomical images that differ in terms\nof application of a magnetization transfer RF pulse (MTon or MToff) and flip\nangle (<a href=\"https://doi.org/10.1002/mrm.21732\">Helms et al. 2008</a>).</p>\n<br><code>vfamt</code>"}, {"entities": {"subject": {"name": "sub", "display_name": "Subject", "description": "<p>A person or animal participating in the study.</p>", "type": "string", "format": "label", "required": "required"}, "session": {"name": "ses", "display_name": "Session", "description": "<p>A logical grouping of neuroimaging and behavioral data consistent across subjects.\nSession can (but doesn't have to) be synonymous to a visit in a longitudinal study.\nIn general, subjects will stay in the scanner during one session.\nHowever, for example, if a subject has to leave the scanner room and then\nbe re-positioned on the scanner bed, the set of MRI acquisitions will still\nbe considered as a session and match sessions acquired in other subjects.\nSimilarly, in situations where different data types are obtained over\nseveral visits (for example fMRI on one day followed by DWI the day after)\nthose can be grouped in one session.</p>\n<p>Defining multiple sessions is appropriate when several identical or similar\ndata acquisitions are planned and performed on all -or most- subjects,\noften in the case of some intervention between sessions\n(for example, training).</p>", "type": "string", "format": "label", "required": "optional"}, "task": {"name": "task", "display_name": "Task", "description": "<p>A set of structured activities performed by the participant.\nTasks are usually accompanied by stimuli and responses, and can greatly vary in complexity.</p>\n<p>In the context of brain scanning, a task is always tied to one data acquisition.\nTherefore, even if during one acquisition the subject performed multiple conceptually different behaviors\n(with different sets of instructions) they will be considered one (combined) task.</p>\n<p>While tasks may be repeated across multiple acquisitions,\na given task may have different sets of stimuli (for example, randomized order) and participant responses\nacross subjects, sessions, and runs.</p>\n<p>The <code>task-&lt;label&gt;</code> MUST be consistent across subjects and sessions.</p>\n<p>Files with the <code>task-&lt;label&gt;</code> entity SHOULD have an associated\n<a href=\"SPEC_ROOT/modality-specific-files/task-events.md#task-events\">events file</a>,\nas well as certain metadata fields in the associated JSON file.</p>\n<p>For the purpose of this specification we consider the so-called \"resting state\" a task,\nalthough events files are not expected for resting state data.\nAdditionally, a common convention in the specification is to include the word \"rest\" in\nthe <code>task</code> label for resting state files (for example, <code>task-rest</code>).</p>", "type": "string", "format": "label", "required": "optional"}, "acquisition": {"name": "acq", "display_name": "Acquisition", "description": "<p>The <code>acq-&lt;label&gt;</code> entity corresponds to a custom label the user MAY use to distinguish\na different set of parameters used for acquiring the same modality.</p>\n<p>For example, this should be used when a study includes two T1w images -\none full brain low resolution and one restricted field of view but high resolution.\nIn such case two files could have the following names:\n<code>sub-01_acq-highres_T1w.nii.gz</code> and <code>sub-01_acq-lowres_T1w.nii.gz</code>;\nhowever, the user is free to choose any other label than <code>highres</code> and <code>lowres</code> as long\nas they are consistent across subjects and sessions.</p>\n<p>In case different sequences are used to record the same modality\n(for example, <code>RARE</code> and <code>FLASH</code> for T1w)\nthis field can also be used to make that distinction.\nThe level of detail at which the distinction is made\n(for example, just between <code>RARE</code> and <code>FLASH</code>, or between <code>RARE</code>, <code>FLASH</code>, and <code>FLASHsubsampled</code>)\nremains at the discretion of the researcher.</p>", "type": "string", "format": "label", "required": "optional"}, "ceagent": {"name": "ce", "display_name": "Contrast Enhancing Agent", "description": "<p>The <code>ce-&lt;label&gt;</code> entity can be used to distinguish sequences using different contrast enhanced images.\nThe label is the name of the contrast agent.</p>\n<p>This entity represents the <code>\"ContrastBolusIngredient\"</code> metadata field.\nTherefore, if the <code>ce-&lt;label&gt;</code> entity is present in a filename,\n<code>\"ContrastBolusIngredient\"</code> MAY also be added in the JSON file, with the same label.</p>", "type": "string", "format": "label", "required": "optional"}, "reconstruction": {"name": "rec", "display_name": "Reconstruction", "description": "<p>The <code>rec-&lt;label&gt;</code> entity can be used to distinguish different reconstruction algorithms\n(for example, <code>MoCo</code> for the ones using motion correction).</p>", "type": "string", "format": "label", "required": "optional"}, "run": {"name": "run", "display_name": "Run", "description": "<p>The <code>run-&lt;index&gt;</code> entity is used to distinguish separate data acquisitions with the same acquisition parameters\nand (other) entities.</p>\n<p>If several data acquisitions (for example, MRI scans or EEG recordings)\nwith the same acquisition parameters are acquired in the same session,\nthey MUST be indexed with the <a href=\"SPEC_ROOT/appendices/entities.md#run\"><code>run-&lt;index&gt;</code></a> entity:\n<code>_run-1</code>, <code>_run-2</code>, <code>_run-3</code>, and so on\n(only nonnegative integers are allowed as run indices).</p>\n<p>If different entities apply,\nsuch as a different session indicated by [<code>ses-&lt;label&gt;</code>][SPEC_ROOT/appendices/entities.md#ses),\nor different acquisition parameters indicated by\n<a href=\"SPEC_ROOT/appendices/entities.md#acq\"><code>acq-&lt;label&gt;</code></a>,\nthen <code>run</code> is not needed to distinguish the scans and MAY be omitted.</p>", "type": "string", "format": "index", "required": "optional"}, "mtransfer": {"name": "mt", "display_name": "Magnetization Transfer", "description": "<p>If files belonging to an entity-linked file collection are acquired at different\nmagnetization transfer (MT) states, the <code>_mt-&lt;label&gt;</code> entity MUST be used to\ndistinguish individual files.</p>\n<p>This entity represents the <code>\"MTState\"</code> metadata field.\nTherefore, if the <code>mt-&lt;label&gt;</code> entity is present in a filename,\n<code>\"MTState\"</code> MUST be defined in the associated metadata.\nAllowed label values for this entity are <code>on</code> and <code>off</code>,\nfor images acquired in presence and absence of an MT pulse, respectively.</p>", "type": "string", "format": "label", "enum": ["on", "off"], "required": "required"}, "part": {"name": "part", "display_name": "Part", "description": "<p>This entity is used to indicate which component of the complex\nrepresentation of the MRI signal is represented in voxel data.\nThe <code>part-&lt;label&gt;</code> entity is associated with the DICOM Tag\n<code>0008, 9208</code>.\nAllowed label values for this entity are <code>phase</code>, <code>mag</code>, <code>real</code> and <code>imag</code>,\nwhich are typically used in <code>part-mag</code>/<code>part-phase</code> or\n<code>part-real</code>/<code>part-imag</code> pairs of files.</p>\n<p>Phase images MAY be in radians or in arbitrary units.\nThe sidecar JSON file MUST include the <code>\"Units\"</code> of the <code>phase</code> image.\nThe possible options are <code>\"rad\"</code> or <code>\"arbitrary\"</code>.</p>\n<p>When there is only a magnitude image of a given type, the <code>part</code> entity MAY be\nomitted.</p>", "type": "string", "format": "label", "enum": ["mag", "phase", "real", "imag"], "required": "optional"}, "chunk": {"name": "chunk", "display_name": "Chunk", "description": "<p>The <code>chunk-&lt;index&gt;</code> key/value pair is used to distinguish between images of\nthe same physical sample with different fields of view acquired in the same\nimaging experiment.\nThis entity applies to collections of 2D images, 3D volumes or 4D volume series\n(for example, diffusion weighted images), and may be used to indicate different\nanatomical structures or regions of the same structure.</p>", "type": "string", "format": "index", "required": "optional"}}, "value": "MTR", "display_name": "Magnetization Transfer Ratio", "description": "<p>This method is to calculate a semi-quantitative magnetization transfer ratio\nmap.</p>\n<br><code>mtr</code>"}, {"entities": {"session": {"name": "ses", "display_name": "Session", "description": "<p>A logical grouping of neuroimaging and behavioral data consistent across subjects.\nSession can (but doesn't have to) be synonymous to a visit in a longitudinal study.\nIn general, subjects will stay in the scanner during one session.\nHowever, for example, if a subject has to leave the scanner room and then\nbe re-positioned on the scanner bed, the set of MRI acquisitions will still\nbe considered as a session and match sessions acquired in other subjects.\nSimilarly, in situations where different data types are obtained over\nseveral visits (for example fMRI on one day followed by DWI the day after)\nthose can be grouped in one session.</p>\n<p>Defining multiple sessions is appropriate when several identical or similar\ndata acquisitions are planned and performed on all -or most- subjects,\noften in the case of some intervention between sessions\n(for example, training).</p>", "type": "string", "format": "label", "required": "optional"}, "acquisition": {"name": "acq", "display_name": "Acquisition", "description": "<p>The <code>acq-&lt;label&gt;</code> entity corresponds to a custom label the user MAY use to distinguish\na different set of parameters used for acquiring the same modality.</p>\n<p>For example, this should be used when a study includes two T1w images -\none full brain low resolution and one restricted field of view but high resolution.\nIn such case two files could have the following names:\n<code>sub-01_acq-highres_T1w.nii.gz</code> and <code>sub-01_acq-lowres_T1w.nii.gz</code>;\nhowever, the user is free to choose any other label than <code>highres</code> and <code>lowres</code> as long\nas they are consistent across subjects and sessions.</p>\n<p>In case different sequences are used to record the same modality\n(for example, <code>RARE</code> and <code>FLASH</code> for T1w)\nthis field can also be used to make that distinction.\nThe level of detail at which the distinction is made\n(for example, just between <code>RARE</code> and <code>FLASH</code>, or between <code>RARE</code>, <code>FLASH</code>, and <code>FLASHsubsampled</code>)\nremains at the discretion of the researcher.</p>", "type": "string", "format": "label", "required": "optional"}}, "value": "scout", "display_name": "Scout localizer", "description": "ReproIn specific entity label for easily labeling a session. Using heudiconv, labeling this sequence session only is sufficent. You do not need to put <code>ses</code> on every sequence name! See <a href=https://github.com/nipy/heudiconv/blob/master/heudiconv/heuristics/reproin.py#L629>source reference</a>\n<br><code>scout</code>", "unit": "arbitrary"}], "dwi": [{"entities": {"subject": {"name": "sub", "display_name": "Subject", "description": "<p>A person or animal participating in the study.</p>", "type": "string", "format": "label", "required": "required"}, "session": {"name": "ses", "display_name": "Session", "description": "<p>A logical grouping of neuroimaging and behavioral data consistent across subjects.\nSession can (but doesn't have to) be synonymous to a visit in a longitudinal study.\nIn general, subjects will stay in the scanner during one session.\nHowever, for example, if a subject has to leave the scanner room and then\nbe re-positioned on the scanner bed, the set of MRI acquisitions will still\nbe considered as a session and match sessions acquired in other subjects.\nSimilarly, in situations where different data types are obtained over\nseveral visits (for example fMRI on one day followed by DWI the day after)\nthose can be grouped in one session.</p>\n<p>Defining multiple sessions is appropriate when several identical or similar\ndata acquisitions are planned and performed on all -or most- subjects,\noften in the case of some intervention between sessions\n(for example, training).</p>", "type": "string", "format": "label", "required": "optional"}, "acquisition": {"name": "acq", "display_name": "Acquisition", "description": "<p>The <code>acq-&lt;label&gt;</code> entity corresponds to a custom label the user MAY use to distinguish\na different set of parameters used for acquiring the same modality.</p>\n<p>For example, this should be used when a study includes two T1w images -\none full brain low resolution and one restricted field of view but high resolution.\nIn such case two files could have the following names:\n<code>sub-01_acq-highres_T1w.nii.gz</code> and <code>sub-01_acq-lowres_T1w.nii.gz</code>;\nhowever, the user is free to choose any other label than <code>highres</code> and <code>lowres</code> as long\nas they are consistent across subjects and sessions.</p>\n<p>In case different sequences are used to record the same modality\n(for example, <code>RARE</code> and <code>FLASH</code> for T1w)\nthis field can also be used to make that distinction.\nThe level of detail at which the distinction is made\n(for example, just between <code>RARE</code> and <code>FLASH</code>, or between <code>RARE</code>, <code>FLASH</code>, and <code>FLASHsubsampled</code>)\nremains at the discretion of the researcher.</p>", "type": "string", "format": "label", "required": "optional"}, "reconstruction": {"name": "rec", "display_name": "Reconstruction", "description": "<p>The <code>rec-&lt;label&gt;</code> entity can be used to distinguish different reconstruction algorithms\n(for example, <code>MoCo</code> for the ones using motion correction).</p>", "type": "string", "format": "label", "required": "optional"}, "direction": {"name": "dir", "display_name": "Phase-Encoding Direction", "description": "<p>The <code>dir-&lt;label&gt;</code> entity can be set to an arbitrary alphanumeric label\n(for example, <code>dir-LR</code> or <code>dir-AP</code>)\nto distinguish different phase-encoding directions.</p>\n<p>This entity represents the <code>\"PhaseEncodingDirection\"</code> metadata field.\nTherefore, if the <code>dir-&lt;label&gt;</code> entity is present in a filename,\n<code>\"PhaseEncodingDirection\"</code> MUST be defined in the associated metadata.\nPlease note that the <code>&lt;label&gt;</code> does not need to match the actual value of the field.</p>", "type": "string", "format": "label", "required": "optional"}, "run": {"name": "run", "display_name": "Run", "description": "<p>The <code>run-&lt;index&gt;</code> entity is used to distinguish separate data acquisitions with the same acquisition parameters\nand (other) entities.</p>\n<p>If several data acquisitions (for example, MRI scans or EEG recordings)\nwith the same acquisition parameters are acquired in the same session,\nthey MUST be indexed with the <a href=\"SPEC_ROOT/appendices/entities.md#run\"><code>run-&lt;index&gt;</code></a> entity:\n<code>_run-1</code>, <code>_run-2</code>, <code>_run-3</code>, and so on\n(only nonnegative integers are allowed as run indices).</p>\n<p>If different entities apply,\nsuch as a different session indicated by [<code>ses-&lt;label&gt;</code>][SPEC_ROOT/appendices/entities.md#ses),\nor different acquisition parameters indicated by\n<a href=\"SPEC_ROOT/appendices/entities.md#acq\"><code>acq-&lt;label&gt;</code></a>,\nthen <code>run</code> is not needed to distinguish the scans and MAY be omitted.</p>", "type": "string", "format": "index", "required": "optional"}, "part": {"name": "part", "display_name": "Part", "description": "<p>This entity is used to indicate which component of the complex\nrepresentation of the MRI signal is represented in voxel data.\nThe <code>part-&lt;label&gt;</code> entity is associated with the DICOM Tag\n<code>0008, 9208</code>.\nAllowed label values for this entity are <code>phase</code>, <code>mag</code>, <code>real</code> and <code>imag</code>,\nwhich are typically used in <code>part-mag</code>/<code>part-phase</code> or\n<code>part-real</code>/<code>part-imag</code> pairs of files.</p>\n<p>Phase images MAY be in radians or in arbitrary units.\nThe sidecar JSON file MUST include the <code>\"Units\"</code> of the <code>phase</code> image.\nThe possible options are <code>\"rad\"</code> or <code>\"arbitrary\"</code>.</p>\n<p>When there is only a magnitude image of a given type, the <code>part</code> entity MAY be\nomitted.</p>", "type": "string", "format": "label", "enum": ["mag", "phase", "real", "imag"], "required": "optional"}, "chunk": {"name": "chunk", "display_name": "Chunk", "description": "<p>The <code>chunk-&lt;index&gt;</code> key/value pair is used to distinguish between images of\nthe same physical sample with different fields of view acquired in the same\nimaging experiment.\nThis entity applies to collections of 2D images, 3D volumes or 4D volume series\n(for example, diffusion weighted images), and may be used to indicate different\nanatomical structures or regions of the same structure.</p>", "type": "string", "format": "index", "required": "optional"}}, "value": "dwi", "display_name": "Diffusion-weighted image", "description": "<p>Diffusion-weighted imaging contrast (specialized T2 weighting).</p>\n<br><code>dwi</code>"}, {"entities": {"subject": {"name": "sub", "display_name": "Subject", "description": "<p>A person or animal participating in the study.</p>", "type": "string", "format": "label", "required": "required"}, "session": {"name": "ses", "display_name": "Session", "description": "<p>A logical grouping of neuroimaging and behavioral data consistent across subjects.\nSession can (but doesn't have to) be synonymous to a visit in a longitudinal study.\nIn general, subjects will stay in the scanner during one session.\nHowever, for example, if a subject has to leave the scanner room and then\nbe re-positioned on the scanner bed, the set of MRI acquisitions will still\nbe considered as a session and match sessions acquired in other subjects.\nSimilarly, in situations where different data types are obtained over\nseveral visits (for example fMRI on one day followed by DWI the day after)\nthose can be grouped in one session.</p>\n<p>Defining multiple sessions is appropriate when several identical or similar\ndata acquisitions are planned and performed on all -or most- subjects,\noften in the case of some intervention between sessions\n(for example, training).</p>", "type": "string", "format": "label", "required": "optional"}, "acquisition": {"name": "acq", "display_name": "Acquisition", "description": "<p>The <code>acq-&lt;label&gt;</code> entity corresponds to a custom label the user MAY use to distinguish\na different set of parameters used for acquiring the same modality.</p>\n<p>For example, this should be used when a study includes two T1w images -\none full brain low resolution and one restricted field of view but high resolution.\nIn such case two files could have the following names:\n<code>sub-01_acq-highres_T1w.nii.gz</code> and <code>sub-01_acq-lowres_T1w.nii.gz</code>;\nhowever, the user is free to choose any other label than <code>highres</code> and <code>lowres</code> as long\nas they are consistent across subjects and sessions.</p>\n<p>In case different sequences are used to record the same modality\n(for example, <code>RARE</code> and <code>FLASH</code> for T1w)\nthis field can also be used to make that distinction.\nThe level of detail at which the distinction is made\n(for example, just between <code>RARE</code> and <code>FLASH</code>, or between <code>RARE</code>, <code>FLASH</code>, and <code>FLASHsubsampled</code>)\nremains at the discretion of the researcher.</p>", "type": "string", "format": "label", "required": "optional"}, "reconstruction": {"name": "rec", "display_name": "Reconstruction", "description": "<p>The <code>rec-&lt;label&gt;</code> entity can be used to distinguish different reconstruction algorithms\n(for example, <code>MoCo</code> for the ones using motion correction).</p>", "type": "string", "format": "label", "required": "optional"}, "direction": {"name": "dir", "display_name": "Phase-Encoding Direction", "description": "<p>The <code>dir-&lt;label&gt;</code> entity can be set to an arbitrary alphanumeric label\n(for example, <code>dir-LR</code> or <code>dir-AP</code>)\nto distinguish different phase-encoding directions.</p>\n<p>This entity represents the <code>\"PhaseEncodingDirection\"</code> metadata field.\nTherefore, if the <code>dir-&lt;label&gt;</code> entity is present in a filename,\n<code>\"PhaseEncodingDirection\"</code> MUST be defined in the associated metadata.\nPlease note that the <code>&lt;label&gt;</code> does not need to match the actual value of the field.</p>", "type": "string", "format": "label", "required": "optional"}, "run": {"name": "run", "display_name": "Run", "description": "<p>The <code>run-&lt;index&gt;</code> entity is used to distinguish separate data acquisitions with the same acquisition parameters\nand (other) entities.</p>\n<p>If several data acquisitions (for example, MRI scans or EEG recordings)\nwith the same acquisition parameters are acquired in the same session,\nthey MUST be indexed with the <a href=\"SPEC_ROOT/appendices/entities.md#run\"><code>run-&lt;index&gt;</code></a> entity:\n<code>_run-1</code>, <code>_run-2</code>, <code>_run-3</code>, and so on\n(only nonnegative integers are allowed as run indices).</p>\n<p>If different entities apply,\nsuch as a different session indicated by [<code>ses-&lt;label&gt;</code>][SPEC_ROOT/appendices/entities.md#ses),\nor different acquisition parameters indicated by\n<a href=\"SPEC_ROOT/appendices/entities.md#acq\"><code>acq-&lt;label&gt;</code></a>,\nthen <code>run</code> is not needed to distinguish the scans and MAY be omitted.</p>", "type": "string", "format": "index", "required": "optional"}, "part": {"name": "part", "display_name": "Part", "description": "<p>This entity is used to indicate which component of the complex\nrepresentation of the MRI signal is represented in voxel data.\nThe <code>part-&lt;label&gt;</code> entity is associated with the DICOM Tag\n<code>0008, 9208</code>.\nAllowed label values for this entity are <code>phase</code>, <code>mag</code>, <code>real</code> and <code>imag</code>,\nwhich are typically used in <code>part-mag</code>/<code>part-phase</code> or\n<code>part-real</code>/<code>part-imag</code> pairs of files.</p>\n<p>Phase images MAY be in radians or in arbitrary units.\nThe sidecar JSON file MUST include the <code>\"Units\"</code> of the <code>phase</code> image.\nThe possible options are <code>\"rad\"</code> or <code>\"arbitrary\"</code>.</p>\n<p>When there is only a magnitude image of a given type, the <code>part</code> entity MAY be\nomitted.</p>", "type": "string", "format": "label", "enum": ["mag", "phase", "real", "imag"], "required": "optional"}, "chunk": {"name": "chunk", "display_name": "Chunk", "description": "<p>The <code>chunk-&lt;index&gt;</code> key/value pair is used to distinguish between images of\nthe same physical sample with different fields of view acquired in the same\nimaging experiment.\nThis entity applies to collections of 2D images, 3D volumes or 4D volume series\n(for example, diffusion weighted images), and may be used to indicate different\nanatomical structures or regions of the same structure.</p>", "type": "string", "format": "index", "required": "optional"}}, "value": "sbref", "display_name": "Single-band reference image", "description": "<p>Single-band reference for one or more multi-band <code>dwi</code> images.</p>\n<br><code>sbref</code>"}, {"entities": {"subject": {"name": "sub", "display_name": "Subject", "description": "<p>A person or animal participating in the study.</p>", "type": "string", "format": "label", "required": "required"}, "session": {"name": "ses", "display_name": "Session", "description": "<p>A logical grouping of neuroimaging and behavioral data consistent across subjects.\nSession can (but doesn't have to) be synonymous to a visit in a longitudinal study.\nIn general, subjects will stay in the scanner during one session.\nHowever, for example, if a subject has to leave the scanner room and then\nbe re-positioned on the scanner bed, the set of MRI acquisitions will still\nbe considered as a session and match sessions acquired in other subjects.\nSimilarly, in situations where different data types are obtained over\nseveral visits (for example fMRI on one day followed by DWI the day after)\nthose can be grouped in one session.</p>\n<p>Defining multiple sessions is appropriate when several identical or similar\ndata acquisitions are planned and performed on all -or most- subjects,\noften in the case of some intervention between sessions\n(for example, training).</p>", "type": "string", "format": "label", "required": "optional"}, "acquisition": {"name": "acq", "display_name": "Acquisition", "description": "<p>The <code>acq-&lt;label&gt;</code> entity corresponds to a custom label the user MAY use to distinguish\na different set of parameters used for acquiring the same modality.</p>\n<p>For example, this should be used when a study includes two T1w images -\none full brain low resolution and one restricted field of view but high resolution.\nIn such case two files could have the following names:\n<code>sub-01_acq-highres_T1w.nii.gz</code> and <code>sub-01_acq-lowres_T1w.nii.gz</code>;\nhowever, the user is free to choose any other label than <code>highres</code> and <code>lowres</code> as long\nas they are consistent across subjects and sessions.</p>\n<p>In case different sequences are used to record the same modality\n(for example, <code>RARE</code> and <code>FLASH</code> for T1w)\nthis field can also be used to make that distinction.\nThe level of detail at which the distinction is made\n(for example, just between <code>RARE</code> and <code>FLASH</code>, or between <code>RARE</code>, <code>FLASH</code>, and <code>FLASHsubsampled</code>)\nremains at the discretion of the researcher.</p>", "type": "string", "format": "label", "required": "optional"}, "reconstruction": {"name": "rec", "display_name": "Reconstruction", "description": "<p>The <code>rec-&lt;label&gt;</code> entity can be used to distinguish different reconstruction algorithms\n(for example, <code>MoCo</code> for the ones using motion correction).</p>", "type": "string", "format": "label", "required": "optional"}, "direction": {"name": "dir", "display_name": "Phase-Encoding Direction", "description": "<p>The <code>dir-&lt;label&gt;</code> entity can be set to an arbitrary alphanumeric label\n(for example, <code>dir-LR</code> or <code>dir-AP</code>)\nto distinguish different phase-encoding directions.</p>\n<p>This entity represents the <code>\"PhaseEncodingDirection\"</code> metadata field.\nTherefore, if the <code>dir-&lt;label&gt;</code> entity is present in a filename,\n<code>\"PhaseEncodingDirection\"</code> MUST be defined in the associated metadata.\nPlease note that the <code>&lt;label&gt;</code> does not need to match the actual value of the field.</p>", "type": "string", "format": "label", "required": "optional"}, "run": {"name": "run", "display_name": "Run", "description": "<p>The <code>run-&lt;index&gt;</code> entity is used to distinguish separate data acquisitions with the same acquisition parameters\nand (other) entities.</p>\n<p>If several data acquisitions (for example, MRI scans or EEG recordings)\nwith the same acquisition parameters are acquired in the same session,\nthey MUST be indexed with the <a href=\"SPEC_ROOT/appendices/entities.md#run\"><code>run-&lt;index&gt;</code></a> entity:\n<code>_run-1</code>, <code>_run-2</code>, <code>_run-3</code>, and so on\n(only nonnegative integers are allowed as run indices).</p>\n<p>If different entities apply,\nsuch as a different session indicated by [<code>ses-&lt;label&gt;</code>][SPEC_ROOT/appendices/entities.md#ses),\nor different acquisition parameters indicated by\n<a href=\"SPEC_ROOT/appendices/entities.md#acq\"><code>acq-&lt;label&gt;</code></a>,\nthen <code>run</code> is not needed to distinguish the scans and MAY be omitted.</p>", "type": "string", "format": "index", "required": "optional"}, "chunk": {"name": "chunk", "display_name": "Chunk", "description": "<p>The <code>chunk-&lt;index&gt;</code> key/value pair is used to distinguish between images of\nthe same physical sample with different fields of view acquired in the same\nimaging experiment.\nThis entity applies to collections of 2D images, 3D volumes or 4D volume series\n(for example, diffusion weighted images), and may be used to indicate different\nanatomical structures or regions of the same structure.</p>", "type": "string", "format": "index", "required": "optional"}}, "value": "ADC", "display_name": "Apparent diffusion coefficient (ADC)", "description": "<p>Apparent diffusion coefficient (ADC) map</p>\n<br><code>isotropic</code>"}, {"entities": {"subject": {"name": "sub", "display_name": "Subject", "description": "<p>A person or animal participating in the study.</p>", "type": "string", "format": "label", "required": "required"}, "session": {"name": "ses", "display_name": "Session", "description": "<p>A logical grouping of neuroimaging and behavioral data consistent across subjects.\nSession can (but doesn't have to) be synonymous to a visit in a longitudinal study.\nIn general, subjects will stay in the scanner during one session.\nHowever, for example, if a subject has to leave the scanner room and then\nbe re-positioned on the scanner bed, the set of MRI acquisitions will still\nbe considered as a session and match sessions acquired in other subjects.\nSimilarly, in situations where different data types are obtained over\nseveral visits (for example fMRI on one day followed by DWI the day after)\nthose can be grouped in one session.</p>\n<p>Defining multiple sessions is appropriate when several identical or similar\ndata acquisitions are planned and performed on all -or most- subjects,\noften in the case of some intervention between sessions\n(for example, training).</p>", "type": "string", "format": "label", "required": "optional"}, "acquisition": {"name": "acq", "display_name": "Acquisition", "description": "<p>The <code>acq-&lt;label&gt;</code> entity corresponds to a custom label the user MAY use to distinguish\na different set of parameters used for acquiring the same modality.</p>\n<p>For example, this should be used when a study includes two T1w images -\none full brain low resolution and one restricted field of view but high resolution.\nIn such case two files could have the following names:\n<code>sub-01_acq-highres_T1w.nii.gz</code> and <code>sub-01_acq-lowres_T1w.nii.gz</code>;\nhowever, the user is free to choose any other label than <code>highres</code> and <code>lowres</code> as long\nas they are consistent across subjects and sessions.</p>\n<p>In case different sequences are used to record the same modality\n(for example, <code>RARE</code> and <code>FLASH</code> for T1w)\nthis field can also be used to make that distinction.\nThe level of detail at which the distinction is made\n(for example, just between <code>RARE</code> and <code>FLASH</code>, or between <code>RARE</code>, <code>FLASH</code>, and <code>FLASHsubsampled</code>)\nremains at the discretion of the researcher.</p>", "type": "string", "format": "label", "required": "optional"}, "reconstruction": {"name": "rec", "display_name": "Reconstruction", "description": "<p>The <code>rec-&lt;label&gt;</code> entity can be used to distinguish different reconstruction algorithms\n(for example, <code>MoCo</code> for the ones using motion correction).</p>", "type": "string", "format": "label", "required": "optional"}, "direction": {"name": "dir", "display_name": "Phase-Encoding Direction", "description": "<p>The <code>dir-&lt;label&gt;</code> entity can be set to an arbitrary alphanumeric label\n(for example, <code>dir-LR</code> or <code>dir-AP</code>)\nto distinguish different phase-encoding directions.</p>\n<p>This entity represents the <code>\"PhaseEncodingDirection\"</code> metadata field.\nTherefore, if the <code>dir-&lt;label&gt;</code> entity is present in a filename,\n<code>\"PhaseEncodingDirection\"</code> MUST be defined in the associated metadata.\nPlease note that the <code>&lt;label&gt;</code> does not need to match the actual value of the field.</p>", "type": "string", "format": "label", "required": "optional"}, "run": {"name": "run", "display_name": "Run", "description": "<p>The <code>run-&lt;index&gt;</code> entity is used to distinguish separate data acquisitions with the same acquisition parameters\nand (other) entities.</p>\n<p>If several data acquisitions (for example, MRI scans or EEG recordings)\nwith the same acquisition parameters are acquired in the same session,\nthey MUST be indexed with the <a href=\"SPEC_ROOT/appendices/entities.md#run\"><code>run-&lt;index&gt;</code></a> entity:\n<code>_run-1</code>, <code>_run-2</code>, <code>_run-3</code>, and so on\n(only nonnegative integers are allowed as run indices).</p>\n<p>If different entities apply,\nsuch as a different session indicated by [<code>ses-&lt;label&gt;</code>][SPEC_ROOT/appendices/entities.md#ses),\nor different acquisition parameters indicated by\n<a href=\"SPEC_ROOT/appendices/entities.md#acq\"><code>acq-&lt;label&gt;</code></a>,\nthen <code>run</code> is not needed to distinguish the scans and MAY be omitted.</p>", "type": "string", "format": "index", "required": "optional"}, "chunk": {"name": "chunk", "display_name": "Chunk", "description": "<p>The <code>chunk-&lt;index&gt;</code> key/value pair is used to distinguish between images of\nthe same physical sample with different fields of view acquired in the same\nimaging experiment.\nThis entity applies to collections of 2D images, 3D volumes or 4D volume series\n(for example, diffusion weighted images), and may be used to indicate different\nanatomical structures or regions of the same structure.</p>", "type": "string", "format": "index", "required": "optional"}}, "value": "TRACE", "display_name": "Trace diffusion weighted image", "description": "<p>Diffusion images proportional to the trace of the diffusion tensor</p>\n<br><code>isotropic</code>"}], "fmap": [{"entities": {"subject": {"name": "sub", "display_name": "Subject", "description": "<p>A person or animal participating in the study.</p>", "type": "string", "format": "label", "required": "required"}, "session": {"name": "ses", "display_name": "Session", "description": "<p>A logical grouping of neuroimaging and behavioral data consistent across subjects.\nSession can (but doesn't have to) be synonymous to a visit in a longitudinal study.\nIn general, subjects will stay in the scanner during one session.\nHowever, for example, if a subject has to leave the scanner room and then\nbe re-positioned on the scanner bed, the set of MRI acquisitions will still\nbe considered as a session and match sessions acquired in other subjects.\nSimilarly, in situations where different data types are obtained over\nseveral visits (for example fMRI on one day followed by DWI the day after)\nthose can be grouped in one session.</p>\n<p>Defining multiple sessions is appropriate when several identical or similar\ndata acquisitions are planned and performed on all -or most- subjects,\noften in the case of some intervention between sessions\n(for example, training).</p>", "type": "string", "format": "label", "required": "optional"}, "acquisition": {"name": "acq", "display_name": "Acquisition", "description": "<p>The <code>acq-&lt;label&gt;</code> entity corresponds to a custom label the user MAY use to distinguish\na different set of parameters used for acquiring the same modality.</p>\n<p>For example, this should be used when a study includes two T1w images -\none full brain low resolution and one restricted field of view but high resolution.\nIn such case two files could have the following names:\n<code>sub-01_acq-highres_T1w.nii.gz</code> and <code>sub-01_acq-lowres_T1w.nii.gz</code>;\nhowever, the user is free to choose any other label than <code>highres</code> and <code>lowres</code> as long\nas they are consistent across subjects and sessions.</p>\n<p>In case different sequences are used to record the same modality\n(for example, <code>RARE</code> and <code>FLASH</code> for T1w)\nthis field can also be used to make that distinction.\nThe level of detail at which the distinction is made\n(for example, just between <code>RARE</code> and <code>FLASH</code>, or between <code>RARE</code>, <code>FLASH</code>, and <code>FLASHsubsampled</code>)\nremains at the discretion of the researcher.</p>", "type": "string", "format": "label", "required": "optional"}, "run": {"name": "run", "display_name": "Run", "description": "<p>The <code>run-&lt;index&gt;</code> entity is used to distinguish separate data acquisitions with the same acquisition parameters\nand (other) entities.</p>\n<p>If several data acquisitions (for example, MRI scans or EEG recordings)\nwith the same acquisition parameters are acquired in the same session,\nthey MUST be indexed with the <a href=\"SPEC_ROOT/appendices/entities.md#run\"><code>run-&lt;index&gt;</code></a> entity:\n<code>_run-1</code>, <code>_run-2</code>, <code>_run-3</code>, and so on\n(only nonnegative integers are allowed as run indices).</p>\n<p>If different entities apply,\nsuch as a different session indicated by [<code>ses-&lt;label&gt;</code>][SPEC_ROOT/appendices/entities.md#ses),\nor different acquisition parameters indicated by\n<a href=\"SPEC_ROOT/appendices/entities.md#acq\"><code>acq-&lt;label&gt;</code></a>,\nthen <code>run</code> is not needed to distinguish the scans and MAY be omitted.</p>", "type": "string", "format": "index", "required": "optional"}, "chunk": {"name": "chunk", "display_name": "Chunk", "description": "<p>The <code>chunk-&lt;index&gt;</code> key/value pair is used to distinguish between images of\nthe same physical sample with different fields of view acquired in the same\nimaging experiment.\nThis entity applies to collections of 2D images, 3D volumes or 4D volume series\n(for example, diffusion weighted images), and may be used to indicate different\nanatomical structures or regions of the same structure.</p>", "type": "string", "format": "index", "required": "optional"}}, "value": "phasediff", "display_name": "Phase-difference", "description": "<p>Some scanners subtract the <code>phase1</code> from the <code>phase2</code> map and generate a\nunique <code>phasediff</code> file.\nFor instance, this is a common output for the built-in fieldmap sequence of\nSiemens scanners.</p>\n<br><code>fieldmaps</code>"}, {"entities": {"subject": {"name": "sub", "display_name": "Subject", "description": "<p>A person or animal participating in the study.</p>", "type": "string", "format": "label", "required": "required"}, "session": {"name": "ses", "display_name": "Session", "description": "<p>A logical grouping of neuroimaging and behavioral data consistent across subjects.\nSession can (but doesn't have to) be synonymous to a visit in a longitudinal study.\nIn general, subjects will stay in the scanner during one session.\nHowever, for example, if a subject has to leave the scanner room and then\nbe re-positioned on the scanner bed, the set of MRI acquisitions will still\nbe considered as a session and match sessions acquired in other subjects.\nSimilarly, in situations where different data types are obtained over\nseveral visits (for example fMRI on one day followed by DWI the day after)\nthose can be grouped in one session.</p>\n<p>Defining multiple sessions is appropriate when several identical or similar\ndata acquisitions are planned and performed on all -or most- subjects,\noften in the case of some intervention between sessions\n(for example, training).</p>", "type": "string", "format": "label", "required": "optional"}, "acquisition": {"name": "acq", "display_name": "Acquisition", "description": "<p>The <code>acq-&lt;label&gt;</code> entity corresponds to a custom label the user MAY use to distinguish\na different set of parameters used for acquiring the same modality.</p>\n<p>For example, this should be used when a study includes two T1w images -\none full brain low resolution and one restricted field of view but high resolution.\nIn such case two files could have the following names:\n<code>sub-01_acq-highres_T1w.nii.gz</code> and <code>sub-01_acq-lowres_T1w.nii.gz</code>;\nhowever, the user is free to choose any other label than <code>highres</code> and <code>lowres</code> as long\nas they are consistent across subjects and sessions.</p>\n<p>In case different sequences are used to record the same modality\n(for example, <code>RARE</code> and <code>FLASH</code> for T1w)\nthis field can also be used to make that distinction.\nThe level of detail at which the distinction is made\n(for example, just between <code>RARE</code> and <code>FLASH</code>, or between <code>RARE</code>, <code>FLASH</code>, and <code>FLASHsubsampled</code>)\nremains at the discretion of the researcher.</p>", "type": "string", "format": "label", "required": "optional"}, "run": {"name": "run", "display_name": "Run", "description": "<p>The <code>run-&lt;index&gt;</code> entity is used to distinguish separate data acquisitions with the same acquisition parameters\nand (other) entities.</p>\n<p>If several data acquisitions (for example, MRI scans or EEG recordings)\nwith the same acquisition parameters are acquired in the same session,\nthey MUST be indexed with the <a href=\"SPEC_ROOT/appendices/entities.md#run\"><code>run-&lt;index&gt;</code></a> entity:\n<code>_run-1</code>, <code>_run-2</code>, <code>_run-3</code>, and so on\n(only nonnegative integers are allowed as run indices).</p>\n<p>If different entities apply,\nsuch as a different session indicated by [<code>ses-&lt;label&gt;</code>][SPEC_ROOT/appendices/entities.md#ses),\nor different acquisition parameters indicated by\n<a href=\"SPEC_ROOT/appendices/entities.md#acq\"><code>acq-&lt;label&gt;</code></a>,\nthen <code>run</code> is not needed to distinguish the scans and MAY be omitted.</p>", "type": "string", "format": "index", "required": "optional"}, "chunk": {"name": "chunk", "display_name": "Chunk", "description": "<p>The <code>chunk-&lt;index&gt;</code> key/value pair is used to distinguish between images of\nthe same physical sample with different fields of view acquired in the same\nimaging experiment.\nThis entity applies to collections of 2D images, 3D volumes or 4D volume series\n(for example, diffusion weighted images), and may be used to indicate different\nanatomical structures or regions of the same structure.</p>", "type": "string", "format": "index", "required": "optional"}}, "value": "phase1", "display_name": "Phase", "description": "<p>Phase map generated by GRE or similar schemes, associated with the first\necho in the sequence.</p>\n<br><code>fieldmaps</code>"}, {"entities": {"subject": {"name": "sub", "display_name": "Subject", "description": "<p>A person or animal participating in the study.</p>", "type": "string", "format": "label", "required": "required"}, "session": {"name": "ses", "display_name": "Session", "description": "<p>A logical grouping of neuroimaging and behavioral data consistent across subjects.\nSession can (but doesn't have to) be synonymous to a visit in a longitudinal study.\nIn general, subjects will stay in the scanner during one session.\nHowever, for example, if a subject has to leave the scanner room and then\nbe re-positioned on the scanner bed, the set of MRI acquisitions will still\nbe considered as a session and match sessions acquired in other subjects.\nSimilarly, in situations where different data types are obtained over\nseveral visits (for example fMRI on one day followed by DWI the day after)\nthose can be grouped in one session.</p>\n<p>Defining multiple sessions is appropriate when several identical or similar\ndata acquisitions are planned and performed on all -or most- subjects,\noften in the case of some intervention between sessions\n(for example, training).</p>", "type": "string", "format": "label", "required": "optional"}, "acquisition": {"name": "acq", "display_name": "Acquisition", "description": "<p>The <code>acq-&lt;label&gt;</code> entity corresponds to a custom label the user MAY use to distinguish\na different set of parameters used for acquiring the same modality.</p>\n<p>For example, this should be used when a study includes two T1w images -\none full brain low resolution and one restricted field of view but high resolution.\nIn such case two files could have the following names:\n<code>sub-01_acq-highres_T1w.nii.gz</code> and <code>sub-01_acq-lowres_T1w.nii.gz</code>;\nhowever, the user is free to choose any other label than <code>highres</code> and <code>lowres</code> as long\nas they are consistent across subjects and sessions.</p>\n<p>In case different sequences are used to record the same modality\n(for example, <code>RARE</code> and <code>FLASH</code> for T1w)\nthis field can also be used to make that distinction.\nThe level of detail at which the distinction is made\n(for example, just between <code>RARE</code> and <code>FLASH</code>, or between <code>RARE</code>, <code>FLASH</code>, and <code>FLASHsubsampled</code>)\nremains at the discretion of the researcher.</p>", "type": "string", "format": "label", "required": "optional"}, "run": {"name": "run", "display_name": "Run", "description": "<p>The <code>run-&lt;index&gt;</code> entity is used to distinguish separate data acquisitions with the same acquisition parameters\nand (other) entities.</p>\n<p>If several data acquisitions (for example, MRI scans or EEG recordings)\nwith the same acquisition parameters are acquired in the same session,\nthey MUST be indexed with the <a href=\"SPEC_ROOT/appendices/entities.md#run\"><code>run-&lt;index&gt;</code></a> entity:\n<code>_run-1</code>, <code>_run-2</code>, <code>_run-3</code>, and so on\n(only nonnegative integers are allowed as run indices).</p>\n<p>If different entities apply,\nsuch as a different session indicated by [<code>ses-&lt;label&gt;</code>][SPEC_ROOT/appendices/entities.md#ses),\nor different acquisition parameters indicated by\n<a href=\"SPEC_ROOT/appendices/entities.md#acq\"><code>acq-&lt;label&gt;</code></a>,\nthen <code>run</code> is not needed to distinguish the scans and MAY be omitted.</p>", "type": "string", "format": "index", "required": "optional"}, "chunk": {"name": "chunk", "display_name": "Chunk", "description": "<p>The <code>chunk-&lt;index&gt;</code> key/value pair is used to distinguish between images of\nthe same physical sample with different fields of view acquired in the same\nimaging experiment.\nThis entity applies to collections of 2D images, 3D volumes or 4D volume series\n(for example, diffusion weighted images), and may be used to indicate different\nanatomical structures or regions of the same structure.</p>", "type": "string", "format": "index", "required": "optional"}}, "value": "phase2", "display_name": "Phase", "description": "<p>Phase map generated by GRE or similar schemes, associated with the second\necho in the sequence.</p>\n<br><code>fieldmaps</code>"}, {"entities": {"subject": {"name": "sub", "display_name": "Subject", "description": "<p>A person or animal participating in the study.</p>", "type": "string", "format": "label", "required": "required"}, "session": {"name": "ses", "display_name": "Session", "description": "<p>A logical grouping of neuroimaging and behavioral data consistent across subjects.\nSession can (but doesn't have to) be synonymous to a visit in a longitudinal study.\nIn general, subjects will stay in the scanner during one session.\nHowever, for example, if a subject has to leave the scanner room and then\nbe re-positioned on the scanner bed, the set of MRI acquisitions will still\nbe considered as a session and match sessions acquired in other subjects.\nSimilarly, in situations where different data types are obtained over\nseveral visits (for example fMRI on one day followed by DWI the day after)\nthose can be grouped in one session.</p>\n<p>Defining multiple sessions is appropriate when several identical or similar\ndata acquisitions are planned and performed on all -or most- subjects,\noften in the case of some intervention between sessions\n(for example, training).</p>", "type": "string", "format": "label", "required": "optional"}, "acquisition": {"name": "acq", "display_name": "Acquisition", "description": "<p>The <code>acq-&lt;label&gt;</code> entity corresponds to a custom label the user MAY use to distinguish\na different set of parameters used for acquiring the same modality.</p>\n<p>For example, this should be used when a study includes two T1w images -\none full brain low resolution and one restricted field of view but high resolution.\nIn such case two files could have the following names:\n<code>sub-01_acq-highres_T1w.nii.gz</code> and <code>sub-01_acq-lowres_T1w.nii.gz</code>;\nhowever, the user is free to choose any other label than <code>highres</code> and <code>lowres</code> as long\nas they are consistent across subjects and sessions.</p>\n<p>In case different sequences are used to record the same modality\n(for example, <code>RARE</code> and <code>FLASH</code> for T1w)\nthis field can also be used to make that distinction.\nThe level of detail at which the distinction is made\n(for example, just between <code>RARE</code> and <code>FLASH</code>, or between <code>RARE</code>, <code>FLASH</code>, and <code>FLASHsubsampled</code>)\nremains at the discretion of the researcher.</p>", "type": "string", "format": "label", "required": "optional"}, "run": {"name": "run", "display_name": "Run", "description": "<p>The <code>run-&lt;index&gt;</code> entity is used to distinguish separate data acquisitions with the same acquisition parameters\nand (other) entities.</p>\n<p>If several data acquisitions (for example, MRI scans or EEG recordings)\nwith the same acquisition parameters are acquired in the same session,\nthey MUST be indexed with the <a href=\"SPEC_ROOT/appendices/entities.md#run\"><code>run-&lt;index&gt;</code></a> entity:\n<code>_run-1</code>, <code>_run-2</code>, <code>_run-3</code>, and so on\n(only nonnegative integers are allowed as run indices).</p>\n<p>If different entities apply,\nsuch as a different session indicated by [<code>ses-&lt;label&gt;</code>][SPEC_ROOT/appendices/entities.md#ses),\nor different acquisition parameters indicated by\n<a href=\"SPEC_ROOT/appendices/entities.md#acq\"><code>acq-&lt;label&gt;</code></a>,\nthen <code>run</code> is not needed to distinguish the scans and MAY be omitted.</p>", "type": "string", "format": "index", "required": "optional"}, "chunk": {"name": "chunk", "display_name": "Chunk", "description": "<p>The <code>chunk-&lt;index&gt;</code> key/value pair is used to distinguish between images of\nthe same physical sample with different fields of view acquired in the same\nimaging experiment.\nThis entity applies to collections of 2D images, 3D volumes or 4D volume series\n(for example, diffusion weighted images), and may be used to indicate different\nanatomical structures or regions of the same structure.</p>", "type": "string", "format": "index", "required": "optional"}}, "value": "magnitude1", "display_name": "Magnitude", "description": "<p>Magnitude map generated by GRE or similar schemes, associated with the first\necho in the sequence.</p>\n<br><code>fieldmaps</code>"}, {"entities": {"subject": {"name": "sub", "display_name": "Subject", "description": "<p>A person or animal participating in the study.</p>", "type": "string", "format": "label", "required": "required"}, "session": {"name": "ses", "display_name": "Session", "description": "<p>A logical grouping of neuroimaging and behavioral data consistent across subjects.\nSession can (but doesn't have to) be synonymous to a visit in a longitudinal study.\nIn general, subjects will stay in the scanner during one session.\nHowever, for example, if a subject has to leave the scanner room and then\nbe re-positioned on the scanner bed, the set of MRI acquisitions will still\nbe considered as a session and match sessions acquired in other subjects.\nSimilarly, in situations where different data types are obtained over\nseveral visits (for example fMRI on one day followed by DWI the day after)\nthose can be grouped in one session.</p>\n<p>Defining multiple sessions is appropriate when several identical or similar\ndata acquisitions are planned and performed on all -or most- subjects,\noften in the case of some intervention between sessions\n(for example, training).</p>", "type": "string", "format": "label", "required": "optional"}, "acquisition": {"name": "acq", "display_name": "Acquisition", "description": "<p>The <code>acq-&lt;label&gt;</code> entity corresponds to a custom label the user MAY use to distinguish\na different set of parameters used for acquiring the same modality.</p>\n<p>For example, this should be used when a study includes two T1w images -\none full brain low resolution and one restricted field of view but high resolution.\nIn such case two files could have the following names:\n<code>sub-01_acq-highres_T1w.nii.gz</code> and <code>sub-01_acq-lowres_T1w.nii.gz</code>;\nhowever, the user is free to choose any other label than <code>highres</code> and <code>lowres</code> as long\nas they are consistent across subjects and sessions.</p>\n<p>In case different sequences are used to record the same modality\n(for example, <code>RARE</code> and <code>FLASH</code> for T1w)\nthis field can also be used to make that distinction.\nThe level of detail at which the distinction is made\n(for example, just between <code>RARE</code> and <code>FLASH</code>, or between <code>RARE</code>, <code>FLASH</code>, and <code>FLASHsubsampled</code>)\nremains at the discretion of the researcher.</p>", "type": "string", "format": "label", "required": "optional"}, "run": {"name": "run", "display_name": "Run", "description": "<p>The <code>run-&lt;index&gt;</code> entity is used to distinguish separate data acquisitions with the same acquisition parameters\nand (other) entities.</p>\n<p>If several data acquisitions (for example, MRI scans or EEG recordings)\nwith the same acquisition parameters are acquired in the same session,\nthey MUST be indexed with the <a href=\"SPEC_ROOT/appendices/entities.md#run\"><code>run-&lt;index&gt;</code></a> entity:\n<code>_run-1</code>, <code>_run-2</code>, <code>_run-3</code>, and so on\n(only nonnegative integers are allowed as run indices).</p>\n<p>If different entities apply,\nsuch as a different session indicated by [<code>ses-&lt;label&gt;</code>][SPEC_ROOT/appendices/entities.md#ses),\nor different acquisition parameters indicated by\n<a href=\"SPEC_ROOT/appendices/entities.md#acq\"><code>acq-&lt;label&gt;</code></a>,\nthen <code>run</code> is not needed to distinguish the scans and MAY be omitted.</p>", "type": "string", "format": "index", "required": "optional"}, "chunk": {"name": "chunk", "display_name": "Chunk", "description": "<p>The <code>chunk-&lt;index&gt;</code> key/value pair is used to distinguish between images of\nthe same physical sample with different fields of view acquired in the same\nimaging experiment.\nThis entity applies to collections of 2D images, 3D volumes or 4D volume series\n(for example, diffusion weighted images), and may be used to indicate different\nanatomical structures or regions of the same structure.</p>", "type": "string", "format": "index", "required": "optional"}}, "value": "magnitude2", "display_name": "Magnitude", "description": "<p>Magnitude map generated by GRE or similar schemes, associated with the second\necho in the sequence.</p>\n<br><code>fieldmaps</code>"}, {"entities": {"subject": {"name": "sub", "display_name": "Subject", "description": "<p>A person or animal participating in the study.</p>", "type": "string", "format": "label", "required": "required"}, "session": {"name": "ses", "display_name": "Session", "description": "<p>A logical grouping of neuroimaging and behavioral data consistent across subjects.\nSession can (but doesn't have to) be synonymous to a visit in a longitudinal study.\nIn general, subjects will stay in the scanner during one session.\nHowever, for example, if a subject has to leave the scanner room and then\nbe re-positioned on the scanner bed, the set of MRI acquisitions will still\nbe considered as a session and match sessions acquired in other subjects.\nSimilarly, in situations where different data types are obtained over\nseveral visits (for example fMRI on one day followed by DWI the day after)\nthose can be grouped in one session.</p>\n<p>Defining multiple sessions is appropriate when several identical or similar\ndata acquisitions are planned and performed on all -or most- subjects,\noften in the case of some intervention between sessions\n(for example, training).</p>", "type": "string", "format": "label", "required": "optional"}, "acquisition": {"name": "acq", "display_name": "Acquisition", "description": "<p>The <code>acq-&lt;label&gt;</code> entity corresponds to a custom label the user MAY use to distinguish\na different set of parameters used for acquiring the same modality.</p>\n<p>For example, this should be used when a study includes two T1w images -\none full brain low resolution and one restricted field of view but high resolution.\nIn such case two files could have the following names:\n<code>sub-01_acq-highres_T1w.nii.gz</code> and <code>sub-01_acq-lowres_T1w.nii.gz</code>;\nhowever, the user is free to choose any other label than <code>highres</code> and <code>lowres</code> as long\nas they are consistent across subjects and sessions.</p>\n<p>In case different sequences are used to record the same modality\n(for example, <code>RARE</code> and <code>FLASH</code> for T1w)\nthis field can also be used to make that distinction.\nThe level of detail at which the distinction is made\n(for example, just between <code>RARE</code> and <code>FLASH</code>, or between <code>RARE</code>, <code>FLASH</code>, and <code>FLASHsubsampled</code>)\nremains at the discretion of the researcher.</p>", "type": "string", "format": "label", "required": "optional"}, "run": {"name": "run", "display_name": "Run", "description": "<p>The <code>run-&lt;index&gt;</code> entity is used to distinguish separate data acquisitions with the same acquisition parameters\nand (other) entities.</p>\n<p>If several data acquisitions (for example, MRI scans or EEG recordings)\nwith the same acquisition parameters are acquired in the same session,\nthey MUST be indexed with the <a href=\"SPEC_ROOT/appendices/entities.md#run\"><code>run-&lt;index&gt;</code></a> entity:\n<code>_run-1</code>, <code>_run-2</code>, <code>_run-3</code>, and so on\n(only nonnegative integers are allowed as run indices).</p>\n<p>If different entities apply,\nsuch as a different session indicated by [<code>ses-&lt;label&gt;</code>][SPEC_ROOT/appendices/entities.md#ses),\nor different acquisition parameters indicated by\n<a href=\"SPEC_ROOT/appendices/entities.md#acq\"><code>acq-&lt;label&gt;</code></a>,\nthen <code>run</code> is not needed to distinguish the scans and MAY be omitted.</p>", "type": "string", "format": "index", "required": "optional"}, "chunk": {"name": "chunk", "display_name": "Chunk", "description": "<p>The <code>chunk-&lt;index&gt;</code> key/value pair is used to distinguish between images of\nthe same physical sample with different fields of view acquired in the same\nimaging experiment.\nThis entity applies to collections of 2D images, 3D volumes or 4D volume series\n(for example, diffusion weighted images), and may be used to indicate different\nanatomical structures or regions of the same structure.</p>", "type": "string", "format": "index", "required": "optional"}}, "value": "magnitude", "display_name": "Magnitude", "description": "<p>Field-mapping MR schemes such as gradient-recalled echo (GRE) generate a\nMagnitude image to be used for anatomical reference.\nRequires the existence of Phase, Phase-difference or Fieldmap maps.</p>\n<br><code>fieldmaps</code>"}, {"entities": {"subject": {"name": "sub", "display_name": "Subject", "description": "<p>A person or animal participating in the study.</p>", "type": "string", "format": "label", "required": "required"}, "session": {"name": "ses", "display_name": "Session", "description": "<p>A logical grouping of neuroimaging and behavioral data consistent across subjects.\nSession can (but doesn't have to) be synonymous to a visit in a longitudinal study.\nIn general, subjects will stay in the scanner during one session.\nHowever, for example, if a subject has to leave the scanner room and then\nbe re-positioned on the scanner bed, the set of MRI acquisitions will still\nbe considered as a session and match sessions acquired in other subjects.\nSimilarly, in situations where different data types are obtained over\nseveral visits (for example fMRI on one day followed by DWI the day after)\nthose can be grouped in one session.</p>\n<p>Defining multiple sessions is appropriate when several identical or similar\ndata acquisitions are planned and performed on all -or most- subjects,\noften in the case of some intervention between sessions\n(for example, training).</p>", "type": "string", "format": "label", "required": "optional"}, "acquisition": {"name": "acq", "display_name": "Acquisition", "description": "<p>The <code>acq-&lt;label&gt;</code> entity corresponds to a custom label the user MAY use to distinguish\na different set of parameters used for acquiring the same modality.</p>\n<p>For example, this should be used when a study includes two T1w images -\none full brain low resolution and one restricted field of view but high resolution.\nIn such case two files could have the following names:\n<code>sub-01_acq-highres_T1w.nii.gz</code> and <code>sub-01_acq-lowres_T1w.nii.gz</code>;\nhowever, the user is free to choose any other label than <code>highres</code> and <code>lowres</code> as long\nas they are consistent across subjects and sessions.</p>\n<p>In case different sequences are used to record the same modality\n(for example, <code>RARE</code> and <code>FLASH</code> for T1w)\nthis field can also be used to make that distinction.\nThe level of detail at which the distinction is made\n(for example, just between <code>RARE</code> and <code>FLASH</code>, or between <code>RARE</code>, <code>FLASH</code>, and <code>FLASHsubsampled</code>)\nremains at the discretion of the researcher.</p>", "type": "string", "format": "label", "required": "optional"}, "run": {"name": "run", "display_name": "Run", "description": "<p>The <code>run-&lt;index&gt;</code> entity is used to distinguish separate data acquisitions with the same acquisition parameters\nand (other) entities.</p>\n<p>If several data acquisitions (for example, MRI scans or EEG recordings)\nwith the same acquisition parameters are acquired in the same session,\nthey MUST be indexed with the <a href=\"SPEC_ROOT/appendices/entities.md#run\"><code>run-&lt;index&gt;</code></a> entity:\n<code>_run-1</code>, <code>_run-2</code>, <code>_run-3</code>, and so on\n(only nonnegative integers are allowed as run indices).</p>\n<p>If different entities apply,\nsuch as a different session indicated by [<code>ses-&lt;label&gt;</code>][SPEC_ROOT/appendices/entities.md#ses),\nor different acquisition parameters indicated by\n<a href=\"SPEC_ROOT/appendices/entities.md#acq\"><code>acq-&lt;label&gt;</code></a>,\nthen <code>run</code> is not needed to distinguish the scans and MAY be omitted.</p>", "type": "string", "format": "index", "required": "optional"}, "chunk": {"name": "chunk", "display_name": "Chunk", "description": "<p>The <code>chunk-&lt;index&gt;</code> key/value pair is used to distinguish between images of\nthe same physical sample with different fields of view acquired in the same\nimaging experiment.\nThis entity applies to collections of 2D images, 3D volumes or 4D volume series\n(for example, diffusion weighted images), and may be used to indicate different\nanatomical structures or regions of the same structure.</p>", "type": "string", "format": "index", "required": "optional"}}, "value": "fieldmap", "display_name": "Fieldmap", "description": "<p>Some MR schemes such as spiral-echo imaging (SEI) sequences are able to\ndirectly provide maps of the <em>B<sub>0</sub></em> field inhomogeneity.</p>\n<br><code>fieldmaps</code>"}, {"entities": {"subject": {"name": "sub", "display_name": "Subject", "description": "<p>A person or animal participating in the study.</p>", "type": "string", "format": "label", "required": "required"}, "session": {"name": "ses", "display_name": "Session", "description": "<p>A logical grouping of neuroimaging and behavioral data consistent across subjects.\nSession can (but doesn't have to) be synonymous to a visit in a longitudinal study.\nIn general, subjects will stay in the scanner during one session.\nHowever, for example, if a subject has to leave the scanner room and then\nbe re-positioned on the scanner bed, the set of MRI acquisitions will still\nbe considered as a session and match sessions acquired in other subjects.\nSimilarly, in situations where different data types are obtained over\nseveral visits (for example fMRI on one day followed by DWI the day after)\nthose can be grouped in one session.</p>\n<p>Defining multiple sessions is appropriate when several identical or similar\ndata acquisitions are planned and performed on all -or most- subjects,\noften in the case of some intervention between sessions\n(for example, training).</p>", "type": "string", "format": "label", "required": "optional"}, "acquisition": {"name": "acq", "display_name": "Acquisition", "description": "<p>The <code>acq-&lt;label&gt;</code> entity corresponds to a custom label the user MAY use to distinguish\na different set of parameters used for acquiring the same modality.</p>\n<p>For example, this should be used when a study includes two T1w images -\none full brain low resolution and one restricted field of view but high resolution.\nIn such case two files could have the following names:\n<code>sub-01_acq-highres_T1w.nii.gz</code> and <code>sub-01_acq-lowres_T1w.nii.gz</code>;\nhowever, the user is free to choose any other label than <code>highres</code> and <code>lowres</code> as long\nas they are consistent across subjects and sessions.</p>\n<p>In case different sequences are used to record the same modality\n(for example, <code>RARE</code> and <code>FLASH</code> for T1w)\nthis field can also be used to make that distinction.\nThe level of detail at which the distinction is made\n(for example, just between <code>RARE</code> and <code>FLASH</code>, or between <code>RARE</code>, <code>FLASH</code>, and <code>FLASHsubsampled</code>)\nremains at the discretion of the researcher.</p>", "type": "string", "format": "label", "required": "optional"}, "ceagent": {"name": "ce", "display_name": "Contrast Enhancing Agent", "description": "<p>The <code>ce-&lt;label&gt;</code> entity can be used to distinguish sequences using different contrast enhanced images.\nThe label is the name of the contrast agent.</p>\n<p>This entity represents the <code>\"ContrastBolusIngredient\"</code> metadata field.\nTherefore, if the <code>ce-&lt;label&gt;</code> entity is present in a filename,\n<code>\"ContrastBolusIngredient\"</code> MAY also be added in the JSON file, with the same label.</p>", "type": "string", "format": "label", "required": "optional"}, "direction": {"name": "dir", "display_name": "Phase-Encoding Direction", "description": "<p>The <code>dir-&lt;label&gt;</code> entity can be set to an arbitrary alphanumeric label\n(for example, <code>dir-LR</code> or <code>dir-AP</code>)\nto distinguish different phase-encoding directions.</p>\n<p>This entity represents the <code>\"PhaseEncodingDirection\"</code> metadata field.\nTherefore, if the <code>dir-&lt;label&gt;</code> entity is present in a filename,\n<code>\"PhaseEncodingDirection\"</code> MUST be defined in the associated metadata.\nPlease note that the <code>&lt;label&gt;</code> does not need to match the actual value of the field.</p>", "type": "string", "format": "label", "required": "required"}, "run": {"name": "run", "display_name": "Run", "description": "<p>The <code>run-&lt;index&gt;</code> entity is used to distinguish separate data acquisitions with the same acquisition parameters\nand (other) entities.</p>\n<p>If several data acquisitions (for example, MRI scans or EEG recordings)\nwith the same acquisition parameters are acquired in the same session,\nthey MUST be indexed with the <a href=\"SPEC_ROOT/appendices/entities.md#run\"><code>run-&lt;index&gt;</code></a> entity:\n<code>_run-1</code>, <code>_run-2</code>, <code>_run-3</code>, and so on\n(only nonnegative integers are allowed as run indices).</p>\n<p>If different entities apply,\nsuch as a different session indicated by [<code>ses-&lt;label&gt;</code>][SPEC_ROOT/appendices/entities.md#ses),\nor different acquisition parameters indicated by\n<a href=\"SPEC_ROOT/appendices/entities.md#acq\"><code>acq-&lt;label&gt;</code></a>,\nthen <code>run</code> is not needed to distinguish the scans and MAY be omitted.</p>", "type": "string", "format": "index", "required": "optional"}, "part": {"name": "part", "display_name": "Part", "description": "<p>This entity is used to indicate which component of the complex\nrepresentation of the MRI signal is represented in voxel data.\nThe <code>part-&lt;label&gt;</code> entity is associated with the DICOM Tag\n<code>0008, 9208</code>.\nAllowed label values for this entity are <code>phase</code>, <code>mag</code>, <code>real</code> and <code>imag</code>,\nwhich are typically used in <code>part-mag</code>/<code>part-phase</code> or\n<code>part-real</code>/<code>part-imag</code> pairs of files.</p>\n<p>Phase images MAY be in radians or in arbitrary units.\nThe sidecar JSON file MUST include the <code>\"Units\"</code> of the <code>phase</code> image.\nThe possible options are <code>\"rad\"</code> or <code>\"arbitrary\"</code>.</p>\n<p>When there is only a magnitude image of a given type, the <code>part</code> entity MAY be\nomitted.</p>", "type": "string", "format": "label", "enum": ["mag", "phase", "real", "imag"], "required": "optional"}, "chunk": {"name": "chunk", "display_name": "Chunk", "description": "<p>The <code>chunk-&lt;index&gt;</code> key/value pair is used to distinguish between images of\nthe same physical sample with different fields of view acquired in the same\nimaging experiment.\nThis entity applies to collections of 2D images, 3D volumes or 4D volume series\n(for example, diffusion weighted images), and may be used to indicate different\nanatomical structures or regions of the same structure.</p>", "type": "string", "format": "index", "required": "optional"}}, "value": "epi", "display_name": "EPI", "description": "<p>The phase-encoding polarity (PEpolar) technique combines two or more Spin Echo\nEPI scans with different phase encoding directions to estimate the underlying\ninhomogeneity/deformation map.</p>\n<br><code>pepolar</code>"}, {"entities": {"subject": {"name": "sub", "display_name": "Subject", "description": "<p>A person or animal participating in the study.</p>", "type": "string", "format": "label", "required": "required"}, "session": {"name": "ses", "display_name": "Session", "description": "<p>A logical grouping of neuroimaging and behavioral data consistent across subjects.\nSession can (but doesn't have to) be synonymous to a visit in a longitudinal study.\nIn general, subjects will stay in the scanner during one session.\nHowever, for example, if a subject has to leave the scanner room and then\nbe re-positioned on the scanner bed, the set of MRI acquisitions will still\nbe considered as a session and match sessions acquired in other subjects.\nSimilarly, in situations where different data types are obtained over\nseveral visits (for example fMRI on one day followed by DWI the day after)\nthose can be grouped in one session.</p>\n<p>Defining multiple sessions is appropriate when several identical or similar\ndata acquisitions are planned and performed on all -or most- subjects,\noften in the case of some intervention between sessions\n(for example, training).</p>", "type": "string", "format": "label", "required": "optional"}, "acquisition": {"name": "acq", "display_name": "Acquisition", "description": "<p>The <code>acq-&lt;label&gt;</code> entity corresponds to a custom label the user MAY use to distinguish\na different set of parameters used for acquiring the same modality.</p>\n<p>For example, this should be used when a study includes two T1w images -\none full brain low resolution and one restricted field of view but high resolution.\nIn such case two files could have the following names:\n<code>sub-01_acq-highres_T1w.nii.gz</code> and <code>sub-01_acq-lowres_T1w.nii.gz</code>;\nhowever, the user is free to choose any other label than <code>highres</code> and <code>lowres</code> as long\nas they are consistent across subjects and sessions.</p>\n<p>In case different sequences are used to record the same modality\n(for example, <code>RARE</code> and <code>FLASH</code> for T1w)\nthis field can also be used to make that distinction.\nThe level of detail at which the distinction is made\n(for example, just between <code>RARE</code> and <code>FLASH</code>, or between <code>RARE</code>, <code>FLASH</code>, and <code>FLASHsubsampled</code>)\nremains at the discretion of the researcher.</p>", "type": "string", "format": "label", "required": "optional"}, "ceagent": {"name": "ce", "display_name": "Contrast Enhancing Agent", "description": "<p>The <code>ce-&lt;label&gt;</code> entity can be used to distinguish sequences using different contrast enhanced images.\nThe label is the name of the contrast agent.</p>\n<p>This entity represents the <code>\"ContrastBolusIngredient\"</code> metadata field.\nTherefore, if the <code>ce-&lt;label&gt;</code> entity is present in a filename,\n<code>\"ContrastBolusIngredient\"</code> MAY also be added in the JSON file, with the same label.</p>", "type": "string", "format": "label", "required": "optional"}, "direction": {"name": "dir", "display_name": "Phase-Encoding Direction", "description": "<p>The <code>dir-&lt;label&gt;</code> entity can be set to an arbitrary alphanumeric label\n(for example, <code>dir-LR</code> or <code>dir-AP</code>)\nto distinguish different phase-encoding directions.</p>\n<p>This entity represents the <code>\"PhaseEncodingDirection\"</code> metadata field.\nTherefore, if the <code>dir-&lt;label&gt;</code> entity is present in a filename,\n<code>\"PhaseEncodingDirection\"</code> MUST be defined in the associated metadata.\nPlease note that the <code>&lt;label&gt;</code> does not need to match the actual value of the field.</p>", "type": "string", "format": "label", "required": "required"}, "run": {"name": "run", "display_name": "Run", "description": "<p>The <code>run-&lt;index&gt;</code> entity is used to distinguish separate data acquisitions with the same acquisition parameters\nand (other) entities.</p>\n<p>If several data acquisitions (for example, MRI scans or EEG recordings)\nwith the same acquisition parameters are acquired in the same session,\nthey MUST be indexed with the <a href=\"SPEC_ROOT/appendices/entities.md#run\"><code>run-&lt;index&gt;</code></a> entity:\n<code>_run-1</code>, <code>_run-2</code>, <code>_run-3</code>, and so on\n(only nonnegative integers are allowed as run indices).</p>\n<p>If different entities apply,\nsuch as a different session indicated by [<code>ses-&lt;label&gt;</code>][SPEC_ROOT/appendices/entities.md#ses),\nor different acquisition parameters indicated by\n<a href=\"SPEC_ROOT/appendices/entities.md#acq\"><code>acq-&lt;label&gt;</code></a>,\nthen <code>run</code> is not needed to distinguish the scans and MAY be omitted.</p>", "type": "string", "format": "index", "required": "optional"}, "part": {"name": "part", "display_name": "Part", "description": "<p>This entity is used to indicate which component of the complex\nrepresentation of the MRI signal is represented in voxel data.\nThe <code>part-&lt;label&gt;</code> entity is associated with the DICOM Tag\n<code>0008, 9208</code>.\nAllowed label values for this entity are <code>phase</code>, <code>mag</code>, <code>real</code> and <code>imag</code>,\nwhich are typically used in <code>part-mag</code>/<code>part-phase</code> or\n<code>part-real</code>/<code>part-imag</code> pairs of files.</p>\n<p>Phase images MAY be in radians or in arbitrary units.\nThe sidecar JSON file MUST include the <code>\"Units\"</code> of the <code>phase</code> image.\nThe possible options are <code>\"rad\"</code> or <code>\"arbitrary\"</code>.</p>\n<p>When there is only a magnitude image of a given type, the <code>part</code> entity MAY be\nomitted.</p>", "type": "string", "format": "label", "enum": ["mag", "phase", "real", "imag"], "required": "optional"}, "chunk": {"name": "chunk", "display_name": "Chunk", "description": "<p>The <code>chunk-&lt;index&gt;</code> key/value pair is used to distinguish between images of\nthe same physical sample with different fields of view acquired in the same\nimaging experiment.\nThis entity applies to collections of 2D images, 3D volumes or 4D volume series\n(for example, diffusion weighted images), and may be used to indicate different\nanatomical structures or regions of the same structure.</p>", "type": "string", "format": "index", "required": "optional"}}, "value": "m0scan", "display_name": "M0 image", "description": "<p>The M0 image is a calibration image, used to estimate the equilibrium\nmagnetization of blood.</p>\n<br><code>pepolar_m0scan</code>"}, {"entities": {"subject": {"name": "sub", "display_name": "Subject", "description": "<p>A person or animal participating in the study.</p>", "type": "string", "format": "label", "required": "required"}, "session": {"name": "ses", "display_name": "Session", "description": "<p>A logical grouping of neuroimaging and behavioral data consistent across subjects.\nSession can (but doesn't have to) be synonymous to a visit in a longitudinal study.\nIn general, subjects will stay in the scanner during one session.\nHowever, for example, if a subject has to leave the scanner room and then\nbe re-positioned on the scanner bed, the set of MRI acquisitions will still\nbe considered as a session and match sessions acquired in other subjects.\nSimilarly, in situations where different data types are obtained over\nseveral visits (for example fMRI on one day followed by DWI the day after)\nthose can be grouped in one session.</p>\n<p>Defining multiple sessions is appropriate when several identical or similar\ndata acquisitions are planned and performed on all -or most- subjects,\noften in the case of some intervention between sessions\n(for example, training).</p>", "type": "string", "format": "label", "required": "optional"}, "acquisition": {"name": "acq", "display_name": "Acquisition", "description": "<p>The <code>acq-&lt;label&gt;</code> entity corresponds to a custom label the user MAY use to distinguish\na different set of parameters used for acquiring the same modality.</p>\n<p>For example, this should be used when a study includes two T1w images -\none full brain low resolution and one restricted field of view but high resolution.\nIn such case two files could have the following names:\n<code>sub-01_acq-highres_T1w.nii.gz</code> and <code>sub-01_acq-lowres_T1w.nii.gz</code>;\nhowever, the user is free to choose any other label than <code>highres</code> and <code>lowres</code> as long\nas they are consistent across subjects and sessions.</p>\n<p>In case different sequences are used to record the same modality\n(for example, <code>RARE</code> and <code>FLASH</code> for T1w)\nthis field can also be used to make that distinction.\nThe level of detail at which the distinction is made\n(for example, just between <code>RARE</code> and <code>FLASH</code>, or between <code>RARE</code>, <code>FLASH</code>, and <code>FLASHsubsampled</code>)\nremains at the discretion of the researcher.</p>", "type": "string", "format": "label", "required": "optional"}, "ceagent": {"name": "ce", "display_name": "Contrast Enhancing Agent", "description": "<p>The <code>ce-&lt;label&gt;</code> entity can be used to distinguish sequences using different contrast enhanced images.\nThe label is the name of the contrast agent.</p>\n<p>This entity represents the <code>\"ContrastBolusIngredient\"</code> metadata field.\nTherefore, if the <code>ce-&lt;label&gt;</code> entity is present in a filename,\n<code>\"ContrastBolusIngredient\"</code> MAY also be added in the JSON file, with the same label.</p>", "type": "string", "format": "label", "required": "optional"}, "reconstruction": {"name": "rec", "display_name": "Reconstruction", "description": "<p>The <code>rec-&lt;label&gt;</code> entity can be used to distinguish different reconstruction algorithms\n(for example, <code>MoCo</code> for the ones using motion correction).</p>", "type": "string", "format": "label", "required": "optional"}, "run": {"name": "run", "display_name": "Run", "description": "<p>The <code>run-&lt;index&gt;</code> entity is used to distinguish separate data acquisitions with the same acquisition parameters\nand (other) entities.</p>\n<p>If several data acquisitions (for example, MRI scans or EEG recordings)\nwith the same acquisition parameters are acquired in the same session,\nthey MUST be indexed with the <a href=\"SPEC_ROOT/appendices/entities.md#run\"><code>run-&lt;index&gt;</code></a> entity:\n<code>_run-1</code>, <code>_run-2</code>, <code>_run-3</code>, and so on\n(only nonnegative integers are allowed as run indices).</p>\n<p>If different entities apply,\nsuch as a different session indicated by [<code>ses-&lt;label&gt;</code>][SPEC_ROOT/appendices/entities.md#ses),\nor different acquisition parameters indicated by\n<a href=\"SPEC_ROOT/appendices/entities.md#acq\"><code>acq-&lt;label&gt;</code></a>,\nthen <code>run</code> is not needed to distinguish the scans and MAY be omitted.</p>", "type": "string", "format": "index", "required": "optional"}, "flip": {"name": "flip", "display_name": "Flip Angle", "description": "<p>If files belonging to an entity-linked file collection are acquired at different\nflip angles, the <code>_flip-&lt;index&gt;</code> entity pair MUST be used to distinguish\nindividual files.</p>\n<p>This entity represents the <code>\"FlipAngle\"</code> metadata field.\nTherefore, if the <code>flip-&lt;index&gt;</code> entity is present in a filename,\n<code>\"FlipAngle\"</code> MUST be defined in the associated metadata.\nPlease note that the <code>&lt;index&gt;</code> denotes the number/index (in the form of a nonnegative integer),\nnot the <code>\"FlipAngle\"</code> value of the separate JSON file.</p>", "type": "string", "format": "index", "required": "required"}, "inversion": {"name": "inv", "display_name": "Inversion Time", "description": "<p>If files belonging to an entity-linked file collection are acquired at different inversion times,\nthe <code>inv-&lt;index&gt;</code> entity MUST be used to distinguish individual files.</p>\n<p>This entity represents the <code>\"InversionTime</code> metadata field.\nTherefore, if the <code>inv-&lt;index&gt;</code> entity is present in a filename,\n<code>\"InversionTime\"</code> MUST be defined in the associated metadata.\nPlease note that the <code>&lt;index&gt;</code> denotes the number/index (in the form of a nonnegative integer),\nnot the <code>\"InversionTime\"</code> value of the separate JSON file.</p>", "type": "string", "format": "index", "required": "optional"}, "part": {"name": "part", "display_name": "Part", "description": "<p>This entity is used to indicate which component of the complex\nrepresentation of the MRI signal is represented in voxel data.\nThe <code>part-&lt;label&gt;</code> entity is associated with the DICOM Tag\n<code>0008, 9208</code>.\nAllowed label values for this entity are <code>phase</code>, <code>mag</code>, <code>real</code> and <code>imag</code>,\nwhich are typically used in <code>part-mag</code>/<code>part-phase</code> or\n<code>part-real</code>/<code>part-imag</code> pairs of files.</p>\n<p>Phase images MAY be in radians or in arbitrary units.\nThe sidecar JSON file MUST include the <code>\"Units\"</code> of the <code>phase</code> image.\nThe possible options are <code>\"rad\"</code> or <code>\"arbitrary\"</code>.</p>\n<p>When there is only a magnitude image of a given type, the <code>part</code> entity MAY be\nomitted.</p>", "type": "string", "format": "label", "enum": ["mag", "phase", "real", "imag"], "required": "optional"}, "chunk": {"name": "chunk", "display_name": "Chunk", "description": "<p>The <code>chunk-&lt;index&gt;</code> key/value pair is used to distinguish between images of\nthe same physical sample with different fields of view acquired in the same\nimaging experiment.\nThis entity applies to collections of 2D images, 3D volumes or 4D volume series\n(for example, diffusion weighted images), and may be used to indicate different\nanatomical structures or regions of the same structure.</p>", "type": "string", "format": "index", "required": "optional"}}, "value": "TB1DAM", "display_name": "TB1DAM", "description": "<p>The double-angle B1<sup>+</sup> method\n(<a href=\"https://doi.org/10.1006/jmra.1993.1133\">Insko and Bolinger 1993</a>) is based\non the calculation of the actual angles from signal ratios,\ncollected by two acquisitions at different nominal excitation flip angles.\nCommon sequence types for this application include spin echo and echo planar\nimaging.</p>\n<br><code>TB1DAM</code>"}, {"entities": {"subject": {"name": "sub", "display_name": "Subject", "description": "<p>A person or animal participating in the study.</p>", "type": "string", "format": "label", "required": "required"}, "session": {"name": "ses", "display_name": "Session", "description": "<p>A logical grouping of neuroimaging and behavioral data consistent across subjects.\nSession can (but doesn't have to) be synonymous to a visit in a longitudinal study.\nIn general, subjects will stay in the scanner during one session.\nHowever, for example, if a subject has to leave the scanner room and then\nbe re-positioned on the scanner bed, the set of MRI acquisitions will still\nbe considered as a session and match sessions acquired in other subjects.\nSimilarly, in situations where different data types are obtained over\nseveral visits (for example fMRI on one day followed by DWI the day after)\nthose can be grouped in one session.</p>\n<p>Defining multiple sessions is appropriate when several identical or similar\ndata acquisitions are planned and performed on all -or most- subjects,\noften in the case of some intervention between sessions\n(for example, training).</p>", "type": "string", "format": "label", "required": "optional"}, "acquisition": {"name": "acq", "display_name": "Acquisition", "description": "<p>The <code>acq-&lt;label&gt;</code> entity corresponds to a custom label the user MAY use to distinguish\na different set of parameters used for acquiring the same modality.</p>\n<p>For example, this should be used when a study includes two T1w images -\none full brain low resolution and one restricted field of view but high resolution.\nIn such case two files could have the following names:\n<code>sub-01_acq-highres_T1w.nii.gz</code> and <code>sub-01_acq-lowres_T1w.nii.gz</code>;\nhowever, the user is free to choose any other label than <code>highres</code> and <code>lowres</code> as long\nas they are consistent across subjects and sessions.</p>\n<p>In case different sequences are used to record the same modality\n(for example, <code>RARE</code> and <code>FLASH</code> for T1w)\nthis field can also be used to make that distinction.\nThe level of detail at which the distinction is made\n(for example, just between <code>RARE</code> and <code>FLASH</code>, or between <code>RARE</code>, <code>FLASH</code>, and <code>FLASHsubsampled</code>)\nremains at the discretion of the researcher.</p>", "type": "string", "format": "label", "required": "optional"}, "ceagent": {"name": "ce", "display_name": "Contrast Enhancing Agent", "description": "<p>The <code>ce-&lt;label&gt;</code> entity can be used to distinguish sequences using different contrast enhanced images.\nThe label is the name of the contrast agent.</p>\n<p>This entity represents the <code>\"ContrastBolusIngredient\"</code> metadata field.\nTherefore, if the <code>ce-&lt;label&gt;</code> entity is present in a filename,\n<code>\"ContrastBolusIngredient\"</code> MAY also be added in the JSON file, with the same label.</p>", "type": "string", "format": "label", "required": "optional"}, "reconstruction": {"name": "rec", "display_name": "Reconstruction", "description": "<p>The <code>rec-&lt;label&gt;</code> entity can be used to distinguish different reconstruction algorithms\n(for example, <code>MoCo</code> for the ones using motion correction).</p>", "type": "string", "format": "label", "required": "optional"}, "run": {"name": "run", "display_name": "Run", "description": "<p>The <code>run-&lt;index&gt;</code> entity is used to distinguish separate data acquisitions with the same acquisition parameters\nand (other) entities.</p>\n<p>If several data acquisitions (for example, MRI scans or EEG recordings)\nwith the same acquisition parameters are acquired in the same session,\nthey MUST be indexed with the <a href=\"SPEC_ROOT/appendices/entities.md#run\"><code>run-&lt;index&gt;</code></a> entity:\n<code>_run-1</code>, <code>_run-2</code>, <code>_run-3</code>, and so on\n(only nonnegative integers are allowed as run indices).</p>\n<p>If different entities apply,\nsuch as a different session indicated by [<code>ses-&lt;label&gt;</code>][SPEC_ROOT/appendices/entities.md#ses),\nor different acquisition parameters indicated by\n<a href=\"SPEC_ROOT/appendices/entities.md#acq\"><code>acq-&lt;label&gt;</code></a>,\nthen <code>run</code> is not needed to distinguish the scans and MAY be omitted.</p>", "type": "string", "format": "index", "required": "optional"}, "echo": {"name": "echo", "display_name": "Echo", "description": "<p>If files belonging to an entity-linked file collection are acquired at different\necho times, the <code>echo-&lt;index&gt;</code> entity MUST be used to distinguish individual files.</p>\n<p>This entity represents the <code>\"EchoTime\"</code> metadata field.\nTherefore, if the <code>echo-&lt;index&gt;</code> entity is present in a filename,\n<code>\"EchoTime\"</code> MUST be defined in the associated metadata.\nPlease note that the <code>&lt;index&gt;</code> denotes the number/index (in the form of a nonnegative integer),\nnot the <code>\"EchoTime\"</code> value of the separate JSON file.</p>", "type": "string", "format": "index", "required": "required"}, "flip": {"name": "flip", "display_name": "Flip Angle", "description": "<p>If files belonging to an entity-linked file collection are acquired at different\nflip angles, the <code>_flip-&lt;index&gt;</code> entity pair MUST be used to distinguish\nindividual files.</p>\n<p>This entity represents the <code>\"FlipAngle\"</code> metadata field.\nTherefore, if the <code>flip-&lt;index&gt;</code> entity is present in a filename,\n<code>\"FlipAngle\"</code> MUST be defined in the associated metadata.\nPlease note that the <code>&lt;index&gt;</code> denotes the number/index (in the form of a nonnegative integer),\nnot the <code>\"FlipAngle\"</code> value of the separate JSON file.</p>", "type": "string", "format": "index", "required": "required"}, "inversion": {"name": "inv", "display_name": "Inversion Time", "description": "<p>If files belonging to an entity-linked file collection are acquired at different inversion times,\nthe <code>inv-&lt;index&gt;</code> entity MUST be used to distinguish individual files.</p>\n<p>This entity represents the <code>\"InversionTime</code> metadata field.\nTherefore, if the <code>inv-&lt;index&gt;</code> entity is present in a filename,\n<code>\"InversionTime\"</code> MUST be defined in the associated metadata.\nPlease note that the <code>&lt;index&gt;</code> denotes the number/index (in the form of a nonnegative integer),\nnot the <code>\"InversionTime\"</code> value of the separate JSON file.</p>", "type": "string", "format": "index", "required": "optional"}, "part": {"name": "part", "display_name": "Part", "description": "<p>This entity is used to indicate which component of the complex\nrepresentation of the MRI signal is represented in voxel data.\nThe <code>part-&lt;label&gt;</code> entity is associated with the DICOM Tag\n<code>0008, 9208</code>.\nAllowed label values for this entity are <code>phase</code>, <code>mag</code>, <code>real</code> and <code>imag</code>,\nwhich are typically used in <code>part-mag</code>/<code>part-phase</code> or\n<code>part-real</code>/<code>part-imag</code> pairs of files.</p>\n<p>Phase images MAY be in radians or in arbitrary units.\nThe sidecar JSON file MUST include the <code>\"Units\"</code> of the <code>phase</code> image.\nThe possible options are <code>\"rad\"</code> or <code>\"arbitrary\"</code>.</p>\n<p>When there is only a magnitude image of a given type, the <code>part</code> entity MAY be\nomitted.</p>", "type": "string", "format": "label", "enum": ["mag", "phase", "real", "imag"], "required": "optional"}, "chunk": {"name": "chunk", "display_name": "Chunk", "description": "<p>The <code>chunk-&lt;index&gt;</code> key/value pair is used to distinguish between images of\nthe same physical sample with different fields of view acquired in the same\nimaging experiment.\nThis entity applies to collections of 2D images, 3D volumes or 4D volume series\n(for example, diffusion weighted images), and may be used to indicate different\nanatomical structures or regions of the same structure.</p>", "type": "string", "format": "index", "required": "optional"}}, "value": "TB1EPI", "display_name": "TB1EPI", "description": "<p>This B1<sup>+</sup> mapping method\n(<a href=\"https://doi.org/10.1002/mrm.21083\">Jiru and Klose 2006</a>) is based on two\nEPI readouts to acquire spin echo (SE) and stimulated echo (STE) images at\nmultiple flip angles in one sequence, used in the calculation of deviations\nfrom the nominal flip angle.</p>\n<br><code>TB1EPI</code>"}, {"entities": {"subject": {"name": "sub", "display_name": "Subject", "description": "<p>A person or animal participating in the study.</p>", "type": "string", "format": "label", "required": "required"}, "session": {"name": "ses", "display_name": "Session", "description": "<p>A logical grouping of neuroimaging and behavioral data consistent across subjects.\nSession can (but doesn't have to) be synonymous to a visit in a longitudinal study.\nIn general, subjects will stay in the scanner during one session.\nHowever, for example, if a subject has to leave the scanner room and then\nbe re-positioned on the scanner bed, the set of MRI acquisitions will still\nbe considered as a session and match sessions acquired in other subjects.\nSimilarly, in situations where different data types are obtained over\nseveral visits (for example fMRI on one day followed by DWI the day after)\nthose can be grouped in one session.</p>\n<p>Defining multiple sessions is appropriate when several identical or similar\ndata acquisitions are planned and performed on all -or most- subjects,\noften in the case of some intervention between sessions\n(for example, training).</p>", "type": "string", "format": "label", "required": "optional"}, "acquisition": {"name": "acq", "display_name": "Acquisition", "description": "<p>The <code>acq-&lt;label&gt;</code> entity corresponds to a custom label the user MAY use to distinguish\na different set of parameters used for acquiring the same modality.</p>\n<p>For example, this should be used when a study includes two T1w images -\none full brain low resolution and one restricted field of view but high resolution.\nIn such case two files could have the following names:\n<code>sub-01_acq-highres_T1w.nii.gz</code> and <code>sub-01_acq-lowres_T1w.nii.gz</code>;\nhowever, the user is free to choose any other label than <code>highres</code> and <code>lowres</code> as long\nas they are consistent across subjects and sessions.</p>\n<p>In case different sequences are used to record the same modality\n(for example, <code>RARE</code> and <code>FLASH</code> for T1w)\nthis field can also be used to make that distinction.\nThe level of detail at which the distinction is made\n(for example, just between <code>RARE</code> and <code>FLASH</code>, or between <code>RARE</code>, <code>FLASH</code>, and <code>FLASHsubsampled</code>)\nremains at the discretion of the researcher.</p>", "type": "string", "format": "label", "required": "optional"}, "ceagent": {"name": "ce", "display_name": "Contrast Enhancing Agent", "description": "<p>The <code>ce-&lt;label&gt;</code> entity can be used to distinguish sequences using different contrast enhanced images.\nThe label is the name of the contrast agent.</p>\n<p>This entity represents the <code>\"ContrastBolusIngredient\"</code> metadata field.\nTherefore, if the <code>ce-&lt;label&gt;</code> entity is present in a filename,\n<code>\"ContrastBolusIngredient\"</code> MAY also be added in the JSON file, with the same label.</p>", "type": "string", "format": "label", "required": "optional"}, "reconstruction": {"name": "rec", "display_name": "Reconstruction", "description": "<p>The <code>rec-&lt;label&gt;</code> entity can be used to distinguish different reconstruction algorithms\n(for example, <code>MoCo</code> for the ones using motion correction).</p>", "type": "string", "format": "label", "required": "optional"}, "run": {"name": "run", "display_name": "Run", "description": "<p>The <code>run-&lt;index&gt;</code> entity is used to distinguish separate data acquisitions with the same acquisition parameters\nand (other) entities.</p>\n<p>If several data acquisitions (for example, MRI scans or EEG recordings)\nwith the same acquisition parameters are acquired in the same session,\nthey MUST be indexed with the <a href=\"SPEC_ROOT/appendices/entities.md#run\"><code>run-&lt;index&gt;</code></a> entity:\n<code>_run-1</code>, <code>_run-2</code>, <code>_run-3</code>, and so on\n(only nonnegative integers are allowed as run indices).</p>\n<p>If different entities apply,\nsuch as a different session indicated by [<code>ses-&lt;label&gt;</code>][SPEC_ROOT/appendices/entities.md#ses),\nor different acquisition parameters indicated by\n<a href=\"SPEC_ROOT/appendices/entities.md#acq\"><code>acq-&lt;label&gt;</code></a>,\nthen <code>run</code> is not needed to distinguish the scans and MAY be omitted.</p>", "type": "string", "format": "index", "required": "optional"}, "echo": {"name": "echo", "display_name": "Echo", "description": "<p>If files belonging to an entity-linked file collection are acquired at different\necho times, the <code>echo-&lt;index&gt;</code> entity MUST be used to distinguish individual files.</p>\n<p>This entity represents the <code>\"EchoTime\"</code> metadata field.\nTherefore, if the <code>echo-&lt;index&gt;</code> entity is present in a filename,\n<code>\"EchoTime\"</code> MUST be defined in the associated metadata.\nPlease note that the <code>&lt;index&gt;</code> denotes the number/index (in the form of a nonnegative integer),\nnot the <code>\"EchoTime\"</code> value of the separate JSON file.</p>", "type": "string", "format": "index", "required": "optional"}, "flip": {"name": "flip", "display_name": "Flip Angle", "description": "<p>If files belonging to an entity-linked file collection are acquired at different\nflip angles, the <code>_flip-&lt;index&gt;</code> entity pair MUST be used to distinguish\nindividual files.</p>\n<p>This entity represents the <code>\"FlipAngle\"</code> metadata field.\nTherefore, if the <code>flip-&lt;index&gt;</code> entity is present in a filename,\n<code>\"FlipAngle\"</code> MUST be defined in the associated metadata.\nPlease note that the <code>&lt;index&gt;</code> denotes the number/index (in the form of a nonnegative integer),\nnot the <code>\"FlipAngle\"</code> value of the separate JSON file.</p>", "type": "string", "format": "index", "required": "optional"}, "inversion": {"name": "inv", "display_name": "Inversion Time", "description": "<p>If files belonging to an entity-linked file collection are acquired at different inversion times,\nthe <code>inv-&lt;index&gt;</code> entity MUST be used to distinguish individual files.</p>\n<p>This entity represents the <code>\"InversionTime</code> metadata field.\nTherefore, if the <code>inv-&lt;index&gt;</code> entity is present in a filename,\n<code>\"InversionTime\"</code> MUST be defined in the associated metadata.\nPlease note that the <code>&lt;index&gt;</code> denotes the number/index (in the form of a nonnegative integer),\nnot the <code>\"InversionTime\"</code> value of the separate JSON file.</p>", "type": "string", "format": "index", "required": "optional"}, "part": {"name": "part", "display_name": "Part", "description": "<p>This entity is used to indicate which component of the complex\nrepresentation of the MRI signal is represented in voxel data.\nThe <code>part-&lt;label&gt;</code> entity is associated with the DICOM Tag\n<code>0008, 9208</code>.\nAllowed label values for this entity are <code>phase</code>, <code>mag</code>, <code>real</code> and <code>imag</code>,\nwhich are typically used in <code>part-mag</code>/<code>part-phase</code> or\n<code>part-real</code>/<code>part-imag</code> pairs of files.</p>\n<p>Phase images MAY be in radians or in arbitrary units.\nThe sidecar JSON file MUST include the <code>\"Units\"</code> of the <code>phase</code> image.\nThe possible options are <code>\"rad\"</code> or <code>\"arbitrary\"</code>.</p>\n<p>When there is only a magnitude image of a given type, the <code>part</code> entity MAY be\nomitted.</p>", "type": "string", "format": "label", "enum": ["mag", "phase", "real", "imag"], "required": "optional"}, "chunk": {"name": "chunk", "display_name": "Chunk", "description": "<p>The <code>chunk-&lt;index&gt;</code> key/value pair is used to distinguish between images of\nthe same physical sample with different fields of view acquired in the same\nimaging experiment.\nThis entity applies to collections of 2D images, 3D volumes or 4D volume series\n(for example, diffusion weighted images), and may be used to indicate different\nanatomical structures or regions of the same structure.</p>", "type": "string", "format": "index", "required": "optional"}}, "value": "TB1AFI", "display_name": "TB1AFI", "description": "<p>This method (<a href=\"https://doi.org/10.1002/mrm.21120\">Yarnykh 2007</a>)\ncalculates a B1<sup>+</sup> map from two images acquired at interleaved (two)\nTRs with identical RF pulses using a steady-state sequence.</p>\n<br><code>RFFieldMaps</code>"}, {"entities": {"subject": {"name": "sub", "display_name": "Subject", "description": "<p>A person or animal participating in the study.</p>", "type": "string", "format": "label", "required": "required"}, "session": {"name": "ses", "display_name": "Session", "description": "<p>A logical grouping of neuroimaging and behavioral data consistent across subjects.\nSession can (but doesn't have to) be synonymous to a visit in a longitudinal study.\nIn general, subjects will stay in the scanner during one session.\nHowever, for example, if a subject has to leave the scanner room and then\nbe re-positioned on the scanner bed, the set of MRI acquisitions will still\nbe considered as a session and match sessions acquired in other subjects.\nSimilarly, in situations where different data types are obtained over\nseveral visits (for example fMRI on one day followed by DWI the day after)\nthose can be grouped in one session.</p>\n<p>Defining multiple sessions is appropriate when several identical or similar\ndata acquisitions are planned and performed on all -or most- subjects,\noften in the case of some intervention between sessions\n(for example, training).</p>", "type": "string", "format": "label", "required": "optional"}, "acquisition": {"name": "acq", "display_name": "Acquisition", "description": "<p>The <code>acq-&lt;label&gt;</code> entity corresponds to a custom label the user MAY use to distinguish\na different set of parameters used for acquiring the same modality.</p>\n<p>For example, this should be used when a study includes two T1w images -\none full brain low resolution and one restricted field of view but high resolution.\nIn such case two files could have the following names:\n<code>sub-01_acq-highres_T1w.nii.gz</code> and <code>sub-01_acq-lowres_T1w.nii.gz</code>;\nhowever, the user is free to choose any other label than <code>highres</code> and <code>lowres</code> as long\nas they are consistent across subjects and sessions.</p>\n<p>In case different sequences are used to record the same modality\n(for example, <code>RARE</code> and <code>FLASH</code> for T1w)\nthis field can also be used to make that distinction.\nThe level of detail at which the distinction is made\n(for example, just between <code>RARE</code> and <code>FLASH</code>, or between <code>RARE</code>, <code>FLASH</code>, and <code>FLASHsubsampled</code>)\nremains at the discretion of the researcher.</p>", "type": "string", "format": "label", "required": "optional"}, "ceagent": {"name": "ce", "display_name": "Contrast Enhancing Agent", "description": "<p>The <code>ce-&lt;label&gt;</code> entity can be used to distinguish sequences using different contrast enhanced images.\nThe label is the name of the contrast agent.</p>\n<p>This entity represents the <code>\"ContrastBolusIngredient\"</code> metadata field.\nTherefore, if the <code>ce-&lt;label&gt;</code> entity is present in a filename,\n<code>\"ContrastBolusIngredient\"</code> MAY also be added in the JSON file, with the same label.</p>", "type": "string", "format": "label", "required": "optional"}, "reconstruction": {"name": "rec", "display_name": "Reconstruction", "description": "<p>The <code>rec-&lt;label&gt;</code> entity can be used to distinguish different reconstruction algorithms\n(for example, <code>MoCo</code> for the ones using motion correction).</p>", "type": "string", "format": "label", "required": "optional"}, "run": {"name": "run", "display_name": "Run", "description": "<p>The <code>run-&lt;index&gt;</code> entity is used to distinguish separate data acquisitions with the same acquisition parameters\nand (other) entities.</p>\n<p>If several data acquisitions (for example, MRI scans or EEG recordings)\nwith the same acquisition parameters are acquired in the same session,\nthey MUST be indexed with the <a href=\"SPEC_ROOT/appendices/entities.md#run\"><code>run-&lt;index&gt;</code></a> entity:\n<code>_run-1</code>, <code>_run-2</code>, <code>_run-3</code>, and so on\n(only nonnegative integers are allowed as run indices).</p>\n<p>If different entities apply,\nsuch as a different session indicated by [<code>ses-&lt;label&gt;</code>][SPEC_ROOT/appendices/entities.md#ses),\nor different acquisition parameters indicated by\n<a href=\"SPEC_ROOT/appendices/entities.md#acq\"><code>acq-&lt;label&gt;</code></a>,\nthen <code>run</code> is not needed to distinguish the scans and MAY be omitted.</p>", "type": "string", "format": "index", "required": "optional"}, "echo": {"name": "echo", "display_name": "Echo", "description": "<p>If files belonging to an entity-linked file collection are acquired at different\necho times, the <code>echo-&lt;index&gt;</code> entity MUST be used to distinguish individual files.</p>\n<p>This entity represents the <code>\"EchoTime\"</code> metadata field.\nTherefore, if the <code>echo-&lt;index&gt;</code> entity is present in a filename,\n<code>\"EchoTime\"</code> MUST be defined in the associated metadata.\nPlease note that the <code>&lt;index&gt;</code> denotes the number/index (in the form of a nonnegative integer),\nnot the <code>\"EchoTime\"</code> value of the separate JSON file.</p>", "type": "string", "format": "index", "required": "optional"}, "flip": {"name": "flip", "display_name": "Flip Angle", "description": "<p>If files belonging to an entity-linked file collection are acquired at different\nflip angles, the <code>_flip-&lt;index&gt;</code> entity pair MUST be used to distinguish\nindividual files.</p>\n<p>This entity represents the <code>\"FlipAngle\"</code> metadata field.\nTherefore, if the <code>flip-&lt;index&gt;</code> entity is present in a filename,\n<code>\"FlipAngle\"</code> MUST be defined in the associated metadata.\nPlease note that the <code>&lt;index&gt;</code> denotes the number/index (in the form of a nonnegative integer),\nnot the <code>\"FlipAngle\"</code> value of the separate JSON file.</p>", "type": "string", "format": "index", "required": "optional"}, "inversion": {"name": "inv", "display_name": "Inversion Time", "description": "<p>If files belonging to an entity-linked file collection are acquired at different inversion times,\nthe <code>inv-&lt;index&gt;</code> entity MUST be used to distinguish individual files.</p>\n<p>This entity represents the <code>\"InversionTime</code> metadata field.\nTherefore, if the <code>inv-&lt;index&gt;</code> entity is present in a filename,\n<code>\"InversionTime\"</code> MUST be defined in the associated metadata.\nPlease note that the <code>&lt;index&gt;</code> denotes the number/index (in the form of a nonnegative integer),\nnot the <code>\"InversionTime\"</code> value of the separate JSON file.</p>", "type": "string", "format": "index", "required": "optional"}, "part": {"name": "part", "display_name": "Part", "description": "<p>This entity is used to indicate which component of the complex\nrepresentation of the MRI signal is represented in voxel data.\nThe <code>part-&lt;label&gt;</code> entity is associated with the DICOM Tag\n<code>0008, 9208</code>.\nAllowed label values for this entity are <code>phase</code>, <code>mag</code>, <code>real</code> and <code>imag</code>,\nwhich are typically used in <code>part-mag</code>/<code>part-phase</code> or\n<code>part-real</code>/<code>part-imag</code> pairs of files.</p>\n<p>Phase images MAY be in radians or in arbitrary units.\nThe sidecar JSON file MUST include the <code>\"Units\"</code> of the <code>phase</code> image.\nThe possible options are <code>\"rad\"</code> or <code>\"arbitrary\"</code>.</p>\n<p>When there is only a magnitude image of a given type, the <code>part</code> entity MAY be\nomitted.</p>", "type": "string", "format": "label", "enum": ["mag", "phase", "real", "imag"], "required": "optional"}, "chunk": {"name": "chunk", "display_name": "Chunk", "description": "<p>The <code>chunk-&lt;index&gt;</code> key/value pair is used to distinguish between images of\nthe same physical sample with different fields of view acquired in the same\nimaging experiment.\nThis entity applies to collections of 2D images, 3D volumes or 4D volume series\n(for example, diffusion weighted images), and may be used to indicate different\nanatomical structures or regions of the same structure.</p>", "type": "string", "format": "index", "required": "optional"}}, "value": "TB1TFL", "display_name": "TB1TFL", "description": "<p>The result of a Siemens <code>tfl_b1_map</code> product sequence.\nThis sequence produces two images.\nThe first image appears like an anatomical image and the second output is a\nscaled flip angle map.</p>\n<br><code>RFFieldMaps</code>"}, {"entities": {"subject": {"name": "sub", "display_name": "Subject", "description": "<p>A person or animal participating in the study.</p>", "type": "string", "format": "label", "required": "required"}, "session": {"name": "ses", "display_name": "Session", "description": "<p>A logical grouping of neuroimaging and behavioral data consistent across subjects.\nSession can (but doesn't have to) be synonymous to a visit in a longitudinal study.\nIn general, subjects will stay in the scanner during one session.\nHowever, for example, if a subject has to leave the scanner room and then\nbe re-positioned on the scanner bed, the set of MRI acquisitions will still\nbe considered as a session and match sessions acquired in other subjects.\nSimilarly, in situations where different data types are obtained over\nseveral visits (for example fMRI on one day followed by DWI the day after)\nthose can be grouped in one session.</p>\n<p>Defining multiple sessions is appropriate when several identical or similar\ndata acquisitions are planned and performed on all -or most- subjects,\noften in the case of some intervention between sessions\n(for example, training).</p>", "type": "string", "format": "label", "required": "optional"}, "acquisition": {"name": "acq", "display_name": "Acquisition", "description": "<p>The <code>acq-&lt;label&gt;</code> entity corresponds to a custom label the user MAY use to distinguish\na different set of parameters used for acquiring the same modality.</p>\n<p>For example, this should be used when a study includes two T1w images -\none full brain low resolution and one restricted field of view but high resolution.\nIn such case two files could have the following names:\n<code>sub-01_acq-highres_T1w.nii.gz</code> and <code>sub-01_acq-lowres_T1w.nii.gz</code>;\nhowever, the user is free to choose any other label than <code>highres</code> and <code>lowres</code> as long\nas they are consistent across subjects and sessions.</p>\n<p>In case different sequences are used to record the same modality\n(for example, <code>RARE</code> and <code>FLASH</code> for T1w)\nthis field can also be used to make that distinction.\nThe level of detail at which the distinction is made\n(for example, just between <code>RARE</code> and <code>FLASH</code>, or between <code>RARE</code>, <code>FLASH</code>, and <code>FLASHsubsampled</code>)\nremains at the discretion of the researcher.</p>", "type": "string", "format": "label", "required": "optional"}, "ceagent": {"name": "ce", "display_name": "Contrast Enhancing Agent", "description": "<p>The <code>ce-&lt;label&gt;</code> entity can be used to distinguish sequences using different contrast enhanced images.\nThe label is the name of the contrast agent.</p>\n<p>This entity represents the <code>\"ContrastBolusIngredient\"</code> metadata field.\nTherefore, if the <code>ce-&lt;label&gt;</code> entity is present in a filename,\n<code>\"ContrastBolusIngredient\"</code> MAY also be added in the JSON file, with the same label.</p>", "type": "string", "format": "label", "required": "optional"}, "reconstruction": {"name": "rec", "display_name": "Reconstruction", "description": "<p>The <code>rec-&lt;label&gt;</code> entity can be used to distinguish different reconstruction algorithms\n(for example, <code>MoCo</code> for the ones using motion correction).</p>", "type": "string", "format": "label", "required": "optional"}, "run": {"name": "run", "display_name": "Run", "description": "<p>The <code>run-&lt;index&gt;</code> entity is used to distinguish separate data acquisitions with the same acquisition parameters\nand (other) entities.</p>\n<p>If several data acquisitions (for example, MRI scans or EEG recordings)\nwith the same acquisition parameters are acquired in the same session,\nthey MUST be indexed with the <a href=\"SPEC_ROOT/appendices/entities.md#run\"><code>run-&lt;index&gt;</code></a> entity:\n<code>_run-1</code>, <code>_run-2</code>, <code>_run-3</code>, and so on\n(only nonnegative integers are allowed as run indices).</p>\n<p>If different entities apply,\nsuch as a different session indicated by [<code>ses-&lt;label&gt;</code>][SPEC_ROOT/appendices/entities.md#ses),\nor different acquisition parameters indicated by\n<a href=\"SPEC_ROOT/appendices/entities.md#acq\"><code>acq-&lt;label&gt;</code></a>,\nthen <code>run</code> is not needed to distinguish the scans and MAY be omitted.</p>", "type": "string", "format": "index", "required": "optional"}, "echo": {"name": "echo", "display_name": "Echo", "description": "<p>If files belonging to an entity-linked file collection are acquired at different\necho times, the <code>echo-&lt;index&gt;</code> entity MUST be used to distinguish individual files.</p>\n<p>This entity represents the <code>\"EchoTime\"</code> metadata field.\nTherefore, if the <code>echo-&lt;index&gt;</code> entity is present in a filename,\n<code>\"EchoTime\"</code> MUST be defined in the associated metadata.\nPlease note that the <code>&lt;index&gt;</code> denotes the number/index (in the form of a nonnegative integer),\nnot the <code>\"EchoTime\"</code> value of the separate JSON file.</p>", "type": "string", "format": "index", "required": "optional"}, "flip": {"name": "flip", "display_name": "Flip Angle", "description": "<p>If files belonging to an entity-linked file collection are acquired at different\nflip angles, the <code>_flip-&lt;index&gt;</code> entity pair MUST be used to distinguish\nindividual files.</p>\n<p>This entity represents the <code>\"FlipAngle\"</code> metadata field.\nTherefore, if the <code>flip-&lt;index&gt;</code> entity is present in a filename,\n<code>\"FlipAngle\"</code> MUST be defined in the associated metadata.\nPlease note that the <code>&lt;index&gt;</code> denotes the number/index (in the form of a nonnegative integer),\nnot the <code>\"FlipAngle\"</code> value of the separate JSON file.</p>", "type": "string", "format": "index", "required": "optional"}, "inversion": {"name": "inv", "display_name": "Inversion Time", "description": "<p>If files belonging to an entity-linked file collection are acquired at different inversion times,\nthe <code>inv-&lt;index&gt;</code> entity MUST be used to distinguish individual files.</p>\n<p>This entity represents the <code>\"InversionTime</code> metadata field.\nTherefore, if the <code>inv-&lt;index&gt;</code> entity is present in a filename,\n<code>\"InversionTime\"</code> MUST be defined in the associated metadata.\nPlease note that the <code>&lt;index&gt;</code> denotes the number/index (in the form of a nonnegative integer),\nnot the <code>\"InversionTime\"</code> value of the separate JSON file.</p>", "type": "string", "format": "index", "required": "optional"}, "part": {"name": "part", "display_name": "Part", "description": "<p>This entity is used to indicate which component of the complex\nrepresentation of the MRI signal is represented in voxel data.\nThe <code>part-&lt;label&gt;</code> entity is associated with the DICOM Tag\n<code>0008, 9208</code>.\nAllowed label values for this entity are <code>phase</code>, <code>mag</code>, <code>real</code> and <code>imag</code>,\nwhich are typically used in <code>part-mag</code>/<code>part-phase</code> or\n<code>part-real</code>/<code>part-imag</code> pairs of files.</p>\n<p>Phase images MAY be in radians or in arbitrary units.\nThe sidecar JSON file MUST include the <code>\"Units\"</code> of the <code>phase</code> image.\nThe possible options are <code>\"rad\"</code> or <code>\"arbitrary\"</code>.</p>\n<p>When there is only a magnitude image of a given type, the <code>part</code> entity MAY be\nomitted.</p>", "type": "string", "format": "label", "enum": ["mag", "phase", "real", "imag"], "required": "optional"}, "chunk": {"name": "chunk", "display_name": "Chunk", "description": "<p>The <code>chunk-&lt;index&gt;</code> key/value pair is used to distinguish between images of\nthe same physical sample with different fields of view acquired in the same\nimaging experiment.\nThis entity applies to collections of 2D images, 3D volumes or 4D volume series\n(for example, diffusion weighted images), and may be used to indicate different\nanatomical structures or regions of the same structure.</p>", "type": "string", "format": "index", "required": "optional"}}, "value": "TB1RFM", "display_name": "TB1RFM", "description": "<p>The result of a Siemens <code>rf_map</code> product sequence.\nThis sequence produces two images.\nThe first image appears like an anatomical image and the second output is a\nscaled flip angle map.</p>\n<br><code>RFFieldMaps</code>"}, {"entities": {"subject": {"name": "sub", "display_name": "Subject", "description": "<p>A person or animal participating in the study.</p>", "type": "string", "format": "label", "required": "required"}, "session": {"name": "ses", "display_name": "Session", "description": "<p>A logical grouping of neuroimaging and behavioral data consistent across subjects.\nSession can (but doesn't have to) be synonymous to a visit in a longitudinal study.\nIn general, subjects will stay in the scanner during one session.\nHowever, for example, if a subject has to leave the scanner room and then\nbe re-positioned on the scanner bed, the set of MRI acquisitions will still\nbe considered as a session and match sessions acquired in other subjects.\nSimilarly, in situations where different data types are obtained over\nseveral visits (for example fMRI on one day followed by DWI the day after)\nthose can be grouped in one session.</p>\n<p>Defining multiple sessions is appropriate when several identical or similar\ndata acquisitions are planned and performed on all -or most- subjects,\noften in the case of some intervention between sessions\n(for example, training).</p>", "type": "string", "format": "label", "required": "optional"}, "acquisition": {"name": "acq", "display_name": "Acquisition", "description": "<p>The <code>acq-&lt;label&gt;</code> entity corresponds to a custom label the user MAY use to distinguish\na different set of parameters used for acquiring the same modality.</p>\n<p>For example, this should be used when a study includes two T1w images -\none full brain low resolution and one restricted field of view but high resolution.\nIn such case two files could have the following names:\n<code>sub-01_acq-highres_T1w.nii.gz</code> and <code>sub-01_acq-lowres_T1w.nii.gz</code>;\nhowever, the user is free to choose any other label than <code>highres</code> and <code>lowres</code> as long\nas they are consistent across subjects and sessions.</p>\n<p>In case different sequences are used to record the same modality\n(for example, <code>RARE</code> and <code>FLASH</code> for T1w)\nthis field can also be used to make that distinction.\nThe level of detail at which the distinction is made\n(for example, just between <code>RARE</code> and <code>FLASH</code>, or between <code>RARE</code>, <code>FLASH</code>, and <code>FLASHsubsampled</code>)\nremains at the discretion of the researcher.</p>", "type": "string", "format": "label", "required": "optional"}, "ceagent": {"name": "ce", "display_name": "Contrast Enhancing Agent", "description": "<p>The <code>ce-&lt;label&gt;</code> entity can be used to distinguish sequences using different contrast enhanced images.\nThe label is the name of the contrast agent.</p>\n<p>This entity represents the <code>\"ContrastBolusIngredient\"</code> metadata field.\nTherefore, if the <code>ce-&lt;label&gt;</code> entity is present in a filename,\n<code>\"ContrastBolusIngredient\"</code> MAY also be added in the JSON file, with the same label.</p>", "type": "string", "format": "label", "required": "optional"}, "reconstruction": {"name": "rec", "display_name": "Reconstruction", "description": "<p>The <code>rec-&lt;label&gt;</code> entity can be used to distinguish different reconstruction algorithms\n(for example, <code>MoCo</code> for the ones using motion correction).</p>", "type": "string", "format": "label", "required": "optional"}, "run": {"name": "run", "display_name": "Run", "description": "<p>The <code>run-&lt;index&gt;</code> entity is used to distinguish separate data acquisitions with the same acquisition parameters\nand (other) entities.</p>\n<p>If several data acquisitions (for example, MRI scans or EEG recordings)\nwith the same acquisition parameters are acquired in the same session,\nthey MUST be indexed with the <a href=\"SPEC_ROOT/appendices/entities.md#run\"><code>run-&lt;index&gt;</code></a> entity:\n<code>_run-1</code>, <code>_run-2</code>, <code>_run-3</code>, and so on\n(only nonnegative integers are allowed as run indices).</p>\n<p>If different entities apply,\nsuch as a different session indicated by [<code>ses-&lt;label&gt;</code>][SPEC_ROOT/appendices/entities.md#ses),\nor different acquisition parameters indicated by\n<a href=\"SPEC_ROOT/appendices/entities.md#acq\"><code>acq-&lt;label&gt;</code></a>,\nthen <code>run</code> is not needed to distinguish the scans and MAY be omitted.</p>", "type": "string", "format": "index", "required": "optional"}, "echo": {"name": "echo", "display_name": "Echo", "description": "<p>If files belonging to an entity-linked file collection are acquired at different\necho times, the <code>echo-&lt;index&gt;</code> entity MUST be used to distinguish individual files.</p>\n<p>This entity represents the <code>\"EchoTime\"</code> metadata field.\nTherefore, if the <code>echo-&lt;index&gt;</code> entity is present in a filename,\n<code>\"EchoTime\"</code> MUST be defined in the associated metadata.\nPlease note that the <code>&lt;index&gt;</code> denotes the number/index (in the form of a nonnegative integer),\nnot the <code>\"EchoTime\"</code> value of the separate JSON file.</p>", "type": "string", "format": "index", "required": "optional"}, "flip": {"name": "flip", "display_name": "Flip Angle", "description": "<p>If files belonging to an entity-linked file collection are acquired at different\nflip angles, the <code>_flip-&lt;index&gt;</code> entity pair MUST be used to distinguish\nindividual files.</p>\n<p>This entity represents the <code>\"FlipAngle\"</code> metadata field.\nTherefore, if the <code>flip-&lt;index&gt;</code> entity is present in a filename,\n<code>\"FlipAngle\"</code> MUST be defined in the associated metadata.\nPlease note that the <code>&lt;index&gt;</code> denotes the number/index (in the form of a nonnegative integer),\nnot the <code>\"FlipAngle\"</code> value of the separate JSON file.</p>", "type": "string", "format": "index", "required": "optional"}, "inversion": {"name": "inv", "display_name": "Inversion Time", "description": "<p>If files belonging to an entity-linked file collection are acquired at different inversion times,\nthe <code>inv-&lt;index&gt;</code> entity MUST be used to distinguish individual files.</p>\n<p>This entity represents the <code>\"InversionTime</code> metadata field.\nTherefore, if the <code>inv-&lt;index&gt;</code> entity is present in a filename,\n<code>\"InversionTime\"</code> MUST be defined in the associated metadata.\nPlease note that the <code>&lt;index&gt;</code> denotes the number/index (in the form of a nonnegative integer),\nnot the <code>\"InversionTime\"</code> value of the separate JSON file.</p>", "type": "string", "format": "index", "required": "optional"}, "part": {"name": "part", "display_name": "Part", "description": "<p>This entity is used to indicate which component of the complex\nrepresentation of the MRI signal is represented in voxel data.\nThe <code>part-&lt;label&gt;</code> entity is associated with the DICOM Tag\n<code>0008, 9208</code>.\nAllowed label values for this entity are <code>phase</code>, <code>mag</code>, <code>real</code> and <code>imag</code>,\nwhich are typically used in <code>part-mag</code>/<code>part-phase</code> or\n<code>part-real</code>/<code>part-imag</code> pairs of files.</p>\n<p>Phase images MAY be in radians or in arbitrary units.\nThe sidecar JSON file MUST include the <code>\"Units\"</code> of the <code>phase</code> image.\nThe possible options are <code>\"rad\"</code> or <code>\"arbitrary\"</code>.</p>\n<p>When there is only a magnitude image of a given type, the <code>part</code> entity MAY be\nomitted.</p>", "type": "string", "format": "label", "enum": ["mag", "phase", "real", "imag"], "required": "optional"}, "chunk": {"name": "chunk", "display_name": "Chunk", "description": "<p>The <code>chunk-&lt;index&gt;</code> key/value pair is used to distinguish between images of\nthe same physical sample with different fields of view acquired in the same\nimaging experiment.\nThis entity applies to collections of 2D images, 3D volumes or 4D volume series\n(for example, diffusion weighted images), and may be used to indicate different\nanatomical structures or regions of the same structure.</p>", "type": "string", "format": "index", "required": "optional"}}, "value": "RB1COR", "display_name": "RB1COR", "description": "<p>Low resolution images acquired by the body coil\n(in the gantry of the scanner) and the head coil using identical acquisition\nparameters to generate a combined sensitivity map as described in\n<a href=\"https://doi.org/10.1002/mrm.26058\">Papp et al. (2016)</a>.</p>\n<br><code>RFFieldMaps</code>"}, {"entities": {"subject": {"name": "sub", "display_name": "Subject", "description": "<p>A person or animal participating in the study.</p>", "type": "string", "format": "label", "required": "required"}, "session": {"name": "ses", "display_name": "Session", "description": "<p>A logical grouping of neuroimaging and behavioral data consistent across subjects.\nSession can (but doesn't have to) be synonymous to a visit in a longitudinal study.\nIn general, subjects will stay in the scanner during one session.\nHowever, for example, if a subject has to leave the scanner room and then\nbe re-positioned on the scanner bed, the set of MRI acquisitions will still\nbe considered as a session and match sessions acquired in other subjects.\nSimilarly, in situations where different data types are obtained over\nseveral visits (for example fMRI on one day followed by DWI the day after)\nthose can be grouped in one session.</p>\n<p>Defining multiple sessions is appropriate when several identical or similar\ndata acquisitions are planned and performed on all -or most- subjects,\noften in the case of some intervention between sessions\n(for example, training).</p>", "type": "string", "format": "label", "required": "optional"}, "acquisition": {"name": "acq", "display_name": "Acquisition", "description": "<p>The <code>acq-&lt;label&gt;</code> entity corresponds to a custom label the user MAY use to distinguish\na different set of parameters used for acquiring the same modality.</p>\n<p>For example, this should be used when a study includes two T1w images -\none full brain low resolution and one restricted field of view but high resolution.\nIn such case two files could have the following names:\n<code>sub-01_acq-highres_T1w.nii.gz</code> and <code>sub-01_acq-lowres_T1w.nii.gz</code>;\nhowever, the user is free to choose any other label than <code>highres</code> and <code>lowres</code> as long\nas they are consistent across subjects and sessions.</p>\n<p>In case different sequences are used to record the same modality\n(for example, <code>RARE</code> and <code>FLASH</code> for T1w)\nthis field can also be used to make that distinction.\nThe level of detail at which the distinction is made\n(for example, just between <code>RARE</code> and <code>FLASH</code>, or between <code>RARE</code>, <code>FLASH</code>, and <code>FLASHsubsampled</code>)\nremains at the discretion of the researcher.</p>", "type": "string", "format": "label", "required": "optional"}, "ceagent": {"name": "ce", "display_name": "Contrast Enhancing Agent", "description": "<p>The <code>ce-&lt;label&gt;</code> entity can be used to distinguish sequences using different contrast enhanced images.\nThe label is the name of the contrast agent.</p>\n<p>This entity represents the <code>\"ContrastBolusIngredient\"</code> metadata field.\nTherefore, if the <code>ce-&lt;label&gt;</code> entity is present in a filename,\n<code>\"ContrastBolusIngredient\"</code> MAY also be added in the JSON file, with the same label.</p>", "type": "string", "format": "label", "required": "optional"}, "reconstruction": {"name": "rec", "display_name": "Reconstruction", "description": "<p>The <code>rec-&lt;label&gt;</code> entity can be used to distinguish different reconstruction algorithms\n(for example, <code>MoCo</code> for the ones using motion correction).</p>", "type": "string", "format": "label", "required": "optional"}, "run": {"name": "run", "display_name": "Run", "description": "<p>The <code>run-&lt;index&gt;</code> entity is used to distinguish separate data acquisitions with the same acquisition parameters\nand (other) entities.</p>\n<p>If several data acquisitions (for example, MRI scans or EEG recordings)\nwith the same acquisition parameters are acquired in the same session,\nthey MUST be indexed with the <a href=\"SPEC_ROOT/appendices/entities.md#run\"><code>run-&lt;index&gt;</code></a> entity:\n<code>_run-1</code>, <code>_run-2</code>, <code>_run-3</code>, and so on\n(only nonnegative integers are allowed as run indices).</p>\n<p>If different entities apply,\nsuch as a different session indicated by [<code>ses-&lt;label&gt;</code>][SPEC_ROOT/appendices/entities.md#ses),\nor different acquisition parameters indicated by\n<a href=\"SPEC_ROOT/appendices/entities.md#acq\"><code>acq-&lt;label&gt;</code></a>,\nthen <code>run</code> is not needed to distinguish the scans and MAY be omitted.</p>", "type": "string", "format": "index", "required": "optional"}, "echo": {"name": "echo", "display_name": "Echo", "description": "<p>If files belonging to an entity-linked file collection are acquired at different\necho times, the <code>echo-&lt;index&gt;</code> entity MUST be used to distinguish individual files.</p>\n<p>This entity represents the <code>\"EchoTime\"</code> metadata field.\nTherefore, if the <code>echo-&lt;index&gt;</code> entity is present in a filename,\n<code>\"EchoTime\"</code> MUST be defined in the associated metadata.\nPlease note that the <code>&lt;index&gt;</code> denotes the number/index (in the form of a nonnegative integer),\nnot the <code>\"EchoTime\"</code> value of the separate JSON file.</p>", "type": "string", "format": "index", "required": "optional"}, "flip": {"name": "flip", "display_name": "Flip Angle", "description": "<p>If files belonging to an entity-linked file collection are acquired at different\nflip angles, the <code>_flip-&lt;index&gt;</code> entity pair MUST be used to distinguish\nindividual files.</p>\n<p>This entity represents the <code>\"FlipAngle\"</code> metadata field.\nTherefore, if the <code>flip-&lt;index&gt;</code> entity is present in a filename,\n<code>\"FlipAngle\"</code> MUST be defined in the associated metadata.\nPlease note that the <code>&lt;index&gt;</code> denotes the number/index (in the form of a nonnegative integer),\nnot the <code>\"FlipAngle\"</code> value of the separate JSON file.</p>", "type": "string", "format": "index", "required": "required"}, "inversion": {"name": "inv", "display_name": "Inversion Time", "description": "<p>If files belonging to an entity-linked file collection are acquired at different inversion times,\nthe <code>inv-&lt;index&gt;</code> entity MUST be used to distinguish individual files.</p>\n<p>This entity represents the <code>\"InversionTime</code> metadata field.\nTherefore, if the <code>inv-&lt;index&gt;</code> entity is present in a filename,\n<code>\"InversionTime\"</code> MUST be defined in the associated metadata.\nPlease note that the <code>&lt;index&gt;</code> denotes the number/index (in the form of a nonnegative integer),\nnot the <code>\"InversionTime\"</code> value of the separate JSON file.</p>", "type": "string", "format": "index", "required": "required"}, "part": {"name": "part", "display_name": "Part", "description": "<p>This entity is used to indicate which component of the complex\nrepresentation of the MRI signal is represented in voxel data.\nThe <code>part-&lt;label&gt;</code> entity is associated with the DICOM Tag\n<code>0008, 9208</code>.\nAllowed label values for this entity are <code>phase</code>, <code>mag</code>, <code>real</code> and <code>imag</code>,\nwhich are typically used in <code>part-mag</code>/<code>part-phase</code> or\n<code>part-real</code>/<code>part-imag</code> pairs of files.</p>\n<p>Phase images MAY be in radians or in arbitrary units.\nThe sidecar JSON file MUST include the <code>\"Units\"</code> of the <code>phase</code> image.\nThe possible options are <code>\"rad\"</code> or <code>\"arbitrary\"</code>.</p>\n<p>When there is only a magnitude image of a given type, the <code>part</code> entity MAY be\nomitted.</p>", "type": "string", "format": "label", "enum": ["mag", "phase", "real", "imag"], "required": "optional"}, "chunk": {"name": "chunk", "display_name": "Chunk", "description": "<p>The <code>chunk-&lt;index&gt;</code> key/value pair is used to distinguish between images of\nthe same physical sample with different fields of view acquired in the same\nimaging experiment.\nThis entity applies to collections of 2D images, 3D volumes or 4D volume series\n(for example, diffusion weighted images), and may be used to indicate different\nanatomical structures or regions of the same structure.</p>", "type": "string", "format": "index", "required": "optional"}}, "value": "TB1SRGE", "display_name": "TB1SRGE", "description": "<p>Saturation-prepared with 2 rapid gradient echoes (SA2RAGE) uses a ratio of\ntwo saturation recovery images with different time delays,\nand a simulated look-up table to estimate B1+\n(<a href=\"https://doi.org/10.1002/mrm.23145\">Eggenschwiler et al. 2011</a>).\nThis sequence can also be used in conjunction with MP2RAGE T1 mapping to\niteratively improve B1+ and T1 map estimation\n(<a href=\"https://doi.org/10.1371/journal.pone.0069294\">Marques &amp; Gruetter 2013</a>).</p>\n<br><code>TB1SRGE</code>"}, {"entities": {"subject": {"name": "sub", "display_name": "Subject", "description": "<p>A person or animal participating in the study.</p>", "type": "string", "format": "label", "required": "required"}, "session": {"name": "ses", "display_name": "Session", "description": "<p>A logical grouping of neuroimaging and behavioral data consistent across subjects.\nSession can (but doesn't have to) be synonymous to a visit in a longitudinal study.\nIn general, subjects will stay in the scanner during one session.\nHowever, for example, if a subject has to leave the scanner room and then\nbe re-positioned on the scanner bed, the set of MRI acquisitions will still\nbe considered as a session and match sessions acquired in other subjects.\nSimilarly, in situations where different data types are obtained over\nseveral visits (for example fMRI on one day followed by DWI the day after)\nthose can be grouped in one session.</p>\n<p>Defining multiple sessions is appropriate when several identical or similar\ndata acquisitions are planned and performed on all -or most- subjects,\noften in the case of some intervention between sessions\n(for example, training).</p>", "type": "string", "format": "label", "required": "optional"}, "acquisition": {"name": "acq", "display_name": "Acquisition", "description": "<p>The <code>acq-&lt;label&gt;</code> entity corresponds to a custom label the user MAY use to distinguish\na different set of parameters used for acquiring the same modality.</p>\n<p>For example, this should be used when a study includes two T1w images -\none full brain low resolution and one restricted field of view but high resolution.\nIn such case two files could have the following names:\n<code>sub-01_acq-highres_T1w.nii.gz</code> and <code>sub-01_acq-lowres_T1w.nii.gz</code>;\nhowever, the user is free to choose any other label than <code>highres</code> and <code>lowres</code> as long\nas they are consistent across subjects and sessions.</p>\n<p>In case different sequences are used to record the same modality\n(for example, <code>RARE</code> and <code>FLASH</code> for T1w)\nthis field can also be used to make that distinction.\nThe level of detail at which the distinction is made\n(for example, just between <code>RARE</code> and <code>FLASH</code>, or between <code>RARE</code>, <code>FLASH</code>, and <code>FLASHsubsampled</code>)\nremains at the discretion of the researcher.</p>", "type": "string", "format": "label", "required": "optional"}, "ceagent": {"name": "ce", "display_name": "Contrast Enhancing Agent", "description": "<p>The <code>ce-&lt;label&gt;</code> entity can be used to distinguish sequences using different contrast enhanced images.\nThe label is the name of the contrast agent.</p>\n<p>This entity represents the <code>\"ContrastBolusIngredient\"</code> metadata field.\nTherefore, if the <code>ce-&lt;label&gt;</code> entity is present in a filename,\n<code>\"ContrastBolusIngredient\"</code> MAY also be added in the JSON file, with the same label.</p>", "type": "string", "format": "label", "required": "optional"}, "reconstruction": {"name": "rec", "display_name": "Reconstruction", "description": "<p>The <code>rec-&lt;label&gt;</code> entity can be used to distinguish different reconstruction algorithms\n(for example, <code>MoCo</code> for the ones using motion correction).</p>", "type": "string", "format": "label", "required": "optional"}, "run": {"name": "run", "display_name": "Run", "description": "<p>The <code>run-&lt;index&gt;</code> entity is used to distinguish separate data acquisitions with the same acquisition parameters\nand (other) entities.</p>\n<p>If several data acquisitions (for example, MRI scans or EEG recordings)\nwith the same acquisition parameters are acquired in the same session,\nthey MUST be indexed with the <a href=\"SPEC_ROOT/appendices/entities.md#run\"><code>run-&lt;index&gt;</code></a> entity:\n<code>_run-1</code>, <code>_run-2</code>, <code>_run-3</code>, and so on\n(only nonnegative integers are allowed as run indices).</p>\n<p>If different entities apply,\nsuch as a different session indicated by [<code>ses-&lt;label&gt;</code>][SPEC_ROOT/appendices/entities.md#ses),\nor different acquisition parameters indicated by\n<a href=\"SPEC_ROOT/appendices/entities.md#acq\"><code>acq-&lt;label&gt;</code></a>,\nthen <code>run</code> is not needed to distinguish the scans and MAY be omitted.</p>", "type": "string", "format": "index", "required": "optional"}, "chunk": {"name": "chunk", "display_name": "Chunk", "description": "<p>The <code>chunk-&lt;index&gt;</code> key/value pair is used to distinguish between images of\nthe same physical sample with different fields of view acquired in the same\nimaging experiment.\nThis entity applies to collections of 2D images, 3D volumes or 4D volume series\n(for example, diffusion weighted images), and may be used to indicate different\nanatomical structures or regions of the same structure.</p>", "type": "string", "format": "index", "required": "optional"}}, "value": "TB1map", "display_name": "RF transmit field image", "description": "<p>In arbitrary units (arbitrary).\nRadio frequency (RF) transmit (B1+) field maps are REQUIRED to use this\nsuffix regardless of the method used to generate them.\nTB1map intensity values are RECOMMENDED to be represented as percent\nmultiplicative factors such that FlipAngle<sub>effective</sub> =\nB1+<sub>intensity</sub>*FlipAngle<sub>nominal</sub> .</p>\n<br><code>parametric</code>", "unit": "arbitrary"}, {"entities": {"subject": {"name": "sub", "display_name": "Subject", "description": "<p>A person or animal participating in the study.</p>", "type": "string", "format": "label", "required": "required"}, "session": {"name": "ses", "display_name": "Session", "description": "<p>A logical grouping of neuroimaging and behavioral data consistent across subjects.\nSession can (but doesn't have to) be synonymous to a visit in a longitudinal study.\nIn general, subjects will stay in the scanner during one session.\nHowever, for example, if a subject has to leave the scanner room and then\nbe re-positioned on the scanner bed, the set of MRI acquisitions will still\nbe considered as a session and match sessions acquired in other subjects.\nSimilarly, in situations where different data types are obtained over\nseveral visits (for example fMRI on one day followed by DWI the day after)\nthose can be grouped in one session.</p>\n<p>Defining multiple sessions is appropriate when several identical or similar\ndata acquisitions are planned and performed on all -or most- subjects,\noften in the case of some intervention between sessions\n(for example, training).</p>", "type": "string", "format": "label", "required": "optional"}, "acquisition": {"name": "acq", "display_name": "Acquisition", "description": "<p>The <code>acq-&lt;label&gt;</code> entity corresponds to a custom label the user MAY use to distinguish\na different set of parameters used for acquiring the same modality.</p>\n<p>For example, this should be used when a study includes two T1w images -\none full brain low resolution and one restricted field of view but high resolution.\nIn such case two files could have the following names:\n<code>sub-01_acq-highres_T1w.nii.gz</code> and <code>sub-01_acq-lowres_T1w.nii.gz</code>;\nhowever, the user is free to choose any other label than <code>highres</code> and <code>lowres</code> as long\nas they are consistent across subjects and sessions.</p>\n<p>In case different sequences are used to record the same modality\n(for example, <code>RARE</code> and <code>FLASH</code> for T1w)\nthis field can also be used to make that distinction.\nThe level of detail at which the distinction is made\n(for example, just between <code>RARE</code> and <code>FLASH</code>, or between <code>RARE</code>, <code>FLASH</code>, and <code>FLASHsubsampled</code>)\nremains at the discretion of the researcher.</p>", "type": "string", "format": "label", "required": "optional"}, "ceagent": {"name": "ce", "display_name": "Contrast Enhancing Agent", "description": "<p>The <code>ce-&lt;label&gt;</code> entity can be used to distinguish sequences using different contrast enhanced images.\nThe label is the name of the contrast agent.</p>\n<p>This entity represents the <code>\"ContrastBolusIngredient\"</code> metadata field.\nTherefore, if the <code>ce-&lt;label&gt;</code> entity is present in a filename,\n<code>\"ContrastBolusIngredient\"</code> MAY also be added in the JSON file, with the same label.</p>", "type": "string", "format": "label", "required": "optional"}, "reconstruction": {"name": "rec", "display_name": "Reconstruction", "description": "<p>The <code>rec-&lt;label&gt;</code> entity can be used to distinguish different reconstruction algorithms\n(for example, <code>MoCo</code> for the ones using motion correction).</p>", "type": "string", "format": "label", "required": "optional"}, "run": {"name": "run", "display_name": "Run", "description": "<p>The <code>run-&lt;index&gt;</code> entity is used to distinguish separate data acquisitions with the same acquisition parameters\nand (other) entities.</p>\n<p>If several data acquisitions (for example, MRI scans or EEG recordings)\nwith the same acquisition parameters are acquired in the same session,\nthey MUST be indexed with the <a href=\"SPEC_ROOT/appendices/entities.md#run\"><code>run-&lt;index&gt;</code></a> entity:\n<code>_run-1</code>, <code>_run-2</code>, <code>_run-3</code>, and so on\n(only nonnegative integers are allowed as run indices).</p>\n<p>If different entities apply,\nsuch as a different session indicated by [<code>ses-&lt;label&gt;</code>][SPEC_ROOT/appendices/entities.md#ses),\nor different acquisition parameters indicated by\n<a href=\"SPEC_ROOT/appendices/entities.md#acq\"><code>acq-&lt;label&gt;</code></a>,\nthen <code>run</code> is not needed to distinguish the scans and MAY be omitted.</p>", "type": "string", "format": "index", "required": "optional"}, "chunk": {"name": "chunk", "display_name": "Chunk", "description": "<p>The <code>chunk-&lt;index&gt;</code> key/value pair is used to distinguish between images of\nthe same physical sample with different fields of view acquired in the same\nimaging experiment.\nThis entity applies to collections of 2D images, 3D volumes or 4D volume series\n(for example, diffusion weighted images), and may be used to indicate different\nanatomical structures or regions of the same structure.</p>", "type": "string", "format": "index", "required": "optional"}}, "value": "RB1map", "display_name": "RF receive sensitivity map", "description": "<p>In arbitrary units (arbitrary).\nRadio frequency (RF) receive (B1-) sensitivity maps are REQUIRED to use this\nsuffix regardless of the method used to generate them.\nRB1map intensity values are RECOMMENDED to be represented as percent\nmultiplicative factors such that Amplitude<sub>effective</sub> =\nB1-<sub>intensity</sub>*Amplitude<sub>ideal</sub>.</p>\n<br><code>parametric</code>", "unit": "arbitrary"}], "func": [{"entities": {"subject": {"name": "sub", "display_name": "Subject", "description": "<p>A person or animal participating in the study.</p>", "type": "string", "format": "label", "required": "required"}, "session": {"name": "ses", "display_name": "Session", "description": "<p>A logical grouping of neuroimaging and behavioral data consistent across subjects.\nSession can (but doesn't have to) be synonymous to a visit in a longitudinal study.\nIn general, subjects will stay in the scanner during one session.\nHowever, for example, if a subject has to leave the scanner room and then\nbe re-positioned on the scanner bed, the set of MRI acquisitions will still\nbe considered as a session and match sessions acquired in other subjects.\nSimilarly, in situations where different data types are obtained over\nseveral visits (for example fMRI on one day followed by DWI the day after)\nthose can be grouped in one session.</p>\n<p>Defining multiple sessions is appropriate when several identical or similar\ndata acquisitions are planned and performed on all -or most- subjects,\noften in the case of some intervention between sessions\n(for example, training).</p>", "type": "string", "format": "label", "required": "optional"}, "task": {"name": "task", "display_name": "Task", "description": "<p>A set of structured activities performed by the participant.\nTasks are usually accompanied by stimuli and responses, and can greatly vary in complexity.</p>\n<p>In the context of brain scanning, a task is always tied to one data acquisition.\nTherefore, even if during one acquisition the subject performed multiple conceptually different behaviors\n(with different sets of instructions) they will be considered one (combined) task.</p>\n<p>While tasks may be repeated across multiple acquisitions,\na given task may have different sets of stimuli (for example, randomized order) and participant responses\nacross subjects, sessions, and runs.</p>\n<p>The <code>task-&lt;label&gt;</code> MUST be consistent across subjects and sessions.</p>\n<p>Files with the <code>task-&lt;label&gt;</code> entity SHOULD have an associated\n<a href=\"SPEC_ROOT/modality-specific-files/task-events.md#task-events\">events file</a>,\nas well as certain metadata fields in the associated JSON file.</p>\n<p>For the purpose of this specification we consider the so-called \"resting state\" a task,\nalthough events files are not expected for resting state data.\nAdditionally, a common convention in the specification is to include the word \"rest\" in\nthe <code>task</code> label for resting state files (for example, <code>task-rest</code>).</p>", "type": "string", "format": "label", "required": "required"}, "acquisition": {"name": "acq", "display_name": "Acquisition", "description": "<p>The <code>acq-&lt;label&gt;</code> entity corresponds to a custom label the user MAY use to distinguish\na different set of parameters used for acquiring the same modality.</p>\n<p>For example, this should be used when a study includes two T1w images -\none full brain low resolution and one restricted field of view but high resolution.\nIn such case two files could have the following names:\n<code>sub-01_acq-highres_T1w.nii.gz</code> and <code>sub-01_acq-lowres_T1w.nii.gz</code>;\nhowever, the user is free to choose any other label than <code>highres</code> and <code>lowres</code> as long\nas they are consistent across subjects and sessions.</p>\n<p>In case different sequences are used to record the same modality\n(for example, <code>RARE</code> and <code>FLASH</code> for T1w)\nthis field can also be used to make that distinction.\nThe level of detail at which the distinction is made\n(for example, just between <code>RARE</code> and <code>FLASH</code>, or between <code>RARE</code>, <code>FLASH</code>, and <code>FLASHsubsampled</code>)\nremains at the discretion of the researcher.</p>", "type": "string", "format": "label", "required": "optional"}, "ceagent": {"name": "ce", "display_name": "Contrast Enhancing Agent", "description": "<p>The <code>ce-&lt;label&gt;</code> entity can be used to distinguish sequences using different contrast enhanced images.\nThe label is the name of the contrast agent.</p>\n<p>This entity represents the <code>\"ContrastBolusIngredient\"</code> metadata field.\nTherefore, if the <code>ce-&lt;label&gt;</code> entity is present in a filename,\n<code>\"ContrastBolusIngredient\"</code> MAY also be added in the JSON file, with the same label.</p>", "type": "string", "format": "label", "required": "optional"}, "reconstruction": {"name": "rec", "display_name": "Reconstruction", "description": "<p>The <code>rec-&lt;label&gt;</code> entity can be used to distinguish different reconstruction algorithms\n(for example, <code>MoCo</code> for the ones using motion correction).</p>", "type": "string", "format": "label", "required": "optional"}, "direction": {"name": "dir", "display_name": "Phase-Encoding Direction", "description": "<p>The <code>dir-&lt;label&gt;</code> entity can be set to an arbitrary alphanumeric label\n(for example, <code>dir-LR</code> or <code>dir-AP</code>)\nto distinguish different phase-encoding directions.</p>\n<p>This entity represents the <code>\"PhaseEncodingDirection\"</code> metadata field.\nTherefore, if the <code>dir-&lt;label&gt;</code> entity is present in a filename,\n<code>\"PhaseEncodingDirection\"</code> MUST be defined in the associated metadata.\nPlease note that the <code>&lt;label&gt;</code> does not need to match the actual value of the field.</p>", "type": "string", "format": "label", "required": "optional"}, "run": {"name": "run", "display_name": "Run", "description": "<p>The <code>run-&lt;index&gt;</code> entity is used to distinguish separate data acquisitions with the same acquisition parameters\nand (other) entities.</p>\n<p>If several data acquisitions (for example, MRI scans or EEG recordings)\nwith the same acquisition parameters are acquired in the same session,\nthey MUST be indexed with the <a href=\"SPEC_ROOT/appendices/entities.md#run\"><code>run-&lt;index&gt;</code></a> entity:\n<code>_run-1</code>, <code>_run-2</code>, <code>_run-3</code>, and so on\n(only nonnegative integers are allowed as run indices).</p>\n<p>If different entities apply,\nsuch as a different session indicated by [<code>ses-&lt;label&gt;</code>][SPEC_ROOT/appendices/entities.md#ses),\nor different acquisition parameters indicated by\n<a href=\"SPEC_ROOT/appendices/entities.md#acq\"><code>acq-&lt;label&gt;</code></a>,\nthen <code>run</code> is not needed to distinguish the scans and MAY be omitted.</p>", "type": "string", "format": "index", "required": "optional"}, "echo": {"name": "echo", "display_name": "Echo", "description": "<p>If files belonging to an entity-linked file collection are acquired at different\necho times, the <code>echo-&lt;index&gt;</code> entity MUST be used to distinguish individual files.</p>\n<p>This entity represents the <code>\"EchoTime\"</code> metadata field.\nTherefore, if the <code>echo-&lt;index&gt;</code> entity is present in a filename,\n<code>\"EchoTime\"</code> MUST be defined in the associated metadata.\nPlease note that the <code>&lt;index&gt;</code> denotes the number/index (in the form of a nonnegative integer),\nnot the <code>\"EchoTime\"</code> value of the separate JSON file.</p>", "type": "string", "format": "index", "required": "optional"}, "part": {"name": "part", "display_name": "Part", "description": "<p>This entity is used to indicate which component of the complex\nrepresentation of the MRI signal is represented in voxel data.\nThe <code>part-&lt;label&gt;</code> entity is associated with the DICOM Tag\n<code>0008, 9208</code>.\nAllowed label values for this entity are <code>phase</code>, <code>mag</code>, <code>real</code> and <code>imag</code>,\nwhich are typically used in <code>part-mag</code>/<code>part-phase</code> or\n<code>part-real</code>/<code>part-imag</code> pairs of files.</p>\n<p>Phase images MAY be in radians or in arbitrary units.\nThe sidecar JSON file MUST include the <code>\"Units\"</code> of the <code>phase</code> image.\nThe possible options are <code>\"rad\"</code> or <code>\"arbitrary\"</code>.</p>\n<p>When there is only a magnitude image of a given type, the <code>part</code> entity MAY be\nomitted.</p>", "type": "string", "format": "label", "enum": ["mag", "phase", "real", "imag"], "required": "optional"}, "chunk": {"name": "chunk", "display_name": "Chunk", "description": "<p>The <code>chunk-&lt;index&gt;</code> key/value pair is used to distinguish between images of\nthe same physical sample with different fields of view acquired in the same\nimaging experiment.\nThis entity applies to collections of 2D images, 3D volumes or 4D volume series\n(for example, diffusion weighted images), and may be used to indicate different\nanatomical structures or regions of the same structure.</p>", "type": "string", "format": "index", "required": "optional"}}, "value": "bold", "display_name": "Blood-Oxygen-Level Dependent image", "description": "<p>Blood-Oxygen-Level Dependent contrast (specialized T2* weighting)</p>\n<br><code>func</code>"}, {"entities": {"subject": {"name": "sub", "display_name": "Subject", "description": "<p>A person or animal participating in the study.</p>", "type": "string", "format": "label", "required": "required"}, "session": {"name": "ses", "display_name": "Session", "description": "<p>A logical grouping of neuroimaging and behavioral data consistent across subjects.\nSession can (but doesn't have to) be synonymous to a visit in a longitudinal study.\nIn general, subjects will stay in the scanner during one session.\nHowever, for example, if a subject has to leave the scanner room and then\nbe re-positioned on the scanner bed, the set of MRI acquisitions will still\nbe considered as a session and match sessions acquired in other subjects.\nSimilarly, in situations where different data types are obtained over\nseveral visits (for example fMRI on one day followed by DWI the day after)\nthose can be grouped in one session.</p>\n<p>Defining multiple sessions is appropriate when several identical or similar\ndata acquisitions are planned and performed on all -or most- subjects,\noften in the case of some intervention between sessions\n(for example, training).</p>", "type": "string", "format": "label", "required": "optional"}, "task": {"name": "task", "display_name": "Task", "description": "<p>A set of structured activities performed by the participant.\nTasks are usually accompanied by stimuli and responses, and can greatly vary in complexity.</p>\n<p>In the context of brain scanning, a task is always tied to one data acquisition.\nTherefore, even if during one acquisition the subject performed multiple conceptually different behaviors\n(with different sets of instructions) they will be considered one (combined) task.</p>\n<p>While tasks may be repeated across multiple acquisitions,\na given task may have different sets of stimuli (for example, randomized order) and participant responses\nacross subjects, sessions, and runs.</p>\n<p>The <code>task-&lt;label&gt;</code> MUST be consistent across subjects and sessions.</p>\n<p>Files with the <code>task-&lt;label&gt;</code> entity SHOULD have an associated\n<a href=\"SPEC_ROOT/modality-specific-files/task-events.md#task-events\">events file</a>,\nas well as certain metadata fields in the associated JSON file.</p>\n<p>For the purpose of this specification we consider the so-called \"resting state\" a task,\nalthough events files are not expected for resting state data.\nAdditionally, a common convention in the specification is to include the word \"rest\" in\nthe <code>task</code> label for resting state files (for example, <code>task-rest</code>).</p>", "type": "string", "format": "label", "required": "required"}, "acquisition": {"name": "acq", "display_name": "Acquisition", "description": "<p>The <code>acq-&lt;label&gt;</code> entity corresponds to a custom label the user MAY use to distinguish\na different set of parameters used for acquiring the same modality.</p>\n<p>For example, this should be used when a study includes two T1w images -\none full brain low resolution and one restricted field of view but high resolution.\nIn such case two files could have the following names:\n<code>sub-01_acq-highres_T1w.nii.gz</code> and <code>sub-01_acq-lowres_T1w.nii.gz</code>;\nhowever, the user is free to choose any other label than <code>highres</code> and <code>lowres</code> as long\nas they are consistent across subjects and sessions.</p>\n<p>In case different sequences are used to record the same modality\n(for example, <code>RARE</code> and <code>FLASH</code> for T1w)\nthis field can also be used to make that distinction.\nThe level of detail at which the distinction is made\n(for example, just between <code>RARE</code> and <code>FLASH</code>, or between <code>RARE</code>, <code>FLASH</code>, and <code>FLASHsubsampled</code>)\nremains at the discretion of the researcher.</p>", "type": "string", "format": "label", "required": "optional"}, "ceagent": {"name": "ce", "display_name": "Contrast Enhancing Agent", "description": "<p>The <code>ce-&lt;label&gt;</code> entity can be used to distinguish sequences using different contrast enhanced images.\nThe label is the name of the contrast agent.</p>\n<p>This entity represents the <code>\"ContrastBolusIngredient\"</code> metadata field.\nTherefore, if the <code>ce-&lt;label&gt;</code> entity is present in a filename,\n<code>\"ContrastBolusIngredient\"</code> MAY also be added in the JSON file, with the same label.</p>", "type": "string", "format": "label", "required": "optional"}, "reconstruction": {"name": "rec", "display_name": "Reconstruction", "description": "<p>The <code>rec-&lt;label&gt;</code> entity can be used to distinguish different reconstruction algorithms\n(for example, <code>MoCo</code> for the ones using motion correction).</p>", "type": "string", "format": "label", "required": "optional"}, "direction": {"name": "dir", "display_name": "Phase-Encoding Direction", "description": "<p>The <code>dir-&lt;label&gt;</code> entity can be set to an arbitrary alphanumeric label\n(for example, <code>dir-LR</code> or <code>dir-AP</code>)\nto distinguish different phase-encoding directions.</p>\n<p>This entity represents the <code>\"PhaseEncodingDirection\"</code> metadata field.\nTherefore, if the <code>dir-&lt;label&gt;</code> entity is present in a filename,\n<code>\"PhaseEncodingDirection\"</code> MUST be defined in the associated metadata.\nPlease note that the <code>&lt;label&gt;</code> does not need to match the actual value of the field.</p>", "type": "string", "format": "label", "required": "optional"}, "run": {"name": "run", "display_name": "Run", "description": "<p>The <code>run-&lt;index&gt;</code> entity is used to distinguish separate data acquisitions with the same acquisition parameters\nand (other) entities.</p>\n<p>If several data acquisitions (for example, MRI scans or EEG recordings)\nwith the same acquisition parameters are acquired in the same session,\nthey MUST be indexed with the <a href=\"SPEC_ROOT/appendices/entities.md#run\"><code>run-&lt;index&gt;</code></a> entity:\n<code>_run-1</code>, <code>_run-2</code>, <code>_run-3</code>, and so on\n(only nonnegative integers are allowed as run indices).</p>\n<p>If different entities apply,\nsuch as a different session indicated by [<code>ses-&lt;label&gt;</code>][SPEC_ROOT/appendices/entities.md#ses),\nor different acquisition parameters indicated by\n<a href=\"SPEC_ROOT/appendices/entities.md#acq\"><code>acq-&lt;label&gt;</code></a>,\nthen <code>run</code> is not needed to distinguish the scans and MAY be omitted.</p>", "type": "string", "format": "index", "required": "optional"}, "echo": {"name": "echo", "display_name": "Echo", "description": "<p>If files belonging to an entity-linked file collection are acquired at different\necho times, the <code>echo-&lt;index&gt;</code> entity MUST be used to distinguish individual files.</p>\n<p>This entity represents the <code>\"EchoTime\"</code> metadata field.\nTherefore, if the <code>echo-&lt;index&gt;</code> entity is present in a filename,\n<code>\"EchoTime\"</code> MUST be defined in the associated metadata.\nPlease note that the <code>&lt;index&gt;</code> denotes the number/index (in the form of a nonnegative integer),\nnot the <code>\"EchoTime\"</code> value of the separate JSON file.</p>", "type": "string", "format": "index", "required": "optional"}, "part": {"name": "part", "display_name": "Part", "description": "<p>This entity is used to indicate which component of the complex\nrepresentation of the MRI signal is represented in voxel data.\nThe <code>part-&lt;label&gt;</code> entity is associated with the DICOM Tag\n<code>0008, 9208</code>.\nAllowed label values for this entity are <code>phase</code>, <code>mag</code>, <code>real</code> and <code>imag</code>,\nwhich are typically used in <code>part-mag</code>/<code>part-phase</code> or\n<code>part-real</code>/<code>part-imag</code> pairs of files.</p>\n<p>Phase images MAY be in radians or in arbitrary units.\nThe sidecar JSON file MUST include the <code>\"Units\"</code> of the <code>phase</code> image.\nThe possible options are <code>\"rad\"</code> or <code>\"arbitrary\"</code>.</p>\n<p>When there is only a magnitude image of a given type, the <code>part</code> entity MAY be\nomitted.</p>", "type": "string", "format": "label", "enum": ["mag", "phase", "real", "imag"], "required": "optional"}, "chunk": {"name": "chunk", "display_name": "Chunk", "description": "<p>The <code>chunk-&lt;index&gt;</code> key/value pair is used to distinguish between images of\nthe same physical sample with different fields of view acquired in the same\nimaging experiment.\nThis entity applies to collections of 2D images, 3D volumes or 4D volume series\n(for example, diffusion weighted images), and may be used to indicate different\nanatomical structures or regions of the same structure.</p>", "type": "string", "format": "index", "required": "optional"}}, "value": "cbv", "display_name": "Cerebral blood volume image", "description": "<p>Cerebral Blood Volume contrast (specialized T2* weighting or difference between T1 weighted images)</p>\n<br><code>func</code>"}, {"entities": {"subject": {"name": "sub", "display_name": "Subject", "description": "<p>A person or animal participating in the study.</p>", "type": "string", "format": "label", "required": "required"}, "session": {"name": "ses", "display_name": "Session", "description": "<p>A logical grouping of neuroimaging and behavioral data consistent across subjects.\nSession can (but doesn't have to) be synonymous to a visit in a longitudinal study.\nIn general, subjects will stay in the scanner during one session.\nHowever, for example, if a subject has to leave the scanner room and then\nbe re-positioned on the scanner bed, the set of MRI acquisitions will still\nbe considered as a session and match sessions acquired in other subjects.\nSimilarly, in situations where different data types are obtained over\nseveral visits (for example fMRI on one day followed by DWI the day after)\nthose can be grouped in one session.</p>\n<p>Defining multiple sessions is appropriate when several identical or similar\ndata acquisitions are planned and performed on all -or most- subjects,\noften in the case of some intervention between sessions\n(for example, training).</p>", "type": "string", "format": "label", "required": "optional"}, "task": {"name": "task", "display_name": "Task", "description": "<p>A set of structured activities performed by the participant.\nTasks are usually accompanied by stimuli and responses, and can greatly vary in complexity.</p>\n<p>In the context of brain scanning, a task is always tied to one data acquisition.\nTherefore, even if during one acquisition the subject performed multiple conceptually different behaviors\n(with different sets of instructions) they will be considered one (combined) task.</p>\n<p>While tasks may be repeated across multiple acquisitions,\na given task may have different sets of stimuli (for example, randomized order) and participant responses\nacross subjects, sessions, and runs.</p>\n<p>The <code>task-&lt;label&gt;</code> MUST be consistent across subjects and sessions.</p>\n<p>Files with the <code>task-&lt;label&gt;</code> entity SHOULD have an associated\n<a href=\"SPEC_ROOT/modality-specific-files/task-events.md#task-events\">events file</a>,\nas well as certain metadata fields in the associated JSON file.</p>\n<p>For the purpose of this specification we consider the so-called \"resting state\" a task,\nalthough events files are not expected for resting state data.\nAdditionally, a common convention in the specification is to include the word \"rest\" in\nthe <code>task</code> label for resting state files (for example, <code>task-rest</code>).</p>", "type": "string", "format": "label", "required": "required"}, "acquisition": {"name": "acq", "display_name": "Acquisition", "description": "<p>The <code>acq-&lt;label&gt;</code> entity corresponds to a custom label the user MAY use to distinguish\na different set of parameters used for acquiring the same modality.</p>\n<p>For example, this should be used when a study includes two T1w images -\none full brain low resolution and one restricted field of view but high resolution.\nIn such case two files could have the following names:\n<code>sub-01_acq-highres_T1w.nii.gz</code> and <code>sub-01_acq-lowres_T1w.nii.gz</code>;\nhowever, the user is free to choose any other label than <code>highres</code> and <code>lowres</code> as long\nas they are consistent across subjects and sessions.</p>\n<p>In case different sequences are used to record the same modality\n(for example, <code>RARE</code> and <code>FLASH</code> for T1w)\nthis field can also be used to make that distinction.\nThe level of detail at which the distinction is made\n(for example, just between <code>RARE</code> and <code>FLASH</code>, or between <code>RARE</code>, <code>FLASH</code>, and <code>FLASHsubsampled</code>)\nremains at the discretion of the researcher.</p>", "type": "string", "format": "label", "required": "optional"}, "ceagent": {"name": "ce", "display_name": "Contrast Enhancing Agent", "description": "<p>The <code>ce-&lt;label&gt;</code> entity can be used to distinguish sequences using different contrast enhanced images.\nThe label is the name of the contrast agent.</p>\n<p>This entity represents the <code>\"ContrastBolusIngredient\"</code> metadata field.\nTherefore, if the <code>ce-&lt;label&gt;</code> entity is present in a filename,\n<code>\"ContrastBolusIngredient\"</code> MAY also be added in the JSON file, with the same label.</p>", "type": "string", "format": "label", "required": "optional"}, "reconstruction": {"name": "rec", "display_name": "Reconstruction", "description": "<p>The <code>rec-&lt;label&gt;</code> entity can be used to distinguish different reconstruction algorithms\n(for example, <code>MoCo</code> for the ones using motion correction).</p>", "type": "string", "format": "label", "required": "optional"}, "direction": {"name": "dir", "display_name": "Phase-Encoding Direction", "description": "<p>The <code>dir-&lt;label&gt;</code> entity can be set to an arbitrary alphanumeric label\n(for example, <code>dir-LR</code> or <code>dir-AP</code>)\nto distinguish different phase-encoding directions.</p>\n<p>This entity represents the <code>\"PhaseEncodingDirection\"</code> metadata field.\nTherefore, if the <code>dir-&lt;label&gt;</code> entity is present in a filename,\n<code>\"PhaseEncodingDirection\"</code> MUST be defined in the associated metadata.\nPlease note that the <code>&lt;label&gt;</code> does not need to match the actual value of the field.</p>", "type": "string", "format": "label", "required": "optional"}, "run": {"name": "run", "display_name": "Run", "description": "<p>The <code>run-&lt;index&gt;</code> entity is used to distinguish separate data acquisitions with the same acquisition parameters\nand (other) entities.</p>\n<p>If several data acquisitions (for example, MRI scans or EEG recordings)\nwith the same acquisition parameters are acquired in the same session,\nthey MUST be indexed with the <a href=\"SPEC_ROOT/appendices/entities.md#run\"><code>run-&lt;index&gt;</code></a> entity:\n<code>_run-1</code>, <code>_run-2</code>, <code>_run-3</code>, and so on\n(only nonnegative integers are allowed as run indices).</p>\n<p>If different entities apply,\nsuch as a different session indicated by [<code>ses-&lt;label&gt;</code>][SPEC_ROOT/appendices/entities.md#ses),\nor different acquisition parameters indicated by\n<a href=\"SPEC_ROOT/appendices/entities.md#acq\"><code>acq-&lt;label&gt;</code></a>,\nthen <code>run</code> is not needed to distinguish the scans and MAY be omitted.</p>", "type": "string", "format": "index", "required": "optional"}, "echo": {"name": "echo", "display_name": "Echo", "description": "<p>If files belonging to an entity-linked file collection are acquired at different\necho times, the <code>echo-&lt;index&gt;</code> entity MUST be used to distinguish individual files.</p>\n<p>This entity represents the <code>\"EchoTime\"</code> metadata field.\nTherefore, if the <code>echo-&lt;index&gt;</code> entity is present in a filename,\n<code>\"EchoTime\"</code> MUST be defined in the associated metadata.\nPlease note that the <code>&lt;index&gt;</code> denotes the number/index (in the form of a nonnegative integer),\nnot the <code>\"EchoTime\"</code> value of the separate JSON file.</p>", "type": "string", "format": "index", "required": "optional"}, "part": {"name": "part", "display_name": "Part", "description": "<p>This entity is used to indicate which component of the complex\nrepresentation of the MRI signal is represented in voxel data.\nThe <code>part-&lt;label&gt;</code> entity is associated with the DICOM Tag\n<code>0008, 9208</code>.\nAllowed label values for this entity are <code>phase</code>, <code>mag</code>, <code>real</code> and <code>imag</code>,\nwhich are typically used in <code>part-mag</code>/<code>part-phase</code> or\n<code>part-real</code>/<code>part-imag</code> pairs of files.</p>\n<p>Phase images MAY be in radians or in arbitrary units.\nThe sidecar JSON file MUST include the <code>\"Units\"</code> of the <code>phase</code> image.\nThe possible options are <code>\"rad\"</code> or <code>\"arbitrary\"</code>.</p>\n<p>When there is only a magnitude image of a given type, the <code>part</code> entity MAY be\nomitted.</p>", "type": "string", "format": "label", "enum": ["mag", "phase", "real", "imag"], "required": "optional"}, "chunk": {"name": "chunk", "display_name": "Chunk", "description": "<p>The <code>chunk-&lt;index&gt;</code> key/value pair is used to distinguish between images of\nthe same physical sample with different fields of view acquired in the same\nimaging experiment.\nThis entity applies to collections of 2D images, 3D volumes or 4D volume series\n(for example, diffusion weighted images), and may be used to indicate different\nanatomical structures or regions of the same structure.</p>", "type": "string", "format": "index", "required": "optional"}}, "value": "sbref", "display_name": "Single-band reference image", "description": "<p>Single-band reference for one or more multi-band <code>dwi</code> images.</p>\n<br><code>func</code>"}, {"entities": {"modality": {"name": "mod", "display_name": "Corresponding Modality", "description": "<p>The <code>mod-&lt;label&gt;</code> entity corresponds to modality label for defacing\nmasks, for example, T1w, inplaneT1, referenced by a defacemask image.\nFor example, <code>sub-01_mod-T1w_defacemask.nii.gz</code>.</p>", "type": "string", "format": "label", "required": "optional"}, "subject": {"name": "sub", "display_name": "Subject", "description": "<p>A person or animal participating in the study.</p>", "type": "string", "format": "label", "required": "required"}, "session": {"name": "ses", "display_name": "Session", "description": "<p>A logical grouping of neuroimaging and behavioral data consistent across subjects.\nSession can (but doesn't have to) be synonymous to a visit in a longitudinal study.\nIn general, subjects will stay in the scanner during one session.\nHowever, for example, if a subject has to leave the scanner room and then\nbe re-positioned on the scanner bed, the set of MRI acquisitions will still\nbe considered as a session and match sessions acquired in other subjects.\nSimilarly, in situations where different data types are obtained over\nseveral visits (for example fMRI on one day followed by DWI the day after)\nthose can be grouped in one session.</p>\n<p>Defining multiple sessions is appropriate when several identical or similar\ndata acquisitions are planned and performed on all -or most- subjects,\noften in the case of some intervention between sessions\n(for example, training).</p>", "type": "string", "format": "label", "required": "optional"}, "task": {"name": "task", "display_name": "Task", "description": "<p>A set of structured activities performed by the participant.\nTasks are usually accompanied by stimuli and responses, and can greatly vary in complexity.</p>\n<p>In the context of brain scanning, a task is always tied to one data acquisition.\nTherefore, even if during one acquisition the subject performed multiple conceptually different behaviors\n(with different sets of instructions) they will be considered one (combined) task.</p>\n<p>While tasks may be repeated across multiple acquisitions,\na given task may have different sets of stimuli (for example, randomized order) and participant responses\nacross subjects, sessions, and runs.</p>\n<p>The <code>task-&lt;label&gt;</code> MUST be consistent across subjects and sessions.</p>\n<p>Files with the <code>task-&lt;label&gt;</code> entity SHOULD have an associated\n<a href=\"SPEC_ROOT/modality-specific-files/task-events.md#task-events\">events file</a>,\nas well as certain metadata fields in the associated JSON file.</p>\n<p>For the purpose of this specification we consider the so-called \"resting state\" a task,\nalthough events files are not expected for resting state data.\nAdditionally, a common convention in the specification is to include the word \"rest\" in\nthe <code>task</code> label for resting state files (for example, <code>task-rest</code>).</p>", "type": "string", "format": "label", "required": "required"}, "acquisition": {"name": "acq", "display_name": "Acquisition", "description": "<p>The <code>acq-&lt;label&gt;</code> entity corresponds to a custom label the user MAY use to distinguish\na different set of parameters used for acquiring the same modality.</p>\n<p>For example, this should be used when a study includes two T1w images -\none full brain low resolution and one restricted field of view but high resolution.\nIn such case two files could have the following names:\n<code>sub-01_acq-highres_T1w.nii.gz</code> and <code>sub-01_acq-lowres_T1w.nii.gz</code>;\nhowever, the user is free to choose any other label than <code>highres</code> and <code>lowres</code> as long\nas they are consistent across subjects and sessions.</p>\n<p>In case different sequences are used to record the same modality\n(for example, <code>RARE</code> and <code>FLASH</code> for T1w)\nthis field can also be used to make that distinction.\nThe level of detail at which the distinction is made\n(for example, just between <code>RARE</code> and <code>FLASH</code>, or between <code>RARE</code>, <code>FLASH</code>, and <code>FLASHsubsampled</code>)\nremains at the discretion of the researcher.</p>", "type": "string", "format": "label", "required": "optional"}, "ceagent": {"name": "ce", "display_name": "Contrast Enhancing Agent", "description": "<p>The <code>ce-&lt;label&gt;</code> entity can be used to distinguish sequences using different contrast enhanced images.\nThe label is the name of the contrast agent.</p>\n<p>This entity represents the <code>\"ContrastBolusIngredient\"</code> metadata field.\nTherefore, if the <code>ce-&lt;label&gt;</code> entity is present in a filename,\n<code>\"ContrastBolusIngredient\"</code> MAY also be added in the JSON file, with the same label.</p>", "type": "string", "format": "label", "required": "optional"}, "reconstruction": {"name": "rec", "display_name": "Reconstruction", "description": "<p>The <code>rec-&lt;label&gt;</code> entity can be used to distinguish different reconstruction algorithms\n(for example, <code>MoCo</code> for the ones using motion correction).</p>", "type": "string", "format": "label", "required": "optional"}, "direction": {"name": "dir", "display_name": "Phase-Encoding Direction", "description": "<p>The <code>dir-&lt;label&gt;</code> entity can be set to an arbitrary alphanumeric label\n(for example, <code>dir-LR</code> or <code>dir-AP</code>)\nto distinguish different phase-encoding directions.</p>\n<p>This entity represents the <code>\"PhaseEncodingDirection\"</code> metadata field.\nTherefore, if the <code>dir-&lt;label&gt;</code> entity is present in a filename,\n<code>\"PhaseEncodingDirection\"</code> MUST be defined in the associated metadata.\nPlease note that the <code>&lt;label&gt;</code> does not need to match the actual value of the field.</p>", "type": "string", "format": "label", "required": "optional"}, "run": {"name": "run", "display_name": "Run", "description": "<p>The <code>run-&lt;index&gt;</code> entity is used to distinguish separate data acquisitions with the same acquisition parameters\nand (other) entities.</p>\n<p>If several data acquisitions (for example, MRI scans or EEG recordings)\nwith the same acquisition parameters are acquired in the same session,\nthey MUST be indexed with the <a href=\"SPEC_ROOT/appendices/entities.md#run\"><code>run-&lt;index&gt;</code></a> entity:\n<code>_run-1</code>, <code>_run-2</code>, <code>_run-3</code>, and so on\n(only nonnegative integers are allowed as run indices).</p>\n<p>If different entities apply,\nsuch as a different session indicated by [<code>ses-&lt;label&gt;</code>][SPEC_ROOT/appendices/entities.md#ses),\nor different acquisition parameters indicated by\n<a href=\"SPEC_ROOT/appendices/entities.md#acq\"><code>acq-&lt;label&gt;</code></a>,\nthen <code>run</code> is not needed to distinguish the scans and MAY be omitted.</p>", "type": "string", "format": "index", "required": "optional"}, "echo": {"name": "echo", "display_name": "Echo", "description": "<p>If files belonging to an entity-linked file collection are acquired at different\necho times, the <code>echo-&lt;index&gt;</code> entity MUST be used to distinguish individual files.</p>\n<p>This entity represents the <code>\"EchoTime\"</code> metadata field.\nTherefore, if the <code>echo-&lt;index&gt;</code> entity is present in a filename,\n<code>\"EchoTime\"</code> MUST be defined in the associated metadata.\nPlease note that the <code>&lt;index&gt;</code> denotes the number/index (in the form of a nonnegative integer),\nnot the <code>\"EchoTime\"</code> value of the separate JSON file.</p>", "type": "string", "format": "index", "required": "optional"}, "part": {"name": "part", "display_name": "Part", "description": "<p>This entity is used to indicate which component of the complex\nrepresentation of the MRI signal is represented in voxel data.\nThe <code>part-&lt;label&gt;</code> entity is associated with the DICOM Tag\n<code>0008, 9208</code>.\nAllowed label values for this entity are <code>phase</code>, <code>mag</code>, <code>real</code> and <code>imag</code>,\nwhich are typically used in <code>part-mag</code>/<code>part-phase</code> or\n<code>part-real</code>/<code>part-imag</code> pairs of files.</p>\n<p>Phase images MAY be in radians or in arbitrary units.\nThe sidecar JSON file MUST include the <code>\"Units\"</code> of the <code>phase</code> image.\nThe possible options are <code>\"rad\"</code> or <code>\"arbitrary\"</code>.</p>\n<p>When there is only a magnitude image of a given type, the <code>part</code> entity MAY be\nomitted.</p>", "type": "string", "format": "label", "enum": ["mag", "phase", "real", "imag"], "required": "optional"}, "chunk": {"name": "chunk", "display_name": "Chunk", "description": "<p>The <code>chunk-&lt;index&gt;</code> key/value pair is used to distinguish between images of\nthe same physical sample with different fields of view acquired in the same\nimaging experiment.\nThis entity applies to collections of 2D images, 3D volumes or 4D volume series\n(for example, diffusion weighted images), and may be used to indicate different\nanatomical structures or regions of the same structure.</p>", "type": "string", "format": "index", "required": "optional"}}, "value": "noRF", "display_name": "No Radio Frequency Excitation Scan", "description": "<p>An MR noise scan often acquired alongside another MR scan.</p>\n<p>These noise scans are acquired by disabling the radio frequency excitation,\nwhile maintaining all other parameters from the associated scan.\nThese can be acquired using some other sequence with RF excitation removed\nor as part of sequences that turns off RF at the beginning or end of a run.\nFor example a <code>bold</code> scan where a few volumes are acquired with RF off.\nThere is no consistent DICOM denotation for these scans.</p>\n<p>If multiple sequences with different suffixes but otherwise the same entities have <code>noRF</code>\nsequences, they SHOULD be disambiguated using the modality entity\n(for example, <code>mod-bold_noRF.nii.gz</code> and <code>mod-cbv_noRF.nii</code>).</p>\n<p><code>noRF</code> are typically used to estimate properties of the scanner and\nsequence that are independent from the object being imaged.</p>\n<br><code>norf</code>"}, {"entities": {"subject": {"name": "sub", "display_name": "Subject", "description": "<p>A person or animal participating in the study.</p>", "type": "string", "format": "label", "required": "required"}, "session": {"name": "ses", "display_name": "Session", "description": "<p>A logical grouping of neuroimaging and behavioral data consistent across subjects.\nSession can (but doesn't have to) be synonymous to a visit in a longitudinal study.\nIn general, subjects will stay in the scanner during one session.\nHowever, for example, if a subject has to leave the scanner room and then\nbe re-positioned on the scanner bed, the set of MRI acquisitions will still\nbe considered as a session and match sessions acquired in other subjects.\nSimilarly, in situations where different data types are obtained over\nseveral visits (for example fMRI on one day followed by DWI the day after)\nthose can be grouped in one session.</p>\n<p>Defining multiple sessions is appropriate when several identical or similar\ndata acquisitions are planned and performed on all -or most- subjects,\noften in the case of some intervention between sessions\n(for example, training).</p>", "type": "string", "format": "label", "required": "optional"}, "task": {"name": "task", "display_name": "Task", "description": "<p>A set of structured activities performed by the participant.\nTasks are usually accompanied by stimuli and responses, and can greatly vary in complexity.</p>\n<p>In the context of brain scanning, a task is always tied to one data acquisition.\nTherefore, even if during one acquisition the subject performed multiple conceptually different behaviors\n(with different sets of instructions) they will be considered one (combined) task.</p>\n<p>While tasks may be repeated across multiple acquisitions,\na given task may have different sets of stimuli (for example, randomized order) and participant responses\nacross subjects, sessions, and runs.</p>\n<p>The <code>task-&lt;label&gt;</code> MUST be consistent across subjects and sessions.</p>\n<p>Files with the <code>task-&lt;label&gt;</code> entity SHOULD have an associated\n<a href=\"SPEC_ROOT/modality-specific-files/task-events.md#task-events\">events file</a>,\nas well as certain metadata fields in the associated JSON file.</p>\n<p>For the purpose of this specification we consider the so-called \"resting state\" a task,\nalthough events files are not expected for resting state data.\nAdditionally, a common convention in the specification is to include the word \"rest\" in\nthe <code>task</code> label for resting state files (for example, <code>task-rest</code>).</p>", "type": "string", "format": "label", "required": "required"}, "acquisition": {"name": "acq", "display_name": "Acquisition", "description": "<p>The <code>acq-&lt;label&gt;</code> entity corresponds to a custom label the user MAY use to distinguish\na different set of parameters used for acquiring the same modality.</p>\n<p>For example, this should be used when a study includes two T1w images -\none full brain low resolution and one restricted field of view but high resolution.\nIn such case two files could have the following names:\n<code>sub-01_acq-highres_T1w.nii.gz</code> and <code>sub-01_acq-lowres_T1w.nii.gz</code>;\nhowever, the user is free to choose any other label than <code>highres</code> and <code>lowres</code> as long\nas they are consistent across subjects and sessions.</p>\n<p>In case different sequences are used to record the same modality\n(for example, <code>RARE</code> and <code>FLASH</code> for T1w)\nthis field can also be used to make that distinction.\nThe level of detail at which the distinction is made\n(for example, just between <code>RARE</code> and <code>FLASH</code>, or between <code>RARE</code>, <code>FLASH</code>, and <code>FLASHsubsampled</code>)\nremains at the discretion of the researcher.</p>", "type": "string", "format": "label", "required": "optional"}, "ceagent": {"name": "ce", "display_name": "Contrast Enhancing Agent", "description": "<p>The <code>ce-&lt;label&gt;</code> entity can be used to distinguish sequences using different contrast enhanced images.\nThe label is the name of the contrast agent.</p>\n<p>This entity represents the <code>\"ContrastBolusIngredient\"</code> metadata field.\nTherefore, if the <code>ce-&lt;label&gt;</code> entity is present in a filename,\n<code>\"ContrastBolusIngredient\"</code> MAY also be added in the JSON file, with the same label.</p>", "type": "string", "format": "label", "required": "optional"}, "reconstruction": {"name": "rec", "display_name": "Reconstruction", "description": "<p>The <code>rec-&lt;label&gt;</code> entity can be used to distinguish different reconstruction algorithms\n(for example, <code>MoCo</code> for the ones using motion correction).</p>", "type": "string", "format": "label", "required": "optional"}, "direction": {"name": "dir", "display_name": "Phase-Encoding Direction", "description": "<p>The <code>dir-&lt;label&gt;</code> entity can be set to an arbitrary alphanumeric label\n(for example, <code>dir-LR</code> or <code>dir-AP</code>)\nto distinguish different phase-encoding directions.</p>\n<p>This entity represents the <code>\"PhaseEncodingDirection\"</code> metadata field.\nTherefore, if the <code>dir-&lt;label&gt;</code> entity is present in a filename,\n<code>\"PhaseEncodingDirection\"</code> MUST be defined in the associated metadata.\nPlease note that the <code>&lt;label&gt;</code> does not need to match the actual value of the field.</p>", "type": "string", "format": "label", "required": "optional"}, "run": {"name": "run", "display_name": "Run", "description": "<p>The <code>run-&lt;index&gt;</code> entity is used to distinguish separate data acquisitions with the same acquisition parameters\nand (other) entities.</p>\n<p>If several data acquisitions (for example, MRI scans or EEG recordings)\nwith the same acquisition parameters are acquired in the same session,\nthey MUST be indexed with the <a href=\"SPEC_ROOT/appendices/entities.md#run\"><code>run-&lt;index&gt;</code></a> entity:\n<code>_run-1</code>, <code>_run-2</code>, <code>_run-3</code>, and so on\n(only nonnegative integers are allowed as run indices).</p>\n<p>If different entities apply,\nsuch as a different session indicated by [<code>ses-&lt;label&gt;</code>][SPEC_ROOT/appendices/entities.md#ses),\nor different acquisition parameters indicated by\n<a href=\"SPEC_ROOT/appendices/entities.md#acq\"><code>acq-&lt;label&gt;</code></a>,\nthen <code>run</code> is not needed to distinguish the scans and MAY be omitted.</p>", "type": "string", "format": "index", "required": "optional"}, "echo": {"name": "echo", "display_name": "Echo", "description": "<p>If files belonging to an entity-linked file collection are acquired at different\necho times, the <code>echo-&lt;index&gt;</code> entity MUST be used to distinguish individual files.</p>\n<p>This entity represents the <code>\"EchoTime\"</code> metadata field.\nTherefore, if the <code>echo-&lt;index&gt;</code> entity is present in a filename,\n<code>\"EchoTime\"</code> MUST be defined in the associated metadata.\nPlease note that the <code>&lt;index&gt;</code> denotes the number/index (in the form of a nonnegative integer),\nnot the <code>\"EchoTime\"</code> value of the separate JSON file.</p>", "type": "string", "format": "index", "required": "optional"}, "chunk": {"name": "chunk", "display_name": "Chunk", "description": "<p>The <code>chunk-&lt;index&gt;</code> key/value pair is used to distinguish between images of\nthe same physical sample with different fields of view acquired in the same\nimaging experiment.\nThis entity applies to collections of 2D images, 3D volumes or 4D volume series\n(for example, diffusion weighted images), and may be used to indicate different\nanatomical structures or regions of the same structure.</p>", "type": "string", "format": "index", "required": "optional"}}, "value": "phase", "display_name": "Phase image", "description": "<p><a href=\"SPEC_ROOT/common-principles.md#definitions\">DEPRECATED</a>.\nPhase information associated with magnitude information stored in BOLD\ncontrast.\nThis suffix should be replaced by the\n<a href=\"SPEC_ROOT/appendices/entities.md#part\"><code>part-phase</code></a>\nin conjunction with the <code>bold</code> suffix.</p>\n<br><code>phase</code>", "anyOf": [{"unit": "arbitrary"}, {"unit": "rad"}]}], "mrs": [{"entities": {"subject": {"name": "sub", "display_name": "Subject", "description": "<p>A person or animal participating in the study.</p>", "type": "string", "format": "label", "required": "required"}, "session": {"name": "ses", "display_name": "Session", "description": "<p>A logical grouping of neuroimaging and behavioral data consistent across subjects.\nSession can (but doesn't have to) be synonymous to a visit in a longitudinal study.\nIn general, subjects will stay in the scanner during one session.\nHowever, for example, if a subject has to leave the scanner room and then\nbe re-positioned on the scanner bed, the set of MRI acquisitions will still\nbe considered as a session and match sessions acquired in other subjects.\nSimilarly, in situations where different data types are obtained over\nseveral visits (for example fMRI on one day followed by DWI the day after)\nthose can be grouped in one session.</p>\n<p>Defining multiple sessions is appropriate when several identical or similar\ndata acquisitions are planned and performed on all -or most- subjects,\noften in the case of some intervention between sessions\n(for example, training).</p>", "type": "string", "format": "label", "required": "optional"}, "task": {"name": "task", "display_name": "Task", "description": "<p>A set of structured activities performed by the participant.\nTasks are usually accompanied by stimuli and responses, and can greatly vary in complexity.</p>\n<p>In the context of brain scanning, a task is always tied to one data acquisition.\nTherefore, even if during one acquisition the subject performed multiple conceptually different behaviors\n(with different sets of instructions) they will be considered one (combined) task.</p>\n<p>While tasks may be repeated across multiple acquisitions,\na given task may have different sets of stimuli (for example, randomized order) and participant responses\nacross subjects, sessions, and runs.</p>\n<p>The <code>task-&lt;label&gt;</code> MUST be consistent across subjects and sessions.</p>\n<p>Files with the <code>task-&lt;label&gt;</code> entity SHOULD have an associated\n<a href=\"SPEC_ROOT/modality-specific-files/task-events.md#task-events\">events file</a>,\nas well as certain metadata fields in the associated JSON file.</p>\n<p>For the purpose of this specification we consider the so-called \"resting state\" a task,\nalthough events files are not expected for resting state data.\nAdditionally, a common convention in the specification is to include the word \"rest\" in\nthe <code>task</code> label for resting state files (for example, <code>task-rest</code>).</p>", "type": "string", "format": "label", "required": "optional"}, "acquisition": {"name": "acq", "display_name": "Acquisition", "description": "<p>The <code>acq-&lt;label&gt;</code> entity corresponds to a custom label the user MAY use to distinguish\na different set of parameters used for acquiring the same modality.</p>\n<p>For example, this should be used when a study includes two T1w images -\none full brain low resolution and one restricted field of view but high resolution.\nIn such case two files could have the following names:\n<code>sub-01_acq-highres_T1w.nii.gz</code> and <code>sub-01_acq-lowres_T1w.nii.gz</code>;\nhowever, the user is free to choose any other label than <code>highres</code> and <code>lowres</code> as long\nas they are consistent across subjects and sessions.</p>\n<p>In case different sequences are used to record the same modality\n(for example, <code>RARE</code> and <code>FLASH</code> for T1w)\nthis field can also be used to make that distinction.\nThe level of detail at which the distinction is made\n(for example, just between <code>RARE</code> and <code>FLASH</code>, or between <code>RARE</code>, <code>FLASH</code>, and <code>FLASHsubsampled</code>)\nremains at the discretion of the researcher.</p>", "type": "string", "format": "label", "required": "optional"}, "reconstruction": {"name": "rec", "display_name": "Reconstruction", "description": "<p>The <code>rec-&lt;label&gt;</code> entity can be used to distinguish different reconstruction algorithms\n(for example, <code>MoCo</code> for the ones using motion correction).</p>", "type": "string", "format": "label", "required": "optional"}, "run": {"name": "run", "display_name": "Run", "description": "<p>The <code>run-&lt;index&gt;</code> entity is used to distinguish separate data acquisitions with the same acquisition parameters\nand (other) entities.</p>\n<p>If several data acquisitions (for example, MRI scans or EEG recordings)\nwith the same acquisition parameters are acquired in the same session,\nthey MUST be indexed with the <a href=\"SPEC_ROOT/appendices/entities.md#run\"><code>run-&lt;index&gt;</code></a> entity:\n<code>_run-1</code>, <code>_run-2</code>, <code>_run-3</code>, and so on\n(only nonnegative integers are allowed as run indices).</p>\n<p>If different entities apply,\nsuch as a different session indicated by [<code>ses-&lt;label&gt;</code>][SPEC_ROOT/appendices/entities.md#ses),\nor different acquisition parameters indicated by\n<a href=\"SPEC_ROOT/appendices/entities.md#acq\"><code>acq-&lt;label&gt;</code></a>,\nthen <code>run</code> is not needed to distinguish the scans and MAY be omitted.</p>", "type": "string", "format": "index", "required": "optional"}, "echo": {"name": "echo", "display_name": "Echo", "description": "<p>If files belonging to an entity-linked file collection are acquired at different\necho times, the <code>echo-&lt;index&gt;</code> entity MUST be used to distinguish individual files.</p>\n<p>This entity represents the <code>\"EchoTime\"</code> metadata field.\nTherefore, if the <code>echo-&lt;index&gt;</code> entity is present in a filename,\n<code>\"EchoTime\"</code> MUST be defined in the associated metadata.\nPlease note that the <code>&lt;index&gt;</code> denotes the number/index (in the form of a nonnegative integer),\nnot the <code>\"EchoTime\"</code> value of the separate JSON file.</p>", "type": "string", "format": "index", "required": "optional"}, "inversion": {"name": "inv", "display_name": "Inversion Time", "description": "<p>If files belonging to an entity-linked file collection are acquired at different inversion times,\nthe <code>inv-&lt;index&gt;</code> entity MUST be used to distinguish individual files.</p>\n<p>This entity represents the <code>\"InversionTime</code> metadata field.\nTherefore, if the <code>inv-&lt;index&gt;</code> entity is present in a filename,\n<code>\"InversionTime\"</code> MUST be defined in the associated metadata.\nPlease note that the <code>&lt;index&gt;</code> denotes the number/index (in the form of a nonnegative integer),\nnot the <code>\"InversionTime\"</code> value of the separate JSON file.</p>", "type": "string", "format": "index", "required": "optional"}, "nucleus": {"name": "nuc", "display_name": "Nucleus", "description": "<p>The <code>nuc-&lt;label&gt;</code> entity can be used to distinguish acquisitions tuned\nto detect different nuclei.\nThe label is the name of the nucleus or nuclei, which corresponds to DICOM Tag <code>0018, 9100</code>.\nIf present in the filename, <code>\"ResonantNucleus\"</code> MUST also be included in\nthe associated metadata.</p>", "type": "string", "format": "label", "required": "optional"}, "volume": {"name": "voi", "display_name": "Volume of Interest", "description": "<p>The <code>voi-&lt;label&gt;</code> entity can be used to distinguish acquisitions localized to different regions.\nThe label SHOULD be the name of the body region or part scanned.\nIf used, the fields <code>\"BodyPart\"</code> and <code>\"BodyPartDetails\"</code> MUST be defined in the JSON file.\n<code>BodyPartDetailsOntology</code> is OPTIONAL to also include.</p>", "type": "string", "format": "label", "required": "optional"}}, "value": "svs", "display_name": "Single-voxel spectroscopy", "description": "<p>MRS acquisitions where the detected MR signal is spatially localized to a single volume.</p>\n<br><code>mrs</code>"}, {"entities": {"subject": {"name": "sub", "display_name": "Subject", "description": "<p>A person or animal participating in the study.</p>", "type": "string", "format": "label", "required": "required"}, "session": {"name": "ses", "display_name": "Session", "description": "<p>A logical grouping of neuroimaging and behavioral data consistent across subjects.\nSession can (but doesn't have to) be synonymous to a visit in a longitudinal study.\nIn general, subjects will stay in the scanner during one session.\nHowever, for example, if a subject has to leave the scanner room and then\nbe re-positioned on the scanner bed, the set of MRI acquisitions will still\nbe considered as a session and match sessions acquired in other subjects.\nSimilarly, in situations where different data types are obtained over\nseveral visits (for example fMRI on one day followed by DWI the day after)\nthose can be grouped in one session.</p>\n<p>Defining multiple sessions is appropriate when several identical or similar\ndata acquisitions are planned and performed on all -or most- subjects,\noften in the case of some intervention between sessions\n(for example, training).</p>", "type": "string", "format": "label", "required": "optional"}, "task": {"name": "task", "display_name": "Task", "description": "<p>A set of structured activities performed by the participant.\nTasks are usually accompanied by stimuli and responses, and can greatly vary in complexity.</p>\n<p>In the context of brain scanning, a task is always tied to one data acquisition.\nTherefore, even if during one acquisition the subject performed multiple conceptually different behaviors\n(with different sets of instructions) they will be considered one (combined) task.</p>\n<p>While tasks may be repeated across multiple acquisitions,\na given task may have different sets of stimuli (for example, randomized order) and participant responses\nacross subjects, sessions, and runs.</p>\n<p>The <code>task-&lt;label&gt;</code> MUST be consistent across subjects and sessions.</p>\n<p>Files with the <code>task-&lt;label&gt;</code> entity SHOULD have an associated\n<a href=\"SPEC_ROOT/modality-specific-files/task-events.md#task-events\">events file</a>,\nas well as certain metadata fields in the associated JSON file.</p>\n<p>For the purpose of this specification we consider the so-called \"resting state\" a task,\nalthough events files are not expected for resting state data.\nAdditionally, a common convention in the specification is to include the word \"rest\" in\nthe <code>task</code> label for resting state files (for example, <code>task-rest</code>).</p>", "type": "string", "format": "label", "required": "optional"}, "acquisition": {"name": "acq", "display_name": "Acquisition", "description": "<p>The <code>acq-&lt;label&gt;</code> entity corresponds to a custom label the user MAY use to distinguish\na different set of parameters used for acquiring the same modality.</p>\n<p>For example, this should be used when a study includes two T1w images -\none full brain low resolution and one restricted field of view but high resolution.\nIn such case two files could have the following names:\n<code>sub-01_acq-highres_T1w.nii.gz</code> and <code>sub-01_acq-lowres_T1w.nii.gz</code>;\nhowever, the user is free to choose any other label than <code>highres</code> and <code>lowres</code> as long\nas they are consistent across subjects and sessions.</p>\n<p>In case different sequences are used to record the same modality\n(for example, <code>RARE</code> and <code>FLASH</code> for T1w)\nthis field can also be used to make that distinction.\nThe level of detail at which the distinction is made\n(for example, just between <code>RARE</code> and <code>FLASH</code>, or between <code>RARE</code>, <code>FLASH</code>, and <code>FLASHsubsampled</code>)\nremains at the discretion of the researcher.</p>", "type": "string", "format": "label", "required": "optional"}, "reconstruction": {"name": "rec", "display_name": "Reconstruction", "description": "<p>The <code>rec-&lt;label&gt;</code> entity can be used to distinguish different reconstruction algorithms\n(for example, <code>MoCo</code> for the ones using motion correction).</p>", "type": "string", "format": "label", "required": "optional"}, "run": {"name": "run", "display_name": "Run", "description": "<p>The <code>run-&lt;index&gt;</code> entity is used to distinguish separate data acquisitions with the same acquisition parameters\nand (other) entities.</p>\n<p>If several data acquisitions (for example, MRI scans or EEG recordings)\nwith the same acquisition parameters are acquired in the same session,\nthey MUST be indexed with the <a href=\"SPEC_ROOT/appendices/entities.md#run\"><code>run-&lt;index&gt;</code></a> entity:\n<code>_run-1</code>, <code>_run-2</code>, <code>_run-3</code>, and so on\n(only nonnegative integers are allowed as run indices).</p>\n<p>If different entities apply,\nsuch as a different session indicated by [<code>ses-&lt;label&gt;</code>][SPEC_ROOT/appendices/entities.md#ses),\nor different acquisition parameters indicated by\n<a href=\"SPEC_ROOT/appendices/entities.md#acq\"><code>acq-&lt;label&gt;</code></a>,\nthen <code>run</code> is not needed to distinguish the scans and MAY be omitted.</p>", "type": "string", "format": "index", "required": "optional"}, "echo": {"name": "echo", "display_name": "Echo", "description": "<p>If files belonging to an entity-linked file collection are acquired at different\necho times, the <code>echo-&lt;index&gt;</code> entity MUST be used to distinguish individual files.</p>\n<p>This entity represents the <code>\"EchoTime\"</code> metadata field.\nTherefore, if the <code>echo-&lt;index&gt;</code> entity is present in a filename,\n<code>\"EchoTime\"</code> MUST be defined in the associated metadata.\nPlease note that the <code>&lt;index&gt;</code> denotes the number/index (in the form of a nonnegative integer),\nnot the <code>\"EchoTime\"</code> value of the separate JSON file.</p>", "type": "string", "format": "index", "required": "optional"}, "inversion": {"name": "inv", "display_name": "Inversion Time", "description": "<p>If files belonging to an entity-linked file collection are acquired at different inversion times,\nthe <code>inv-&lt;index&gt;</code> entity MUST be used to distinguish individual files.</p>\n<p>This entity represents the <code>\"InversionTime</code> metadata field.\nTherefore, if the <code>inv-&lt;index&gt;</code> entity is present in a filename,\n<code>\"InversionTime\"</code> MUST be defined in the associated metadata.\nPlease note that the <code>&lt;index&gt;</code> denotes the number/index (in the form of a nonnegative integer),\nnot the <code>\"InversionTime\"</code> value of the separate JSON file.</p>", "type": "string", "format": "index", "required": "optional"}, "nucleus": {"name": "nuc", "display_name": "Nucleus", "description": "<p>The <code>nuc-&lt;label&gt;</code> entity can be used to distinguish acquisitions tuned\nto detect different nuclei.\nThe label is the name of the nucleus or nuclei, which corresponds to DICOM Tag <code>0018, 9100</code>.\nIf present in the filename, <code>\"ResonantNucleus\"</code> MUST also be included in\nthe associated metadata.</p>", "type": "string", "format": "label", "required": "optional"}, "volume": {"name": "voi", "display_name": "Volume of Interest", "description": "<p>The <code>voi-&lt;label&gt;</code> entity can be used to distinguish acquisitions localized to different regions.\nThe label SHOULD be the name of the body region or part scanned.\nIf used, the fields <code>\"BodyPart\"</code> and <code>\"BodyPartDetails\"</code> MUST be defined in the JSON file.\n<code>BodyPartDetailsOntology</code> is OPTIONAL to also include.</p>", "type": "string", "format": "label", "required": "optional"}}, "value": "mrsi", "display_name": "Magnetic resonance spectroscopy imaging", "description": "<p>MRS acquisitions where additional imaging gradients are used\nto detect the MR signal from 1, 2, or 3 spatial dimensions.</p>\n<br><code>mrs</code>"}, {"entities": {"subject": {"name": "sub", "display_name": "Subject", "description": "<p>A person or animal participating in the study.</p>", "type": "string", "format": "label", "required": "required"}, "session": {"name": "ses", "display_name": "Session", "description": "<p>A logical grouping of neuroimaging and behavioral data consistent across subjects.\nSession can (but doesn't have to) be synonymous to a visit in a longitudinal study.\nIn general, subjects will stay in the scanner during one session.\nHowever, for example, if a subject has to leave the scanner room and then\nbe re-positioned on the scanner bed, the set of MRI acquisitions will still\nbe considered as a session and match sessions acquired in other subjects.\nSimilarly, in situations where different data types are obtained over\nseveral visits (for example fMRI on one day followed by DWI the day after)\nthose can be grouped in one session.</p>\n<p>Defining multiple sessions is appropriate when several identical or similar\ndata acquisitions are planned and performed on all -or most- subjects,\noften in the case of some intervention between sessions\n(for example, training).</p>", "type": "string", "format": "label", "required": "optional"}, "task": {"name": "task", "display_name": "Task", "description": "<p>A set of structured activities performed by the participant.\nTasks are usually accompanied by stimuli and responses, and can greatly vary in complexity.</p>\n<p>In the context of brain scanning, a task is always tied to one data acquisition.\nTherefore, even if during one acquisition the subject performed multiple conceptually different behaviors\n(with different sets of instructions) they will be considered one (combined) task.</p>\n<p>While tasks may be repeated across multiple acquisitions,\na given task may have different sets of stimuli (for example, randomized order) and participant responses\nacross subjects, sessions, and runs.</p>\n<p>The <code>task-&lt;label&gt;</code> MUST be consistent across subjects and sessions.</p>\n<p>Files with the <code>task-&lt;label&gt;</code> entity SHOULD have an associated\n<a href=\"SPEC_ROOT/modality-specific-files/task-events.md#task-events\">events file</a>,\nas well as certain metadata fields in the associated JSON file.</p>\n<p>For the purpose of this specification we consider the so-called \"resting state\" a task,\nalthough events files are not expected for resting state data.\nAdditionally, a common convention in the specification is to include the word \"rest\" in\nthe <code>task</code> label for resting state files (for example, <code>task-rest</code>).</p>", "type": "string", "format": "label", "required": "optional"}, "acquisition": {"name": "acq", "display_name": "Acquisition", "description": "<p>The <code>acq-&lt;label&gt;</code> entity corresponds to a custom label the user MAY use to distinguish\na different set of parameters used for acquiring the same modality.</p>\n<p>For example, this should be used when a study includes two T1w images -\none full brain low resolution and one restricted field of view but high resolution.\nIn such case two files could have the following names:\n<code>sub-01_acq-highres_T1w.nii.gz</code> and <code>sub-01_acq-lowres_T1w.nii.gz</code>;\nhowever, the user is free to choose any other label than <code>highres</code> and <code>lowres</code> as long\nas they are consistent across subjects and sessions.</p>\n<p>In case different sequences are used to record the same modality\n(for example, <code>RARE</code> and <code>FLASH</code> for T1w)\nthis field can also be used to make that distinction.\nThe level of detail at which the distinction is made\n(for example, just between <code>RARE</code> and <code>FLASH</code>, or between <code>RARE</code>, <code>FLASH</code>, and <code>FLASHsubsampled</code>)\nremains at the discretion of the researcher.</p>", "type": "string", "format": "label", "required": "optional"}, "reconstruction": {"name": "rec", "display_name": "Reconstruction", "description": "<p>The <code>rec-&lt;label&gt;</code> entity can be used to distinguish different reconstruction algorithms\n(for example, <code>MoCo</code> for the ones using motion correction).</p>", "type": "string", "format": "label", "required": "optional"}, "run": {"name": "run", "display_name": "Run", "description": "<p>The <code>run-&lt;index&gt;</code> entity is used to distinguish separate data acquisitions with the same acquisition parameters\nand (other) entities.</p>\n<p>If several data acquisitions (for example, MRI scans or EEG recordings)\nwith the same acquisition parameters are acquired in the same session,\nthey MUST be indexed with the <a href=\"SPEC_ROOT/appendices/entities.md#run\"><code>run-&lt;index&gt;</code></a> entity:\n<code>_run-1</code>, <code>_run-2</code>, <code>_run-3</code>, and so on\n(only nonnegative integers are allowed as run indices).</p>\n<p>If different entities apply,\nsuch as a different session indicated by [<code>ses-&lt;label&gt;</code>][SPEC_ROOT/appendices/entities.md#ses),\nor different acquisition parameters indicated by\n<a href=\"SPEC_ROOT/appendices/entities.md#acq\"><code>acq-&lt;label&gt;</code></a>,\nthen <code>run</code> is not needed to distinguish the scans and MAY be omitted.</p>", "type": "string", "format": "index", "required": "optional"}, "echo": {"name": "echo", "display_name": "Echo", "description": "<p>If files belonging to an entity-linked file collection are acquired at different\necho times, the <code>echo-&lt;index&gt;</code> entity MUST be used to distinguish individual files.</p>\n<p>This entity represents the <code>\"EchoTime\"</code> metadata field.\nTherefore, if the <code>echo-&lt;index&gt;</code> entity is present in a filename,\n<code>\"EchoTime\"</code> MUST be defined in the associated metadata.\nPlease note that the <code>&lt;index&gt;</code> denotes the number/index (in the form of a nonnegative integer),\nnot the <code>\"EchoTime\"</code> value of the separate JSON file.</p>", "type": "string", "format": "index", "required": "optional"}, "inversion": {"name": "inv", "display_name": "Inversion Time", "description": "<p>If files belonging to an entity-linked file collection are acquired at different inversion times,\nthe <code>inv-&lt;index&gt;</code> entity MUST be used to distinguish individual files.</p>\n<p>This entity represents the <code>\"InversionTime</code> metadata field.\nTherefore, if the <code>inv-&lt;index&gt;</code> entity is present in a filename,\n<code>\"InversionTime\"</code> MUST be defined in the associated metadata.\nPlease note that the <code>&lt;index&gt;</code> denotes the number/index (in the form of a nonnegative integer),\nnot the <code>\"InversionTime\"</code> value of the separate JSON file.</p>", "type": "string", "format": "index", "required": "optional"}, "nucleus": {"name": "nuc", "display_name": "Nucleus", "description": "<p>The <code>nuc-&lt;label&gt;</code> entity can be used to distinguish acquisitions tuned\nto detect different nuclei.\nThe label is the name of the nucleus or nuclei, which corresponds to DICOM Tag <code>0018, 9100</code>.\nIf present in the filename, <code>\"ResonantNucleus\"</code> MUST also be included in\nthe associated metadata.</p>", "type": "string", "format": "label", "required": "optional"}, "volume": {"name": "voi", "display_name": "Volume of Interest", "description": "<p>The <code>voi-&lt;label&gt;</code> entity can be used to distinguish acquisitions localized to different regions.\nThe label SHOULD be the name of the body region or part scanned.\nIf used, the fields <code>\"BodyPart\"</code> and <code>\"BodyPartDetails\"</code> MUST be defined in the JSON file.\n<code>BodyPartDetailsOntology</code> is OPTIONAL to also include.</p>", "type": "string", "format": "label", "required": "optional"}}, "value": "unloc", "display_name": "Unlocalized spectroscopy", "description": "<p>MRS acquisitions run without localization.\nThis includes signals detected using coil sensitivity only.</p>\n<br><code>mrs</code>"}, {"entities": {"subject": {"name": "sub", "display_name": "Subject", "description": "<p>A person or animal participating in the study.</p>", "type": "string", "format": "label", "required": "required"}, "session": {"name": "ses", "display_name": "Session", "description": "<p>A logical grouping of neuroimaging and behavioral data consistent across subjects.\nSession can (but doesn't have to) be synonymous to a visit in a longitudinal study.\nIn general, subjects will stay in the scanner during one session.\nHowever, for example, if a subject has to leave the scanner room and then\nbe re-positioned on the scanner bed, the set of MRI acquisitions will still\nbe considered as a session and match sessions acquired in other subjects.\nSimilarly, in situations where different data types are obtained over\nseveral visits (for example fMRI on one day followed by DWI the day after)\nthose can be grouped in one session.</p>\n<p>Defining multiple sessions is appropriate when several identical or similar\ndata acquisitions are planned and performed on all -or most- subjects,\noften in the case of some intervention between sessions\n(for example, training).</p>", "type": "string", "format": "label", "required": "optional"}, "task": {"name": "task", "display_name": "Task", "description": "<p>A set of structured activities performed by the participant.\nTasks are usually accompanied by stimuli and responses, and can greatly vary in complexity.</p>\n<p>In the context of brain scanning, a task is always tied to one data acquisition.\nTherefore, even if during one acquisition the subject performed multiple conceptually different behaviors\n(with different sets of instructions) they will be considered one (combined) task.</p>\n<p>While tasks may be repeated across multiple acquisitions,\na given task may have different sets of stimuli (for example, randomized order) and participant responses\nacross subjects, sessions, and runs.</p>\n<p>The <code>task-&lt;label&gt;</code> MUST be consistent across subjects and sessions.</p>\n<p>Files with the <code>task-&lt;label&gt;</code> entity SHOULD have an associated\n<a href=\"SPEC_ROOT/modality-specific-files/task-events.md#task-events\">events file</a>,\nas well as certain metadata fields in the associated JSON file.</p>\n<p>For the purpose of this specification we consider the so-called \"resting state\" a task,\nalthough events files are not expected for resting state data.\nAdditionally, a common convention in the specification is to include the word \"rest\" in\nthe <code>task</code> label for resting state files (for example, <code>task-rest</code>).</p>", "type": "string", "format": "label", "required": "optional"}, "acquisition": {"name": "acq", "display_name": "Acquisition", "description": "<p>The <code>acq-&lt;label&gt;</code> entity corresponds to a custom label the user MAY use to distinguish\na different set of parameters used for acquiring the same modality.</p>\n<p>For example, this should be used when a study includes two T1w images -\none full brain low resolution and one restricted field of view but high resolution.\nIn such case two files could have the following names:\n<code>sub-01_acq-highres_T1w.nii.gz</code> and <code>sub-01_acq-lowres_T1w.nii.gz</code>;\nhowever, the user is free to choose any other label than <code>highres</code> and <code>lowres</code> as long\nas they are consistent across subjects and sessions.</p>\n<p>In case different sequences are used to record the same modality\n(for example, <code>RARE</code> and <code>FLASH</code> for T1w)\nthis field can also be used to make that distinction.\nThe level of detail at which the distinction is made\n(for example, just between <code>RARE</code> and <code>FLASH</code>, or between <code>RARE</code>, <code>FLASH</code>, and <code>FLASHsubsampled</code>)\nremains at the discretion of the researcher.</p>", "type": "string", "format": "label", "required": "optional"}, "reconstruction": {"name": "rec", "display_name": "Reconstruction", "description": "<p>The <code>rec-&lt;label&gt;</code> entity can be used to distinguish different reconstruction algorithms\n(for example, <code>MoCo</code> for the ones using motion correction).</p>", "type": "string", "format": "label", "required": "optional"}, "run": {"name": "run", "display_name": "Run", "description": "<p>The <code>run-&lt;index&gt;</code> entity is used to distinguish separate data acquisitions with the same acquisition parameters\nand (other) entities.</p>\n<p>If several data acquisitions (for example, MRI scans or EEG recordings)\nwith the same acquisition parameters are acquired in the same session,\nthey MUST be indexed with the <a href=\"SPEC_ROOT/appendices/entities.md#run\"><code>run-&lt;index&gt;</code></a> entity:\n<code>_run-1</code>, <code>_run-2</code>, <code>_run-3</code>, and so on\n(only nonnegative integers are allowed as run indices).</p>\n<p>If different entities apply,\nsuch as a different session indicated by [<code>ses-&lt;label&gt;</code>][SPEC_ROOT/appendices/entities.md#ses),\nor different acquisition parameters indicated by\n<a href=\"SPEC_ROOT/appendices/entities.md#acq\"><code>acq-&lt;label&gt;</code></a>,\nthen <code>run</code> is not needed to distinguish the scans and MAY be omitted.</p>", "type": "string", "format": "index", "required": "optional"}, "echo": {"name": "echo", "display_name": "Echo", "description": "<p>If files belonging to an entity-linked file collection are acquired at different\necho times, the <code>echo-&lt;index&gt;</code> entity MUST be used to distinguish individual files.</p>\n<p>This entity represents the <code>\"EchoTime\"</code> metadata field.\nTherefore, if the <code>echo-&lt;index&gt;</code> entity is present in a filename,\n<code>\"EchoTime\"</code> MUST be defined in the associated metadata.\nPlease note that the <code>&lt;index&gt;</code> denotes the number/index (in the form of a nonnegative integer),\nnot the <code>\"EchoTime\"</code> value of the separate JSON file.</p>", "type": "string", "format": "index", "required": "optional"}, "inversion": {"name": "inv", "display_name": "Inversion Time", "description": "<p>If files belonging to an entity-linked file collection are acquired at different inversion times,\nthe <code>inv-&lt;index&gt;</code> entity MUST be used to distinguish individual files.</p>\n<p>This entity represents the <code>\"InversionTime</code> metadata field.\nTherefore, if the <code>inv-&lt;index&gt;</code> entity is present in a filename,\n<code>\"InversionTime\"</code> MUST be defined in the associated metadata.\nPlease note that the <code>&lt;index&gt;</code> denotes the number/index (in the form of a nonnegative integer),\nnot the <code>\"InversionTime\"</code> value of the separate JSON file.</p>", "type": "string", "format": "index", "required": "optional"}, "nucleus": {"name": "nuc", "display_name": "Nucleus", "description": "<p>The <code>nuc-&lt;label&gt;</code> entity can be used to distinguish acquisitions tuned\nto detect different nuclei.\nThe label is the name of the nucleus or nuclei, which corresponds to DICOM Tag <code>0018, 9100</code>.\nIf present in the filename, <code>\"ResonantNucleus\"</code> MUST also be included in\nthe associated metadata.</p>", "type": "string", "format": "label", "required": "optional"}, "volume": {"name": "voi", "display_name": "Volume of Interest", "description": "<p>The <code>voi-&lt;label&gt;</code> entity can be used to distinguish acquisitions localized to different regions.\nThe label SHOULD be the name of the body region or part scanned.\nIf used, the fields <code>\"BodyPart\"</code> and <code>\"BodyPartDetails\"</code> MUST be defined in the JSON file.\n<code>BodyPartDetailsOntology</code> is OPTIONAL to also include.</p>", "type": "string", "format": "label", "required": "optional"}}, "value": "mrsref", "display_name": "MRS reference acquisition", "description": "<p>An MRS acquisition collected to serve as a concentration reference for absolute quantification\nor as a calibration reference for preprocessing (for example, eddy-current correction).</p>\n<br><code>mrs</code>"}], "perf": [{"entities": {"subject": {"name": "sub", "display_name": "Subject", "description": "<p>A person or animal participating in the study.</p>", "type": "string", "format": "label", "required": "required"}, "session": {"name": "ses", "display_name": "Session", "description": "<p>A logical grouping of neuroimaging and behavioral data consistent across subjects.\nSession can (but doesn't have to) be synonymous to a visit in a longitudinal study.\nIn general, subjects will stay in the scanner during one session.\nHowever, for example, if a subject has to leave the scanner room and then\nbe re-positioned on the scanner bed, the set of MRI acquisitions will still\nbe considered as a session and match sessions acquired in other subjects.\nSimilarly, in situations where different data types are obtained over\nseveral visits (for example fMRI on one day followed by DWI the day after)\nthose can be grouped in one session.</p>\n<p>Defining multiple sessions is appropriate when several identical or similar\ndata acquisitions are planned and performed on all -or most- subjects,\noften in the case of some intervention between sessions\n(for example, training).</p>", "type": "string", "format": "label", "required": "optional"}, "acquisition": {"name": "acq", "display_name": "Acquisition", "description": "<p>The <code>acq-&lt;label&gt;</code> entity corresponds to a custom label the user MAY use to distinguish\na different set of parameters used for acquiring the same modality.</p>\n<p>For example, this should be used when a study includes two T1w images -\none full brain low resolution and one restricted field of view but high resolution.\nIn such case two files could have the following names:\n<code>sub-01_acq-highres_T1w.nii.gz</code> and <code>sub-01_acq-lowres_T1w.nii.gz</code>;\nhowever, the user is free to choose any other label than <code>highres</code> and <code>lowres</code> as long\nas they are consistent across subjects and sessions.</p>\n<p>In case different sequences are used to record the same modality\n(for example, <code>RARE</code> and <code>FLASH</code> for T1w)\nthis field can also be used to make that distinction.\nThe level of detail at which the distinction is made\n(for example, just between <code>RARE</code> and <code>FLASH</code>, or between <code>RARE</code>, <code>FLASH</code>, and <code>FLASHsubsampled</code>)\nremains at the discretion of the researcher.</p>", "type": "string", "format": "label", "required": "optional"}, "reconstruction": {"name": "rec", "display_name": "Reconstruction", "description": "<p>The <code>rec-&lt;label&gt;</code> entity can be used to distinguish different reconstruction algorithms\n(for example, <code>MoCo</code> for the ones using motion correction).</p>", "type": "string", "format": "label", "required": "optional"}, "direction": {"name": "dir", "display_name": "Phase-Encoding Direction", "description": "<p>The <code>dir-&lt;label&gt;</code> entity can be set to an arbitrary alphanumeric label\n(for example, <code>dir-LR</code> or <code>dir-AP</code>)\nto distinguish different phase-encoding directions.</p>\n<p>This entity represents the <code>\"PhaseEncodingDirection\"</code> metadata field.\nTherefore, if the <code>dir-&lt;label&gt;</code> entity is present in a filename,\n<code>\"PhaseEncodingDirection\"</code> MUST be defined in the associated metadata.\nPlease note that the <code>&lt;label&gt;</code> does not need to match the actual value of the field.</p>", "type": "string", "format": "label", "required": "optional"}, "run": {"name": "run", "display_name": "Run", "description": "<p>The <code>run-&lt;index&gt;</code> entity is used to distinguish separate data acquisitions with the same acquisition parameters\nand (other) entities.</p>\n<p>If several data acquisitions (for example, MRI scans or EEG recordings)\nwith the same acquisition parameters are acquired in the same session,\nthey MUST be indexed with the <a href=\"SPEC_ROOT/appendices/entities.md#run\"><code>run-&lt;index&gt;</code></a> entity:\n<code>_run-1</code>, <code>_run-2</code>, <code>_run-3</code>, and so on\n(only nonnegative integers are allowed as run indices).</p>\n<p>If different entities apply,\nsuch as a different session indicated by [<code>ses-&lt;label&gt;</code>][SPEC_ROOT/appendices/entities.md#ses),\nor different acquisition parameters indicated by\n<a href=\"SPEC_ROOT/appendices/entities.md#acq\"><code>acq-&lt;label&gt;</code></a>,\nthen <code>run</code> is not needed to distinguish the scans and MAY be omitted.</p>", "type": "string", "format": "index", "required": "optional"}}, "value": "asl", "display_name": "Arterial Spin Labeling", "description": "<p>The complete ASL time series stored as a 4D NIfTI file in the original\nacquisition order, with possible volume types including: control, label,\nm0scan, deltam, cbf.</p>\n<br><code>asl</code>"}, {"entities": {"subject": {"name": "sub", "display_name": "Subject", "description": "<p>A person or animal participating in the study.</p>", "type": "string", "format": "label", "required": "required"}, "session": {"name": "ses", "display_name": "Session", "description": "<p>A logical grouping of neuroimaging and behavioral data consistent across subjects.\nSession can (but doesn't have to) be synonymous to a visit in a longitudinal study.\nIn general, subjects will stay in the scanner during one session.\nHowever, for example, if a subject has to leave the scanner room and then\nbe re-positioned on the scanner bed, the set of MRI acquisitions will still\nbe considered as a session and match sessions acquired in other subjects.\nSimilarly, in situations where different data types are obtained over\nseveral visits (for example fMRI on one day followed by DWI the day after)\nthose can be grouped in one session.</p>\n<p>Defining multiple sessions is appropriate when several identical or similar\ndata acquisitions are planned and performed on all -or most- subjects,\noften in the case of some intervention between sessions\n(for example, training).</p>", "type": "string", "format": "label", "required": "optional"}, "acquisition": {"name": "acq", "display_name": "Acquisition", "description": "<p>The <code>acq-&lt;label&gt;</code> entity corresponds to a custom label the user MAY use to distinguish\na different set of parameters used for acquiring the same modality.</p>\n<p>For example, this should be used when a study includes two T1w images -\none full brain low resolution and one restricted field of view but high resolution.\nIn such case two files could have the following names:\n<code>sub-01_acq-highres_T1w.nii.gz</code> and <code>sub-01_acq-lowres_T1w.nii.gz</code>;\nhowever, the user is free to choose any other label than <code>highres</code> and <code>lowres</code> as long\nas they are consistent across subjects and sessions.</p>\n<p>In case different sequences are used to record the same modality\n(for example, <code>RARE</code> and <code>FLASH</code> for T1w)\nthis field can also be used to make that distinction.\nThe level of detail at which the distinction is made\n(for example, just between <code>RARE</code> and <code>FLASH</code>, or between <code>RARE</code>, <code>FLASH</code>, and <code>FLASHsubsampled</code>)\nremains at the discretion of the researcher.</p>", "type": "string", "format": "label", "required": "optional"}, "reconstruction": {"name": "rec", "display_name": "Reconstruction", "description": "<p>The <code>rec-&lt;label&gt;</code> entity can be used to distinguish different reconstruction algorithms\n(for example, <code>MoCo</code> for the ones using motion correction).</p>", "type": "string", "format": "label", "required": "optional"}, "direction": {"name": "dir", "display_name": "Phase-Encoding Direction", "description": "<p>The <code>dir-&lt;label&gt;</code> entity can be set to an arbitrary alphanumeric label\n(for example, <code>dir-LR</code> or <code>dir-AP</code>)\nto distinguish different phase-encoding directions.</p>\n<p>This entity represents the <code>\"PhaseEncodingDirection\"</code> metadata field.\nTherefore, if the <code>dir-&lt;label&gt;</code> entity is present in a filename,\n<code>\"PhaseEncodingDirection\"</code> MUST be defined in the associated metadata.\nPlease note that the <code>&lt;label&gt;</code> does not need to match the actual value of the field.</p>", "type": "string", "format": "label", "required": "optional"}, "run": {"name": "run", "display_name": "Run", "description": "<p>The <code>run-&lt;index&gt;</code> entity is used to distinguish separate data acquisitions with the same acquisition parameters\nand (other) entities.</p>\n<p>If several data acquisitions (for example, MRI scans or EEG recordings)\nwith the same acquisition parameters are acquired in the same session,\nthey MUST be indexed with the <a href=\"SPEC_ROOT/appendices/entities.md#run\"><code>run-&lt;index&gt;</code></a> entity:\n<code>_run-1</code>, <code>_run-2</code>, <code>_run-3</code>, and so on\n(only nonnegative integers are allowed as run indices).</p>\n<p>If different entities apply,\nsuch as a different session indicated by [<code>ses-&lt;label&gt;</code>][SPEC_ROOT/appendices/entities.md#ses),\nor different acquisition parameters indicated by\n<a href=\"SPEC_ROOT/appendices/entities.md#acq\"><code>acq-&lt;label&gt;</code></a>,\nthen <code>run</code> is not needed to distinguish the scans and MAY be omitted.</p>", "type": "string", "format": "index", "required": "optional"}}, "value": "m0scan", "display_name": "M0 image", "description": "<p>The M0 image is a calibration image, used to estimate the equilibrium\nmagnetization of blood.</p>\n<br><code>asl</code>"}], "pet": [{"entities": {"subject": {"name": "sub", "display_name": "Subject", "description": "<p>A person or animal participating in the study.</p>", "type": "string", "format": "label", "required": "required"}, "session": {"name": "ses", "display_name": "Session", "description": "<p>A logical grouping of neuroimaging and behavioral data consistent across subjects.\nSession can (but doesn't have to) be synonymous to a visit in a longitudinal study.\nIn general, subjects will stay in the scanner during one session.\nHowever, for example, if a subject has to leave the scanner room and then\nbe re-positioned on the scanner bed, the set of MRI acquisitions will still\nbe considered as a session and match sessions acquired in other subjects.\nSimilarly, in situations where different data types are obtained over\nseveral visits (for example fMRI on one day followed by DWI the day after)\nthose can be grouped in one session.</p>\n<p>Defining multiple sessions is appropriate when several identical or similar\ndata acquisitions are planned and performed on all -or most- subjects,\noften in the case of some intervention between sessions\n(for example, training).</p>", "type": "string", "format": "label", "required": "optional"}, "task": {"name": "task", "display_name": "Task", "description": "<p>A set of structured activities performed by the participant.\nTasks are usually accompanied by stimuli and responses, and can greatly vary in complexity.</p>\n<p>In the context of brain scanning, a task is always tied to one data acquisition.\nTherefore, even if during one acquisition the subject performed multiple conceptually different behaviors\n(with different sets of instructions) they will be considered one (combined) task.</p>\n<p>While tasks may be repeated across multiple acquisitions,\na given task may have different sets of stimuli (for example, randomized order) and participant responses\nacross subjects, sessions, and runs.</p>\n<p>The <code>task-&lt;label&gt;</code> MUST be consistent across subjects and sessions.</p>\n<p>Files with the <code>task-&lt;label&gt;</code> entity SHOULD have an associated\n<a href=\"SPEC_ROOT/modality-specific-files/task-events.md#task-events\">events file</a>,\nas well as certain metadata fields in the associated JSON file.</p>\n<p>For the purpose of this specification we consider the so-called \"resting state\" a task,\nalthough events files are not expected for resting state data.\nAdditionally, a common convention in the specification is to include the word \"rest\" in\nthe <code>task</code> label for resting state files (for example, <code>task-rest</code>).</p>", "type": "string", "format": "label", "required": "optional"}, "tracer": {"name": "trc", "display_name": "Tracer", "description": "<p>The <code>trc-&lt;label&gt;</code> entity can be used to distinguish sequences using different tracers.</p>\n<p>This entity represents the <code>\"TracerName\"</code> metadata field.\nTherefore, if the <code>trc-&lt;label&gt;</code> entity is present in a filename,\n<code>\"TracerName\"</code> MUST be defined in the associated metadata.\nPlease note that the <code>&lt;label&gt;</code> does not need to match the actual value of the field.</p>", "type": "string", "format": "label", "required": "optional"}, "reconstruction": {"name": "rec", "display_name": "Reconstruction", "description": "<p>The <code>rec-&lt;label&gt;</code> entity can be used to distinguish different reconstruction algorithms\n(for example, <code>MoCo</code> for the ones using motion correction).</p>", "type": "string", "format": "label", "required": "optional"}, "run": {"name": "run", "display_name": "Run", "description": "<p>The <code>run-&lt;index&gt;</code> entity is used to distinguish separate data acquisitions with the same acquisition parameters\nand (other) entities.</p>\n<p>If several data acquisitions (for example, MRI scans or EEG recordings)\nwith the same acquisition parameters are acquired in the same session,\nthey MUST be indexed with the <a href=\"SPEC_ROOT/appendices/entities.md#run\"><code>run-&lt;index&gt;</code></a> entity:\n<code>_run-1</code>, <code>_run-2</code>, <code>_run-3</code>, and so on\n(only nonnegative integers are allowed as run indices).</p>\n<p>If different entities apply,\nsuch as a different session indicated by [<code>ses-&lt;label&gt;</code>][SPEC_ROOT/appendices/entities.md#ses),\nor different acquisition parameters indicated by\n<a href=\"SPEC_ROOT/appendices/entities.md#acq\"><code>acq-&lt;label&gt;</code></a>,\nthen <code>run</code> is not needed to distinguish the scans and MAY be omitted.</p>", "type": "string", "format": "index", "required": "optional"}}, "value": "pet", "display_name": "Positron Emission Tomography", "description": "<p>PET imaging data SHOULD be stored in 4D\n(or 3D, if only one volume was acquired) NIfTI files with the <code>_pet</code> suffix.\nVolumes MUST be stored in chronological order\n(the order they were acquired in).</p>\n<br><code>pet</code>"}]}