Orientierte Objekterkennung

Definition

Die orientierte Objekterkennung ergänzt eine Erkennung um eine Zahl: den Winkel. Jede Instanz erhält ein gedrehtes Rechteck, eine Klasse und eine Bewertung. Der Vorteil ist die enge Begrenzung. Bei einem Schiff im Winkel von 45 Grad, einem Hallendach oder einer Reihe geparkter Lastwagen enthält eine achsenparallele Box größtenteils Hintergrund. Benachbarte Boxen überlappen sich, obwohl die Objekte es nicht tun. Deshalb ist die Aufgabe bei Luftbildern und Dokumentlayouts üblich und DOTA ihr Referenzdatensatz.

obb ist der kanonische Aufgabenschlüssel. Das Suffix -obb im Dateinamen eines Checkpoints wählt ihn aus, weshalb beim Laden veröffentlichter Gewichte kein task= erforderlich ist.

predict() befüllt result.obb. .xywhr ist die kanonische Form (N, 5): Mittelpunkt x, Mittelpunkt y, Breite, Höhe und ein Winkel im Bogenmaß für die Drehung der Breitseite um den Mittelpunkt. .conf und .cls enthalten Bewertung und Klassenindex in result.names, .id beim Tracking eine Tracking-ID. .xyxyxyxy wandelt jede Zeile in vier Eckpunkte als Pixel der Form (N, 4, 2) um, .xyxyxyxyn normalisiert diese Ecken und .xyxy liefert die umschließende achsenparallele Box. Verwende Letztere, wenn nachgelagerter Code nur Rechtecke versteht. result.boxes wird ebenfalls mit der achsenparallelen Form befüllt.

Modelle

Vier Familien decken diese Aufgabe ab.

RF-DETR unterstützt Training. Es unterstützt Vorhersage, Training, Validierung und Export orientierter Boxen und bietet veröffentlichte orientierte Checkpoints in vier Größen: n, s, m und l. Es benötigt sein eigenes Extra, pip install "libreyolo[rfdetr]"; seine Modellseite enthält die Gewichtslizenz und Herkunft.

Lies vor der Planung mit diesen Checkpoints den folgenden Abschnitt über ihre tatsächlichen Vorhersagen.

RT-DETRv2 bietet Gewichte für Luftbilder. Die Checkpoints LibreRTDETRv2n-obb.pt bis LibreRTDETRv2x-obb.pt sind die offiziellen, in das LibreYOLO-Format konvertierten Single-Scale-Checkpoints für DOTA v1.0. Sie decken die 15 DOTA-Klassen bei 1024 px ab. Neben dem Basispaket ist kein Extra erforderlich. Der orientierte Graph wird anhand der Tensoren des Checkpoints erkannt. Vorhersage, Validierung sowie Export nach ONNX und TorchScript werden unterstützt. Training wird nicht unterstützt. Die orientierte Aufgabe ist bei dieser Familie nur für die Inferenz vorgesehen, train() löst einen Fehler aus und eine Übertragung aus den Erkennungsgewichten mit anderem Backbone ist nicht möglich. Tracking und Test-Time Augmentation sind für orientierte Boxen ebenfalls nicht verfügbar.

Wähle den Labelsatz des Checkpoints und die Trainingsunterstützung passend zu deinem Datensatz.

YOLO-NAS unterstützt ebenfalls OBB-Training und -Inferenz. Seine vortrainierten Gewichte behalten die nichtkommerziellen Upstream-Bedingungen.

GTR veröffentlicht LibreGTRs-obb.pt und LibreGTRx-obb.pt, die die 15 Klassen von DOTA v1.0 bei einer festen Eingabegröße von 1024 vorhersagen. Es läuft mit dem Basispaket und unterstützt Vorhersage, Training, Validierung sowie Export nach ONNX und TorchScript.

Vorhersage

Die Gewichte werden bei der ersten Verwendung von Hugging Face heruntergeladen und lokal zwischengespeichert.

# Benötigt das rfdetr-Extra: pip install "libreyolo[rfdetr]"from libreyolo import LibreYOLO, SAMPLE_IMAGE # Das Suffix -obb im Dateinamen wählt die Aufgabe aus,# daher ist kein task-Argument erforderlich.model = LibreYOLO("LibreRFDETRs-obb.pt")result = model(SAMPLE_IMAGE, save=True) obb = result.obbprint(obb.xywhr)   # (N, 5): Mittelpunkt x, Mittelpunkt y, Breite, Höhe, Bogenmaßprint(obb.conf, obb.cls)

libreyolo predict model=LibreRFDETRs-obb.pt save=True \  source=https://raw.githubusercontent.com/LibreYOLO/libreyolo/release/libreyolo/assets/parkour.jpg

from libreyolo import LibreYOLO, SAMPLE_IMAGE result = LibreYOLO("LibreRFDETRs-obb.pt")(SAMPLE_IMAGE)obb = result.obb print(obb.xyxyxyxy.shape)    # (N, 4, 2) Eckpunkte in Pixelnprint(obb.xyxyxyxyn.shape)   # dieselben normalisiertprint(obb.xyxy.shape)        # (N, 4) umschließende achsenparallele Box

from libreyolo import LibreYOLO, SAMPLE_IMAGE model = LibreYOLO("LibreRFDETRn-obb.pt")result = model(SAMPLE_IMAGE) print(result.obb.xywhr.shape)

from libreyolo import LibreYOLO # DOTA-v1.0-Gewichte mit 15 Luftbildklassen bei 1024 px. Der orientierte Graph# wird anhand der Tensoren des Checkpoints erkannt, daher ist kein task-Argument nötig.model = LibreYOLO("LibreRTDETRv2n-obb.pt")result = model("aerial.png", save=True) obb = result.obbprint(obb.xywhr)print(result.names)   # plane, ship, harbor, helicopter und 11 weitere

Prüfe vor der Verwendung, was die veröffentlichten RF-DETR-Checkpoints enthalten. Obwohl DOTA der Referenzbenchmark für diese Aufgabe ist, wurden diese Gewichte nicht darauf trainiert. Alle vier wurden mit RF-DETR-Erkennungsgewichten initialisiert und auf einem einzelnen UAV-Videodatensatz mit sechs Fahrzeugklassen nachtrainiert: bike, bus, car, other_vehicle, taxi und truck. Ihre Modellkarten bezeichnen sie als Entwicklungsgewichte, die zur Validierung der Unterstützung für orientiertes Training entstanden sind, und ausdrücklich nicht als Produktionsgewichte oder offizielle Benchmarkgewichte.

In der Praxis sind sie ein funktionierender Ausgangspunkt für orientierte Boxen um Fahrzeuge aus der Vogelperspektive und zur Prüfung einer vollständigen Pipeline. Jede andere Domäne erfordert Training mit eigenen orientierten Labels. Für die bekannten Luftbildkategorien von DOTA wurden tatsächlich die RT-DETRv2-Checkpoints auf diesen Daten trainiert. conf und max_det formen die Ausgabe wie bei der Objekterkennung, und agnostic_nms=True unterdrückt überlappende Boxen klassenübergreifend über die gedrehte IoU. Unter Vorhersage findest du Informationen zu Quellen, Streaming und Ergebnisverarbeitung.

Datensatzformat

Die Struktur entspricht dem Erkennungslayout. Für jedes Bild gibt es eine .txt-Labeldatei. Ihr Pfad entsteht aus dem Bildpfad, indem images durch labels und die Dateiendung ersetzt wird.

dataset/  data.yaml  images/    train/P0001.png    val/P0101.png  labels/    train/P0001.txt    val/P0101.txt

Eine Zeile enthält exakt neun Felder: einen Klassenindex, gefolgt von vier geordneten Eckpunkten.

<class_id> <x1> <y1> <x2> <y2> <x3> <y3> <x4> <y4>

Die vier Punkte sind normalisierte Gleitkommazahlen in [0, 1] und müssen ein nicht degeneriertes orientiertes Rechteck bilden. Die Labeldatei speichert keinen Winkel. Der Loader leitet die kanonische Form xywhr aus den Ecken ab. Standardmäßig ist der Parser streng und lehnt Koordinaten außerhalb des Bereichs ab. Bei der Aufnahme für Datensatz und Validierung dürfen anderweitig gültige Labels an Beschnittgrenzen zunächst auf [0, 1] begrenzt werden. Degenerierte Boxen werden weiterhin abgelehnt.

Die Zeilenanalyse berücksichtigt die Aufgabe. Neun Felder bezeichnen nur im Modus obb eine orientierte Box. Im Modus segment wird dieselbe Zeile als Polygon mit vier Punkten gelesen.

Die YAML-Datei entspricht der Erkennungs-YAML:

path: datasettrain: images/trainval: images/valnames:  0: plane  1: ship

Natives COCO-JSON wird mit einer Zuordnung annotations von Splitnamen zu JSON-Dateien ebenfalls geladen. Annotationen werden in folgender Priorität gelesen: ein Feld obb mit acht Ecken im Pixelraum, ein Feld obb als [cx, cy, w, h, angle] mit Winkel im Bogenmaß, ein segmentation-Polygon oder RLE, das an sein flächenkleinstes Rechteck angepasst wird, oder eine gewöhnliche COCO-bbox. Letztere wird als achsenparalleles Rechteck behandelt und zu xywhr kanonisiert.

Der kanonische Zeilenparser heißt libreyolo.data.parse_yolo_obb_label_line.

Training

from libreyolo import LibreYOLO # Setzt veröffentlichte orientierte Gewichte fort. data muss auf einen# Datensatz mit vier Ecken je Labelzeile verweisen.model = LibreYOLO("LibreRFDETRs-obb.pt")model.train(data="my-obb-dataset.yaml", epochs=50, imgsz=512, batch=8, lr0=1e-4)

libreyolo train model=LibreRFDETRs-obb.pt data=my-obb-dataset.yaml \  epochs=50 imgsz=512 batch=8 lr0=1e-4

# Erkennungsgewichte sagen keinen Winkel vorher, daher ist dies eine ausdrückliche# Übertragung. Die Angabe task=obb autorisiert sie.libreyolo train model=LibreRFDETRs.pt data=my-obb-dataset.yaml \  task=obb epochs=50 imgsz=512

RF-DETR setzt das Training standardmäßig mit einem veröffentlichten -obb-Checkpoint fort. Der Start mit Erkennungsgewichten ist ein bewusster Transfer: Diese Gewichte sagen keinen Winkel vorher, und task=obb erlaubt den Wechsel. Halte lr0 wie bei den anderen Aufgaben der Familie bei höchstens 1e-4. Die orientierten Checkpoints von RT-DETRv2 lassen sich nicht nachtrainieren; verwende sie unverändert oder trainiere ein RF-DETR-Modell mit deinen eigenen Labels. Siehe Training für Datensätze, Augmentierung, Multi-GPU und Logger.

YOLO-NAS OBB verwendet gedrehte Zuordnung und Losses, Spiegelungs-/HSV-Augmentierung sowie standardmäßig amp=False. Es wählt Checkpoints anhand von metrics/mAP50-95(OBB).

Validierung

val() gibt ein einfaches Dictionary mit metrics/-Schlüsseln zurück. Die Zuordnung verwendet Rotated IoU zwischen orientierten Rechtecken statt zwischen ihren achsenparallelen Hüllen. Eine Vorhersage mit korrekter Position und falschem Winkel wird dadurch als Fehler bewertet.

from libreyolo import LibreYOLO model = LibreYOLO("LibreRFDETRs-obb.pt") # val() gibt ein einfaches Dictionary und kein Objekt zurück.metrics = model.val(data="my-obb-dataset.yaml") print(metrics["metrics/mAP50-95"])print(metrics["metrics/mAP50"], metrics["metrics/mAP75"])print(metrics["metrics/precision"], metrics["metrics/recall"])

libreyolo val model=LibreRFDETRs-obb.pt data=my-obb-dataset.yaml

libreyolo val model=LibreRTDETRv2n-obb.pt data=my-obb-dataset.yaml

metrics/mAP50-95 ist die Mean Average Precision über IoU-Schwellenwerte von 0,50 bis 0,95 in Schritten von 0,05 und die wichtigste Kennzahl. Anders als der COCO-Pfad der Objekterkennung berücksichtigt diese Aufgabe iou_thresholds in der Validierungskonfiguration. Der Durchlauf lässt sich daher ändern. metrics/mAP50 und metrics/mAP75 sind Varianten bei einem einzelnen Schwellenwert. metrics/precision und metrics/recall sind echte Precision und Recall bei IoU 0,50 am lockersten Arbeitspunkt. Jede Vorhersage oberhalb des Konfidenzschwellenwerts wird gezählt. Während der Validierung ist dieser standardmäßig 0,001. Eine Erhöhung von conf verändert diese Werte, während die über die gesamte Precision-Recall-Kurve berechneten mAP-Werte gleich bleiben. Vier Werte wiederholen sich mit dem Suffix (OBB): metrics/mAP50-95(OBB), metrics/mAP50(OBB), metrics/precision(OBB) und metrics/recall(OBB). So kann ein Aufrufer ein orientiertes von einem achsenparallelen Ergebnis in derselben Tabelle unterscheiden. metrics/mAP75 besitzt keinen Alias mit Suffix.

Zwei Optionen haben bei dieser Aufgabe keine Wirkung. save_json und save_plots werden akzeptiert und protokollieren eine Warnung. Dumps orientierter Vorhersagen und Validierungsdarstellungen sind nicht implementiert. agnostic_nms=True löst hier ValueError aus; es deckt nur die Validierung von detect und segment ab.

Export

from libreyolo import LibreYOLO model = LibreYOLO("LibreRFDETRs-obb.pt")model.export(format="onnx", imgsz=512)

libreyolo export model=LibreRFDETRs-obb.pt format=onnx imgsz=512

# ONNX und TorchScript sind hier die validierten Ziele bei FP32,# Batchgröße 1 und einem festen Canvas von 1024 mal 1024.libreyolo export model=LibreRTDETRv2n-obb.pt format=onnx imgsz=1024libreyolo export model=LibreRTDETRv2n-obb.pt format=torchscript imgsz=1024

from libreyolo import LibreYOLO, SAMPLE_IMAGE # Die Factory leitet anhand der Dateiendung weiter. Ein exportiertes Artefakt# wird wie ein Checkpoint geladen und gibt dasselbe Results-Objekt zurück.model = LibreYOLO("LibreRFDETRs-obb.onnx")result = model(SAMPLE_IMAGE) print(result.obb.xywhr)

Ein exportiertes Artefakt wird über seine Dateiendung wieder durch LibreYOLO() geladen. Eine .onnx- oder .engine-Datei verhält sich daher wie ein Checkpoint und gibt dasselbe Results-Objekt zurück. Die Formatabdeckung unterscheidet sich bei derselben Familie je Aufgabe. Die Matrix auf der Modellseite wird aus der validierten Menge generiert und nennt den Grund, wenn ein Ziel nicht verfügbar ist. Unter Export und Deployment findest du Formate, Extras und Einschränkungen.