EngineOutput to normalize engine outputs

[dtronmans]

Purpose

• Two main abstractions: EngineOutput (parser-facing, now the parsers have no information regarding which backend is supplying them) and TensorSpec / ModelSpec for resolved model I/O metadata.
• ONNX engine and depthai engine now both return EngineOutput instead of their raw data they were previously returning (raw tensors or dai.NNData) and new implemented engines have to adapt this.
• parsers now consume EngineOutput + ModelSpec: no longer dependent on engine-specific raw output types
• luxonis-eval parsers call the compute() function of parsers in depthai-nodes instead of hand-written computation logic
• Relies on this depthai-nodes code
• Added example configs for the main tasks (keypoints, detection, semantic segmentation, classification)

Set to draft: 1) depends on depthai-nodes PR and 2) I need to generate different models by training them with LuxonisTrain, converting them to ONNX NNArchive and RVC4 NNArchive (FP16) and making sure the results are coherent between luxonis_train test ... and luxonis_eval eval .... Although this PR is supposed to only be architectural shouldn't change anything functionally, this is just to make sure since the computation now relies on the depthai-nodes parsers' compute. Then we can use these .ckpt/.onnx.tar.xz/.rvc4.tar.xz files later on for automatic E2E/regression testing.

Specification

None / not applicable

Dependencies & Potential Impact

None / not applicable

Deployment Plan

None / not applicable

Testing & Validation

None / not applicable

AI Usage

Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]

Submitted code was reviewed by a human: YES/NO

The author is taking the responsibility for the contribution: YES/NO

[coderabbitai]

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 0315b05b-970d-477c-aaf7-4c0588bb683b

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/abstract-engines

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[klemen1999]

I think it makes sense to define these classes in the respective engine files for better visibility (e.g. if I would go implement my own engine I would see right away some references for engine output classes)

[dtronmans]

Good point, I moved the ONNXEngineOutput and DepthaiEngineOutput to their respective classes in e7bc102. Also a bit of a stylistic choice but in this same commit I also added a requirement that each engine should be assigned an EngineOutput as a class attribute a bit like how some LuxonisTrain heads can be assigned a parser, but this time it throws an error if it is not implemented.

[klemen1999]

Generally I'd rename the parsers to match 1:1 to depthai-nodes parsers. This would also mean then that we wouldn'thave detection.py instance_seg.py and keypoint_detection.py. Instead there would only be yolo.py which would have YOLOExtendedParser class defined (and would use depthai-nodes YOLOExtendedParser.compute() internally)

[dtronmans]

Good point, I renamed SemanticSegmentationParser to SegmentationParser and the three YOLO parsers are collapsed into a single YOLOExtendedParser in 52b82a1. One thing to note now though is that there is no more "task selection" through the parsers in luxonis-eval and this is done through the depthai-nodesYOLOcompute()which determines the task based on the output tensor names. I think this is fine since we want the flow to be as similar to the normaldepthai-nodes` flow, just something worth noting though.