-
Notifications
You must be signed in to change notification settings - Fork 78
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
Keypoints kind #401
Comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Following up below code review comment:
[loud thinking] I am generally in favour of having
sv.Detections
for all detections-based use cases, butsupervision
itself seems to diverge from that idea. In the latest release we got new abstraction sv.KeyPoints which do not hold bboxes, and is invariant on "different skeleton for different class" topic - which makes it not 100% suitable for our usage now.I propose to keep as is for now, but we need to have discussion what to do next - definitely we need support for multiple skeletons (this is in general good change for
supervision
as this makes the abstraction more robust), but I would say that's suboptimal to loose info about Bounding Boxes when model provides them - maybe we could have both data outputs later in the future - one of Object Detection kind and another of Keypoints kindOriginally posted by @PawelPeczek-Roboflow in #392 (comment)
The text was updated successfully, but these errors were encountered: