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 timestamps for different nodes/subject parts #34

Open
h-mayorquin opened this issue Sep 2, 2024 · 0 comments
Open

Handling of timestamps for different nodes/subject parts #34

h-mayorquin opened this issue Sep 2, 2024 · 0 comments

Comments

@h-mayorquin
Copy link
Contributor

This is a question that I think can help to document the schema better.

The schema says the following:

doc: Group that holds estimated position data for multiple body parts, computed
from the same video with the same tool/algorithm. The timestamps of each child
PoseEstimationSeries type should be the same.

But when I was working on sleap-io I remember finding on the example data that the algorithm did not produce estimations for some frames. What I ended up writing (because I did not read that part of the schema and the API did not throw an error) is different timestamps per node see here:

https://github.com/talmolab/sleap-io/blob/2bc3d5210c46bdb25413d25970c4bdc7adb6e8cc/sleap_io/io/nwb.py#L439-L441

As I was reading the schema today for totally unrelated reasons this jumped to mind and I just wanted to document it.

Is there a reason this is the expected behavior (same timestamps)? I guess it makes some analysis easier and it avoids some data duplication at the cost of forcing the users of the API to do some more leg work than before.

If this is the case should we?

  1. Emphasize this point in the document?
  2. Throw an error in the API if they are not? (is that possible?)

I can volunteer to add a small section in the documentation about this as a good practice.

Am I missing something?

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

1 participant