fNIRS / snirf

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

Multiplex configuration description for enahnced data processing #141

Open samuelpowell opened 3 months ago

samuelpowell commented 3 months ago

Further to #112 it may be desirable to add information to the probe description which allows one to understand the multiplexing scheme used to acquire the data, where this may be informative in terms of signal to noise, and so on.

Consider a system where two channels are acquired on a single detector, at the same time. If these channels have vastly different intensities it may be that the lower intensity channel's noise floor is elevated by the shot noise of the higher intensity channel. Knowing that this is the case permits one to properly weight each channel (e.g. through it's variance or covariance when performing estimation or image reconstruction).

Note that the intention is not to provide information that is strictly neccesary to interpret the data (this process should happen in the vendor's acquisiton software).

SNIRF could potentially permit information about the multiplexing scheme to be stored that could either be completely ignored, or used to help understand potential excess shot-noise (as could happen with frequency encoding) or cross-talk (as can easily happen with spatial-temporal multiplexing).

dboas commented 3 months ago

Thanks for opening this @samuelpowell .

I was thinking that it was appropriate to put this information in the probe object, perhaps creating probe.multiplexing.

But from there, I am not sure how to describe it.

For temporal multiplexing, we need to indicate which sources and wavelengths are on for any given state. This could be described in a 2D array. But then we also need to describe what is conveyed in each column (say which source and which wavelength) and what is conveyed in each row (perhaps the timing of the state). I think that would capture what I have in my experience for temporal multiplexing.

For frequency multiplexing, do we need to convey the encoding frequency? It seems that we could probably just capture this in the temporal multiplexing scheme above, perhaps with the addition of perhaps a parallel 2D array that indicates the encoding frequency for the given source/wavelength and state.

This needs further discussion.

samuelpowell commented 3 months ago

One representation would be that each channel (measurementList entry) has optional fields for a temporal multiplex index, and frequency multiplex index.

Without any further information, one would be able to determine the potential for excess shot-noise by checking to see if two channels share the same temporal multiplex index. If the frequeny multiplex index were also the same (or not present) then that would indicate that cross-talk was possible.

I don't think it's essential, but if present these indices could optionally index into an array which gives the temporal offset (from start of frame) or the modulation frequency.