Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multiplex configuration description for enahnced data processing #141

Open
samuelpowell opened this issue Apr 19, 2024 · 2 comments
Open

Comments

@samuelpowell
Copy link
Collaborator

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
Copy link
Collaborator

dboas commented Apr 19, 2024

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
Copy link
Collaborator Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants