Why does OpenCV's net.forward() with no argument miss a detector's outputs?

## What "output" means to the DNN module After import, an OpenCV `Net` is a directed graph of layers. Some layers feed other layers; the ones whose output nothing consumes are the network's **unconnected output layers**. A classifier has exactly one. An SSD detection head has one. A Darknet YOLOv3 or YOLOv4 graph has three, one per detection scale, and each produces predictions for a different range of object sizes. ## The overload that catches people There are two shapes of the call: - `net.forward()` or `net.forward(outputName)` — returns a **single** blob. With no name, it computes the whole network and returns the first output. With a name, it computes up to that layer and returns its blob. - `net.forward(outBlobNames)` — takes a sequence of layer names and returns a **list** of blobs, one per name, in that order. The single-blob form is the one every tutorial opens with, so it is the one that gets pasted into a multi-head pipeline. Nothing raises. You get a valid array, you parse it correctly, you draw correct boxes — and small objects, or large ones, simply never appear. The bug reads as a model-quality problem, which is why it can survive a long time. ## Getting the names right The direct API is: ``` names = net.getUnconnectedOutLayersNames() outs = net.forward(names) ``` Older sample code predates that helper and does this instead: take `net.getLayerNames()`, take `net.getUnconnectedOutLayers()`, and index the first with the second. The catch is that the layer indices returned there are **1-based**, so the correct lookup subtracts one. Copies of this snippet float around both with and without the subtraction, and the version without it either throws an index error or, worse, picks the wrong layers. `getUnconnectedOutLayersNames()` exists precisely to remove that class of bug — prefer it and the question disappears. ## Parsing a list of outputs With three YOLO heads you get three arrays, each `(num_boxes, 5 + num_classes)` rows for that scale. The standard postprocessing loops over all three, thresholds by confidence, converts the normalised centre-form boxes to pixel corner-form, and accumulates one flat candidate list — and only then applies non-maximum suppression **across the combined list**. Running NMS per output blob is a second, subtler version of the same bug: the same object detected at two scales produces two overlapping boxes that never get compared, so duplicates survive into the final result. ## Where else the multi-output form matters - **Multi-task networks** — a model with both a segmentation mask and a classification head. - **Text detection models** with separate score and geometry outputs, where you need both blobs to reconstruct boxes. - **Debugging a port** — passing one intermediate layer name lets you compare that activation against the original framework and bisect where the two diverge. ## The higher-level escape hatch If the ceremony is not adding value, OpenCV ships wrapper classes over `Net` — `cv2.dnn.DetectionModel` is the relevant one — that take `setInputParams(scale, size, mean, swapRB)` and expose `detect(frame, confThreshold, nmsThreshold)` returning class ids, confidences and boxes. They handle the multiple output blobs, the coordinate conversion and the suppression internally. The tradeoff is the usual one: less code and fewer places to get it wrong, against less control when a model's output layout does not match what the wrapper assumes. Knowing both paths, and why the low-level one has this trap, is what the question is really probing.