libreyolo export

Składnia

libreyolo export model=<name|path> [format=<format>] [key=value ...]

Argumenty to pary key=value, działa też forma POSIX, więc format=onnx i --format onnx to ten sam argument.

Argumenty

engine to alias dla tensorrt, a litert alias dla tflite. Oba są rozwiązywane do nazwy kanonicznej, zanim cokolwiek zostanie zapisane, więc wynik JSON i linia logu zawsze podają tensorrt lub tflite.

Przykłady

# Zapisuje weights/LibreYOLO9s.onnxlibreyolo export model=LibreYOLO9s.pt format=onnx imgsz=640

libreyolo export model=LibreYOLO9s.pt format=onnx \  nms=true conf=0.25 iou=0.45 max_det=300

libreyolo export model=LibreYOLO9s.pt format=onnx imgsz=640 # Fabryka rozpoznaje sufiks pliku, więc eksport wczytuje się jak checkpoint.libreyolo predict model=weights/LibreYOLO9s.onnx \  source=https://raw.githubusercontent.com/LibreYOLO/libreyolo/release/libreyolo/assets/parkour.jpg

Uwagi

Gdzie trafia plik

Polecenie nie przyjmuje ścieżki wyjściowej. Artefakt jest zapisywany w weights/, a jego nazwa to rdzeń nazwy źródłowego checkpointu plus sufiks formatu, z wstawionym _fp16 lub _int8, gdy zażądano jednej z tych precyzji. LibreYOLO9s.pt wyeksportowany do ONNX w FP16 staje się weights/LibreYOLO9s_fp16.onnx. Wynik JSON zawiera rozwiązaną wartość output_path, rozmiar pliku w MB oraz kształt wejścia w postaci [batch, 3, height, width].

Kombinacje, które są odrzucane

nms=true jest akceptowane dla ONNX i CoreML, a dla każdego innego formatu odrzucane z nms_unsupported_format. W ONNX wymusza wyłączenie dynamic, ponieważ osadzony graf jest ustalony na batch 1, i informuje o tym na stderr. W CoreML przyjmuje conf i iou, ale nie max_det, więc niedomyślna wartość max_det razem z format=coreml nms=true kończy się wyjściem z config_unsupported.

half=true razem z int8=true nie jest błędem. INT8 wygrywa, half zostaje pominięte, a ostrzeżenie trafia na stderr. quantize niezgodne z half lub int8 kończy się wyjściem z config_conflict.

name i verify są dziś opcjami RKNN. Przekazanie którejkolwiek z nich z innym formatem kończy się wyjściem z config_unsupported, zamiast zostać zignorowane.

Które formaty obsługuje dana rodzina

Wsparcie jest określane per rodzina i per zadanie, nie globalnie. libreyolo formats family=<family> task=<task> wypisuje poziom wsparcia dla każdego formatu w tej kombinacji, wraz z uzasadnieniem, ewentualnym ograniczeniem oraz informacją, czy export() akceptuje tam FP16 i INT8. Argumenty opisuje libreyolo formats.

Niektóre formaty wymagają opcjonalnej instalacji, a niektóre gotowego toolchainu. Brakująca zależność Pythona kończy się wyjściem z export_dep_missing; precyzja, której format nie potrafi wygenerować, kończy się wyjściem z format_precision_unsupported.

Uruchamianie tego, co wyeksportowano

Wyeksportowane artefakty są wczytywane przez tę samą fabrykę modeli co checkpointy, na podstawie sufiksu pliku, więc libreyolo predict model=weights/LibreYOLO9s.onnx działa bez żadnej dalszej konwersji. Wyjątkiem są trzy opcje predykcji, odrzucane na backendach runtime: tiling, overlap_ratio i output_file_format.

Dwa cele wdrożenia mają własne strony: NVIDIA DeepStream i NVIDIA Jetson.

Wynik i kody wyjścia

Wynik trafia na stdout; postęp na stderr. Kod wyjścia to 0 przy powodzeniu, 2 przy błędzie użycia lub konfiguracji, 4 gdy modelu nie da się wczytać, 5 przy nieznanym formacie, brakującej zależności eksportu, nieobsługiwanej precyzji lub odrzuconym żądaniu osadzenia NMS, oraz 1 przy pozostałych błędach w trakcie działania.

Powiązane: libreyolo quantize, które pozostaje w środowisku PyTorch i zapisuje checkpoint, a nie artefakt do wdrożenia.

TFLite INT8 używa int8=True do detekcji YOLO9 lub YOLOX z data=..., fraction=1.0, batch=1 i dynamic=False. FP16 nie jest obsługiwane; jeśli podano obie flagi precyzji, CLI pomija half na rzecz INT8. Wynik eksportu JSON podaje rzeczywisty rozstrzygnięty obszar obrazu, w tym kwadratowy obszar zastępczy dla rodzin o natywnym kwadratowym wejściu wczytanych z checkpointów trenowanych na prostokątach.