feat(model): Add YOLO26 support

[richard-xx]

Purpose

Added Yolo26 export support

Specification

None / not applicable

Dependencies & Potential Impact

None / not applicable

Deployment Plan

None / not applicable

Testing & Validation

None / not applicable

[dtronmans]

Hello Richard,

Thank you for your quick contribution by adding YOLO26 support! Since YOLO26 inference is end-to-end and bypasses post-processing steps like DFL and NMS, we opted for pruning the model in a way that takes advantage of the native one-to-one detection heads.

That means that, instead of relying on the previous cv2 and cv3 heads (and cv4 heads for masks and keypoints), we opted for using the new end-to-end one2one_cv2 and one2one_cv3 heads, which required us to add and a new exporter. This also means that we rely on a single, directly regressed output rather than the traditional three outputs from the FPN. Your implementation is completely correct, however using the old heads and three outputs means that NMS still has to be performed, whereas NMS-free inference is an aspect of YOLO26 that we are trying to leverage in our repositories.

For now, a YOLO26 model can be exported through the main branch of this repository, converted on HubAI and run on the main branch of depthai-nodes (in this case, it can be run without changes in the generic-example tutorial). Over the next few weeks, our next release cycle will make the full YOLO26 end-to-end conversion available on HubAI.

Thanks again for your contribution and your efforts, and I’m happy to answer any questions or discuss this further.

[richard-xx]

@dtronmans I understand. I just want to confirm whether YOLO26 exported from the main branch supports the standard API, instead of using depthai-nodes.

[klemen1999]

Hi @richard-xx ,
What do you mean by standard API in this context?
The support that was currently merged in main is compatible with YOLOExtendedParser that is currently merged in depthai-nodes main branch. This is using the one-to-one version of YOLOv26 which eliminates the need for NMS postprocessing.
Your PR treated YOLOv26 as one-to-many (similarly as e.g. YOLOv8) and if you exported that way then this also already works with existing YOLOExtendedParser or depthai native DetectionParser but it does require NMS to be ran by the parser.
The direction we took was purely because we wanted to utilize this NMS free version of the model which leads to less postprocessing overhead. But the version with NMS needed also works.
Hopefully this clears thins up a bit more but if you have any questions feel free to bring them up.
Best,
Klemen

[richard-xx]

I apologize for not being clear earlier. The standard API refers to the use of the DetectionNetwork in depthai, similar to the example found at https://github.com/luxonis/depthai-core/tree/main/examples/python/DetectionNetwork.

[klemen1999]

I apologize for not being clear earlier. The standard API refers to the use of the DetectionNetwork in depthai, similar to the example found at https://github.com/luxonis/depthai-core/tree/main/examples/python/DetectionNetwork.

Currently your implementation will work with DetectionNetwork where as the one merged in main will not yet. Though we are working to having it supported soon also in native DetectionNetwork (most likely in one of the next DepthaiV3 releases). Until then you can either export it "your way" and have it working with DetectionNetwork (but this includes NMS postprocessing that is not really needed) or for the time being use YOLOExtenedParser from depthai-nodes main branch instead (e.g. with ParsingNeuralNetwork example)