Magnetoencephalography

Support for Magnetoencephalography (MEG) was developed as a BIDS Extension Proposal. Please see Citing BIDS on how to appropriately credit this extension when referring to it in the context of the academic literature.

Example datasets

The following example MEG datasets have been formatted using this specification and can be used for practical guidance when curating a new dataset.

• multimodal MEG and MRI

Further datasets are available from the BIDS examples repository.

MEG recording data

Template:

sub-<label>/
    [ses-<label>/]
        meg/
            sub-<label>[_ses-<label>]_task-<label>[_acq-<label>][_run-<index>][_proc-<label>][_split-<index>]_meg.<extension>
            sub-<label>[_ses-<label>]_task-<label>[_acq-<label>][_run-<index>][_proc-<label>][_split-<index>]_meg.json
            sub-<label>[_ses-<label>]_acq-<calibration>_meg.dat
            sub-<label>[_ses-<label>]_acq-<crosstalk>_meg.fif
            sub-<label>[_ses-<label>][_task-<label>][_acq-<label>][_space-<label>]_markers.mrk
            sub-<label>[_ses-<label>][_task-<label>][_acq-<label>][_space-<label>]_markers.sqd
            sub-<label>[_ses-<label>]_task-<label>[_acq-<label>][_run-<index>]_events.json
            sub-<label>[_ses-<label>]_task-<label>[_acq-<label>][_run-<index>]_events.tsv
            sub-<label>[_ses-<label>]_task-<label>[_acq-<label>][_run-<index>][_proc-<label>][_recording-<label>]_physio.json
            sub-<label>[_ses-<label>]_task-<label>[_acq-<label>][_run-<index>][_proc-<label>][_recording-<label>]_physio.tsv.gz
            sub-<label>[_ses-<label>]_task-<label>[_acq-<label>][_run-<index>][_proc-<label>][_recording-<label>]_stim.json
            sub-<label>[_ses-<label>]_task-<label>[_acq-<label>][_run-<index>][_proc-<label>][_recording-<label>]_stim.tsv.gz

Legend:

• For more information about filename elements (for example, entities, suffixes, extensions), follow the links embedded in the filename template.

• Filename entities or directories between square brackets (for example, [_ses-<label>]) are OPTIONAL.

• Some entities may only allow specific values, in which case those values are listed in <>, separated by |.

• _<suffix> means that there are several (>6) valid suffixes for this filename pattern.

• .<extension> means that there are several (>6) valid extensions for this file type.

• [.gz] means that both the unzipped and gzipped versions of the extension are valid.

Unprocessed MEG data MUST be stored in the native file format of the MEG instrument with which the data was collected. With the MEG specification of BIDS, we wish to promote the adoption of good practices in the management of scientific data. Hence, the emphasis is not to impose a new, generic data format for the modality, but rather to standardize the way data is stored in repositories. Further, there is currently no widely accepted standard file format for MEG, but major software applications, including free and open-source solutions for MEG data analysis, provide readers of such raw files.

Some software readers may skip important metadata that is specific to MEG system manufacturers. It is therefore RECOMMENDED that users provide additional meta information extracted from the manufacturer raw data files in a sidecar JSON file. This allows for easy searching and indexing of key metadata elements without the need to parse files in proprietary data format. Other relevant files MAY be included alongside the MEG data; examples are provided below.

This template is for MEG data of any kind, including but not limited to task-based, resting-state, and noise recordings. If multiple Tasks were performed within a single Run, the task description can be set to task-multitask. The *_meg.json file SHOULD contain details on the Tasks.

Some manufacturers' data storage conventions use directories which contain data files of various nature: for example, CTF's .ds format, or BTi/4D's data directory. Yet other manufacturers split their files once they exceed a certain size limit. For example Neuromag/Elekta/Megin, which can produce several files for a single recording. Both some_file.fif and some_file-1.fif would belong to a single recording. In BIDS, the split entity is RECOMMENDED to deal with split files. If there are multiple parts of a recording and the optional scans.tsv is provided, remember to list all files separately in scans.tsv and that the entries for the acq_time column in scans.tsv MUST all be identical, as described in Scans file.

The Neuromag/Elekta/Megin system may also produce datasets that require a set of crosstalk and calibration files to be used properly (see also filename templates above). Please refer to Cross-talk and fine-calibration files for more information on this detail.

Another manufacturer-specific detail pertains to the KIT/Yokogawa/Ricoh system, which saves the MEG sensor coil positions in a separate file with two possible filename extensions (.sqd, .mrk). For these files, the markers suffix MUST be used. For example: sub-01_task-nback_markers.sqd

Please refer to the MEG File Formats Appendix for general information on how to deal with such manufacturer specifics and to see more examples.

The proc-<label> entity is analogous to the rec-<label> entity for MRI, and denotes a variant of a file that was a result of particular processing performed on the device. This is useful for files produced in particular by Neuromag/Elekta/MEGIN's MaxFilter (for example, sss, tsss, trans, quat, mc), which some installations impose to be run on raw data prior to analysis. Such processing steps are needed for example because of active shielding software corrections that have to be performed to before the MEG data can actually be exploited.

Recording (i)EEG simultaneously with MEG

Note that if (i)EEG is recorded with a separate amplifier, it SHOULD be stored separately under a new /eeg data type (see the EEG and iEEG specifications).

If however (i)EEG is recorded simultaneously with the same MEG system, it MAY be stored under the /meg data type. In that case, it SHOULD have the same sampling frequency as MEG (see SamplingFrequency field below). Furthermore, (i)EEG sensor coordinates MAY be recorded in an electrodes.tsv file using MEG-specific coordinate systems (see Coordinate System JSON below and the Coordinate Systems Appendix).

Sidecar JSON (*_meg.json)

For consistency between studies and institutions, we encourage users to extract the values of metadata fields from the actual raw data. Whenever possible, please avoid using ad hoc wording.

Those fields MUST be present:

Key name	Requirement Level	Data type	Description
SamplingFrequency	REQUIRED	number	Sampling frequency (in Hz) of all the data in the recording, regardless of their type (for example, 2400). The sampling frequency of data channels that deviate from the main sampling frequency SHOULD be specified in the channels.tsv file.
PowerLineFrequency	REQUIRED	number or "n/a"	Frequency (in Hz) of the power grid at the geographical location of the instrument (for example, 50 or 60).
DewarPosition	REQUIRED	string	Position of the dewar during the MEG scan: "upright", "supine" or "degrees" of angle from vertical: for example on CTF systems, "upright=15°, supine=90°".
SoftwareFilters	REQUIRED	object of objects or "n/a"	Object of temporal software filters applied, or "n/a" if the data is not available. Each key-value pair in the JSON object is a name of the filter and an object in which its parameters are defined as key-value pairs (for example, {"Anti-aliasing filter": {"half-amplitude cutoff (Hz)": 500, "Roll-off": "6dB/Octave"}}).
DigitizedLandmarks	REQUIRED	boolean	true or false value indicating whether anatomical landmark points (fiducials) are contained within this recording. Must be one of: "true", "false".
DigitizedHeadPoints	REQUIRED	boolean	true or false value indicating whether head points outlining the scalp/face surface are contained within this recording. Must be one of: "true", "false".

Those fields SHOULD be present:

Key name	Requirement Level	Data type	Description
MEGChannelCount	RECOMMENDED	integer	Number of MEG channels (for example, 275). Must be a number greater than or equal to 0.
MEGREFChannelCount	RECOMMENDED	integer	Number of MEG reference channels (for example, 23). For systems without such channels (for example, Neuromag Vectorview), MEGREFChannelCount should be set to 0. Must be a number greater than or equal to 0.
EEGChannelCount	RECOMMENDED	integer	Number of EEG channels recorded simultaneously (for example, 21). Must be a number greater than or equal to 0.
ECOGChannelCount	RECOMMENDED	integer	Number of ECoG channels. Must be a number greater than or equal to 0.
SEEGChannelCount	RECOMMENDED	integer	Number of SEEG channels. Must be a number greater than or equal to 0.
EOGChannelCount	RECOMMENDED	integer	Number of EOG channels. Must be a number greater than or equal to 0.
ECGChannelCount	RECOMMENDED	integer	Number of ECG channels. Must be a number greater than or equal to 0.
EMGChannelCount	RECOMMENDED	integer	Number of EMG channels. Must be a number greater than or equal to 0.
MiscChannelCount	RECOMMENDED	integer	Number of miscellaneous analog channels for auxiliary signals. Must be a number greater than or equal to 0.
TriggerChannelCount	RECOMMENDED	integer	Number of channels for digital (binary TTL) triggers or analog equivalents (TTL in volt). Corresponds to the TRIG channel type. Must be a number greater than or equal to 0.
RecordingDuration	RECOMMENDED	number	Length of the recording in seconds (for example, 3600).
RecordingType	RECOMMENDED	string	Defines whether the recording is "continuous", "discontinuous", or "epoched", where "epoched" is limited to time windows about events of interest (for example, stimulus presentations or subject responses). Must be one of: "continuous", "epoched", "discontinuous".
EpochLength	RECOMMENDED	number	Duration of individual epochs in seconds (for example, 1) in case of epoched data. If recording was continuous or discontinuous, leave out the field. Must be a number greater than or equal to 0.
ContinuousHeadLocalization	RECOMMENDED	boolean	true or false value indicating whether continuous head localisation was performed. Must be one of: "true", "false".
HeadCoilFrequency	RECOMMENDED	number or array of numbers	List of frequencies (in Hz) used by the head localisation coils ('HLC' in CTF systems, 'HPI' in Neuromag/Elekta/MEGIN, 'COH' in BTi/4D) that track the subject's head position in the MEG helmet (for example, [293, 307, 314, 321]).
MaxMovement	RECOMMENDED	number	Maximum head movement (in mm) detected during the recording, as measured by the head localisation coils (for example, 4.8).
SubjectArtefactDescription	RECOMMENDED	string	Freeform description of the observed subject artifact and its possible cause (for example, "Vagus Nerve Stimulator", "non-removable implant"). If this field is set to "n/a", it will be interpreted as absence of major source of artifacts except cardiac and blinks.
AssociatedEmptyRoom	RECOMMENDED	array or string	One or more BIDS URIs pointing to empty-room file(s) associated with the subject's MEG recording. Using forward-slash separated paths relative to the dataset root is DEPRECATED.
HardwareFilters	RECOMMENDED	object of objects or "n/a"	Object of temporal hardware filters applied, or "n/a" if the data is not available. Each key-value pair in the JSON object is a name of the filter and an object in which its parameters are defined as key-value pairs. For example, {"Highpass RC filter": {"Half amplitude cutoff (Hz)": 0.0159, "Roll-off": "6dB/Octave"}}.

These fields MAY be present:

Key name	Requirement Level	Data type	Description
ElectricalStimulation	OPTIONAL	boolean	Boolean field to specify if electrical stimulation was done during the recording (options are true or false). Parameters for event-like stimulation should be specified in the events.tsv file. Must be one of: "true", "false".
ElectricalStimulationParameters	OPTIONAL	string	Free form description of stimulation parameters, such as frequency or shape. Specific onsets can be specified in the events.tsv file. Specific shapes can be described here in freeform text.

Hardware information

Key name	Requirement Level	Data type	Description
Manufacturer	RECOMMENDED	string	Manufacturer of the equipment that produced the measurements. For MEG scanners, this must be one of: "CTF", "Elekta/Neuromag", "BTi/4D", "KIT/Yokogawa", "ITAB", "KRISS", "Other". See the MEG Systems Appendix for preferred names.
ManufacturersModelName	RECOMMENDED	string	Manufacturer's model name of the equipment that produced the measurements. See the MEG Systems Appendix for preferred names.
SoftwareVersions	RECOMMENDED	string	Manufacturer's designation of software version of the equipment that produced the measurements.
DeviceSerialNumber	RECOMMENDED	string	The serial number of the equipment that produced the measurements. A pseudonym can also be used to prevent the equipment from being identifiable, so long as each pseudonym is unique within the dataset.

Task information

Key name	Requirement Level	Data type	Description
TaskName	REQUIRED	string	Name of the task. No two tasks should have the same name. The task label included in the filename is derived from this "TaskName" field by removing all non-alphanumeric characters (that is, all except those matching [0-9a-zA-Z]). For example "TaskName" "faces n-back" or "head nodding" will correspond to task labels facesnback and headnodding, respectively. A RECOMMENDED convention is to name resting state task using labels beginning with rest.
TaskDescription	RECOMMENDED	string	Longer description of the task.
Instructions	RECOMMENDED	string	Text of the instructions given to participants before the recording. This is especially important in context of resting state recordings and distinguishing between eyes open and eyes closed paradigms.
CogAtlasID	RECOMMENDED	string	URI of the corresponding Cognitive Atlas Task term.
CogPOID	RECOMMENDED	string	URI of the corresponding CogPO term.

Institution information

Key name	Requirement Level	Data type	Description
InstitutionName	RECOMMENDED	string	The name of the institution in charge of the equipment that produced the measurements.
InstitutionAddress	RECOMMENDED	string	The address of the institution in charge of the equipment that produced the measurements.
InstitutionalDepartmentName	RECOMMENDED	string	The department in the institution in charge of the equipment that produced the measurements.

Specific EEG fields

If recorded with MEG, see Recording EEG simultaneously with MEG SHOULD be present:

Key name	Requirement Level	Data type	Description
EEGPlacementScheme	OPTIONAL	string	Placement scheme of EEG electrodes. Either the name of a standardized placement system (for example, "10-20") or a list of standardized electrode names (for example, ["Cz", "Pz"]).
CapManufacturer	OPTIONAL	string	Name of the cap manufacturer (for example, "EasyCap").
CapManufacturersModelName	OPTIONAL	string	Manufacturer's designation of the cap model (for example, "actiCAP 64 Ch Standard-2").
EEGReference	OPTIONAL	string	General description of the reference scheme used and (when applicable) of location of the reference electrode in the raw recordings (for example, "left mastoid", "Cz", "CMS"). If different channels have a different reference, this field should have a general description and the channel specific reference should be defined in the channels.tsv file.

Example *_meg.json

{
   "InstitutionName": "Stanford University",
   "InstitutionAddress": "450 Serra Mall, Stanford, CA 94305-2004, USA",
   "Manufacturer": "CTF",
   "ManufacturersModelName": "CTF-275",
   "DeviceSerialNumber": "11035",
   "SoftwareVersions": "Acq 5.4.2-linux-20070507",
   "PowerLineFrequency": 60,
   "SamplingFrequency": 2400,
   "MEGChannelCount": 270,
   "MEGREFChannelCount": 26,
   "EEGChannelCount": 0,
   "EOGChannelCount": 2,
   "ECGChannelCount": 1,
   "EMGChannelCount": 0,
     "DewarPosition": "upright",
   "SoftwareFilters": {
     "SpatialCompensation": {"GradientOrder": "3rd"}
   },
   "RecordingDuration": 600,
   "RecordingType": "continuous",
   "EpochLength": 0,
   "TaskName": "rest",
   "ContinuousHeadLocalization": true,
   "HeadCoilFrequency": [1470,1530,1590],
   "DigitizedLandmarks": true,
   "DigitizedHeadPoints": true
}

Note that the date and time information SHOULD be stored in the Study key file (scans.tsv), see Scans file. Date time information MUST be expressed as indicated in Units

Channels description (*_channels.tsv)

Template:

sub-<label>/
    [ses-<label>/]
        meg/
            sub-<label>[_ses-<label>]_task-<label>[_acq-<label>][_run-<index>][_proc-<label>]_channels.json
            sub-<label>[_ses-<label>]_task-<label>[_acq-<label>][_run-<index>][_proc-<label>]_channels.tsv

Legend:

• For more information about filename elements (for example, entities, suffixes, extensions), follow the links embedded in the filename template.

• Filename entities or directories between square brackets (for example, [_ses-<label>]) are OPTIONAL.

• Some entities may only allow specific values, in which case those values are listed in <>, separated by |.

• _<suffix> means that there are several (>6) valid suffixes for this filename pattern.

• .<extension> means that there are several (>6) valid extensions for this file type.

• [.gz] means that both the unzipped and gzipped versions of the extension are valid.

This file is RECOMMENDED as it provides easily searchable information across BIDS datasets. For example for general curation, response to queries, or for batch analysis. To avoid confusion, the channels SHOULD be listed in the order they appear in the MEG data file. Any number of additional columns MAY be added to provide additional information about the channels. Missing values MUST be indicated with "n/a".

The columns of the channels description table stored in *_channels.tsv are:

Column name	Requirement Level	Data type	Description
name	REQUIRED	string	Label of the channel. Values in name MUST be unique. This column must appear first in the file.
type	REQUIRED	string	Type of channel; MUST use the channel types listed below. Note that the type MUST be in upper-case. This column must appear second in the file. For a list of valid values for this column, see the associated glossary entry.
units	REQUIRED	string	Physical unit of the value represented in this channel, for example, V for Volt, or fT/cm for femto Tesla per centimeter (see Units). This column must appear third in the file.
description	OPTIONAL	string	Brief free-text description of the channel, or other information of interest. This column may appear anywhere in the file.
sampling_frequency	OPTIONAL	number	Sampling rate of the channel in Hz. This column may appear anywhere in the file.
low_cutoff	OPTIONAL	number or "n/a"	Frequencies used for the high-pass filter applied to the channel in Hz. If no high-pass filter applied, use n/a. This column may appear anywhere in the file.
high_cutoff	OPTIONAL	number or "n/a"	Frequencies used for the low-pass filter applied to the channel in Hz. If no low-pass filter applied, use n/a. Note that hardware anti-aliasing in A/D conversion of all MEG/EEG electronics applies a low-pass filter; specify its frequency here if applicable. This column may appear anywhere in the file.
notch	OPTIONAL	string	Frequencies used for the notch filter applied to the channel, in Hz. If notch filters are applied at multiple frequencies, these frequencies MAY be specified as a list, for example, [60, 120, 180]. If no notch filter was applied, use n/a. This column may appear anywhere in the file.
software_filters	OPTIONAL	string or "n/a"	List of temporal and/or spatial software filters applied (for example, SSS, SpatialCompensation). Note that parameters should be defined in the general MEG sidecar .json file. Indicate n/a in the absence of software filters applied. This column may appear anywhere in the file.
status	OPTIONAL	string	Data quality observed on the channel. A channel is considered bad if its data quality is compromised by excessive noise. If quality is unknown, then a value of n/a may be used. Description of noise type SHOULD be provided in [status_description]. This column may appear anywhere in the file. Must be one of: "good", "bad", "n/a".
status_description	OPTIONAL	string	Freeform text description of noise or artifact affecting data quality on the channel. It is meant to explain why the channel was declared bad in the status column. This column may appear anywhere in the file.
Additional Columns	OPTIONAL	n/a	Additional columns are allowed if they are defined in the associated metadata file.

Restricted keyword list for field type. Note that upper-case is REQUIRED:

Keyword	Description
MEGMAG	MEG magnetometer
MEGGRADAXIAL	MEG axial gradiometer
MEGGRADPLANAR	MEG planargradiometer
MEGREFMAG	MEG reference magnetometer
MEGREFGRADAXIAL	MEG reference axial gradiometer
MEGREFGRADPLANAR	MEG reference planar gradiometer
MEGOTHER	Any other type of MEG sensor
EEG	Electrode channel
ECOG	Electrode channel
SEEG	Electrode channel
DBS	Electrode channel
VEOG	Vertical EOG (electrooculogram)
HEOG	Horizontal EOG
EOG	Generic EOG channel
ECG	ElectroCardioGram (heart)
EMG	ElectroMyoGram (muscle)
TRIG	Analog (TTL in Volt) or digital (binary TTL) trigger channel
AUDIO	Audio signal
PD	Photodiode
EYEGAZE	Eye Tracker gaze
PUPIL	Eye Tracker pupil diameter
MISC	Miscellaneous
SYSCLOCK	System time showing elapsed time since trial started
ADC	Analog to Digital input
DAC	Digital to Analog output
HLU	Measured position of head and head coils
FITERR	Fit error signal from each head localization coil
OTHER	Any other type of channel

Examples of free text for field description:

• stimulus
• response
• vertical EOG
• horizontal EOG
• skin conductance
• sats
• intracranial
• eyetracker

Example *_channels.tsv

name type units description
VEOG VEOG V vertical EOG
FDI EMG V left first dorsal interosseous
UDIO001 TRIG V analog trigger signal
UADC001 AUDIO V envelope of audio signal presented to participant

Coordinate System JSON (*_coordsystem.json)

Template:

sub-<label>/
    [ses-<label>/]
        meg/
            sub-<label>[_ses-<label>][_acq-<label>]_coordsystem.json

Legend:

• For more information about filename elements (for example, entities, suffixes, extensions), follow the links embedded in the filename template.

• Filename entities or directories between square brackets (for example, [_ses-<label>]) are OPTIONAL.

• Some entities may only allow specific values, in which case those values are listed in <>, separated by |.

• _<suffix> means that there are several (>6) valid suffixes for this filename pattern.

• .<extension> means that there are several (>6) valid extensions for this file type.

• [.gz] means that both the unzipped and gzipped versions of the extension are valid.

OPTIONAL. A JSON document specifying the coordinate system(s) used for the MEG, EEG, head localization coils, and anatomical landmarks.

MEG and EEG sensors:

Key name	Requirement Level	Data type	Description
MEGCoordinateSystem	REQUIRED	string	Defines the coordinate system for the MEG sensors. See the Coordinate Systems Appendix for a list of restricted keywords for coordinate systems. If "Other", provide definition of the coordinate system in "MEGCoordinateSystemDescription". For a list of valid values for this field, see the associated glossary entry.
MEGCoordinateUnits	REQUIRED	string	Units of the coordinates of "MEGCoordinateSystem". Must be one of: "m", "mm", "cm", "n/a".
MEGCoordinateSystemDescription	OPTIONAL, but REQUIRED if MEGCoordinateSystem is Other	string	Free-form text description of the coordinate system. May also include a link to a documentation page or paper describing the system in greater detail.
EEGCoordinateSystem	OPTIONAL	string	Defines the coordinate system for the EEG sensors. See the Coordinate Systems Appendix for a list of restricted keywords for coordinate systems. If "Other", provide definition of the coordinate system in EEGCoordinateSystemDescription. See [Recording EEG simultaneously with MEG] (/modality-specific-files/magnetoencephalography.html#recording-eeg-simultaneously-with-meg). Preferably the same as the MEGCoordinateSystem. For a list of valid values for this field, see the associated glossary entry.
EEGCoordinateUnits	OPTIONAL	string	Units of the coordinates of EEGCoordinateSystem. Must be one of: "m", "mm", "cm", "n/a".
EEGCoordinateSystemDescription	OPTIONAL, but REQUIRED if EEGCoordinateSystem is Other	string	Free-form text description of the coordinate system. May also include a link to a documentation page or paper describing the system in greater detail. See [Recording EEG simultaneously with MEG] (/modality-specific-files/magnetoencephalography.html#recording-eeg-simultaneously-with-meg).

Head localization coils:

Key name	Requirement Level	Data type	Description
HeadCoilCoordinates	OPTIONAL	object of arrays	Key-value pairs describing head localization coil labels and their coordinates, interpreted following the HeadCoilCoordinateSystem (for example, {"NAS": [12.7,21.3,13.9], "LPA": [5.2,11.3,9.6], "RPA": [20.2,11.3,9.1]}). Note that coils are not always placed at locations that have a known anatomical name (for example, for Neuromag/Elekta/MEGIN, Yokogawa systems); in that case generic labels can be used (for example, {"coil1": [12.2,21.3,12.3], "coil2": [6.7,12.3,8.6], "coil3": [21.9,11.0,8.1]}). Each array MUST contain three numeric values corresponding to x, y, and z axis of the coordinate system in that exact order.
HeadCoilCoordinateSystem	OPTIONAL	string	Defines the coordinate system for the head coils. See the Coordinate Systems Appendix for a list of restricted keywords for coordinate systems. If "Other", provide definition of the coordinate system in HeadCoilCoordinateSystemDescription. For a list of valid values for this field, see the associated glossary entry.
HeadCoilCoordinateUnits	OPTIONAL	string	Units of the coordinates of HeadCoilCoordinateSystem. Must be one of: "m", "mm", "cm", "n/a".
HeadCoilCoordinateSystemDescription	OPTIONAL, but REQUIRED if HeadCoilCoordinateSystem is Other	string	Free-form text description of the coordinate system. May also include a link to a documentation page or paper describing the system in greater detail.

Digitized head points:

Key name	Requirement Level	Data type	Description
DigitizedHeadPoints	OPTIONAL	boolean	true or false value indicating whether head points outlining the scalp/face surface are contained within this recording. Must be one of: "true", "false".
DigitizedHeadPointsCoordinateSystem	OPTIONAL	string	Defines the coordinate system for the digitized head points. See the Coordinate Systems Appendix for a list of restricted keywords for coordinate systems. If "Other", provide definition of the coordinate system in "DigitizedHeadPointsCoordinateSystemDescription". For a list of valid values for this field, see the associated glossary entry.
DigitizedHeadPointsCoordinateUnits	OPTIONAL	string	Units of the coordinates of "DigitizedHeadPointsCoordinateSystem". Must be one of: "m", "mm", "cm", "n/a".
DigitizedHeadPointsCoordinateSystemDescription	OPTIONAL, but REQUIRED if DigitizedHeadPointsCoordinateSystem is Other	string	Free-form text description of the coordinate system. May also include a link to a documentation page or paper describing the system in greater detail.

Anatomical MRI:

Key name	Requirement Level	Data type	Description
IntendedFor	OPTIONAL	string or array	The paths to files for which the associated file is intended to be used. Contains one or more BIDS URIs. Using forward-slash separated paths relative to the participant subdirectory is DEPRECATED. This is used to identify the structural MRI(s), possibly of different types if a list is specified, to be used with the MEG recording.

Anatomical landmarks:

Key name	Requirement Level	Data type	Description
AnatomicalLandmarkCoordinates	OPTIONAL	object of arrays	Key-value pairs of the labels and 3-D digitized locations of anatomical landmarks, interpreted following the "AnatomicalLandmarkCoordinateSystem" (for example, {"NAS": [12.7,21.3,13.9], "LPA": [5.2,11.3,9.6], "RPA": [20.2,11.3,9.1]}. Each array MUST contain three numeric values corresponding to x, y, and z axis of the coordinate system in that exact order.
AnatomicalLandmarkCoordinateSystem	OPTIONAL	string	Defines the coordinate system for the anatomical landmarks. See the Coordinate Systems Appendix for a list of restricted keywords for coordinate systems. If "Other", provide definition of the coordinate system in "AnatomicalLandmarkCoordinateSystemDescription". Preferably the same as the MEGCoordinateSystem. For a list of valid values for this field, see the associated glossary entry.
AnatomicalLandmarkCoordinateUnits	OPTIONAL	string	Units of the coordinates of "AnatomicalLandmarkCoordinateSystem". Must be one of: "m", "mm", "cm", "n/a".
AnatomicalLandmarkCoordinateSystemDescription	OPTIONAL, but REQUIRED if AnatomicalLandmarkCoordinateSystem is Other	string	Free-form text description of the coordinate system. May also include a link to a documentation page or paper describing the system in greater detail.

It is also RECOMMENDED that the MRI voxel coordinates of the actual anatomical landmarks for co-registration of MEG with structural MRI are stored in the AnatomicalLandmarkCoordinates field in the JSON sidecar of the corresponding T1w MRI anatomical data of the subject seen in the MEG session (see Anatomy Imaging Data).

For example: "sub-01/ses-mri/anat/sub-01_ses-mri_acq-mprage_T1w.json"

In principle, these locations are those of absolute anatomical markers. However, the marking of NAS, LPA and RPA is more ambiguous than that of for example, AC and PC. This may result in some variability in their 3-D digitization from session to session, even for the same participant. The solution would be to use only one T1w file and populate the AnatomicalLandmarkCoordinates field with session-specific labels for example, "NAS-session1": [127,213,139],"NAS-session2": [123,220,142].

Fiducials information:

Key name	Requirement Level	Data type	Description
FiducialsDescription	OPTIONAL	string	Free-form text description of how the fiducials such as vitamin-E capsules were placed relative to anatomical landmarks, and how the position of the fiducials were measured (for example, "both with Polhemus and with T1w MRI").

For more information on the definition of anatomical landmarks, please visit: How are the Left and Right Pre-Auricular (LPA and RPA) points defined? - FieldTrip Toolbox

For more information on typical coordinate systems for MEG-MRI coregistration: How are the different head and MRI coordinate systems defined? - FieldTrip Toolbox or: Coordinate Systems - Brainstorm toolbox

Landmark photos (*_photo.<extension>)

Photos of the anatomical landmarks and/or head localization coils (*_photo.<extension>)

Template:

sub-<label>/
    [ses-<label>/]
        meg/
            sub-<label>[_ses-<label>][_acq-<label>]_photo.jpg
            sub-<label>[_ses-<label>][_acq-<label>]_photo.png
            sub-<label>[_ses-<label>][_acq-<label>]_photo.tif

Legend:

• For more information about filename elements (for example, entities, suffixes, extensions), follow the links embedded in the filename template.

• Filename entities or directories between square brackets (for example, [_ses-<label>]) are OPTIONAL.

• Some entities may only allow specific values, in which case those values are listed in <>, separated by |.

• _<suffix> means that there are several (>6) valid suffixes for this filename pattern.

• .<extension> means that there are several (>6) valid extensions for this file type.

• [.gz] means that both the unzipped and gzipped versions of the extension are valid.

Photos of the anatomical landmarks and/or head localization coils on the subject's head are RECOMMENDED. If the coils are not placed at the location of actual anatomical landmarks, these latter may be marked with a piece of felt-tip taped to the skin. Please note that the photos may need to be cropped or blurred to conceal identifying features prior to sharing, depending on the terms of the consent given by the participant.

The acq-<label> entity can be used to indicate acquisition of different photos of the same face (or other body part in different angles to show, for example, the location of the nasion (NAS) as opposed to the right periauricular point (RPA)).

Example *_photo.<extension>

Example of the NAS fiducial placed between the eyebrows, rather than at the actual anatomical nasion: sub-0001_ses-001_acq-NAS_photo.jpg

Head shape and electrode description (*_headshape.<extension>)

Template:

sub-<label>/
    [ses-<label>/]
        meg/
            sub-<label>[_ses-<label>][_acq-<label>]_headshape.*
            sub-<label>[_ses-<label>][_acq-<label>]_headshape.pos

Legend:

• For more information about filename elements (for example, entities, suffixes, extensions), follow the links embedded in the filename template.

• Filename entities or directories between square brackets (for example, [_ses-<label>]) are OPTIONAL.

• Some entities may only allow specific values, in which case those values are listed in <>, separated by |.

• _<suffix> means that there are several (>6) valid suffixes for this filename pattern.

• .<extension> means that there are several (>6) valid extensions for this file type.

• [.gz] means that both the unzipped and gzipped versions of the extension are valid.

This file is RECOMMENDED.

The 3-D locations of points that describe the head shape and/or EEG electrode locations can be digitized and stored in separate files. The acq-<label> entity can be used when more than one type of digitization in done for a session, for example when the head points are in a separate file from the EEG locations. These files are stored in the specific format of the 3-D digitizer's manufacturer (see the MEG File Formats Appendix).

For example:

└─ sub-control01/
   └─ ses-01/
      ├─ sub-control01_ses-01_acq-HEAD_headshape.pos 
      └─ sub-control01_ses-01_acq-EEG_headshape.pos 

Note that the *_headshape file(s) is shared by all the runs and tasks in a session. If the subject needs to be taken out of the scanner and the head-shape has to be updated, then for MEG it could be considered to be a new session.

Empty-room MEG recordings

Empty-room MEG recordings capture the environmental and recording system's noise.

It is RECOMMENDED to explicitly specify which empty-room recording should be used with which experimental run(s) or session(s). This can be done via the AssociatedEmptyRoom field in the *_meg.json sidecar files.

Empty-room recordings may be collected once per day, where a single empty-room recording may be shared between multiple subjects and/or sessions (see Example 1). Empty-room recordings may also be collected for each individual experimental session (see Example 2). In either case, the label for the task-<label> entity in the empty-room recording SHOULD be set to noise.

Example 1

One empty-room recording per day, applying to all subjects for that day.

In the case of empty-room recordings being associated with multiple subjects and/or sessions, it is RECOMMENDED to store the empty-room recording inside a subject directory named sub-emptyroom. If a session-<label> entity is present, its label SHOULD be the date of the empty-room recording in the format YYYYMMDD, that is ses-YYYYMMDD. The scans.tsv file containing the date and time of the acquisition SHOULD also be included. The rationale is that this naming scheme will allow users to easily retrieve the empty-room recording that best matches a particular experimental session, based on date and time of the recording. It should be possible to query empty-room recordings just like usual subject recordings, hence all metadata sidecar files (such as the channels.tsv) file SHOULD be present as well.

├─ sub-control01/
├─ sub-control02/
└─ sub-emptyroom/
   └─ ses-20170801/
      ├─ sub-emptyroom_ses-20170801_scans.tsv 
      └─ meg/
         ├─ sub-emptyroom_ses-20170801_task-noise_meg.ds 
         ├─ sub-emptyroom_ses-20170801_task-noise_meg.json 
         └─ sub-emptyroom_ses-20170801_task-noise_channels.tsv 

Example 2

One empty-room recording per each participant's session, stored within the session directory.

In the case of empty-room recordings being collected for the individual experimental session, it is RECOMMENDED to store the empty-room recording along with that subject and session.

└─ sub-control01/
   └─ ses-01/
      ├─ sub-01_ses-01_scans.tsv 
      └─ meg/
         ├─ sub-control01_ses-01_task-rest_meg.ds 
         ├─ sub-control01_ses-01_task-rest_meg.json 
         ├─ sub-control01_ses-01_task-rest_channels.tsv 
         ├─ sub-control01_ses-01_task-noise_meg.ds 
         ├─ sub-control01_ses-01_task-noise_meg.json 
         └─ sub-control01_ses-01_task-noise_channels.tsv