-
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
NN Archive Structural Update #82
Conversation
Would |
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
@type metadata: HeadMetadata | ||
@ivar metadata: Parameters required by head to run postprocessing. | ||
""" | ||
|
||
head_id: str = Field(description="Unique head identifier.") | ||
outputs: Union[List[str], Dict[str, Union[str, List]]] = Field( | ||
description="A list of output names from the `outputs` block of the archive or a dictionary mapping DepthAI parser names needed for the head to output names. The referenced outputs will be used by the DepthAI parser." |
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.
I assume only the outputs relevant to the head operations must be listed here? I'm wondering how to identify those from the perspective of automatic NN archive generation. We could try drawing them from cfg model architecture but this might not be so straight-forward as the NN archive outputs now became the outputs of the executable and might differ from names in cfg (as far as I know).
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.
@jkbmrz I was considering overriding outputs
for each HeadMetadata
or at least providing some validation on the expected format of outputs
for a given head. However, we would then need to define outputs
on the HeadMetadata
level (instead of Head
) or have one really long validtor in Head
(which I don't think is a good idea). If we move outputs
to HeadMetadata
, then we only have HeadMetadata
attributes and no attributes specific to Head
.
Thus, it might make sense removing HeadMetadata
entirely and just having all the head types inherit from Head
. Then, we overrride outputs
for each head, further defining its type and validating possible param names (in the outputs
keys). Thoughts on that idea?
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.
We could remove the HeadMetadata
class and have all the head types inherit from Head
but I'm still not sure how we would figure out automatically what outputs belong to a specific head. Or does overriding outputs
for each head means predefining?
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.
Commit 2dcc2c3 implements the idea
Test Results43 tests 43 ✅ 33s ⏱️ Results for commit f95efac. ♻️ This comment has been updated with latest results. |
☂️ Python Coverage
Overall Coverage
New Files
Modified Files
|
@conorsim Let's always store JSONs as nnarchive.json or config.json to keep it consistent as discussed offline? |
^ a small commit adding return statement to |
…s-ml into rework/nn-archive-updates
^ added support for LZMA compression and setting .tar.xz as the default nn archive option |
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 introduces the following changes to the NN archive structure from some iteration on what is needed for DepthAI:
HeadMetadata
for YOLO instance segmentation -HeadMetadataInstanceSegmentationYOLO
.stages
block and instead replace it withmodel
since any multi-executable NN cases will instead be handled byHead.metadata
. For example,HeadMetadataInstanceSegmentationYOLO
specifiespostprocessor_path
for the postprocessing step which uses a second blob to perform a multiplication operation.connections
block since we no longer havestages
.head_id
field in theoutputs
block and instead introduce aHead.outputs
block which can be more descriptive about the parameters required for a DepthAI parser.stride
parameter for object detection heads.anchors
for object detection heads to be a triply nested list. We assume it's always in the order of smallest to largest outputs.