Version 2.9.0-alpha Jun 20, 2025
1. Format Overview
1.1. Namespace – NWB core
Description: NWB namespace
Name: core
Full Name: NWB core
Version: 2.8.0
- Authors:
Andrew Tritt
Oliver Ruebel
Ryan Ly
Ben Dichter
Keith Godfrey
Jeff Teeters
- Schema:
namespace: hdmf-common
doc: This source module contains base data types used throughout the NWB data format.
source: nwb.base.yaml
title: Base data types
doc: This source module contains neurodata_types for device data.
source: nwb.device.yaml
title: Devices
doc: This source module contains neurodata_types for epoch data.
source: nwb.epoch.yaml
title: Epochs
doc: This source module contains neurodata_types for image data.
source: nwb.image.yaml
title: Image data
doc: Main NWB file specification.
source: nwb.file.yaml
title: NWB file
doc: Miscellaneous types.
source: nwb.misc.yaml
title: Miscellaneous neurodata_types.
doc: This source module contains neurodata_types for behavior data.
source: nwb.behavior.yaml
title: Behavior
doc: This source module contains neurodata_types for extracellular electrophysiology data.
source: nwb.ecephys.yaml
title: Extracellular electrophysiology
doc: This source module contains neurodata_types for intracellular electrophysiology data.
source: nwb.icephys.yaml
title: Intracellular electrophysiology
doc: This source module contains neurodata_types for opto-genetics data.
source: nwb.ogen.yaml
title: Optogenetics
doc: This source module contains neurodata_types for optical physiology data.
source: nwb.ophys.yaml
title: Optical physiology
doc: This source module contains neurodata_type for retinotopy data.
source: nwb.retinotopy.yaml
title: Retinotopy
1.2. Type Hierarchy
2. Type Specifications
2.1. Base data types
This source module contains base data types used throughout the NWB data format.
2.1.1. NWBData
Overview: An abstract data type for a dataset.
NWBData
extends Data
and includes all elements of Data with the following additions or changes.
Extends: Data
Primitive Type: Dataset
Inherits from: Data
Subtypes: ScratchData, RGBImage, Image, RGBAImage, GrayscaleImage, ImageReferences
Source filename: nwb.base.yaml
Source Specification: see Section 3.2.1
2.1.2. TimeSeriesReferenceVectorData
Overview: Column storing references to a TimeSeries (rows). For each TimeSeries this VectorData column stores the start_index and count to indicate the range in time to be selected as well as an object reference to the TimeSeries.
TimeSeriesReferenceVectorData
extends VectorData
and includes all elements of VectorData with the following additions or changes.
Extends: VectorData
Primitive Type: Dataset
- Data Type: Compound data type with the following elements:
idx_start: Start index into the TimeSeries ‘data’ and ‘timestamp’ datasets of the referenced TimeSeries. The first dimension of those arrays is always time. (dtype= int32 )
count: Number of data samples available in this time series, during this epoch (dtype= int32 )
timeseries: The TimeSeries that this index applies to (dtype= object reference to TimeSeries )
Default Name: timeseries
Inherits from: VectorData, Data
Source filename: nwb.base.yaml
Source Specification: see Section 3.2.2
Id |
Type |
Description |
---|---|---|
<TimeSeriesReferenceVectorData> |
Dataset |
Top level Dataset for <TimeSeriesReferenceVectorData>
|
—description |
Attribute |
Description of what these vectors represent.
|
2.1.3. Image
Overview: An abstract data type for an image. Shape can be 2-D (x, y), or 3-D where the third dimension can have three or four elements, e.g. (x, y, (r, g, b)) or (x, y, (r, g, b, a)).
Image
extends NWBData
and includes all elements of NWBData with the following additions or changes.
Extends: NWBData
Primitive Type: Dataset
Data Type: numeric
Dimensions: [[‘x’, ‘y’], [‘x’, ‘y’, ‘r, g, b’], [‘x’, ‘y’, ‘r, g, b, a’]]
Shape: [[None, None], [None, None, 3], [None, None, 4]]
Subtypes: RGBImage, GrayscaleImage, RGBAImage
Source filename: nwb.base.yaml
Source Specification: see Section 3.2.3

Id |
Type |
Description |
---|---|---|
<Image> |
Dataset |
Top level Dataset for <Image>
|
—resolution |
Attribute |
Pixel resolution of the image, in pixels per centimeter.
|
—description |
Attribute |
Description of the image.
|
2.1.4. ImageReferences
Overview: Ordered dataset of references to Image objects.
ImageReferences
extends NWBData
and includes all elements of NWBData with the following additions or changes.
Extends: NWBData
Primitive Type: Dataset
Data Type: object reference to Image
Dimensions: [‘num_images’]
Shape: [None]
Source filename: nwb.base.yaml
Source Specification: see Section 3.2.4
2.1.5. NWBContainer
Overview: An abstract data type for a generic container storing collections of data and metadata. Base type for all data and metadata containers.
NWBContainer
extends Container
and includes all elements of Container with the following additions or changes.
Extends: Container
Primitive Type: Group
Inherits from: Container
Subtypes: FeatureExtraction, LFP, OpticalChannel, Fluorescence, IntervalSeries, TimeSeries, CurrentClampStimulusSeries, ProcessingModule, EyeTracking, CurrentClampSeries, ImagingPlane, NWBFile, BehavioralEvents, IntracellularElectrode, NWBDataInterface, CorrectedImageStack, IndexSeries, ElectrodeGroup, MotionCorrection, AbstractFeatureSeries, Clustering, EventDetection, FilteredEphys, OpticalSeries, ImageMaskSeries, VoltageClampSeries, OptogeneticSeries, IZeroClampSeries, Images, ImagingRetinotopy, Device, OnePhotonSeries, DecompositionSeries, BehavioralEpochs, VoltageClampStimulusSeries, ImageSegmentation, OptogeneticStimulusSite, SpikeEventSeries, Position, LabMetaData, ClusterWaveforms, DfOverF, TwoPhotonSeries, ElectricalSeries, RoiResponseSeries, ImageSeries, CompassDirection, EventWaveform, Subject, BehavioralTimeSeries, SpatialSeries, PupilTracking, PatchClampSeries, AnnotationSeries
Source filename: nwb.base.yaml
Source Specification: see Section 3.2.5
2.1.6. NWBDataInterface
Overview: An abstract data type for a generic container storing collections of data, as opposed to metadata.
NWBDataInterface
extends NWBContainer
and includes all elements of NWBContainer with the following additions or changes.
Extends: NWBContainer
Primitive Type: Group
Inherits from: NWBContainer, Container
Subtypes: FeatureExtraction, LFP, Fluorescence, IntervalSeries, TimeSeries, CurrentClampStimulusSeries, EyeTracking, CurrentClampSeries, BehavioralEvents, CorrectedImageStack, IndexSeries, MotionCorrection, AbstractFeatureSeries, Clustering, EventDetection, FilteredEphys, OpticalSeries, ImageMaskSeries, VoltageClampSeries, OptogeneticSeries, IZeroClampSeries, Images, ImagingRetinotopy, OnePhotonSeries, DecompositionSeries, BehavioralEpochs, VoltageClampStimulusSeries, ImageSegmentation, SpikeEventSeries, Position, ClusterWaveforms, DfOverF, TwoPhotonSeries, ElectricalSeries, RoiResponseSeries, ImageSeries, CompassDirection, EventWaveform, BehavioralTimeSeries, SpatialSeries, PupilTracking, PatchClampSeries, AnnotationSeries
Source filename: nwb.base.yaml
Source Specification: see Section 3.2.6
2.1.7. TimeSeries
Overview: General purpose time series.
TimeSeries
extends NWBDataInterface
and includes all elements of NWBDataInterface with the following additions or changes.
Extends: NWBDataInterface
Primitive Type: Group
Inherits from: NWBDataInterface, NWBContainer, Container
Subtypes: IntervalSeries, CurrentClampStimulusSeries, CurrentClampSeries, IndexSeries, AbstractFeatureSeries, OpticalSeries, ImageMaskSeries, VoltageClampSeries, IZeroClampSeries, OptogeneticSeries, OnePhotonSeries, DecompositionSeries, VoltageClampStimulusSeries, SpikeEventSeries, TwoPhotonSeries, ElectricalSeries, RoiResponseSeries, ImageSeries, SpatialSeries, PatchClampSeries, AnnotationSeries
Source filename: nwb.base.yaml
Source Specification: see Section 3.2.7

Id |
Type |
Description |
---|---|---|
<TimeSeries> |
Group |
Top level Group for <TimeSeries>
|
—description |
Attribute |
Description of the time series.
|
—comments |
Attribute |
Human-readable comments about the TimeSeries. This second descriptive field can be used to store additional information, or descriptive information if the primary description field is populated with a computer-readable string.
|
—data |
Dataset |
Data values. Data can be in 1-D, 2-D, 3-D, or 4-D. The first dimension should always represent time. This can also be used to store binary data (e.g., image frames). This can also be a link to data stored in an external file.
|
——conversion |
Attribute |
Scalar to multiply each element in data to convert it to the specified ‘unit’. If the data are stored in acquisition system units or other units that require a conversion to be interpretable, multiply the data by ‘conversion’ to convert the data to the specified ‘unit’. e.g. if the data acquisition system stores values in this object as signed 16-bit integers (int16 range -32,768 to 32,767) that correspond to a 5V range (-2.5V to 2.5V), and the data acquisition system gain is 8000X, then the ‘conversion’ multiplier to get from raw data acquisition values to recorded volts is 2.5/32768/8000 = 9.5367e-9.
|
——offset |
Attribute |
Scalar to add to the data after scaling by ‘conversion’ to finalize its coercion to the specified ‘unit’. Two common examples of this include (a) data stored in an unsigned type that requires a shift after scaling to re-center the data, and (b) specialized recording devices that naturally cause a scalar offset with respect to the true units.
|
——resolution |
Attribute |
Smallest meaningful difference between values in data, stored in the specified by unit, e.g., the change in value of the least significant bit, or a larger number if signal noise is known to be present. If unknown, use -1.0.
|
——unit |
Attribute |
Base unit of measurement for working with the data. Actual stored values are not necessarily stored in these units. To access the data in these units, multiply ‘data’ by ‘conversion’ and add ‘offset’.
|
——continuity |
Attribute |
Optionally describe the continuity of the data. Can be “continuous”, “instantaneous”, or “step”. For example, a voltage trace would be “continuous”, because samples are recorded from a continuous process. An array of lick times would be “instantaneous”, because the data represents distinct moments in time. Times of image presentations would be “step” because the picture remains the same until the next timepoint. This field is optional, but is useful in providing information about the underlying data. It may inform the way this data is interpreted, the way it is visualized, and what analysis methods are applicable.
|
—starting_time |
Dataset |
Timestamp of the first sample in seconds. When timestamps are uniformly spaced, the timestamp of the first sample can be specified and all subsequent ones calculated from the sampling rate attribute.
|
——rate |
Attribute |
Sampling rate, in Hz.
|
——unit |
Attribute |
Unit of measurement for time, which is fixed to ‘seconds’.
|
—timestamps |
Dataset |
Timestamps for samples stored in data, in seconds, relative to the common experiment master-clock stored in NWBFile.timestamps_reference_time.
|
——interval |
Attribute |
Value is ‘1’
|
——unit |
Attribute |
Unit of measurement for timestamps, which is fixed to ‘seconds’.
|
—control |
Dataset |
Numerical labels that apply to each time point in data for the purpose of querying and slicing data by these values. If present, the length of this array should be the same size as the first dimension of data.
|
—control_description |
Dataset |
Description of each control value. Must be present if control is present. If present, control_description[0] should describe time points where control == 0.
|
Id |
Type |
Description |
---|---|---|
<TimeSeries> |
Group |
Top level Group for <TimeSeries>
|
—sync |
Group |
Lab-specific time and sync information as provided directly from hardware devices and that is necessary for aligning all acquired time information to a common timebase. The timestamp array stores time in the common timebase. This group will usually only be populated in TimeSeries that are stored external to the NWB file, in files storing raw data. Once timestamp data is calculated, the contents of ‘sync’ are mostly for archival purposes.
|
2.1.7.1. Groups: sync
Lab-specific time and sync information as provided directly from hardware devices and that is necessary for aligning all acquired time information to a common timebase. The timestamp array stores time in the common timebase. This group will usually only be populated in TimeSeries that are stored external to the NWB file, in files storing raw data. Once timestamp data is calculated, the contents of ‘sync’ are mostly for archival purposes.
Quantity: 0 or 1
Name: sync
2.1.8. ProcessingModule
Overview: A collection of processed data.
ProcessingModule
extends NWBContainer
and includes all elements of NWBContainer with the following additions or changes.
Extends: NWBContainer
Primitive Type: Group
Inherits from: NWBContainer, Container
Source filename: nwb.base.yaml
Source Specification: see Section 3.2.8

Id |
Type |
Description |
---|---|---|
<ProcessingModule> |
Group |
Top level Group for <ProcessingModule>
|
—description |
Attribute |
Description of this collection of processed data.
|
Id |
Type |
Description |
---|---|---|
<ProcessingModule> |
Group |
Top level Group for <ProcessingModule>
|
Group |
Data objects stored in this collection.
|
|
—<DynamicTable> |
Group |
Tables stored in this collection.
|
2.1.8.1. Groups: <NWBDataInterface>
Data objects stored in this collection.
Extends: NWBDataInterface
Quantity: 0 or more
2.1.8.2. Groups: <DynamicTable>
Tables stored in this collection.
Extends: DynamicTable
Quantity: 0 or more
2.1.9. Images
Overview: A collection of images with an optional way to specify the order of the images using the “order_of_images” dataset. An order must be specified if the images are referenced by index, e.g., from an IndexSeries.
Images
extends NWBDataInterface
and includes all elements of NWBDataInterface with the following additions or changes.
Extends: NWBDataInterface
Primitive Type: Group
Default Name: Images
Inherits from: NWBDataInterface, NWBContainer, Container
Source filename: nwb.base.yaml
Source Specification: see Section 3.2.9

Id |
Type |
Description |
---|---|---|
<Images> |
Group |
Top level Group for <Images>
|
—description |
Attribute |
Description of this collection of images.
|
—<Image> |
Dataset |
Images stored in this collection.
|
—order_of_images |
Dataset |
Ordered dataset of references to Image objects stored in the parent group. Each Image object in the Images group should be stored once and only once, so the dataset should have the same length as the number of images.
|
2.2. Devices
This source module contains neurodata_types for device data.
2.2.1. Device
Overview: Metadata about a data acquisition device, e.g., recording system, electrode, microscope.
Device
extends NWBContainer
and includes all elements of NWBContainer with the following additions or changes.
Extends: NWBContainer
Primitive Type: Group
Inherits from: NWBContainer, Container
Source filename: nwb.device.yaml
Source Specification: see Section 3.3.1

Id |
Type |
Description |
---|---|---|
<Device> |
Group |
Top level Group for <Device>
|
—description |
Attribute |
Description of the device as free-form text. If there is any software/firmware associated with the device, the names and versions of those can be added to NWBFile.was_generated_by.
|
—manufacturer |
Attribute |
The name of the manufacturer of the device, e.g., Imec, Plexon, Thorlabs.
|
—model_number |
Attribute |
The model number (or part/product number) of the device, e.g., PRB_1_4_0480_1, PLX-VP-32-15SE(75)-(260-80)(460-10)-300-(1)CON/32m-V, BERGAMO.
|
—model_name |
Attribute |
The model name of the device, e.g., Neuropixels 1.0, V-Probe, Bergamo III.
|
—serial_number |
Attribute |
The serial number of the device.
|
2.3. Epochs
This source module contains neurodata_types for epoch data.
2.3.1. TimeIntervals
Overview: A container for aggregating epoch data and the TimeSeries that each epoch applies to.
TimeIntervals
extends DynamicTable
and includes all elements of DynamicTable with the following additions or changes.
Extends: DynamicTable
Primitive Type: Group
Inherits from: DynamicTable, Container
Source filename: nwb.epoch.yaml
Source Specification: see Section 3.4.1

Id |
Type |
Description |
---|---|---|
<TimeIntervals> |
Group |
Top level Group for <TimeIntervals>
|
—colnames |
Attribute |
The names of the columns in this table. This should be used to specify an order to the columns.
|
—description |
Attribute |
Description of what is in this dynamic table.
|
—start_time |
Dataset |
Start time of epoch, in seconds.
|
—stop_time |
Dataset |
Stop time of epoch, in seconds.
|
—tags |
Dataset |
User-defined tags that identify or categorize events.
|
—tags_index |
Dataset |
Index for tags.
|
—timeseries |
Dataset |
An index into a TimeSeries object.
|
—timeseries_index |
Dataset |
Index for timeseries.
|
—id |
Dataset |
Array of unique identifiers for the rows of this dynamic table.
|
—<VectorData> |
Dataset |
Vector columns, including index columns, of this dynamic table.
|
2.4. Image data
This source module contains neurodata_types for image data.
2.4.1. GrayscaleImage
Overview: A grayscale image.
GrayscaleImage
extends Image
and includes all elements of Image with the following additions or changes.
Extends: Image
Primitive Type: Dataset
Data Type: numeric
Dimensions: [‘x’, ‘y’]
Shape: [None, None]
Source filename: nwb.image.yaml
Source Specification: see Section 3.5.1

Id |
Type |
Description |
---|---|---|
<GrayscaleImage> |
Dataset |
Top level Dataset for <GrayscaleImage>
|
—resolution |
Attribute |
Pixel resolution of the image, in pixels per centimeter.
|
—description |
Attribute |
Description of the image.
|
2.4.2. RGBImage
Overview: A color image.
RGBImage
extends Image
and includes all elements of Image with the following additions or changes.
Extends: Image
Primitive Type: Dataset
Data Type: numeric
Dimensions: [‘x’, ‘y’, ‘r, g, b’]
Shape: [None, None, 3]
Source filename: nwb.image.yaml
Source Specification: see Section 3.5.2

Id |
Type |
Description |
---|---|---|
<RGBImage> |
Dataset |
Top level Dataset for <RGBImage>
|
—resolution |
Attribute |
Pixel resolution of the image, in pixels per centimeter.
|
—description |
Attribute |
Description of the image.
|
2.4.3. RGBAImage
Overview: A color image with transparency.
RGBAImage
extends Image
and includes all elements of Image with the following additions or changes.
Extends: Image
Primitive Type: Dataset
Data Type: numeric
Dimensions: [‘x’, ‘y’, ‘r, g, b, a’]
Shape: [None, None, 4]
Source filename: nwb.image.yaml
Source Specification: see Section 3.5.3

Id |
Type |
Description |
---|---|---|
<RGBAImage> |
Dataset |
Top level Dataset for <RGBAImage>
|
—resolution |
Attribute |
Pixel resolution of the image, in pixels per centimeter.
|
—description |
Attribute |
Description of the image.
|
2.4.4. ImageSeries
Overview: General image data that is common between acquisition and stimulus time series. Sometimes the image data is stored in the file in a raw format while other times it will be stored as a series of external image files in the host file system. The data field will either be binary data, if the data is stored in the NWB file, or empty, if the data is stored in an external image stack. [frame][x][y] or [frame][x][y][z].
ImageSeries
extends TimeSeries
and includes all elements of TimeSeries with the following additions or changes.
Extends: TimeSeries
Primitive Type: Group
Inherits from: TimeSeries, NWBDataInterface, NWBContainer, Container
Subtypes: OpticalSeries, OnePhotonSeries, ImageMaskSeries, TwoPhotonSeries
Source filename: nwb.image.yaml
Source Specification: see Section 3.5.4

Id |
Type |
Description |
---|---|---|
<ImageSeries> |
Group |
Top level Group for <ImageSeries>
|
—description |
Attribute |
Description of the time series.
|
—comments |
Attribute |
Human-readable comments about the TimeSeries. This second descriptive field can be used to store additional information, or descriptive information if the primary description field is populated with a computer-readable string.
|
—data |
Dataset |
Binary data representing images across frames. If data are stored in an external file, this should be an empty 3D array.
|
——conversion |
Attribute |
Scalar to multiply each element in data to convert it to the specified ‘unit’. If the data are stored in acquisition system units or other units that require a conversion to be interpretable, multiply the data by ‘conversion’ to convert the data to the specified ‘unit’. e.g. if the data acquisition system stores values in this object as signed 16-bit integers (int16 range -32,768 to 32,767) that correspond to a 5V range (-2.5V to 2.5V), and the data acquisition system gain is 8000X, then the ‘conversion’ multiplier to get from raw data acquisition values to recorded volts is 2.5/32768/8000 = 9.5367e-9.
|
——offset |
Attribute |
Scalar to add to the data after scaling by ‘conversion’ to finalize its coercion to the specified ‘unit’. Two common examples of this include (a) data stored in an unsigned type that requires a shift after scaling to re-center the data, and (b) specialized recording devices that naturally cause a scalar offset with respect to the true units.
|
——resolution |
Attribute |
Smallest meaningful difference between values in data, stored in the specified by unit, e.g., the change in value of the least significant bit, or a larger number if signal noise is known to be present. If unknown, use -1.0.
|
——unit |
Attribute |
Base unit of measurement for working with the data. Actual stored values are not necessarily stored in these units. To access the data in these units, multiply ‘data’ by ‘conversion’ and add ‘offset’.
|
——continuity |
Attribute |
Optionally describe the continuity of the data. Can be “continuous”, “instantaneous”, or “step”. For example, a voltage trace would be “continuous”, because samples are recorded from a continuous process. An array of lick times would be “instantaneous”, because the data represents distinct moments in time. Times of image presentations would be “step” because the picture remains the same until the next timepoint. This field is optional, but is useful in providing information about the underlying data. It may inform the way this data is interpreted, the way it is visualized, and what analysis methods are applicable.
|
—dimension |
Dataset |
Number of pixels on x, y, (and z) axes.
|
—external_file |
Dataset |
Paths to one or more external file(s). The field is only present if format=’external’. This is only relevant if the image series is stored in the file system as one or more image file(s). This field should NOT be used if the image is stored in another NWB file and that file is linked to this file.
|
——starting_frame |
Attribute |
Each external image may contain one or more consecutive frames of the full ImageSeries. This attribute serves as an index to indicate which frames each file contains, to facilitate random access. The ‘starting_frame’ attribute, hence, contains a list of frame numbers within the full ImageSeries of the first frame of each file listed in the parent ‘external_file’ dataset. Zero-based indexing is used (hence, the first element will always be zero). For example, if the ‘external_file’ dataset has three paths to files and the first file has 5 frames, the second file has 10 frames, and the third file has 20 frames, then this attribute will have values [0, 5, 15]. If there is a single external file that holds all of the frames of the ImageSeries (and so there is a single element in the ‘external_file’ dataset), then this attribute should have value [0].
|
—format |
Dataset |
Format of image. If this is ‘external’, then the attribute ‘external_file’ contains the path information to the image files. If this is ‘raw’, then the raw (single-channel) binary data is stored in the ‘data’ dataset. If this attribute is not present, then the default format=’raw’ case is assumed.
|
—starting_time |
Dataset |
Timestamp of the first sample in seconds. When timestamps are uniformly spaced, the timestamp of the first sample can be specified and all subsequent ones calculated from the sampling rate attribute.
|
——rate |
Attribute |
Sampling rate, in Hz.
|
——unit |
Attribute |
Unit of measurement for time, which is fixed to ‘seconds’.
|
—timestamps |
Dataset |
Timestamps for samples stored in data, in seconds, relative to the common experiment master-clock stored in NWBFile.timestamps_reference_time.
|
——interval |
Attribute |
Value is ‘1’
|
——unit |
Attribute |
Unit of measurement for timestamps, which is fixed to ‘seconds’.
|
—control |
Dataset |
Numerical labels that apply to each time point in data for the purpose of querying and slicing data by these values. If present, the length of this array should be the same size as the first dimension of data.
|
—control_description |
Dataset |
Description of each control value. Must be present if control is present. If present, control_description[0] should describe time points where control == 0.
|
—device |
Link |
Link to the Device object that was used to capture these images.
|
Id |
Type |
Description |
---|---|---|
<ImageSeries> |
Group |
Top level Group for <ImageSeries>
|
—device |
Link |
Link to the Device object that was used to capture these images.
|
—sync |
Group |
Lab-specific time and sync information as provided directly from hardware devices and that is necessary for aligning all acquired time information to a common timebase. The timestamp array stores time in the common timebase. This group will usually only be populated in TimeSeries that are stored external to the NWB file, in files storing raw data. Once timestamp data is calculated, the contents of ‘sync’ are mostly for archival purposes.
|
2.4.4.1. Groups: sync
Lab-specific time and sync information as provided directly from hardware devices and that is necessary for aligning all acquired time information to a common timebase. The timestamp array stores time in the common timebase. This group will usually only be populated in TimeSeries that are stored external to the NWB file, in files storing raw data. Once timestamp data is calculated, the contents of ‘sync’ are mostly for archival purposes.
Quantity: 0 or 1
Name: sync
2.4.5. ImageMaskSeries
Overview: DEPRECATED. An alpha mask that is applied to a presented visual stimulus. The ‘data’ array contains an array of mask values that are applied to the displayed image. Mask values are stored as RGBA. Mask can vary with time. The timestamps array indicates the starting time of a mask, and that mask pattern continues until it’s explicitly changed.
ImageMaskSeries
extends ImageSeries
and includes all elements of ImageSeries with the following additions or changes.
Extends: ImageSeries
Primitive Type: Group
Inherits from: ImageSeries, TimeSeries, NWBDataInterface, NWBContainer, Container
Source filename: nwb.image.yaml
Source Specification: see Section 3.5.5

Id |
Type |
Description |
---|---|---|
<ImageMaskSeries> |
Group |
Top level Group for <ImageMaskSeries>
|
—description |
Attribute |
Description of the time series.
|
—comments |
Attribute |
Human-readable comments about the TimeSeries. This second descriptive field can be used to store additional information, or descriptive information if the primary description field is populated with a computer-readable string.
|
—data |
Dataset |
Binary data representing images across frames. If data are stored in an external file, this should be an empty 3D array.
|
——conversion |
Attribute |
Scalar to multiply each element in data to convert it to the specified ‘unit’. If the data are stored in acquisition system units or other units that require a conversion to be interpretable, multiply the data by ‘conversion’ to convert the data to the specified ‘unit’. e.g. if the data acquisition system stores values in this object as signed 16-bit integers (int16 range -32,768 to 32,767) that correspond to a 5V range (-2.5V to 2.5V), and the data acquisition system gain is 8000X, then the ‘conversion’ multiplier to get from raw data acquisition values to recorded volts is 2.5/32768/8000 = 9.5367e-9.
|
——offset |
Attribute |
Scalar to add to the data after scaling by ‘conversion’ to finalize its coercion to the specified ‘unit’. Two common examples of this include (a) data stored in an unsigned type that requires a shift after scaling to re-center the data, and (b) specialized recording devices that naturally cause a scalar offset with respect to the true units.
|
——resolution |
Attribute |
Smallest meaningful difference between values in data, stored in the specified by unit, e.g., the change in value of the least significant bit, or a larger number if signal noise is known to be present. If unknown, use -1.0.
|
——unit |
Attribute |
Base unit of measurement for working with the data. Actual stored values are not necessarily stored in these units. To access the data in these units, multiply ‘data’ by ‘conversion’ and add ‘offset’.
|
——continuity |
Attribute |
Optionally describe the continuity of the data. Can be “continuous”, “instantaneous”, or “step”. For example, a voltage trace would be “continuous”, because samples are recorded from a continuous process. An array of lick times would be “instantaneous”, because the data represents distinct moments in time. Times of image presentations would be “step” because the picture remains the same until the next timepoint. This field is optional, but is useful in providing information about the underlying data. It may inform the way this data is interpreted, the way it is visualized, and what analysis methods are applicable.
|
—dimension |
Dataset |
Number of pixels on x, y, (and z) axes.
|
—external_file |
Dataset |
Paths to one or more external file(s). The field is only present if format=’external’. This is only relevant if the image series is stored in the file system as one or more image file(s). This field should NOT be used if the image is stored in another NWB file and that file is linked to this file.
|
——starting_frame |
Attribute |
Each external image may contain one or more consecutive frames of the full ImageSeries. This attribute serves as an index to indicate which frames each file contains, to facilitate random access. The ‘starting_frame’ attribute, hence, contains a list of frame numbers within the full ImageSeries of the first frame of each file listed in the parent ‘external_file’ dataset. Zero-based indexing is used (hence, the first element will always be zero). For example, if the ‘external_file’ dataset has three paths to files and the first file has 5 frames, the second file has 10 frames, and the third file has 20 frames, then this attribute will have values [0, 5, 15]. If there is a single external file that holds all of the frames of the ImageSeries (and so there is a single element in the ‘external_file’ dataset), then this attribute should have value [0].
|
—format |
Dataset |
Format of image. If this is ‘external’, then the attribute ‘external_file’ contains the path information to the image files. If this is ‘raw’, then the raw (single-channel) binary data is stored in the ‘data’ dataset. If this attribute is not present, then the default format=’raw’ case is assumed.
|
—starting_time |
Dataset |
Timestamp of the first sample in seconds. When timestamps are uniformly spaced, the timestamp of the first sample can be specified and all subsequent ones calculated from the sampling rate attribute.
|
——rate |
Attribute |
Sampling rate, in Hz.
|
——unit |
Attribute |
Unit of measurement for time, which is fixed to ‘seconds’.
|
—timestamps |
Dataset |
Timestamps for samples stored in data, in seconds, relative to the common experiment master-clock stored in NWBFile.timestamps_reference_time.
|
——interval |
Attribute |
Value is ‘1’
|
——unit |
Attribute |
Unit of measurement for timestamps, which is fixed to ‘seconds’.
|
—control |
Dataset |
Numerical labels that apply to each time point in data for the purpose of querying and slicing data by these values. If present, the length of this array should be the same size as the first dimension of data.
|
—control_description |
Dataset |
Description of each control value. Must be present if control is present. If present, control_description[0] should describe time points where control == 0.
|
—masked_imageseries |
Link |
Link to ImageSeries object that this image mask is applied to.
|
—device |
Link |
Link to the Device object that was used to capture these images.
|
Id |
Type |
Description |
---|---|---|
<ImageMaskSeries> |
Group |
Top level Group for <ImageMaskSeries>
|
—masked_imageseries |
Link |
Link to ImageSeries object that this image mask is applied to.
|
—device |
Link |
Link to the Device object that was used to capture these images.
|
—sync |
Group |
Lab-specific time and sync information as provided directly from hardware devices and that is necessary for aligning all acquired time information to a common timebase. The timestamp array stores time in the common timebase. This group will usually only be populated in TimeSeries that are stored external to the NWB file, in files storing raw data. Once timestamp data is calculated, the contents of ‘sync’ are mostly for archival purposes.
|
2.4.5.1. Groups: sync
Lab-specific time and sync information as provided directly from hardware devices and that is necessary for aligning all acquired time information to a common timebase. The timestamp array stores time in the common timebase. This group will usually only be populated in TimeSeries that are stored external to the NWB file, in files storing raw data. Once timestamp data is calculated, the contents of ‘sync’ are mostly for archival purposes.
Quantity: 0 or 1
Name: sync
2.4.6. OpticalSeries
Overview: Image data that is presented or recorded. A stimulus template movie will be stored only as an image. When the image is presented as stimulus, additional data is required, such as field of view (e.g., how much of the visual field the image covers, or how what is the area of the target being imaged). If the OpticalSeries represents acquired imaging data, orientation is also important.
OpticalSeries
extends ImageSeries
and includes all elements of ImageSeries with the following additions or changes.
Extends: ImageSeries
Primitive Type: Group
Inherits from: ImageSeries, TimeSeries, NWBDataInterface, NWBContainer, Container
Source filename: nwb.image.yaml
Source Specification: see Section 3.5.6

Id |
Type |
Description |
---|---|---|
<OpticalSeries> |
Group |
Top level Group for <OpticalSeries>
|
—description |
Attribute |
Description of the time series.
|
—comments |
Attribute |
Human-readable comments about the TimeSeries. This second descriptive field can be used to store additional information, or descriptive information if the primary description field is populated with a computer-readable string.
|
—distance |
Dataset |
Distance from camera/monitor to target/eye.
|
—field_of_view |
Dataset |
Width, height and depth of image, or imaged area, in meters.
|
—data |
Dataset |
Images presented to subject, either grayscale or RGB
|
——conversion |
Attribute |
Scalar to multiply each element in data to convert it to the specified ‘unit’. If the data are stored in acquisition system units or other units that require a conversion to be interpretable, multiply the data by ‘conversion’ to convert the data to the specified ‘unit’. e.g. if the data acquisition system stores values in this object as signed 16-bit integers (int16 range -32,768 to 32,767) that correspond to a 5V range (-2.5V to 2.5V), and the data acquisition system gain is 8000X, then the ‘conversion’ multiplier to get from raw data acquisition values to recorded volts is 2.5/32768/8000 = 9.5367e-9.
|
——offset |
Attribute |
Scalar to add to the data after scaling by ‘conversion’ to finalize its coercion to the specified ‘unit’. Two common examples of this include (a) data stored in an unsigned type that requires a shift after scaling to re-center the data, and (b) specialized recording devices that naturally cause a scalar offset with respect to the true units.
|
——resolution |
Attribute |
Smallest meaningful difference between values in data, stored in the specified by unit, e.g., the change in value of the least significant bit, or a larger number if signal noise is known to be present. If unknown, use -1.0.
|
——unit |
Attribute |
Base unit of measurement for working with the data. Actual stored values are not necessarily stored in these units. To access the data in these units, multiply ‘data’ by ‘conversion’ and add ‘offset’.
|
——continuity |
Attribute |
Optionally describe the continuity of the data. Can be “continuous”, “instantaneous”, or “step”. For example, a voltage trace would be “continuous”, because samples are recorded from a continuous process. An array of lick times would be “instantaneous”, because the data represents distinct moments in time. Times of image presentations would be “step” because the picture remains the same until the next timepoint. This field is optional, but is useful in providing information about the underlying data. It may inform the way this data is interpreted, the way it is visualized, and what analysis methods are applicable.
|
—orientation |
Dataset |
Description of image relative to some reference frame (e.g., which way is up). Must also specify frame of reference.
|
—dimension |
Dataset |
Number of pixels on x, y, (and z) axes.
|
—external_file |
Dataset |
Paths to one or more external file(s). The field is only present if format=’external’. This is only relevant if the image series is stored in the file system as one or more image file(s). This field should NOT be used if the image is stored in another NWB file and that file is linked to this file.
|
——starting_frame |
Attribute |
Each external image may contain one or more consecutive frames of the full ImageSeries. This attribute serves as an index to indicate which frames each file contains, to facilitate random access. The ‘starting_frame’ attribute, hence, contains a list of frame numbers within the full ImageSeries of the first frame of each file listed in the parent ‘external_file’ dataset. Zero-based indexing is used (hence, the first element will always be zero). For example, if the ‘external_file’ dataset has three paths to files and the first file has 5 frames, the second file has 10 frames, and the third file has 20 frames, then this attribute will have values [0, 5, 15]. If there is a single external file that holds all of the frames of the ImageSeries (and so there is a single element in the ‘external_file’ dataset), then this attribute should have value [0].
|
—format |
Dataset |
Format of image. If this is ‘external’, then the attribute ‘external_file’ contains the path information to the image files. If this is ‘raw’, then the raw (single-channel) binary data is stored in the ‘data’ dataset. If this attribute is not present, then the default format=’raw’ case is assumed.
|
—starting_time |
Dataset |
Timestamp of the first sample in seconds. When timestamps are uniformly spaced, the timestamp of the first sample can be specified and all subsequent ones calculated from the sampling rate attribute.
|
——rate |
Attribute |
Sampling rate, in Hz.
|
——unit |
Attribute |
Unit of measurement for time, which is fixed to ‘seconds’.
|
—timestamps |
Dataset |
Timestamps for samples stored in data, in seconds, relative to the common experiment master-clock stored in NWBFile.timestamps_reference_time.
|
——interval |
Attribute |
Value is ‘1’
|
——unit |
Attribute |
Unit of measurement for timestamps, which is fixed to ‘seconds’.
|
—control |
Dataset |
Numerical labels that apply to each time point in data for the purpose of querying and slicing data by these values. If present, the length of this array should be the same size as the first dimension of data.
|
—control_description |
Dataset |
Description of each control value. Must be present if control is present. If present, control_description[0] should describe time points where control == 0.
|
—device |
Link |
Link to the Device object that was used to capture these images.
|
Id |
Type |
Description |
---|---|---|
<OpticalSeries> |
Group |
Top level Group for <OpticalSeries>
|
—device |
Link |
Link to the Device object that was used to capture these images.
|
—sync |
Group |
Lab-specific time and sync information as provided directly from hardware devices and that is necessary for aligning all acquired time information to a common timebase. The timestamp array stores time in the common timebase. This group will usually only be populated in TimeSeries that are stored external to the NWB file, in files storing raw data. Once timestamp data is calculated, the contents of ‘sync’ are mostly for archival purposes.
|
2.4.6.1. Groups: sync
Lab-specific time and sync information as provided directly from hardware devices and that is necessary for aligning all acquired time information to a common timebase. The timestamp array stores time in the common timebase. This group will usually only be populated in TimeSeries that are stored external to the NWB file, in files storing raw data. Once timestamp data is calculated, the contents of ‘sync’ are mostly for archival purposes.
Quantity: 0 or 1
Name: sync
2.4.7. IndexSeries
Overview: Stores indices to image frames stored in an ImageSeries. The purpose of the IndexSeries is to allow a static image stack to be stored in an Images object, and the images in the stack to be referenced out-of-order. This can be for the display of individual images, or of movie segments (as a movie is simply a series of images). The data field stores the index of the frame in the referenced Images object, and the timestamps array indicates when that image was displayed.
IndexSeries
extends TimeSeries
and includes all elements of TimeSeries with the following additions or changes.
Extends: TimeSeries
Primitive Type: Group
Inherits from: TimeSeries, NWBDataInterface, NWBContainer, Container
Source filename: nwb.image.yaml
Source Specification: see Section 3.5.7

Id |
Type |
Description |
---|---|---|
<IndexSeries> |
Group |
Top level Group for <IndexSeries>
|
—description |
Attribute |
Description of the time series.
|
—comments |
Attribute |
Human-readable comments about the TimeSeries. This second descriptive field can be used to store additional information, or descriptive information if the primary description field is populated with a computer-readable string.
|
—data |
Dataset |
Index of the image (using zero-indexing) in the linked Images object.
|
——conversion |
Attribute |
This field is unused by IndexSeries.
|
——resolution |
Attribute |
This field is unused by IndexSeries.
|
——offset |
Attribute |
This field is unused by IndexSeries.
|
——unit |
Attribute |
This field is unused by IndexSeries and has the value N/A.
|
——continuity |
Attribute |
Optionally describe the continuity of the data. Can be “continuous”, “instantaneous”, or “step”. For example, a voltage trace would be “continuous”, because samples are recorded from a continuous process. An array of lick times would be “instantaneous”, because the data represents distinct moments in time. Times of image presentations would be “step” because the picture remains the same until the next timepoint. This field is optional, but is useful in providing information about the underlying data. It may inform the way this data is interpreted, the way it is visualized, and what analysis methods are applicable.
|
—starting_time |
Dataset |
Timestamp of the first sample in seconds. When timestamps are uniformly spaced, the timestamp of the first sample can be specified and all subsequent ones calculated from the sampling rate attribute.
|
——rate |
Attribute |
Sampling rate, in Hz.
|
——unit |
Attribute |
Unit of measurement for time, which is fixed to ‘seconds’.
|
—timestamps |
Dataset |
Timestamps for samples stored in data, in seconds, relative to the common experiment master-clock stored in NWBFile.timestamps_reference_time.
|
——interval |
Attribute |
Value is ‘1’
|
——unit |
Attribute |
Unit of measurement for timestamps, which is fixed to ‘seconds’.
|
—control |
Dataset |
Numerical labels that apply to each time point in data for the purpose of querying and slicing data by these values. If present, the length of this array should be the same size as the first dimension of data.
|
—control_description |
Dataset |
Description of each control value. Must be present if control is present. If present, control_description[0] should describe time points where control == 0.
|
—indexed_timeseries |
Link |
Link to ImageSeries object containing images that are indexed. Use of this link is discouraged and will be deprecated. Link to an Images type instead.
|
—indexed_images |
Link |
Link to Images object containing an ordered set of images that are indexed. The Images object must contain a ‘ordered_images’ dataset specifying the order of the images in the Images type.
|
Id |
Type |
Description |
---|---|---|
<IndexSeries> |
Group |
Top level Group for <IndexSeries>
|
—indexed_timeseries |
Link |
Link to ImageSeries object containing images that are indexed. Use of this link is discouraged and will be deprecated. Link to an Images type instead.
|
—indexed_images |
Link |
Link to Images object containing an ordered set of images that are indexed. The Images object must contain a ‘ordered_images’ dataset specifying the order of the images in the Images type.
|
—sync |
Group |
Lab-specific time and sync information as provided directly from hardware devices and that is necessary for aligning all acquired time information to a common timebase. The timestamp array stores time in the common timebase. This group will usually only be populated in TimeSeries that are stored external to the NWB file, in files storing raw data. Once timestamp data is calculated, the contents of ‘sync’ are mostly for archival purposes.
|
2.4.7.1. Groups: sync
Lab-specific time and sync information as provided directly from hardware devices and that is necessary for aligning all acquired time information to a common timebase. The timestamp array stores time in the common timebase. This group will usually only be populated in TimeSeries that are stored external to the NWB file, in files storing raw data. Once timestamp data is calculated, the contents of ‘sync’ are mostly for archival purposes.
Quantity: 0 or 1
Name: sync
2.5. NWB file
Main NWB file specification.
2.5.1. ScratchData
Overview: Any one-off datasets
ScratchData
extends NWBData
and includes all elements of NWBData with the following additions or changes.
Extends: NWBData
Primitive Type: Dataset
Source filename: nwb.file.yaml
Source Specification: see Section 3.6.1
Id |
Type |
Description |
---|---|---|
<ScratchData> |
Dataset |
Top level Dataset for <ScratchData>
|
—notes |
Attribute |
Any notes the user has about the dataset being stored
|
2.5.2. NWBFile
Overview: An NWB file storing cellular-based neurophysiology data from a single experimental session.
NWBFile
extends NWBContainer
and includes all elements of NWBContainer with the following additions or changes.
Extends: NWBContainer
Primitive Type: Group
Name: root
Inherits from: NWBContainer, Container
Source filename: nwb.file.yaml
Source Specification: see Section 3.6.2

Id |
Type |
Description |
---|---|---|
root |
Group |
Top level Group for root
|
—nwb_version |
Attribute |
File version string. Use semantic versioning, e.g. 1.2.1. This will be the name of the format with trailing major, minor and patch numbers.
|
—file_create_date |
Dataset |
A record of the date the file was created and of subsequent modifications. The date is stored in UTC with local timezone offset as ISO 8601 extended formatted strings: 2018-09-28T14:43:54.123+02:00. Dates stored in UTC end in “Z” with no timezone offset. Date accuracy is up to milliseconds. The file can be created after the experiment was run, so this may differ from the experiment start time. Each modification to the nwb file adds a new entry to the array.
|
—identifier |
Dataset |
A unique text identifier for the file. For example, concatenated lab name, file creation date/time and experimentalist, or a hash of these and/or other values. The goal is that the string should be unique to all other files.
|
—session_description |
Dataset |
A description of the experimental session and data in the file.
|
—session_start_time |
Dataset |
Date and time of the experiment/session start. The date is stored in UTC with local timezone offset as ISO 8601 extended formatted string: 2018-09-28T14:43:54.123+02:00. Dates stored in UTC end in “Z” with no timezone offset. Date accuracy is up to milliseconds.
|
—timestamps_reference_time |
Dataset |
Date and time corresponding to time zero of all timestamps. The date is stored in UTC with local timezone offset as ISO 8601 extended formatted string: 2018-09-28T14:43:54.123+02:00. Dates stored in UTC end in “Z” with no timezone offset. Date accuracy is up to milliseconds. All times stored in the file use this time as reference (i.e., time zero).
|
Id |
Type |
Description |
---|---|---|
root |
Group |
Top level Group for root
|
—acquisition |
Group |
Data streams recorded from the system, including ephys, ophys, tracking, etc. This group should be read-only after the experiment is completed and timestamps are corrected to a common timebase. The data stored here may be links to raw data stored in external NWB files. This will allow keeping bulky raw data out of the file while preserving the option of keeping some/all in the file. Acquired data includes tracking and experimental data streams (i.e., everything measured from the system). If bulky data is stored in the /acquisition group, the data can exist in a separate NWB file that is linked to by the file being used for processing and analysis.
|
—analysis |
Group |
Lab-specific and custom scientific analysis of data. There is no defined format for the content of this group - the format is up to the individual user/lab. To facilitate sharing analysis data between labs, the contents here should be stored in standard types (e.g., neurodata_types) and appropriately documented. The file can store lab-specific and custom data analysis without restriction on its form or schema, reducing data formatting restrictions on end users. Such data should be placed in the analysis group. The analysis data should be documented so that it could be shared with other labs.
|
—scratch |
Group |
A place to store one-off analysis results. Data placed here is not intended for sharing. By placing data here, users acknowledge that there is no guarantee that their data meets any standard.
|
—processing |
Group |
The home for ProcessingModules. These modules perform intermediate analysis of data that is necessary to perform before scientific analysis. Examples include spike clustering, extracting position from tracking data, stitching together image slices. ProcessingModules can be large and express many data sets from relatively complex analysis (e.g., spike detection and clustering) or small, representing extraction of position information from tracking video, or even binary lick/no-lick decisions. Common software tools (e.g., klustakwik, MClust) are expected to read/write data here. ‘Processing’ refers to intermediate analysis of the acquired data to make it more amenable to scientific analysis.
|
—stimulus |
Group |
Data pushed into the system (eg, video stimulus, sound, voltage, etc) and secondary representations of that data (eg, measurements of something used as a stimulus). This group should be made read-only after experiment complete and timestamps are corrected to common timebase. Stores both presented stimuli and stimulus templates, the latter in case the same stimulus is presented multiple times, or is pulled from an external stimulus library. Stimuli are here defined as any signal that is pushed into the system as part of the experiment (eg, sound, video, voltage, etc). Many different experiments can use the same stimuli, and stimuli can be re-used during an experiment. The stimulus group is organized so that one version of template stimuli can be stored and these be used multiple times. These templates can exist in the present file or can be linked to a remote library file.
|
—general |
Group |
Experimental metadata, including protocol, notes and description of hardware device(s). The metadata stored in this section should be used to describe the experiment. Metadata necessary for interpreting the data is stored with the data. General experimental metadata, including animal strain, experimental protocols, experimenter, devices, etc, are stored under ‘general’. Core metadata (e.g., that required to interpret data fields) is stored with the data itself, and implicitly defined by the file specification (e.g., time is in seconds). The strategy used here for storing non-core metadata is to use free-form text fields, such as would appear in sentences or paragraphs from a Methods section. Metadata fields are text to enable them to be more general, for example to represent ranges instead of numerical values. Machine-readable metadata is stored as attributes to these free-form datasets. All entries in the below table are to be included when data is present. Unused groups (e.g., intracellular_ephys in an optophysiology experiment) should not be created unless there is data to store within them.
|
—intervals |
Group |
Experimental intervals, whether that be logically distinct sub-experiments having a particular scientific goal, trials (see trials subgroup) during an experiment, or epochs (see epochs subgroup) deriving from analysis of data.
|
—units |
Group |
Data about sorted spike units.
|
2.5.2.1. Groups: /acquisition
Data streams recorded from the system, including ephys, ophys, tracking, etc. This group should be read-only after the experiment is completed and timestamps are corrected to a common timebase. The data stored here may be links to raw data stored in external NWB files. This will allow keeping bulky raw data out of the file while preserving the option of keeping some/all in the file. Acquired data includes tracking and experimental data streams (i.e., everything measured from the system). If bulky data is stored in the /acquisition group, the data can exist in a separate NWB file that is linked to by the file being used for processing and analysis.
Name: acquisition
Id |
Type |
Description |
---|---|---|
acquisition |
Group |
Top level Group for acquisition
|
Group |
Acquired, raw data.
|
|
—<DynamicTable> |
Group |
Tabular data that is relevant to acquisition
|
2.5.2.2. Groups: /acquisition/<NWBDataInterface>
Acquired, raw data.
Extends: NWBDataInterface
Quantity: 0 or more
2.5.2.3. Groups: /acquisition/<DynamicTable>
Tabular data that is relevant to acquisition
Extends: DynamicTable
Quantity: 0 or more
2.5.2.4. Groups: /analysis
Lab-specific and custom scientific analysis of data. There is no defined format for the content of this group - the format is up to the individual user/lab. To facilitate sharing analysis data between labs, the contents here should be stored in standard types (e.g., neurodata_types) and appropriately documented. The file can store lab-specific and custom data analysis without restriction on its form or schema, reducing data formatting restrictions on end users. Such data should be placed in the analysis group. The analysis data should be documented so that it could be shared with other labs.
Name: analysis
Id |
Type |
Description |
---|---|---|
analysis |
Group |
Top level Group for analysis
|
—<NWBContainer> |
Group |
Custom analysis results.
|
—<DynamicTable> |
Group |
Tabular data that is relevant to data stored in analysis
|
2.5.2.5. Groups: /analysis/<NWBContainer>
Custom analysis results.
Extends: NWBContainer
Quantity: 0 or more
2.5.2.6. Groups: /analysis/<DynamicTable>
Tabular data that is relevant to data stored in analysis
Extends: DynamicTable
Quantity: 0 or more
2.5.2.7. Groups: /scratch
A place to store one-off analysis results. Data placed here is not intended for sharing. By placing data here, users acknowledge that there is no guarantee that their data meets any standard.
Quantity: 0 or 1
Name: scratch
Id |
Type |
Description |
---|---|---|
scratch |
Group |
Top level Group for scratch
|
—<ScratchData> |
Dataset |
Any one-off datasets
|
Id |
Type |
Description |
---|---|---|
scratch |
Group |
Top level Group for scratch
|
—<NWBContainer> |
Group |
Any one-off containers
|
—<DynamicTable> |
Group |
Any one-off tables
|
2.5.2.8. Groups: /scratch/<NWBContainer>
Any one-off containers
Extends: NWBContainer
Quantity: 0 or more
2.5.2.9. Groups: /scratch/<DynamicTable>
Any one-off tables
Extends: DynamicTable
Quantity: 0 or more
2.5.2.10. Groups: /processing
The home for ProcessingModules. These modules perform intermediate analysis of data that is necessary to perform before scientific analysis. Examples include spike clustering, extracting position from tracking data, stitching together image slices. ProcessingModules can be large and express many data sets from relatively complex analysis (e.g., spike detection and clustering) or small, representing extraction of position information from tracking video, or even binary lick/no-lick decisions. Common software tools (e.g., klustakwik, MClust) are expected to read/write data here. ‘Processing’ refers to intermediate analysis of the acquired data to make it more amenable to scientific analysis.
Name: processing
Id |
Type |
Description |
---|---|---|
processing |
Group |
Top level Group for processing
|
Group |
Intermediate analysis of acquired data.
|
2.5.2.11. Groups: /processing/<ProcessingModule>
Intermediate analysis of acquired data.
Extends: ProcessingModule
Quantity: 0 or more
2.5.2.12. Groups: /stimulus
Data pushed into the system (eg, video stimulus, sound, voltage, etc) and secondary representations of that data (eg, measurements of something used as a stimulus). This group should be made read-only after experiment complete and timestamps are corrected to common timebase. Stores both presented stimuli and stimulus templates, the latter in case the same stimulus is presented multiple times, or is pulled from an external stimulus library. Stimuli are here defined as any signal that is pushed into the system as part of the experiment (eg, sound, video, voltage, etc). Many different experiments can use the same stimuli, and stimuli can be re-used during an experiment. The stimulus group is organized so that one version of template stimuli can be stored and these be used multiple times. These templates can exist in the present file or can be linked to a remote library file.
Name: stimulus
Id |
Type |
Description |
---|---|---|
stimulus |
Group |
Top level Group for stimulus
|
—presentation |
Group |
Stimuli presented during the experiment.
|
—templates |
Group |
Template stimuli. Timestamps in templates are based on stimulus design and are relative to the beginning of the stimulus. When templates are used, the stimulus instances must convert presentation times to the experiment`s time reference frame.
|
2.5.2.13. Groups: /stimulus/presentation
Stimuli presented during the experiment.
Name: presentation
Id |
Type |
Description |
---|---|---|
presentation |
Group |
Top level Group for presentation
|
—<TimeSeries> |
Group |
TimeSeries objects containing data of presented stimuli.
|
Group |
Generic NWB data interfaces, usually from an extension, containing data of presented stimuli.
|
|
—<DynamicTable> |
Group |
DynamicTable objects containing data of presented stimuli.
|
2.5.2.14. Groups: /stimulus/presentation/<TimeSeries>
TimeSeries objects containing data of presented stimuli.
Extends: TimeSeries
Quantity: 0 or more
2.5.2.15. Groups: /stimulus/presentation/<NWBDataInterface>
Generic NWB data interfaces, usually from an extension, containing data of presented stimuli.
Extends: NWBDataInterface
Quantity: 0 or more
2.5.2.16. Groups: /stimulus/presentation/<DynamicTable>
DynamicTable objects containing data of presented stimuli.
Extends: DynamicTable
Quantity: 0 or more
2.5.2.17. Groups: /stimulus/templates
Template stimuli. Timestamps in templates are based on stimulus design and are relative to the beginning of the stimulus. When templates are used, the stimulus instances must convert presentation times to the experiment`s time reference frame.
Name: templates
Id |
Type |
Description |
---|---|---|
templates |
Group |
Top level Group for templates
|
—<TimeSeries> |
Group |
TimeSeries objects containing template data of presented stimuli.
|
—<Images> |
Group |
Images objects containing images of presented stimuli.
|
2.5.2.18. Groups: /stimulus/templates/<TimeSeries>
TimeSeries objects containing template data of presented stimuli.
Extends: TimeSeries
Quantity: 0 or more
2.5.2.19. Groups: /stimulus/templates/<Images>
Images objects containing images of presented stimuli.
Extends: Images
Quantity: 0 or more
2.5.2.20. Groups: /general
Experimental metadata, including protocol, notes and description of hardware device(s). The metadata stored in this section should be used to describe the experiment. Metadata necessary for interpreting the data is stored with the data. General experimental metadata, including animal strain, experimental protocols, experimenter, devices, etc, are stored under ‘general’. Core metadata (e.g., that required to interpret data fields) is stored with the data itself, and implicitly defined by the file specification (e.g., time is in seconds). The strategy used here for storing non-core metadata is to use free-form text fields, such as would appear in sentences or paragraphs from a Methods section. Metadata fields are text to enable them to be more general, for example to represent ranges instead of numerical values. Machine-readable metadata is stored as attributes to these free-form datasets. All entries in the below table are to be included when data is present. Unused groups (e.g., intracellular_ephys in an optophysiology experiment) should not be created unless there is data to store within them.
Name: general
Id |
Type |
Description |
---|---|---|
general |
Group |
Top level Group for general
|
—data_collection |
Dataset |
Notes about data collection and analysis.
|
—experiment_description |
Dataset |
General description of the experiment.
|
—experimenter |
Dataset |
Name of person(s) who performed the experiment. Can also specify roles of different people involved.
|
—institution |
Dataset |
Institution(s) where experiment was performed.
|
—keywords |
Dataset |
Terms to search over.
|
—lab |
Dataset |
Laboratory where experiment was performed.
|
—notes |
Dataset |
Notes about the experiment.
|
—pharmacology |
Dataset |
Description of drugs used, including how and when they were administered. Anesthesia(s), painkiller(s), etc., plus dosage, concentration, etc.
|
—protocol |
Dataset |
Experimental protocol, if applicable. e.g., include IACUC protocol number.
|
—related_publications |
Dataset |
Publication information. PMID, DOI, URL, etc.
|
—session_id |
Dataset |
Lab-specific ID for the session.
|
—slices |
Dataset |
Description of slices, including information about preparation thickness, orientation, temperature, and bath solution.
|
—source_script |
Dataset |
Script file or link to public source code used to create this NWB file.
|
——file_name |
Attribute |
Name of script file.
|
—was_generated_by |
Dataset |
Name and version of software package(s) used to generate data contained in this NWB File. For each software package or library, include the name of the software as the first value and the version as the second value.
|
—stimulus |
Dataset |
Notes about stimuli, such as how and where they were presented.
|
—surgery |
Dataset |
Narrative description about surgery/surgeries, including date(s) and who performed surgery.
|
—virus |
Dataset |
Information about virus(es) used in experiments, including virus ID, source, date made, injection location, volume, etc.
|
Id |
Type |
Description |
---|---|---|
general |
Group |
Top level Group for general
|
—<LabMetaData> |
Group |
Place-holder than can be extended so that lab-specific meta-data can be placed in /general.
|
—devices |
Group |
Description of hardware devices used during experiment, e.g., monitors, ADC boards, microscopes, etc.
|
—subject |
Group |
Information about the animal or person from which the data was measured.
|
—extracellular_ephys |
Group |
Metadata related to extracellular electrophysiology.
|
—intracellular_ephys |
Group |
Metadata related to intracellular electrophysiology.
|
—optogenetics |
Group |
Metadata describing optogenetic stimuluation.
|
—optophysiology |
Group |
Metadata related to optophysiology.
|
2.5.2.21. Groups: /general/<LabMetaData>
Place-holder than can be extended so that lab-specific meta-data can be placed in /general.
Extends: LabMetaData
Quantity: 0 or more
2.5.2.22. Groups: /general/devices
Description of hardware devices used during experiment, e.g., monitors, ADC boards, microscopes, etc.
Quantity: 0 or 1
Name: devices
Id |
Type |
Description |
---|---|---|
devices |
Group |
Top level Group for devices
|
—<Device> |
Group |
Data acquisition devices.
|
2.5.2.23. Groups: /general/devices/<Device>
Data acquisition devices.
Extends: Device
Quantity: 0 or more
2.5.2.24. Groups: /general/subject
Information about the animal or person from which the data was measured.
Extends: Subject
Quantity: 0 or 1
Name: subject
2.5.2.25. Groups: /general/extracellular_ephys
Metadata related to extracellular electrophysiology.
Quantity: 0 or 1
Name: extracellular_ephys
Id |
Type |
Description |
---|---|---|
extracellular_ephys |
Group |
Top level Group for extracellular_ephys
|
Group |
Physical group of electrodes.
|
|
—electrodes |
Group |
A table of all electrodes (i.e. channels) used for recording.
|
2.5.2.26. Groups: /general/extracellular_ephys/<ElectrodeGroup>
Physical group of electrodes.
Extends: ElectrodeGroup
Quantity: 0 or more
2.5.2.27. Groups: /general/extracellular_ephys/electrodes
A table of all electrodes (i.e. channels) used for recording.
Extends: DynamicTable
Quantity: 0 or 1
Name: electrodes
Id |
Type |
Description |
---|---|---|
electrodes |
Group |
Top level Group for electrodes
|
—x |
Dataset |
x coordinate of the channel location in the brain (+x is posterior).
|
—y |
Dataset |
y coordinate of the channel location in the brain (+y is inferior).
|
—z |
Dataset |
z coordinate of the channel location in the brain (+z is right).
|
—imp |
Dataset |
Impedance of the channel, in ohms.
|
—location |
Dataset |
Location of the electrode (channel). Specify the area, layer, comments on estimation of area/layer, stereotaxic coordinates if in vivo, etc. Use standard atlas names for anatomical regions when possible.
|
—filtering |
Dataset |
Description of hardware filtering, including the filter name and frequency cutoffs.
|
—group |
Dataset |
Reference to the ElectrodeGroup this electrode is a part of.
|
—group_name |
Dataset |
Name of the ElectrodeGroup this electrode is a part of.
|
—rel_x |
Dataset |
x coordinate in electrode group
|
—rel_y |
Dataset |
y coordinate in electrode group
|
—rel_z |
Dataset |
z coordinate in electrode group
|
—reference |
Dataset |
Description of the reference electrode and/or reference scheme used for this electrode, e.g., “stainless steel skull screw” or “online common average referencing”.
|
2.5.2.28. Groups: /general/intracellular_ephys
Metadata related to intracellular electrophysiology.
Quantity: 0 or 1
Name: intracellular_ephys
Id |
Type |
Description |
---|---|---|
intracellular_ephys |
Group |
Top level Group for intracellular_ephys
|
—filtering |
Dataset |
[DEPRECATED] Use IntracellularElectrode.filtering instead. Description of filtering used. Includes filtering type and parameters, frequency fall-off, etc. If this changes between TimeSeries, filter description should be stored as a text attribute for each TimeSeries.
|
Id |
Type |
Description |
---|---|---|
intracellular_ephys |
Group |
Top level Group for intracellular_ephys
|
Group |
An intracellular electrode.
|
|
—sweep_table |
Group |
[DEPRECATED] Table used to group different PatchClampSeries. SweepTable is being replaced by IntracellularRecordingsTable and SimultaneousRecordingsTable tables. Additional SequentialRecordingsTable, RepetitionsTable and ExperimentalConditions tables provide enhanced support for experiment metadata.
|
—intracellular_recordings |
Group |
A table to group together a stimulus and response from a single electrode and a single simultaneous recording. Each row in the table represents a single recording consisting typically of a stimulus and a corresponding response. In some cases, however, only a stimulus or a response are recorded as as part of an experiment. In this case both, the stimulus and response will point to the same TimeSeries while the idx_start and count of the invalid column will be set to -1, thus, indicating that no values have been recorded for the stimulus or response, respectively. Note, a recording MUST contain at least a stimulus or a response. Typically the stimulus and response are PatchClampSeries. However, the use of AD/DA channels that are not associated to an electrode is also common in intracellular electrophysiology, in which case other TimeSeries may be used.
|
—simultaneous_recordings |
Group |
A table for grouping different intracellular recordings from the IntracellularRecordingsTable table together that were recorded simultaneously from different electrodes
|
—sequential_recordings |
Group |
A table for grouping different sequential recordings from the SimultaneousRecordingsTable table together. This is typically used to group together sequential recordings where the a sequence of stimuli of the same type with varying parameters have been presented in a sequence.
|
—repetitions |
Group |
A table for grouping different sequential intracellular recordings together. With each SequentialRecording typically representing a particular type of stimulus, the RepetitionsTable table is typically used to group sets of stimuli applied in sequence.
|
—experimental_conditions |
Group |
A table for grouping different intracellular recording repetitions together that belong to the same experimental experimental_conditions.
|
2.5.2.29. Groups: /general/intracellular_ephys/<IntracellularElectrode>
An intracellular electrode.
Extends: IntracellularElectrode
Quantity: 0 or more
2.5.2.30. Groups: /general/intracellular_ephys/sweep_table
[DEPRECATED] Table used to group different PatchClampSeries. SweepTable is being replaced by IntracellularRecordingsTable and SimultaneousRecordingsTable tables. Additional SequentialRecordingsTable, RepetitionsTable and ExperimentalConditions tables provide enhanced support for experiment metadata.
Extends: SweepTable
Quantity: 0 or 1
Name: sweep_table
2.5.2.31. Groups: /general/intracellular_ephys/intracellular_recordings
A table to group together a stimulus and response from a single electrode and a single simultaneous recording. Each row in the table represents a single recording consisting typically of a stimulus and a corresponding response. In some cases, however, only a stimulus or a response are recorded as as part of an experiment. In this case both, the stimulus and response will point to the same TimeSeries while the idx_start and count of the invalid column will be set to -1, thus, indicating that no values have been recorded for the stimulus or response, respectively. Note, a recording MUST contain at least a stimulus or a response. Typically the stimulus and response are PatchClampSeries. However, the use of AD/DA channels that are not associated to an electrode is also common in intracellular electrophysiology, in which case other TimeSeries may be used.
Extends: IntracellularRecordingsTable
Quantity: 0 or 1
Name: intracellular_recordings
2.5.2.32. Groups: /general/intracellular_ephys/simultaneous_recordings
A table for grouping different intracellular recordings from the IntracellularRecordingsTable table together that were recorded simultaneously from different electrodes
Extends: SimultaneousRecordingsTable
Quantity: 0 or 1
Name: simultaneous_recordings
2.5.2.33. Groups: /general/intracellular_ephys/sequential_recordings
A table for grouping different sequential recordings from the SimultaneousRecordingsTable table together. This is typically used to group together sequential recordings where the a sequence of stimuli of the same type with varying parameters have been presented in a sequence.
Extends: SequentialRecordingsTable
Quantity: 0 or 1
Name: sequential_recordings
2.5.2.34. Groups: /general/intracellular_ephys/repetitions
A table for grouping different sequential intracellular recordings together. With each SequentialRecording typically representing a particular type of stimulus, the RepetitionsTable table is typically used to group sets of stimuli applied in sequence.
Extends: RepetitionsTable
Quantity: 0 or 1
Name: repetitions
2.5.2.35. Groups: /general/intracellular_ephys/experimental_conditions
A table for grouping different intracellular recording repetitions together that belong to the same experimental experimental_conditions.
Extends: ExperimentalConditionsTable
Quantity: 0 or 1
Name: experimental_conditions
2.5.2.36. Groups: /general/optogenetics
Metadata describing optogenetic stimuluation.
Quantity: 0 or 1
Name: optogenetics
Id |
Type |
Description |
---|---|---|
optogenetics |
Group |
Top level Group for optogenetics
|
Group |
An optogenetic stimulation site.
|
2.5.2.37. Groups: /general/optogenetics/<OptogeneticStimulusSite>
An optogenetic stimulation site.
Extends: OptogeneticStimulusSite
Quantity: 0 or more
2.5.2.38. Groups: /general/optophysiology
Metadata related to optophysiology.
Quantity: 0 or 1
Name: optophysiology
Id |
Type |
Description |
---|---|---|
optophysiology |
Group |
Top level Group for optophysiology
|
—<ImagingPlane> |
Group |
An imaging plane.
|
2.5.2.39. Groups: /general/optophysiology/<ImagingPlane>
An imaging plane.
Extends: ImagingPlane
Quantity: 0 or more
2.5.2.40. Groups: /intervals
Experimental intervals, whether that be logically distinct sub-experiments having a particular scientific goal, trials (see trials subgroup) during an experiment, or epochs (see epochs subgroup) deriving from analysis of data.
Quantity: 0 or 1
Name: intervals
Id |
Type |
Description |
---|---|---|
intervals |
Group |
Top level Group for intervals
|
—epochs |
Group |
Divisions in time marking experimental stages or sub-divisions of a single recording session.
|
—trials |
Group |
Repeated experimental events that have a logical grouping.
|
—invalid_times |
Group |
Time intervals that should be removed from analysis.
|
Group |
Optional additional table(s) for describing other experimental time intervals.
|
2.5.2.41. Groups: /intervals/epochs
Divisions in time marking experimental stages or sub-divisions of a single recording session.
Extends: TimeIntervals
Quantity: 0 or 1
Name: epochs
2.5.2.42. Groups: /intervals/trials
Repeated experimental events that have a logical grouping.
Extends: TimeIntervals
Quantity: 0 or 1
Name: trials
2.5.2.43. Groups: /intervals/invalid_times
Time intervals that should be removed from analysis.
Extends: TimeIntervals
Quantity: 0 or 1
Name: invalid_times
2.5.2.44. Groups: /intervals/<TimeIntervals>
Optional additional table(s) for describing other experimental time intervals.
Extends: TimeIntervals
Quantity: 0 or more
2.5.2.45. Groups: /units
Data about sorted spike units.
Extends: Units
Quantity: 0 or 1
Name: units
2.5.3. LabMetaData
Overview: Lab-specific meta-data.
LabMetaData
extends NWBContainer
and includes all elements of NWBContainer with the following additions or changes.
Extends: NWBContainer
Primitive Type: Group
Inherits from: NWBContainer, Container
Source filename: nwb.file.yaml
Source Specification: see Section 3.6.3
2.5.4. Subject
Overview: Information about the animal or person from which the data was measured.
Subject
extends NWBContainer
and includes all elements of NWBContainer with the following additions or changes.
Extends: NWBContainer
Primitive Type: Group
Inherits from: NWBContainer, Container
Source filename: nwb.file.yaml
Source Specification: see Section 3.6.4

Id |
Type |
Description |
---|---|---|
<Subject> |
Group |
Top level Group for <Subject>
|
—age |
Dataset |
Age of subject. Can be supplied instead of ‘date_of_birth’.
|
——reference |
Attribute |
Age is with reference to this event. Can be ‘birth’ or ‘gestational’. If reference is omitted, ‘birth’ is implied.
|
—date_of_birth |
Dataset |
Date of birth of subject. Can be supplied instead of ‘age’.
|
—description |
Dataset |
Description of subject and where subject came from (e.g., breeder, if animal).
|
—genotype |
Dataset |
Genetic strain. If absent, assume Wild Type (WT).
|
—sex |
Dataset |
Gender of subject.
|
—species |
Dataset |
Species of subject.
|
—strain |
Dataset |
Strain of subject.
|
—subject_id |
Dataset |
ID of animal/person used/participating in experiment (lab convention).
|
—weight |
Dataset |
Weight at time of experiment, at time of surgery and at other important times.
|
2.6. Miscellaneous neurodata_types.
Miscellaneous types.
2.6.1. AbstractFeatureSeries
Overview: Abstract features, such as quantitative descriptions of sensory stimuli. The TimeSeries::data field is a 2D array, storing those features (e.g., for visual grating stimulus this might be orientation, spatial frequency and contrast). Null stimuli (eg, uniform gray) can be marked as being an independent feature (eg, 1.0 for gray, 0.0 for actual stimulus) or by storing NaNs for feature values, or through use of the TimeSeries::control fields. A set of features is considered to persist until the next set of features is defined. The final set of features stored should be the null set. This is useful when storing the raw stimulus is impractical.
AbstractFeatureSeries
extends TimeSeries
and includes all elements of TimeSeries with the following additions or changes.
Extends: TimeSeries
Primitive Type: Group
Inherits from: TimeSeries, NWBDataInterface, NWBContainer, Container
Source filename: nwb.misc.yaml
Source Specification: see Section 3.7.1

Id |
Type |
Description |
---|---|---|
<AbstractFeatureSeries> |
Group |
Top level Group for <AbstractFeatureSeries>
|
—description |
Attribute |
Description of the time series.
|
—comments |
Attribute |
Human-readable comments about the TimeSeries. This second descriptive field can be used to store additional information, or descriptive information if the primary description field is populated with a computer-readable string.
|
—data |
Dataset |
Values of each feature at each time.
|
——unit |
Attribute |
Since there can be different units for different features, store the units in ‘feature_units’. The default value for this attribute is “see ‘feature_units’”.
|
——conversion |
Attribute |
Scalar to multiply each element in data to convert it to the specified ‘unit’. If the data are stored in acquisition system units or other units that require a conversion to be interpretable, multiply the data by ‘conversion’ to convert the data to the specified ‘unit’. e.g. if the data acquisition system stores values in this object as signed 16-bit integers (int16 range -32,768 to 32,767) that correspond to a 5V range (-2.5V to 2.5V), and the data acquisition system gain is 8000X, then the ‘conversion’ multiplier to get from raw data acquisition values to recorded volts is 2.5/32768/8000 = 9.5367e-9.
|
——offset |
Attribute |
Scalar to add to the data after scaling by ‘conversion’ to finalize its coercion to the specified ‘unit’. Two common examples of this include (a) data stored in an unsigned type that requires a shift after scaling to re-center the data, and (b) specialized recording devices that naturally cause a scalar offset with respect to the true units.
|
——resolution |
Attribute |
Smallest meaningful difference between values in data, stored in the specified by unit, e.g., the change in value of the least significant bit, or a larger number if signal noise is known to be present. If unknown, use -1.0.
|
——continuity |
Attribute |
Optionally describe the continuity of the data. Can be “continuous”, “instantaneous”, or “step”. For example, a voltage trace would be “continuous”, because samples are recorded from a continuous process. An array of lick times would be “instantaneous”, because the data represents distinct moments in time. Times of image presentations would be “step” because the picture remains the same until the next timepoint. This field is optional, but is useful in providing information about the underlying data. It may inform the way this data is interpreted, the way it is visualized, and what analysis methods are applicable.
|
—feature_units |
Dataset |
Units of each feature.
|
—features |
Dataset |
Description of the features represented in TimeSeries::data.
|
—starting_time |
Dataset |
Timestamp of the first sample in seconds. When timestamps are uniformly spaced, the timestamp of the first sample can be specified and all subsequent ones calculated from the sampling rate attribute.
|
——rate |
Attribute |
Sampling rate, in Hz.
|
——unit |
Attribute |
Unit of measurement for time, which is fixed to ‘seconds’.
|
—timestamps |
Dataset |
Timestamps for samples stored in data, in seconds, relative to the common experiment master-clock stored in NWBFile.timestamps_reference_time.
|
——interval |
Attribute |
Value is ‘1’
|
——unit |
Attribute |
Unit of measurement for timestamps, which is fixed to ‘seconds’.
|
—control |
Dataset |
Numerical labels that apply to each time point in data for the purpose of querying and slicing data by these values. If present, the length of this array should be the same size as the first dimension of data.
|
—control_description |
Dataset |
Description of each control value. Must be present if control is present. If present, control_description[0] should describe time points where control == 0.
|
Id |
Type |
Description |
---|---|---|
<AbstractFeatureSeries> |
Group |
Top level Group for <AbstractFeatureSeries>
|
—sync |
Group |
Lab-specific time and sync information as provided directly from hardware devices and that is necessary for aligning all acquired time information to a common timebase. The timestamp array stores time in the common timebase. This group will usually only be populated in TimeSeries that are stored external to the NWB file, in files storing raw data. Once timestamp data is calculated, the contents of ‘sync’ are mostly for archival purposes.
|
2.6.1.1. Groups: sync
Lab-specific time and sync information as provided directly from hardware devices and that is necessary for aligning all acquired time information to a common timebase. The timestamp array stores time in the common timebase. This group will usually only be populated in TimeSeries that are stored external to the NWB file, in files storing raw data. Once timestamp data is calculated, the contents of ‘sync’ are mostly for archival purposes.
Quantity: 0 or 1
Name: sync
2.6.2. AnnotationSeries
Overview: Stores user annotations made during an experiment. The data[] field stores a text array, and timestamps are stored for each annotation (ie, interval=1). This is largely an alias to a standard TimeSeries storing a text array but that is identifiable as storing annotations in a machine-readable way.
AnnotationSeries
extends TimeSeries
and includes all elements of TimeSeries with the following additions or changes.
Extends: TimeSeries
Primitive Type: Group
Inherits from: TimeSeries, NWBDataInterface, NWBContainer, Container
Source filename: nwb.misc.yaml
Source Specification: see Section 3.7.2

Id |
Type |
Description |
---|---|---|
<AnnotationSeries> |
Group |
Top level Group for <AnnotationSeries>
|
—description |
Attribute |
Description of the time series.
|
—comments |
Attribute |
Human-readable comments about the TimeSeries. This second descriptive field can be used to store additional information, or descriptive information if the primary description field is populated with a computer-readable string.
|
—data |
Dataset |
Annotations made during an experiment.
|
——resolution |
Attribute |
Smallest meaningful difference between values in data. Annotations have no units, so the value is fixed to -1.0.
|
——unit |
Attribute |
Base unit of measurement for working with the data. Annotations have no units, so the value is fixed to ‘n/a’.
|
——conversion |
Attribute |
Scalar to multiply each element in data to convert it to the specified ‘unit’. If the data are stored in acquisition system units or other units that require a conversion to be interpretable, multiply the data by ‘conversion’ to convert the data to the specified ‘unit’. e.g. if the data acquisition system stores values in this object as signed 16-bit integers (int16 range -32,768 to 32,767) that correspond to a 5V range (-2.5V to 2.5V), and the data acquisition system gain is 8000X, then the ‘conversion’ multiplier to get from raw data acquisition values to recorded volts is 2.5/32768/8000 = 9.5367e-9.
|
——offset |
Attribute |
Scalar to add to the data after scaling by ‘conversion’ to finalize its coercion to the specified ‘unit’. Two common examples of this include (a) data stored in an unsigned type that requires a shift after scaling to re-center the data, and (b) specialized recording devices that naturally cause a scalar offset with respect to the true units.
|
——continuity |
Attribute |
Optionally describe the continuity of the data. Can be “continuous”, “instantaneous”, or “step”. For example, a voltage trace would be “continuous”, because samples are recorded from a continuous process. An array of lick times would be “instantaneous”, because the data represents distinct moments in time. Times of image presentations would be “step” because the picture remains the same until the next timepoint. This field is optional, but is useful in providing information about the underlying data. It may inform the way this data is interpreted, the way it is visualized, and what analysis methods are applicable.
|
—starting_time |
Dataset |
Timestamp of the first sample in seconds. When timestamps are uniformly spaced, the timestamp of the first sample can be specified and all subsequent ones calculated from the sampling rate attribute.
|
——rate |
Attribute |
Sampling rate, in Hz.
|
——unit |
Attribute |
Unit of measurement for time, which is fixed to ‘seconds’.
|
—timestamps |
Dataset |
Timestamps for samples stored in data, in seconds, relative to the common experiment master-clock stored in NWBFile.timestamps_reference_time.
|
——interval |
Attribute |
Value is ‘1’
|
——unit |
Attribute |
Unit of measurement for timestamps, which is fixed to ‘seconds’.
|
—control |
Dataset |
Numerical labels that apply to each time point in data for the purpose of querying and slicing data by these values. If present, the length of this array should be the same size as the first dimension of data.
|
—control_description |
Dataset |
Description of each control value. Must be present if control is present. If present, control_description[0] should describe time points where control == 0.
|
Id |
Type |
Description |
---|---|---|
<AnnotationSeries> |
Group |
Top level Group for <AnnotationSeries>
|
—sync |
Group |
Lab-specific time and sync information as provided directly from hardware devices and that is necessary for aligning all acquired time information to a common timebase. The timestamp array stores time in the common timebase. This group will usually only be populated in TimeSeries that are stored external to the NWB file, in files storing raw data. Once timestamp data is calculated, the contents of ‘sync’ are mostly for archival purposes.
|
2.6.2.1. Groups: sync
Lab-specific time and sync information as provided directly from hardware devices and that is necessary for aligning all acquired time information to a common timebase. The timestamp array stores time in the common timebase. This group will usually only be populated in TimeSeries that are stored external to the NWB file, in files storing raw data. Once timestamp data is calculated, the contents of ‘sync’ are mostly for archival purposes.
Quantity: 0 or 1
Name: sync
2.6.3. IntervalSeries
Overview: Stores intervals of data. The timestamps field stores the beginning and end of intervals. The data field stores whether the interval just started (>0 value) or ended (<0 value). Different interval types can be represented in the same series by using multiple key values (eg, 1 for feature A, 2 for feature B, 3 for feature C, etc). The field data stores an 8-bit integer. This is largely an alias of a standard TimeSeries but that is identifiable as representing time intervals in a machine-readable way.
IntervalSeries
extends TimeSeries
and includes all elements of TimeSeries with the following additions or changes.
Extends: TimeSeries
Primitive Type: Group
Inherits from: TimeSeries, NWBDataInterface, NWBContainer, Container
Source filename: nwb.misc.yaml
Source Specification: see Section 3.7.3

Id |
Type |
Description |
---|---|---|
<IntervalSeries> |
Group |
Top level Group for <IntervalSeries>
|
—description |
Attribute |
Description of the time series.
|
—comments |
Attribute |
Human-readable comments about the TimeSeries. This second descriptive field can be used to store additional information, or descriptive information if the primary description field is populated with a computer-readable string.
|
—data |
Dataset |
Use values >0 if interval started, <0 if interval ended.
|
——resolution |
Attribute |
Smallest meaningful difference between values in data. Annotations have no units, so the value is fixed to -1.0.
|
——unit |
Attribute |
Base unit of measurement for working with the data. Annotations have no units, so the value is fixed to ‘n/a’.
|
——conversion |
Attribute |
Scalar to multiply each element in data to convert it to the specified ‘unit’. If the data are stored in acquisition system units or other units that require a conversion to be interpretable, multiply the data by ‘conversion’ to convert the data to the specified ‘unit’. e.g. if the data acquisition system stores values in this object as signed 16-bit integers (int16 range -32,768 to 32,767) that correspond to a 5V range (-2.5V to 2.5V), and the data acquisition system gain is 8000X, then the ‘conversion’ multiplier to get from raw data acquisition values to recorded volts is 2.5/32768/8000 = 9.5367e-9.
|
——offset |
Attribute |
Scalar to add to the data after scaling by ‘conversion’ to finalize its coercion to the specified ‘unit’. Two common examples of this include (a) data stored in an unsigned type that requires a shift after scaling to re-center the data, and (b) specialized recording devices that naturally cause a scalar offset with respect to the true units.
|
——continuity |
Attribute |
Optionally describe the continuity of the data. Can be “continuous”, “instantaneous”, or “step”. For example, a voltage trace would be “continuous”, because samples are recorded from a continuous process. An array of lick times would be “instantaneous”, because the data represents distinct moments in time. Times of image presentations would be “step” because the picture remains the same until the next timepoint. This field is optional, but is useful in providing information about the underlying data. It may inform the way this data is interpreted, the way it is visualized, and what analysis methods are applicable.
|
—starting_time |
Dataset |
Timestamp of the first sample in seconds. When timestamps are uniformly spaced, the timestamp of the first sample can be specified and all subsequent ones calculated from the sampling rate attribute.
|
——rate |
Attribute |
Sampling rate, in Hz.
|
——unit |
Attribute |
Unit of measurement for time, which is fixed to ‘seconds’.
|
—timestamps |
Dataset |
Timestamps for samples stored in data, in seconds, relative to the common experiment master-clock stored in NWBFile.timestamps_reference_time.
|
——interval |
Attribute |
Value is ‘1’
|
——unit |
Attribute |
Unit of measurement for timestamps, which is fixed to ‘seconds’.
|
—control |
Dataset |
Numerical labels that apply to each time point in data for the purpose of querying and slicing data by these values. If present, the length of this array should be the same size as the first dimension of data.
|
—control_description |
Dataset |
Description of each control value. Must be present if control is present. If present, control_description[0] should describe time points where control == 0.
|
Id |
Type |
Description |
---|---|---|
<IntervalSeries> |
Group |
Top level Group for <IntervalSeries>
|
—sync |
Group |
Lab-specific time and sync information as provided directly from hardware devices and that is necessary for aligning all acquired time information to a common timebase. The timestamp array stores time in the common timebase. This group will usually only be populated in TimeSeries that are stored external to the NWB file, in files storing raw data. Once timestamp data is calculated, the contents of ‘sync’ are mostly for archival purposes.
|
2.6.3.1. Groups: sync
Lab-specific time and sync information as provided directly from hardware devices and that is necessary for aligning all acquired time information to a common timebase. The timestamp array stores time in the common timebase. This group will usually only be populated in TimeSeries that are stored external to the NWB file, in files storing raw data. Once timestamp data is calculated, the contents of ‘sync’ are mostly for archival purposes.
Quantity: 0 or 1
Name: sync
2.6.4. DecompositionSeries
Overview: Spectral analysis of a time series, e.g. of an LFP or a speech signal.
DecompositionSeries
extends TimeSeries
and includes all elements of TimeSeries with the following additions or changes.
Extends: TimeSeries
Primitive Type: Group
Inherits from: TimeSeries, NWBDataInterface, NWBContainer, Container
Source filename: nwb.misc.yaml
Source Specification: see Section 3.7.4

Id |
Type |
Description |
---|---|---|
<DecompositionSeries> |
Group |
Top level Group for <DecompositionSeries>
|
—description |
Attribute |
Description of the time series.
|
—comments |
Attribute |
Human-readable comments about the TimeSeries. This second descriptive field can be used to store additional information, or descriptive information if the primary description field is populated with a computer-readable string.
|
—data |
Dataset |
Data decomposed into frequency bands.
|
——unit |
Attribute |
Base unit of measurement for working with the data. Actual stored values are not necessarily stored in these units. To access the data in these units, multiply ‘data’ by ‘conversion’.
|
——conversion |
Attribute |
Scalar to multiply each element in data to convert it to the specified ‘unit’. If the data are stored in acquisition system units or other units that require a conversion to be interpretable, multiply the data by ‘conversion’ to convert the data to the specified ‘unit’. e.g. if the data acquisition system stores values in this object as signed 16-bit integers (int16 range -32,768 to 32,767) that correspond to a 5V range (-2.5V to 2.5V), and the data acquisition system gain is 8000X, then the ‘conversion’ multiplier to get from raw data acquisition values to recorded volts is 2.5/32768/8000 = 9.5367e-9.
|
——offset |
Attribute |
Scalar to add to the data after scaling by ‘conversion’ to finalize its coercion to the specified ‘unit’. Two common examples of this include (a) data stored in an unsigned type that requires a shift after scaling to re-center the data, and (b) specialized recording devices that naturally cause a scalar offset with respect to the true units.
|
——resolution |
Attribute |
Smallest meaningful difference between values in data, stored in the specified by unit, e.g., the change in value of the least significant bit, or a larger number if signal noise is known to be present. If unknown, use -1.0.
|
——continuity |
Attribute |
Optionally describe the continuity of the data. Can be “continuous”, “instantaneous”, or “step”. For example, a voltage trace would be “continuous”, because samples are recorded from a continuous process. An array of lick times would be “instantaneous”, because the data represents distinct moments in time. Times of image presentations would be “step” because the picture remains the same until the next timepoint. This field is optional, but is useful in providing information about the underlying data. It may inform the way this data is interpreted, the way it is visualized, and what analysis methods are applicable.
|
—metric |
Dataset |
The metric used, e.g. phase, amplitude, power.
|
—source_channels |
Dataset |
DynamicTableRegion pointer to the channels that this decomposition series was generated from.
|
—starting_time |
Dataset |
Timestamp of the first sample in seconds. When timestamps are uniformly spaced, the timestamp of the first sample can be specified and all subsequent ones calculated from the sampling rate attribute.
|
——rate |
Attribute |
Sampling rate, in Hz.
|
——unit |
Attribute |
Unit of measurement for time, which is fixed to ‘seconds’.
|
—timestamps |
Dataset |
Timestamps for samples stored in data, in seconds, relative to the common experiment master-clock stored in NWBFile.timestamps_reference_time.
|
——interval |
Attribute |
Value is ‘1’
|
——unit |
Attribute |
Unit of measurement for timestamps, which is fixed to ‘seconds’.
|
—control |
Dataset |
Numerical labels that apply to each time point in data for the purpose of querying and slicing data by these values. If present, the length of this array should be the same size as the first dimension of data.
|
—control_description |
Dataset |
Description of each control value. Must be present if control is present. If present, control_description[0] should describe time points where control == 0.
|
—source_timeseries |
Link |
Link to TimeSeries object that this data was calculated from. Metadata about electrodes and their position can be read from that ElectricalSeries so it is not necessary to store that information here.
|
Id |
Type |
Description |
---|---|---|
<DecompositionSeries> |
Group |
Top level Group for <DecompositionSeries>
|
—source_timeseries |
Link |
Link to TimeSeries object that this data was calculated from. Metadata about electrodes and their position can be read from that ElectricalSeries so it is not necessary to store that information here.
|
—bands |
Group |
Table for describing the bands that this series was generated from. There should be one row in this table for each band.
|
—sync |
Group |
Lab-specific time and sync information as provided directly from hardware devices and that is necessary for aligning all acquired time information to a common timebase. The timestamp array stores time in the common timebase. This group will usually only be populated in TimeSeries that are stored external to the NWB file, in files storing raw data. Once timestamp data is calculated, the contents of ‘sync’ are mostly for archival purposes.
|
2.6.4.1. Groups: bands
Table for describing the bands that this series was generated from. There should be one row in this table for each band.
Extends: DynamicTable
Name: bands
Id |
Type |
Description |
---|---|---|
bands |
Group |
Top level Group for bands
|
—band_name |
Dataset |
Name of the band, e.g. theta.
|
—band_limits |
Dataset |
Low and high limit of each band in Hz. If it is a Gaussian filter, use 2 SD on either side of the center.
|
—band_mean |
Dataset |
The mean Gaussian filters, in Hz.
|
—band_stdev |
Dataset |
The standard deviation of Gaussian filters, in Hz.
|
2.6.4.2. Groups: sync
Lab-specific time and sync information as provided directly from hardware devices and that is necessary for aligning all acquired time information to a common timebase. The timestamp array stores time in the common timebase. This group will usually only be populated in TimeSeries that are stored external to the NWB file, in files storing raw data. Once timestamp data is calculated, the contents of ‘sync’ are mostly for archival purposes.
Quantity: 0 or 1
Name: sync
2.6.5. Units
Overview: Data about spiking units. Event times of observed units (e.g. cell, synapse, etc.) should be concatenated and stored in spike_times.
Units
extends DynamicTable
and includes all elements of DynamicTable with the following additions or changes.
Extends: DynamicTable
Primitive Type: Group
Default Name: Units
Inherits from: DynamicTable, Container
Source filename: nwb.misc.yaml
Source Specification: see Section 3.7.5

Id |
Type |
Description |
---|---|---|
<Units> |
Group |
Top level Group for <Units>
|
—colnames |
Attribute |
The names of the columns in this table. This should be used to specify an order to the columns.
|
—description |
Attribute |
Description of what is in this dynamic table.
|
—spike_times_index |
Dataset |
Index into the spike_times dataset.
|
—spike_times |
Dataset |
Spike times for each unit in seconds.
|
——resolution |
Attribute |
The smallest possible difference between two spike times. Usually 1 divided by the acquisition sampling rate from which spike times were extracted, but could be larger if the acquisition time series was downsampled or smaller if the acquisition time series was smoothed/interpolated and it is possible for the spike time to be between samples.
|
—obs_intervals_index |
Dataset |
Index into the obs_intervals dataset.
|
—obs_intervals |
Dataset |
Observation intervals for each unit.
|
—electrodes_index |
Dataset |
Index into electrodes.
|
—electrodes |
Dataset |
Electrode that each spike unit came from, specified using a DynamicTableRegion.
|
—electrode_group |
Dataset |
Electrode group that each spike unit came from.
|
—waveform_mean |
Dataset |
Spike waveform mean for each spike unit.
|
——sampling_rate |
Attribute |
Sampling rate, in hertz.
|
——unit |
Attribute |
Unit of measurement. This value is fixed to ‘volts’.
|
—waveform_sd |
Dataset |
Spike waveform standard deviation for each spike unit.
|
——sampling_rate |
Attribute |
Sampling rate, in hertz.
|
——unit |
Attribute |
Unit of measurement. This value is fixed to ‘volts’.
|
—waveforms |
Dataset |
Individual waveforms for each spike on each electrode. This is a doubly indexed column. The ‘waveforms_index’ column indexes which waveforms in this column belong to the same spike event for a given unit, where each waveform was recorded from a different electrode. The ‘waveforms_index_index’ column indexes the ‘waveforms_index’ column to indicate which spike events belong to a given unit. For example, if the ‘waveforms_index_index’ column has values [2, 5, 6], then the first 2 elements of the ‘waveforms_index’ column correspond to the 2 spike events of the first unit, the next 3 elements of the ‘waveforms_index’ column correspond to the 3 spike events of the second unit, and the next 1 element of the ‘waveforms_index’ column corresponds to the 1 spike event of the third unit. If the ‘waveforms_index’ column has values [3, 6, 8, 10, 12, 13], then the first 3 elements of the ‘waveforms’ column contain the 3 spike waveforms that were recorded from 3 different electrodes for the first spike time of the first unit. See https://nwb-schema.readthedocs.io/en/stable/format_description.html#doubly-ragged-arrays for a graphical representation of this example. When there is only one electrode for each unit (i.e., each spike time is associated with a single waveform), then the ‘waveforms_index’ column will have values 1, 2, …, N, where N is the number of spike events. The number of electrodes for each spike event should be the same within a given unit. The ‘electrodes’ column should be used to indicate which electrodes are associated with each unit, and the order of the waveforms within a given unit x spike event should be the same as the order of the electrodes referenced in the ‘electrodes’ column of this table. The number of samples for each waveform must be the same.
|
——sampling_rate |
Attribute |
Sampling rate, in hertz.
|
——unit |
Attribute |
Unit of measurement. This value is fixed to ‘volts’.
|
—waveforms_index |
Dataset |
Index into the ‘waveforms’ dataset. One value for every spike event. See ‘waveforms’ for more detail.
|
—waveforms_index_index |
Dataset |
Index into the ‘waveforms_index’ dataset. One value for every unit (row in the table). See ‘waveforms’ for more detail.
|
—id |
Dataset |
Array of unique identifiers for the rows of this dynamic table.
|
—<VectorData> |
Dataset |
Vector columns, including index columns, of this dynamic table.
|
2.7. Behavior
This source module contains neurodata_types for behavior data.
2.7.1. SpatialSeries
Overview: Direction, e.g., of gaze or travel, or position. The TimeSeries::data field is a 2D array storing position or direction relative to some reference frame. Array structure: [num measurements] [num dimensions]. Each SpatialSeries has a text dataset reference_frame that indicates the zero-position, or the zero-axes for direction. For example, if representing gaze direction, ‘straight-ahead’ might be a specific pixel on the monitor, or some other point in space. For position data, the 0,0 point might be the top-left corner of an enclosure, as viewed from the tracking camera. The unit of data will indicate how to interpret SpatialSeries values.
SpatialSeries
extends TimeSeries
and includes all elements of TimeSeries with the following additions or changes.
Extends: TimeSeries
Primitive Type: Group
Inherits from: TimeSeries, NWBDataInterface, NWBContainer, Container
Source filename: nwb.behavior.yaml
Source Specification: see Section 3.8.1

Id |
Type |
Description |
---|---|---|
<SpatialSeries> |
Group |
Top level Group for <SpatialSeries>
|
—description |
Attribute |
Description of the time series.
|
—comments |
Attribute |
Human-readable comments about the TimeSeries. This second descriptive field can be used to store additional information, or descriptive information if the primary description field is populated with a computer-readable string.
|
—data |
Dataset |
1-D or 2-D array storing position or direction relative to some reference frame.
|
——unit |
Attribute |
Base unit of measurement for working with the data. The default value is ‘meters’. Actual stored values are not necessarily stored in these units. To access the data in these units, multiply ‘data’ by ‘conversion’ and add ‘offset’.
|
——conversion |
Attribute |
Scalar to multiply each element in data to convert it to the specified ‘unit’. If the data are stored in acquisition system units or other units that require a conversion to be interpretable, multiply the data by ‘conversion’ to convert the data to the specified ‘unit’. e.g. if the data acquisition system stores values in this object as signed 16-bit integers (int16 range -32,768 to 32,767) that correspond to a 5V range (-2.5V to 2.5V), and the data acquisition system gain is 8000X, then the ‘conversion’ multiplier to get from raw data acquisition values to recorded volts is 2.5/32768/8000 = 9.5367e-9.
|
——offset |
Attribute |
Scalar to add to the data after scaling by ‘conversion’ to finalize its coercion to the specified ‘unit’. Two common examples of this include (a) data stored in an unsigned type that requires a shift after scaling to re-center the data, and (b) specialized recording devices that naturally cause a scalar offset with respect to the true units.
|
——resolution |
Attribute |
Smallest meaningful difference between values in data, stored in the specified by unit, e.g., the change in value of the least significant bit, or a larger number if signal noise is known to be present. If unknown, use -1.0.
|
——continuity |
Attribute |
Optionally describe the continuity of the data. Can be “continuous”, “instantaneous”, or “step”. For example, a voltage trace would be “continuous”, because samples are recorded from a continuous process. An array of lick times would be “instantaneous”, because the data represents distinct moments in time. Times of image presentations would be “step” because the picture remains the same until the next timepoint. This field is optional, but is useful in providing information about the underlying data. It may inform the way this data is interpreted, the way it is visualized, and what analysis methods are applicable.
|
—reference_frame |
Dataset |
Description defining what exactly ‘straight-ahead’ means.
|
—starting_time |
Dataset |
Timestamp of the first sample in seconds. When timestamps are uniformly spaced, the timestamp of the first sample can be specified and all subsequent ones calculated from the sampling rate attribute.
|
——rate |
Attribute |
Sampling rate, in Hz.
|
——unit |
Attribute |
Unit of measurement for time, which is fixed to ‘seconds’.
|
—timestamps |
Dataset |
Timestamps for samples stored in data, in seconds, relative to the common experiment master-clock stored in NWBFile.timestamps_reference_time.
|
——interval |
Attribute |
Value is ‘1’
|
——unit |
Attribute |
Unit of measurement for timestamps, which is fixed to ‘seconds’.
|
—control |
Dataset |
Numerical labels that apply to each time point in data for the purpose of querying and slicing data by these values. If present, the length of this array should be the same size as the first dimension of data.
|
—control_description |
Dataset |
Description of each control value. Must be present if control is present. If present, control_description[0] should describe time points where control == 0.
|
Id |
Type |
Description |
---|---|---|
<SpatialSeries> |
Group |
Top level Group for <SpatialSeries>
|
—sync |
Group |
Lab-specific time and sync information as provided directly from hardware devices and that is necessary for aligning all acquired time information to a common timebase. The timestamp array stores time in the common timebase. This group will usually only be populated in TimeSeries that are stored external to the NWB file, in files storing raw data. Once timestamp data is calculated, the contents of ‘sync’ are mostly for archival purposes.
|
2.7.1.1. Groups: sync
Lab-specific time and sync information as provided directly from hardware devices and that is necessary for aligning all acquired time information to a common timebase. The timestamp array stores time in the common timebase. This group will usually only be populated in TimeSeries that are stored external to the NWB file, in files storing raw data. Once timestamp data is calculated, the contents of ‘sync’ are mostly for archival purposes.
Quantity: 0 or 1
Name: sync
2.7.2. BehavioralEpochs
Overview: TimeSeries for storing behavioral epochs. The objective of this and the other two Behavioral interfaces (e.g. BehavioralEvents and BehavioralTimeSeries) is to provide generic hooks for software tools/scripts. This allows a tool/script to take the output one specific interface (e.g., UnitTimes) and plot that data relative to another data modality (e.g., behavioral events) without having to define all possible modalities in advance. Declaring one of these interfaces means that one or more TimeSeries of the specified type is published. These TimeSeries should reside in a group having the same name as the interface. For example, if a BehavioralTimeSeries interface is declared, the module will have one or more TimeSeries defined in the module sub-group ‘BehavioralTimeSeries’. BehavioralEpochs should use IntervalSeries. BehavioralEvents is used for irregular events. BehavioralTimeSeries is for continuous data.
BehavioralEpochs
extends NWBDataInterface
and includes all elements of NWBDataInterface with the following additions or changes.
Extends: NWBDataInterface
Primitive Type: Group
Default Name: BehavioralEpochs
Inherits from: NWBDataInterface, NWBContainer, Container
Source filename: nwb.behavior.yaml
Source Specification: see Section 3.8.2
Id |
Type |
Description |
---|---|---|
<BehavioralEpochs> |
Group |
Top level Group for <BehavioralEpochs>
|
Group |
IntervalSeries object containing start and stop times of epochs.
|
2.7.2.1. Groups: <IntervalSeries>
IntervalSeries object containing start and stop times of epochs.
Extends: IntervalSeries
Quantity: 0 or more
2.7.3. BehavioralEvents
Overview: TimeSeries for storing behavioral events. See description of <a href=”#BehavioralEpochs”>BehavioralEpochs</a> for more details.
BehavioralEvents
extends NWBDataInterface
and includes all elements of NWBDataInterface with the following additions or changes.
Extends: NWBDataInterface
Primitive Type: Group
Default Name: BehavioralEvents
Inherits from: NWBDataInterface, NWBContainer, Container
Source filename: nwb.behavior.yaml
Source Specification: see Section 3.8.3
Id |
Type |
Description |
---|---|---|
<BehavioralEvents> |
Group |
Top level Group for <BehavioralEvents>
|
—<TimeSeries> |
Group |
TimeSeries object containing behavioral events.
|
2.7.3.1. Groups: <TimeSeries>
TimeSeries object containing behavioral events.
Extends: TimeSeries
Quantity: 0 or more
2.7.4. BehavioralTimeSeries
Overview: TimeSeries for storing Behavoioral time series data. See description of <a href=”#BehavioralEpochs”>BehavioralEpochs</a> for more details.
BehavioralTimeSeries
extends NWBDataInterface
and includes all elements of NWBDataInterface with the following additions or changes.
Extends: NWBDataInterface
Primitive Type: Group
Default Name: BehavioralTimeSeries
Inherits from: NWBDataInterface, NWBContainer, Container
Source filename: nwb.behavior.yaml
Source Specification: see Section 3.8.4
Id |
Type |
Description |
---|---|---|
<BehavioralTimeSeries> |
Group |
Top level Group for <BehavioralTimeSeries>
|
—<TimeSeries> |
Group |
TimeSeries object containing continuous behavioral data.
|
2.7.4.1. Groups: <TimeSeries>
TimeSeries object containing continuous behavioral data.
Extends: TimeSeries
Quantity: 0 or more
2.7.5. PupilTracking
Overview: Eye-tracking data, representing pupil size.
PupilTracking
extends NWBDataInterface
and includes all elements of NWBDataInterface with the following additions or changes.
Extends: NWBDataInterface
Primitive Type: Group
Default Name: PupilTracking
Inherits from: NWBDataInterface, NWBContainer, Container
Source filename: nwb.behavior.yaml
Source Specification: see Section 3.8.5
Id |
Type |
Description |
---|---|---|
<PupilTracking> |
Group |
Top level Group for <PupilTracking>
|
—<TimeSeries> |
Group |
TimeSeries object containing time series data on pupil size.
|
2.7.5.1. Groups: <TimeSeries>
TimeSeries object containing time series data on pupil size.
Extends: TimeSeries
Quantity: 1 or more
2.7.6. EyeTracking
Overview: Eye-tracking data, representing direction of gaze.
EyeTracking
extends NWBDataInterface
and includes all elements of NWBDataInterface with the following additions or changes.
Extends: NWBDataInterface
Primitive Type: Group
Default Name: EyeTracking
Inherits from: NWBDataInterface, NWBContainer, Container
Source filename: nwb.behavior.yaml
Source Specification: see Section 3.8.6
Id |
Type |
Description |
---|---|---|
<EyeTracking> |
Group |
Top level Group for <EyeTracking>
|
Group |
SpatialSeries object containing data measuring direction of gaze.
|
2.7.6.1. Groups: <SpatialSeries>
SpatialSeries object containing data measuring direction of gaze.
Extends: SpatialSeries
Quantity: 0 or more
2.7.7. CompassDirection
Overview: With a CompassDirection interface, a module publishes a SpatialSeries object representing a floating point value for theta. The SpatialSeries::reference_frame field should indicate what direction corresponds to 0 and which is the direction of rotation (this should be clockwise). The si_unit for the SpatialSeries should be radians or degrees.
CompassDirection
extends NWBDataInterface
and includes all elements of NWBDataInterface with the following additions or changes.
Extends: NWBDataInterface
Primitive Type: Group
Default Name: CompassDirection
Inherits from: NWBDataInterface, NWBContainer, Container
Source filename: nwb.behavior.yaml
Source Specification: see Section 3.8.7
Id |
Type |
Description |
---|---|---|
<CompassDirection> |
Group |
Top level Group for <CompassDirection>
|
Group |
SpatialSeries object containing direction of gaze travel.
|
2.7.7.1. Groups: <SpatialSeries>
SpatialSeries object containing direction of gaze travel.
Extends: SpatialSeries
Quantity: 0 or more
2.7.8. Position
Overview: Position data, whether along the x, x/y or x/y/z axis.
Position
extends NWBDataInterface
and includes all elements of NWBDataInterface with the following additions or changes.
Extends: NWBDataInterface
Primitive Type: Group
Default Name: Position
Inherits from: NWBDataInterface, NWBContainer, Container
Source filename: nwb.behavior.yaml
Source Specification: see Section 3.8.8
Id |
Type |
Description |
---|---|---|
<Position> |
Group |
Top level Group for <Position>
|
Group |
SpatialSeries object containing position data.
|
2.7.8.1. Groups: <SpatialSeries>
SpatialSeries object containing position data.
Extends: SpatialSeries
Quantity: 1 or more
2.8. Extracellular electrophysiology
This source module contains neurodata_types for extracellular electrophysiology data.
2.8.1. ElectricalSeries
Overview: A time series of acquired voltage data from extracellular recordings. The data field is an int or float array storing data in volts. The first dimension should always represent time. The second dimension, if present, should represent channels.
ElectricalSeries
extends TimeSeries
and includes all elements of TimeSeries with the following additions or changes.
Extends: TimeSeries
Primitive Type: Group
Inherits from: TimeSeries, NWBDataInterface, NWBContainer, Container
Subtypes: SpikeEventSeries
Source filename: nwb.ecephys.yaml
Source Specification: see Section 3.9.1

Id |
Type |
Description |
---|---|---|
<ElectricalSeries> |
Group |
Top level Group for <ElectricalSeries>
|
—filtering |
Attribute |
Filtering applied to all channels of the data. For example, if this ElectricalSeries represents high-pass-filtered data (also known as AP Band), then this value could be “High-pass 4-pole Bessel filter at 500 Hz”. If this ElectricalSeries represents low-pass-filtered LFP data and the type of filter is unknown, then this value could be “Low-pass filter at 300 Hz”. If a non-standard filter type is used, provide as much detail about the filter properties as possible.
|
—description |
Attribute |
Description of the time series.
|
—comments |
Attribute |
Human-readable comments about the TimeSeries. This second descriptive field can be used to store additional information, or descriptive information if the primary description field is populated with a computer-readable string.
|
—data |
Dataset |
Recorded voltage data.
|
——unit |
Attribute |
Base unit of measurement for working with the data. This value is fixed to ‘volts’. Actual stored values are not necessarily stored in these units. To access the data in these units, multiply ‘data’ by ‘conversion’, followed by ‘channel_conversion’ (if present), and then add ‘offset’.
|
——conversion |
Attribute |
Scalar to multiply each element in data to convert it to the specified ‘unit’. If the data are stored in acquisition system units or other units that require a conversion to be interpretable, multiply the data by ‘conversion’ to convert the data to the specified ‘unit’. e.g. if the data acquisition system stores values in this object as signed 16-bit integers (int16 range -32,768 to 32,767) that correspond to a 5V range (-2.5V to 2.5V), and the data acquisition system gain is 8000X, then the ‘conversion’ multiplier to get from raw data acquisition values to recorded volts is 2.5/32768/8000 = 9.5367e-9.
|
——offset |
Attribute |
Scalar to add to the data after scaling by ‘conversion’ to finalize its coercion to the specified ‘unit’. Two common examples of this include (a) data stored in an unsigned type that requires a shift after scaling to re-center the data, and (b) specialized recording devices that naturally cause a scalar offset with respect to the true units.
|
——resolution |
Attribute |
Smallest meaningful difference between values in data, stored in the specified by unit, e.g., the change in value of the least significant bit, or a larger number if signal noise is known to be present. If unknown, use -1.0.
|
——continuity |
Attribute |
Optionally describe the continuity of the data. Can be “continuous”, “instantaneous”, or “step”. For example, a voltage trace would be “continuous”, because samples are recorded from a continuous process. An array of lick times would be “instantaneous”, because the data represents distinct moments in time. Times of image presentations would be “step” because the picture remains the same until the next timepoint. This field is optional, but is useful in providing information about the underlying data. It may inform the way this data is interpreted, the way it is visualized, and what analysis methods are applicable.
|
—electrodes |
Dataset |
DynamicTableRegion pointer to the electrodes that this time series was generated from.
|
—channel_conversion |
Dataset |
Channel-specific conversion factor. Multiply the data in the ‘data’ dataset by these values along the channel axis (as indicated by axis attribute) AND by the global conversion factor in the ‘conversion’ attribute of ‘data’ to get the data values in Volts, i.e, data in Volts = data * data.conversion * channel_conversion. This approach allows for both global and per-channel data conversion factors needed to support the storage of electrical recordings as native values generated by data acquisition systems. If this dataset is not present, then there is no channel-specific conversion factor, i.e. it is 1 for all channels.
|
——axis |
Attribute |
The zero-indexed axis of the ‘data’ dataset that the channel-specific conversion factor corresponds to. This value is fixed to 1.
|
—starting_time |
Dataset |
Timestamp of the first sample in seconds. When timestamps are uniformly spaced, the timestamp of the first sample can be specified and all subsequent ones calculated from the sampling rate attribute.
|
——rate |
Attribute |
Sampling rate, in Hz.
|
——unit |
Attribute |
Unit of measurement for time, which is fixed to ‘seconds’.
|
—timestamps |
Dataset |
Timestamps for samples stored in data, in seconds, relative to the common experiment master-clock stored in NWBFile.timestamps_reference_time.
|
——interval |
Attribute |
Value is ‘1’
|
——unit |
Attribute |
Unit of measurement for timestamps, which is fixed to ‘seconds’.
|
—control |
Dataset |
Numerical labels that apply to each time point in data for the purpose of querying and slicing data by these values. If present, the length of this array should be the same size as the first dimension of data.
|
—control_description |
Dataset |
Description of each control value. Must be present if control is present. If present, control_description[0] should describe time points where control == 0.
|
Id |
Type |
Description |
---|---|---|
<ElectricalSeries> |
Group |
Top level Group for <ElectricalSeries>
|
—sync |
Group |
Lab-specific time and sync information as provided directly from hardware devices and that is necessary for aligning all acquired time information to a common timebase. The timestamp array stores time in the common timebase. This group will usually only be populated in TimeSeries that are stored external to the NWB file, in files storing raw data. Once timestamp data is calculated, the contents of ‘sync’ are mostly for archival purposes.
|
2.8.1.1. Groups: sync
Lab-specific time and sync information as provided directly from hardware devices and that is necessary for aligning all acquired time information to a common timebase. The timestamp array stores time in the common timebase. This group will usually only be populated in TimeSeries that are stored external to the NWB file, in files storing raw data. Once timestamp data is calculated, the contents of ‘sync’ are mostly for archival purposes.
Quantity: 0 or 1
Name: sync
2.8.2. SpikeEventSeries
Overview: Stores snapshots/snippets of recorded spike events (i.e., threshold crossings). This may also be raw data, as reported by ephys hardware. If so, the TimeSeries::description field should describe how events were detected. All events span the same recording channels and store snapshots of equal duration. TimeSeries::data array structure: [num events] [num channels] [num samples] (or [num events] [num samples] for single electrode).
SpikeEventSeries
extends ElectricalSeries
and includes all elements of ElectricalSeries with the following additions or changes.
Extends: ElectricalSeries
Primitive Type: Group
Inherits from: ElectricalSeries, TimeSeries, NWBDataInterface, NWBContainer, Container
Source filename: nwb.ecephys.yaml
Source Specification: see Section 3.9.2

Id |
Type |
Description |
---|---|---|
<SpikeEventSeries> |
Group |
Top level Group for <SpikeEventSeries>
|
—filtering |
Attribute |
Filtering applied to all channels of the data. For example, if this ElectricalSeries represents high-pass-filtered data (also known as AP Band), then this value could be “High-pass 4-pole Bessel filter at 500 Hz”. If this ElectricalSeries represents low-pass-filtered LFP data and the type of filter is unknown, then this value could be “Low-pass filter at 300 Hz”. If a non-standard filter type is used, provide as much detail about the filter properties as possible.
|
—description |
Attribute |
Description of the time series.
|
—comments |
Attribute |
Human-readable comments about the TimeSeries. This second descriptive field can be used to store additional information, or descriptive information if the primary description field is populated with a computer-readable string.
|
—data |
Dataset |
Spike waveforms.
|
——unit |
Attribute |
Unit of measurement for waveforms, which is fixed to ‘volts’.
|
——conversion |
Attribute |
Scalar to multiply each element in data to convert it to the specified ‘unit’. If the data are stored in acquisition system units or other units that require a conversion to be interpretable, multiply the data by ‘conversion’ to convert the data to the specified ‘unit’. e.g. if the data acquisition system stores values in this object as signed 16-bit integers (int16 range -32,768 to 32,767) that correspond to a 5V range (-2.5V to 2.5V), and the data acquisition system gain is 8000X, then the ‘conversion’ multiplier to get from raw data acquisition values to recorded volts is 2.5/32768/8000 = 9.5367e-9.
|
——offset |
Attribute |
Scalar to add to the data after scaling by ‘conversion’ to finalize its coercion to the specified ‘unit’. Two common examples of this include (a) data stored in an unsigned type that requires a shift after scaling to re-center the data, and (b) specialized recording devices that naturally cause a scalar offset with respect to the true units.
|
——resolution |
Attribute |
Smallest meaningful difference between values in data, stored in the specified by unit, e.g., the change in value of the least significant bit, or a larger number if signal noise is known to be present. If unknown, use -1.0.
|
——continuity |
Attribute |
Optionally describe the continuity of the data. Can be “continuous”, “instantaneous”, or “step”. For example, a voltage trace would be “continuous”, because samples are recorded from a continuous process. An array of lick times would be “instantaneous”, because the data represents distinct moments in time. Times of image presentations would be “step” because the picture remains the same until the next timepoint. This field is optional, but is useful in providing information about the underlying data. It may inform the way this data is interpreted, the way it is visualized, and what analysis methods are applicable.
|
—timestamps |
Dataset |
Timestamps for samples stored in data, in seconds, relative to the common experiment master-clock stored in NWBFile.timestamps_reference_time. Timestamps are required for the events. Unlike for TimeSeries, timestamps are required for SpikeEventSeries and are thus re-specified here.
|
——interval |
Attribute |
Value is ‘1’
|
——unit |
Attribute |
Unit of measurement for timestamps, which is fixed to ‘seconds’.
|
—electrodes |
Dataset |
DynamicTableRegion pointer to the electrodes that this time series was generated from.
|
—channel_conversion |
Dataset |
Channel-specific conversion factor. Multiply the data in the ‘data’ dataset by these values along the channel axis (as indicated by axis attribute) AND by the global conversion factor in the ‘conversion’ attribute of ‘data’ to get the data values in Volts, i.e, data in Volts = data * data.conversion * channel_conversion. This approach allows for both global and per-channel data conversion factors needed to support the storage of electrical recordings as native values generated by data acquisition systems. If this dataset is not present, then there is no channel-specific conversion factor, i.e. it is 1 for all channels.
|
——axis |
Attribute |
The zero-indexed axis of the ‘data’ dataset that the channel-specific conversion factor corresponds to. This value is fixed to 1.
|
—starting_time |
Dataset |
Timestamp of the first sample in seconds. When timestamps are uniformly spaced, the timestamp of the first sample can be specified and all subsequent ones calculated from the sampling rate attribute.
|
——rate |
Attribute |
Sampling rate, in Hz.
|
——unit |
Attribute |
Unit of measurement for time, which is fixed to ‘seconds’.
|
—control |
Dataset |
Numerical labels that apply to each time point in data for the purpose of querying and slicing data by these values. If present, the length of this array should be the same size as the first dimension of data.
|
—control_description |
Dataset |
Description of each control value. Must be present if control is present. If present, control_description[0] should describe time points where control == 0.
|
Id |
Type |
Description |
---|---|---|
<SpikeEventSeries> |
Group |
Top level Group for <SpikeEventSeries>
|
—sync |
Group |
Lab-specific time and sync information as provided directly from hardware devices and that is necessary for aligning all acquired time information to a common timebase. The timestamp array stores time in the common timebase. This group will usually only be populated in TimeSeries that are stored external to the NWB file, in files storing raw data. Once timestamp data is calculated, the contents of ‘sync’ are mostly for archival purposes.
|
2.8.2.1. Groups: sync
Lab-specific time and sync information as provided directly from hardware devices and that is necessary for aligning all acquired time information to a common timebase. The timestamp array stores time in the common timebase. This group will usually only be populated in TimeSeries that are stored external to the NWB file, in files storing raw data. Once timestamp data is calculated, the contents of ‘sync’ are mostly for archival purposes.
Quantity: 0 or 1
Name: sync
2.8.3. FeatureExtraction
Overview: Features, such as PC1 and PC2, that are extracted from signals stored in a SpikeEventSeries or other source.
FeatureExtraction
extends NWBDataInterface
and includes all elements of NWBDataInterface with the following additions or changes.
Extends: NWBDataInterface
Primitive Type: Group
Default Name: FeatureExtraction
Inherits from: NWBDataInterface, NWBContainer, Container
Source filename: nwb.ecephys.yaml
Source Specification: see Section 3.9.3

Id |
Type |
Description |
---|---|---|
<FeatureExtraction> |
Group |
Top level Group for <FeatureExtraction>
|
—description |
Dataset |
Description of features (eg, ‘’PC1’’) for each of the extracted features.
|
—features |
Dataset |
Multi-dimensional array of features extracted from each event.
|
—times |
Dataset |
Times of events that features correspond to (can be a link).
|
—electrodes |
Dataset |
DynamicTableRegion pointer to the electrodes that this time series was generated from.
|
2.8.4. EventDetection
Overview: Detected spike events from voltage trace(s).
EventDetection
extends NWBDataInterface
and includes all elements of NWBDataInterface with the following additions or changes.
Extends: NWBDataInterface
Primitive Type: Group
Default Name: EventDetection
Inherits from: NWBDataInterface, NWBContainer, Container
Source filename: nwb.ecephys.yaml
Source Specification: see Section 3.9.4

Id |
Type |
Description |
---|---|---|
<EventDetection> |
Group |
Top level Group for <EventDetection>
|
—detection_method |
Dataset |
Description of how events were detected, such as voltage threshold, or dV/dT threshold, as well as relevant values.
|
—source_idx |
Dataset |
Indices (zero-based) into source ElectricalSeries::data array corresponding to time of event. ‘’description’’ should define what is meant by time of event (e.g., .25 ms before action potential peak, zero-crossing time, etc). The index points to each event from the raw data.
|
—times |
Dataset |
Timestamps of events, in seconds.
|
——unit |
Attribute |
Unit of measurement for event times, which is fixed to ‘seconds’.
|
—source_electricalseries |
Link |
Link to the ElectricalSeries that this data was calculated from. Metadata about electrodes and their position can be read from that ElectricalSeries so it’s not necessary to include that information here.
|
Id |
Type |
Description |
---|---|---|
<EventDetection> |
Group |
Top level Group for <EventDetection>
|
—source_electricalseries |
Link |
Link to the ElectricalSeries that this data was calculated from. Metadata about electrodes and their position can be read from that ElectricalSeries so it’s not necessary to include that information here.
|
2.8.5. EventWaveform
Overview: DEPRECATED. Represents either the waveforms of detected events, as extracted from a raw data trace in /acquisition, or the event waveforms that were stored during experiment acquisition.
EventWaveform
extends NWBDataInterface
and includes all elements of NWBDataInterface with the following additions or changes.
Extends: NWBDataInterface
Primitive Type: Group
Default Name: EventWaveform
Inherits from: NWBDataInterface, NWBContainer, Container
Source filename: nwb.ecephys.yaml
Source Specification: see Section 3.9.5
Id |
Type |
Description |
---|---|---|
<EventWaveform> |
Group |
Top level Group for <EventWaveform>
|
Group |
SpikeEventSeries object(s) containing detected spike event waveforms.
|
2.8.5.1. Groups: <SpikeEventSeries>
SpikeEventSeries object(s) containing detected spike event waveforms.
Extends: SpikeEventSeries
Quantity: 0 or more
2.8.6. FilteredEphys
Overview: Electrophysiology data from one or more channels that has been subjected to filtering. Examples of filtered data include Theta and Gamma (LFP has its own interface). FilteredEphys modules publish an ElectricalSeries for each filtered channel or set of channels. The name of each ElectricalSeries is arbitrary but should be informative. The source of the filtered data, whether this is from analysis of another time series or as acquired by hardware, should be noted in each’s TimeSeries::description field. There is no assumed 1::1 correspondence between filtered ephys signals and electrodes, as a single signal can apply to many nearby electrodes, and one electrode may have different filtered (e.g., theta and/or gamma) signals represented. Filter properties should be noted in the ElectricalSeries ‘filtering’ attribute.
FilteredEphys
extends NWBDataInterface
and includes all elements of NWBDataInterface with the following additions or changes.
Extends: NWBDataInterface
Primitive Type: Group
Default Name: FilteredEphys
Inherits from: NWBDataInterface, NWBContainer, Container
Source filename: nwb.ecephys.yaml
Source Specification: see Section 3.9.6
Id |
Type |
Description |
---|---|---|
<FilteredEphys> |
Group |
Top level Group for <FilteredEphys>
|
Group |
ElectricalSeries object(s) containing filtered electrophysiology data.
|
2.8.6.1. Groups: <ElectricalSeries>
ElectricalSeries object(s) containing filtered electrophysiology data.
Extends: ElectricalSeries
Quantity: 1 or more
2.8.7. LFP
Overview: LFP data from one or more channels. The electrode map in each published ElectricalSeries will identify which channels are providing LFP data. Filter properties should be noted in the ElectricalSeries ‘filtering’ attribute.
LFP
extends NWBDataInterface
and includes all elements of NWBDataInterface with the following additions or changes.
Extends: NWBDataInterface
Primitive Type: Group
Default Name: LFP
Inherits from: NWBDataInterface, NWBContainer, Container
Source filename: nwb.ecephys.yaml
Source Specification: see Section 3.9.7
Id |
Type |
Description |
---|---|---|
<LFP> |
Group |
Top level Group for <LFP>
|
Group |
ElectricalSeries object(s) containing LFP data for one or more channels.
|
2.8.7.1. Groups: <ElectricalSeries>
ElectricalSeries object(s) containing LFP data for one or more channels.
Extends: ElectricalSeries
Quantity: 1 or more
2.8.8. ElectrodeGroup
Overview: A physical grouping of electrodes, e.g. a shank of an array.
ElectrodeGroup
extends NWBContainer
and includes all elements of NWBContainer with the following additions or changes.
Extends: NWBContainer
Primitive Type: Group
Inherits from: NWBContainer, Container
Source filename: nwb.ecephys.yaml
Source Specification: see Section 3.9.8

Id |
Type |
Description |
---|---|---|
<ElectrodeGroup> |
Group |
Top level Group for <ElectrodeGroup>
|
—description |
Attribute |
Description of this electrode group.
|
—location |
Attribute |
Location of electrode group. Specify the area, layer, comments on estimation of area/layer, etc. Use standard atlas names for anatomical regions when possible.
|
—position |
Dataset |
stereotaxic or common framework coordinates
|
—device |
Link |
Link to the device that was used to record from this electrode group.
|
Id |
Type |
Description |
---|---|---|
<ElectrodeGroup> |
Group |
Top level Group for <ElectrodeGroup>
|
—device |
Link |
Link to the device that was used to record from this electrode group.
|
2.8.9. ClusterWaveforms
Overview: DEPRECATED The mean waveform shape, including standard deviation, of the different clusters. Ideally, the waveform analysis should be performed on data that is only high-pass filtered. This is a separate module because it is expected to require updating. For example, IMEC probes may require different storage requirements to store/display mean waveforms, requiring a new interface or an extension of this one.
ClusterWaveforms
extends NWBDataInterface
and includes all elements of NWBDataInterface with the following additions or changes.
Extends: NWBDataInterface
Primitive Type: Group
Default Name: ClusterWaveforms
Inherits from: NWBDataInterface, NWBContainer, Container
Source filename: nwb.ecephys.yaml
Source Specification: see Section 3.9.9

Id |
Type |
Description |
---|---|---|
<ClusterWaveforms> |
Group |
Top level Group for <ClusterWaveforms>
|
—waveform_filtering |
Dataset |
Filtering applied to data before generating mean/sd
|
—waveform_mean |
Dataset |
The mean waveform for each cluster, using the same indices for each wave as cluster numbers in the associated Clustering module (i.e, cluster 3 is in array slot [3]). Waveforms corresponding to gaps in cluster sequence should be empty (e.g., zero- filled)
|
—waveform_sd |
Dataset |
Stdev of waveforms for each cluster, using the same indices as in mean
|
—clustering_interface |
Link |
Link to Clustering interface that was the source of the clustered data
|
Id |
Type |
Description |
---|---|---|
<ClusterWaveforms> |
Group |
Top level Group for <ClusterWaveforms>
|
—clustering_interface |
Link |
Link to Clustering interface that was the source of the clustered data
|
2.8.10. Clustering
Overview: DEPRECATED Clustered spike data, whether from automatic clustering tools (e.g., klustakwik) or as a result of manual sorting.
Clustering
extends NWBDataInterface
and includes all elements of NWBDataInterface with the following additions or changes.
Extends: NWBDataInterface
Primitive Type: Group
Default Name: Clustering
Inherits from: NWBDataInterface, NWBContainer, Container
Source filename: nwb.ecephys.yaml
Source Specification: see Section 3.9.10

Id |
Type |
Description |
---|---|---|
<Clustering> |
Group |
Top level Group for <Clustering>
|
—description |
Dataset |
Description of clusters or clustering, (e.g. cluster 0 is noise, clusters curated using Klusters, etc)
|
—num |
Dataset |
Cluster number of each event
|
—peak_over_rms |
Dataset |
Maximum ratio of waveform peak to RMS on any channel in the cluster (provides a basic clustering metric).
|
—times |
Dataset |
Times of clustered events, in seconds. This may be a link to times field in associated FeatureExtraction module.
|
2.9. Intracellular electrophysiology
This source module contains neurodata_types for intracellular electrophysiology data.
2.9.1. PatchClampSeries
Overview: An abstract base class for patch-clamp data - stimulus or response, current or voltage.
PatchClampSeries
extends TimeSeries
and includes all elements of TimeSeries with the following additions or changes.
Extends: TimeSeries
Primitive Type: Group
Inherits from: TimeSeries, NWBDataInterface, NWBContainer, Container
Subtypes: VoltageClampStimulusSeries, CurrentClampStimulusSeries, CurrentClampSeries, VoltageClampSeries, IZeroClampSeries
Source filename: nwb.icephys.yaml
Source Specification: see Section 3.10.1

Id |
Type |
Description |
---|---|---|
<PatchClampSeries> |
Group |
Top level Group for <PatchClampSeries>
|
—stimulus_description |
Attribute |
Protocol/stimulus name for this patch-clamp dataset.
|
—sweep_number |
Attribute |
Sweep number, allows to group different PatchClampSeries together.
|
—description |
Attribute |
Description of the time series.
|
—comments |
Attribute |
Human-readable comments about the TimeSeries. This second descriptive field can be used to store additional information, or descriptive information if the primary description field is populated with a computer-readable string.
|
—data |
Dataset |
Recorded voltage or current.
|
——unit |
Attribute |
Base unit of measurement for working with the data. Actual stored values are not necessarily stored in these units. To access the data in these units, multiply ‘data’ by ‘conversion’ and add ‘offset’.
|
——conversion |
Attribute |
Scalar to multiply each element in data to convert it to the specified ‘unit’. If the data are stored in acquisition system units or other units that require a conversion to be interpretable, multiply the data by ‘conversion’ to convert the data to the specified ‘unit’. e.g. if the data acquisition system stores values in this object as signed 16-bit integers (int16 range -32,768 to 32,767) that correspond to a 5V range (-2.5V to 2.5V), and the data acquisition system gain is 8000X, then the ‘conversion’ multiplier to get from raw data acquisition values to recorded volts is 2.5/32768/8000 = 9.5367e-9.
|
——offset |
Attribute |
Scalar to add to the data after scaling by ‘conversion’ to finalize its coercion to the specified ‘unit’. Two common examples of this include (a) data stored in an unsigned type that requires a shift after scaling to re-center the data, and (b) specialized recording devices that naturally cause a scalar offset with respect to the true units.
|
——resolution |
Attribute |
Smallest meaningful difference between values in data, stored in the specified by unit, e.g., the change in value of the least significant bit, or a larger number if signal noise is known to be present. If unknown, use -1.0.
|
——continuity |
Attribute |
Optionally describe the continuity of the data. Can be “continuous”, “instantaneous”, or “step”. For example, a voltage trace would be “continuous”, because samples are recorded from a continuous process. An array of lick times would be “instantaneous”, because the data represents distinct moments in time. Times of image presentations would be “step” because the picture remains the same until the next timepoint. This field is optional, but is useful in providing information about the underlying data. It may inform the way this data is interpreted, the way it is visualized, and what analysis methods are applicable.
|
—gain |
Dataset |
Gain of the recording, in units Volt/Amp (v-clamp) or Volt/Volt (c-clamp).
|
—starting_time |
Dataset |
Timestamp of the first sample in seconds. When timestamps are uniformly spaced, the timestamp of the first sample can be specified and all subsequent ones calculated from the sampling rate attribute.
|
——rate |
Attribute |
Sampling rate, in Hz.
|
——unit |
Attribute |
Unit of measurement for time, which is fixed to ‘seconds’.
|
—timestamps |
Dataset |
Timestamps for samples stored in data, in seconds, relative to the common experiment master-clock stored in NWBFile.timestamps_reference_time.
|
——interval |
Attribute |
Value is ‘1’
|
——unit |
Attribute |
Unit of measurement for timestamps, which is fixed to ‘seconds’.
|
—control |
Dataset |
Numerical labels that apply to each time point in data for the purpose of querying and slicing data by these values. If present, the length of this array should be the same size as the first dimension of data.
|
—control_description |
Dataset |
Description of each control value. Must be present if control is present. If present, control_description[0] should describe time points where control == 0.
|
—electrode |
Link |
Link to IntracellularElectrode object that describes the electrode that was used to apply or record this data.
|
Id |
Type |
Description |
---|---|---|
<PatchClampSeries> |
Group |
Top level Group for <PatchClampSeries>
|
—electrode |
Link |
Link to IntracellularElectrode object that describes the electrode that was used to apply or record this data.
|
—sync |
Group |
Lab-specific time and sync information as provided directly from hardware devices and that is necessary for aligning all acquired time information to a common timebase. The timestamp array stores time in the common timebase. This group will usually only be populated in TimeSeries that are stored external to the NWB file, in files storing raw data. Once timestamp data is calculated, the contents of ‘sync’ are mostly for archival purposes.
|
2.9.1.1. Groups: sync
Lab-specific time and sync information as provided directly from hardware devices and that is necessary for aligning all acquired time information to a common timebase. The timestamp array stores time in the common timebase. This group will usually only be populated in TimeSeries that are stored external to the NWB file, in files storing raw data. Once timestamp data is calculated, the contents of ‘sync’ are mostly for archival purposes.
Quantity: 0 or 1
Name: sync
2.9.2. CurrentClampSeries
Overview: Voltage data from an intracellular current-clamp recording. A corresponding CurrentClampStimulusSeries (stored separately as a stimulus) is used to store the current injected.
CurrentClampSeries
extends PatchClampSeries
and includes all elements of PatchClampSeries with the following additions or changes.
Extends: PatchClampSeries
Primitive Type: Group
Inherits from: PatchClampSeries, TimeSeries, NWBDataInterface, NWBContainer, Container
Subtypes: IZeroClampSeries
Source filename: nwb.icephys.yaml
Source Specification: see Section 3.10.2

Id |
Type |
Description |
---|---|---|
<CurrentClampSeries> |
Group |
Top level Group for <CurrentClampSeries>
|
—stimulus_description |
Attribute |
Protocol/stimulus name for this patch-clamp dataset.
|
—sweep_number |
Attribute |
Sweep number, allows to group different PatchClampSeries together.
|
—description |
Attribute |
Description of the time series.
|
—comments |
Attribute |
Human-readable comments about the TimeSeries. This second descriptive field can be used to store additional information, or descriptive information if the primary description field is populated with a computer-readable string.
|
—data |
Dataset |
Recorded voltage.
|
——unit |
Attribute |
Base unit of measurement for working with the data. which is fixed to ‘volts’. Actual stored values are not necessarily stored in these units. To access the data in these units, multiply ‘data’ by ‘conversion’ and add ‘offset’.
|
——conversion |
Attribute |
Scalar to multiply each element in data to convert it to the specified ‘unit’. If the data are stored in acquisition system units or other units that require a conversion to be interpretable, multiply the data by ‘conversion’ to convert the data to the specified ‘unit’. e.g. if the data acquisition system stores values in this object as signed 16-bit integers (int16 range -32,768 to 32,767) that correspond to a 5V range (-2.5V to 2.5V), and the data acquisition system gain is 8000X, then the ‘conversion’ multiplier to get from raw data acquisition values to recorded volts is 2.5/32768/8000 = 9.5367e-9.
|
——offset |
Attribute |
Scalar to add to the data after scaling by ‘conversion’ to finalize its coercion to the specified ‘unit’. Two common examples of this include (a) data stored in an unsigned type that requires a shift after scaling to re-center the data, and (b) specialized recording devices that naturally cause a scalar offset with respect to the true units.
|
——resolution |
Attribute |
Smallest meaningful difference between values in data, stored in the specified by unit, e.g., the change in value of the least significant bit, or a larger number if signal noise is known to be present. If unknown, use -1.0.
|
——continuity |
Attribute |
Optionally describe the continuity of the data. Can be “continuous”, “instantaneous”, or “step”. For example, a voltage trace would be “continuous”, because samples are recorded from a continuous process. An array of lick times would be “instantaneous”, because the data represents distinct moments in time. Times of image presentations would be “step” because the picture remains the same until the next timepoint. This field is optional, but is useful in providing information about the underlying data. It may inform the way this data is interpreted, the way it is visualized, and what analysis methods are applicable.
|
—bias_current |
Dataset |
Bias current, in amps.
|
—bridge_balance |
Dataset |
Bridge balance, in ohms.
|
—capacitance_compensation |
Dataset |
Capacitance compensation, in farads.
|
—gain |
Dataset |
Gain of the recording, in units Volt/Amp (v-clamp) or Volt/Volt (c-clamp).
|
—starting_time |
Dataset |
Timestamp of the first sample in seconds. When timestamps are uniformly spaced, the timestamp of the first sample can be specified and all subsequent ones calculated from the sampling rate attribute.
|
——rate |
Attribute |
Sampling rate, in Hz.
|
——unit |
Attribute |
Unit of measurement for time, which is fixed to ‘seconds’.
|
—timestamps |
Dataset |
Timestamps for samples stored in data, in seconds, relative to the common experiment master-clock stored in NWBFile.timestamps_reference_time.
|
——interval |
Attribute |
Value is ‘1’
|
——unit |
Attribute |
Unit of measurement for timestamps, which is fixed to ‘seconds’.
|
—control |
Dataset |
Numerical labels that apply to each time point in data for the purpose of querying and slicing data by these values. If present, the length of this array should be the same size as the first dimension of data.
|
—control_description |
Dataset |
Description of each control value. Must be present if control is present. If present, control_description[0] should describe time points where control == 0.
|
—electrode |
Link |
Link to IntracellularElectrode object that describes the electrode that was used to apply or record this data.
|
Id |
Type |
Description |
---|---|---|
<CurrentClampSeries> |
Group |
Top level Group for <CurrentClampSeries>
|
—electrode |
Link |
Link to IntracellularElectrode object that describes the electrode that was used to apply or record this data.
|
—sync |
Group |
Lab-specific time and sync information as provided directly from hardware devices and that is necessary for aligning all acquired time information to a common timebase. The timestamp array stores time in the common timebase. This group will usually only be populated in TimeSeries that are stored external to the NWB file, in files storing raw data. Once timestamp data is calculated, the contents of ‘sync’ are mostly for archival purposes.
|
2.9.2.1. Groups: sync
Lab-specific time and sync information as provided directly from hardware devices and that is necessary for aligning all acquired time information to a common timebase. The timestamp array stores time in the common timebase. This group will usually only be populated in TimeSeries that are stored external to the NWB file, in files storing raw data. Once timestamp data is calculated, the contents of ‘sync’ are mostly for archival purposes.
Quantity: 0 or 1
Name: sync
2.9.3. IZeroClampSeries
Overview: Voltage data from an intracellular recording when all current and amplifier settings are off (i.e., CurrentClampSeries fields will be zero). There is no CurrentClampStimulusSeries associated with an IZero series because the amplifier is disconnected and no stimulus can reach the cell.
IZeroClampSeries
extends CurrentClampSeries
and includes all elements of CurrentClampSeries with the following additions or changes.
Extends: CurrentClampSeries
Primitive Type: Group
Inherits from: CurrentClampSeries, PatchClampSeries, TimeSeries, NWBDataInterface, NWBContainer, Container
Source filename: nwb.icephys.yaml
Source Specification: see Section 3.10.3

Id |
Type |
Description |
---|---|---|
<IZeroClampSeries> |
Group |
Top level Group for <IZeroClampSeries>
|
—stimulus_description |
Attribute |
An IZeroClampSeries has no stimulus, so this attribute is automatically set to “N/A”
|
—sweep_number |
Attribute |
Sweep number, allows to group different PatchClampSeries together.
|
—description |
Attribute |
Description of the time series.
|
—comments |
Attribute |
Human-readable comments about the TimeSeries. This second descriptive field can be used to store additional information, or descriptive information if the primary description field is populated with a computer-readable string.
|
—bias_current |
Dataset |
Bias current, in amps, fixed to 0.0.
|
—bridge_balance |
Dataset |
Bridge balance, in ohms, fixed to 0.0.
|
—capacitance_compensation |
Dataset |
Capacitance compensation, in farads, fixed to 0.0.
|
—data |
Dataset |
Recorded voltage.
|
——unit |
Attribute |
Base unit of measurement for working with the data. which is fixed to ‘volts’. Actual stored values are not necessarily stored in these units. To access the data in these units, multiply ‘data’ by ‘conversion’ and add ‘offset’.
|
——conversion |
Attribute |
Scalar to multiply each element in data to convert it to the specified ‘unit’. If the data are stored in acquisition system units or other units that require a conversion to be interpretable, multiply the data by ‘conversion’ to convert the data to the specified ‘unit’. e.g. if the data acquisition system stores values in this object as signed 16-bit integers (int16 range -32,768 to 32,767) that correspond to a 5V range (-2.5V to 2.5V), and the data acquisition system gain is 8000X, then the ‘conversion’ multiplier to get from raw data acquisition values to recorded volts is 2.5/32768/8000 = 9.5367e-9.
|
——offset |
Attribute |
Scalar to add to the data after scaling by ‘conversion’ to finalize its coercion to the specified ‘unit’. Two common examples of this include (a) data stored in an unsigned type that requires a shift after scaling to re-center the data, and (b) specialized recording devices that naturally cause a scalar offset with respect to the true units.
|
——resolution |
Attribute |
Smallest meaningful difference between values in data, stored in the specified by unit, e.g., the change in value of the least significant bit, or a larger number if signal noise is known to be present. If unknown, use -1.0.
|
——continuity |
Attribute |
Optionally describe the continuity of the data. Can be “continuous”, “instantaneous”, or “step”. For example, a voltage trace would be “continuous”, because samples are recorded from a continuous process. An array of lick times would be “instantaneous”, because the data represents distinct moments in time. Times of image presentations would be “step” because the picture remains the same until the next timepoint. This field is optional, but is useful in providing information about the underlying data. It may inform the way this data is interpreted, the way it is visualized, and what analysis methods are applicable.
|
—gain |
Dataset |
Gain of the recording, in units Volt/Amp (v-clamp) or Volt/Volt (c-clamp).
|
—starting_time |
Dataset |
Timestamp of the first sample in seconds. When timestamps are uniformly spaced, the timestamp of the first sample can be specified and all subsequent ones calculated from the sampling rate attribute.
|
——rate |
Attribute |
Sampling rate, in Hz.
|
——unit |
Attribute |
Unit of measurement for time, which is fixed to ‘seconds’.
|
—timestamps |
Dataset |
Timestamps for samples stored in data, in seconds, relative to the common experiment master-clock stored in NWBFile.timestamps_reference_time.
|
——interval |
Attribute |
Value is ‘1’
|
——unit |
Attribute |
Unit of measurement for timestamps, which is fixed to ‘seconds’.
|
—control |
Dataset |
Numerical labels that apply to each time point in data for the purpose of querying and slicing data by these values. If present, the length of this array should be the same size as the first dimension of data.
|
—control_description |
Dataset |
Description of each control value. Must be present if control is present. If present, control_description[0] should describe time points where control == 0.
|
—electrode |
Link |
Link to IntracellularElectrode object that describes the electrode that was used to apply or record this data.
|
Id |
Type |
Description |
---|---|---|
<IZeroClampSeries> |
Group |
Top level Group for <IZeroClampSeries>
|
—electrode |
Link |
Link to IntracellularElectrode object that describes the electrode that was used to apply or record this data.
|
—sync |
Group |
Lab-specific time and sync information as provided directly from hardware devices and that is necessary for aligning all acquired time information to a common timebase. The timestamp array stores time in the common timebase. This group will usually only be populated in TimeSeries that are stored external to the NWB file, in files storing raw data. Once timestamp data is calculated, the contents of ‘sync’ are mostly for archival purposes.
|
2.9.3.1. Groups: sync
Lab-specific time and sync information as provided directly from hardware devices and that is necessary for aligning all acquired time information to a common timebase. The timestamp array stores time in the common timebase. This group will usually only be populated in TimeSeries that are stored external to the NWB file, in files storing raw data. Once timestamp data is calculated, the contents of ‘sync’ are mostly for archival purposes.
Quantity: 0 or 1
Name: sync
2.9.4. CurrentClampStimulusSeries
Overview: Stimulus current applied during current clamp recording.
CurrentClampStimulusSeries
extends PatchClampSeries
and includes all elements of PatchClampSeries with the following additions or changes.
Extends: PatchClampSeries
Primitive Type: Group
Inherits from: PatchClampSeries, TimeSeries, NWBDataInterface, NWBContainer, Container
Source filename: nwb.icephys.yaml
Source Specification: see Section 3.10.4

Id |
Type |
Description |
---|---|---|
<CurrentClampStimulusSeries> |
Group |
Top level Group for <CurrentClampStimulusSeries>
|
—stimulus_description |
Attribute |
Protocol/stimulus name for this patch-clamp dataset.
|
—sweep_number |
Attribute |
Sweep number, allows to group different PatchClampSeries together.
|
—description |
Attribute |
Description of the time series.
|
—comments |
Attribute |
Human-readable comments about the TimeSeries. This second descriptive field can be used to store additional information, or descriptive information if the primary description field is populated with a computer-readable string.
|
—data |
Dataset |
Stimulus current applied.
|
——unit |
Attribute |
Base unit of measurement for working with the data. which is fixed to ‘amperes’. Actual stored values are not necessarily stored in these units. To access the data in these units, multiply ‘data’ by ‘conversion’ and add ‘offset’.
|
——conversion |
Attribute |
Scalar to multiply each element in data to convert it to the specified ‘unit’. If the data are stored in acquisition system units or other units that require a conversion to be interpretable, multiply the data by ‘conversion’ to convert the data to the specified ‘unit’. e.g. if the data acquisition system stores values in this object as signed 16-bit integers (int16 range -32,768 to 32,767) that correspond to a 5V range (-2.5V to 2.5V), and the data acquisition system gain is 8000X, then the ‘conversion’ multiplier to get from raw data acquisition values to recorded volts is 2.5/32768/8000 = 9.5367e-9.
|
——offset |
Attribute |
Scalar to add to the data after scaling by ‘conversion’ to finalize its coercion to the specified ‘unit’. Two common examples of this include (a) data stored in an unsigned type that requires a shift after scaling to re-center the data, and (b) specialized recording devices that naturally cause a scalar offset with respect to the true units.
|
——resolution |
Attribute |
Smallest meaningful difference between values in data, stored in the specified by unit, e.g., the change in value of the least significant bit, or a larger number if signal noise is known to be present. If unknown, use -1.0.
|
——continuity |
Attribute |
Optionally describe the continuity of the data. Can be “continuous”, “instantaneous”, or “step”. For example, a voltage trace would be “continuous”, because samples are recorded from a continuous process. An array of lick times would be “instantaneous”, because the data represents distinct moments in time. Times of image presentations would be “step” because the picture remains the same until the next timepoint. This field is optional, but is useful in providing information about the underlying data. It may inform the way this data is interpreted, the way it is visualized, and what analysis methods are applicable.
|
—gain |
Dataset |
Gain of the recording, in units Volt/Amp (v-clamp) or Volt/Volt (c-clamp).
|
—starting_time |
Dataset |
Timestamp of the first sample in seconds. When timestamps are uniformly spaced, the timestamp of the first sample can be specified and all subsequent ones calculated from the sampling rate attribute.
|
——rate |
Attribute |
Sampling rate, in Hz.
|
——unit |
Attribute |
Unit of measurement for time, which is fixed to ‘seconds’.
|
—timestamps |
Dataset |
Timestamps for samples stored in data, in seconds, relative to the common experiment master-clock stored in NWBFile.timestamps_reference_time.
|
——interval |
Attribute |
Value is ‘1’
|
——unit |
Attribute |
Unit of measurement for timestamps, which is fixed to ‘seconds’.
|
—control |
Dataset |
Numerical labels that apply to each time point in data for the purpose of querying and slicing data by these values. If present, the length of this array should be the same size as the first dimension of data.
|
—control_description |
Dataset |
Description of each control value. Must be present if control is present. If present, control_description[0] should describe time points where control == 0.
|
—electrode |
Link |
Link to IntracellularElectrode object that describes the electrode that was used to apply or record this data.
|
Id |
Type |
Description |
---|---|---|
<CurrentClampStimulusSeries> |
Group |
Top level Group for <CurrentClampStimulusSeries>
|
—electrode |
Link |
Link to IntracellularElectrode object that describes the electrode that was used to apply or record this data.
|
—sync |
Group |
Lab-specific time and sync information as provided directly from hardware devices and that is necessary for aligning all acquired time information to a common timebase. The timestamp array stores time in the common timebase. This group will usually only be populated in TimeSeries that are stored external to the NWB file, in files storing raw data. Once timestamp data is calculated, the contents of ‘sync’ are mostly for archival purposes.
|
2.9.4.1. Groups: sync
Lab-specific time and sync information as provided directly from hardware devices and that is necessary for aligning all acquired time information to a common timebase. The timestamp array stores time in the common timebase. This group will usually only be populated in TimeSeries that are stored external to the NWB file, in files storing raw data. Once timestamp data is calculated, the contents of ‘sync’ are mostly for archival purposes.
Quantity: 0 or 1
Name: sync
2.9.5. VoltageClampSeries
Overview: Current data from an intracellular voltage-clamp recording. A corresponding VoltageClampStimulusSeries (stored separately as a stimulus) is used to store the voltage injected.
VoltageClampSeries
extends PatchClampSeries
and includes all elements of PatchClampSeries with the following additions or changes.
Extends: PatchClampSeries
Primitive Type: Group
Inherits from: PatchClampSeries, TimeSeries, NWBDataInterface, NWBContainer, Container
Source filename: nwb.icephys.yaml
Source Specification: see Section 3.10.5

Id |
Type |
Description |
---|---|---|
<VoltageClampSeries> |
Group |
Top level Group for <VoltageClampSeries>
|
—stimulus_description |
Attribute |
Protocol/stimulus name for this patch-clamp dataset.
|
—sweep_number |
Attribute |
Sweep number, allows to group different PatchClampSeries together.
|
—description |
Attribute |
Description of the time series.
|
—comments |
Attribute |
Human-readable comments about the TimeSeries. This second descriptive field can be used to store additional information, or descriptive information if the primary description field is populated with a computer-readable string.
|
—data |
Dataset |
Recorded current.
|
——unit |
Attribute |
Base unit of measurement for working with the data. which is fixed to ‘amperes’. Actual stored values are not necessarily stored in these units. To access the data in these units, multiply ‘data’ by ‘conversion’ and add ‘offset’.
|
——conversion |
Attribute |
Scalar to multiply each element in data to convert it to the specified ‘unit’. If the data are stored in acquisition system units or other units that require a conversion to be interpretable, multiply the data by ‘conversion’ to convert the data to the specified ‘unit’. e.g. if the data acquisition system stores values in this object as signed 16-bit integers (int16 range -32,768 to 32,767) that correspond to a 5V range (-2.5V to 2.5V), and the data acquisition system gain is 8000X, then the ‘conversion’ multiplier to get from raw data acquisition values to recorded volts is 2.5/32768/8000 = 9.5367e-9.
|
——offset |
Attribute |
Scalar to add to the data after scaling by ‘conversion’ to finalize its coercion to the specified ‘unit’. Two common examples of this include (a) data stored in an unsigned type that requires a shift after scaling to re-center the data, and (b) specialized recording devices that naturally cause a scalar offset with respect to the true units.
|
——resolution |
Attribute |
Smallest meaningful difference between values in data, stored in the specified by unit, e.g., the change in value of the least significant bit, or a larger number if signal noise is known to be present. If unknown, use -1.0.
|
——continuity |
Attribute |
Optionally describe the continuity of the data. Can be “continuous”, “instantaneous”, or “step”. For example, a voltage trace would be “continuous”, because samples are recorded from a continuous process. An array of lick times would be “instantaneous”, because the data represents distinct moments in time. Times of image presentations would be “step” because the picture remains the same until the next timepoint. This field is optional, but is useful in providing information about the underlying data. It may inform the way this data is interpreted, the way it is visualized, and what analysis methods are applicable.
|
—capacitance_fast |
Dataset |
Fast capacitance, in farads.
|
——unit |
Attribute |
Unit of measurement for capacitance_fast, which is fixed to ‘farads’.
|
—capacitance_slow |
Dataset |
Slow capacitance, in farads.
|
——unit |
Attribute |
Unit of measurement for capacitance_fast, which is fixed to ‘farads’.
|
—resistance_comp_bandwidth |
Dataset |
Resistance compensation bandwidth, in hertz.
|
——unit |
Attribute |
Unit of measurement for resistance_comp_bandwidth, which is fixed to ‘hertz’.
|
—resistance_comp_correction |
Dataset |
Resistance compensation correction, in percent.
|
——unit |
Attribute |
Unit of measurement for resistance_comp_correction, which is fixed to ‘percent’.
|
—resistance_comp_prediction |
Dataset |
Resistance compensation prediction, in percent.
|
——unit |
Attribute |
Unit of measurement for resistance_comp_prediction, which is fixed to ‘percent’.
|
—whole_cell_capacitance_comp |
Dataset |
Whole cell capacitance compensation, in farads.
|
——unit |
Attribute |
Unit of measurement for whole_cell_capacitance_comp, which is fixed to ‘farads’.
|
—whole_cell_series_resistance_comp |
Dataset |
Whole cell series resistance compensation, in ohms.
|
——unit |
Attribute |
Unit of measurement for whole_cell_series_resistance_comp, which is fixed to ‘ohms’.
|
—gain |
Dataset |
Gain of the recording, in units Volt/Amp (v-clamp) or Volt/Volt (c-clamp).
|
—starting_time |
Dataset |
Timestamp of the first sample in seconds. When timestamps are uniformly spaced, the timestamp of the first sample can be specified and all subsequent ones calculated from the sampling rate attribute.
|
——rate |
Attribute |
Sampling rate, in Hz.
|
——unit |
Attribute |
Unit of measurement for time, which is fixed to ‘seconds’.
|
—timestamps |
Dataset |
Timestamps for samples stored in data, in seconds, relative to the common experiment master-clock stored in NWBFile.timestamps_reference_time.
|
——interval |
Attribute |
Value is ‘1’
|
——unit |
Attribute |
Unit of measurement for timestamps, which is fixed to ‘seconds’.
|
—control |
Dataset |
Numerical labels that apply to each time point in data for the purpose of querying and slicing data by these values. If present, the length of this array should be the same size as the first dimension of data.
|
—control_description |
Dataset |
Description of each control value. Must be present if control is present. If present, control_description[0] should describe time points where control == 0.
|
—electrode |
Link |
Link to IntracellularElectrode object that describes the electrode that was used to apply or record this data.
|
Id |
Type |
Description |
---|---|---|
<VoltageClampSeries> |
Group |
Top level Group for <VoltageClampSeries>
|
—electrode |
Link |
Link to IntracellularElectrode object that describes the electrode that was used to apply or record this data.
|
—sync |
Group |
Lab-specific time and sync information as provided directly from hardware devices and that is necessary for aligning all acquired time information to a common timebase. The timestamp array stores time in the common timebase. This group will usually only be populated in TimeSeries that are stored external to the NWB file, in files storing raw data. Once timestamp data is calculated, the contents of ‘sync’ are mostly for archival purposes.
|
2.9.5.1. Groups: sync
Lab-specific time and sync information as provided directly from hardware devices and that is necessary for aligning all acquired time information to a common timebase. The timestamp array stores time in the common timebase. This group will usually only be populated in TimeSeries that are stored external to the NWB file, in files storing raw data. Once timestamp data is calculated, the contents of ‘sync’ are mostly for archival purposes.
Quantity: 0 or 1
Name: sync
2.9.6. VoltageClampStimulusSeries
Overview: Stimulus voltage applied during a voltage clamp recording.
VoltageClampStimulusSeries
extends PatchClampSeries
and includes all elements of PatchClampSeries with the following additions or changes.
Extends: PatchClampSeries
Primitive Type: Group
Inherits from: PatchClampSeries, TimeSeries, NWBDataInterface, NWBContainer, Container
Source filename: nwb.icephys.yaml
Source Specification: see Section 3.10.6

Id |
Type |
Description |
---|---|---|
<VoltageClampStimulusSeries> |
Group |
Top level Group for <VoltageClampStimulusSeries>
|
—stimulus_description |
Attribute |
Protocol/stimulus name for this patch-clamp dataset.
|
—sweep_number |
Attribute |
Sweep number, allows to group different PatchClampSeries together.
|
—description |
Attribute |
Description of the time series.
|
—comments |
Attribute |
Human-readable comments about the TimeSeries. This second descriptive field can be used to store additional information, or descriptive information if the primary description field is populated with a computer-readable string.
|
—data |
Dataset |
Stimulus voltage applied.
|
——unit |
Attribute |
Base unit of measurement for working with the data. which is fixed to ‘volts’. Actual stored values are not necessarily stored in these units. To access the data in these units, multiply ‘data’ by ‘conversion’ and add ‘offset’.
|
——conversion |
Attribute |
Scalar to multiply each element in data to convert it to the specified ‘unit’. If the data are stored in acquisition system units or other units that require a conversion to be interpretable, multiply the data by ‘conversion’ to convert the data to the specified ‘unit’. e.g. if the data acquisition system stores values in this object as signed 16-bit integers (int16 range -32,768 to 32,767) that correspond to a 5V range (-2.5V to 2.5V), and the data acquisition system gain is 8000X, then the ‘conversion’ multiplier to get from raw data acquisition values to recorded volts is 2.5/32768/8000 = 9.5367e-9.
|
——offset |
Attribute |
Scalar to add to the data after scaling by ‘conversion’ to finalize its coercion to the specified ‘unit’. Two common examples of this include (a) data stored in an unsigned type that requires a shift after scaling to re-center the data, and (b) specialized recording devices that naturally cause a scalar offset with respect to the true units.
|
——resolution |
Attribute |
Smallest meaningful difference between values in data, stored in the specified by unit, e.g., the change in value of the least significant bit, or a larger number if signal noise is known to be present. If unknown, use -1.0.
|
——continuity |
Attribute |
Optionally describe the continuity of the data. Can be “continuous”, “instantaneous”, or “step”. For example, a voltage trace would be “continuous”, because samples are recorded from a continuous process. An array of lick times would be “instantaneous”, because the data represents distinct moments in time. Times of image presentations would be “step” because the picture remains the same until the next timepoint. This field is optional, but is useful in providing information about the underlying data. It may inform the way this data is interpreted, the way it is visualized, and what analysis methods are applicable.
|
—gain |
Dataset |
Gain of the recording, in units Volt/Amp (v-clamp) or Volt/Volt (c-clamp).
|
—starting_time |
Dataset |
Timestamp of the first sample in seconds. When timestamps are uniformly spaced, the timestamp of the first sample can be specified and all subsequent ones calculated from the sampling rate attribute.
|
——rate |
Attribute |
Sampling rate, in Hz.
|
——unit |
Attribute |
Unit of measurement for time, which is fixed to ‘seconds’.
|
—timestamps |
Dataset |
Timestamps for samples stored in data, in seconds, relative to the common experiment master-clock stored in NWBFile.timestamps_reference_time.
|
——interval |
Attribute |
Value is ‘1’
|
——unit |
Attribute |
Unit of measurement for timestamps, which is fixed to ‘seconds’.
|
—control |
Dataset |
Numerical labels that apply to each time point in data for the purpose of querying and slicing data by these values. If present, the length of this array should be the same size as the first dimension of data.
|
—control_description |
Dataset |
Description of each control value. Must be present if control is present. If present, control_description[0] should describe time points where control == 0.
|
—electrode |
Link |
Link to IntracellularElectrode object that describes the electrode that was used to apply or record this data.
|
Id |
Type |
Description |
---|---|---|
<VoltageClampStimulusSeries> |
Group |
Top level Group for <VoltageClampStimulusSeries>
|
—electrode |
Link |
Link to IntracellularElectrode object that describes the electrode that was used to apply or record this data.
|
—sync |
Group |
Lab-specific time and sync information as provided directly from hardware devices and that is necessary for aligning all acquired time information to a common timebase. The timestamp array stores time in the common timebase. This group will usually only be populated in TimeSeries that are stored external to the NWB file, in files storing raw data. Once timestamp data is calculated, the contents of ‘sync’ are mostly for archival purposes.
|
2.9.6.1. Groups: sync
Lab-specific time and sync information as provided directly from hardware devices and that is necessary for aligning all acquired time information to a common timebase. The timestamp array stores time in the common timebase. This group will usually only be populated in TimeSeries that are stored external to the NWB file, in files storing raw data. Once timestamp data is calculated, the contents of ‘sync’ are mostly for archival purposes.
Quantity: 0 or 1
Name: sync
2.9.7. IntracellularElectrode
Overview: An intracellular electrode and its metadata.
IntracellularElectrode
extends NWBContainer
and includes all elements of NWBContainer with the following additions or changes.
Extends: NWBContainer
Primitive Type: Group
Inherits from: NWBContainer, Container
Source filename: nwb.icephys.yaml
Source Specification: see Section 3.10.7

Id |
Type |
Description |
---|---|---|
<IntracellularElectrode> |
Group |
Top level Group for <IntracellularElectrode>
|
—cell_id |
Dataset |
unique ID of the cell
|
—description |
Dataset |
Description of electrode (e.g., whole-cell, sharp, etc.).
|
—filtering |
Dataset |
Electrode specific filtering.
|
—initial_access_resistance |
Dataset |
Initial access resistance.
|
—location |
Dataset |
Location of the electrode. Specify the area, layer, comments on estimation of area/layer, stereotaxic coordinates if in vivo, etc. Use standard atlas names for anatomical regions when possible.
|
—resistance |
Dataset |
Electrode resistance, in ohms.
|
—seal |
Dataset |
Information about seal used for recording.
|
—slice |
Dataset |
Information about slice used for recording.
|
—device |
Link |
Device that was used to record from this electrode.
|
Id |
Type |
Description |
---|---|---|
<IntracellularElectrode> |
Group |
Top level Group for <IntracellularElectrode>
|
—device |
Link |
Device that was used to record from this electrode.
|
2.9.8. SweepTable
Overview: [DEPRECATED] Table used to group different PatchClampSeries. SweepTable is being replaced by IntracellularRecordingsTable and SimultaneousRecordingsTable tables. Additional SequentialRecordingsTable, RepetitionsTable, and ExperimentalConditions tables provide enhanced support for experiment metadata.
SweepTable
extends DynamicTable
and includes all elements of DynamicTable with the following additions or changes.
Extends: DynamicTable
Primitive Type: Group
Inherits from: DynamicTable, Container
Source filename: nwb.icephys.yaml
Source Specification: see Section 3.10.8

Id |
Type |
Description |
---|---|---|
<SweepTable> |
Group |
Top level Group for <SweepTable>
|
—colnames |
Attribute |
The names of the columns in this table. This should be used to specify an order to the columns.
|
—description |
Attribute |
Description of what is in this dynamic table.
|
—sweep_number |
Dataset |
Sweep number of the PatchClampSeries in that row.
|
—series |
Dataset |
The PatchClampSeries with the sweep number in that row.
|
—series_index |
Dataset |
Index for series.
|
—id |
Dataset |
Array of unique identifiers for the rows of this dynamic table.
|
—<VectorData> |
Dataset |
Vector columns, including index columns, of this dynamic table.
|
2.9.9. IntracellularElectrodesTable
Overview: Table for storing intracellular electrode related metadata.
IntracellularElectrodesTable
extends DynamicTable
and includes all elements of DynamicTable with the following additions or changes.
Extends: DynamicTable
Primitive Type: Group
Inherits from: DynamicTable, Container
Source filename: nwb.icephys.yaml
Source Specification: see Section 3.10.9

Id |
Type |
Description |
---|---|---|
<IntracellularElectrodesTable> |
Group |
Top level Group for <IntracellularElectrodesTable>
|
—description |
Attribute |
Description of what is in this dynamic table.
|
—colnames |
Attribute |
The names of the columns in this table. This should be used to specify an order to the columns.
|
—electrode |
Dataset |
Column for storing the reference to the intracellular electrode.
|
—id |
Dataset |
Array of unique identifiers for the rows of this dynamic table.
|
—<VectorData> |
Dataset |
Vector columns, including index columns, of this dynamic table.
|
2.9.10. IntracellularStimuliTable
Overview: Table for storing intracellular stimulus related metadata.
IntracellularStimuliTable
extends DynamicTable
and includes all elements of DynamicTable with the following additions or changes.
Extends: DynamicTable
Primitive Type: Group
Inherits from: DynamicTable, Container
Source filename: nwb.icephys.yaml
Source Specification: see Section 3.10.10

Id |
Type |
Description |
---|---|---|
<IntracellularStimuliTable> |
Group |
Top level Group for <IntracellularStimuliTable>
|
—description |
Attribute |
Description of what is in this dynamic table.
|
—colnames |
Attribute |
The names of the columns in this table. This should be used to specify an order to the columns.
|
—stimulus |
Dataset |
Column storing the reference to the recorded stimulus for the recording (rows).
|
—stimulus_template |
Dataset |
Column storing the reference to the stimulus template for the recording (rows).
|
—id |
Dataset |
Array of unique identifiers for the rows of this dynamic table.
|
—<VectorData> |
Dataset |
Vector columns, including index columns, of this dynamic table.
|
2.9.11. IntracellularResponsesTable
Overview: Table for storing intracellular response related metadata.
IntracellularResponsesTable
extends DynamicTable
and includes all elements of DynamicTable with the following additions or changes.
Extends: DynamicTable
Primitive Type: Group
Inherits from: DynamicTable, Container
Source filename: nwb.icephys.yaml
Source Specification: see Section 3.10.11

Id |
Type |
Description |
---|---|---|
<IntracellularResponsesTable> |
Group |
Top level Group for <IntracellularResponsesTable>
|
—description |
Attribute |
Description of what is in this dynamic table.
|
—colnames |
Attribute |
The names of the columns in this table. This should be used to specify an order to the columns.
|
—response |
Dataset |
Column storing the reference to the recorded response for the recording (rows)
|
—id |
Dataset |
Array of unique identifiers for the rows of this dynamic table.
|
—<VectorData> |
Dataset |
Vector columns, including index columns, of this dynamic table.
|
2.9.12. IntracellularRecordingsTable
Overview: A table to group together a stimulus and response from a single electrode and a single simultaneous recording. Each row in the table represents a single recording consisting typically of a stimulus and a corresponding response. In some cases, however, only a stimulus or a response is recorded as part of an experiment. In this case, both the stimulus and response will point to the same TimeSeries while the idx_start and count of the invalid column will be set to -1, thus, indicating that no values have been recorded for the stimulus or response, respectively. Note, a recording MUST contain at least a stimulus or a response. Typically the stimulus and response are PatchClampSeries. However, the use of AD/DA channels that are not associated to an electrode is also common in intracellular electrophysiology, in which case other TimeSeries may be used.
IntracellularRecordingsTable
extends AlignedDynamicTable
and includes all elements of AlignedDynamicTable with the following additions or changes.
Extends: AlignedDynamicTable
Primitive Type: Group
Name: intracellular_recordings
Inherits from: AlignedDynamicTable, DynamicTable, Container
Source filename: nwb.icephys.yaml
Source Specification: see Section 3.10.12

Id |
Type |
Description |
---|---|---|
intracellular_recordings |
Group |
Top level Group for intracellular_recordings
|
—description |
Attribute |
Description of the contents of this table. Inherited from AlignedDynamicTable and overwritten here to fix the value of the attribute.
|
—categories |
Attribute |
The names of the categories in this AlignedDynamicTable. Each category is represented by one DynamicTable stored in the parent group. This attribute should be used to specify an order of categories and the category names must match the names of the corresponding DynamicTable in the group.
|
—colnames |
Attribute |
The names of the columns in this table. This should be used to specify an order to the columns.
|
—id |
Dataset |
Array of unique identifiers for the rows of this dynamic table.
|
—<VectorData> |
Dataset |
Vector columns, including index columns, of this dynamic table.
|
Id |
Type |
Description |
---|---|---|
intracellular_recordings |
Group |
Top level Group for intracellular_recordings
|
—electrodes |
Group |
Table for storing intracellular electrode related metadata.
|
—stimuli |
Group |
Table for storing intracellular stimulus related metadata.
|
—responses |
Group |
Table for storing intracellular response related metadata.
|
—<DynamicTable> |
Group |
A DynamicTable representing a particular category for columns in the AlignedDynamicTable parent container. The table MUST be aligned with (i.e., have the same number of rows) as all other DynamicTables stored in the AlignedDynamicTable parent container. The name of the category is given by the name of the DynamicTable and its description by the description attribute of the DynamicTable.
|
2.9.12.1. Groups: electrodes
Table for storing intracellular electrode related metadata.
Extends: IntracellularElectrodesTable
Name: electrodes
2.9.12.2. Groups: stimuli
Table for storing intracellular stimulus related metadata.
Extends: IntracellularStimuliTable
Name: stimuli
2.9.12.3. Groups: responses
Table for storing intracellular response related metadata.
Extends: IntracellularResponsesTable
Name: responses
2.9.12.4. Groups: <DynamicTable>
A DynamicTable representing a particular category for columns in the AlignedDynamicTable parent container. The table MUST be aligned with (i.e., have the same number of rows) as all other DynamicTables stored in the AlignedDynamicTable parent container. The name of the category is given by the name of the DynamicTable and its description by the description attribute of the DynamicTable.
Extends: DynamicTable
Quantity: 0 or more
2.9.13. SimultaneousRecordingsTable
Overview: A table for grouping different intracellular recordings from the IntracellularRecordingsTable table together that were recorded simultaneously from different electrodes.
SimultaneousRecordingsTable
extends DynamicTable
and includes all elements of DynamicTable with the following additions or changes.
Extends: DynamicTable
Primitive Type: Group
Name: simultaneous_recordings
Inherits from: DynamicTable, Container
Source filename: nwb.icephys.yaml
Source Specification: see Section 3.10.13

Id |
Type |
Description |
---|---|---|
simultaneous_recordings |
Group |
Top level Group for simultaneous_recordings
|
—colnames |
Attribute |
The names of the columns in this table. This should be used to specify an order to the columns.
|
—description |
Attribute |
Description of what is in this dynamic table.
|
—recordings |
Dataset |
A reference to one or more rows in the IntracellularRecordingsTable table.
|
——table |
Attribute |
Reference to the IntracellularRecordingsTable table that this table region applies to. This specializes the attribute inherited from DynamicTableRegion to fix the type of table that can be referenced here.
|
—recordings_index |
Dataset |
Index dataset for the recordings column.
|
—id |
Dataset |
Array of unique identifiers for the rows of this dynamic table.
|
—<VectorData> |
Dataset |
Vector columns, including index columns, of this dynamic table.
|
2.9.14. SequentialRecordingsTable
Overview: A table for grouping different sequential recordings from the SimultaneousRecordingsTable table together. This is typically used to group together sequential recordings where a sequence of stimuli of the same type with varying parameters have been presented in a sequence.
SequentialRecordingsTable
extends DynamicTable
and includes all elements of DynamicTable with the following additions or changes.
Extends: DynamicTable
Primitive Type: Group
Name: sequential_recordings
Inherits from: DynamicTable, Container
Source filename: nwb.icephys.yaml
Source Specification: see Section 3.10.14

Id |
Type |
Description |
---|---|---|
sequential_recordings |
Group |
Top level Group for sequential_recordings
|
—colnames |
Attribute |
The names of the columns in this table. This should be used to specify an order to the columns.
|
—description |
Attribute |
Description of what is in this dynamic table.
|
—simultaneous_recordings |
Dataset |
A reference to one or more rows in the SimultaneousRecordingsTable table.
|
——table |
Attribute |
Reference to the SimultaneousRecordingsTable table that this table region applies to. This specializes the attribute inherited from DynamicTableRegion to fix the type of table that can be referenced here.
|
—simultaneous_recordings_index |
Dataset |
Index dataset for the simultaneous_recordings column.
|
—stimulus_type |
Dataset |
The type of stimulus used for the sequential recording.
|
—id |
Dataset |
Array of unique identifiers for the rows of this dynamic table.
|
—<VectorData> |
Dataset |
Vector columns, including index columns, of this dynamic table.
|
2.9.15. RepetitionsTable
Overview: A table for grouping different sequential intracellular recordings together. With each SequentialRecording typically representing a particular type of stimulus, the RepetitionsTable table is typically used to group sets of stimuli applied in sequence.
RepetitionsTable
extends DynamicTable
and includes all elements of DynamicTable with the following additions or changes.
Extends: DynamicTable
Primitive Type: Group
Name: repetitions
Inherits from: DynamicTable, Container
Source filename: nwb.icephys.yaml
Source Specification: see Section 3.10.15

Id |
Type |
Description |
---|---|---|
repetitions |
Group |
Top level Group for repetitions
|
—colnames |
Attribute |
The names of the columns in this table. This should be used to specify an order to the columns.
|
—description |
Attribute |
Description of what is in this dynamic table.
|
—sequential_recordings |
Dataset |
A reference to one or more rows in the SequentialRecordingsTable table.
|
——table |
Attribute |
Reference to the SequentialRecordingsTable table that this table region applies to. This specializes the attribute inherited from DynamicTableRegion to fix the type of table that can be referenced here.
|
—sequential_recordings_index |
Dataset |
Index dataset for the sequential_recordings column.
|
—id |
Dataset |
Array of unique identifiers for the rows of this dynamic table.
|
—<VectorData> |
Dataset |
Vector columns, including index columns, of this dynamic table.
|
2.9.16. ExperimentalConditionsTable
Overview: A table for grouping different intracellular recording repetitions together that belong to the same experimental condition.
ExperimentalConditionsTable
extends DynamicTable
and includes all elements of DynamicTable with the following additions or changes.
Extends: DynamicTable
Primitive Type: Group
Name: experimental_conditions
Inherits from: DynamicTable, Container
Source filename: nwb.icephys.yaml
Source Specification: see Section 3.10.16

Id |
Type |
Description |
---|---|---|
experimental_conditions |
Group |
Top level Group for experimental_conditions
|
—colnames |
Attribute |
The names of the columns in this table. This should be used to specify an order to the columns.
|
—description |
Attribute |
Description of what is in this dynamic table.
|
—repetitions |
Dataset |
A reference to one or more rows in the RepetitionsTable table.
|
——table |
Attribute |
Reference to the RepetitionsTable table that this table region applies to. This specializes the attribute inherited from DynamicTableRegion to fix the type of table that can be referenced here.
|
—repetitions_index |
Dataset |
Index dataset for the repetitions column.
|
—id |
Dataset |
Array of unique identifiers for the rows of this dynamic table.
|
—<VectorData> |
Dataset |
Vector columns, including index columns, of this dynamic table.
|
2.10. Optogenetics
This source module contains neurodata_types for opto-genetics data.
2.10.1. OptogeneticSeries
Overview: An optogenetic stimulus.
OptogeneticSeries
extends TimeSeries
and includes all elements of TimeSeries with the following additions or changes.
Extends: TimeSeries
Primitive Type: Group
Inherits from: TimeSeries, NWBDataInterface, NWBContainer, Container
Source filename: nwb.ogen.yaml
Source Specification: see Section 3.11.1

Id |
Type |
Description |
---|---|---|
<OptogeneticSeries> |
Group |
Top level Group for <OptogeneticSeries>
|
—description |
Attribute |
Description of the time series.
|
—comments |
Attribute |
Human-readable comments about the TimeSeries. This second descriptive field can be used to store additional information, or descriptive information if the primary description field is populated with a computer-readable string.
|
—data |
Dataset |
Applied power for optogenetic stimulus, in watts. Shape can be 1D or 2D. 2D data is meant to be used in an extension of OptogeneticSeries that defines what the second dimension represents.
|
——unit |
Attribute |
Unit of measurement for data, which is fixed to ‘watts’.
|
——conversion |
Attribute |
Scalar to multiply each element in data to convert it to the specified ‘unit’. If the data are stored in acquisition system units or other units that require a conversion to be interpretable, multiply the data by ‘conversion’ to convert the data to the specified ‘unit’. e.g. if the data acquisition system stores values in this object as signed 16-bit integers (int16 range -32,768 to 32,767) that correspond to a 5V range (-2.5V to 2.5V), and the data acquisition system gain is 8000X, then the ‘conversion’ multiplier to get from raw data acquisition values to recorded volts is 2.5/32768/8000 = 9.5367e-9.
|
——offset |
Attribute |
Scalar to add to the data after scaling by ‘conversion’ to finalize its coercion to the specified ‘unit’. Two common examples of this include (a) data stored in an unsigned type that requires a shift after scaling to re-center the data, and (b) specialized recording devices that naturally cause a scalar offset with respect to the true units.
|
——resolution |
Attribute |
Smallest meaningful difference between values in data, stored in the specified by unit, e.g., the change in value of the least significant bit, or a larger number if signal noise is known to be present. If unknown, use -1.0.
|
——continuity |
Attribute |
Optionally describe the continuity of the data. Can be “continuous”, “instantaneous”, or “step”. For example, a voltage trace would be “continuous”, because samples are recorded from a continuous process. An array of lick times would be “instantaneous”, because the data represents distinct moments in time. Times of image presentations would be “step” because the picture remains the same until the next timepoint. This field is optional, but is useful in providing information about the underlying data. It may inform the way this data is interpreted, the way it is visualized, and what analysis methods are applicable.
|
—starting_time |
Dataset |
Timestamp of the first sample in seconds. When timestamps are uniformly spaced, the timestamp of the first sample can be specified and all subsequent ones calculated from the sampling rate attribute.
|
——rate |
Attribute |
Sampling rate, in Hz.
|
——unit |
Attribute |
Unit of measurement for time, which is fixed to ‘seconds’.
|
—timestamps |
Dataset |
Timestamps for samples stored in data, in seconds, relative to the common experiment master-clock stored in NWBFile.timestamps_reference_time.
|
——interval |
Attribute |
Value is ‘1’
|
——unit |
Attribute |
Unit of measurement for timestamps, which is fixed to ‘seconds’.
|
—control |
Dataset |
Numerical labels that apply to each time point in data for the purpose of querying and slicing data by these values. If present, the length of this array should be the same size as the first dimension of data.
|
—control_description |
Dataset |
Description of each control value. Must be present if control is present. If present, control_description[0] should describe time points where control == 0.
|
—site |
Link |
Link to OptogeneticStimulusSite object that describes the site to which this stimulus was applied.
|
Id |
Type |
Description |
---|---|---|
<OptogeneticSeries> |
Group |
Top level Group for <OptogeneticSeries>
|
—site |
Link |
Link to OptogeneticStimulusSite object that describes the site to which this stimulus was applied.
|
—sync |
Group |
Lab-specific time and sync information as provided directly from hardware devices and that is necessary for aligning all acquired time information to a common timebase. The timestamp array stores time in the common timebase. This group will usually only be populated in TimeSeries that are stored external to the NWB file, in files storing raw data. Once timestamp data is calculated, the contents of ‘sync’ are mostly for archival purposes.
|
2.10.1.1. Groups: sync
Lab-specific time and sync information as provided directly from hardware devices and that is necessary for aligning all acquired time information to a common timebase. The timestamp array stores time in the common timebase. This group will usually only be populated in TimeSeries that are stored external to the NWB file, in files storing raw data. Once timestamp data is calculated, the contents of ‘sync’ are mostly for archival purposes.
Quantity: 0 or 1
Name: sync
2.10.2. OptogeneticStimulusSite
Overview: A site of optogenetic stimulation.
OptogeneticStimulusSite
extends NWBContainer
and includes all elements of NWBContainer with the following additions or changes.
Extends: NWBContainer
Primitive Type: Group
Inherits from: NWBContainer, Container
Source filename: nwb.ogen.yaml
Source Specification: see Section 3.11.2

Id |
Type |
Description |
---|---|---|
<OptogeneticStimulusSite> |
Group |
Top level Group for <OptogeneticStimulusSite>
|
—description |
Dataset |
Description of stimulation site.
|
—excitation_lambda |
Dataset |
Excitation wavelength, in nm.
|
—location |
Dataset |
Location of the stimulation site. Specify the area, layer, comments on estimation of area/layer, stereotaxic coordinates if in vivo, etc. Use standard atlas names for anatomical regions when possible.
|
—device |
Link |
Device that generated the stimulus.
|
Id |
Type |
Description |
---|---|---|
<OptogeneticStimulusSite> |
Group |
Top level Group for <OptogeneticStimulusSite>
|
—device |
Link |
Device that generated the stimulus.
|
2.11. Optical physiology
This source module contains neurodata_types for optical physiology data.
2.11.1. OnePhotonSeries
Overview: Image stack recorded over time from 1-photon microscope.
OnePhotonSeries
extends ImageSeries
and includes all elements of ImageSeries with the following additions or changes.
Extends: ImageSeries
Primitive Type: Group
Inherits from: ImageSeries, TimeSeries, NWBDataInterface, NWBContainer, Container
Source filename: nwb.ophys.yaml
Source Specification: see Section 3.12.1

Id |
Type |
Description |
---|---|---|
<OnePhotonSeries> |
Group |
Top level Group for <OnePhotonSeries>
|
—pmt_gain |
Attribute |
Photomultiplier gain.
|
—scan_line_rate |
Attribute |
Lines imaged per second. This is also stored in /general/optophysiology but is kept here as it is useful information for analysis, and so good to be stored w/ the actual data.
|
—exposure_time |
Attribute |
Exposure time of the sample; often the inverse of the frequency.
|
—binning |
Attribute |
Amount of pixels combined into ‘bins’; could be 1, 2, 4, 8, etc.
|
—power |
Attribute |
Power of the excitation in mW, if known.
|
—intensity |
Attribute |
Intensity of the excitation in mW/mm^2, if known.
|
—description |
Attribute |
Description of the time series.
|
—comments |
Attribute |
Human-readable comments about the TimeSeries. This second descriptive field can be used to store additional information, or descriptive information if the primary description field is populated with a computer-readable string.
|
—data |
Dataset |
Binary data representing images across frames. If data are stored in an external file, this should be an empty 3D array.
|
——conversion |
Attribute |
Scalar to multiply each element in data to convert it to the specified ‘unit’. If the data are stored in acquisition system units or other units that require a conversion to be interpretable, multiply the data by ‘conversion’ to convert the data to the specified ‘unit’. e.g. if the data acquisition system stores values in this object as signed 16-bit integers (int16 range -32,768 to 32,767) that correspond to a 5V range (-2.5V to 2.5V), and the data acquisition system gain is 8000X, then the ‘conversion’ multiplier to get from raw data acquisition values to recorded volts is 2.5/32768/8000 = 9.5367e-9.
|
——offset |
Attribute |
Scalar to add to the data after scaling by ‘conversion’ to finalize its coercion to the specified ‘unit’. Two common examples of this include (a) data stored in an unsigned type that requires a shift after scaling to re-center the data, and (b) specialized recording devices that naturally cause a scalar offset with respect to the true units.
|
——resolution |
Attribute |
Smallest meaningful difference between values in data, stored in the specified by unit, e.g., the change in value of the least significant bit, or a larger number if signal noise is known to be present. If unknown, use -1.0.
|
——unit |
Attribute |
Base unit of measurement for working with the data. Actual stored values are not necessarily stored in these units. To access the data in these units, multiply ‘data’ by ‘conversion’ and add ‘offset’.
|
——continuity |
Attribute |
Optionally describe the continuity of the data. Can be “continuous”, “instantaneous”, or “step”. For example, a voltage trace would be “continuous”, because samples are recorded from a continuous process. An array of lick times would be “instantaneous”, because the data represents distinct moments in time. Times of image presentations would be “step” because the picture remains the same until the next timepoint. This field is optional, but is useful in providing information about the underlying data. It may inform the way this data is interpreted, the way it is visualized, and what analysis methods are applicable.
|
—dimension |
Dataset |
Number of pixels on x, y, (and z) axes.
|
—external_file |
Dataset |
Paths to one or more external file(s). The field is only present if format=’external’. This is only relevant if the image series is stored in the file system as one or more image file(s). This field should NOT be used if the image is stored in another NWB file and that file is linked to this file.
|
——starting_frame |
Attribute |
Each external image may contain one or more consecutive frames of the full ImageSeries. This attribute serves as an index to indicate which frames each file contains, to facilitate random access. The ‘starting_frame’ attribute, hence, contains a list of frame numbers within the full ImageSeries of the first frame of each file listed in the parent ‘external_file’ dataset. Zero-based indexing is used (hence, the first element will always be zero). For example, if the ‘external_file’ dataset has three paths to files and the first file has 5 frames, the second file has 10 frames, and the third file has 20 frames, then this attribute will have values [0, 5, 15]. If there is a single external file that holds all of the frames of the ImageSeries (and so there is a single element in the ‘external_file’ dataset), then this attribute should have value [0].
|
—format |
Dataset |
Format of image. If this is ‘external’, then the attribute ‘external_file’ contains the path information to the image files. If this is ‘raw’, then the raw (single-channel) binary data is stored in the ‘data’ dataset. If this attribute is not present, then the default format=’raw’ case is assumed.
|
—starting_time |
Dataset |
Timestamp of the first sample in seconds. When timestamps are uniformly spaced, the timestamp of the first sample can be specified and all subsequent ones calculated from the sampling rate attribute.
|
——rate |
Attribute |
Sampling rate, in Hz.
|
——unit |
Attribute |
Unit of measurement for time, which is fixed to ‘seconds’.
|
—timestamps |
Dataset |
Timestamps for samples stored in data, in seconds, relative to the common experiment master-clock stored in NWBFile.timestamps_reference_time.
|
——interval |
Attribute |
Value is ‘1’
|
——unit |
Attribute |
Unit of measurement for timestamps, which is fixed to ‘seconds’.
|
—control |
Dataset |
Numerical labels that apply to each time point in data for the purpose of querying and slicing data by these values. If present, the length of this array should be the same size as the first dimension of data.
|
—control_description |
Dataset |
Description of each control value. Must be present if control is present. If present, control_description[0] should describe time points where control == 0.
|
—imaging_plane |
Link |
Link to ImagingPlane object from which this TimeSeries data was generated.
|
—device |
Link |
Link to the Device object that was used to capture these images.
|
Id |
Type |
Description |
---|---|---|
<OnePhotonSeries> |
Group |
Top level Group for <OnePhotonSeries>
|
—imaging_plane |
Link |
Link to ImagingPlane object from which this TimeSeries data was generated.
|
—device |
Link |
Link to the Device object that was used to capture these images.
|
—sync |
Group |
Lab-specific time and sync information as provided directly from hardware devices and that is necessary for aligning all acquired time information to a common timebase. The timestamp array stores time in the common timebase. This group will usually only be populated in TimeSeries that are stored external to the NWB file, in files storing raw data. Once timestamp data is calculated, the contents of ‘sync’ are mostly for archival purposes.
|
2.11.1.1. Groups: sync
Lab-specific time and sync information as provided directly from hardware devices and that is necessary for aligning all acquired time information to a common timebase. The timestamp array stores time in the common timebase. This group will usually only be populated in TimeSeries that are stored external to the NWB file, in files storing raw data. Once timestamp data is calculated, the contents of ‘sync’ are mostly for archival purposes.
Quantity: 0 or 1
Name: sync
2.11.2. TwoPhotonSeries
Overview: Image stack recorded over time from 2-photon microscope.
TwoPhotonSeries
extends ImageSeries
and includes all elements of ImageSeries with the following additions or changes.
Extends: ImageSeries
Primitive Type: Group
Inherits from: ImageSeries, TimeSeries, NWBDataInterface, NWBContainer, Container
Source filename: nwb.ophys.yaml
Source Specification: see Section 3.12.2

Id |
Type |
Description |
---|---|---|
<TwoPhotonSeries> |
Group |
Top level Group for <TwoPhotonSeries>
|
—pmt_gain |
Attribute |
Photomultiplier gain.
|
—scan_line_rate |
Attribute |
Lines imaged per second. This is also stored in /general/optophysiology but is kept here as it is useful information for analysis, and so good to be stored w/ the actual data.
|
—description |
Attribute |
Description of the time series.
|
—comments |
Attribute |
Human-readable comments about the TimeSeries. This second descriptive field can be used to store additional information, or descriptive information if the primary description field is populated with a computer-readable string.
|
—field_of_view |
Dataset |
Width, height and depth of image, or imaged area, in meters.
|
—data |
Dataset |
Binary data representing images across frames. If data are stored in an external file, this should be an empty 3D array.
|
——conversion |
Attribute |
Scalar to multiply each element in data to convert it to the specified ‘unit’. If the data are stored in acquisition system units or other units that require a conversion to be interpretable, multiply the data by ‘conversion’ to convert the data to the specified ‘unit’. e.g. if the data acquisition system stores values in this object as signed 16-bit integers (int16 range -32,768 to 32,767) that correspond to a 5V range (-2.5V to 2.5V), and the data acquisition system gain is 8000X, then the ‘conversion’ multiplier to get from raw data acquisition values to recorded volts is 2.5/32768/8000 = 9.5367e-9.
|
——offset |
Attribute |
Scalar to add to the data after scaling by ‘conversion’ to finalize its coercion to the specified ‘unit’. Two common examples of this include (a) data stored in an unsigned type that requires a shift after scaling to re-center the data, and (b) specialized recording devices that naturally cause a scalar offset with respect to the true units.
|
——resolution |
Attribute |
Smallest meaningful difference between values in data, stored in the specified by unit, e.g., the change in value of the least significant bit, or a larger number if signal noise is known to be present. If unknown, use -1.0.
|
——unit |
Attribute |
Base unit of measurement for working with the data. Actual stored values are not necessarily stored in these units. To access the data in these units, multiply ‘data’ by ‘conversion’ and add ‘offset’.
|
——continuity |
Attribute |
Optionally describe the continuity of the data. Can be “continuous”, “instantaneous”, or “step”. For example, a voltage trace would be “continuous”, because samples are recorded from a continuous process. An array of lick times would be “instantaneous”, because the data represents distinct moments in time. Times of image presentations would be “step” because the picture remains the same until the next timepoint. This field is optional, but is useful in providing information about the underlying data. It may inform the way this data is interpreted, the way it is visualized, and what analysis methods are applicable.
|
—dimension |
Dataset |
Number of pixels on x, y, (and z) axes.
|
—external_file |
Dataset |
Paths to one or more external file(s). The field is only present if format=’external’. This is only relevant if the image series is stored in the file system as one or more image file(s). This field should NOT be used if the image is stored in another NWB file and that file is linked to this file.
|
——starting_frame |
Attribute |
Each external image may contain one or more consecutive frames of the full ImageSeries. This attribute serves as an index to indicate which frames each file contains, to facilitate random access. The ‘starting_frame’ attribute, hence, contains a list of frame numbers within the full ImageSeries of the first frame of each file listed in the parent ‘external_file’ dataset. Zero-based indexing is used (hence, the first element will always be zero). For example, if the ‘external_file’ dataset has three paths to files and the first file has 5 frames, the second file has 10 frames, and the third file has 20 frames, then this attribute will have values [0, 5, 15]. If there is a single external file that holds all of the frames of the ImageSeries (and so there is a single element in the ‘external_file’ dataset), then this attribute should have value [0].
|
—format |
Dataset |
Format of image. If this is ‘external’, then the attribute ‘external_file’ contains the path information to the image files. If this is ‘raw’, then the raw (single-channel) binary data is stored in the ‘data’ dataset. If this attribute is not present, then the default format=’raw’ case is assumed.
|
—starting_time |
Dataset |
Timestamp of the first sample in seconds. When timestamps are uniformly spaced, the timestamp of the first sample can be specified and all subsequent ones calculated from the sampling rate attribute.
|
——rate |
Attribute |
Sampling rate, in Hz.
|
——unit |
Attribute |
Unit of measurement for time, which is fixed to ‘seconds’.
|
—timestamps |
Dataset |
Timestamps for samples stored in data, in seconds, relative to the common experiment master-clock stored in NWBFile.timestamps_reference_time.
|
——interval |
Attribute |
Value is ‘1’
|
——unit |
Attribute |
Unit of measurement for timestamps, which is fixed to ‘seconds’.
|
—control |
Dataset |
Numerical labels that apply to each time point in data for the purpose of querying and slicing data by these values. If present, the length of this array should be the same size as the first dimension of data.
|
—control_description |
Dataset |
Description of each control value. Must be present if control is present. If present, control_description[0] should describe time points where control == 0.
|
—imaging_plane |
Link |
Link to ImagingPlane object from which this TimeSeries data was generated.
|
—device |
Link |
Link to the Device object that was used to capture these images.
|
Id |
Type |
Description |
---|---|---|
<TwoPhotonSeries> |
Group |
Top level Group for <TwoPhotonSeries>
|
—imaging_plane |
Link |
Link to ImagingPlane object from which this TimeSeries data was generated.
|
—device |
Link |
Link to the Device object that was used to capture these images.
|
—sync |
Group |
Lab-specific time and sync information as provided directly from hardware devices and that is necessary for aligning all acquired time information to a common timebase. The timestamp array stores time in the common timebase. This group will usually only be populated in TimeSeries that are stored external to the NWB file, in files storing raw data. Once timestamp data is calculated, the contents of ‘sync’ are mostly for archival purposes.
|
2.11.2.1. Groups: sync
Lab-specific time and sync information as provided directly from hardware devices and that is necessary for aligning all acquired time information to a common timebase. The timestamp array stores time in the common timebase. This group will usually only be populated in TimeSeries that are stored external to the NWB file, in files storing raw data. Once timestamp data is calculated, the contents of ‘sync’ are mostly for archival purposes.
Quantity: 0 or 1
Name: sync
2.11.3. RoiResponseSeries
Overview: ROI responses over an imaging plane. The first dimension represents time. The second dimension, if present, represents ROIs.
RoiResponseSeries
extends TimeSeries
and includes all elements of TimeSeries with the following additions or changes.
Extends: TimeSeries
Primitive Type: Group
Inherits from: TimeSeries, NWBDataInterface, NWBContainer, Container
Source filename: nwb.ophys.yaml
Source Specification: see Section 3.12.3

Id |
Type |
Description |
---|---|---|
<RoiResponseSeries> |
Group |
Top level Group for <RoiResponseSeries>
|
—description |
Attribute |
Description of the time series.
|
—comments |
Attribute |
Human-readable comments about the TimeSeries. This second descriptive field can be used to store additional information, or descriptive information if the primary description field is populated with a computer-readable string.
|
—data |
Dataset |
Signals from ROIs.
|
——conversion |
Attribute |
Scalar to multiply each element in data to convert it to the specified ‘unit’. If the data are stored in acquisition system units or other units that require a conversion to be interpretable, multiply the data by ‘conversion’ to convert the data to the specified ‘unit’. e.g. if the data acquisition system stores values in this object as signed 16-bit integers (int16 range -32,768 to 32,767) that correspond to a 5V range (-2.5V to 2.5V), and the data acquisition system gain is 8000X, then the ‘conversion’ multiplier to get from raw data acquisition values to recorded volts is 2.5/32768/8000 = 9.5367e-9.
|
——offset |
Attribute |
Scalar to add to the data after scaling by ‘conversion’ to finalize its coercion to the specified ‘unit’. Two common examples of this include (a) data stored in an unsigned type that requires a shift after scaling to re-center the data, and (b) specialized recording devices that naturally cause a scalar offset with respect to the true units.
|
——resolution |
Attribute |
Smallest meaningful difference between values in data, stored in the specified by unit, e.g., the change in value of the least significant bit, or a larger number if signal noise is known to be present. If unknown, use -1.0.
|
——unit |
Attribute |
Base unit of measurement for working with the data. Actual stored values are not necessarily stored in these units. To access the data in these units, multiply ‘data’ by ‘conversion’ and add ‘offset’.
|
——continuity |
Attribute |
Optionally describe the continuity of the data. Can be “continuous”, “instantaneous”, or “step”. For example, a voltage trace would be “continuous”, because samples are recorded from a continuous process. An array of lick times would be “instantaneous”, because the data represents distinct moments in time. Times of image presentations would be “step” because the picture remains the same until the next timepoint. This field is optional, but is useful in providing information about the underlying data. It may inform the way this data is interpreted, the way it is visualized, and what analysis methods are applicable.
|
—rois |
Dataset |
DynamicTableRegion referencing into an ROITable containing information on the ROIs stored in this timeseries.
|
—starting_time |
Dataset |
Timestamp of the first sample in seconds. When timestamps are uniformly spaced, the timestamp of the first sample can be specified and all subsequent ones calculated from the sampling rate attribute.
|
——rate |
Attribute |
Sampling rate, in Hz.
|
——unit |
Attribute |
Unit of measurement for time, which is fixed to ‘seconds’.
|
—timestamps |
Dataset |
Timestamps for samples stored in data, in seconds, relative to the common experiment master-clock stored in NWBFile.timestamps_reference_time.
|
——interval |
Attribute |
Value is ‘1’
|
——unit |
Attribute |
Unit of measurement for timestamps, which is fixed to ‘seconds’.
|
—control |
Dataset |
Numerical labels that apply to each time point in data for the purpose of querying and slicing data by these values. If present, the length of this array should be the same size as the first dimension of data.
|
—control_description |
Dataset |
Description of each control value. Must be present if control is present. If present, control_description[0] should describe time points where control == 0.
|
Id |
Type |
Description |
---|---|---|
<RoiResponseSeries> |
Group |
Top level Group for <RoiResponseSeries>
|
—sync |
Group |
Lab-specific time and sync information as provided directly from hardware devices and that is necessary for aligning all acquired time information to a common timebase. The timestamp array stores time in the common timebase. This group will usually only be populated in TimeSeries that are stored external to the NWB file, in files storing raw data. Once timestamp data is calculated, the contents of ‘sync’ are mostly for archival purposes.
|
2.11.3.1. Groups: sync
Lab-specific time and sync information as provided directly from hardware devices and that is necessary for aligning all acquired time information to a common timebase. The timestamp array stores time in the common timebase. This group will usually only be populated in TimeSeries that are stored external to the NWB file, in files storing raw data. Once timestamp data is calculated, the contents of ‘sync’ are mostly for archival purposes.
Quantity: 0 or 1
Name: sync
2.11.4. DfOverF
Overview: dF/F information about a region of interest (ROI). Storage hierarchy of dF/F should be the same as for segmentation (i.e., same names for ROIs and for image planes).
DfOverF
extends NWBDataInterface
and includes all elements of NWBDataInterface with the following additions or changes.
Extends: NWBDataInterface
Primitive Type: Group
Default Name: DfOverF
Inherits from: NWBDataInterface, NWBContainer, Container
Source filename: nwb.ophys.yaml
Source Specification: see Section 3.12.4
Id |
Type |
Description |
---|---|---|
<DfOverF> |
Group |
Top level Group for <DfOverF>
|
Group |
RoiResponseSeries object(s) containing dF/F for a ROI.
|
2.11.4.1. Groups: <RoiResponseSeries>
RoiResponseSeries object(s) containing dF/F for a ROI.
Extends: RoiResponseSeries
Quantity: 1 or more
2.11.5. Fluorescence
Overview: Fluorescence information about a region of interest (ROI). Storage hierarchy of fluorescence should be the same as for segmentation (ie, same names for ROIs and for image planes).
Fluorescence
extends NWBDataInterface
and includes all elements of NWBDataInterface with the following additions or changes.
Extends: NWBDataInterface
Primitive Type: Group
Default Name: Fluorescence
Inherits from: NWBDataInterface, NWBContainer, Container
Source filename: nwb.ophys.yaml
Source Specification: see Section 3.12.5
Id |
Type |
Description |
---|---|---|
<Fluorescence> |
Group |
Top level Group for <Fluorescence>
|
Group |
RoiResponseSeries object(s) containing fluorescence data for a ROI.
|
2.11.5.1. Groups: <RoiResponseSeries>
RoiResponseSeries object(s) containing fluorescence data for a ROI.
Extends: RoiResponseSeries
Quantity: 1 or more
2.11.6. ImageSegmentation
Overview: Stores pixels in an image that represent different regions of interest (ROIs) or masks. All segmentation for a given imaging plane is stored together, with storage for multiple imaging planes (masks) supported. Each ROI is stored in its own subgroup, with the ROI group containing both a 2D mask and a list of pixels that make up this mask. Segments can also be used for masking neuropil. If segmentation is allowed to change with time, a new imaging plane (or module) is required and ROI names should remain consistent between them.
ImageSegmentation
extends NWBDataInterface
and includes all elements of NWBDataInterface with the following additions or changes.
Extends: NWBDataInterface
Primitive Type: Group
Default Name: ImageSegmentation
Inherits from: NWBDataInterface, NWBContainer, Container
Source filename: nwb.ophys.yaml
Source Specification: see Section 3.12.6
Id |
Type |
Description |
---|---|---|
<ImageSegmentation> |
Group |
Top level Group for <ImageSegmentation>
|
Group |
Results from image segmentation of a specific imaging plane.
|
2.11.6.1. Groups: <PlaneSegmentation>
Results from image segmentation of a specific imaging plane.
Extends: PlaneSegmentation
Quantity: 1 or more
2.11.7. PlaneSegmentation
Overview: Results from image segmentation of a specific imaging plane.
PlaneSegmentation
extends DynamicTable
and includes all elements of DynamicTable with the following additions or changes.
Extends: DynamicTable
Primitive Type: Group
Inherits from: DynamicTable, Container
Source filename: nwb.ophys.yaml
Source Specification: see Section 3.12.7

Id |
Type |
Description |
---|---|---|
<PlaneSegmentation> |
Group |
Top level Group for <PlaneSegmentation>
|
—colnames |
Attribute |
The names of the columns in this table. This should be used to specify an order to the columns.
|
—description |
Attribute |
Description of what is in this dynamic table.
|
—image_mask |
Dataset |
ROI masks for each ROI. Each image mask is the size of the original imaging plane (or volume) and members of the ROI are finite non-zero.
|
—pixel_mask_index |
Dataset |
Index into pixel_mask.
|
—pixel_mask |
Dataset |
Pixel masks for each ROI: a list of indices and weights for the ROI. Pixel masks are concatenated and parsing of this dataset is maintained by the PlaneSegmentation
|
—voxel_mask_index |
Dataset |
Index into voxel_mask.
|
—voxel_mask |
Dataset |
Voxel masks for each ROI: a list of indices and weights for the ROI. Voxel masks are concatenated and parsing of this dataset is maintained by the PlaneSegmentation
|
—id |
Dataset |
Array of unique identifiers for the rows of this dynamic table.
|
—<VectorData> |
Dataset |
Vector columns, including index columns, of this dynamic table.
|
—imaging_plane |
Link |
Link to ImagingPlane object from which this data was generated.
|
Id |
Type |
Description |
---|---|---|
<PlaneSegmentation> |
Group |
Top level Group for <PlaneSegmentation>
|
—imaging_plane |
Link |
Link to ImagingPlane object from which this data was generated.
|
—reference_images |
Group |
Image stacks that the segmentation masks apply to.
|
2.11.7.1. Groups: reference_images
Image stacks that the segmentation masks apply to.
Name: reference_images
Id |
Type |
Description |
---|---|---|
reference_images |
Group |
Top level Group for reference_images
|
—<ImageSeries> |
Group |
One or more image stacks that the masks apply to (can be one-element stack).
|
2.11.7.2. Groups: reference_images/<ImageSeries>
One or more image stacks that the masks apply to (can be one-element stack).
Extends: ImageSeries
Quantity: 0 or more
2.11.8. ImagingPlane
Overview: An imaging plane and its metadata.
ImagingPlane
extends NWBContainer
and includes all elements of NWBContainer with the following additions or changes.
Extends: NWBContainer
Primitive Type: Group
Inherits from: NWBContainer, Container
Source filename: nwb.ophys.yaml
Source Specification: see Section 3.12.8

Id |
Type |
Description |
---|---|---|
<ImagingPlane> |
Group |
Top level Group for <ImagingPlane>
|
—description |
Dataset |
Description of the imaging plane.
|
—excitation_lambda |
Dataset |
Excitation wavelength, in nm.
|
—imaging_rate |
Dataset |
Rate that images are acquired, in Hz. If the corresponding TimeSeries is present, the rate should be stored there instead.
|
—indicator |
Dataset |
Calcium indicator.
|
—location |
Dataset |
Location of the imaging plane. Specify the area, layer, comments on estimation of area/layer, stereotaxic coordinates if in vivo, etc. Use standard atlas names for anatomical regions when possible.
|
—manifold |
Dataset |
DEPRECATED Physical position of each pixel. ‘xyz’ represents the position of the pixel relative to the defined coordinate space. Deprecated in favor of origin_coords and grid_spacing.
|
——conversion |
Attribute |
Scalar to multiply each element in data to convert it to the specified ‘unit’. If the data are stored in acquisition system units or other units that require a conversion to be interpretable, multiply the data by ‘conversion’ to convert the data to the specified ‘unit’. e.g. if the data acquisition system stores values in this object as pixels from x = -500 to 499, y = -500 to 499 that correspond to a 2 m x 2 m range, then the ‘conversion’ multiplier to get from raw data acquisition pixel units to meters is 2/1000.
|
——unit |
Attribute |
Base unit of measurement for working with the data. The default value is ‘meters’.
|
—origin_coords |
Dataset |
Physical location of the first element of the imaging plane (0, 0) for 2-D data or (0, 0, 0) for 3-D data. See also reference_frame for what the physical location is relative to (e.g., bregma).
|
——unit |
Attribute |
Measurement units for origin_coords. The default value is ‘meters’.
|
—grid_spacing |
Dataset |
Space between pixels in (x, y) or voxels in (x, y, z) directions, in the specified unit. Assumes imaging plane is a regular grid. See also reference_frame to interpret the grid.
|
——unit |
Attribute |
Measurement units for grid_spacing. The default value is ‘meters’.
|
—reference_frame |
Dataset |
Describes reference frame of origin_coords and grid_spacing. For example, this can be a text description of the anatomical location and orientation of the grid defined by origin_coords and grid_spacing or the vectors needed to transform or rotate the grid to a common anatomical axis (e.g., AP/DV/ML). This field is necessary to interpret origin_coords and grid_spacing. If origin_coords and grid_spacing are not present, then this field is not required. For example, if the microscope takes 10 x 10 x 2 images, where the first value of the data matrix (index (0, 0, 0)) corresponds to (-1.2, -0.6, -2) mm relative to bregma, the spacing between pixels is 0.2 mm in x, 0.2 mm in y and 0.5 mm in z, and larger numbers in x means more anterior, larger numbers in y means more rightward, and larger numbers in z means more ventral, then enter the following – origin_coords = (-1.2, -0.6, -2) grid_spacing = (0.2, 0.2, 0.5) reference_frame = “Origin coordinates are relative to bregma. First dimension corresponds to anterior-posterior axis (larger index = more anterior). Second dimension corresponds to medial-lateral axis (larger index = more rightward). Third dimension corresponds to dorsal-ventral axis (larger index = more ventral).”
|
—device |
Link |
Link to the Device object that was used to record from this electrode.
|
Id |
Type |
Description |
---|---|---|
<ImagingPlane> |
Group |
Top level Group for <ImagingPlane>
|
—device |
Link |
Link to the Device object that was used to record from this electrode.
|
Group |
An optical channel used to record from an imaging plane.
|
2.11.8.1. Groups: <OpticalChannel>
An optical channel used to record from an imaging plane.
Extends: OpticalChannel
Quantity: 1 or more
2.11.9. OpticalChannel
Overview: An optical channel used to record from an imaging plane.
OpticalChannel
extends NWBContainer
and includes all elements of NWBContainer with the following additions or changes.
Extends: NWBContainer
Primitive Type: Group
Inherits from: NWBContainer, Container
Source filename: nwb.ophys.yaml
Source Specification: see Section 3.12.9

Id |
Type |
Description |
---|---|---|
<OpticalChannel> |
Group |
Top level Group for <OpticalChannel>
|
—description |
Dataset |
Description or other notes about the channel.
|
—emission_lambda |
Dataset |
Emission wavelength for channel, in nm.
|
2.11.10. MotionCorrection
Overview: An image stack where all frames are shifted (registered) to a common coordinate system, to account for movement and drift between frames. Note: each frame at each point in time is assumed to be 2-D (has only x & y dimensions).
MotionCorrection
extends NWBDataInterface
and includes all elements of NWBDataInterface with the following additions or changes.
Extends: NWBDataInterface
Primitive Type: Group
Default Name: MotionCorrection
Inherits from: NWBDataInterface, NWBContainer, Container
Source filename: nwb.ophys.yaml
Source Specification: see Section 3.12.10
Id |
Type |
Description |
---|---|---|
<MotionCorrection> |
Group |
Top level Group for <MotionCorrection>
|
Group |
Results from motion correction of an image stack.
|
2.11.10.1. Groups: <CorrectedImageStack>
Results from motion correction of an image stack.
Extends: CorrectedImageStack
Quantity: 1 or more
2.11.11. CorrectedImageStack
Overview: Results from motion correction of an image stack.
CorrectedImageStack
extends NWBDataInterface
and includes all elements of NWBDataInterface with the following additions or changes.
Extends: NWBDataInterface
Primitive Type: Group
Inherits from: NWBDataInterface, NWBContainer, Container
Source filename: nwb.ophys.yaml
Source Specification: see Section 3.12.11

Id |
Type |
Description |
---|---|---|
<CorrectedImageStack> |
Group |
Top level Group for <CorrectedImageStack>
|
—original |
Link |
Link to ImageSeries object that is being registered.
|
Id |
Type |
Description |
---|---|---|
<CorrectedImageStack> |
Group |
Top level Group for <CorrectedImageStack>
|
—original |
Link |
Link to ImageSeries object that is being registered.
|
—corrected |
Group |
Image stack with frames shifted to the common coordinates.
|
—xy_translation |
Group |
Stores the x,y delta necessary to align each frame to the common coordinates, for example, to align each frame to a reference image.
|
2.11.11.1. Groups: corrected
Image stack with frames shifted to the common coordinates.
Extends: ImageSeries
Name: corrected
2.11.11.2. Groups: xy_translation
Stores the x,y delta necessary to align each frame to the common coordinates, for example, to align each frame to a reference image.
Extends: TimeSeries
Name: xy_translation
2.12. Retinotopy
This source module contains neurodata_type for retinotopy data.
2.12.1. ImagingRetinotopy
Overview: DEPRECATED. Intrinsic signal optical imaging or widefield imaging for measuring retinotopy. Stores orthogonal maps (e.g., altitude/azimuth; radius/theta) of responses to specific stimuli and a combined polarity map from which to identify visual areas. This group does not store the raw responses imaged during retinotopic mapping or the stimuli presented, but rather the resulting phase and power maps after applying a Fourier transform on the averaged responses. Note: for data consistency, all images and arrays are stored in the format [row][column] and [row, col], which equates to [y][x]. Field of view and dimension arrays may appear backward (i.e., y before x).
ImagingRetinotopy
extends NWBDataInterface
and includes all elements of NWBDataInterface with the following additions or changes.
Extends: NWBDataInterface
Primitive Type: Group
Default Name: ImagingRetinotopy
Inherits from: NWBDataInterface, NWBContainer, Container
Source filename: nwb.retinotopy.yaml
Source Specification: see Section 3.13.1

Id |
Type |
Description |
---|---|---|
<ImagingRetinotopy> |
Group |
Top level Group for <ImagingRetinotopy>
|
—axis_1_phase_map |
Dataset |
Phase response to stimulus on the first measured axis.
|
——dimension |
Attribute |
Number of rows and columns in the image.
|
——field_of_view |
Attribute |
Size of viewing area, in meters.
|
——unit |
Attribute |
Unit that axis data is stored in (e.g., degrees).
|
—axis_1_power_map |
Dataset |
Power response on the first measured axis. Response is scaled so 0.0 is no power in the response and 1.0 is maximum relative power.
|
——dimension |
Attribute |
Number of rows and columns in the image.
|
——field_of_view |
Attribute |
Size of viewing area, in meters.
|
——unit |
Attribute |
Unit that axis data is stored in (e.g., degrees).
|
—axis_2_phase_map |
Dataset |
Phase response to stimulus on the second measured axis.
|
——dimension |
Attribute |
Number of rows and columns in the image.
|
——field_of_view |
Attribute |
Size of viewing area, in meters.
|
——unit |
Attribute |
Unit that axis data is stored in (e.g., degrees).
|
—axis_2_power_map |
Dataset |
Power response on the second measured axis. Response is scaled so 0.0 is no power in the response and 1.0 is maximum relative power.
|
——dimension |
Attribute |
Number of rows and columns in the image.
|
——field_of_view |
Attribute |
Size of viewing area, in meters.
|
——unit |
Attribute |
Unit that axis data is stored in (e.g., degrees).
|
—axis_descriptions |
Dataset |
Two-element array describing the contents of the two response axis fields. Description should be something like [‘altitude’, ‘azimuth’] or ‘[‘radius’, ‘theta’].
|
—focal_depth_image |
Dataset |
Gray-scale image taken with same settings/parameters (e.g., focal depth, wavelength) as data collection. Array format: [rows][columns].
|
——bits_per_pixel |
Attribute |
Number of bits used to represent each value. This is necessary to determine maximum (white) pixel value.
|
——dimension |
Attribute |
Number of rows and columns in the image.
|
——field_of_view |
Attribute |
Size of viewing area, in meters.
|
——focal_depth |
Attribute |
Focal depth offset, in meters.
|
——format |
Attribute |
Format of image. Right now only ‘raw’ is supported.
|
—sign_map |
Dataset |
Sine of the angle between the direction of the gradient in axis_1 and axis_2.
|
——dimension |
Attribute |
Number of rows and columns in the image.
|
——field_of_view |
Attribute |
Size of viewing area, in meters.
|
—vasculature_image |
Dataset |
Gray-scale anatomical image of cortical surface. Array structure: [rows][columns]
|
——bits_per_pixel |
Attribute |
Number of bits used to represent each value. This is necessary to determine maximum (white) pixel value
|
——dimension |
Attribute |
Number of rows and columns in the image.
|
——field_of_view |
Attribute |
Size of viewing area, in meters.
|
——format |
Attribute |
Format of image. Right now only ‘raw’ is supported.
|
3. Schema Sources
Source Specification: see Section 3.1
3.1. Namespace – NWB core
Description: see Section 1.1
YAML Specification:
1author:
2- Andrew Tritt
3- Oliver Ruebel
4- Ryan Ly
5- Ben Dichter
6- Keith Godfrey
7- Jeff Teeters
8contact:
9- ajtritt@lbl.gov
10- oruebel@lbl.gov
11- rly@lbl.gov
12- bdichter@lbl.gov
13- keithg@alleninstitute.org
14- jteeters@berkeley.edu
15doc: NWB namespace
16full_name: NWB core
17name: core
18schema:
19- namespace: hdmf-common
20- doc: This source module contains base data types used throughout the NWB data
21 format.
22 source: nwb.base.yaml
23 title: Base data types
24- doc: This source module contains neurodata_types for device data.
25 source: nwb.device.yaml
26 title: Devices
27- doc: This source module contains neurodata_types for epoch data.
28 source: nwb.epoch.yaml
29 title: Epochs
30- doc: This source module contains neurodata_types for image data.
31 source: nwb.image.yaml
32 title: Image data
33- doc: Main NWB file specification.
34 source: nwb.file.yaml
35 title: NWB file
36- doc: Miscellaneous types.
37 source: nwb.misc.yaml
38 title: Miscellaneous neurodata_types.
39- doc: This source module contains neurodata_types for behavior data.
40 source: nwb.behavior.yaml
41 title: Behavior
42- doc: This source module contains neurodata_types for extracellular
43 electrophysiology data.
44 source: nwb.ecephys.yaml
45 title: Extracellular electrophysiology
46- doc: This source module contains neurodata_types for intracellular
47 electrophysiology data.
48 source: nwb.icephys.yaml
49 title: Intracellular electrophysiology
50- doc: This source module contains neurodata_types for opto-genetics data.
51 source: nwb.ogen.yaml
52 title: Optogenetics
53- doc: This source module contains neurodata_types for optical physiology data.
54 source: nwb.ophys.yaml
55 title: Optical physiology
56- doc: This source module contains neurodata_type for retinotopy data.
57 source: nwb.retinotopy.yaml
58 title: Retinotopy
59version: 2.8.0
3.2. Base data types
This source module contains base data types used throughout the NWB data format.
3.2.1. NWBData
Extends: Data
Description: see Section 2.1.1
YAML Specification:
1doc: An abstract data type for a dataset.
2neurodata_type_def: NWBData
3neurodata_type_inc: Data
3.2.2. TimeSeriesReferenceVectorData
Extends: VectorData
Description: see Section 2.1.2
YAML Specification:
1attributes:
2- doc: Description of what these vectors represent.
3 dtype: text
4 name: description
5default_name: timeseries
6doc: Column storing references to a TimeSeries (rows). For each TimeSeries this
7 VectorData column stores the start_index and count to indicate the range in
8 time to be selected as well as an object reference to the TimeSeries.
9dtype:
10- doc: Start index into the TimeSeries 'data' and 'timestamp' datasets of the
11 referenced TimeSeries. The first dimension of those arrays is always time.
12 dtype: int32
13 name: idx_start
14- doc: Number of data samples available in this time series, during this epoch
15 dtype: int32
16 name: count
17- doc: The TimeSeries that this index applies to
18 dtype:
19 reftype: object
20 target_type: TimeSeries
21 name: timeseries
22neurodata_type_def: TimeSeriesReferenceVectorData
23neurodata_type_inc: VectorData
3.2.3. Image
Extends: NWBData
Description: see Section 2.1.3
YAML Specification:
1attributes:
2- doc: Pixel resolution of the image, in pixels per centimeter.
3 dtype: float32
4 name: resolution
5 required: false
6- doc: Description of the image.
7 dtype: text
8 name: description
9 required: false
10dims:
11- - x
12 - y
13- - x
14 - y
15 - r, g, b
16- - x
17 - y
18 - r, g, b, a
19doc: An abstract data type for an image. Shape can be 2-D (x, y), or 3-D where
20 the third dimension can have three or four elements, e.g. (x, y, (r, g, b)) or
21 (x, y, (r, g, b, a)).
22dtype: numeric
23neurodata_type_def: Image
24neurodata_type_inc: NWBData
25shape:
26- -
27 -
28- -
29 -
30 - 3
31- -
32 -
33 - 4
3.2.4. ImageReferences
Extends: NWBData
Description: see Section 2.1.4
YAML Specification:
1dims:
2- num_images
3doc: Ordered dataset of references to Image objects.
4dtype:
5 reftype: object
6 target_type: Image
7neurodata_type_def: ImageReferences
8neurodata_type_inc: NWBData
9shape:
10-
3.2.5. NWBContainer
Extends: Container
Description: see Section 2.1.5
YAML Specification:
1doc: An abstract data type for a generic container storing collections of data
2 and metadata. Base type for all data and metadata containers.
3neurodata_type_def: NWBContainer
4neurodata_type_inc: Container
3.2.6. NWBDataInterface
Extends: NWBContainer
Description: see Section 2.1.6
YAML Specification:
1doc: An abstract data type for a generic container storing collections of data,
2 as opposed to metadata.
3neurodata_type_def: NWBDataInterface
4neurodata_type_inc: NWBContainer
3.2.7. TimeSeries
Extends: NWBDataInterface
Description: see Section 2.1.7
YAML Specification:
1attributes:
2- default_value: no description
3 doc: Description of the time series.
4 dtype: text
5 name: description
6 required: false
7- default_value: no comments
8 doc: Human-readable comments about the TimeSeries. This second descriptive
9 field can be used to store additional information, or descriptive
10 information if the primary description field is populated with a
11 computer-readable string.
12 dtype: text
13 name: comments
14 required: false
15datasets:
16- attributes:
17 - default_value: 1.0
18 doc: Scalar to multiply each element in data to convert it to the specified
19 'unit'. If the data are stored in acquisition system units or other units
20 that require a conversion to be interpretable, multiply the data by
21 'conversion' to convert the data to the specified 'unit'. e.g. if the data
22 acquisition system stores values in this object as signed 16-bit integers
23 (int16 range -32,768 to 32,767) that correspond to a 5V range (-2.5V to
24 2.5V), and the data acquisition system gain is 8000X, then the
25 'conversion' multiplier to get from raw data acquisition values to
26 recorded volts is 2.5/32768/8000 = 9.5367e-9.
27 dtype: float32
28 name: conversion
29 required: false
30 - default_value: 0.0
31 doc: Scalar to add to the data after scaling by 'conversion' to finalize its
32 coercion to the specified 'unit'. Two common examples of this include (a)
33 data stored in an unsigned type that requires a shift after scaling to
34 re-center the data, and (b) specialized recording devices that naturally
35 cause a scalar offset with respect to the true units.
36 dtype: float32
37 name: offset
38 required: false
39 - default_value: -1.0
40 doc: Smallest meaningful difference between values in data, stored in the
41 specified by unit, e.g., the change in value of the least significant bit,
42 or a larger number if signal noise is known to be present. If unknown, use
43 -1.0.
44 dtype: float32
45 name: resolution
46 required: false
47 - doc: Base unit of measurement for working with the data. Actual stored
48 values are not necessarily stored in these units. To access the data in
49 these units, multiply 'data' by 'conversion' and add 'offset'.
50 dtype: text
51 name: unit
52 - doc: Optionally describe the continuity of the data. Can be "continuous",
53 "instantaneous", or "step". For example, a voltage trace would be
54 "continuous", because samples are recorded from a continuous process. An
55 array of lick times would be "instantaneous", because the data represents
56 distinct moments in time. Times of image presentations would be "step"
57 because the picture remains the same until the next timepoint. This field
58 is optional, but is useful in providing information about the underlying
59 data. It may inform the way this data is interpreted, the way it is
60 visualized, and what analysis methods are applicable.
61 dtype: text
62 name: continuity
63 required: false
64 dims:
65 - - num_times
66 - - num_times
67 - num_DIM2
68 - - num_times
69 - num_DIM2
70 - num_DIM3
71 - - num_times
72 - num_DIM2
73 - num_DIM3
74 - num_DIM4
75 doc: Data values. Data can be in 1-D, 2-D, 3-D, or 4-D. The first dimension
76 should always represent time. This can also be used to store binary data
77 (e.g., image frames). This can also be a link to data stored in an external
78 file.
79 name: data
80 shape:
81 - -
82 - -
83 -
84 - -
85 -
86 -
87 - -
88 -
89 -
90 -
91- attributes:
92 - doc: Sampling rate, in Hz.
93 dtype: float32
94 name: rate
95 - doc: Unit of measurement for time, which is fixed to 'seconds'.
96 dtype: text
97 name: unit
98 value: seconds
99 doc: Timestamp of the first sample in seconds. When timestamps are uniformly
100 spaced, the timestamp of the first sample can be specified and all
101 subsequent ones calculated from the sampling rate attribute.
102 dtype: float64
103 name: starting_time
104 quantity: '?'
105- attributes:
106 - doc: Value is '1'
107 dtype: int32
108 name: interval
109 value: 1
110 - doc: Unit of measurement for timestamps, which is fixed to 'seconds'.
111 dtype: text
112 name: unit
113 value: seconds
114 dims:
115 - num_times
116 doc: Timestamps for samples stored in data, in seconds, relative to the common
117 experiment master-clock stored in NWBFile.timestamps_reference_time.
118 dtype: float64
119 name: timestamps
120 quantity: '?'
121 shape:
122 -
123- dims:
124 - num_times
125 doc: Numerical labels that apply to each time point in data for the purpose of
126 querying and slicing data by these values. If present, the length of this
127 array should be the same size as the first dimension of data.
128 dtype: uint8
129 name: control
130 quantity: '?'
131 shape:
132 -
133- dims:
134 - num_control_values
135 doc: Description of each control value. Must be present if control is present.
136 If present, control_description[0] should describe time points where control
137 == 0.
138 dtype: text
139 name: control_description
140 quantity: '?'
141 shape:
142 -
143doc: General purpose time series.
144groups:
145- doc: Lab-specific time and sync information as provided directly from hardware
146 devices and that is necessary for aligning all acquired time information to
147 a common timebase. The timestamp array stores time in the common timebase.
148 This group will usually only be populated in TimeSeries that are stored
149 external to the NWB file, in files storing raw data. Once timestamp data is
150 calculated, the contents of 'sync' are mostly for archival purposes.
151 name: sync
152 quantity: '?'
153neurodata_type_def: TimeSeries
154neurodata_type_inc: NWBDataInterface
3.2.8. ProcessingModule
Extends: NWBContainer
Description: see Section 2.1.8
YAML Specification:
1attributes:
2- doc: Description of this collection of processed data.
3 dtype: text
4 name: description
5doc: A collection of processed data.
6groups:
7- doc: Data objects stored in this collection.
8 neurodata_type_inc: NWBDataInterface
9 quantity: '*'
10- doc: Tables stored in this collection.
11 neurodata_type_inc: DynamicTable
12 quantity: '*'
13neurodata_type_def: ProcessingModule
14neurodata_type_inc: NWBContainer
3.2.9. Images
Extends: NWBDataInterface
Description: see Section 2.1.9
YAML Specification:
1attributes:
2- doc: Description of this collection of images.
3 dtype: text
4 name: description
5datasets:
6- doc: Images stored in this collection.
7 neurodata_type_inc: Image
8 quantity: +
9- doc: Ordered dataset of references to Image objects stored in the parent
10 group. Each Image object in the Images group should be stored once and only
11 once, so the dataset should have the same length as the number of images.
12 name: order_of_images
13 neurodata_type_inc: ImageReferences
14 quantity: '?'
15default_name: Images
16doc: A collection of images with an optional way to specify the order of the
17 images using the "order_of_images" dataset. An order must be specified if the
18 images are referenced by index, e.g., from an IndexSeries.
19neurodata_type_def: Images
20neurodata_type_inc: NWBDataInterface
3.3. Devices
This source module contains neurodata_types for device data.
3.3.1. Device
Extends: NWBContainer
Description: see Section 2.2.1
YAML Specification:
1attributes:
2- doc: Description of the device as free-form text. If there is any
3 software/firmware associated with the device, the names and versions of
4 those can be added to NWBFile.was_generated_by.
5 dtype: text
6 name: description
7 required: false
8- doc: The name of the manufacturer of the device, e.g., Imec, Plexon, Thorlabs.
9 dtype: text
10 name: manufacturer
11 required: false
12- doc: The model number (or part/product number) of the device, e.g.,
13 PRB_1_4_0480_1, PLX-VP-32-15SE(75)-(260-80)(460-10)-300-(1)CON/32m-V,
14 BERGAMO.
15 dtype: text
16 name: model_number
17 required: false
18- doc: The model name of the device, e.g., Neuropixels 1.0, V-Probe, Bergamo
19 III.
20 dtype: text
21 name: model_name
22 required: false
23- doc: The serial number of the device.
24 dtype: text
25 name: serial_number
26 required: false
27doc: Metadata about a data acquisition device, e.g., recording system,
28 electrode, microscope.
29neurodata_type_def: Device
30neurodata_type_inc: NWBContainer
3.4. Epochs
This source module contains neurodata_types for epoch data.
3.4.1. TimeIntervals
Extends: DynamicTable
Description: see Section 2.3.1
YAML Specification:
1attributes:
2- dims:
3 - num_columns
4 doc: The names of the columns in this table. This should be used to specify an
5 order to the columns.
6 dtype: text
7 name: colnames
8 shape:
9 -
10- doc: Description of what is in this dynamic table.
11 dtype: text
12 name: description
13datasets:
14- doc: Start time of epoch, in seconds.
15 dtype: float32
16 name: start_time
17 neurodata_type_inc: VectorData
18- doc: Stop time of epoch, in seconds.
19 dtype: float32
20 name: stop_time
21 neurodata_type_inc: VectorData
22- doc: User-defined tags that identify or categorize events.
23 dtype: text
24 name: tags
25 neurodata_type_inc: VectorData
26 quantity: '?'
27- doc: Index for tags.
28 name: tags_index
29 neurodata_type_inc: VectorIndex
30 quantity: '?'
31- doc: An index into a TimeSeries object.
32 name: timeseries
33 neurodata_type_inc: TimeSeriesReferenceVectorData
34 quantity: '?'
35- doc: Index for timeseries.
36 name: timeseries_index
37 neurodata_type_inc: VectorIndex
38 quantity: '?'
39- dims:
40 - num_rows
41 doc: Array of unique identifiers for the rows of this dynamic table.
42 dtype: int
43 name: id
44 neurodata_type_inc: ElementIdentifiers
45 shape:
46 -
47- doc: Vector columns, including index columns, of this dynamic table.
48 neurodata_type_inc: VectorData
49 quantity: '*'
50doc: A container for aggregating epoch data and the TimeSeries that each epoch
51 applies to.
52neurodata_type_def: TimeIntervals
53neurodata_type_inc: DynamicTable
3.5. Image data
This source module contains neurodata_types for image data.
3.5.1. GrayscaleImage
Extends: Image
Description: see Section 2.4.1
YAML Specification:
1attributes:
2- doc: Pixel resolution of the image, in pixels per centimeter.
3 dtype: float32
4 name: resolution
5 required: false
6- doc: Description of the image.
7 dtype: text
8 name: description
9 required: false
10dims:
11- x
12- y
13doc: A grayscale image.
14dtype: numeric
15neurodata_type_def: GrayscaleImage
16neurodata_type_inc: Image
17shape:
18-
19-
3.5.2. RGBImage
Extends: Image
Description: see Section 2.4.2
YAML Specification:
1attributes:
2- doc: Pixel resolution of the image, in pixels per centimeter.
3 dtype: float32
4 name: resolution
5 required: false
6- doc: Description of the image.
7 dtype: text
8 name: description
9 required: false
10dims:
11- x
12- y
13- r, g, b
14doc: A color image.
15dtype: numeric
16neurodata_type_def: RGBImage
17neurodata_type_inc: Image
18shape:
19-
20-
21- 3
3.5.3. RGBAImage
Extends: Image
Description: see Section 2.4.3
YAML Specification:
1attributes:
2- doc: Pixel resolution of the image, in pixels per centimeter.
3 dtype: float32
4 name: resolution
5 required: false
6- doc: Description of the image.
7 dtype: text
8 name: description
9 required: false
10dims:
11- x
12- y
13- r, g, b, a
14doc: A color image with transparency.
15dtype: numeric
16neurodata_type_def: RGBAImage
17neurodata_type_inc: Image
18shape:
19-
20-
21- 4
3.5.4. ImageSeries
Extends: TimeSeries
Description: see Section 2.4.4
YAML Specification:
1attributes:
2- default_value: no description
3 doc: Description of the time series.
4 dtype: text
5 name: description
6 required: false
7- default_value: no comments
8 doc: Human-readable comments about the TimeSeries. This second descriptive
9 field can be used to store additional information, or descriptive
10 information if the primary description field is populated with a
11 computer-readable string.
12 dtype: text
13 name: comments
14 required: false
15datasets:
16- attributes:
17 - default_value: 1.0
18 doc: Scalar to multiply each element in data to convert it to the specified
19 'unit'. If the data are stored in acquisition system units or other units
20 that require a conversion to be interpretable, multiply the data by
21 'conversion' to convert the data to the specified 'unit'. e.g. if the data
22 acquisition system stores values in this object as signed 16-bit integers
23 (int16 range -32,768 to 32,767) that correspond to a 5V range (-2.5V to
24 2.5V), and the data acquisition system gain is 8000X, then the
25 'conversion' multiplier to get from raw data acquisition values to
26 recorded volts is 2.5/32768/8000 = 9.5367e-9.
27 dtype: float32
28 name: conversion
29 required: false
30 - default_value: 0.0
31 doc: Scalar to add to the data after scaling by 'conversion' to finalize its
32 coercion to the specified 'unit'. Two common examples of this include (a)
33 data stored in an unsigned type that requires a shift after scaling to
34 re-center the data, and (b) specialized recording devices that naturally
35 cause a scalar offset with respect to the true units.
36 dtype: float32
37 name: offset
38 required: false
39 - default_value: -1.0
40 doc: Smallest meaningful difference between values in data, stored in the
41 specified by unit, e.g., the change in value of the least significant bit,
42 or a larger number if signal noise is known to be present. If unknown, use
43 -1.0.
44 dtype: float32
45 name: resolution
46 required: false
47 - doc: Base unit of measurement for working with the data. Actual stored
48 values are not necessarily stored in these units. To access the data in
49 these units, multiply 'data' by 'conversion' and add 'offset'.
50 dtype: text
51 name: unit
52 - doc: Optionally describe the continuity of the data. Can be "continuous",
53 "instantaneous", or "step". For example, a voltage trace would be
54 "continuous", because samples are recorded from a continuous process. An
55 array of lick times would be "instantaneous", because the data represents
56 distinct moments in time. Times of image presentations would be "step"
57 because the picture remains the same until the next timepoint. This field
58 is optional, but is useful in providing information about the underlying
59 data. It may inform the way this data is interpreted, the way it is
60 visualized, and what analysis methods are applicable.
61 dtype: text
62 name: continuity
63 required: false
64 dims:
65 - - frame
66 - x
67 - y
68 - - frame
69 - x
70 - y
71 - z
72 doc: Binary data representing images across frames. If data are stored in an
73 external file, this should be an empty 3D array.
74 dtype: numeric
75 name: data
76 shape:
77 - -
78 -
79 -
80 - -
81 -
82 -
83 -
84- dims:
85 - rank
86 doc: Number of pixels on x, y, (and z) axes.
87 dtype: int32
88 name: dimension
89 quantity: '?'
90 shape:
91 -
92- attributes:
93 - dims:
94 - num_files
95 doc: Each external image may contain one or more consecutive frames of the
96 full ImageSeries. This attribute serves as an index to indicate which
97 frames each file contains, to facilitate random access. The
98 'starting_frame' attribute, hence, contains a list of frame numbers within
99 the full ImageSeries of the first frame of each file listed in the parent
100 'external_file' dataset. Zero-based indexing is used (hence, the first
101 element will always be zero). For example, if the 'external_file' dataset
102 has three paths to files and the first file has 5 frames, the second file
103 has 10 frames, and the third file has 20 frames, then this attribute will
104 have values [0, 5, 15]. If there is a single external file that holds all
105 of the frames of the ImageSeries (and so there is a single element in the
106 'external_file' dataset), then this attribute should have value [0].
107 dtype: int32
108 name: starting_frame
109 shape:
110 -
111 dims:
112 - num_files
113 doc: Paths to one or more external file(s). The field is only present if
114 format='external'. This is only relevant if the image series is stored in
115 the file system as one or more image file(s). This field should NOT be used
116 if the image is stored in another NWB file and that file is linked to this
117 file.
118 dtype: text
119 name: external_file
120 quantity: '?'
121 shape:
122 -
123- default_value: raw
124 doc: Format of image. If this is 'external', then the attribute
125 'external_file' contains the path information to the image files. If this is
126 'raw', then the raw (single-channel) binary data is stored in the 'data'
127 dataset. If this attribute is not present, then the default format='raw'
128 case is assumed.
129 dtype: text
130 name: format
131 quantity: '?'
132- attributes:
133 - doc: Sampling rate, in Hz.
134 dtype: float32
135 name: rate
136 - doc: Unit of measurement for time, which is fixed to 'seconds'.
137 dtype: text
138 name: unit
139 value: seconds
140 doc: Timestamp of the first sample in seconds. When timestamps are uniformly
141 spaced, the timestamp of the first sample can be specified and all
142 subsequent ones calculated from the sampling rate attribute.
143 dtype: float64
144 name: starting_time
145 quantity: '?'
146- attributes:
147 - doc: Value is '1'
148 dtype: int32
149 name: interval
150 value: 1
151 - doc: Unit of measurement for timestamps, which is fixed to 'seconds'.
152 dtype: text
153 name: unit
154 value: seconds
155 dims:
156 - num_times
157 doc: Timestamps for samples stored in data, in seconds, relative to the common
158 experiment master-clock stored in NWBFile.timestamps_reference_time.
159 dtype: float64
160 name: timestamps
161 quantity: '?'
162 shape:
163 -
164- dims:
165 - num_times
166 doc: Numerical labels that apply to each time point in data for the purpose of
167 querying and slicing data by these values. If present, the length of this
168 array should be the same size as the first dimension of data.
169 dtype: uint8
170 name: control
171 quantity: '?'
172 shape:
173 -
174- dims:
175 - num_control_values
176 doc: Description of each control value. Must be present if control is present.
177 If present, control_description[0] should describe time points where control
178 == 0.
179 dtype: text
180 name: control_description
181 quantity: '?'
182 shape:
183 -
184doc: General image data that is common between acquisition and stimulus time
185 series. Sometimes the image data is stored in the file in a raw format while
186 other times it will be stored as a series of external image files in the host
187 file system. The data field will either be binary data, if the data is stored
188 in the NWB file, or empty, if the data is stored in an external image stack.
189 [frame][x][y] or [frame][x][y][z].
190groups:
191- doc: Lab-specific time and sync information as provided directly from hardware
192 devices and that is necessary for aligning all acquired time information to
193 a common timebase. The timestamp array stores time in the common timebase.
194 This group will usually only be populated in TimeSeries that are stored
195 external to the NWB file, in files storing raw data. Once timestamp data is
196 calculated, the contents of 'sync' are mostly for archival purposes.
197 name: sync
198 quantity: '?'
199links:
200- doc: Link to the Device object that was used to capture these images.
201 name: device
202 quantity: '?'
203 target_type: Device
204neurodata_type_def: ImageSeries
205neurodata_type_inc: TimeSeries
3.5.5. ImageMaskSeries
Extends: ImageSeries
Description: see Section 2.4.5
YAML Specification:
1attributes:
2- default_value: no description
3 doc: Description of the time series.
4 dtype: text
5 name: description
6 required: false
7- default_value: no comments
8 doc: Human-readable comments about the TimeSeries. This second descriptive
9 field can be used to store additional information, or descriptive
10 information if the primary description field is populated with a
11 computer-readable string.
12 dtype: text
13 name: comments
14 required: false
15datasets:
16- attributes:
17 - default_value: 1.0
18 doc: Scalar to multiply each element in data to convert it to the specified
19 'unit'. If the data are stored in acquisition system units or other units
20 that require a conversion to be interpretable, multiply the data by
21 'conversion' to convert the data to the specified 'unit'. e.g. if the data
22 acquisition system stores values in this object as signed 16-bit integers
23 (int16 range -32,768 to 32,767) that correspond to a 5V range (-2.5V to
24 2.5V), and the data acquisition system gain is 8000X, then the
25 'conversion' multiplier to get from raw data acquisition values to
26 recorded volts is 2.5/32768/8000 = 9.5367e-9.
27 dtype: float32
28 name: conversion
29 required: false
30 - default_value: 0.0
31 doc: Scalar to add to the data after scaling by 'conversion' to finalize its
32 coercion to the specified 'unit'. Two common examples of this include (a)
33 data stored in an unsigned type that requires a shift after scaling to
34 re-center the data, and (b) specialized recording devices that naturally
35 cause a scalar offset with respect to the true units.
36 dtype: float32
37 name: offset
38 required: false
39 - default_value: -1.0
40 doc: Smallest meaningful difference between values in data, stored in the
41 specified by unit, e.g., the change in value of the least significant bit,
42 or a larger number if signal noise is known to be present. If unknown, use
43 -1.0.
44 dtype: float32
45 name: resolution
46 required: false
47 - doc: Base unit of measurement for working with the data. Actual stored
48 values are not necessarily stored in these units. To access the data in
49 these units, multiply 'data' by 'conversion' and add 'offset'.
50 dtype: text
51 name: unit
52 - doc: Optionally describe the continuity of the data. Can be "continuous",
53 "instantaneous", or "step". For example, a voltage trace would be
54 "continuous", because samples are recorded from a continuous process. An
55 array of lick times would be "instantaneous", because the data represents
56 distinct moments in time. Times of image presentations would be "step"
57 because the picture remains the same until the next timepoint. This field
58 is optional, but is useful in providing information about the underlying
59 data. It may inform the way this data is interpreted, the way it is
60 visualized, and what analysis methods are applicable.
61 dtype: text
62 name: continuity
63 required: false
64 dims:
65 - - frame
66 - x
67 - y
68 - - frame
69 - x
70 - y
71 - z
72 doc: Binary data representing images across frames. If data are stored in an
73 external file, this should be an empty 3D array.
74 dtype: numeric
75 name: data
76 shape:
77 - -
78 -
79 -
80 - -
81 -
82 -
83 -
84- dims:
85 - rank
86 doc: Number of pixels on x, y, (and z) axes.
87 dtype: int32
88 name: dimension
89 quantity: '?'
90 shape:
91 -
92- attributes:
93 - dims:
94 - num_files
95 doc: Each external image may contain one or more consecutive frames of the
96 full ImageSeries. This attribute serves as an index to indicate which
97 frames each file contains, to facilitate random access. The
98 'starting_frame' attribute, hence, contains a list of frame numbers within
99 the full ImageSeries of the first frame of each file listed in the parent
100 'external_file' dataset. Zero-based indexing is used (hence, the first
101 element will always be zero). For example, if the 'external_file' dataset
102 has three paths to files and the first file has 5 frames, the second file
103 has 10 frames, and the third file has 20 frames, then this attribute will
104 have values [0, 5, 15]. If there is a single external file that holds all
105 of the frames of the ImageSeries (and so there is a single element in the
106 'external_file' dataset), then this attribute should have value [0].
107 dtype: int32
108 name: starting_frame
109 shape:
110 -
111 dims:
112 - num_files
113 doc: Paths to one or more external file(s). The field is only present if
114 format='external'. This is only relevant if the image series is stored in
115 the file system as one or more image file(s). This field should NOT be used
116 if the image is stored in another NWB file and that file is linked to this
117 file.
118 dtype: text
119 name: external_file
120 quantity: '?'
121 shape:
122 -
123- default_value: raw
124 doc: Format of image. If this is 'external', then the attribute
125 'external_file' contains the path information to the image files. If this is
126 'raw', then the raw (single-channel) binary data is stored in the 'data'
127 dataset. If this attribute is not present, then the default format='raw'
128 case is assumed.
129 dtype: text
130 name: format
131 quantity: '?'
132- attributes:
133 - doc: Sampling rate, in Hz.
134 dtype: float32
135 name: rate
136 - doc: Unit of measurement for time, which is fixed to 'seconds'.
137 dtype: text
138 name: unit
139 value: seconds
140 doc: Timestamp of the first sample in seconds. When timestamps are uniformly
141 spaced, the timestamp of the first sample can be specified and all
142 subsequent ones calculated from the sampling rate attribute.
143 dtype: float64
144 name: starting_time
145 quantity: '?'
146- attributes:
147 - doc: Value is '1'
148 dtype: int32
149 name: interval
150 value: 1
151 - doc: Unit of measurement for timestamps, which is fixed to 'seconds'.
152 dtype: text
153 name: unit
154 value: seconds
155 dims:
156 - num_times
157 doc: Timestamps for samples stored in data, in seconds, relative to the common
158 experiment master-clock stored in NWBFile.timestamps_reference_time.
159 dtype: float64
160 name: timestamps
161 quantity: '?'
162 shape:
163 -
164- dims:
165 - num_times
166 doc: Numerical labels that apply to each time point in data for the purpose of
167 querying and slicing data by these values. If present, the length of this
168 array should be the same size as the first dimension of data.
169 dtype: uint8
170 name: control
171 quantity: '?'
172 shape:
173 -
174- dims:
175 - num_control_values
176 doc: Description of each control value. Must be present if control is present.
177 If present, control_description[0] should describe time points where control
178 == 0.
179 dtype: text
180 name: control_description
181 quantity: '?'
182 shape:
183 -
184doc: DEPRECATED. An alpha mask that is applied to a presented visual stimulus.
185 The 'data' array contains an array of mask values that are applied to the
186 displayed image. Mask values are stored as RGBA. Mask can vary with time. The
187 timestamps array indicates the starting time of a mask, and that mask pattern
188 continues until it's explicitly changed.
189groups:
190- doc: Lab-specific time and sync information as provided directly from hardware
191 devices and that is necessary for aligning all acquired time information to
192 a common timebase. The timestamp array stores time in the common timebase.
193 This group will usually only be populated in TimeSeries that are stored
194 external to the NWB file, in files storing raw data. Once timestamp data is
195 calculated, the contents of 'sync' are mostly for archival purposes.
196 name: sync
197 quantity: '?'
198links:
199- doc: Link to ImageSeries object that this image mask is applied to.
200 name: masked_imageseries
201 target_type: ImageSeries
202- doc: Link to the Device object that was used to capture these images.
203 name: device
204 quantity: '?'
205 target_type: Device
206neurodata_type_def: ImageMaskSeries
207neurodata_type_inc: ImageSeries
3.5.6. OpticalSeries
Extends: ImageSeries
Description: see Section 2.4.6
YAML Specification:
1attributes:
2- default_value: no description
3 doc: Description of the time series.
4 dtype: text
5 name: description
6 required: false
7- default_value: no comments
8 doc: Human-readable comments about the TimeSeries. This second descriptive
9 field can be used to store additional information, or descriptive
10 information if the primary description field is populated with a
11 computer-readable string.
12 dtype: text
13 name: comments
14 required: false
15datasets:
16- doc: Distance from camera/monitor to target/eye.
17 dtype: float32
18 name: distance
19 quantity: '?'
20- dims:
21 - - width, height
22 - - width, height, depth
23 doc: Width, height and depth of image, or imaged area, in meters.
24 dtype: float32
25 name: field_of_view
26 quantity: '?'
27 shape:
28 - - 2
29 - - 3
30- attributes:
31 - default_value: 1.0
32 doc: Scalar to multiply each element in data to convert it to the specified
33 'unit'. If the data are stored in acquisition system units or other units
34 that require a conversion to be interpretable, multiply the data by
35 'conversion' to convert the data to the specified 'unit'. e.g. if the data
36 acquisition system stores values in this object as signed 16-bit integers
37 (int16 range -32,768 to 32,767) that correspond to a 5V range (-2.5V to
38 2.5V), and the data acquisition system gain is 8000X, then the
39 'conversion' multiplier to get from raw data acquisition values to
40 recorded volts is 2.5/32768/8000 = 9.5367e-9.
41 dtype: float32
42 name: conversion
43 required: false
44 - default_value: 0.0
45 doc: Scalar to add to the data after scaling by 'conversion' to finalize its
46 coercion to the specified 'unit'. Two common examples of this include (a)
47 data stored in an unsigned type that requires a shift after scaling to
48 re-center the data, and (b) specialized recording devices that naturally
49 cause a scalar offset with respect to the true units.
50 dtype: float32
51 name: offset
52 required: false
53 - default_value: -1.0
54 doc: Smallest meaningful difference between values in data, stored in the
55 specified by unit, e.g., the change in value of the least significant bit,
56 or a larger number if signal noise is known to be present. If unknown, use
57 -1.0.
58 dtype: float32
59 name: resolution
60 required: false
61 - doc: Base unit of measurement for working with the data. Actual stored
62 values are not necessarily stored in these units. To access the data in
63 these units, multiply 'data' by 'conversion' and add 'offset'.
64 dtype: text
65 name: unit
66 - doc: Optionally describe the continuity of the data. Can be "continuous",
67 "instantaneous", or "step". For example, a voltage trace would be
68 "continuous", because samples are recorded from a continuous process. An
69 array of lick times would be "instantaneous", because the data represents
70 distinct moments in time. Times of image presentations would be "step"
71 because the picture remains the same until the next timepoint. This field
72 is optional, but is useful in providing information about the underlying
73 data. It may inform the way this data is interpreted, the way it is
74 visualized, and what analysis methods are applicable.
75 dtype: text
76 name: continuity
77 required: false
78 dims:
79 - - frame
80 - x
81 - y
82 - - frame
83 - x
84 - y
85 - r, g, b
86 doc: Images presented to subject, either grayscale or RGB
87 dtype: numeric
88 name: data
89 shape:
90 - -
91 -
92 -
93 - -
94 -
95 -
96 - 3
97- doc: Description of image relative to some reference frame (e.g., which way is
98 up). Must also specify frame of reference.
99 dtype: text
100 name: orientation
101 quantity: '?'
102- dims:
103 - rank
104 doc: Number of pixels on x, y, (and z) axes.
105 dtype: int32
106 name: dimension
107 quantity: '?'
108 shape:
109 -
110- attributes:
111 - dims:
112 - num_files
113 doc: Each external image may contain one or more consecutive frames of the
114 full ImageSeries. This attribute serves as an index to indicate which
115 frames each file contains, to facilitate random access. The
116 'starting_frame' attribute, hence, contains a list of frame numbers within
117 the full ImageSeries of the first frame of each file listed in the parent
118 'external_file' dataset. Zero-based indexing is used (hence, the first
119 element will always be zero). For example, if the 'external_file' dataset
120 has three paths to files and the first file has 5 frames, the second file
121 has 10 frames, and the third file has 20 frames, then this attribute will
122 have values [0, 5, 15]. If there is a single external file that holds all
123 of the frames of the ImageSeries (and so there is a single element in the
124 'external_file' dataset), then this attribute should have value [0].
125 dtype: int32
126 name: starting_frame
127 shape:
128 -
129 dims:
130 - num_files
131 doc: Paths to one or more external file(s). The field is only present if
132 format='external'. This is only relevant if the image series is stored in
133 the file system as one or more image file(s). This field should NOT be used
134 if the image is stored in another NWB file and that file is linked to this
135 file.
136 dtype: text
137 name: external_file
138 quantity: '?'
139 shape:
140 -
141- default_value: raw
142 doc: Format of image. If this is 'external', then the attribute
143 'external_file' contains the path information to the image files. If this is
144 'raw', then the raw (single-channel) binary data is stored in the 'data'
145 dataset. If this attribute is not present, then the default format='raw'
146 case is assumed.
147 dtype: text
148 name: format
149 quantity: '?'
150- attributes:
151 - doc: Sampling rate, in Hz.
152 dtype: float32
153 name: rate
154 - doc: Unit of measurement for time, which is fixed to 'seconds'.
155 dtype: text
156 name: unit
157 value: seconds
158 doc: Timestamp of the first sample in seconds. When timestamps are uniformly
159 spaced, the timestamp of the first sample can be specified and all
160 subsequent ones calculated from the sampling rate attribute.
161 dtype: float64
162 name: starting_time
163 quantity: '?'
164- attributes:
165 - doc: Value is '1'
166 dtype: int32
167 name: interval
168 value: 1
169 - doc: Unit of measurement for timestamps, which is fixed to 'seconds'.
170 dtype: text
171 name: unit
172 value: seconds
173 dims:
174 - num_times
175 doc: Timestamps for samples stored in data, in seconds, relative to the common
176 experiment master-clock stored in NWBFile.timestamps_reference_time.
177 dtype: float64
178 name: timestamps
179 quantity: '?'
180 shape:
181 -
182- dims:
183 - num_times
184 doc: Numerical labels that apply to each time point in data for the purpose of
185 querying and slicing data by these values. If present, the length of this
186 array should be the same size as the first dimension of data.
187 dtype: uint8
188 name: control
189 quantity: '?'
190 shape:
191 -
192- dims:
193 - num_control_values
194 doc: Description of each control value. Must be present if control is present.
195 If present, control_description[0] should describe time points where control
196 == 0.
197 dtype: text
198 name: control_description
199 quantity: '?'
200 shape:
201 -
202doc: Image data that is presented or recorded. A stimulus template movie will be
203 stored only as an image. When the image is presented as stimulus, additional
204 data is required, such as field of view (e.g., how much of the visual field
205 the image covers, or how what is the area of the target being imaged). If the
206 OpticalSeries represents acquired imaging data, orientation is also important.
207groups:
208- doc: Lab-specific time and sync information as provided directly from hardware
209 devices and that is necessary for aligning all acquired time information to
210 a common timebase. The timestamp array stores time in the common timebase.
211 This group will usually only be populated in TimeSeries that are stored
212 external to the NWB file, in files storing raw data. Once timestamp data is
213 calculated, the contents of 'sync' are mostly for archival purposes.
214 name: sync
215 quantity: '?'
216links:
217- doc: Link to the Device object that was used to capture these images.
218 name: device
219 quantity: '?'
220 target_type: Device
221neurodata_type_def: OpticalSeries
222neurodata_type_inc: ImageSeries
3.5.7. IndexSeries
Extends: TimeSeries
Description: see Section 2.4.7
YAML Specification:
1attributes:
2- default_value: no description
3 doc: Description of the time series.
4 dtype: text
5 name: description
6 required: false
7- default_value: no comments
8 doc: Human-readable comments about the TimeSeries. This second descriptive
9 field can be used to store additional information, or descriptive
10 information if the primary description field is populated with a
11 computer-readable string.
12 dtype: text
13 name: comments
14 required: false
15datasets:
16- attributes:
17 - doc: This field is unused by IndexSeries.
18 dtype: float32
19 name: conversion
20 required: false
21 - doc: This field is unused by IndexSeries.
22 dtype: float32
23 name: resolution
24 required: false
25 - doc: This field is unused by IndexSeries.
26 dtype: float32
27 name: offset
28 required: false
29 - doc: This field is unused by IndexSeries and has the value N/A.
30 dtype: text
31 name: unit
32 value: N/A
33 - doc: Optionally describe the continuity of the data. Can be "continuous",
34 "instantaneous", or "step". For example, a voltage trace would be
35 "continuous", because samples are recorded from a continuous process. An
36 array of lick times would be "instantaneous", because the data represents
37 distinct moments in time. Times of image presentations would be "step"
38 because the picture remains the same until the next timepoint. This field
39 is optional, but is useful in providing information about the underlying
40 data. It may inform the way this data is interpreted, the way it is
41 visualized, and what analysis methods are applicable.
42 dtype: text
43 name: continuity
44 required: false
45 dims:
46 - num_times
47 doc: Index of the image (using zero-indexing) in the linked Images object.
48 dtype: uint32
49 name: data
50 shape:
51 -
52- attributes:
53 - doc: Sampling rate, in Hz.
54 dtype: float32
55 name: rate
56 - doc: Unit of measurement for time, which is fixed to 'seconds'.
57 dtype: text
58 name: unit
59 value: seconds
60 doc: Timestamp of the first sample in seconds. When timestamps are uniformly
61 spaced, the timestamp of the first sample can be specified and all
62 subsequent ones calculated from the sampling rate attribute.
63 dtype: float64
64 name: starting_time
65 quantity: '?'
66- attributes:
67 - doc: Value is '1'
68 dtype: int32
69 name: interval
70 value: 1
71 - doc: Unit of measurement for timestamps, which is fixed to 'seconds'.
72 dtype: text
73 name: unit
74 value: seconds
75 dims:
76 - num_times
77 doc: Timestamps for samples stored in data, in seconds, relative to the common
78 experiment master-clock stored in NWBFile.timestamps_reference_time.
79 dtype: float64
80 name: timestamps
81 quantity: '?'
82 shape:
83 -
84- dims:
85 - num_times
86 doc: Numerical labels that apply to each time point in data for the purpose of
87 querying and slicing data by these values. If present, the length of this
88 array should be the same size as the first dimension of data.
89 dtype: uint8
90 name: control
91 quantity: '?'
92 shape:
93 -
94- dims:
95 - num_control_values
96 doc: Description of each control value. Must be present if control is present.
97 If present, control_description[0] should describe time points where control
98 == 0.
99 dtype: text
100 name: control_description
101 quantity: '?'
102 shape:
103 -
104doc: Stores indices to image frames stored in an ImageSeries. The purpose of the
105 IndexSeries is to allow a static image stack to be stored in an Images object,
106 and the images in the stack to be referenced out-of-order. This can be for the
107 display of individual images, or of movie segments (as a movie is simply a
108 series of images). The data field stores the index of the frame in the
109 referenced Images object, and the timestamps array indicates when that image
110 was displayed.
111groups:
112- doc: Lab-specific time and sync information as provided directly from hardware
113 devices and that is necessary for aligning all acquired time information to
114 a common timebase. The timestamp array stores time in the common timebase.
115 This group will usually only be populated in TimeSeries that are stored
116 external to the NWB file, in files storing raw data. Once timestamp data is
117 calculated, the contents of 'sync' are mostly for archival purposes.
118 name: sync
119 quantity: '?'
120links:
121- doc: Link to ImageSeries object containing images that are indexed. Use of
122 this link is discouraged and will be deprecated. Link to an Images type
123 instead.
124 name: indexed_timeseries
125 quantity: '?'
126 target_type: ImageSeries
127- doc: Link to Images object containing an ordered set of images that are
128 indexed. The Images object must contain a 'ordered_images' dataset
129 specifying the order of the images in the Images type.
130 name: indexed_images
131 quantity: '?'
132 target_type: Images
133neurodata_type_def: IndexSeries
134neurodata_type_inc: TimeSeries
3.6. NWB file
Main NWB file specification.
3.6.1. ScratchData
Extends: NWBData
Description: see Section 2.5.1
YAML Specification:
1attributes:
2- doc: Any notes the user has about the dataset being stored
3 dtype: text
4 name: notes
5doc: Any one-off datasets
6neurodata_type_def: ScratchData
7neurodata_type_inc: NWBData
3.6.2. NWBFile
Extends: NWBContainer
Description: see Section 2.5.2
YAML Specification:
1attributes:
2- doc: File version string. Use semantic versioning, e.g. 1.2.1. This will be
3 the name of the format with trailing major, minor and patch numbers.
4 dtype: text
5 name: nwb_version
6 value: 2.8.0
7datasets:
8- dims:
9 - num_modifications
10 doc: 'A record of the date the file was created and of subsequent modifications.
11 The date is stored in UTC with local timezone offset as ISO 8601 extended formatted
12 strings: 2018-09-28T14:43:54.123+02:00. Dates stored in UTC end in "Z" with no
13 timezone offset. Date accuracy is up to milliseconds. The file can be created
14 after the experiment was run, so this may differ from the experiment start time.
15 Each modification to the nwb file adds a new entry to the array.'
16 dtype: isodatetime
17 name: file_create_date
18 shape:
19 -
20- doc: A unique text identifier for the file. For example, concatenated lab
21 name, file creation date/time and experimentalist, or a hash of these and/or
22 other values. The goal is that the string should be unique to all other
23 files.
24 dtype: text
25 name: identifier
26- doc: A description of the experimental session and data in the file.
27 dtype: text
28 name: session_description
29- doc: 'Date and time of the experiment/session start. The date is stored in UTC with
30 local timezone offset as ISO 8601 extended formatted string: 2018-09-28T14:43:54.123+02:00.
31 Dates stored in UTC end in "Z" with no timezone offset. Date accuracy is up to
32 milliseconds.'
33 dtype: isodatetime
34 name: session_start_time
35- doc: 'Date and time corresponding to time zero of all timestamps. The date is stored
36 in UTC with local timezone offset as ISO 8601 extended formatted string: 2018-09-28T14:43:54.123+02:00.
37 Dates stored in UTC end in "Z" with no timezone offset. Date accuracy is up to
38 milliseconds. All times stored in the file use this time as reference (i.e., time
39 zero).'
40 dtype: isodatetime
41 name: timestamps_reference_time
42doc: An NWB file storing cellular-based neurophysiology data from a single
43 experimental session.
44groups:
45- doc: Data streams recorded from the system, including ephys, ophys, tracking,
46 etc. This group should be read-only after the experiment is completed and
47 timestamps are corrected to a common timebase. The data stored here may be
48 links to raw data stored in external NWB files. This will allow keeping
49 bulky raw data out of the file while preserving the option of keeping
50 some/all in the file. Acquired data includes tracking and experimental data
51 streams (i.e., everything measured from the system). If bulky data is stored
52 in the /acquisition group, the data can exist in a separate NWB file that is
53 linked to by the file being used for processing and analysis.
54 groups:
55 - doc: Acquired, raw data.
56 neurodata_type_inc: NWBDataInterface
57 quantity: '*'
58 - doc: Tabular data that is relevant to acquisition
59 neurodata_type_inc: DynamicTable
60 quantity: '*'
61 name: acquisition
62- doc: Lab-specific and custom scientific analysis of data. There is no defined
63 format for the content of this group - the format is up to the individual
64 user/lab. To facilitate sharing analysis data between labs, the contents
65 here should be stored in standard types (e.g., neurodata_types) and
66 appropriately documented. The file can store lab-specific and custom data
67 analysis without restriction on its form or schema, reducing data formatting
68 restrictions on end users. Such data should be placed in the analysis group.
69 The analysis data should be documented so that it could be shared with other
70 labs.
71 groups:
72 - doc: Custom analysis results.
73 neurodata_type_inc: NWBContainer
74 quantity: '*'
75 - doc: Tabular data that is relevant to data stored in analysis
76 neurodata_type_inc: DynamicTable
77 quantity: '*'
78 name: analysis
79- datasets:
80 - doc: Any one-off datasets
81 neurodata_type_inc: ScratchData
82 quantity: '*'
83 doc: A place to store one-off analysis results. Data placed here is not
84 intended for sharing. By placing data here, users acknowledge that there is
85 no guarantee that their data meets any standard.
86 groups:
87 - doc: Any one-off containers
88 neurodata_type_inc: NWBContainer
89 quantity: '*'
90 - doc: Any one-off tables
91 neurodata_type_inc: DynamicTable
92 quantity: '*'
93 name: scratch
94 quantity: '?'
95- doc: The home for ProcessingModules. These modules perform intermediate
96 analysis of data that is necessary to perform before scientific analysis.
97 Examples include spike clustering, extracting position from tracking data,
98 stitching together image slices. ProcessingModules can be large and express
99 many data sets from relatively complex analysis (e.g., spike detection and
100 clustering) or small, representing extraction of position information from
101 tracking video, or even binary lick/no-lick decisions. Common software tools
102 (e.g., klustakwik, MClust) are expected to read/write data here.
103 'Processing' refers to intermediate analysis of the acquired data to make it
104 more amenable to scientific analysis.
105 groups:
106 - doc: Intermediate analysis of acquired data.
107 neurodata_type_inc: ProcessingModule
108 quantity: '*'
109 name: processing
110- doc: Data pushed into the system (eg, video stimulus, sound, voltage, etc) and
111 secondary representations of that data (eg, measurements of something used
112 as a stimulus). This group should be made read-only after experiment
113 complete and timestamps are corrected to common timebase. Stores both
114 presented stimuli and stimulus templates, the latter in case the same
115 stimulus is presented multiple times, or is pulled from an external stimulus
116 library. Stimuli are here defined as any signal that is pushed into the
117 system as part of the experiment (eg, sound, video, voltage, etc). Many
118 different experiments can use the same stimuli, and stimuli can be re-used
119 during an experiment. The stimulus group is organized so that one version of
120 template stimuli can be stored and these be used multiple times. These
121 templates can exist in the present file or can be linked to a remote library
122 file.
123 groups:
124 - doc: Stimuli presented during the experiment.
125 groups:
126 - doc: TimeSeries objects containing data of presented stimuli.
127 neurodata_type_inc: TimeSeries
128 quantity: '*'
129 - doc: Generic NWB data interfaces, usually from an extension, containing
130 data of presented stimuli.
131 neurodata_type_inc: NWBDataInterface
132 quantity: '*'
133 - doc: DynamicTable objects containing data of presented stimuli.
134 neurodata_type_inc: DynamicTable
135 quantity: '*'
136 name: presentation
137 - doc: Template stimuli. Timestamps in templates are based on stimulus design
138 and are relative to the beginning of the stimulus. When templates are
139 used, the stimulus instances must convert presentation times to the
140 experiment`s time reference frame.
141 groups:
142 - doc: TimeSeries objects containing template data of presented stimuli.
143 neurodata_type_inc: TimeSeries
144 quantity: '*'
145 - doc: Images objects containing images of presented stimuli.
146 neurodata_type_inc: Images
147 quantity: '*'
148 name: templates
149 name: stimulus
150- datasets:
151 - doc: Notes about data collection and analysis.
152 dtype: text
153 name: data_collection
154 quantity: '?'
155 - doc: General description of the experiment.
156 dtype: text
157 name: experiment_description
158 quantity: '?'
159 - dims:
160 - num_experimenters
161 doc: Name of person(s) who performed the experiment. Can also specify roles
162 of different people involved.
163 dtype: text
164 name: experimenter
165 quantity: '?'
166 shape:
167 -
168 - doc: Institution(s) where experiment was performed.
169 dtype: text
170 name: institution
171 quantity: '?'
172 - dims:
173 - num_keywords
174 doc: Terms to search over.
175 dtype: text
176 name: keywords
177 quantity: '?'
178 shape:
179 -
180 - doc: Laboratory where experiment was performed.
181 dtype: text
182 name: lab
183 quantity: '?'
184 - doc: Notes about the experiment.
185 dtype: text
186 name: notes
187 quantity: '?'
188 - doc: Description of drugs used, including how and when they were
189 administered. Anesthesia(s), painkiller(s), etc., plus dosage,
190 concentration, etc.
191 dtype: text
192 name: pharmacology
193 quantity: '?'
194 - doc: Experimental protocol, if applicable. e.g., include IACUC protocol
195 number.
196 dtype: text
197 name: protocol
198 quantity: '?'
199 - dims:
200 - num_publications
201 doc: Publication information. PMID, DOI, URL, etc.
202 dtype: text
203 name: related_publications
204 quantity: '?'
205 shape:
206 -
207 - doc: Lab-specific ID for the session.
208 dtype: text
209 name: session_id
210 quantity: '?'
211 - doc: Description of slices, including information about preparation
212 thickness, orientation, temperature, and bath solution.
213 dtype: text
214 name: slices
215 quantity: '?'
216 - attributes:
217 - doc: Name of script file.
218 dtype: text
219 name: file_name
220 doc: Script file or link to public source code used to create this NWB file.
221 dtype: text
222 name: source_script
223 quantity: '?'
224 - dims:
225 - num_sources
226 - name, version
227 doc: Name and version of software package(s) used to generate data contained
228 in this NWB File. For each software package or library, include the name
229 of the software as the first value and the version as the second value.
230 dtype: text
231 name: was_generated_by
232 quantity: '?'
233 shape:
234 -
235 - 2
236 - doc: Notes about stimuli, such as how and where they were presented.
237 dtype: text
238 name: stimulus
239 quantity: '?'
240 - doc: Narrative description about surgery/surgeries, including date(s) and
241 who performed surgery.
242 dtype: text
243 name: surgery
244 quantity: '?'
245 - doc: Information about virus(es) used in experiments, including virus ID,
246 source, date made, injection location, volume, etc.
247 dtype: text
248 name: virus
249 quantity: '?'
250 doc: Experimental metadata, including protocol, notes and description of
251 hardware device(s). The metadata stored in this section should be used to
252 describe the experiment. Metadata necessary for interpreting the data is
253 stored with the data. General experimental metadata, including animal
254 strain, experimental protocols, experimenter, devices, etc, are stored under
255 'general'. Core metadata (e.g., that required to interpret data fields) is
256 stored with the data itself, and implicitly defined by the file
257 specification (e.g., time is in seconds). The strategy used here for storing
258 non-core metadata is to use free-form text fields, such as would appear in
259 sentences or paragraphs from a Methods section. Metadata fields are text to
260 enable them to be more general, for example to represent ranges instead of
261 numerical values. Machine-readable metadata is stored as attributes to these
262 free-form datasets. All entries in the below table are to be included when
263 data is present. Unused groups (e.g., intracellular_ephys in an
264 optophysiology experiment) should not be created unless there is data to
265 store within them.
266 groups:
267 - doc: Place-holder than can be extended so that lab-specific meta-data can be
268 placed in /general.
269 neurodata_type_inc: LabMetaData
270 quantity: '*'
271 - doc: Description of hardware devices used during experiment, e.g., monitors,
272 ADC boards, microscopes, etc.
273 groups:
274 - doc: Data acquisition devices.
275 neurodata_type_inc: Device
276 quantity: '*'
277 name: devices
278 quantity: '?'
279 - doc: Information about the animal or person from which the data was
280 measured.
281 name: subject
282 neurodata_type_inc: Subject
283 quantity: '?'
284 - doc: Metadata related to extracellular electrophysiology.
285 groups:
286 - doc: Physical group of electrodes.
287 neurodata_type_inc: ElectrodeGroup
288 quantity: '*'
289 - datasets:
290 - doc: x coordinate of the channel location in the brain (+x is
291 posterior).
292 dtype: float32
293 name: x
294 neurodata_type_inc: VectorData
295 quantity: '?'
296 - doc: y coordinate of the channel location in the brain (+y is inferior).
297 dtype: float32
298 name: y
299 neurodata_type_inc: VectorData
300 quantity: '?'
301 - doc: z coordinate of the channel location in the brain (+z is right).
302 dtype: float32
303 name: z
304 neurodata_type_inc: VectorData
305 quantity: '?'
306 - doc: Impedance of the channel, in ohms.
307 dtype: float32
308 name: imp
309 neurodata_type_inc: VectorData
310 quantity: '?'
311 - doc: Location of the electrode (channel). Specify the area, layer,
312 comments on estimation of area/layer, stereotaxic coordinates if in
313 vivo, etc. Use standard atlas names for anatomical regions when
314 possible.
315 dtype: text
316 name: location
317 neurodata_type_inc: VectorData
318 - doc: Description of hardware filtering, including the filter name and
319 frequency cutoffs.
320 dtype: text
321 name: filtering
322 neurodata_type_inc: VectorData
323 quantity: '?'
324 - doc: Reference to the ElectrodeGroup this electrode is a part of.
325 dtype:
326 reftype: object
327 target_type: ElectrodeGroup
328 name: group
329 neurodata_type_inc: VectorData
330 - doc: Name of the ElectrodeGroup this electrode is a part of.
331 dtype: text
332 name: group_name
333 neurodata_type_inc: VectorData
334 - doc: x coordinate in electrode group
335 dtype: float32
336 name: rel_x
337 neurodata_type_inc: VectorData
338 quantity: '?'
339 - doc: y coordinate in electrode group
340 dtype: float32
341 name: rel_y
342 neurodata_type_inc: VectorData
343 quantity: '?'
344 - doc: z coordinate in electrode group
345 dtype: float32
346 name: rel_z
347 neurodata_type_inc: VectorData
348 quantity: '?'
349 - doc: Description of the reference electrode and/or reference scheme used
350 for this electrode, e.g., "stainless steel skull screw" or "online
351 common average referencing".
352 dtype: text
353 name: reference
354 neurodata_type_inc: VectorData
355 quantity: '?'
356 doc: A table of all electrodes (i.e. channels) used for recording.
357 name: electrodes
358 neurodata_type_inc: DynamicTable
359 quantity: '?'
360 name: extracellular_ephys
361 quantity: '?'
362 - datasets:
363 - doc: '[DEPRECATED] Use IntracellularElectrode.filtering instead. Description
364 of filtering used. Includes filtering type and parameters, frequency fall-off,
365 etc. If this changes between TimeSeries, filter description should be stored
366 as a text attribute for each TimeSeries.'
367 dtype: text
368 name: filtering
369 quantity: '?'
370 doc: Metadata related to intracellular electrophysiology.
371 groups:
372 - doc: An intracellular electrode.
373 neurodata_type_inc: IntracellularElectrode
374 quantity: '*'
375 - doc: '[DEPRECATED] Table used to group different PatchClampSeries. SweepTable
376 is being replaced by IntracellularRecordingsTable and SimultaneousRecordingsTable
377 tables. Additional SequentialRecordingsTable, RepetitionsTable and ExperimentalConditions
378 tables provide enhanced support for experiment metadata.'
379 name: sweep_table
380 neurodata_type_inc: SweepTable
381 quantity: '?'
382 - doc: A table to group together a stimulus and response from a single
383 electrode and a single simultaneous recording. Each row in the table
384 represents a single recording consisting typically of a stimulus and a
385 corresponding response. In some cases, however, only a stimulus or a
386 response are recorded as as part of an experiment. In this case both,
387 the stimulus and response will point to the same TimeSeries while the
388 idx_start and count of the invalid column will be set to -1, thus,
389 indicating that no values have been recorded for the stimulus or
390 response, respectively. Note, a recording MUST contain at least a
391 stimulus or a response. Typically the stimulus and response are
392 PatchClampSeries. However, the use of AD/DA channels that are not
393 associated to an electrode is also common in intracellular
394 electrophysiology, in which case other TimeSeries may be used.
395 name: intracellular_recordings
396 neurodata_type_inc: IntracellularRecordingsTable
397 quantity: '?'
398 - doc: A table for grouping different intracellular recordings from the
399 IntracellularRecordingsTable table together that were recorded
400 simultaneously from different electrodes
401 name: simultaneous_recordings
402 neurodata_type_inc: SimultaneousRecordingsTable
403 quantity: '?'
404 - doc: A table for grouping different sequential recordings from the
405 SimultaneousRecordingsTable table together. This is typically used to
406 group together sequential recordings where the a sequence of stimuli of
407 the same type with varying parameters have been presented in a sequence.
408 name: sequential_recordings
409 neurodata_type_inc: SequentialRecordingsTable
410 quantity: '?'
411 - doc: A table for grouping different sequential intracellular recordings
412 together. With each SequentialRecording typically representing a
413 particular type of stimulus, the RepetitionsTable table is typically
414 used to group sets of stimuli applied in sequence.
415 name: repetitions
416 neurodata_type_inc: RepetitionsTable
417 quantity: '?'
418 - doc: A table for grouping different intracellular recording repetitions
419 together that belong to the same experimental experimental_conditions.
420 name: experimental_conditions
421 neurodata_type_inc: ExperimentalConditionsTable
422 quantity: '?'
423 name: intracellular_ephys
424 quantity: '?'
425 - doc: Metadata describing optogenetic stimuluation.
426 groups:
427 - doc: An optogenetic stimulation site.
428 neurodata_type_inc: OptogeneticStimulusSite
429 quantity: '*'
430 name: optogenetics
431 quantity: '?'
432 - doc: Metadata related to optophysiology.
433 groups:
434 - doc: An imaging plane.
435 neurodata_type_inc: ImagingPlane
436 quantity: '*'
437 name: optophysiology
438 quantity: '?'
439 name: general
440- doc: Experimental intervals, whether that be logically distinct
441 sub-experiments having a particular scientific goal, trials (see trials
442 subgroup) during an experiment, or epochs (see epochs subgroup) deriving
443 from analysis of data.
444 groups:
445 - doc: Divisions in time marking experimental stages or sub-divisions of a
446 single recording session.
447 name: epochs
448 neurodata_type_inc: TimeIntervals
449 quantity: '?'
450 - doc: Repeated experimental events that have a logical grouping.
451 name: trials
452 neurodata_type_inc: TimeIntervals
453 quantity: '?'
454 - doc: Time intervals that should be removed from analysis.
455 name: invalid_times
456 neurodata_type_inc: TimeIntervals
457 quantity: '?'
458 - doc: Optional additional table(s) for describing other experimental time
459 intervals.
460 neurodata_type_inc: TimeIntervals
461 quantity: '*'
462 name: intervals
463 quantity: '?'
464- doc: Data about sorted spike units.
465 name: units
466 neurodata_type_inc: Units
467 quantity: '?'
468name: root
469neurodata_type_def: NWBFile
470neurodata_type_inc: NWBContainer
3.6.3. LabMetaData
Extends: NWBContainer
Description: see Section 2.5.3
YAML Specification:
1doc: Lab-specific meta-data.
2neurodata_type_def: LabMetaData
3neurodata_type_inc: NWBContainer
3.6.4. Subject
Extends: NWBContainer
Description: see Section 2.5.4
YAML Specification:
1datasets:
2- attributes:
3 - default_value: birth
4 doc: Age is with reference to this event. Can be 'birth' or 'gestational'.
5 If reference is omitted, 'birth' is implied.
6 dtype: text
7 name: reference
8 required: false
9 doc: Age of subject. Can be supplied instead of 'date_of_birth'.
10 dtype: text
11 name: age
12 quantity: '?'
13- doc: Date of birth of subject. Can be supplied instead of 'age'.
14 dtype: isodatetime
15 name: date_of_birth
16 quantity: '?'
17- doc: Description of subject and where subject came from (e.g., breeder, if
18 animal).
19 dtype: text
20 name: description
21 quantity: '?'
22- doc: Genetic strain. If absent, assume Wild Type (WT).
23 dtype: text
24 name: genotype
25 quantity: '?'
26- doc: Gender of subject.
27 dtype: text
28 name: sex
29 quantity: '?'
30- doc: Species of subject.
31 dtype: text
32 name: species
33 quantity: '?'
34- doc: Strain of subject.
35 dtype: text
36 name: strain
37 quantity: '?'
38- doc: ID of animal/person used/participating in experiment (lab convention).
39 dtype: text
40 name: subject_id
41 quantity: '?'
42- doc: Weight at time of experiment, at time of surgery and at other important
43 times.
44 dtype: text
45 name: weight
46 quantity: '?'
47doc: Information about the animal or person from which the data was measured.
48neurodata_type_def: Subject
49neurodata_type_inc: NWBContainer
3.7. Miscellaneous neurodata_types.
Miscellaneous types.
3.7.1. AbstractFeatureSeries
Extends: TimeSeries
Description: see Section 2.6.1
YAML Specification:
1attributes:
2- default_value: no description
3 doc: Description of the time series.
4 dtype: text
5 name: description
6 required: false
7- default_value: no comments
8 doc: Human-readable comments about the TimeSeries. This second descriptive
9 field can be used to store additional information, or descriptive
10 information if the primary description field is populated with a
11 computer-readable string.
12 dtype: text
13 name: comments
14 required: false
15datasets:
16- attributes:
17 - default_value: see 'feature_units'
18 doc: Since there can be different units for different features, store the
19 units in 'feature_units'. The default value for this attribute is "see
20 'feature_units'".
21 dtype: text
22 name: unit
23 required: false
24 - default_value: 1.0
25 doc: Scalar to multiply each element in data to convert it to the specified
26 'unit'. If the data are stored in acquisition system units or other units
27 that require a conversion to be interpretable, multiply the data by
28 'conversion' to convert the data to the specified 'unit'. e.g. if the data
29 acquisition system stores values in this object as signed 16-bit integers
30 (int16 range -32,768 to 32,767) that correspond to a 5V range (-2.5V to
31 2.5V), and the data acquisition system gain is 8000X, then the
32 'conversion' multiplier to get from raw data acquisition values to
33 recorded volts is 2.5/32768/8000 = 9.5367e-9.
34 dtype: float32
35 name: conversion
36 required: false
37 - default_value: 0.0
38 doc: Scalar to add to the data after scaling by 'conversion' to finalize its
39 coercion to the specified 'unit'. Two common examples of this include (a)
40 data stored in an unsigned type that requires a shift after scaling to
41 re-center the data, and (b) specialized recording devices that naturally
42 cause a scalar offset with respect to the true units.
43 dtype: float32
44 name: offset
45 required: false
46 - default_value: -1.0
47 doc: Smallest meaningful difference between values in data, stored in the
48 specified by unit, e.g., the change in value of the least significant bit,
49 or a larger number if signal noise is known to be present. If unknown, use
50 -1.0.
51 dtype: float32
52 name: resolution
53 required: false
54 - doc: Optionally describe the continuity of the data. Can be "continuous",
55 "instantaneous", or "step". For example, a voltage trace would be
56 "continuous", because samples are recorded from a continuous process. An
57 array of lick times would be "instantaneous", because the data represents
58 distinct moments in time. Times of image presentations would be "step"
59 because the picture remains the same until the next timepoint. This field
60 is optional, but is useful in providing information about the underlying
61 data. It may inform the way this data is interpreted, the way it is
62 visualized, and what analysis methods are applicable.
63 dtype: text
64 name: continuity
65 required: false
66 dims:
67 - - num_times
68 - - num_times
69 - num_features
70 doc: Values of each feature at each time.
71 dtype: numeric
72 name: data
73 shape:
74 - -
75 - -
76 -
77- dims:
78 - num_features
79 doc: Units of each feature.
80 dtype: text
81 name: feature_units
82 quantity: '?'
83 shape:
84 -
85- dims:
86 - num_features
87 doc: Description of the features represented in TimeSeries::data.
88 dtype: text
89 name: features
90 shape:
91 -
92- attributes:
93 - doc: Sampling rate, in Hz.
94 dtype: float32
95 name: rate
96 - doc: Unit of measurement for time, which is fixed to 'seconds'.
97 dtype: text
98 name: unit
99 value: seconds
100 doc: Timestamp of the first sample in seconds. When timestamps are uniformly
101 spaced, the timestamp of the first sample can be specified and all
102 subsequent ones calculated from the sampling rate attribute.
103 dtype: float64
104 name: starting_time
105 quantity: '?'
106- attributes:
107 - doc: Value is '1'
108 dtype: int32
109 name: interval
110 value: 1
111 - doc: Unit of measurement for timestamps, which is fixed to 'seconds'.
112 dtype: text
113 name: unit
114 value: seconds
115 dims:
116 - num_times
117 doc: Timestamps for samples stored in data, in seconds, relative to the common
118 experiment master-clock stored in NWBFile.timestamps_reference_time.
119 dtype: float64
120 name: timestamps
121 quantity: '?'
122 shape:
123 -
124- dims:
125 - num_times
126 doc: Numerical labels that apply to each time point in data for the purpose of
127 querying and slicing data by these values. If present, the length of this
128 array should be the same size as the first dimension of data.
129 dtype: uint8
130 name: control
131 quantity: '?'
132 shape:
133 -
134- dims:
135 - num_control_values
136 doc: Description of each control value. Must be present if control is present.
137 If present, control_description[0] should describe time points where control
138 == 0.
139 dtype: text
140 name: control_description
141 quantity: '?'
142 shape:
143 -
144doc: Abstract features, such as quantitative descriptions of sensory stimuli.
145 The TimeSeries::data field is a 2D array, storing those features (e.g., for
146 visual grating stimulus this might be orientation, spatial frequency and
147 contrast). Null stimuli (eg, uniform gray) can be marked as being an
148 independent feature (eg, 1.0 for gray, 0.0 for actual stimulus) or by storing
149 NaNs for feature values, or through use of the TimeSeries::control fields. A
150 set of features is considered to persist until the next set of features is
151 defined. The final set of features stored should be the null set. This is
152 useful when storing the raw stimulus is impractical.
153groups:
154- doc: Lab-specific time and sync information as provided directly from hardware
155 devices and that is necessary for aligning all acquired time information to
156 a common timebase. The timestamp array stores time in the common timebase.
157 This group will usually only be populated in TimeSeries that are stored
158 external to the NWB file, in files storing raw data. Once timestamp data is
159 calculated, the contents of 'sync' are mostly for archival purposes.
160 name: sync
161 quantity: '?'
162neurodata_type_def: AbstractFeatureSeries
163neurodata_type_inc: TimeSeries
3.7.2. AnnotationSeries
Extends: TimeSeries
Description: see Section 2.6.2
YAML Specification:
1attributes:
2- default_value: no description
3 doc: Description of the time series.
4 dtype: text
5 name: description
6 required: false
7- default_value: no comments
8 doc: Human-readable comments about the TimeSeries. This second descriptive
9 field can be used to store additional information, or descriptive
10 information if the primary description field is populated with a
11 computer-readable string.
12 dtype: text
13 name: comments
14 required: false
15datasets:
16- attributes:
17 - doc: Smallest meaningful difference between values in data. Annotations have
18 no units, so the value is fixed to -1.0.
19 dtype: float32
20 name: resolution
21 value: -1.0
22 - doc: Base unit of measurement for working with the data. Annotations have no
23 units, so the value is fixed to 'n/a'.
24 dtype: text
25 name: unit
26 value: n/a
27 - default_value: 1.0
28 doc: Scalar to multiply each element in data to convert it to the specified
29 'unit'. If the data are stored in acquisition system units or other units
30 that require a conversion to be interpretable, multiply the data by
31 'conversion' to convert the data to the specified 'unit'. e.g. if the data
32 acquisition system stores values in this object as signed 16-bit integers
33 (int16 range -32,768 to 32,767) that correspond to a 5V range (-2.5V to
34 2.5V), and the data acquisition system gain is 8000X, then the
35 'conversion' multiplier to get from raw data acquisition values to
36 recorded volts is 2.5/32768/8000 = 9.5367e-9.
37 dtype: float32
38 name: conversion
39 required: false
40 - default_value: 0.0
41 doc: Scalar to add to the data after scaling by 'conversion' to finalize its
42 coercion to the specified 'unit'. Two common examples of this include (a)
43 data stored in an unsigned type that requires a shift after scaling to
44 re-center the data, and (b) specialized recording devices that naturally
45 cause a scalar offset with respect to the true units.
46 dtype: float32
47 name: offset
48 required: false
49 - doc: Optionally describe the continuity of the data. Can be "continuous",
50 "instantaneous", or "step". For example, a voltage trace would be
51 "continuous", because samples are recorded from a continuous process. An
52 array of lick times would be "instantaneous", because the data represents
53 distinct moments in time. Times of image presentations would be "step"
54 because the picture remains the same until the next timepoint. This field
55 is optional, but is useful in providing information about the underlying
56 data. It may inform the way this data is interpreted, the way it is
57 visualized, and what analysis methods are applicable.
58 dtype: text
59 name: continuity
60 required: false
61 dims:
62 - num_times
63 doc: Annotations made during an experiment.
64 dtype: text
65 name: data
66 shape:
67 -
68- attributes:
69 - doc: Sampling rate, in Hz.
70 dtype: float32
71 name: rate
72 - doc: Unit of measurement for time, which is fixed to 'seconds'.
73 dtype: text
74 name: unit
75 value: seconds
76 doc: Timestamp of the first sample in seconds. When timestamps are uniformly
77 spaced, the timestamp of the first sample can be specified and all
78 subsequent ones calculated from the sampling rate attribute.
79 dtype: float64
80 name: starting_time
81 quantity: '?'
82- attributes:
83 - doc: Value is '1'
84 dtype: int32
85 name: interval
86 value: 1
87 - doc: Unit of measurement for timestamps, which is fixed to 'seconds'.
88 dtype: text
89 name: unit
90 value: seconds
91 dims:
92 - num_times
93 doc: Timestamps for samples stored in data, in seconds, relative to the common
94 experiment master-clock stored in NWBFile.timestamps_reference_time.
95 dtype: float64
96 name: timestamps
97 quantity: '?'
98 shape:
99 -
100- dims:
101 - num_times
102 doc: Numerical labels that apply to each time point in data for the purpose of
103 querying and slicing data by these values. If present, the length of this
104 array should be the same size as the first dimension of data.
105 dtype: uint8
106 name: control
107 quantity: '?'
108 shape:
109 -
110- dims:
111 - num_control_values
112 doc: Description of each control value. Must be present if control is present.
113 If present, control_description[0] should describe time points where control
114 == 0.
115 dtype: text
116 name: control_description
117 quantity: '?'
118 shape:
119 -
120doc: Stores user annotations made during an experiment. The data[] field stores
121 a text array, and timestamps are stored for each annotation (ie, interval=1).
122 This is largely an alias to a standard TimeSeries storing a text array but
123 that is identifiable as storing annotations in a machine-readable way.
124groups:
125- doc: Lab-specific time and sync information as provided directly from hardware
126 devices and that is necessary for aligning all acquired time information to
127 a common timebase. The timestamp array stores time in the common timebase.
128 This group will usually only be populated in TimeSeries that are stored
129 external to the NWB file, in files storing raw data. Once timestamp data is
130 calculated, the contents of 'sync' are mostly for archival purposes.
131 name: sync
132 quantity: '?'
133neurodata_type_def: AnnotationSeries
134neurodata_type_inc: TimeSeries
3.7.3. IntervalSeries
Extends: TimeSeries
Description: see Section 2.6.3
YAML Specification:
1attributes:
2- default_value: no description
3 doc: Description of the time series.
4 dtype: text
5 name: description
6 required: false
7- default_value: no comments
8 doc: Human-readable comments about the TimeSeries. This second descriptive
9 field can be used to store additional information, or descriptive
10 information if the primary description field is populated with a
11 computer-readable string.
12 dtype: text
13 name: comments
14 required: false
15datasets:
16- attributes:
17 - doc: Smallest meaningful difference between values in data. Annotations have
18 no units, so the value is fixed to -1.0.
19 dtype: float32
20 name: resolution
21 value: -1.0
22 - doc: Base unit of measurement for working with the data. Annotations have no
23 units, so the value is fixed to 'n/a'.
24 dtype: text
25 name: unit
26 value: n/a
27 - default_value: 1.0
28 doc: Scalar to multiply each element in data to convert it to the specified
29 'unit'. If the data are stored in acquisition system units or other units
30 that require a conversion to be interpretable, multiply the data by
31 'conversion' to convert the data to the specified 'unit'. e.g. if the data
32 acquisition system stores values in this object as signed 16-bit integers
33 (int16 range -32,768 to 32,767) that correspond to a 5V range (-2.5V to
34 2.5V), and the data acquisition system gain is 8000X, then the
35 'conversion' multiplier to get from raw data acquisition values to
36 recorded volts is 2.5/32768/8000 = 9.5367e-9.
37 dtype: float32
38 name: conversion
39 required: false
40 - default_value: 0.0
41 doc: Scalar to add to the data after scaling by 'conversion' to finalize its
42 coercion to the specified 'unit'. Two common examples of this include (a)
43 data stored in an unsigned type that requires a shift after scaling to
44 re-center the data, and (b) specialized recording devices that naturally
45 cause a scalar offset with respect to the true units.
46 dtype: float32
47 name: offset
48 required: false
49 - doc: Optionally describe the continuity of the data. Can be "continuous",
50 "instantaneous", or "step". For example, a voltage trace would be
51 "continuous", because samples are recorded from a continuous process. An
52 array of lick times would be "instantaneous", because the data represents
53 distinct moments in time. Times of image presentations would be "step"
54 because the picture remains the same until the next timepoint. This field
55 is optional, but is useful in providing information about the underlying
56 data. It may inform the way this data is interpreted, the way it is
57 visualized, and what analysis methods are applicable.
58 dtype: text
59 name: continuity
60 required: false
61 dims:
62 - num_times
63 doc: Use values >0 if interval started, <0 if interval ended.
64 dtype: int8
65 name: data
66 shape:
67 -
68- attributes:
69 - doc: Sampling rate, in Hz.
70 dtype: float32
71 name: rate
72 - doc: Unit of measurement for time, which is fixed to 'seconds'.
73 dtype: text
74 name: unit
75 value: seconds
76 doc: Timestamp of the first sample in seconds. When timestamps are uniformly
77 spaced, the timestamp of the first sample can be specified and all
78 subsequent ones calculated from the sampling rate attribute.
79 dtype: float64
80 name: starting_time
81 quantity: '?'
82- attributes:
83 - doc: Value is '1'
84 dtype: int32
85 name: interval
86 value: 1
87 - doc: Unit of measurement for timestamps, which is fixed to 'seconds'.
88 dtype: text
89 name: unit
90 value: seconds
91 dims:
92 - num_times
93 doc: Timestamps for samples stored in data, in seconds, relative to the common
94 experiment master-clock stored in NWBFile.timestamps_reference_time.
95 dtype: float64
96 name: timestamps
97 quantity: '?'
98 shape:
99 -
100- dims:
101 - num_times
102 doc: Numerical labels that apply to each time point in data for the purpose of
103 querying and slicing data by these values. If present, the length of this
104 array should be the same size as the first dimension of data.
105 dtype: uint8
106 name: control
107 quantity: '?'
108 shape:
109 -
110- dims:
111 - num_control_values
112 doc: Description of each control value. Must be present if control is present.
113 If present, control_description[0] should describe time points where control
114 == 0.
115 dtype: text
116 name: control_description
117 quantity: '?'
118 shape:
119 -
120doc: Stores intervals of data. The timestamps field stores the beginning and end
121 of intervals. The data field stores whether the interval just started (>0
122 value) or ended (<0 value). Different interval types can be represented in the
123 same series by using multiple key values (eg, 1 for feature A, 2 for feature
124 B, 3 for feature C, etc). The field data stores an 8-bit integer. This is
125 largely an alias of a standard TimeSeries but that is identifiable as
126 representing time intervals in a machine-readable way.
127groups:
128- doc: Lab-specific time and sync information as provided directly from hardware
129 devices and that is necessary for aligning all acquired time information to
130 a common timebase. The timestamp array stores time in the common timebase.
131 This group will usually only be populated in TimeSeries that are stored
132 external to the NWB file, in files storing raw data. Once timestamp data is
133 calculated, the contents of 'sync' are mostly for archival purposes.
134 name: sync
135 quantity: '?'
136neurodata_type_def: IntervalSeries
137neurodata_type_inc: TimeSeries
3.7.4. DecompositionSeries
Extends: TimeSeries
Description: see Section 2.6.4
YAML Specification:
1attributes:
2- default_value: no description
3 doc: Description of the time series.
4 dtype: text
5 name: description
6 required: false
7- default_value: no comments
8 doc: Human-readable comments about the TimeSeries. This second descriptive
9 field can be used to store additional information, or descriptive
10 information if the primary description field is populated with a
11 computer-readable string.
12 dtype: text
13 name: comments
14 required: false
15datasets:
16- attributes:
17 - default_value: no unit
18 doc: Base unit of measurement for working with the data. Actual stored
19 values are not necessarily stored in these units. To access the data in
20 these units, multiply 'data' by 'conversion'.
21 dtype: text
22 name: unit
23 required: false
24 - default_value: 1.0
25 doc: Scalar to multiply each element in data to convert it to the specified
26 'unit'. If the data are stored in acquisition system units or other units
27 that require a conversion to be interpretable, multiply the data by
28 'conversion' to convert the data to the specified 'unit'. e.g. if the data
29 acquisition system stores values in this object as signed 16-bit integers
30 (int16 range -32,768 to 32,767) that correspond to a 5V range (-2.5V to
31 2.5V), and the data acquisition system gain is 8000X, then the
32 'conversion' multiplier to get from raw data acquisition values to
33 recorded volts is 2.5/32768/8000 = 9.5367e-9.
34 dtype: float32
35 name: conversion
36 required: false
37 - default_value: 0.0
38 doc: Scalar to add to the data after scaling by 'conversion' to finalize its
39 coercion to the specified 'unit'. Two common examples of this include (a)
40 data stored in an unsigned type that requires a shift after scaling to
41 re-center the data, and (b) specialized recording devices that naturally
42 cause a scalar offset with respect to the true units.
43 dtype: float32
44 name: offset
45 required: false
46 - default_value: -1.0
47 doc: Smallest meaningful difference between values in data, stored in the
48 specified by unit, e.g., the change in value of the least significant bit,
49 or a larger number if signal noise is known to be present. If unknown, use
50 -1.0.
51 dtype: float32
52 name: resolution
53 required: false
54 - doc: Optionally describe the continuity of the data. Can be "continuous",
55 "instantaneous", or "step". For example, a voltage trace would be
56 "continuous", because samples are recorded from a continuous process. An
57 array of lick times would be "instantaneous", because the data represents
58 distinct moments in time. Times of image presentations would be "step"
59 because the picture remains the same until the next timepoint. This field
60 is optional, but is useful in providing information about the underlying
61 data. It may inform the way this data is interpreted, the way it is
62 visualized, and what analysis methods are applicable.
63 dtype: text
64 name: continuity
65 required: false
66 dims:
67 - num_times
68 - num_channels
69 - num_bands
70 doc: Data decomposed into frequency bands.
71 dtype: numeric
72 name: data
73 shape:
74 -
75 -
76 -
77- doc: The metric used, e.g. phase, amplitude, power.
78 dtype: text
79 name: metric
80- doc: DynamicTableRegion pointer to the channels that this decomposition series
81 was generated from.
82 name: source_channels
83 neurodata_type_inc: DynamicTableRegion
84 quantity: '?'
85- attributes:
86 - doc: Sampling rate, in Hz.
87 dtype: float32
88 name: rate
89 - doc: Unit of measurement for time, which is fixed to 'seconds'.
90 dtype: text
91 name: unit
92 value: seconds
93 doc: Timestamp of the first sample in seconds. When timestamps are uniformly
94 spaced, the timestamp of the first sample can be specified and all
95 subsequent ones calculated from the sampling rate attribute.
96 dtype: float64
97 name: starting_time
98 quantity: '?'
99- attributes:
100 - doc: Value is '1'
101 dtype: int32
102 name: interval
103 value: 1
104 - doc: Unit of measurement for timestamps, which is fixed to 'seconds'.
105 dtype: text
106 name: unit
107 value: seconds
108 dims:
109 - num_times
110 doc: Timestamps for samples stored in data, in seconds, relative to the common
111 experiment master-clock stored in NWBFile.timestamps_reference_time.
112 dtype: float64
113 name: timestamps
114 quantity: '?'
115 shape:
116 -
117- dims:
118 - num_times
119 doc: Numerical labels that apply to each time point in data for the purpose of
120 querying and slicing data by these values. If present, the length of this
121 array should be the same size as the first dimension of data.
122 dtype: uint8
123 name: control
124 quantity: '?'
125 shape:
126 -
127- dims:
128 - num_control_values
129 doc: Description of each control value. Must be present if control is present.
130 If present, control_description[0] should describe time points where control
131 == 0.
132 dtype: text
133 name: control_description
134 quantity: '?'
135 shape:
136 -
137doc: Spectral analysis of a time series, e.g. of an LFP or a speech signal.
138groups:
139- datasets:
140 - doc: Name of the band, e.g. theta.
141 dtype: text
142 name: band_name
143 neurodata_type_inc: VectorData
144 - dims:
145 - num_bands
146 - low, high
147 doc: Low and high limit of each band in Hz. If it is a Gaussian filter, use
148 2 SD on either side of the center.
149 dtype: float32
150 name: band_limits
151 neurodata_type_inc: VectorData
152 shape:
153 -
154 - 2
155 - dims:
156 - num_bands
157 doc: The mean Gaussian filters, in Hz.
158 dtype: float32
159 name: band_mean
160 neurodata_type_inc: VectorData
161 quantity: '?'
162 shape:
163 -
164 - dims:
165 - num_bands
166 doc: The standard deviation of Gaussian filters, in Hz.
167 dtype: float32
168 name: band_stdev
169 neurodata_type_inc: VectorData
170 quantity: '?'
171 shape:
172 -
173 doc: Table for describing the bands that this series was generated from. There
174 should be one row in this table for each band.
175 name: bands
176 neurodata_type_inc: DynamicTable
177- doc: Lab-specific time and sync information as provided directly from hardware
178 devices and that is necessary for aligning all acquired time information to
179 a common timebase. The timestamp array stores time in the common timebase.
180 This group will usually only be populated in TimeSeries that are stored
181 external to the NWB file, in files storing raw data. Once timestamp data is
182 calculated, the contents of 'sync' are mostly for archival purposes.
183 name: sync
184 quantity: '?'
185links:
186- doc: Link to TimeSeries object that this data was calculated from. Metadata
187 about electrodes and their position can be read from that ElectricalSeries
188 so it is not necessary to store that information here.
189 name: source_timeseries
190 quantity: '?'
191 target_type: TimeSeries
192neurodata_type_def: DecompositionSeries
193neurodata_type_inc: TimeSeries
3.7.5. Units
Extends: DynamicTable
Description: see Section 2.6.5
YAML Specification:
1attributes:
2- dims:
3 - num_columns
4 doc: The names of the columns in this table. This should be used to specify an
5 order to the columns.
6 dtype: text
7 name: colnames
8 shape:
9 -
10- doc: Description of what is in this dynamic table.
11 dtype: text
12 name: description
13datasets:
14- doc: Index into the spike_times dataset.
15 name: spike_times_index
16 neurodata_type_inc: VectorIndex
17 quantity: '?'
18- attributes:
19 - doc: The smallest possible difference between two spike times. Usually 1
20 divided by the acquisition sampling rate from which spike times were
21 extracted, but could be larger if the acquisition time series was
22 downsampled or smaller if the acquisition time series was
23 smoothed/interpolated and it is possible for the spike time to be between
24 samples.
25 dtype: float64
26 name: resolution
27 required: false
28 doc: Spike times for each unit in seconds.
29 dtype: float64
30 name: spike_times
31 neurodata_type_inc: VectorData
32 quantity: '?'
33- doc: Index into the obs_intervals dataset.
34 name: obs_intervals_index
35 neurodata_type_inc: VectorIndex
36 quantity: '?'
37- dims:
38 - num_intervals
39 - start|end
40 doc: Observation intervals for each unit.
41 dtype: float64
42 name: obs_intervals
43 neurodata_type_inc: VectorData
44 quantity: '?'
45 shape:
46 -
47 - 2
48- doc: Index into electrodes.
49 name: electrodes_index
50 neurodata_type_inc: VectorIndex
51 quantity: '?'
52- doc: Electrode that each spike unit came from, specified using a
53 DynamicTableRegion.
54 name: electrodes
55 neurodata_type_inc: DynamicTableRegion
56 quantity: '?'
57- doc: Electrode group that each spike unit came from.
58 dtype:
59 reftype: object
60 target_type: ElectrodeGroup
61 name: electrode_group
62 neurodata_type_inc: VectorData
63 quantity: '?'
64- attributes:
65 - doc: Sampling rate, in hertz.
66 dtype: float32
67 name: sampling_rate
68 required: false
69 - doc: Unit of measurement. This value is fixed to 'volts'.
70 dtype: text
71 name: unit
72 value: volts
73 dims:
74 - - num_units
75 - num_samples
76 - - num_units
77 - num_samples
78 - num_electrodes
79 doc: Spike waveform mean for each spike unit.
80 dtype: float32
81 name: waveform_mean
82 neurodata_type_inc: VectorData
83 quantity: '?'
84 shape:
85 - -
86 -
87 - -
88 -
89 -
90- attributes:
91 - doc: Sampling rate, in hertz.
92 dtype: float32
93 name: sampling_rate
94 required: false
95 - doc: Unit of measurement. This value is fixed to 'volts'.
96 dtype: text
97 name: unit
98 value: volts
99 dims:
100 - - num_units
101 - num_samples
102 - - num_units
103 - num_samples
104 - num_electrodes
105 doc: Spike waveform standard deviation for each spike unit.
106 dtype: float32
107 name: waveform_sd
108 neurodata_type_inc: VectorData
109 quantity: '?'
110 shape:
111 - -
112 -
113 - -
114 -
115 -
116- attributes:
117 - doc: Sampling rate, in hertz.
118 dtype: float32
119 name: sampling_rate
120 required: false
121 - doc: Unit of measurement. This value is fixed to 'volts'.
122 dtype: text
123 name: unit
124 value: volts
125 dims:
126 - num_waveforms
127 - num_samples
128 doc: Individual waveforms for each spike on each electrode. This is a doubly
129 indexed column. The 'waveforms_index' column indexes which waveforms in this
130 column belong to the same spike event for a given unit, where each waveform
131 was recorded from a different electrode. The 'waveforms_index_index' column
132 indexes the 'waveforms_index' column to indicate which spike events belong
133 to a given unit. For example, if the 'waveforms_index_index' column has
134 values [2, 5, 6], then the first 2 elements of the 'waveforms_index' column
135 correspond to the 2 spike events of the first unit, the next 3 elements of
136 the 'waveforms_index' column correspond to the 3 spike events of the second
137 unit, and the next 1 element of the 'waveforms_index' column corresponds to
138 the 1 spike event of the third unit. If the 'waveforms_index' column has
139 values [3, 6, 8, 10, 12, 13], then the first 3 elements of the 'waveforms'
140 column contain the 3 spike waveforms that were recorded from 3 different
141 electrodes for the first spike time of the first unit. See
142 https://nwb-schema.readthedocs.io/en/stable/format_description.html#doubly-ragged-arrays
143 for a graphical representation of this example. When there is only one
144 electrode for each unit (i.e., each spike time is associated with a single
145 waveform), then the 'waveforms_index' column will have values 1, 2, ..., N,
146 where N is the number of spike events. The number of electrodes for each
147 spike event should be the same within a given unit. The 'electrodes' column
148 should be used to indicate which electrodes are associated with each unit,
149 and the order of the waveforms within a given unit x spike event should be
150 the same as the order of the electrodes referenced in the 'electrodes'
151 column of this table. The number of samples for each waveform must be the
152 same.
153 dtype: numeric
154 name: waveforms
155 neurodata_type_inc: VectorData
156 quantity: '?'
157 shape:
158 -
159 -
160- doc: Index into the 'waveforms' dataset. One value for every spike event. See
161 'waveforms' for more detail.
162 name: waveforms_index
163 neurodata_type_inc: VectorIndex
164 quantity: '?'
165- doc: Index into the 'waveforms_index' dataset. One value for every unit (row
166 in the table). See 'waveforms' for more detail.
167 name: waveforms_index_index
168 neurodata_type_inc: VectorIndex
169 quantity: '?'
170- dims:
171 - num_rows
172 doc: Array of unique identifiers for the rows of this dynamic table.
173 dtype: int
174 name: id
175 neurodata_type_inc: ElementIdentifiers
176 shape:
177 -
178- doc: Vector columns, including index columns, of this dynamic table.
179 neurodata_type_inc: VectorData
180 quantity: '*'
181default_name: Units
182doc: Data about spiking units. Event times of observed units (e.g. cell,
183 synapse, etc.) should be concatenated and stored in spike_times.
184neurodata_type_def: Units
185neurodata_type_inc: DynamicTable
3.8. Behavior
This source module contains neurodata_types for behavior data.
3.8.1. SpatialSeries
Extends: TimeSeries
Description: see Section 2.7.1
YAML Specification:
1attributes:
2- default_value: no description
3 doc: Description of the time series.
4 dtype: text
5 name: description
6 required: false
7- default_value: no comments
8 doc: Human-readable comments about the TimeSeries. This second descriptive
9 field can be used to store additional information, or descriptive
10 information if the primary description field is populated with a
11 computer-readable string.
12 dtype: text
13 name: comments
14 required: false
15datasets:
16- attributes:
17 - default_value: meters
18 doc: Base unit of measurement for working with the data. The default value
19 is 'meters'. Actual stored values are not necessarily stored in these
20 units. To access the data in these units, multiply 'data' by 'conversion'
21 and add 'offset'.
22 dtype: text
23 name: unit
24 required: false
25 - default_value: 1.0
26 doc: Scalar to multiply each element in data to convert it to the specified
27 'unit'. If the data are stored in acquisition system units or other units
28 that require a conversion to be interpretable, multiply the data by
29 'conversion' to convert the data to the specified 'unit'. e.g. if the data
30 acquisition system stores values in this object as signed 16-bit integers
31 (int16 range -32,768 to 32,767) that correspond to a 5V range (-2.5V to
32 2.5V), and the data acquisition system gain is 8000X, then the
33 'conversion' multiplier to get from raw data acquisition values to
34 recorded volts is 2.5/32768/8000 = 9.5367e-9.
35 dtype: float32
36 name: conversion
37 required: false
38 - default_value: 0.0
39 doc: Scalar to add to the data after scaling by 'conversion' to finalize its
40 coercion to the specified 'unit'. Two common examples of this include (a)
41 data stored in an unsigned type that requires a shift after scaling to
42 re-center the data, and (b) specialized recording devices that naturally
43 cause a scalar offset with respect to the true units.
44 dtype: float32
45 name: offset
46 required: false
47 - default_value: -1.0
48 doc: Smallest meaningful difference between values in data, stored in the
49 specified by unit, e.g., the change in value of the least significant bit,
50 or a larger number if signal noise is known to be present. If unknown, use
51 -1.0.
52 dtype: float32
53 name: resolution
54 required: false
55 - doc: Optionally describe the continuity of the data. Can be "continuous",
56 "instantaneous", or "step". For example, a voltage trace would be
57 "continuous", because samples are recorded from a continuous process. An
58 array of lick times would be "instantaneous", because the data represents
59 distinct moments in time. Times of image presentations would be "step"
60 because the picture remains the same until the next timepoint. This field
61 is optional, but is useful in providing information about the underlying
62 data. It may inform the way this data is interpreted, the way it is
63 visualized, and what analysis methods are applicable.
64 dtype: text
65 name: continuity
66 required: false
67 dims:
68 - - num_times
69 - - num_times
70 - x
71 - - num_times
72 - x,y
73 - - num_times
74 - x,y,z
75 doc: 1-D or 2-D array storing position or direction relative to some reference
76 frame.
77 dtype: numeric
78 name: data
79 shape:
80 - -
81 - -
82 - 1
83 - -
84 - 2
85 - -
86 - 3
87- doc: Description defining what exactly 'straight-ahead' means.
88 dtype: text
89 name: reference_frame
90 quantity: '?'
91- attributes:
92 - doc: Sampling rate, in Hz.
93 dtype: float32
94 name: rate
95 - doc: Unit of measurement for time, which is fixed to 'seconds'.
96 dtype: text
97 name: unit
98 value: seconds
99 doc: Timestamp of the first sample in seconds. When timestamps are uniformly
100 spaced, the timestamp of the first sample can be specified and all
101 subsequent ones calculated from the sampling rate attribute.
102 dtype: float64
103 name: starting_time
104 quantity: '?'
105- attributes:
106 - doc: Value is '1'
107 dtype: int32
108 name: interval
109 value: 1
110 - doc: Unit of measurement for timestamps, which is fixed to 'seconds'.
111 dtype: text
112 name: unit
113 value: seconds
114 dims:
115 - num_times
116 doc: Timestamps for samples stored in data, in seconds, relative to the common
117 experiment master-clock stored in NWBFile.timestamps_reference_time.
118 dtype: float64
119 name: timestamps
120 quantity: '?'
121 shape:
122 -
123- dims:
124 - num_times
125 doc: Numerical labels that apply to each time point in data for the purpose of
126 querying and slicing data by these values. If present, the length of this
127 array should be the same size as the first dimension of data.
128 dtype: uint8
129 name: control
130 quantity: '?'
131 shape:
132 -
133- dims:
134 - num_control_values
135 doc: Description of each control value. Must be present if control is present.
136 If present, control_description[0] should describe time points where control
137 == 0.
138 dtype: text
139 name: control_description
140 quantity: '?'
141 shape:
142 -
143doc: "Direction, e.g., of gaze or travel, or position. The TimeSeries::data field
144 is a 2D array storing position or direction relative to some reference frame. Array
145 structure: [num measurements] [num dimensions]. Each SpatialSeries has a text dataset
146 reference_frame that indicates the zero-position, or the zero-axes for direction.
147 For example, if representing gaze direction, 'straight-ahead' might be a specific
148 pixel on the monitor, or some other point in space. For position data, the 0,0 point
149 might be the top-left corner of an enclosure, as viewed from the tracking camera.
150 The unit of data will indicate how to interpret SpatialSeries values."
151groups:
152- doc: Lab-specific time and sync information as provided directly from hardware
153 devices and that is necessary for aligning all acquired time information to
154 a common timebase. The timestamp array stores time in the common timebase.
155 This group will usually only be populated in TimeSeries that are stored
156 external to the NWB file, in files storing raw data. Once timestamp data is
157 calculated, the contents of 'sync' are mostly for archival purposes.
158 name: sync
159 quantity: '?'
160neurodata_type_def: SpatialSeries
161neurodata_type_inc: TimeSeries
3.8.2. BehavioralEpochs
Extends: NWBDataInterface
Description: see Section 2.7.2
YAML Specification:
1default_name: BehavioralEpochs
2doc: TimeSeries for storing behavioral epochs. The objective of this and the
3 other two Behavioral interfaces (e.g. BehavioralEvents and
4 BehavioralTimeSeries) is to provide generic hooks for software tools/scripts.
5 This allows a tool/script to take the output one specific interface (e.g.,
6 UnitTimes) and plot that data relative to another data modality (e.g.,
7 behavioral events) without having to define all possible modalities in
8 advance. Declaring one of these interfaces means that one or more TimeSeries
9 of the specified type is published. These TimeSeries should reside in a group
10 having the same name as the interface. For example, if a BehavioralTimeSeries
11 interface is declared, the module will have one or more TimeSeries defined in
12 the module sub-group 'BehavioralTimeSeries'. BehavioralEpochs should use
13 IntervalSeries. BehavioralEvents is used for irregular events.
14 BehavioralTimeSeries is for continuous data.
15groups:
16- doc: IntervalSeries object containing start and stop times of epochs.
17 neurodata_type_inc: IntervalSeries
18 quantity: '*'
19neurodata_type_def: BehavioralEpochs
20neurodata_type_inc: NWBDataInterface
3.8.3. BehavioralEvents
Extends: NWBDataInterface
Description: see Section 2.7.3
YAML Specification:
1default_name: BehavioralEvents
2doc: TimeSeries for storing behavioral events. See description of <a
3 href="#BehavioralEpochs">BehavioralEpochs</a> for more details.
4groups:
5- doc: TimeSeries object containing behavioral events.
6 neurodata_type_inc: TimeSeries
7 quantity: '*'
8neurodata_type_def: BehavioralEvents
9neurodata_type_inc: NWBDataInterface
3.8.4. BehavioralTimeSeries
Extends: NWBDataInterface
Description: see Section 2.7.4
YAML Specification:
1default_name: BehavioralTimeSeries
2doc: TimeSeries for storing Behavoioral time series data. See description of <a
3 href="#BehavioralEpochs">BehavioralEpochs</a> for more details.
4groups:
5- doc: TimeSeries object containing continuous behavioral data.
6 neurodata_type_inc: TimeSeries
7 quantity: '*'
8neurodata_type_def: BehavioralTimeSeries
9neurodata_type_inc: NWBDataInterface
3.8.5. PupilTracking
Extends: NWBDataInterface
Description: see Section 2.7.5
YAML Specification:
1default_name: PupilTracking
2doc: Eye-tracking data, representing pupil size.
3groups:
4- doc: TimeSeries object containing time series data on pupil size.
5 neurodata_type_inc: TimeSeries
6 quantity: +
7neurodata_type_def: PupilTracking
8neurodata_type_inc: NWBDataInterface
3.8.6. EyeTracking
Extends: NWBDataInterface
Description: see Section 2.7.6
YAML Specification:
1default_name: EyeTracking
2doc: Eye-tracking data, representing direction of gaze.
3groups:
4- doc: SpatialSeries object containing data measuring direction of gaze.
5 neurodata_type_inc: SpatialSeries
6 quantity: '*'
7neurodata_type_def: EyeTracking
8neurodata_type_inc: NWBDataInterface
3.8.7. CompassDirection
Extends: NWBDataInterface
Description: see Section 2.7.7
YAML Specification:
1default_name: CompassDirection
2doc: With a CompassDirection interface, a module publishes a SpatialSeries
3 object representing a floating point value for theta. The
4 SpatialSeries::reference_frame field should indicate what direction
5 corresponds to 0 and which is the direction of rotation (this should be
6 clockwise). The si_unit for the SpatialSeries should be radians or degrees.
7groups:
8- doc: SpatialSeries object containing direction of gaze travel.
9 neurodata_type_inc: SpatialSeries
10 quantity: '*'
11neurodata_type_def: CompassDirection
12neurodata_type_inc: NWBDataInterface
3.8.8. Position
Extends: NWBDataInterface
Description: see Section 2.7.8
YAML Specification:
1default_name: Position
2doc: Position data, whether along the x, x/y or x/y/z axis.
3groups:
4- doc: SpatialSeries object containing position data.
5 neurodata_type_inc: SpatialSeries
6 quantity: +
7neurodata_type_def: Position
8neurodata_type_inc: NWBDataInterface
3.9. Extracellular electrophysiology
This source module contains neurodata_types for extracellular electrophysiology data.
3.9.1. ElectricalSeries
Extends: TimeSeries
Description: see Section 2.8.1
YAML Specification:
1attributes:
2- doc: Filtering applied to all channels of the data. For example, if this
3 ElectricalSeries represents high-pass-filtered data (also known as AP Band),
4 then this value could be "High-pass 4-pole Bessel filter at 500 Hz". If this
5 ElectricalSeries represents low-pass-filtered LFP data and the type of
6 filter is unknown, then this value could be "Low-pass filter at 300 Hz". If
7 a non-standard filter type is used, provide as much detail about the filter
8 properties as possible.
9 dtype: text
10 name: filtering
11 required: false
12- default_value: no description
13 doc: Description of the time series.
14 dtype: text
15 name: description
16 required: false
17- default_value: no comments
18 doc: Human-readable comments about the TimeSeries. This second descriptive
19 field can be used to store additional information, or descriptive
20 information if the primary description field is populated with a
21 computer-readable string.
22 dtype: text
23 name: comments
24 required: false
25datasets:
26- attributes:
27 - doc: Base unit of measurement for working with the data. This value is fixed
28 to 'volts'. Actual stored values are not necessarily stored in these
29 units. To access the data in these units, multiply 'data' by 'conversion',
30 followed by 'channel_conversion' (if present), and then add 'offset'.
31 dtype: text
32 name: unit
33 value: volts
34 - default_value: 1.0
35 doc: Scalar to multiply each element in data to convert it to the specified
36 'unit'. If the data are stored in acquisition system units or other units
37 that require a conversion to be interpretable, multiply the data by
38 'conversion' to convert the data to the specified 'unit'. e.g. if the data
39 acquisition system stores values in this object as signed 16-bit integers
40 (int16 range -32,768 to 32,767) that correspond to a 5V range (-2.5V to
41 2.5V), and the data acquisition system gain is 8000X, then the
42 'conversion' multiplier to get from raw data acquisition values to
43 recorded volts is 2.5/32768/8000 = 9.5367e-9.
44 dtype: float32
45 name: conversion
46 required: false
47 - default_value: 0.0
48 doc: Scalar to add to the data after scaling by 'conversion' to finalize its
49 coercion to the specified 'unit'. Two common examples of this include (a)
50 data stored in an unsigned type that requires a shift after scaling to
51 re-center the data, and (b) specialized recording devices that naturally
52 cause a scalar offset with respect to the true units.
53 dtype: float32
54 name: offset
55 required: false
56 - default_value: -1.0
57 doc: Smallest meaningful difference between values in data, stored in the
58 specified by unit, e.g., the change in value of the least significant bit,
59 or a larger number if signal noise is known to be present. If unknown, use
60 -1.0.
61 dtype: float32
62 name: resolution
63 required: false
64 - doc: Optionally describe the continuity of the data. Can be "continuous",
65 "instantaneous", or "step". For example, a voltage trace would be
66 "continuous", because samples are recorded from a continuous process. An
67 array of lick times would be "instantaneous", because the data represents
68 distinct moments in time. Times of image presentations would be "step"
69 because the picture remains the same until the next timepoint. This field
70 is optional, but is useful in providing information about the underlying
71 data. It may inform the way this data is interpreted, the way it is
72 visualized, and what analysis methods are applicable.
73 dtype: text
74 name: continuity
75 required: false
76 dims:
77 - - num_times
78 - - num_times
79 - num_channels
80 - - num_times
81 - num_channels
82 - num_samples
83 doc: Recorded voltage data.
84 dtype: numeric
85 name: data
86 shape:
87 - -
88 - -
89 -
90 - -
91 -
92 -
93- doc: DynamicTableRegion pointer to the electrodes that this time series was
94 generated from.
95 name: electrodes
96 neurodata_type_inc: DynamicTableRegion
97- attributes:
98 - doc: The zero-indexed axis of the 'data' dataset that the channel-specific
99 conversion factor corresponds to. This value is fixed to 1.
100 dtype: int32
101 name: axis
102 value: 1
103 dims:
104 - num_channels
105 doc: Channel-specific conversion factor. Multiply the data in the 'data'
106 dataset by these values along the channel axis (as indicated by axis
107 attribute) AND by the global conversion factor in the 'conversion' attribute
108 of 'data' to get the data values in Volts, i.e, data in Volts = data *
109 data.conversion * channel_conversion. This approach allows for both global
110 and per-channel data conversion factors needed to support the storage of
111 electrical recordings as native values generated by data acquisition
112 systems. If this dataset is not present, then there is no channel-specific
113 conversion factor, i.e. it is 1 for all channels.
114 dtype: float32
115 name: channel_conversion
116 quantity: '?'
117 shape:
118 -
119- attributes:
120 - doc: Sampling rate, in Hz.
121 dtype: float32
122 name: rate
123 - doc: Unit of measurement for time, which is fixed to 'seconds'.
124 dtype: text
125 name: unit
126 value: seconds
127 doc: Timestamp of the first sample in seconds. When timestamps are uniformly
128 spaced, the timestamp of the first sample can be specified and all
129 subsequent ones calculated from the sampling rate attribute.
130 dtype: float64
131 name: starting_time
132 quantity: '?'
133- attributes:
134 - doc: Value is '1'
135 dtype: int32
136 name: interval
137 value: 1
138 - doc: Unit of measurement for timestamps, which is fixed to 'seconds'.
139 dtype: text
140 name: unit
141 value: seconds
142 dims:
143 - num_times
144 doc: Timestamps for samples stored in data, in seconds, relative to the common
145 experiment master-clock stored in NWBFile.timestamps_reference_time.
146 dtype: float64
147 name: timestamps
148 quantity: '?'
149 shape:
150 -
151- dims:
152 - num_times
153 doc: Numerical labels that apply to each time point in data for the purpose of
154 querying and slicing data by these values. If present, the length of this
155 array should be the same size as the first dimension of data.
156 dtype: uint8
157 name: control
158 quantity: '?'
159 shape:
160 -
161- dims:
162 - num_control_values
163 doc: Description of each control value. Must be present if control is present.
164 If present, control_description[0] should describe time points where control
165 == 0.
166 dtype: text
167 name: control_description
168 quantity: '?'
169 shape:
170 -
171doc: A time series of acquired voltage data from extracellular recordings. The
172 data field is an int or float array storing data in volts. The first dimension
173 should always represent time. The second dimension, if present, should
174 represent channels.
175groups:
176- doc: Lab-specific time and sync information as provided directly from hardware
177 devices and that is necessary for aligning all acquired time information to
178 a common timebase. The timestamp array stores time in the common timebase.
179 This group will usually only be populated in TimeSeries that are stored
180 external to the NWB file, in files storing raw data. Once timestamp data is
181 calculated, the contents of 'sync' are mostly for archival purposes.
182 name: sync
183 quantity: '?'
184neurodata_type_def: ElectricalSeries
185neurodata_type_inc: TimeSeries
3.9.2. SpikeEventSeries
Extends: ElectricalSeries
Description: see Section 2.8.2
YAML Specification:
1attributes:
2- doc: Filtering applied to all channels of the data. For example, if this
3 ElectricalSeries represents high-pass-filtered data (also known as AP Band),
4 then this value could be "High-pass 4-pole Bessel filter at 500 Hz". If this
5 ElectricalSeries represents low-pass-filtered LFP data and the type of
6 filter is unknown, then this value could be "Low-pass filter at 300 Hz". If
7 a non-standard filter type is used, provide as much detail about the filter
8 properties as possible.
9 dtype: text
10 name: filtering
11 required: false
12- default_value: no description
13 doc: Description of the time series.
14 dtype: text
15 name: description
16 required: false
17- default_value: no comments
18 doc: Human-readable comments about the TimeSeries. This second descriptive
19 field can be used to store additional information, or descriptive
20 information if the primary description field is populated with a
21 computer-readable string.
22 dtype: text
23 name: comments
24 required: false
25datasets:
26- attributes:
27 - doc: Unit of measurement for waveforms, which is fixed to 'volts'.
28 dtype: text
29 name: unit
30 value: volts
31 - default_value: 1.0
32 doc: Scalar to multiply each element in data to convert it to the specified
33 'unit'. If the data are stored in acquisition system units or other units
34 that require a conversion to be interpretable, multiply the data by
35 'conversion' to convert the data to the specified 'unit'. e.g. if the data
36 acquisition system stores values in this object as signed 16-bit integers
37 (int16 range -32,768 to 32,767) that correspond to a 5V range (-2.5V to
38 2.5V), and the data acquisition system gain is 8000X, then the
39 'conversion' multiplier to get from raw data acquisition values to
40 recorded volts is 2.5/32768/8000 = 9.5367e-9.
41 dtype: float32
42 name: conversion
43 required: false
44 - default_value: 0.0
45 doc: Scalar to add to the data after scaling by 'conversion' to finalize its
46 coercion to the specified 'unit'. Two common examples of this include (a)
47 data stored in an unsigned type that requires a shift after scaling to
48 re-center the data, and (b) specialized recording devices that naturally
49 cause a scalar offset with respect to the true units.
50 dtype: float32
51 name: offset
52 required: false
53 - default_value: -1.0
54 doc: Smallest meaningful difference between values in data, stored in the
55 specified by unit, e.g., the change in value of the least significant bit,
56 or a larger number if signal noise is known to be present. If unknown, use
57 -1.0.
58 dtype: float32
59 name: resolution
60 required: false
61 - doc: Optionally describe the continuity of the data. Can be "continuous",
62 "instantaneous", or "step". For example, a voltage trace would be
63 "continuous", because samples are recorded from a continuous process. An
64 array of lick times would be "instantaneous", because the data represents
65 distinct moments in time. Times of image presentations would be "step"
66 because the picture remains the same until the next timepoint. This field
67 is optional, but is useful in providing information about the underlying
68 data. It may inform the way this data is interpreted, the way it is
69 visualized, and what analysis methods are applicable.
70 dtype: text
71 name: continuity
72 required: false
73 dims:
74 - - num_events
75 - num_samples
76 - - num_events
77 - num_channels
78 - num_samples
79 doc: Spike waveforms.
80 dtype: numeric
81 name: data
82 shape:
83 - -
84 -
85 - -
86 -
87 -
88- attributes:
89 - doc: Value is '1'
90 dtype: int32
91 name: interval
92 value: 1
93 - doc: Unit of measurement for timestamps, which is fixed to 'seconds'.
94 dtype: text
95 name: unit
96 value: seconds
97 dims:
98 - num_times
99 doc: Timestamps for samples stored in data, in seconds, relative to the common
100 experiment master-clock stored in NWBFile.timestamps_reference_time.
101 Timestamps are required for the events. Unlike for TimeSeries, timestamps
102 are required for SpikeEventSeries and are thus re-specified here.
103 dtype: float64
104 name: timestamps
105 shape:
106 -
107- doc: DynamicTableRegion pointer to the electrodes that this time series was
108 generated from.
109 name: electrodes
110 neurodata_type_inc: DynamicTableRegion
111- attributes:
112 - doc: The zero-indexed axis of the 'data' dataset that the channel-specific
113 conversion factor corresponds to. This value is fixed to 1.
114 dtype: int32
115 name: axis
116 value: 1
117 dims:
118 - num_channels
119 doc: Channel-specific conversion factor. Multiply the data in the 'data'
120 dataset by these values along the channel axis (as indicated by axis
121 attribute) AND by the global conversion factor in the 'conversion' attribute
122 of 'data' to get the data values in Volts, i.e, data in Volts = data *
123 data.conversion * channel_conversion. This approach allows for both global
124 and per-channel data conversion factors needed to support the storage of
125 electrical recordings as native values generated by data acquisition
126 systems. If this dataset is not present, then there is no channel-specific
127 conversion factor, i.e. it is 1 for all channels.
128 dtype: float32
129 name: channel_conversion
130 quantity: '?'
131 shape:
132 -
133- attributes:
134 - doc: Sampling rate, in Hz.
135 dtype: float32
136 name: rate
137 - doc: Unit of measurement for time, which is fixed to 'seconds'.
138 dtype: text
139 name: unit
140 value: seconds
141 doc: Timestamp of the first sample in seconds. When timestamps are uniformly
142 spaced, the timestamp of the first sample can be specified and all
143 subsequent ones calculated from the sampling rate attribute.
144 dtype: float64
145 name: starting_time
146 quantity: '?'
147- dims:
148 - num_times
149 doc: Numerical labels that apply to each time point in data for the purpose of
150 querying and slicing data by these values. If present, the length of this
151 array should be the same size as the first dimension of data.
152 dtype: uint8
153 name: control
154 quantity: '?'
155 shape:
156 -
157- dims:
158 - num_control_values
159 doc: Description of each control value. Must be present if control is present.
160 If present, control_description[0] should describe time points where control
161 == 0.
162 dtype: text
163 name: control_description
164 quantity: '?'
165 shape:
166 -
167doc: 'Stores snapshots/snippets of recorded spike events (i.e., threshold crossings).
168 This may also be raw data, as reported by ephys hardware. If so, the TimeSeries::description
169 field should describe how events were detected. All events span the same recording
170 channels and store snapshots of equal duration. TimeSeries::data array structure:
171 [num events] [num channels] [num samples] (or [num events] [num samples] for single
172 electrode).'
173groups:
174- doc: Lab-specific time and sync information as provided directly from hardware
175 devices and that is necessary for aligning all acquired time information to
176 a common timebase. The timestamp array stores time in the common timebase.
177 This group will usually only be populated in TimeSeries that are stored
178 external to the NWB file, in files storing raw data. Once timestamp data is
179 calculated, the contents of 'sync' are mostly for archival purposes.
180 name: sync
181 quantity: '?'
182neurodata_type_def: SpikeEventSeries
183neurodata_type_inc: ElectricalSeries
3.9.3. FeatureExtraction
Extends: NWBDataInterface
Description: see Section 2.8.3
YAML Specification:
1datasets:
2- dims:
3 - num_features
4 doc: Description of features (eg, ''PC1'') for each of the extracted features.
5 dtype: text
6 name: description
7 shape:
8 -
9- dims:
10 - num_events
11 - num_channels
12 - num_features
13 doc: Multi-dimensional array of features extracted from each event.
14 dtype: float32
15 name: features
16 shape:
17 -
18 -
19 -
20- dims:
21 - num_events
22 doc: Times of events that features correspond to (can be a link).
23 dtype: float64
24 name: times
25 shape:
26 -
27- doc: DynamicTableRegion pointer to the electrodes that this time series was
28 generated from.
29 name: electrodes
30 neurodata_type_inc: DynamicTableRegion
31default_name: FeatureExtraction
32doc: Features, such as PC1 and PC2, that are extracted from signals stored in a
33 SpikeEventSeries or other source.
34neurodata_type_def: FeatureExtraction
35neurodata_type_inc: NWBDataInterface
3.9.4. EventDetection
Extends: NWBDataInterface
Description: see Section 2.8.4
YAML Specification:
1datasets:
2- doc: Description of how events were detected, such as voltage threshold, or
3 dV/dT threshold, as well as relevant values.
4 dtype: text
5 name: detection_method
6- dims:
7 - num_events
8 doc: Indices (zero-based) into source ElectricalSeries::data array
9 corresponding to time of event. ''description'' should define what is meant
10 by time of event (e.g., .25 ms before action potential peak, zero-crossing
11 time, etc). The index points to each event from the raw data.
12 dtype: int32
13 name: source_idx
14 shape:
15 -
16- attributes:
17 - doc: Unit of measurement for event times, which is fixed to 'seconds'.
18 dtype: text
19 name: unit
20 value: seconds
21 dims:
22 - num_events
23 doc: Timestamps of events, in seconds.
24 dtype: float64
25 name: times
26 shape:
27 -
28default_name: EventDetection
29doc: Detected spike events from voltage trace(s).
30links:
31- doc: Link to the ElectricalSeries that this data was calculated from. Metadata
32 about electrodes and their position can be read from that ElectricalSeries
33 so it's not necessary to include that information here.
34 name: source_electricalseries
35 target_type: ElectricalSeries
36neurodata_type_def: EventDetection
37neurodata_type_inc: NWBDataInterface
3.9.5. EventWaveform
Extends: NWBDataInterface
Description: see Section 2.8.5
YAML Specification:
1default_name: EventWaveform
2doc: DEPRECATED. Represents either the waveforms of detected events, as
3 extracted from a raw data trace in /acquisition, or the event waveforms that
4 were stored during experiment acquisition.
5groups:
6- doc: SpikeEventSeries object(s) containing detected spike event waveforms.
7 neurodata_type_inc: SpikeEventSeries
8 quantity: '*'
9neurodata_type_def: EventWaveform
10neurodata_type_inc: NWBDataInterface
3.9.6. FilteredEphys
Extends: NWBDataInterface
Description: see Section 2.8.6
YAML Specification:
1default_name: FilteredEphys
2doc: Electrophysiology data from one or more channels that has been subjected to
3 filtering. Examples of filtered data include Theta and Gamma (LFP has its own
4 interface). FilteredEphys modules publish an ElectricalSeries for each
5 filtered channel or set of channels. The name of each ElectricalSeries is
6 arbitrary but should be informative. The source of the filtered data, whether
7 this is from analysis of another time series or as acquired by hardware,
8 should be noted in each's TimeSeries::description field. There is no assumed
9 1::1 correspondence between filtered ephys signals and electrodes, as a single
10 signal can apply to many nearby electrodes, and one electrode may have
11 different filtered (e.g., theta and/or gamma) signals represented. Filter
12 properties should be noted in the ElectricalSeries 'filtering' attribute.
13groups:
14- doc: ElectricalSeries object(s) containing filtered electrophysiology data.
15 neurodata_type_inc: ElectricalSeries
16 quantity: +
17neurodata_type_def: FilteredEphys
18neurodata_type_inc: NWBDataInterface
3.9.7. LFP
Extends: NWBDataInterface
Description: see Section 2.8.7
YAML Specification:
1default_name: LFP
2doc: LFP data from one or more channels. The electrode map in each published
3 ElectricalSeries will identify which channels are providing LFP data. Filter
4 properties should be noted in the ElectricalSeries 'filtering' attribute.
5groups:
6- doc: ElectricalSeries object(s) containing LFP data for one or more channels.
7 neurodata_type_inc: ElectricalSeries
8 quantity: +
9neurodata_type_def: LFP
10neurodata_type_inc: NWBDataInterface
3.9.8. ElectrodeGroup
Extends: NWBContainer
Description: see Section 2.8.8
YAML Specification:
1attributes:
2- doc: Description of this electrode group.
3 dtype: text
4 name: description
5- doc: Location of electrode group. Specify the area, layer, comments on
6 estimation of area/layer, etc. Use standard atlas names for anatomical
7 regions when possible.
8 dtype: text
9 name: location
10datasets:
11- doc: stereotaxic or common framework coordinates
12 dtype:
13 - doc: x coordinate
14 dtype: float32
15 name: x
16 - doc: y coordinate
17 dtype: float32
18 name: y
19 - doc: z coordinate
20 dtype: float32
21 name: z
22 name: position
23 quantity: '?'
24doc: A physical grouping of electrodes, e.g. a shank of an array.
25links:
26- doc: Link to the device that was used to record from this electrode group.
27 name: device
28 target_type: Device
29neurodata_type_def: ElectrodeGroup
30neurodata_type_inc: NWBContainer
3.9.9. ClusterWaveforms
Extends: NWBDataInterface
Description: see Section 2.8.9
YAML Specification:
1datasets:
2- doc: Filtering applied to data before generating mean/sd
3 dtype: text
4 name: waveform_filtering
5- dims:
6 - num_clusters
7 - num_samples
8 doc: The mean waveform for each cluster, using the same indices for each wave
9 as cluster numbers in the associated Clustering module (i.e, cluster 3 is in
10 array slot [3]). Waveforms corresponding to gaps in cluster sequence should
11 be empty (e.g., zero- filled)
12 dtype: float32
13 name: waveform_mean
14 shape:
15 -
16 -
17- dims:
18 - num_clusters
19 - num_samples
20 doc: Stdev of waveforms for each cluster, using the same indices as in mean
21 dtype: float32
22 name: waveform_sd
23 shape:
24 -
25 -
26default_name: ClusterWaveforms
27doc: DEPRECATED The mean waveform shape, including standard deviation, of the
28 different clusters. Ideally, the waveform analysis should be performed on data
29 that is only high-pass filtered. This is a separate module because it is
30 expected to require updating. For example, IMEC probes may require different
31 storage requirements to store/display mean waveforms, requiring a new
32 interface or an extension of this one.
33links:
34- doc: Link to Clustering interface that was the source of the clustered data
35 name: clustering_interface
36 target_type: Clustering
37neurodata_type_def: ClusterWaveforms
38neurodata_type_inc: NWBDataInterface
3.9.10. Clustering
Extends: NWBDataInterface
Description: see Section 2.8.10
YAML Specification:
1datasets:
2- doc: Description of clusters or clustering, (e.g. cluster 0 is noise, clusters
3 curated using Klusters, etc)
4 dtype: text
5 name: description
6- dims:
7 - num_events
8 doc: Cluster number of each event
9 dtype: int32
10 name: num
11 shape:
12 -
13- dims:
14 - num_clusters
15 doc: Maximum ratio of waveform peak to RMS on any channel in the cluster
16 (provides a basic clustering metric).
17 dtype: float32
18 name: peak_over_rms
19 shape:
20 -
21- dims:
22 - num_events
23 doc: Times of clustered events, in seconds. This may be a link to times field
24 in associated FeatureExtraction module.
25 dtype: float64
26 name: times
27 shape:
28 -
29default_name: Clustering
30doc: DEPRECATED Clustered spike data, whether from automatic clustering tools
31 (e.g., klustakwik) or as a result of manual sorting.
32neurodata_type_def: Clustering
33neurodata_type_inc: NWBDataInterface
3.10. Intracellular electrophysiology
This source module contains neurodata_types for intracellular electrophysiology data.
3.10.1. PatchClampSeries
Extends: TimeSeries
Description: see Section 2.9.1
YAML Specification:
1attributes:
2- doc: Protocol/stimulus name for this patch-clamp dataset.
3 dtype: text
4 name: stimulus_description
5- doc: Sweep number, allows to group different PatchClampSeries together.
6 dtype: uint32
7 name: sweep_number
8 required: false
9- default_value: no description
10 doc: Description of the time series.
11 dtype: text
12 name: description
13 required: false
14- default_value: no comments
15 doc: Human-readable comments about the TimeSeries. This second descriptive
16 field can be used to store additional information, or descriptive
17 information if the primary description field is populated with a
18 computer-readable string.
19 dtype: text
20 name: comments
21 required: false
22datasets:
23- attributes:
24 - doc: Base unit of measurement for working with the data. Actual stored
25 values are not necessarily stored in these units. To access the data in
26 these units, multiply 'data' by 'conversion' and add 'offset'.
27 dtype: text
28 name: unit
29 - default_value: 1.0
30 doc: Scalar to multiply each element in data to convert it to the specified
31 'unit'. If the data are stored in acquisition system units or other units
32 that require a conversion to be interpretable, multiply the data by
33 'conversion' to convert the data to the specified 'unit'. e.g. if the data
34 acquisition system stores values in this object as signed 16-bit integers
35 (int16 range -32,768 to 32,767) that correspond to a 5V range (-2.5V to
36 2.5V), and the data acquisition system gain is 8000X, then the
37 'conversion' multiplier to get from raw data acquisition values to
38 recorded volts is 2.5/32768/8000 = 9.5367e-9.
39 dtype: float32
40 name: conversion
41 required: false
42 - default_value: 0.0
43 doc: Scalar to add to the data after scaling by 'conversion' to finalize its
44 coercion to the specified 'unit'. Two common examples of this include (a)
45 data stored in an unsigned type that requires a shift after scaling to
46 re-center the data, and (b) specialized recording devices that naturally
47 cause a scalar offset with respect to the true units.
48 dtype: float32
49 name: offset
50 required: false
51 - default_value: -1.0
52 doc: Smallest meaningful difference between values in data, stored in the
53 specified by unit, e.g., the change in value of the least significant bit,
54 or a larger number if signal noise is known to be present. If unknown, use
55 -1.0.
56 dtype: float32
57 name: resolution
58 required: false
59 - doc: Optionally describe the continuity of the data. Can be "continuous",
60 "instantaneous", or "step". For example, a voltage trace would be
61 "continuous", because samples are recorded from a continuous process. An
62 array of lick times would be "instantaneous", because the data represents
63 distinct moments in time. Times of image presentations would be "step"
64 because the picture remains the same until the next timepoint. This field
65 is optional, but is useful in providing information about the underlying
66 data. It may inform the way this data is interpreted, the way it is
67 visualized, and what analysis methods are applicable.
68 dtype: text
69 name: continuity
70 required: false
71 dims:
72 - num_times
73 doc: Recorded voltage or current.
74 dtype: numeric
75 name: data
76 shape:
77 -
78- doc: Gain of the recording, in units Volt/Amp (v-clamp) or Volt/Volt
79 (c-clamp).
80 dtype: float32
81 name: gain
82 quantity: '?'
83- attributes:
84 - doc: Sampling rate, in Hz.
85 dtype: float32
86 name: rate
87 - doc: Unit of measurement for time, which is fixed to 'seconds'.
88 dtype: text
89 name: unit
90 value: seconds
91 doc: Timestamp of the first sample in seconds. When timestamps are uniformly
92 spaced, the timestamp of the first sample can be specified and all
93 subsequent ones calculated from the sampling rate attribute.
94 dtype: float64
95 name: starting_time
96 quantity: '?'
97- attributes:
98 - doc: Value is '1'
99 dtype: int32
100 name: interval
101 value: 1
102 - doc: Unit of measurement for timestamps, which is fixed to 'seconds'.
103 dtype: text
104 name: unit
105 value: seconds
106 dims:
107 - num_times
108 doc: Timestamps for samples stored in data, in seconds, relative to the common
109 experiment master-clock stored in NWBFile.timestamps_reference_time.
110 dtype: float64
111 name: timestamps
112 quantity: '?'
113 shape:
114 -
115- dims:
116 - num_times
117 doc: Numerical labels that apply to each time point in data for the purpose of
118 querying and slicing data by these values. If present, the length of this
119 array should be the same size as the first dimension of data.
120 dtype: uint8
121 name: control
122 quantity: '?'
123 shape:
124 -
125- dims:
126 - num_control_values
127 doc: Description of each control value. Must be present if control is present.
128 If present, control_description[0] should describe time points where control
129 == 0.
130 dtype: text
131 name: control_description
132 quantity: '?'
133 shape:
134 -
135doc: An abstract base class for patch-clamp data - stimulus or response, current
136 or voltage.
137groups:
138- doc: Lab-specific time and sync information as provided directly from hardware
139 devices and that is necessary for aligning all acquired time information to
140 a common timebase. The timestamp array stores time in the common timebase.
141 This group will usually only be populated in TimeSeries that are stored
142 external to the NWB file, in files storing raw data. Once timestamp data is
143 calculated, the contents of 'sync' are mostly for archival purposes.
144 name: sync
145 quantity: '?'
146links:
147- doc: Link to IntracellularElectrode object that describes the electrode that
148 was used to apply or record this data.
149 name: electrode
150 target_type: IntracellularElectrode
151neurodata_type_def: PatchClampSeries
152neurodata_type_inc: TimeSeries
3.10.2. CurrentClampSeries
Extends: PatchClampSeries
Description: see Section 2.9.2
YAML Specification:
1attributes:
2- doc: Protocol/stimulus name for this patch-clamp dataset.
3 dtype: text
4 name: stimulus_description
5- doc: Sweep number, allows to group different PatchClampSeries together.
6 dtype: uint32
7 name: sweep_number
8 required: false
9- default_value: no description
10 doc: Description of the time series.
11 dtype: text
12 name: description
13 required: false
14- default_value: no comments
15 doc: Human-readable comments about the TimeSeries. This second descriptive
16 field can be used to store additional information, or descriptive
17 information if the primary description field is populated with a
18 computer-readable string.
19 dtype: text
20 name: comments
21 required: false
22datasets:
23- attributes:
24 - doc: Base unit of measurement for working with the data. which is fixed to
25 'volts'. Actual stored values are not necessarily stored in these units.
26 To access the data in these units, multiply 'data' by 'conversion' and add
27 'offset'.
28 dtype: text
29 name: unit
30 value: volts
31 - default_value: 1.0
32 doc: Scalar to multiply each element in data to convert it to the specified
33 'unit'. If the data are stored in acquisition system units or other units
34 that require a conversion to be interpretable, multiply the data by
35 'conversion' to convert the data to the specified 'unit'. e.g. if the data
36 acquisition system stores values in this object as signed 16-bit integers
37 (int16 range -32,768 to 32,767) that correspond to a 5V range (-2.5V to
38 2.5V), and the data acquisition system gain is 8000X, then the
39 'conversion' multiplier to get from raw data acquisition values to
40 recorded volts is 2.5/32768/8000 = 9.5367e-9.
41 dtype: float32
42 name: conversion
43 required: false
44 - default_value: 0.0
45 doc: Scalar to add to the data after scaling by 'conversion' to finalize its
46 coercion to the specified 'unit'. Two common examples of this include (a)
47 data stored in an unsigned type that requires a shift after scaling to
48 re-center the data, and (b) specialized recording devices that naturally
49 cause a scalar offset with respect to the true units.
50 dtype: float32
51 name: offset
52 required: false
53 - default_value: -1.0
54 doc: Smallest meaningful difference between values in data, stored in the
55 specified by unit, e.g., the change in value of the least significant bit,
56 or a larger number if signal noise is known to be present. If unknown, use
57 -1.0.
58 dtype: float32
59 name: resolution
60 required: false
61 - doc: Optionally describe the continuity of the data. Can be "continuous",
62 "instantaneous", or "step". For example, a voltage trace would be
63 "continuous", because samples are recorded from a continuous process. An
64 array of lick times would be "instantaneous", because the data represents
65 distinct moments in time. Times of image presentations would be "step"
66 because the picture remains the same until the next timepoint. This field
67 is optional, but is useful in providing information about the underlying
68 data. It may inform the way this data is interpreted, the way it is
69 visualized, and what analysis methods are applicable.
70 dtype: text
71 name: continuity
72 required: false
73 doc: Recorded voltage.
74 name: data
75- doc: Bias current, in amps.
76 dtype: float32
77 name: bias_current
78 quantity: '?'
79- doc: Bridge balance, in ohms.
80 dtype: float32
81 name: bridge_balance
82 quantity: '?'
83- doc: Capacitance compensation, in farads.
84 dtype: float32
85 name: capacitance_compensation
86 quantity: '?'
87- doc: Gain of the recording, in units Volt/Amp (v-clamp) or Volt/Volt
88 (c-clamp).
89 dtype: float32
90 name: gain
91 quantity: '?'
92- attributes:
93 - doc: Sampling rate, in Hz.
94 dtype: float32
95 name: rate
96 - doc: Unit of measurement for time, which is fixed to 'seconds'.
97 dtype: text
98 name: unit
99 value: seconds
100 doc: Timestamp of the first sample in seconds. When timestamps are uniformly
101 spaced, the timestamp of the first sample can be specified and all
102 subsequent ones calculated from the sampling rate attribute.
103 dtype: float64
104 name: starting_time
105 quantity: '?'
106- attributes:
107 - doc: Value is '1'
108 dtype: int32
109 name: interval
110 value: 1
111 - doc: Unit of measurement for timestamps, which is fixed to 'seconds'.
112 dtype: text
113 name: unit
114 value: seconds
115 dims:
116 - num_times
117 doc: Timestamps for samples stored in data, in seconds, relative to the common
118 experiment master-clock stored in NWBFile.timestamps_reference_time.
119 dtype: float64
120 name: timestamps
121 quantity: '?'
122 shape:
123 -
124- dims:
125 - num_times
126 doc: Numerical labels that apply to each time point in data for the purpose of
127 querying and slicing data by these values. If present, the length of this
128 array should be the same size as the first dimension of data.
129 dtype: uint8
130 name: control
131 quantity: '?'
132 shape:
133 -
134- dims:
135 - num_control_values
136 doc: Description of each control value. Must be present if control is present.
137 If present, control_description[0] should describe time points where control
138 == 0.
139 dtype: text
140 name: control_description
141 quantity: '?'
142 shape:
143 -
144doc: Voltage data from an intracellular current-clamp recording. A corresponding
145 CurrentClampStimulusSeries (stored separately as a stimulus) is used to store
146 the current injected.
147groups:
148- doc: Lab-specific time and sync information as provided directly from hardware
149 devices and that is necessary for aligning all acquired time information to
150 a common timebase. The timestamp array stores time in the common timebase.
151 This group will usually only be populated in TimeSeries that are stored
152 external to the NWB file, in files storing raw data. Once timestamp data is
153 calculated, the contents of 'sync' are mostly for archival purposes.
154 name: sync
155 quantity: '?'
156links:
157- doc: Link to IntracellularElectrode object that describes the electrode that
158 was used to apply or record this data.
159 name: electrode
160 target_type: IntracellularElectrode
161neurodata_type_def: CurrentClampSeries
162neurodata_type_inc: PatchClampSeries
3.10.3. IZeroClampSeries
Extends: CurrentClampSeries
Description: see Section 2.9.3
YAML Specification:
1attributes:
2- doc: An IZeroClampSeries has no stimulus, so this attribute is automatically
3 set to "N/A"
4 dtype: text
5 name: stimulus_description
6 value: N/A
7- doc: Sweep number, allows to group different PatchClampSeries together.
8 dtype: uint32
9 name: sweep_number
10 required: false
11- default_value: no description
12 doc: Description of the time series.
13 dtype: text
14 name: description
15 required: false
16- default_value: no comments
17 doc: Human-readable comments about the TimeSeries. This second descriptive
18 field can be used to store additional information, or descriptive
19 information if the primary description field is populated with a
20 computer-readable string.
21 dtype: text
22 name: comments
23 required: false
24datasets:
25- doc: Bias current, in amps, fixed to 0.0.
26 dtype: float32
27 name: bias_current
28 value: 0.0
29- doc: Bridge balance, in ohms, fixed to 0.0.
30 dtype: float32
31 name: bridge_balance
32 value: 0.0
33- doc: Capacitance compensation, in farads, fixed to 0.0.
34 dtype: float32
35 name: capacitance_compensation
36 value: 0.0
37- attributes:
38 - doc: Base unit of measurement for working with the data. which is fixed to
39 'volts'. Actual stored values are not necessarily stored in these units.
40 To access the data in these units, multiply 'data' by 'conversion' and add
41 'offset'.
42 dtype: text
43 name: unit
44 value: volts
45 - default_value: 1.0
46 doc: Scalar to multiply each element in data to convert it to the specified
47 'unit'. If the data are stored in acquisition system units or other units
48 that require a conversion to be interpretable, multiply the data by
49 'conversion' to convert the data to the specified 'unit'. e.g. if the data
50 acquisition system stores values in this object as signed 16-bit integers
51 (int16 range -32,768 to 32,767) that correspond to a 5V range (-2.5V to
52 2.5V), and the data acquisition system gain is 8000X, then the
53 'conversion' multiplier to get from raw data acquisition values to
54 recorded volts is 2.5/32768/8000 = 9.5367e-9.
55 dtype: float32
56 name: conversion
57 required: false
58 - default_value: 0.0
59 doc: Scalar to add to the data after scaling by 'conversion' to finalize its
60 coercion to the specified 'unit'. Two common examples of this include (a)
61 data stored in an unsigned type that requires a shift after scaling to
62 re-center the data, and (b) specialized recording devices that naturally
63 cause a scalar offset with respect to the true units.
64 dtype: float32
65 name: offset
66 required: false
67 - default_value: -1.0
68 doc: Smallest meaningful difference between values in data, stored in the
69 specified by unit, e.g., the change in value of the least significant bit,
70 or a larger number if signal noise is known to be present. If unknown, use
71 -1.0.
72 dtype: float32
73 name: resolution
74 required: false
75 - doc: Optionally describe the continuity of the data. Can be "continuous",
76 "instantaneous", or "step". For example, a voltage trace would be
77 "continuous", because samples are recorded from a continuous process. An
78 array of lick times would be "instantaneous", because the data represents
79 distinct moments in time. Times of image presentations would be "step"
80 because the picture remains the same until the next timepoint. This field
81 is optional, but is useful in providing information about the underlying
82 data. It may inform the way this data is interpreted, the way it is
83 visualized, and what analysis methods are applicable.
84 dtype: text
85 name: continuity
86 required: false
87 doc: Recorded voltage.
88 name: data
89- doc: Gain of the recording, in units Volt/Amp (v-clamp) or Volt/Volt
90 (c-clamp).
91 dtype: float32
92 name: gain
93 quantity: '?'
94- attributes:
95 - doc: Sampling rate, in Hz.
96 dtype: float32
97 name: rate
98 - doc: Unit of measurement for time, which is fixed to 'seconds'.
99 dtype: text
100 name: unit
101 value: seconds
102 doc: Timestamp of the first sample in seconds. When timestamps are uniformly
103 spaced, the timestamp of the first sample can be specified and all
104 subsequent ones calculated from the sampling rate attribute.
105 dtype: float64
106 name: starting_time
107 quantity: '?'
108- attributes:
109 - doc: Value is '1'
110 dtype: int32
111 name: interval
112 value: 1
113 - doc: Unit of measurement for timestamps, which is fixed to 'seconds'.
114 dtype: text
115 name: unit
116 value: seconds
117 dims:
118 - num_times
119 doc: Timestamps for samples stored in data, in seconds, relative to the common
120 experiment master-clock stored in NWBFile.timestamps_reference_time.
121 dtype: float64
122 name: timestamps
123 quantity: '?'
124 shape:
125 -
126- dims:
127 - num_times
128 doc: Numerical labels that apply to each time point in data for the purpose of
129 querying and slicing data by these values. If present, the length of this
130 array should be the same size as the first dimension of data.
131 dtype: uint8
132 name: control
133 quantity: '?'
134 shape:
135 -
136- dims:
137 - num_control_values
138 doc: Description of each control value. Must be present if control is present.
139 If present, control_description[0] should describe time points where control
140 == 0.
141 dtype: text
142 name: control_description
143 quantity: '?'
144 shape:
145 -
146doc: Voltage data from an intracellular recording when all current and amplifier
147 settings are off (i.e., CurrentClampSeries fields will be zero). There is no
148 CurrentClampStimulusSeries associated with an IZero series because the
149 amplifier is disconnected and no stimulus can reach the cell.
150groups:
151- doc: Lab-specific time and sync information as provided directly from hardware
152 devices and that is necessary for aligning all acquired time information to
153 a common timebase. The timestamp array stores time in the common timebase.
154 This group will usually only be populated in TimeSeries that are stored
155 external to the NWB file, in files storing raw data. Once timestamp data is
156 calculated, the contents of 'sync' are mostly for archival purposes.
157 name: sync
158 quantity: '?'
159links:
160- doc: Link to IntracellularElectrode object that describes the electrode that
161 was used to apply or record this data.
162 name: electrode
163 target_type: IntracellularElectrode
164neurodata_type_def: IZeroClampSeries
165neurodata_type_inc: CurrentClampSeries
3.10.4. CurrentClampStimulusSeries
Extends: PatchClampSeries
Description: see Section 2.9.4
YAML Specification:
1attributes:
2- doc: Protocol/stimulus name for this patch-clamp dataset.
3 dtype: text
4 name: stimulus_description
5- doc: Sweep number, allows to group different PatchClampSeries together.
6 dtype: uint32
7 name: sweep_number
8 required: false
9- default_value: no description
10 doc: Description of the time series.
11 dtype: text
12 name: description
13 required: false
14- default_value: no comments
15 doc: Human-readable comments about the TimeSeries. This second descriptive
16 field can be used to store additional information, or descriptive
17 information if the primary description field is populated with a
18 computer-readable string.
19 dtype: text
20 name: comments
21 required: false
22datasets:
23- attributes:
24 - doc: Base unit of measurement for working with the data. which is fixed to
25 'amperes'. Actual stored values are not necessarily stored in these units.
26 To access the data in these units, multiply 'data' by 'conversion' and add
27 'offset'.
28 dtype: text
29 name: unit
30 value: amperes
31 - default_value: 1.0
32 doc: Scalar to multiply each element in data to convert it to the specified
33 'unit'. If the data are stored in acquisition system units or other units
34 that require a conversion to be interpretable, multiply the data by
35 'conversion' to convert the data to the specified 'unit'. e.g. if the data
36 acquisition system stores values in this object as signed 16-bit integers
37 (int16 range -32,768 to 32,767) that correspond to a 5V range (-2.5V to
38 2.5V), and the data acquisition system gain is 8000X, then the
39 'conversion' multiplier to get from raw data acquisition values to
40 recorded volts is 2.5/32768/8000 = 9.5367e-9.
41 dtype: float32
42 name: conversion
43 required: false
44 - default_value: 0.0
45 doc: Scalar to add to the data after scaling by 'conversion' to finalize its
46 coercion to the specified 'unit'. Two common examples of this include (a)
47 data stored in an unsigned type that requires a shift after scaling to
48 re-center the data, and (b) specialized recording devices that naturally
49 cause a scalar offset with respect to the true units.
50 dtype: float32
51 name: offset
52 required: false
53 - default_value: -1.0
54 doc: Smallest meaningful difference between values in data, stored in the
55 specified by unit, e.g., the change in value of the least significant bit,
56 or a larger number if signal noise is known to be present. If unknown, use
57 -1.0.
58 dtype: float32
59 name: resolution
60 required: false
61 - doc: Optionally describe the continuity of the data. Can be "continuous",
62 "instantaneous", or "step". For example, a voltage trace would be
63 "continuous", because samples are recorded from a continuous process. An
64 array of lick times would be "instantaneous", because the data represents
65 distinct moments in time. Times of image presentations would be "step"
66 because the picture remains the same until the next timepoint. This field
67 is optional, but is useful in providing information about the underlying
68 data. It may inform the way this data is interpreted, the way it is
69 visualized, and what analysis methods are applicable.
70 dtype: text
71 name: continuity
72 required: false
73 doc: Stimulus current applied.
74 name: data
75- doc: Gain of the recording, in units Volt/Amp (v-clamp) or Volt/Volt
76 (c-clamp).
77 dtype: float32
78 name: gain
79 quantity: '?'
80- attributes:
81 - doc: Sampling rate, in Hz.
82 dtype: float32
83 name: rate
84 - doc: Unit of measurement for time, which is fixed to 'seconds'.
85 dtype: text
86 name: unit
87 value: seconds
88 doc: Timestamp of the first sample in seconds. When timestamps are uniformly
89 spaced, the timestamp of the first sample can be specified and all
90 subsequent ones calculated from the sampling rate attribute.
91 dtype: float64
92 name: starting_time
93 quantity: '?'
94- attributes:
95 - doc: Value is '1'
96 dtype: int32
97 name: interval
98 value: 1
99 - doc: Unit of measurement for timestamps, which is fixed to 'seconds'.
100 dtype: text
101 name: unit
102 value: seconds
103 dims:
104 - num_times
105 doc: Timestamps for samples stored in data, in seconds, relative to the common
106 experiment master-clock stored in NWBFile.timestamps_reference_time.
107 dtype: float64
108 name: timestamps
109 quantity: '?'
110 shape:
111 -
112- dims:
113 - num_times
114 doc: Numerical labels that apply to each time point in data for the purpose of
115 querying and slicing data by these values. If present, the length of this
116 array should be the same size as the first dimension of data.
117 dtype: uint8
118 name: control
119 quantity: '?'
120 shape:
121 -
122- dims:
123 - num_control_values
124 doc: Description of each control value. Must be present if control is present.
125 If present, control_description[0] should describe time points where control
126 == 0.
127 dtype: text
128 name: control_description
129 quantity: '?'
130 shape:
131 -
132doc: Stimulus current applied during current clamp recording.
133groups:
134- doc: Lab-specific time and sync information as provided directly from hardware
135 devices and that is necessary for aligning all acquired time information to
136 a common timebase. The timestamp array stores time in the common timebase.
137 This group will usually only be populated in TimeSeries that are stored
138 external to the NWB file, in files storing raw data. Once timestamp data is
139 calculated, the contents of 'sync' are mostly for archival purposes.
140 name: sync
141 quantity: '?'
142links:
143- doc: Link to IntracellularElectrode object that describes the electrode that
144 was used to apply or record this data.
145 name: electrode
146 target_type: IntracellularElectrode
147neurodata_type_def: CurrentClampStimulusSeries
148neurodata_type_inc: PatchClampSeries
3.10.5. VoltageClampSeries
Extends: PatchClampSeries
Description: see Section 2.9.5
YAML Specification:
1attributes:
2- doc: Protocol/stimulus name for this patch-clamp dataset.
3 dtype: text
4 name: stimulus_description
5- doc: Sweep number, allows to group different PatchClampSeries together.
6 dtype: uint32
7 name: sweep_number
8 required: false
9- default_value: no description
10 doc: Description of the time series.
11 dtype: text
12 name: description
13 required: false
14- default_value: no comments
15 doc: Human-readable comments about the TimeSeries. This second descriptive
16 field can be used to store additional information, or descriptive
17 information if the primary description field is populated with a
18 computer-readable string.
19 dtype: text
20 name: comments
21 required: false
22datasets:
23- attributes:
24 - doc: Base unit of measurement for working with the data. which is fixed to
25 'amperes'. Actual stored values are not necessarily stored in these units.
26 To access the data in these units, multiply 'data' by 'conversion' and add
27 'offset'.
28 dtype: text
29 name: unit
30 value: amperes
31 - default_value: 1.0
32 doc: Scalar to multiply each element in data to convert it to the specified
33 'unit'. If the data are stored in acquisition system units or other units
34 that require a conversion to be interpretable, multiply the data by
35 'conversion' to convert the data to the specified 'unit'. e.g. if the data
36 acquisition system stores values in this object as signed 16-bit integers
37 (int16 range -32,768 to 32,767) that correspond to a 5V range (-2.5V to
38 2.5V), and the data acquisition system gain is 8000X, then the
39 'conversion' multiplier to get from raw data acquisition values to
40 recorded volts is 2.5/32768/8000 = 9.5367e-9.
41 dtype: float32
42 name: conversion
43 required: false
44 - default_value: 0.0
45 doc: Scalar to add to the data after scaling by 'conversion' to finalize its
46 coercion to the specified 'unit'. Two common examples of this include (a)
47 data stored in an unsigned type that requires a shift after scaling to
48 re-center the data, and (b) specialized recording devices that naturally
49 cause a scalar offset with respect to the true units.
50 dtype: float32
51 name: offset
52 required: false
53 - default_value: -1.0
54 doc: Smallest meaningful difference between values in data, stored in the
55 specified by unit, e.g., the change in value of the least significant bit,
56 or a larger number if signal noise is known to be present. If unknown, use
57 -1.0.
58 dtype: float32
59 name: resolution
60 required: false
61 - doc: Optionally describe the continuity of the data. Can be "continuous",
62 "instantaneous", or "step". For example, a voltage trace would be
63 "continuous", because samples are recorded from a continuous process. An
64 array of lick times would be "instantaneous", because the data represents
65 distinct moments in time. Times of image presentations would be "step"
66 because the picture remains the same until the next timepoint. This field
67 is optional, but is useful in providing information about the underlying
68 data. It may inform the way this data is interpreted, the way it is
69 visualized, and what analysis methods are applicable.
70 dtype: text
71 name: continuity
72 required: false
73 doc: Recorded current.
74 name: data
75- attributes:
76 - doc: Unit of measurement for capacitance_fast, which is fixed to 'farads'.
77 dtype: text
78 name: unit
79 value: farads
80 doc: Fast capacitance, in farads.
81 dtype: float32
82 name: capacitance_fast
83 quantity: '?'
84- attributes:
85 - doc: Unit of measurement for capacitance_fast, which is fixed to 'farads'.
86 dtype: text
87 name: unit
88 value: farads
89 doc: Slow capacitance, in farads.
90 dtype: float32
91 name: capacitance_slow
92 quantity: '?'
93- attributes:
94 - doc: Unit of measurement for resistance_comp_bandwidth, which is fixed to
95 'hertz'.
96 dtype: text
97 name: unit
98 value: hertz
99 doc: Resistance compensation bandwidth, in hertz.
100 dtype: float32
101 name: resistance_comp_bandwidth
102 quantity: '?'
103- attributes:
104 - doc: Unit of measurement for resistance_comp_correction, which is fixed to
105 'percent'.
106 dtype: text
107 name: unit
108 value: percent
109 doc: Resistance compensation correction, in percent.
110 dtype: float32
111 name: resistance_comp_correction
112 quantity: '?'
113- attributes:
114 - doc: Unit of measurement for resistance_comp_prediction, which is fixed to
115 'percent'.
116 dtype: text
117 name: unit
118 value: percent
119 doc: Resistance compensation prediction, in percent.
120 dtype: float32
121 name: resistance_comp_prediction
122 quantity: '?'
123- attributes:
124 - doc: Unit of measurement for whole_cell_capacitance_comp, which is fixed to
125 'farads'.
126 dtype: text
127 name: unit
128 value: farads
129 doc: Whole cell capacitance compensation, in farads.
130 dtype: float32
131 name: whole_cell_capacitance_comp
132 quantity: '?'
133- attributes:
134 - doc: Unit of measurement for whole_cell_series_resistance_comp, which is
135 fixed to 'ohms'.
136 dtype: text
137 name: unit
138 value: ohms
139 doc: Whole cell series resistance compensation, in ohms.
140 dtype: float32
141 name: whole_cell_series_resistance_comp
142 quantity: '?'
143- doc: Gain of the recording, in units Volt/Amp (v-clamp) or Volt/Volt
144 (c-clamp).
145 dtype: float32
146 name: gain
147 quantity: '?'
148- attributes:
149 - doc: Sampling rate, in Hz.
150 dtype: float32
151 name: rate
152 - doc: Unit of measurement for time, which is fixed to 'seconds'.
153 dtype: text
154 name: unit
155 value: seconds
156 doc: Timestamp of the first sample in seconds. When timestamps are uniformly
157 spaced, the timestamp of the first sample can be specified and all
158 subsequent ones calculated from the sampling rate attribute.
159 dtype: float64
160 name: starting_time
161 quantity: '?'
162- attributes:
163 - doc: Value is '1'
164 dtype: int32
165 name: interval
166 value: 1
167 - doc: Unit of measurement for timestamps, which is fixed to 'seconds'.
168 dtype: text
169 name: unit
170 value: seconds
171 dims:
172 - num_times
173 doc: Timestamps for samples stored in data, in seconds, relative to the common
174 experiment master-clock stored in NWBFile.timestamps_reference_time.
175 dtype: float64
176 name: timestamps
177 quantity: '?'
178 shape:
179 -
180- dims:
181 - num_times
182 doc: Numerical labels that apply to each time point in data for the purpose of
183 querying and slicing data by these values. If present, the length of this
184 array should be the same size as the first dimension of data.
185 dtype: uint8
186 name: control
187 quantity: '?'
188 shape:
189 -
190- dims:
191 - num_control_values
192 doc: Description of each control value. Must be present if control is present.
193 If present, control_description[0] should describe time points where control
194 == 0.
195 dtype: text
196 name: control_description
197 quantity: '?'
198 shape:
199 -
200doc: Current data from an intracellular voltage-clamp recording. A corresponding
201 VoltageClampStimulusSeries (stored separately as a stimulus) is used to store
202 the voltage injected.
203groups:
204- doc: Lab-specific time and sync information as provided directly from hardware
205 devices and that is necessary for aligning all acquired time information to
206 a common timebase. The timestamp array stores time in the common timebase.
207 This group will usually only be populated in TimeSeries that are stored
208 external to the NWB file, in files storing raw data. Once timestamp data is
209 calculated, the contents of 'sync' are mostly for archival purposes.
210 name: sync
211 quantity: '?'
212links:
213- doc: Link to IntracellularElectrode object that describes the electrode that
214 was used to apply or record this data.
215 name: electrode
216 target_type: IntracellularElectrode
217neurodata_type_def: VoltageClampSeries
218neurodata_type_inc: PatchClampSeries
3.10.6. VoltageClampStimulusSeries
Extends: PatchClampSeries
Description: see Section 2.9.6
YAML Specification:
1attributes:
2- doc: Protocol/stimulus name for this patch-clamp dataset.
3 dtype: text
4 name: stimulus_description
5- doc: Sweep number, allows to group different PatchClampSeries together.
6 dtype: uint32
7 name: sweep_number
8 required: false
9- default_value: no description
10 doc: Description of the time series.
11 dtype: text
12 name: description
13 required: false
14- default_value: no comments
15 doc: Human-readable comments about the TimeSeries. This second descriptive
16 field can be used to store additional information, or descriptive
17 information if the primary description field is populated with a
18 computer-readable string.
19 dtype: text
20 name: comments
21 required: false
22datasets:
23- attributes:
24 - doc: Base unit of measurement for working with the data. which is fixed to
25 'volts'. Actual stored values are not necessarily stored in these units.
26 To access the data in these units, multiply 'data' by 'conversion' and add
27 'offset'.
28 dtype: text
29 name: unit
30 value: volts
31 - default_value: 1.0
32 doc: Scalar to multiply each element in data to convert it to the specified
33 'unit'. If the data are stored in acquisition system units or other units
34 that require a conversion to be interpretable, multiply the data by
35 'conversion' to convert the data to the specified 'unit'. e.g. if the data
36 acquisition system stores values in this object as signed 16-bit integers
37 (int16 range -32,768 to 32,767) that correspond to a 5V range (-2.5V to
38 2.5V), and the data acquisition system gain is 8000X, then the
39 'conversion' multiplier to get from raw data acquisition values to
40 recorded volts is 2.5/32768/8000 = 9.5367e-9.
41 dtype: float32
42 name: conversion
43 required: false
44 - default_value: 0.0
45 doc: Scalar to add to the data after scaling by 'conversion' to finalize its
46 coercion to the specified 'unit'. Two common examples of this include (a)
47 data stored in an unsigned type that requires a shift after scaling to
48 re-center the data, and (b) specialized recording devices that naturally
49 cause a scalar offset with respect to the true units.
50 dtype: float32
51 name: offset
52 required: false
53 - default_value: -1.0
54 doc: Smallest meaningful difference between values in data, stored in the
55 specified by unit, e.g., the change in value of the least significant bit,
56 or a larger number if signal noise is known to be present. If unknown, use
57 -1.0.
58 dtype: float32
59 name: resolution
60 required: false
61 - doc: Optionally describe the continuity of the data. Can be "continuous",
62 "instantaneous", or "step". For example, a voltage trace would be
63 "continuous", because samples are recorded from a continuous process. An
64 array of lick times would be "instantaneous", because the data represents
65 distinct moments in time. Times of image presentations would be "step"
66 because the picture remains the same until the next timepoint. This field
67 is optional, but is useful in providing information about the underlying
68 data. It may inform the way this data is interpreted, the way it is
69 visualized, and what analysis methods are applicable.
70 dtype: text
71 name: continuity
72 required: false
73 doc: Stimulus voltage applied.
74 name: data
75- doc: Gain of the recording, in units Volt/Amp (v-clamp) or Volt/Volt
76 (c-clamp).
77 dtype: float32
78 name: gain
79 quantity: '?'
80- attributes:
81 - doc: Sampling rate, in Hz.
82 dtype: float32
83 name: rate
84 - doc: Unit of measurement for time, which is fixed to 'seconds'.
85 dtype: text
86 name: unit
87 value: seconds
88 doc: Timestamp of the first sample in seconds. When timestamps are uniformly
89 spaced, the timestamp of the first sample can be specified and all
90 subsequent ones calculated from the sampling rate attribute.
91 dtype: float64
92 name: starting_time
93 quantity: '?'
94- attributes:
95 - doc: Value is '1'
96 dtype: int32
97 name: interval
98 value: 1
99 - doc: Unit of measurement for timestamps, which is fixed to 'seconds'.
100 dtype: text
101 name: unit
102 value: seconds
103 dims:
104 - num_times
105 doc: Timestamps for samples stored in data, in seconds, relative to the common
106 experiment master-clock stored in NWBFile.timestamps_reference_time.
107 dtype: float64
108 name: timestamps
109 quantity: '?'
110 shape:
111 -
112- dims:
113 - num_times
114 doc: Numerical labels that apply to each time point in data for the purpose of
115 querying and slicing data by these values. If present, the length of this
116 array should be the same size as the first dimension of data.
117 dtype: uint8
118 name: control
119 quantity: '?'
120 shape:
121 -
122- dims:
123 - num_control_values
124 doc: Description of each control value. Must be present if control is present.
125 If present, control_description[0] should describe time points where control
126 == 0.
127 dtype: text
128 name: control_description
129 quantity: '?'
130 shape:
131 -
132doc: Stimulus voltage applied during a voltage clamp recording.
133groups:
134- doc: Lab-specific time and sync information as provided directly from hardware
135 devices and that is necessary for aligning all acquired time information to
136 a common timebase. The timestamp array stores time in the common timebase.
137 This group will usually only be populated in TimeSeries that are stored
138 external to the NWB file, in files storing raw data. Once timestamp data is
139 calculated, the contents of 'sync' are mostly for archival purposes.
140 name: sync
141 quantity: '?'
142links:
143- doc: Link to IntracellularElectrode object that describes the electrode that
144 was used to apply or record this data.
145 name: electrode
146 target_type: IntracellularElectrode
147neurodata_type_def: VoltageClampStimulusSeries
148neurodata_type_inc: PatchClampSeries
3.10.7. IntracellularElectrode
Extends: NWBContainer
Description: see Section 2.9.7
YAML Specification:
1datasets:
2- doc: unique ID of the cell
3 dtype: text
4 name: cell_id
5 quantity: '?'
6- doc: Description of electrode (e.g., whole-cell, sharp, etc.).
7 dtype: text
8 name: description
9- doc: Electrode specific filtering.
10 dtype: text
11 name: filtering
12 quantity: '?'
13- doc: Initial access resistance.
14 dtype: text
15 name: initial_access_resistance
16 quantity: '?'
17- doc: Location of the electrode. Specify the area, layer, comments on
18 estimation of area/layer, stereotaxic coordinates if in vivo, etc. Use
19 standard atlas names for anatomical regions when possible.
20 dtype: text
21 name: location
22 quantity: '?'
23- doc: Electrode resistance, in ohms.
24 dtype: text
25 name: resistance
26 quantity: '?'
27- doc: Information about seal used for recording.
28 dtype: text
29 name: seal
30 quantity: '?'
31- doc: Information about slice used for recording.
32 dtype: text
33 name: slice
34 quantity: '?'
35doc: An intracellular electrode and its metadata.
36links:
37- doc: Device that was used to record from this electrode.
38 name: device
39 target_type: Device
40neurodata_type_def: IntracellularElectrode
41neurodata_type_inc: NWBContainer
3.10.8. SweepTable
Extends: DynamicTable
Description: see Section 2.9.8
YAML Specification:
1attributes:
2- dims:
3 - num_columns
4 doc: The names of the columns in this table. This should be used to specify an
5 order to the columns.
6 dtype: text
7 name: colnames
8 shape:
9 -
10- doc: Description of what is in this dynamic table.
11 dtype: text
12 name: description
13datasets:
14- doc: Sweep number of the PatchClampSeries in that row.
15 dtype: uint32
16 name: sweep_number
17 neurodata_type_inc: VectorData
18- doc: The PatchClampSeries with the sweep number in that row.
19 dtype:
20 reftype: object
21 target_type: PatchClampSeries
22 name: series
23 neurodata_type_inc: VectorData
24- doc: Index for series.
25 name: series_index
26 neurodata_type_inc: VectorIndex
27- dims:
28 - num_rows
29 doc: Array of unique identifiers for the rows of this dynamic table.
30 dtype: int
31 name: id
32 neurodata_type_inc: ElementIdentifiers
33 shape:
34 -
35- doc: Vector columns, including index columns, of this dynamic table.
36 neurodata_type_inc: VectorData
37 quantity: '*'
38doc: '[DEPRECATED] Table used to group different PatchClampSeries. SweepTable is being
39 replaced by IntracellularRecordingsTable and SimultaneousRecordingsTable tables.
40 Additional SequentialRecordingsTable, RepetitionsTable, and ExperimentalConditions
41 tables provide enhanced support for experiment metadata.'
42neurodata_type_def: SweepTable
43neurodata_type_inc: DynamicTable
3.10.9. IntracellularElectrodesTable
Extends: DynamicTable
Description: see Section 2.9.9
YAML Specification:
1attributes:
2- doc: Description of what is in this dynamic table.
3 dtype: text
4 name: description
5 value: Table for storing intracellular electrode related metadata.
6- dims:
7 - num_columns
8 doc: The names of the columns in this table. This should be used to specify an
9 order to the columns.
10 dtype: text
11 name: colnames
12 shape:
13 -
14datasets:
15- doc: Column for storing the reference to the intracellular electrode.
16 dtype:
17 reftype: object
18 target_type: IntracellularElectrode
19 name: electrode
20 neurodata_type_inc: VectorData
21- dims:
22 - num_rows
23 doc: Array of unique identifiers for the rows of this dynamic table.
24 dtype: int
25 name: id
26 neurodata_type_inc: ElementIdentifiers
27 shape:
28 -
29- doc: Vector columns, including index columns, of this dynamic table.
30 neurodata_type_inc: VectorData
31 quantity: '*'
32doc: Table for storing intracellular electrode related metadata.
33neurodata_type_def: IntracellularElectrodesTable
34neurodata_type_inc: DynamicTable
3.10.10. IntracellularStimuliTable
Extends: DynamicTable
Description: see Section 2.9.10
YAML Specification:
1attributes:
2- doc: Description of what is in this dynamic table.
3 dtype: text
4 name: description
5 value: Table for storing intracellular stimulus related metadata.
6- dims:
7 - num_columns
8 doc: The names of the columns in this table. This should be used to specify an
9 order to the columns.
10 dtype: text
11 name: colnames
12 shape:
13 -
14datasets:
15- doc: Column storing the reference to the recorded stimulus for the recording
16 (rows).
17 name: stimulus
18 neurodata_type_inc: TimeSeriesReferenceVectorData
19- doc: Column storing the reference to the stimulus template for the recording
20 (rows).
21 name: stimulus_template
22 neurodata_type_inc: TimeSeriesReferenceVectorData
23 quantity: '?'
24- dims:
25 - num_rows
26 doc: Array of unique identifiers for the rows of this dynamic table.
27 dtype: int
28 name: id
29 neurodata_type_inc: ElementIdentifiers
30 shape:
31 -
32- doc: Vector columns, including index columns, of this dynamic table.
33 neurodata_type_inc: VectorData
34 quantity: '*'
35doc: Table for storing intracellular stimulus related metadata.
36neurodata_type_def: IntracellularStimuliTable
37neurodata_type_inc: DynamicTable
3.10.11. IntracellularResponsesTable
Extends: DynamicTable
Description: see Section 2.9.11
YAML Specification:
1attributes:
2- doc: Description of what is in this dynamic table.
3 dtype: text
4 name: description
5 value: Table for storing intracellular response related metadata.
6- dims:
7 - num_columns
8 doc: The names of the columns in this table. This should be used to specify an
9 order to the columns.
10 dtype: text
11 name: colnames
12 shape:
13 -
14datasets:
15- doc: Column storing the reference to the recorded response for the recording
16 (rows)
17 name: response
18 neurodata_type_inc: TimeSeriesReferenceVectorData
19- dims:
20 - num_rows
21 doc: Array of unique identifiers for the rows of this dynamic table.
22 dtype: int
23 name: id
24 neurodata_type_inc: ElementIdentifiers
25 shape:
26 -
27- doc: Vector columns, including index columns, of this dynamic table.
28 neurodata_type_inc: VectorData
29 quantity: '*'
30doc: Table for storing intracellular response related metadata.
31neurodata_type_def: IntracellularResponsesTable
32neurodata_type_inc: DynamicTable
3.10.12. IntracellularRecordingsTable
Extends: AlignedDynamicTable
Description: see Section 2.9.12
YAML Specification:
1attributes:
2- doc: Description of the contents of this table. Inherited from
3 AlignedDynamicTable and overwritten here to fix the value of the attribute.
4 dtype: text
5 name: description
6 value: A table to group together a stimulus and response from a single
7 electrode and a single simultaneous recording and for storing metadata about
8 the intracellular recording.
9- dims:
10 - num_categories
11 doc: The names of the categories in this AlignedDynamicTable. Each category is
12 represented by one DynamicTable stored in the parent group. This attribute
13 should be used to specify an order of categories and the category names must
14 match the names of the corresponding DynamicTable in the group.
15 dtype: text
16 name: categories
17 shape:
18 -
19- dims:
20 - num_columns
21 doc: The names of the columns in this table. This should be used to specify an
22 order to the columns.
23 dtype: text
24 name: colnames
25 shape:
26 -
27datasets:
28- dims:
29 - num_rows
30 doc: Array of unique identifiers for the rows of this dynamic table.
31 dtype: int
32 name: id
33 neurodata_type_inc: ElementIdentifiers
34 shape:
35 -
36- doc: Vector columns, including index columns, of this dynamic table.
37 neurodata_type_inc: VectorData
38 quantity: '*'
39doc: A table to group together a stimulus and response from a single electrode
40 and a single simultaneous recording. Each row in the table represents a single
41 recording consisting typically of a stimulus and a corresponding response. In
42 some cases, however, only a stimulus or a response is recorded as part of an
43 experiment. In this case, both the stimulus and response will point to the
44 same TimeSeries while the idx_start and count of the invalid column will be
45 set to -1, thus, indicating that no values have been recorded for the stimulus
46 or response, respectively. Note, a recording MUST contain at least a stimulus
47 or a response. Typically the stimulus and response are PatchClampSeries.
48 However, the use of AD/DA channels that are not associated to an electrode is
49 also common in intracellular electrophysiology, in which case other TimeSeries
50 may be used.
51groups:
52- doc: Table for storing intracellular electrode related metadata.
53 name: electrodes
54 neurodata_type_inc: IntracellularElectrodesTable
55- doc: Table for storing intracellular stimulus related metadata.
56 name: stimuli
57 neurodata_type_inc: IntracellularStimuliTable
58- doc: Table for storing intracellular response related metadata.
59 name: responses
60 neurodata_type_inc: IntracellularResponsesTable
61- doc: A DynamicTable representing a particular category for columns in the
62 AlignedDynamicTable parent container. The table MUST be aligned with (i.e.,
63 have the same number of rows) as all other DynamicTables stored in the
64 AlignedDynamicTable parent container. The name of the category is given by
65 the name of the DynamicTable and its description by the description
66 attribute of the DynamicTable.
67 neurodata_type_inc: DynamicTable
68 quantity: '*'
69name: intracellular_recordings
70neurodata_type_def: IntracellularRecordingsTable
71neurodata_type_inc: AlignedDynamicTable
3.10.13. SimultaneousRecordingsTable
Extends: DynamicTable
Description: see Section 2.9.13
YAML Specification:
1attributes:
2- dims:
3 - num_columns
4 doc: The names of the columns in this table. This should be used to specify an
5 order to the columns.
6 dtype: text
7 name: colnames
8 shape:
9 -
10- doc: Description of what is in this dynamic table.
11 dtype: text
12 name: description
13datasets:
14- attributes:
15 - doc: Reference to the IntracellularRecordingsTable table that this table
16 region applies to. This specializes the attribute inherited from
17 DynamicTableRegion to fix the type of table that can be referenced here.
18 dtype:
19 reftype: object
20 target_type: IntracellularRecordingsTable
21 name: table
22 doc: A reference to one or more rows in the IntracellularRecordingsTable
23 table.
24 name: recordings
25 neurodata_type_inc: DynamicTableRegion
26- doc: Index dataset for the recordings column.
27 name: recordings_index
28 neurodata_type_inc: VectorIndex
29- dims:
30 - num_rows
31 doc: Array of unique identifiers for the rows of this dynamic table.
32 dtype: int
33 name: id
34 neurodata_type_inc: ElementIdentifiers
35 shape:
36 -
37- doc: Vector columns, including index columns, of this dynamic table.
38 neurodata_type_inc: VectorData
39 quantity: '*'
40doc: A table for grouping different intracellular recordings from the
41 IntracellularRecordingsTable table together that were recorded simultaneously
42 from different electrodes.
43name: simultaneous_recordings
44neurodata_type_def: SimultaneousRecordingsTable
45neurodata_type_inc: DynamicTable
3.10.14. SequentialRecordingsTable
Extends: DynamicTable
Description: see Section 2.9.14
YAML Specification:
1attributes:
2- dims:
3 - num_columns
4 doc: The names of the columns in this table. This should be used to specify an
5 order to the columns.
6 dtype: text
7 name: colnames
8 shape:
9 -
10- doc: Description of what is in this dynamic table.
11 dtype: text
12 name: description
13datasets:
14- attributes:
15 - doc: Reference to the SimultaneousRecordingsTable table that this table
16 region applies to. This specializes the attribute inherited from
17 DynamicTableRegion to fix the type of table that can be referenced here.
18 dtype:
19 reftype: object
20 target_type: SimultaneousRecordingsTable
21 name: table
22 doc: A reference to one or more rows in the SimultaneousRecordingsTable table.
23 name: simultaneous_recordings
24 neurodata_type_inc: DynamicTableRegion
25- doc: Index dataset for the simultaneous_recordings column.
26 name: simultaneous_recordings_index
27 neurodata_type_inc: VectorIndex
28- doc: The type of stimulus used for the sequential recording.
29 dtype: text
30 name: stimulus_type
31 neurodata_type_inc: VectorData
32- dims:
33 - num_rows
34 doc: Array of unique identifiers for the rows of this dynamic table.
35 dtype: int
36 name: id
37 neurodata_type_inc: ElementIdentifiers
38 shape:
39 -
40- doc: Vector columns, including index columns, of this dynamic table.
41 neurodata_type_inc: VectorData
42 quantity: '*'
43doc: A table for grouping different sequential recordings from the
44 SimultaneousRecordingsTable table together. This is typically used to group
45 together sequential recordings where a sequence of stimuli of the same type
46 with varying parameters have been presented in a sequence.
47name: sequential_recordings
48neurodata_type_def: SequentialRecordingsTable
49neurodata_type_inc: DynamicTable
3.10.15. RepetitionsTable
Extends: DynamicTable
Description: see Section 2.9.15
YAML Specification:
1attributes:
2- dims:
3 - num_columns
4 doc: The names of the columns in this table. This should be used to specify an
5 order to the columns.
6 dtype: text
7 name: colnames
8 shape:
9 -
10- doc: Description of what is in this dynamic table.
11 dtype: text
12 name: description
13datasets:
14- attributes:
15 - doc: Reference to the SequentialRecordingsTable table that this table region
16 applies to. This specializes the attribute inherited from
17 DynamicTableRegion to fix the type of table that can be referenced here.
18 dtype:
19 reftype: object
20 target_type: SequentialRecordingsTable
21 name: table
22 doc: A reference to one or more rows in the SequentialRecordingsTable table.
23 name: sequential_recordings
24 neurodata_type_inc: DynamicTableRegion
25- doc: Index dataset for the sequential_recordings column.
26 name: sequential_recordings_index
27 neurodata_type_inc: VectorIndex
28- dims:
29 - num_rows
30 doc: Array of unique identifiers for the rows of this dynamic table.
31 dtype: int
32 name: id
33 neurodata_type_inc: ElementIdentifiers
34 shape:
35 -
36- doc: Vector columns, including index columns, of this dynamic table.
37 neurodata_type_inc: VectorData
38 quantity: '*'
39doc: A table for grouping different sequential intracellular recordings
40 together. With each SequentialRecording typically representing a particular
41 type of stimulus, the RepetitionsTable table is typically used to group sets
42 of stimuli applied in sequence.
43name: repetitions
44neurodata_type_def: RepetitionsTable
45neurodata_type_inc: DynamicTable
3.10.16. ExperimentalConditionsTable
Extends: DynamicTable
Description: see Section 2.9.16
YAML Specification:
1attributes:
2- dims:
3 - num_columns
4 doc: The names of the columns in this table. This should be used to specify an
5 order to the columns.
6 dtype: text
7 name: colnames
8 shape:
9 -
10- doc: Description of what is in this dynamic table.
11 dtype: text
12 name: description
13datasets:
14- attributes:
15 - doc: Reference to the RepetitionsTable table that this table region applies
16 to. This specializes the attribute inherited from DynamicTableRegion to
17 fix the type of table that can be referenced here.
18 dtype:
19 reftype: object
20 target_type: RepetitionsTable
21 name: table
22 doc: A reference to one or more rows in the RepetitionsTable table.
23 name: repetitions
24 neurodata_type_inc: DynamicTableRegion
25- doc: Index dataset for the repetitions column.
26 name: repetitions_index
27 neurodata_type_inc: VectorIndex
28- dims:
29 - num_rows
30 doc: Array of unique identifiers for the rows of this dynamic table.
31 dtype: int
32 name: id
33 neurodata_type_inc: ElementIdentifiers
34 shape:
35 -
36- doc: Vector columns, including index columns, of this dynamic table.
37 neurodata_type_inc: VectorData
38 quantity: '*'
39doc: A table for grouping different intracellular recording repetitions together
40 that belong to the same experimental condition.
41name: experimental_conditions
42neurodata_type_def: ExperimentalConditionsTable
43neurodata_type_inc: DynamicTable
3.11. Optogenetics
This source module contains neurodata_types for opto-genetics data.
3.11.1. OptogeneticSeries
Extends: TimeSeries
Description: see Section 2.10.1
YAML Specification:
1attributes:
2- default_value: no description
3 doc: Description of the time series.
4 dtype: text
5 name: description
6 required: false
7- default_value: no comments
8 doc: Human-readable comments about the TimeSeries. This second descriptive
9 field can be used to store additional information, or descriptive
10 information if the primary description field is populated with a
11 computer-readable string.
12 dtype: text
13 name: comments
14 required: false
15datasets:
16- attributes:
17 - doc: Unit of measurement for data, which is fixed to 'watts'.
18 dtype: text
19 name: unit
20 value: watts
21 - default_value: 1.0
22 doc: Scalar to multiply each element in data to convert it to the specified
23 'unit'. If the data are stored in acquisition system units or other units
24 that require a conversion to be interpretable, multiply the data by
25 'conversion' to convert the data to the specified 'unit'. e.g. if the data
26 acquisition system stores values in this object as signed 16-bit integers
27 (int16 range -32,768 to 32,767) that correspond to a 5V range (-2.5V to
28 2.5V), and the data acquisition system gain is 8000X, then the
29 'conversion' multiplier to get from raw data acquisition values to
30 recorded volts is 2.5/32768/8000 = 9.5367e-9.
31 dtype: float32
32 name: conversion
33 required: false
34 - default_value: 0.0
35 doc: Scalar to add to the data after scaling by 'conversion' to finalize its
36 coercion to the specified 'unit'. Two common examples of this include (a)
37 data stored in an unsigned type that requires a shift after scaling to
38 re-center the data, and (b) specialized recording devices that naturally
39 cause a scalar offset with respect to the true units.
40 dtype: float32
41 name: offset
42 required: false
43 - default_value: -1.0
44 doc: Smallest meaningful difference between values in data, stored in the
45 specified by unit, e.g., the change in value of the least significant bit,
46 or a larger number if signal noise is known to be present. If unknown, use
47 -1.0.
48 dtype: float32
49 name: resolution
50 required: false
51 - doc: Optionally describe the continuity of the data. Can be "continuous",
52 "instantaneous", or "step". For example, a voltage trace would be
53 "continuous", because samples are recorded from a continuous process. An
54 array of lick times would be "instantaneous", because the data represents
55 distinct moments in time. Times of image presentations would be "step"
56 because the picture remains the same until the next timepoint. This field
57 is optional, but is useful in providing information about the underlying
58 data. It may inform the way this data is interpreted, the way it is
59 visualized, and what analysis methods are applicable.
60 dtype: text
61 name: continuity
62 required: false
63 dims:
64 - - num_times
65 - - num_times
66 - num_rois
67 doc: Applied power for optogenetic stimulus, in watts. Shape can be 1D or 2D.
68 2D data is meant to be used in an extension of OptogeneticSeries that
69 defines what the second dimension represents.
70 dtype: numeric
71 name: data
72 shape:
73 - -
74 - -
75 -
76- attributes:
77 - doc: Sampling rate, in Hz.
78 dtype: float32
79 name: rate
80 - doc: Unit of measurement for time, which is fixed to 'seconds'.
81 dtype: text
82 name: unit
83 value: seconds
84 doc: Timestamp of the first sample in seconds. When timestamps are uniformly
85 spaced, the timestamp of the first sample can be specified and all
86 subsequent ones calculated from the sampling rate attribute.
87 dtype: float64
88 name: starting_time
89 quantity: '?'
90- attributes:
91 - doc: Value is '1'
92 dtype: int32
93 name: interval
94 value: 1
95 - doc: Unit of measurement for timestamps, which is fixed to 'seconds'.
96 dtype: text
97 name: unit
98 value: seconds
99 dims:
100 - num_times
101 doc: Timestamps for samples stored in data, in seconds, relative to the common
102 experiment master-clock stored in NWBFile.timestamps_reference_time.
103 dtype: float64
104 name: timestamps
105 quantity: '?'
106 shape:
107 -
108- dims:
109 - num_times
110 doc: Numerical labels that apply to each time point in data for the purpose of
111 querying and slicing data by these values. If present, the length of this
112 array should be the same size as the first dimension of data.
113 dtype: uint8
114 name: control
115 quantity: '?'
116 shape:
117 -
118- dims:
119 - num_control_values
120 doc: Description of each control value. Must be present if control is present.
121 If present, control_description[0] should describe time points where control
122 == 0.
123 dtype: text
124 name: control_description
125 quantity: '?'
126 shape:
127 -
128doc: An optogenetic stimulus.
129groups:
130- doc: Lab-specific time and sync information as provided directly from hardware
131 devices and that is necessary for aligning all acquired time information to
132 a common timebase. The timestamp array stores time in the common timebase.
133 This group will usually only be populated in TimeSeries that are stored
134 external to the NWB file, in files storing raw data. Once timestamp data is
135 calculated, the contents of 'sync' are mostly for archival purposes.
136 name: sync
137 quantity: '?'
138links:
139- doc: Link to OptogeneticStimulusSite object that describes the site to which
140 this stimulus was applied.
141 name: site
142 target_type: OptogeneticStimulusSite
143neurodata_type_def: OptogeneticSeries
144neurodata_type_inc: TimeSeries
3.11.2. OptogeneticStimulusSite
Extends: NWBContainer
Description: see Section 2.10.2
YAML Specification:
1datasets:
2- doc: Description of stimulation site.
3 dtype: text
4 name: description
5- doc: Excitation wavelength, in nm.
6 dtype: float32
7 name: excitation_lambda
8- doc: Location of the stimulation site. Specify the area, layer, comments on
9 estimation of area/layer, stereotaxic coordinates if in vivo, etc. Use
10 standard atlas names for anatomical regions when possible.
11 dtype: text
12 name: location
13doc: A site of optogenetic stimulation.
14links:
15- doc: Device that generated the stimulus.
16 name: device
17 target_type: Device
18neurodata_type_def: OptogeneticStimulusSite
19neurodata_type_inc: NWBContainer
3.12. Optical physiology
This source module contains neurodata_types for optical physiology data.
3.12.1. OnePhotonSeries
Extends: ImageSeries
Description: see Section 2.11.1
YAML Specification:
1attributes:
2- doc: Photomultiplier gain.
3 dtype: float32
4 name: pmt_gain
5 required: false
6- doc: Lines imaged per second. This is also stored in /general/optophysiology
7 but is kept here as it is useful information for analysis, and so good to be
8 stored w/ the actual data.
9 dtype: float32
10 name: scan_line_rate
11 required: false
12- doc: Exposure time of the sample; often the inverse of the frequency.
13 dtype: float32
14 name: exposure_time
15 required: false
16- doc: Amount of pixels combined into 'bins'; could be 1, 2, 4, 8, etc.
17 dtype: uint8
18 name: binning
19 required: false
20- doc: Power of the excitation in mW, if known.
21 dtype: float32
22 name: power
23 required: false
24- doc: Intensity of the excitation in mW/mm^2, if known.
25 dtype: float32
26 name: intensity
27 required: false
28- default_value: no description
29 doc: Description of the time series.
30 dtype: text
31 name: description
32 required: false
33- default_value: no comments
34 doc: Human-readable comments about the TimeSeries. This second descriptive
35 field can be used to store additional information, or descriptive
36 information if the primary description field is populated with a
37 computer-readable string.
38 dtype: text
39 name: comments
40 required: false
41datasets:
42- attributes:
43 - default_value: 1.0
44 doc: Scalar to multiply each element in data to convert it to the specified
45 'unit'. If the data are stored in acquisition system units or other units
46 that require a conversion to be interpretable, multiply the data by
47 'conversion' to convert the data to the specified 'unit'. e.g. if the data
48 acquisition system stores values in this object as signed 16-bit integers
49 (int16 range -32,768 to 32,767) that correspond to a 5V range (-2.5V to
50 2.5V), and the data acquisition system gain is 8000X, then the
51 'conversion' multiplier to get from raw data acquisition values to
52 recorded volts is 2.5/32768/8000 = 9.5367e-9.
53 dtype: float32
54 name: conversion
55 required: false
56 - default_value: 0.0
57 doc: Scalar to add to the data after scaling by 'conversion' to finalize its
58 coercion to the specified 'unit'. Two common examples of this include (a)
59 data stored in an unsigned type that requires a shift after scaling to
60 re-center the data, and (b) specialized recording devices that naturally
61 cause a scalar offset with respect to the true units.
62 dtype: float32
63 name: offset
64 required: false
65 - default_value: -1.0
66 doc: Smallest meaningful difference between values in data, stored in the
67 specified by unit, e.g., the change in value of the least significant bit,
68 or a larger number if signal noise is known to be present. If unknown, use
69 -1.0.
70 dtype: float32
71 name: resolution
72 required: false
73 - doc: Base unit of measurement for working with the data. Actual stored
74 values are not necessarily stored in these units. To access the data in
75 these units, multiply 'data' by 'conversion' and add 'offset'.
76 dtype: text
77 name: unit
78 - doc: Optionally describe the continuity of the data. Can be "continuous",
79 "instantaneous", or "step". For example, a voltage trace would be
80 "continuous", because samples are recorded from a continuous process. An
81 array of lick times would be "instantaneous", because the data represents
82 distinct moments in time. Times of image presentations would be "step"
83 because the picture remains the same until the next timepoint. This field
84 is optional, but is useful in providing information about the underlying
85 data. It may inform the way this data is interpreted, the way it is
86 visualized, and what analysis methods are applicable.
87 dtype: text
88 name: continuity
89 required: false
90 dims:
91 - - frame
92 - x
93 - y
94 - - frame
95 - x
96 - y
97 - z
98 doc: Binary data representing images across frames. If data are stored in an
99 external file, this should be an empty 3D array.
100 dtype: numeric
101 name: data
102 shape:
103 - -
104 -
105 -
106 - -
107 -
108 -
109 -
110- dims:
111 - rank
112 doc: Number of pixels on x, y, (and z) axes.
113 dtype: int32
114 name: dimension
115 quantity: '?'
116 shape:
117 -
118- attributes:
119 - dims:
120 - num_files
121 doc: Each external image may contain one or more consecutive frames of the
122 full ImageSeries. This attribute serves as an index to indicate which
123 frames each file contains, to facilitate random access. The
124 'starting_frame' attribute, hence, contains a list of frame numbers within
125 the full ImageSeries of the first frame of each file listed in the parent
126 'external_file' dataset. Zero-based indexing is used (hence, the first
127 element will always be zero). For example, if the 'external_file' dataset
128 has three paths to files and the first file has 5 frames, the second file
129 has 10 frames, and the third file has 20 frames, then this attribute will
130 have values [0, 5, 15]. If there is a single external file that holds all
131 of the frames of the ImageSeries (and so there is a single element in the
132 'external_file' dataset), then this attribute should have value [0].
133 dtype: int32
134 name: starting_frame
135 shape:
136 -
137 dims:
138 - num_files
139 doc: Paths to one or more external file(s). The field is only present if
140 format='external'. This is only relevant if the image series is stored in
141 the file system as one or more image file(s). This field should NOT be used
142 if the image is stored in another NWB file and that file is linked to this
143 file.
144 dtype: text
145 name: external_file
146 quantity: '?'
147 shape:
148 -
149- default_value: raw
150 doc: Format of image. If this is 'external', then the attribute
151 'external_file' contains the path information to the image files. If this is
152 'raw', then the raw (single-channel) binary data is stored in the 'data'
153 dataset. If this attribute is not present, then the default format='raw'
154 case is assumed.
155 dtype: text
156 name: format
157 quantity: '?'
158- attributes:
159 - doc: Sampling rate, in Hz.
160 dtype: float32
161 name: rate
162 - doc: Unit of measurement for time, which is fixed to 'seconds'.
163 dtype: text
164 name: unit
165 value: seconds
166 doc: Timestamp of the first sample in seconds. When timestamps are uniformly
167 spaced, the timestamp of the first sample can be specified and all
168 subsequent ones calculated from the sampling rate attribute.
169 dtype: float64
170 name: starting_time
171 quantity: '?'
172- attributes:
173 - doc: Value is '1'
174 dtype: int32
175 name: interval
176 value: 1
177 - doc: Unit of measurement for timestamps, which is fixed to 'seconds'.
178 dtype: text
179 name: unit
180 value: seconds
181 dims:
182 - num_times
183 doc: Timestamps for samples stored in data, in seconds, relative to the common
184 experiment master-clock stored in NWBFile.timestamps_reference_time.
185 dtype: float64
186 name: timestamps
187 quantity: '?'
188 shape:
189 -
190- dims:
191 - num_times
192 doc: Numerical labels that apply to each time point in data for the purpose of
193 querying and slicing data by these values. If present, the length of this
194 array should be the same size as the first dimension of data.
195 dtype: uint8
196 name: control
197 quantity: '?'
198 shape:
199 -
200- dims:
201 - num_control_values
202 doc: Description of each control value. Must be present if control is present.
203 If present, control_description[0] should describe time points where control
204 == 0.
205 dtype: text
206 name: control_description
207 quantity: '?'
208 shape:
209 -
210doc: Image stack recorded over time from 1-photon microscope.
211groups:
212- doc: Lab-specific time and sync information as provided directly from hardware
213 devices and that is necessary for aligning all acquired time information to
214 a common timebase. The timestamp array stores time in the common timebase.
215 This group will usually only be populated in TimeSeries that are stored
216 external to the NWB file, in files storing raw data. Once timestamp data is
217 calculated, the contents of 'sync' are mostly for archival purposes.
218 name: sync
219 quantity: '?'
220links:
221- doc: Link to ImagingPlane object from which this TimeSeries data was
222 generated.
223 name: imaging_plane
224 target_type: ImagingPlane
225- doc: Link to the Device object that was used to capture these images.
226 name: device
227 quantity: '?'
228 target_type: Device
229neurodata_type_def: OnePhotonSeries
230neurodata_type_inc: ImageSeries
3.12.2. TwoPhotonSeries
Extends: ImageSeries
Description: see Section 2.11.2
YAML Specification:
1attributes:
2- doc: Photomultiplier gain.
3 dtype: float32
4 name: pmt_gain
5 required: false
6- doc: Lines imaged per second. This is also stored in /general/optophysiology
7 but is kept here as it is useful information for analysis, and so good to be
8 stored w/ the actual data.
9 dtype: float32
10 name: scan_line_rate
11 required: false
12- default_value: no description
13 doc: Description of the time series.
14 dtype: text
15 name: description
16 required: false
17- default_value: no comments
18 doc: Human-readable comments about the TimeSeries. This second descriptive
19 field can be used to store additional information, or descriptive
20 information if the primary description field is populated with a
21 computer-readable string.
22 dtype: text
23 name: comments
24 required: false
25datasets:
26- dims:
27 - - width|height
28 - - width|height|depth
29 doc: Width, height and depth of image, or imaged area, in meters.
30 dtype: float32
31 name: field_of_view
32 quantity: '?'
33 shape:
34 - - 2
35 - - 3
36- attributes:
37 - default_value: 1.0
38 doc: Scalar to multiply each element in data to convert it to the specified
39 'unit'. If the data are stored in acquisition system units or other units
40 that require a conversion to be interpretable, multiply the data by
41 'conversion' to convert the data to the specified 'unit'. e.g. if the data
42 acquisition system stores values in this object as signed 16-bit integers
43 (int16 range -32,768 to 32,767) that correspond to a 5V range (-2.5V to
44 2.5V), and the data acquisition system gain is 8000X, then the
45 'conversion' multiplier to get from raw data acquisition values to
46 recorded volts is 2.5/32768/8000 = 9.5367e-9.
47 dtype: float32
48 name: conversion
49 required: false
50 - default_value: 0.0
51 doc: Scalar to add to the data after scaling by 'conversion' to finalize its
52 coercion to the specified 'unit'. Two common examples of this include (a)
53 data stored in an unsigned type that requires a shift after scaling to
54 re-center the data, and (b) specialized recording devices that naturally
55 cause a scalar offset with respect to the true units.
56 dtype: float32
57 name: offset
58 required: false
59 - default_value: -1.0
60 doc: Smallest meaningful difference between values in data, stored in the
61 specified by unit, e.g., the change in value of the least significant bit,
62 or a larger number if signal noise is known to be present. If unknown, use
63 -1.0.
64 dtype: float32
65 name: resolution
66 required: false
67 - doc: Base unit of measurement for working with the data. Actual stored
68 values are not necessarily stored in these units. To access the data in
69 these units, multiply 'data' by 'conversion' and add 'offset'.
70 dtype: text
71 name: unit
72 - doc: Optionally describe the continuity of the data. Can be "continuous",
73 "instantaneous", or "step". For example, a voltage trace would be
74 "continuous", because samples are recorded from a continuous process. An
75 array of lick times would be "instantaneous", because the data represents
76 distinct moments in time. Times of image presentations would be "step"
77 because the picture remains the same until the next timepoint. This field
78 is optional, but is useful in providing information about the underlying
79 data. It may inform the way this data is interpreted, the way it is
80 visualized, and what analysis methods are applicable.
81 dtype: text
82 name: continuity
83 required: false
84 dims:
85 - - frame
86 - x
87 - y
88 - - frame
89 - x
90 - y
91 - z
92 doc: Binary data representing images across frames. If data are stored in an
93 external file, this should be an empty 3D array.
94 dtype: numeric
95 name: data
96 shape:
97 - -
98 -
99 -
100 - -
101 -
102 -
103 -
104- dims:
105 - rank
106 doc: Number of pixels on x, y, (and z) axes.
107 dtype: int32
108 name: dimension
109 quantity: '?'
110 shape:
111 -
112- attributes:
113 - dims:
114 - num_files
115 doc: Each external image may contain one or more consecutive frames of the
116 full ImageSeries. This attribute serves as an index to indicate which
117 frames each file contains, to facilitate random access. The
118 'starting_frame' attribute, hence, contains a list of frame numbers within
119 the full ImageSeries of the first frame of each file listed in the parent
120 'external_file' dataset. Zero-based indexing is used (hence, the first
121 element will always be zero). For example, if the 'external_file' dataset
122 has three paths to files and the first file has 5 frames, the second file
123 has 10 frames, and the third file has 20 frames, then this attribute will
124 have values [0, 5, 15]. If there is a single external file that holds all
125 of the frames of the ImageSeries (and so there is a single element in the
126 'external_file' dataset), then this attribute should have value [0].
127 dtype: int32
128 name: starting_frame
129 shape:
130 -
131 dims:
132 - num_files
133 doc: Paths to one or more external file(s). The field is only present if
134 format='external'. This is only relevant if the image series is stored in
135 the file system as one or more image file(s). This field should NOT be used
136 if the image is stored in another NWB file and that file is linked to this
137 file.
138 dtype: text
139 name: external_file
140 quantity: '?'
141 shape:
142 -
143- default_value: raw
144 doc: Format of image. If this is 'external', then the attribute
145 'external_file' contains the path information to the image files. If this is
146 'raw', then the raw (single-channel) binary data is stored in the 'data'
147 dataset. If this attribute is not present, then the default format='raw'
148 case is assumed.
149 dtype: text
150 name: format
151 quantity: '?'
152- attributes:
153 - doc: Sampling rate, in Hz.
154 dtype: float32
155 name: rate
156 - doc: Unit of measurement for time, which is fixed to 'seconds'.
157 dtype: text
158 name: unit
159 value: seconds
160 doc: Timestamp of the first sample in seconds. When timestamps are uniformly
161 spaced, the timestamp of the first sample can be specified and all
162 subsequent ones calculated from the sampling rate attribute.
163 dtype: float64
164 name: starting_time
165 quantity: '?'
166- attributes:
167 - doc: Value is '1'
168 dtype: int32
169 name: interval
170 value: 1
171 - doc: Unit of measurement for timestamps, which is fixed to 'seconds'.
172 dtype: text
173 name: unit
174 value: seconds
175 dims:
176 - num_times
177 doc: Timestamps for samples stored in data, in seconds, relative to the common
178 experiment master-clock stored in NWBFile.timestamps_reference_time.
179 dtype: float64
180 name: timestamps
181 quantity: '?'
182 shape:
183 -
184- dims:
185 - num_times
186 doc: Numerical labels that apply to each time point in data for the purpose of
187 querying and slicing data by these values. If present, the length of this
188 array should be the same size as the first dimension of data.
189 dtype: uint8
190 name: control
191 quantity: '?'
192 shape:
193 -
194- dims:
195 - num_control_values
196 doc: Description of each control value. Must be present if control is present.
197 If present, control_description[0] should describe time points where control
198 == 0.
199 dtype: text
200 name: control_description
201 quantity: '?'
202 shape:
203 -
204doc: Image stack recorded over time from 2-photon microscope.
205groups:
206- doc: Lab-specific time and sync information as provided directly from hardware
207 devices and that is necessary for aligning all acquired time information to
208 a common timebase. The timestamp array stores time in the common timebase.
209 This group will usually only be populated in TimeSeries that are stored
210 external to the NWB file, in files storing raw data. Once timestamp data is
211 calculated, the contents of 'sync' are mostly for archival purposes.
212 name: sync
213 quantity: '?'
214links:
215- doc: Link to ImagingPlane object from which this TimeSeries data was
216 generated.
217 name: imaging_plane
218 target_type: ImagingPlane
219- doc: Link to the Device object that was used to capture these images.
220 name: device
221 quantity: '?'
222 target_type: Device
223neurodata_type_def: TwoPhotonSeries
224neurodata_type_inc: ImageSeries
3.12.3. RoiResponseSeries
Extends: TimeSeries
Description: see Section 2.11.3
YAML Specification:
1attributes:
2- default_value: no description
3 doc: Description of the time series.
4 dtype: text
5 name: description
6 required: false
7- default_value: no comments
8 doc: Human-readable comments about the TimeSeries. This second descriptive
9 field can be used to store additional information, or descriptive
10 information if the primary description field is populated with a
11 computer-readable string.
12 dtype: text
13 name: comments
14 required: false
15datasets:
16- attributes:
17 - default_value: 1.0
18 doc: Scalar to multiply each element in data to convert it to the specified
19 'unit'. If the data are stored in acquisition system units or other units
20 that require a conversion to be interpretable, multiply the data by
21 'conversion' to convert the data to the specified 'unit'. e.g. if the data
22 acquisition system stores values in this object as signed 16-bit integers
23 (int16 range -32,768 to 32,767) that correspond to a 5V range (-2.5V to
24 2.5V), and the data acquisition system gain is 8000X, then the
25 'conversion' multiplier to get from raw data acquisition values to
26 recorded volts is 2.5/32768/8000 = 9.5367e-9.
27 dtype: float32
28 name: conversion
29 required: false
30 - default_value: 0.0
31 doc: Scalar to add to the data after scaling by 'conversion' to finalize its
32 coercion to the specified 'unit'. Two common examples of this include (a)
33 data stored in an unsigned type that requires a shift after scaling to
34 re-center the data, and (b) specialized recording devices that naturally
35 cause a scalar offset with respect to the true units.
36 dtype: float32
37 name: offset
38 required: false
39 - default_value: -1.0
40 doc: Smallest meaningful difference between values in data, stored in the
41 specified by unit, e.g., the change in value of the least significant bit,
42 or a larger number if signal noise is known to be present. If unknown, use
43 -1.0.
44 dtype: float32
45 name: resolution
46 required: false
47 - doc: Base unit of measurement for working with the data. Actual stored
48 values are not necessarily stored in these units. To access the data in
49 these units, multiply 'data' by 'conversion' and add 'offset'.
50 dtype: text
51 name: unit
52 - doc: Optionally describe the continuity of the data. Can be "continuous",
53 "instantaneous", or "step". For example, a voltage trace would be
54 "continuous", because samples are recorded from a continuous process. An
55 array of lick times would be "instantaneous", because the data represents
56 distinct moments in time. Times of image presentations would be "step"
57 because the picture remains the same until the next timepoint. This field
58 is optional, but is useful in providing information about the underlying
59 data. It may inform the way this data is interpreted, the way it is
60 visualized, and what analysis methods are applicable.
61 dtype: text
62 name: continuity
63 required: false
64 dims:
65 - - num_times
66 - - num_times
67 - num_ROIs
68 doc: Signals from ROIs.
69 dtype: numeric
70 name: data
71 shape:
72 - -
73 - -
74 -
75- doc: DynamicTableRegion referencing into an ROITable containing information on
76 the ROIs stored in this timeseries.
77 name: rois
78 neurodata_type_inc: DynamicTableRegion
79- attributes:
80 - doc: Sampling rate, in Hz.
81 dtype: float32
82 name: rate
83 - doc: Unit of measurement for time, which is fixed to 'seconds'.
84 dtype: text
85 name: unit
86 value: seconds
87 doc: Timestamp of the first sample in seconds. When timestamps are uniformly
88 spaced, the timestamp of the first sample can be specified and all
89 subsequent ones calculated from the sampling rate attribute.
90 dtype: float64
91 name: starting_time
92 quantity: '?'
93- attributes:
94 - doc: Value is '1'
95 dtype: int32
96 name: interval
97 value: 1
98 - doc: Unit of measurement for timestamps, which is fixed to 'seconds'.
99 dtype: text
100 name: unit
101 value: seconds
102 dims:
103 - num_times
104 doc: Timestamps for samples stored in data, in seconds, relative to the common
105 experiment master-clock stored in NWBFile.timestamps_reference_time.
106 dtype: float64
107 name: timestamps
108 quantity: '?'
109 shape:
110 -
111- dims:
112 - num_times
113 doc: Numerical labels that apply to each time point in data for the purpose of
114 querying and slicing data by these values. If present, the length of this
115 array should be the same size as the first dimension of data.
116 dtype: uint8
117 name: control
118 quantity: '?'
119 shape:
120 -
121- dims:
122 - num_control_values
123 doc: Description of each control value. Must be present if control is present.
124 If present, control_description[0] should describe time points where control
125 == 0.
126 dtype: text
127 name: control_description
128 quantity: '?'
129 shape:
130 -
131doc: ROI responses over an imaging plane. The first dimension represents time.
132 The second dimension, if present, represents ROIs.
133groups:
134- doc: Lab-specific time and sync information as provided directly from hardware
135 devices and that is necessary for aligning all acquired time information to
136 a common timebase. The timestamp array stores time in the common timebase.
137 This group will usually only be populated in TimeSeries that are stored
138 external to the NWB file, in files storing raw data. Once timestamp data is
139 calculated, the contents of 'sync' are mostly for archival purposes.
140 name: sync
141 quantity: '?'
142neurodata_type_def: RoiResponseSeries
143neurodata_type_inc: TimeSeries
3.12.4. DfOverF
Extends: NWBDataInterface
Description: see Section 2.11.4
YAML Specification:
1default_name: DfOverF
2doc: dF/F information about a region of interest (ROI). Storage hierarchy of
3 dF/F should be the same as for segmentation (i.e., same names for ROIs and for
4 image planes).
5groups:
6- doc: RoiResponseSeries object(s) containing dF/F for a ROI.
7 neurodata_type_inc: RoiResponseSeries
8 quantity: +
9neurodata_type_def: DfOverF
10neurodata_type_inc: NWBDataInterface
3.12.5. Fluorescence
Extends: NWBDataInterface
Description: see Section 2.11.5
YAML Specification:
1default_name: Fluorescence
2doc: Fluorescence information about a region of interest (ROI). Storage
3 hierarchy of fluorescence should be the same as for segmentation (ie, same
4 names for ROIs and for image planes).
5groups:
6- doc: RoiResponseSeries object(s) containing fluorescence data for a ROI.
7 neurodata_type_inc: RoiResponseSeries
8 quantity: +
9neurodata_type_def: Fluorescence
10neurodata_type_inc: NWBDataInterface
3.12.6. ImageSegmentation
Extends: NWBDataInterface
Description: see Section 2.11.6
YAML Specification:
1default_name: ImageSegmentation
2doc: Stores pixels in an image that represent different regions of interest
3 (ROIs) or masks. All segmentation for a given imaging plane is stored
4 together, with storage for multiple imaging planes (masks) supported. Each ROI
5 is stored in its own subgroup, with the ROI group containing both a 2D mask
6 and a list of pixels that make up this mask. Segments can also be used for
7 masking neuropil. If segmentation is allowed to change with time, a new
8 imaging plane (or module) is required and ROI names should remain consistent
9 between them.
10groups:
11- doc: Results from image segmentation of a specific imaging plane.
12 neurodata_type_inc: PlaneSegmentation
13 quantity: +
14neurodata_type_def: ImageSegmentation
15neurodata_type_inc: NWBDataInterface
3.12.7. PlaneSegmentation
Extends: DynamicTable
Description: see Section 2.11.7
YAML Specification:
1attributes:
2- dims:
3 - num_columns
4 doc: The names of the columns in this table. This should be used to specify an
5 order to the columns.
6 dtype: text
7 name: colnames
8 shape:
9 -
10- doc: Description of what is in this dynamic table.
11 dtype: text
12 name: description
13datasets:
14- dims:
15 - - num_roi
16 - num_x
17 - num_y
18 - - num_roi
19 - num_x
20 - num_y
21 - num_z
22 doc: ROI masks for each ROI. Each image mask is the size of the original
23 imaging plane (or volume) and members of the ROI are finite non-zero.
24 name: image_mask
25 neurodata_type_inc: VectorData
26 quantity: '?'
27 shape:
28 - -
29 -
30 -
31 - -
32 -
33 -
34 -
35- doc: Index into pixel_mask.
36 name: pixel_mask_index
37 neurodata_type_inc: VectorIndex
38 quantity: '?'
39- doc: 'Pixel masks for each ROI: a list of indices and weights for the ROI. Pixel
40 masks are concatenated and parsing of this dataset is maintained by the PlaneSegmentation'
41 dtype:
42 - doc: Pixel x-coordinate.
43 dtype: uint32
44 name: x
45 - doc: Pixel y-coordinate.
46 dtype: uint32
47 name: y
48 - doc: Weight of the pixel.
49 dtype: float32
50 name: weight
51 name: pixel_mask
52 neurodata_type_inc: VectorData
53 quantity: '?'
54- doc: Index into voxel_mask.
55 name: voxel_mask_index
56 neurodata_type_inc: VectorIndex
57 quantity: '?'
58- doc: 'Voxel masks for each ROI: a list of indices and weights for the ROI. Voxel
59 masks are concatenated and parsing of this dataset is maintained by the PlaneSegmentation'
60 dtype:
61 - doc: Voxel x-coordinate.
62 dtype: uint32
63 name: x
64 - doc: Voxel y-coordinate.
65 dtype: uint32
66 name: y
67 - doc: Voxel z-coordinate.
68 dtype: uint32
69 name: z
70 - doc: Weight of the voxel.
71 dtype: float32
72 name: weight
73 name: voxel_mask
74 neurodata_type_inc: VectorData
75 quantity: '?'
76- dims:
77 - num_rows
78 doc: Array of unique identifiers for the rows of this dynamic table.
79 dtype: int
80 name: id
81 neurodata_type_inc: ElementIdentifiers
82 shape:
83 -
84- doc: Vector columns, including index columns, of this dynamic table.
85 neurodata_type_inc: VectorData
86 quantity: '*'
87doc: Results from image segmentation of a specific imaging plane.
88groups:
89- doc: Image stacks that the segmentation masks apply to.
90 groups:
91 - doc: One or more image stacks that the masks apply to (can be one-element
92 stack).
93 neurodata_type_inc: ImageSeries
94 quantity: '*'
95 name: reference_images
96links:
97- doc: Link to ImagingPlane object from which this data was generated.
98 name: imaging_plane
99 target_type: ImagingPlane
100neurodata_type_def: PlaneSegmentation
101neurodata_type_inc: DynamicTable
3.12.8. ImagingPlane
Extends: NWBContainer
Description: see Section 2.11.8
YAML Specification:
1datasets:
2- doc: Description of the imaging plane.
3 dtype: text
4 name: description
5 quantity: '?'
6- doc: Excitation wavelength, in nm.
7 dtype: float32
8 name: excitation_lambda
9- doc: Rate that images are acquired, in Hz. If the corresponding TimeSeries is
10 present, the rate should be stored there instead.
11 dtype: float32
12 name: imaging_rate
13 quantity: '?'
14- doc: Calcium indicator.
15 dtype: text
16 name: indicator
17- doc: Location of the imaging plane. Specify the area, layer, comments on
18 estimation of area/layer, stereotaxic coordinates if in vivo, etc. Use
19 standard atlas names for anatomical regions when possible.
20 dtype: text
21 name: location
22- attributes:
23 - default_value: 1.0
24 doc: Scalar to multiply each element in data to convert it to the specified
25 'unit'. If the data are stored in acquisition system units or other units
26 that require a conversion to be interpretable, multiply the data by
27 'conversion' to convert the data to the specified 'unit'. e.g. if the data
28 acquisition system stores values in this object as pixels from x = -500 to
29 499, y = -500 to 499 that correspond to a 2 m x 2 m range, then the
30 'conversion' multiplier to get from raw data acquisition pixel units to
31 meters is 2/1000.
32 dtype: float32
33 name: conversion
34 required: false
35 - default_value: meters
36 doc: Base unit of measurement for working with the data. The default value
37 is 'meters'.
38 dtype: text
39 name: unit
40 required: false
41 dims:
42 - - height
43 - width
44 - x, y, z
45 - - height
46 - width
47 - depth
48 - x, y, z
49 doc: DEPRECATED Physical position of each pixel. 'xyz' represents the position
50 of the pixel relative to the defined coordinate space. Deprecated in favor
51 of origin_coords and grid_spacing.
52 dtype: float32
53 name: manifold
54 quantity: '?'
55 shape:
56 - -
57 -
58 - 3
59 - -
60 -
61 -
62 - 3
63- attributes:
64 - default_value: meters
65 doc: Measurement units for origin_coords. The default value is 'meters'.
66 dtype: text
67 name: unit
68 required: false
69 dims:
70 - - x, y
71 - - x, y, z
72 doc: Physical location of the first element of the imaging plane (0, 0) for
73 2-D data or (0, 0, 0) for 3-D data. See also reference_frame for what the
74 physical location is relative to (e.g., bregma).
75 dtype: float32
76 name: origin_coords
77 quantity: '?'
78 shape:
79 - - 2
80 - - 3
81- attributes:
82 - default_value: meters
83 doc: Measurement units for grid_spacing. The default value is 'meters'.
84 dtype: text
85 name: unit
86 required: false
87 dims:
88 - - x, y
89 - - x, y, z
90 doc: Space between pixels in (x, y) or voxels in (x, y, z) directions, in the
91 specified unit. Assumes imaging plane is a regular grid. See also
92 reference_frame to interpret the grid.
93 dtype: float32
94 name: grid_spacing
95 quantity: '?'
96 shape:
97 - - 2
98 - - 3
99- doc: Describes reference frame of origin_coords and grid_spacing. For example,
100 this can be a text description of the anatomical location and orientation of
101 the grid defined by origin_coords and grid_spacing or the vectors needed to
102 transform or rotate the grid to a common anatomical axis (e.g., AP/DV/ML).
103 This field is necessary to interpret origin_coords and grid_spacing. If
104 origin_coords and grid_spacing are not present, then this field is not
105 required. For example, if the microscope takes 10 x 10 x 2 images, where the
106 first value of the data matrix (index (0, 0, 0)) corresponds to (-1.2, -0.6,
107 -2) mm relative to bregma, the spacing between pixels is 0.2 mm in x, 0.2 mm
108 in y and 0.5 mm in z, and larger numbers in x means more anterior, larger
109 numbers in y means more rightward, and larger numbers in z means more
110 ventral, then enter the following -- origin_coords = (-1.2, -0.6, -2)
111 grid_spacing = (0.2, 0.2, 0.5) reference_frame = "Origin coordinates are
112 relative to bregma. First dimension corresponds to anterior-posterior axis
113 (larger index = more anterior). Second dimension corresponds to
114 medial-lateral axis (larger index = more rightward). Third dimension
115 corresponds to dorsal-ventral axis (larger index = more ventral)."
116 dtype: text
117 name: reference_frame
118 quantity: '?'
119doc: An imaging plane and its metadata.
120groups:
121- doc: An optical channel used to record from an imaging plane.
122 neurodata_type_inc: OpticalChannel
123 quantity: +
124links:
125- doc: Link to the Device object that was used to record from this electrode.
126 name: device
127 target_type: Device
128neurodata_type_def: ImagingPlane
129neurodata_type_inc: NWBContainer
3.12.9. OpticalChannel
Extends: NWBContainer
Description: see Section 2.11.9
YAML Specification:
1datasets:
2- doc: Description or other notes about the channel.
3 dtype: text
4 name: description
5- doc: Emission wavelength for channel, in nm.
6 dtype: float32
7 name: emission_lambda
8doc: An optical channel used to record from an imaging plane.
9neurodata_type_def: OpticalChannel
10neurodata_type_inc: NWBContainer
3.12.10. MotionCorrection
Extends: NWBDataInterface
Description: see Section 2.11.10
YAML Specification:
1default_name: MotionCorrection
2doc: 'An image stack where all frames are shifted (registered) to a common coordinate
3 system, to account for movement and drift between frames. Note: each frame at each
4 point in time is assumed to be 2-D (has only x & y dimensions).'
5groups:
6- doc: Results from motion correction of an image stack.
7 neurodata_type_inc: CorrectedImageStack
8 quantity: +
9neurodata_type_def: MotionCorrection
10neurodata_type_inc: NWBDataInterface
3.12.11. CorrectedImageStack
Extends: NWBDataInterface
Description: see Section 2.11.11
YAML Specification:
1doc: Results from motion correction of an image stack.
2groups:
3- doc: Image stack with frames shifted to the common coordinates.
4 name: corrected
5 neurodata_type_inc: ImageSeries
6- doc: Stores the x,y delta necessary to align each frame to the common
7 coordinates, for example, to align each frame to a reference image.
8 name: xy_translation
9 neurodata_type_inc: TimeSeries
10links:
11- doc: Link to ImageSeries object that is being registered.
12 name: original
13 target_type: ImageSeries
14neurodata_type_def: CorrectedImageStack
15neurodata_type_inc: NWBDataInterface
3.13. Retinotopy
This source module contains neurodata_type for retinotopy data.
3.13.1. ImagingRetinotopy
Extends: NWBDataInterface
Description: see Section 2.12.1
YAML Specification:
1datasets:
2- attributes:
3 - dims:
4 - num_rows, num_cols
5 doc: 'Number of rows and columns in the image. NOTE: row, column representation
6 is equivalent to height, width.'
7 dtype: int32
8 name: dimension
9 shape:
10 - 2
11 - dims:
12 - height, width
13 doc: Size of viewing area, in meters.
14 dtype: float32
15 name: field_of_view
16 shape:
17 - 2
18 - doc: Unit that axis data is stored in (e.g., degrees).
19 dtype: text
20 name: unit
21 dims:
22 - num_rows
23 - num_cols
24 doc: Phase response to stimulus on the first measured axis.
25 dtype: float32
26 name: axis_1_phase_map
27 shape:
28 -
29 -
30- attributes:
31 - dims:
32 - num_rows, num_cols
33 doc: 'Number of rows and columns in the image. NOTE: row, column representation
34 is equivalent to height, width.'
35 dtype: int32
36 name: dimension
37 shape:
38 - 2
39 - dims:
40 - height, width
41 doc: Size of viewing area, in meters.
42 dtype: float32
43 name: field_of_view
44 shape:
45 - 2
46 - doc: Unit that axis data is stored in (e.g., degrees).
47 dtype: text
48 name: unit
49 dims:
50 - num_rows
51 - num_cols
52 doc: Power response on the first measured axis. Response is scaled so 0.0 is
53 no power in the response and 1.0 is maximum relative power.
54 dtype: float32
55 name: axis_1_power_map
56 quantity: '?'
57 shape:
58 -
59 -
60- attributes:
61 - dims:
62 - num_rows, num_cols
63 doc: 'Number of rows and columns in the image. NOTE: row, column representation
64 is equivalent to height, width.'
65 dtype: int32
66 name: dimension
67 shape:
68 - 2
69 - dims:
70 - height, width
71 doc: Size of viewing area, in meters.
72 dtype: float32
73 name: field_of_view
74 shape:
75 - 2
76 - doc: Unit that axis data is stored in (e.g., degrees).
77 dtype: text
78 name: unit
79 dims:
80 - num_rows
81 - num_cols
82 doc: Phase response to stimulus on the second measured axis.
83 dtype: float32
84 name: axis_2_phase_map
85 shape:
86 -
87 -
88- attributes:
89 - dims:
90 - num_rows, num_cols
91 doc: 'Number of rows and columns in the image. NOTE: row, column representation
92 is equivalent to height, width.'
93 dtype: int32
94 name: dimension
95 shape:
96 - 2
97 - dims:
98 - height, width
99 doc: Size of viewing area, in meters.
100 dtype: float32
101 name: field_of_view
102 shape:
103 - 2
104 - doc: Unit that axis data is stored in (e.g., degrees).
105 dtype: text
106 name: unit
107 dims:
108 - num_rows
109 - num_cols
110 doc: Power response on the second measured axis. Response is scaled so 0.0 is
111 no power in the response and 1.0 is maximum relative power.
112 dtype: float32
113 name: axis_2_power_map
114 quantity: '?'
115 shape:
116 -
117 -
118- dims:
119 - axis_1, axis_2
120 doc: Two-element array describing the contents of the two response axis
121 fields. Description should be something like ['altitude', 'azimuth'] or
122 '['radius', 'theta'].
123 dtype: text
124 name: axis_descriptions
125 shape:
126 - 2
127- attributes:
128 - doc: Number of bits used to represent each value. This is necessary to
129 determine maximum (white) pixel value.
130 dtype: int32
131 name: bits_per_pixel
132 - dims:
133 - num_rows, num_cols
134 doc: 'Number of rows and columns in the image. NOTE: row, column representation
135 is equivalent to height, width.'
136 dtype: int32
137 name: dimension
138 shape:
139 - 2
140 - dims:
141 - height, width
142 doc: Size of viewing area, in meters.
143 dtype: float32
144 name: field_of_view
145 shape:
146 - 2
147 - doc: Focal depth offset, in meters.
148 dtype: float32
149 name: focal_depth
150 - doc: Format of image. Right now only 'raw' is supported.
151 dtype: text
152 name: format
153 dims:
154 - num_rows
155 - num_cols
156 doc: 'Gray-scale image taken with same settings/parameters (e.g., focal depth, wavelength)
157 as data collection. Array format: [rows][columns].'
158 dtype: uint16
159 name: focal_depth_image
160 quantity: '?'
161 shape:
162 -
163 -
164- attributes:
165 - dims:
166 - num_rows, num_cols
167 doc: 'Number of rows and columns in the image. NOTE: row, column representation
168 is equivalent to height, width.'
169 dtype: int32
170 name: dimension
171 shape:
172 - 2
173 - dims:
174 - height, width
175 doc: Size of viewing area, in meters.
176 dtype: float32
177 name: field_of_view
178 shape:
179 - 2
180 dims:
181 - num_rows
182 - num_cols
183 doc: Sine of the angle between the direction of the gradient in axis_1 and
184 axis_2.
185 dtype: float32
186 name: sign_map
187 quantity: '?'
188 shape:
189 -
190 -
191- attributes:
192 - doc: Number of bits used to represent each value. This is necessary to
193 determine maximum (white) pixel value
194 dtype: int32
195 name: bits_per_pixel
196 - dims:
197 - num_rows, num_cols
198 doc: 'Number of rows and columns in the image. NOTE: row, column representation
199 is equivalent to height, width.'
200 dtype: int32
201 name: dimension
202 shape:
203 - 2
204 - dims:
205 - height, width
206 doc: Size of viewing area, in meters.
207 dtype: float32
208 name: field_of_view
209 shape:
210 - 2
211 - doc: Format of image. Right now only 'raw' is supported.
212 dtype: text
213 name: format
214 dims:
215 - num_rows
216 - num_cols
217 doc: 'Gray-scale anatomical image of cortical surface. Array structure: [rows][columns]'
218 dtype: uint16
219 name: vasculature_image
220 shape:
221 -
222 -
223default_name: ImagingRetinotopy
224doc: 'DEPRECATED. Intrinsic signal optical imaging or widefield imaging for measuring
225 retinotopy. Stores orthogonal maps (e.g., altitude/azimuth; radius/theta) of responses
226 to specific stimuli and a combined polarity map from which to identify visual areas.
227 This group does not store the raw responses imaged during retinotopic mapping or
228 the stimuli presented, but rather the resulting phase and power maps after applying
229 a Fourier transform on the averaged responses. Note: for data consistency, all images
230 and arrays are stored in the format [row][column] and [row, col], which equates
231 to [y][x]. Field of view and dimension arrays may appear backward (i.e., y before
232 x).'
233neurodata_type_def: ImagingRetinotopy
234neurodata_type_inc: NWBDataInterface