Homer3
Homer3 copied to clipboard
BUNPC
[BUG]: Non proper handling of non-constant sampling rates
Version of Homer3 you are using
Development branch v1.35.4, latest as of date (same issue in master etc)
Your environment (MATLAB environment and OS)
All.
Description of the issue
Steps to reproduce:
Our nirs system samples on 10Hz mostly, but the actual rate can vary a bit in different time points, and even rarely some sample may be skipped etc. Eg it can happen that the times reported are 0.000, 0.110, 0.210, 0.310 .... The issue arises when data with such variations in sampling rate is used in the preprocessing (and in particular in the averaging parts).
Expected behavior:
The actual times/variation in sampling rate should be taken into account in the averaging processes.
Actual behavior:
In hmrR_BlockAvg line 66 dt = t(2)-t(1) the sampling rate is assumed constant and computed by the difference of the first two time points, which in some subjects happens to be bigger than normal (0.110 vs 0.100). The data range around the stimuli markers is selected based on this sampling rate, rather than based on the actual times in the time vector (line 66:70).
In subject level, as this also results in different runs to assume different sampling rates, it results in truncations in the data fed in hmrS_RunAvg and no regard for the differences in assumed sampling rates between runs in the function itself, which leads to erroneously averaging different time points together, as well as losing a final part of the data timeseries in runs with the proper assumed sampling rate (because of the truncation).
All this should probably not matter in shorter trials, but in our long trial design it seems to cause some minor to moderate issues.
Possible solution:
I do not know if our case of small variation in sampling rate is a rare one (we use the NTS fnirs system). I am not sure if and how you want to handle this, but the solution I think I will apply in my script will be to interpolate/resample the data timeseries prior to feeding it to hmrR_BlockAvg to a prefixed sampling rate.
I just realised that other homer3 functions, like wavelet motion correction, compute sampling frequency in similar way. Not sure if this is any deal overall, but I think I will just make a homer function to interpolate the data to a given sampling rate and share it.
The assumption that sampling rates are constant throughout the signal is pretty baked in to Homer processing.
The tool you describe would be useful. You could add it as a standalone script or include it as a processing function. See: https://github.com/BUNPC/Homer3/wiki/User-Function-Definitions-and-the-Processing-Stream
is there a function currently that can resample SNIRF or NIRS files? We had some issues with inconsistent sampling rates in a current study.
There may be one built in under Tools drop down towards the bottom? Can't remember right now.