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

Initial implementation of a PoseTraining Group #9

Merged
merged 6 commits into from
Aug 1, 2023
Merged

Conversation

roomrys
Copy link
Collaborator

@roomrys roomrys commented Jul 27, 2022

Description

Add PoseTraining group to store annotations for training a pose estimator.

Related Issues

Copy link

@CBroz1 CBroz1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor suggestions. Added specificity regarding instances of skeletons. In all the cases I've seen, subject would work just as well, but instance works as more generic.

spec/ndx-pose.namespace.yaml Show resolved Hide resolved
spec/ndx-pose.namespace.yaml Show resolved Hide resolved
src/spec/create_extension_spec.py Outdated Show resolved Hide resolved
spec/ndx-pose.extensions.yaml Outdated Show resolved Hide resolved
src/spec/create_extension_spec.py Outdated Show resolved Hide resolved
src/spec/create_extension_spec.py Outdated Show resolved Hide resolved
src/spec/create_extension_spec.py Outdated Show resolved Hide resolved
src/spec/create_extension_spec.py Outdated Show resolved Hide resolved
spec/ndx-pose.extensions.yaml Outdated Show resolved Hide resolved
src/spec/create_extension_spec.py Outdated Show resolved Hide resolved
- name: path
dtype: text
doc: Path to original video file.
required: false
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this and frame_index be optional? If a source_video is provided, it seems like a path and frame index should be provided.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The logic of requirement I think was to be applied to the entirety of the source_video attribute. Combined logic being the user either links source_video to an ImageSeries (internal or external storage) plus the frame index used and then they also specify the source_frame as a standalone Image (ideally internal or external, but see other comments regarding that). Hence source_frame is required, but the video it was extracted from is optional (but ideal) provenance.

So should the required logic apply to source_video directly then?

Copy link
Collaborator Author

@roomrys roomrys Sep 27, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We wanted to provide two ways for supplying the training frame - either as a frame index given the path to the source video (source_video) or as a standalone image (source_frame). Hence why neither are required although at least one must be supplied.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we are confusing two different things here. I get that source_video is optional. If source_video is provided, then because the path and frame_index fields are optional, then the user does not have to provide either. From what you have both written, I think if source_video is provided, then path and frame_index should also be required, and we can specify that by removing required: false from both attributes.

Comment on lines 155 to 158
- name: source_frame
neurodata_type_inc: Image
doc: Image frame used for training (stored either internally or externally).
quantity: '1'
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that currently the Image type supports only images stored internally. Also quantity: 1 is fine to include, but it is the default when no quantity is provided, so we tend to omit it.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From the past discussion, internally saving is the preferred approach since there could be thousands of external files otherwise.

However, maximal freedom for the user is also desired - would it be appropriate to extend the Image neurodata type in this extension to allow an external mode or should we alter that in the core instead?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I created an issue NeurodataWithoutBorders/nwb-schema#529 on the topic. This is part of a larger discussion over how we want to support storing external files in NWB.

@rly
Copy link
Owner

rly commented Jul 28, 2022

These changes look good to me, and I support @CBroz1 's changes. It would be good to get feedback from @bendichter and @AlexEMG on these changes before we proceed.

Copy link
Collaborator

@bendichter bendichter left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@roomrys , could you look through these suggestions when you have time? This extension looks like it is really quite close to complete

spec/ndx-pose.extensions.yaml Show resolved Hide resolved
@CBroz1
Copy link

CBroz1 commented Sep 26, 2022

Hi @roomrys, Hi @rly - I'd like to get this merged to use with a DataJoint NWB export. Should I open a separate PR to reflect the changes we discuss here?

Comment on lines 157 to 159
- name: source_frame
neurodata_type_inc: Image
doc: Image frame used for training (stored either internally or externally).
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @CBroz1, @rly,

I believe all the changes have been address (except for Image only allowing externally stored images and our current docs incorrectly say "stored either internally or externally"). With source_video linked to an ImageSeries, I believe we may not even need the source_frame group as we can directly supply a collection of images. However, the images supplied for training are rarely in a sequential format (and may therefore be an incorrect use of ImageSeries which extends TimeSeries).

The problem: We would like to store non-sequential images internally. ImageSeries allows images to be stored internally, but expects them to be sequential. Image allows images to be non-sequential, but requires them to be stored externally.

@CodyCBakerPhD had suggested making a change to the Image datatype to allow this. Is this feasible? Is there another workaround? Should we just hack ImageSeries for our purposes?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In NWB 2.5.0, we recently revamped the Images neurodata type, which represents a collection of images that may or may not be ordered. The IndexSeries neurodata type supports references to an Images type. This type seems like a better fit for the use case.

And to be clear, Image requires images to be stored internally and does not support external storage. External storage of individual images is not currently supported, but we can add that if we need to. External storage of movies is supported through ImageSeries.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, great. I swapped the Image data type for the Images data type and added an images_index attribute to pull out a specific frame from the Images collection.

spec/ndx-pose.extensions.yaml Outdated Show resolved Hide resolved
@roomrys
Copy link
Collaborator Author

roomrys commented Oct 11, 2022

Hi @rly,

I believe all is ready! Please let me know if there is anything else that needs work.

@talmo
Copy link
Contributor

talmo commented Jul 17, 2023

Hey friends, where do we stand with this PR these days @rly @bendichter?

@rly
Copy link
Owner

rly commented Jul 21, 2023

Hi @talmo . Sorry for the extreme delay on wrapping up this PR... I will finalize this during the developer hackathon next week.

@talmo
Copy link
Contributor

talmo commented Jul 26, 2023

Let us know if there's anything we can help with! This is a key piece of functionality for us to be able to convert our hand labeled data for archival :)

@rly
Copy link
Owner

rly commented Jul 29, 2023

@roomrys Could you please enable edits to this PR / branch from maintainers? There should be a checkbox on the right side. I would like to give you credit for this PR if possible.

@roomrys
Copy link
Collaborator Author

roomrys commented Aug 1, 2023

Sorry @rly, it seems that is impossible at the moment https://github.com/orgs/community/discussions/5634

@talmo
Copy link
Contributor

talmo commented Aug 1, 2023

@rly what if you send a PR with your changes to talmolab:main, we merge it there, and then it updates here?

Or we could follow the above thread's response:

HELP! Please fix this, or we shall move to svn 🥲

😂😂

@talmo
Copy link
Contributor

talmo commented Aug 1, 2023

Or maybe add @roomrys as a maintainer to the repo? Or @roomrys add @rly as a maintainer to our fork so the checkbox works?

@rly
Copy link
Owner

rly commented Aug 1, 2023

Sounds good. Will do.

@rly what if you send a PR with your changes to talmolab:main, we merge it there, and then it updates here?

@rly
Copy link
Owner

rly commented Aug 1, 2023

Or maybe add @roomrys as a maintainer to the repo? Or @roomrys add @rly as a maintainer to our fork so the checkbox works?

I'll add @roomrys to the repo in case that helps but I think adding me to the fork would work.

@rly
Copy link
Owner

rly commented Aug 1, 2023

Sounds good. Will do.

@rly what if you send a PR with your changes to talmolab:main, we merge it there, and then it updates here?

It turns out that GitHub does not allow me to fork a fork of my repo.

image

@rly
Copy link
Owner

rly commented Aug 1, 2023

I will just merge this and make changes in a new PR. Thanks for the contribution @roomrys , @CBroz1 , and @CodyCBakerPhD !

@rly rly merged commit b5d91bb into rly:main Aug 1, 2023
@rly rly mentioned this pull request Nov 22, 2023
7 tasks
@talmo talmo mentioned this pull request Aug 16, 2024
4 tasks
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

Successfully merging this pull request may close these issues.

7 participants