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

Handling of noncontiguous segments in BioPac recordings #279

Open
tsalo opened this issue Jul 26, 2020 · 2 comments
Open

Handling of noncontiguous segments in BioPac recordings #279

tsalo opened this issue Jul 26, 2020 · 2 comments
Labels
Discussion Discussion of a concept or implementation. Need to stay always open. Enhancement New feature or request

Comments

@tsalo
Copy link
Member

tsalo commented Jul 26, 2020

Detailed Description

For multi-run workflows (including the one proposed in #219), the existence of noncontiguous segments (i.e., stopping and starting recording without saving to separate files) can present a problem for identifying runs, as there will be missing time in the overall time series that, at least currently, isn't reflected in the BlueprintInput object at all.

Context / Motivation

I originally planned to address this in #219, but couldn't figure out an easy solution. BioPac segment time stamps only have second-level resolution, so stitching them together with empty values during the missing time would introduce 1-2 seconds of potential error. Additionally, the time stamps require a bit of customization in order to do, and still must be triggered manually when a new segment is started.

Possible Implementation

I'm not sure. I see three reasonable options:

  1. Perhaps we could automatically split BioPac physio data, as it's read in, based on segments? That way, users would get multiple BlueprintInput objects based on the separate segments.
    • Any segments with no trigger periods would be dropped, of course.
  2. We could stitch together the segments (assuming they have time stamps) and just accept the 1-2s error.
    • There would still need to be a warning.
  3. Raise a warning. At minimum, users should be aware that there are possible gaps in the time series when there are multiple segments.
    • If the segments start and stop before or after any of the trigger runs, this is less of a problem. It should probably just be considered when figuring out the amount of time before or after the run to retain in the new file(s).
    • Also, the segments could be reflected in the x-axis (time) of any plots with an axis break symbol (--//--).
@tsalo tsalo added Enhancement New feature or request Discussion Discussion of a concept or implementation. Need to stay always open. labels Jul 26, 2020
@smoia
Copy link
Member

smoia commented Jul 31, 2020

@tsalo do you have a file like the one you're describing to see?
I thought that when stopping and restarting recordings, AcqKnowledge just stitched together the timeseries as if it was a continuous recording.
@sangfrois implementation of multi-runs splits should treat this kind of files without any issue, I don't know if yours would encounter more problems. If that's the case, we can write in the help and in the documentation that it's not possible to use pre-existing BIDS libraries information with such files.

In any case, let's see a file and decide the course of action (maybe it's easier than expected).

@tsalo
Copy link
Member Author

tsalo commented Jul 31, 2020

I have a couple, but they all have identifiable timestamps. I can try to see if I can overwrite the timestamps to make the files shareable.

AcqKnowledge does just stitch the time series together, but this hides the missing time. The segments can be accessed, though, in order to see when those breaks occur, although without timestamps there's no way to know how long those breaks are. At least not as far as I know.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Discussion Discussion of a concept or implementation. Need to stay always open. Enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants