Closed julien-dubois-k closed 2 months ago
may I raise this issue to the top of the stack again? Thank you.
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.
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.
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?
Fixed in #143
The
dataTypeLabel
spec supports only the changes in moments of the distribution of time of flight (DTOF), with labels:dOD
Change in optical densitydMean
Change in mean time-of-flightdVar
Change in variance (2nd central moment)Would having labels
mean
andvar
, 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
orintensity
? 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.