Reuse YOLO weights on YOLOv3: what carries over and what breaks

You have a YOLOv2-era detector trained on your own parts, and the next build release moves to YOLOv3. The question that sets your schedule is what carries over. The answer splits cleanly: the training data — images, per-image annotation files, class order, holdout split — reuses untouched, while the weights file does not, because the layer layout changed underneath it. This page gives the architecture numbers behind that split, the arithmetic that has to match in the cfg, the anchor decision, and a retraining plan that starts from the official YOLOv3 weights so the run converges in hours rather than days. It is written for anyone migrating an in-house darknet detector onto factory vision hardware.

What changed between YOLOv2 and YOLOv3

YOLOv2 runs a Darknet-19 backbone and a single detection head: at 416 × 416 px input it predicts five boxes on a 13 × 13 grid, so 13 × 13 × 5 = 845 boxes per frame, each with five coordinate-and-confidence values plus a score per class. The original 2016 release was narrower still: 7 × 7 × 2 = 98 boxes at 448 × 448 px, with no anchors at all.

YOLOv3 swaps in the Darknet-53 backbone and puts three heads on 13 × 13, 26 × 26 and 52 × 52 grids, nine anchors in total, three per head. At the same 416 × 416 px input it predicts 507 + 2,028 + 8,112 = 10,647 boxes per frame — 12.6 times more candidates — and the 52 × 52 head is what lifts recall on small features. Every number above is fixed by the published architecture, not by your dataset.

Why the old weights file will not load

A darknet weights file is not a structured container. It is a flat dump of each layer's parameters, written in cfg order, four bytes per value, with no layer names or shapes inside. The loader reads those bytes sequentially against whatever architecture the cfg in front of it describes. Point a YOLOv3 cfg at a v2 file and the load breaks early: the backbones differ (19 convolution layers versus 53), and every head shape differs. A build that skips the length checks is worse — everything after the first misaligned layer is noise, and the model fails quietly on the line.

The head arithmetic shows there is nothing to map. For two classes, a v2 head convolution outputs 5 × (2 + 5) = 35 values per cell; a v3 head convolution outputs 3 × (2 + 5) = 21. No documented converter exists, and a byte-level shim you write yourself would need re-verification for every class count and checkpoint — a cost well above the fine-tune it tries to avoid.

For loading failures that hit even valid v3 weights — wrong paths, truncated downloads, cfg mismatches — the darknet custom-weights troubleshooting checklist walks the usual causes and fixes.

What carries over: dataset, class list and holdout

The expensive asset survives whole. YOLO's dataset format is per image: one same-named text file per image, one row per object, each row holding the class index and the box centre x, centre y, width and height normalized to the image. Nothing in that format knows which network reads it, so YOLOv3 consumes it unchanged.

Preserve three things:

• Class order. Each row's class index points into your names list. Keep the order identical between the v2 and v3 runs, or a renumbered list silently relabels every box.
• The v2 reference model. Archive the old weights, cfg and a logged metric until the v3 model beats them on the same holdout.
• The holdout split. Score both models on the same validation images, or the comparison proves nothing.

If your boxes live in a labeling tool's CSV or JSON export, convert once to the per-image text files and make that the master copy: the CSV-to-YOLO conversion pitfalls and the JSON bounding-box conversion cover both routes. Tight, consistent boxes matter twice over in a fresh run; the occlusion labeling guide shows where loose boxes come from.

The arithmetic that has to match

Four numbers change at migration, and all four come from the architecture, not from your data. The cfg is the plain-text architecture file that sits beside the weights.

• Class count. It is set once per detection head — three places in a v3 cfg against one in v2.
• Filter count. The convolution immediately before each of the three heads must output 3 × (classes + 5) values; at 80 classes that is 3 × 85 = 255, which is why stock v3 cfgs print 255 on those layers.
• Training length. Two thousand iterations per class with a 6,000 floor is the working rule across darknet training guides; it sizes the compute budget before you commit a server.
• Anchors. Nine pairs, three per head, against five in v2. The stock nine are tuned for COCO-scale objects.

Worked example: two classes, 2,000 images

A socket head and a flange, 2,000 labeled images, the v2 model trained at 416 × 416 px — here is the full migration arithmetic:

• v2 head: 5 × (2 + 5) = 35 values per cell, 13 × 13 × 5 = 845 boxes per frame.
• v3 head: 3 × (2 + 5) = 21 values per head convolution, 63 across three heads, 10,647 boxes per frame. Check: 10,647 ÷ 845 = 12.6 times the candidates.
• Training length: max(6,000, 2,000 × 2) = 6,000 iterations.
• Size check: the official COCO-trained v3 file is about 248 MB; 248 MB ÷ 4 bytes ≈ 62 million parameters, almost all in the backbone your two-class model keeps, so expect the trained custom file near the same size.

Start the run from the official COCO weights — the published files run 237–248 MB — not from random initialization. Try the stock nine anchors first for these part sizes; recompute from your own boxes with nine clusters only if the 52 × 52 head keeps missing small features.

Retraining plan: pretrained start, fine-tune, validate

1. Freeze the dataset. Count images against annotation files; in the example both must read 2,000. A missing text file silently drops that image from training.
2. Write a fresh v3 cfg. Set the class count in all three heads and the filter arithmetic on each head's preceding convolution. Do not copy v2 hyperparameters across: five anchors and a single head do not translate.
3. Initialize from the official YOLOv3 COCO weights. Standard darknet builds copy layers until the first shape mismatch — the backbone — and random-start the heads, so general features come free while the heads learn your classes.
4. Fine-tune at a lower initial learning rate than a from-random run needs, and stop when the reported average loss flattens.
5. Validate on the untouched holdout at a fixed criterion — recall at IoU 0.5 is the common default — before the model goes anywhere near the line.

If the run dies partway with an out-of-memory error, that is the GPU memory budget, not the migration; the segmentation fault and CUDA fixes article covers the usual levers. For the hardware logic behind that budget, why GPUs beat CPUs for deep learning training gives the arithmetic. More migration-adjacent mechanics live on the systems topic hub.

Where the model runs: training server and line-side inference

Keep training off the production cell. Train on a dedicated GPU server, export, then deploy to the inference terminal that drives the station:

The MV-TS1004-256GR-960G16TR10 is the quad-GPU AI training server in the vision controller family, with 2 LAN ports and 3-4 USB 3 ports — sized for retraining jobs, not for the line.

On the line, an inference terminal reads the cameras, drives the lights and returns a verdict each cycle:

The dual-card MV-VAC5724-256G02 carries PoE camera ports, 5+ LAN ports, 5+ USB 3 ports and 8 built-in channels; the single-card MV-VAC3504X-128G01 covers smaller stations with 5+ LAN ports, 3-4 USB 3 ports and 4 built-in channels. Both leave the GPU free for inference while the CPU side handles acquisition and PLC traffic.

Two deployment details bite after migration: the exported model must see exactly the training preprocessing, or confidence drops for no visible reason — the preprocessing mismatch article shows the failure pattern — and runtime libraries on the edge device need version pinning, covered in the edge inference crash fix.

When "retrain from scratch" is the wrong emphasis

The classic short answer — different models, no compatibility, start over — is correct about the weights and misleading about the work. In practice "start over" means a fresh network initialized from the COCO-trained file: your 2,000 images, class list and holdout all carry forward, and the pretrained backbone contributes general features from iteration one. Against the original v2 run, which had to learn those features itself, the v3 fine-tune converges in a fraction of the iterations.

Two other places the usual advice misleads. A converter script is a dead end, for the head-semantics reasons above. And carrying v2 expectations across — a 35-value head, five anchors, one grid — produces a v3 cfg that cannot train. The honest limit: YOLOv3 buys small-object recall, not label quality; if the v2 model failed on ambiguous parts, migration will not fix the labels, the illumination or the boxes.

When the plan is set, browse smart cameras and the smart camera finder for the acquisition side, use the vision controllers category for the training-and-inference pair, or contact the applications team to size the run against your dataset.