dataTypeLabel spec for "absolute" moments (TD data)

[julien-dubois-k]

The dataTypeLabel spec supports only the changes in moments of the distribution of time of flight (DTOF), with labels:

• dOD Change in optical density
• dMean Change in mean time-of-flight
• dVar Change in variance (2nd central moment)

Would having labels mean and var, so one can export the absolute values of the moments, be agreeable? There is a slight loss of information in the process of computing the changes only.

How about counts or intensity? I'm in particular thinking about TD-nirs gated data or histograms, for which being able to export the absolute quantity (photon counts) rather than the relative quantity (dOD) may be useful.

Note: This is related to a discussion in MNE python's repository, around supporting reading in TD-NIRS data.

[julien-dubois-k]

may I raise this issue to the top of the stack again? Thank you.

[samuelpowell]

In a meeting on 17/04/2024, it was proposed to add an optional, per-channel, absolute offset field. When present, absolute data could be represented by the sum of the channel offset and the channel data time series (which would still then be a delta).

This approach was suggested as it avoids the proliferation of different entries in the dataTypeLabel field. Morevoer, it will not break any existing analysis code where absolute values have already been stored using technically incorrect type labels.

[dboas]

Should we discuss possible implementations for this offset in the spec here?

It could simply be data.dataOffset.

Or we can come up with something a bit more flexible that would allow other types of data to be provided on a per channel basis. For instance something likedata.dataMeta that could then have subfields of .name, .data, and .dataLabels much like stim has.

[rob-luke]

As part of understanding the implications of the simpler proposal from of dataOffset, I wrote out how it might be implemented in #143.

Considering the dataMeta approach, what is something one might want to add there in the future?

[samuelpowell]

Fixed in #143