search

fNIRS / snirf

SNIRF Format Specification
http://fnirs.org/resources/software/snirf/
Other
59 stars 34 forks source link

Definition of Channel #53

Closed MichaelUM closed 3 years ago

MichaelUM commented 3 years ago

Just a short remark to clarify the definition of a channel. As there is no clear definition within the format I assume that a channel can contain basically any data defined in detail in the measurementList and that it is basically defined as a source detector pair. This then implies that a source detector pair can define 0 - n channels. By this definition, I could create a snirf file containing, say, only one channel of HbO data, or 20 channels of only WL1 data, for whatever reason I might want, but just to make the point that a source detector pair doesn't need to include all datatypes that are used in the snirf file. Also since if never directly defined within the format.

Thanks for the clarification!

MichaelUM commented 3 years ago

One implication of the remark above: It is possible / intended to store for example raw and processed data within one snirf datatimeseries structure?

fangq commented 3 years ago

the dataType field is channel bounded, so, I suppose the answer is yes, one can store a raw data stream in a "channel" and something for another "channel", but the sourceIndex and detectorIndex are also channel bound, so, it would be confusing if there are multiple data types that are attached to the same src/det pair/channel.

a related question is: should we forbid duplicated src/det-index pairs in the same measurementList?

@jayd1860 @dboas and @huppertt, what do you think?

dboas commented 3 years ago

@fangq we should NOT forbid duplicate src/det-index pairs in the same measurementList. For instance, the src/det-index pair can be coupled with the optional wavelength index to indicate two different channels that have the same src/det-index pair but different wavelength indices.

@fangq I don't see any confusion or issue with have multiple data types attached to the same src/det-index pair. Each data type would be specified in a different element of the measurementList array. Best practice would presumably dictate that the snirf file containing raw data should never be mixed with derived data types, that is all derived data types should be stored in a different snirf file as is being described now in the BIDS-fNIRS specification that incorporates SNIRF into a higher level specification of folder structures for neuroimaging data. But the snirf file for the derived data could easily have multiple data types for the same src/det-index pair. For instance, you could save the optical density derived data and the concentration derived data as separate channels (i.e. elements in the measurementList array).

I think this also addresses all of the questions brought up by @MichaelUM

MichaelUM commented 3 years ago

@fangq @dboas thanks a lot, this addressed all my questions! To summarize: We will keep raw and processed data in seperate SNIRF files for best practice and might store different processed data in one SNIRF file.