-
Notifications
You must be signed in to change notification settings - Fork 140
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
Fix the schema for keypoint detection in workflows #946
base: main
Are you sure you want to change the base?
Conversation
@@ -227,7 +227,7 @@ class Keypoint(Point): | |||
description="Model confidence regarding keypoint visibility." | |||
) | |||
class_id: int = Field(description="Identifier of keypoint.") | |||
class_name: str = Field(field="class", description="Type of keypoint.") | |||
class_name: str = Field(alias="class", description="Type of keypoint.") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@PawelPeczek-Roboflow You likely know more about what is happening here much better than I do - I couldn't figure out why this was field=
instead of alias=
, but this adjustment seems to more closely match the data we are actually passing around.
Do you foresee any unintended consequences of making this change? I might also be completely wrong in my approach to fixing this bug, would appreciate your input 🙏
Description
This PR fixes what appears to be a bug in keypoint detection models used in Workflows using keypoint detection models due to the naming conventions in inference - here is a screen recording of the bug:
workflow-keyp.mp4
It appears that we use
class_name
andclass_id
naming conventions in most cases, but the baseKeypointsDetectionBaseOnnxRoboflowInferenceModel
usesclass
andclass_id
instead.Error message:
Type of change
Please delete options that are not relevant.
How has this change been tested, please provide a testcase or example of how you tested the change?
I need some help here - I'm not 100% sure what might be depending on the old schema, or whether this change to the object will break downstream code.
Any specific deployment considerations
Will this break anything depending on this old schema?
Docs
N/A