-
Notifications
You must be signed in to change notification settings - Fork 0
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
Vehicle attributes parser #67
Conversation
Test Results143 tests 143 ✅ 1s ⏱️ Results for commit b1d42d5. ♻️ This comment has been updated with latest results. |
☂️ Python Coverage
Overall Coverage
New Files
Modified Files
|
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.
LGTM, I would just like us to think a bit if there is a way to use more general message types instead of custom ones. Because for example create_vehicle_attributes_message
(and also VehicleAttributes
) are very model specific. These message are nice from the standpoint of user experience (e.g. can get type just by looking at .vehicle_type
) but in the longrun this means custom message for every model that is a bit different (e.g. one that predicts brand instead of type).
In general this is a multi-classification model. What if we have a message MultiClassification
and its data would be a dict[str, Classification]
(mapping between attribute name and it's Classification - scores and class names)? Or perhaps even more composited message type which has dict[str, dai.Buffer]
which could be used for this case and also for something like AgeGender?
The drawback of this approach is that these composited types wouldn't have attributes accessable straight on but would have them in a dictionary -> no autocomplete, not that clean,... But I fear that we'll have to create very specific message types for some specific models if we continue down this path.
What are your thoughts on this? Do you have any other possible solutions? (also CC: @kkeroo , @jkbmrz for thoughts)
I agree with what @klemen1999 wrote and would go with the second option he proposed:
I don't think these models will be so common anyways so the drawbacks wouldn't be too annoying and its much nicer to have a clean library than a multitude of custom messages/parsers. |
I had the same concerns. I can refactor the code maybe as MultiOutputMessage with data dict[string, [dai.Buffer, float, str, np.ndarray] and then we can make subclasses MultiClassification, AgeGender, ..., Anything that has more than one output? Because AgeGender isnt multi classification but one classification one regression. |
I dont like I would also generalize your parser, instead of VehicleAttributesParser you can name it MultiClassifcaitonParser and then map the tensor to the names inside the init:
and this can then be set via |
Okay I will change accordingly to multiclass and also update nn_archive to incorperate multiple heads. |
Agree, since we sacrifice in type hints we should then profit in the lesser amount of custom messages needed (try to keep only strong ones). This MultiOutputMessage could be then built in the parser itself: if we take AgeGender for example parser creates a Classification message for gender and float for age, we package this into MultiOutputMessage and return it (similarly for vehicle model we can have 2 Classification messages packaged together). Does this make sense? |
Changed to MultiClassification Parser. Also made a Miscellaneous message that only saves a dictionary. The dictionary can only have values dai.Buffer, float or np.ndarray. To get the dictionary you can call .getData() method thats overwritten from the dai.Buffer class. Therefore at least some autofill is present when using the parser/message. |
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.
create_age_gender_message
and AgeGender
will also need to be changed accordingly but we can do that in a separate PR. LGTM otherwise.
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.
LGTM
This PR adds a
VehicleAttributesParser
that is used for vehicle-attributes-classification:72x72 . The model has two classification outputs:The parser returns a message with attributes
vehicle_type
andvehicle_color
each being a Tuple like(class, probability)
of the class with the highest probability.