Оновлення до 1.7.0

З 1.6.0 до 1.7.0

• Контрольні точки YOLO9, YOLO9-E2E і YOLO9-P2, збережені в 1.7.0, використовують нові назви тензорів і не завантажуються в 1.6.x: 1.6.x завантажує контрольні точки YOLO9 і YOLO9-P2 з попередженням про відсутні ключі й не передбачає жодних рамок, а для YOLO9-E2E спричиняє помилку невідповідності model_family. Оновіть кожне середовище, що їх читає. Контрольні точки з рухомою комою, квантовані й навчальні, записані попередніми випусками, завантажуються в 1.7.0, а експорт ONNX не зачеплено.

• Код, що звертається до model.model моделі сімейства YOLO9, бачить назви модулів MultimediaTechLab/YOLO, без псевдонімів. DDetect стає YOLO9Head (anchor_convs / class_convs), RepConvN стає RepConv, RepNBottleneck стає Bottleneck, DFL стає Anchor2Vec (anchor2vec), nc стає num_classes, а підшари блоків називаються conv1/conv2/bottleneck. У YOLO9-E2E YOLO9E2EDetect стає YOLO9E2EHead, а one2one_cv2 / one2one_cv3 стають one_to_one_anchor_convs / one_to_one_class_convs. LibreYOLO9Model.fuse(), RepConvN.fuse_convs(), Conv.forward_without_bn(), Concat і yolo9.utils.decode_boxes видалено. Кожне перейменування перелічено в журналі змін.

• Назви вузлів ONNX відповідають новим назвам модулів у голові, бекбоні та neck, наприклад /head/anchor_convs.0/.... Оновіть інструменти, що спираються на назви вузлів, як-от конфігурації кінцевих вузлів Hailo. Входи, виходи та назви виходів моделі не змінилися.

• Донавчання YOLO9 з ваг без тензорів PGI, до яких належать опубліковані LibreYOLO9{t,s,m,c}.pt, навчає лише основну голову, як у 1.5.0; 1.6.0 під'єднувала випадково ініціалізовану гілку PGI з aux_weight=0.25. Ваги з тензорами PGI і запуски з нуля, як і раніше, навчаються з PGI. Передайте aux_weight=0.25, щоб усе одно під'єднати нову гілку, або aux_weight=0, щоб примусово її вимкнути.

• Коли PGI під'єднано, YOLO9-m і YOLO9-c будують допоміжну гілку MultimediaTechLab: 12.8M (m) і 25.7M (c) параметрів лише для навчання за 80 класів, замість 7.5M і 10.2M, тому навчання PGI цих розмірів потребує більше пам'яті й часу на крок. Навчальна контрольна точка m/c з 1.6.0 відновлюється й донавчається з гілкою, з якою її навчали. Інференс і YOLO9-t/s не змінилися.

• YOLO9, YOLO9-E2E і YOLO9-P2 обрізають L2-норму градієнта до 10, а їхній навчальний асайнер оцінює якорі в fp32, тому позитиви, обрані під fp16 AMP, можуть відрізнятися. Передайте clip_max_norm=0 для обрізання як у 1.6.0; запуск, розпочатий у 1.6.0 і відновлений у 1.7.0, також обрізає, якщо ви цього не передасте. Для призначення в fp32 перемикача немає.

• Ненульовий perspective викривляє за зсувом кутів у кожному сімействі, що використовує спільне афінне викривлення (YOLO9 та його варіанти E2E і P2, YOLOX, YOLOv7, YOLO-NAS, PP-YOLOE, RTMDet, PicoDet, RT-DETR і RT-DETRv2), зокрема в запусках, відновлених із контрольної точки 1.6.0, яка його задавала. Значення 0.002 і вище дають те саме максимальне викривлення, а від'ємні значення спричиняють ValueError. Жодне налаштування не відтворює викривлення 1.6.0; типове perspective=0 не змінилося.

• Пайплайн mosaic YOLO9 бере коефіцієнт mixup з Beta(1, 1) замість Beta(32, 32), без налаштування для старого значення. Типове навчання YOLOv7 змінюється, бо YOLOv7 типово вмикає mixup. YOLO9, YOLO9-E2E, YOLO9-P2, RT-DETR і RT-DETRv2 змінюються лише тоді, коли mixup ввімкнено.

• libreyolo train без name= записує запуски EC, D-FINE, SegFormer і LingBot-Vision у runs/train/ec_exp, dfine_exp, segformer_exp і lingbotvision_exp замість runs/train/exp, проби V-JEPA 2 у runs/train/train, а запуски YOLO9-P2 у runs/train/yolo9_exp. Передайте name=exp для старого шляху або name=yolo9_p2_exp для YOLO9-P2.

• libreyolo train запускає D-FINE, SegFormer і LingBot-Vision з їхніх власних рецептів. Для D-FINE це 132 епохи, lr0=2e-4, weight_decay=1e-4, 2 епохи прогрівання і без аугментацій mosaic, mixup, HSV та афінних. Щоб надіслати значення, які надсилала 1.6.0, передайте epochs=300 optimizer=sgd lr0=0.01 weight_decay=5e-4 warmup_epochs=5 mosaic=1.0 mixup=1.0 hsv_prob=1.0 degrees=10 translate=0.1 shear=2.0.

• libreyolo.validation.ConfusionMatrix індексує matrix[predicted, true] (було [actual, predicted]), рахує виявлення за conf_thres=0.25 (було 0.15), приймає names= і task= лише як іменовані аргументи, а його matrix більше не можна перепризначити. Транспонуйте код, що індексував стару матрицю, і передайте conf_thres=0.15 для старих підрахунків. plots=True записує кількості в confusion_matrix.png, а нормалізований графік у confusion_matrix_normalized.png.

• predict(agnostic_nms=True) придушує перекривні рамки різних класів замість попередження. Завдання без рамок спричиняють ValueError, LibreEnsemble і HRNet спричиняють NotImplementedError, а рівень SAM відхиляє аргумент із TypeError; приберіть аргумент із цих викликів.

• Невідомий interpolation класифікатора спричиняє ValueError, зокрема режими torchvision LANCZOS, BOX, HAMMING і NEAREST_EXACT. Використовуйте bilinear, bicubic, nearest або bilinear_no_antialias.

• Повторіть валідацію перед порівнянням із числами 1.6.0 для val(single_cls=True) на моделі, навченій на кількох класах, датасетів сегментації, що змішують рядки лише з рамками та з полігонами, і RTMDet-Ins, який типово зберігає до max_det=300 масок на зображення; передайте max_det=100 для налаштування MMDetection.

• Без libreyolo[rfdetr] виклики CLI з назвою моделі RF-DETR або DINOv2 завершуються з кодом помилки JSON model_load_failed замість model_not_found, а повідомлення називає pip install libreyolo[rfdetr].

Повний випуск описано в журналі змін.

З 1.5.0 до 1.6.0

• Перед встановленням додаткового пакета ONNX оновіть середовища з ONNX Runtime нижче 1.18 до onnxruntime>=1.18.0.

• SAM 3D Body приймає перевірений набір ресурсів знімка. Встановіть libreyolo[hf], отримайте доступ і використовуйте автоматичне отримання або надайте незмінений каталог знімка й зафіксований ресурс MHR у довіреній локальній файловій системі.

• Повторіть валідацію після виправлень масштабування RF-DETR для завдань, окрім пози, і нормалізації класифікаторів. Перевірте пороги впевненості розгортання перед порівнянням із результатами 1.5.0; прапорця попередньої обробки старого зразка немає.

• Виявлення D-FINE, DEIM, RT-DETRv4 і YOLO-NAS типово вмикає FP16 AMP. Передайте amp=False, щоб зберегти FP32.

• Для попередніх налаштувань донавчання YOLO9 задайте aux_weight=0, max_labels=100 і warmup_momentum=0.937. Задайте letterbox_pad="topleft", коли нова конверсія з позначкою центру має відтворити стару геометрію. Старі контрольні точки з однією головою відновлюються зі своїм початковим графом. Нові запуски YOLO9 використовують більше пам'яті GPU, тому зменште batch, якщо з розміром батча з версії 1.5.0 не вистачає пам'яті.

• RF-DETR і DINOv2 створюють каталоги запусків із назвою сімейства та збільшуваним номером. Оновіть споживачів шляхів артефактів або задайте output_dir="runs/train", exist_ok=True, щоб зберегти старе розташування й повторне використання.

• Для класифікації дотримуйтеся mixup + cutmix <= 1; неправильні поєднання тепер викликають помилку під час налаштування.

• QAT вимикає EMA, SyncBatchNorm і усереднення контрольних точок. Використовуйте найкращі й останні контрольні точки QAT, не покладаючись на ці стани.

• Власні завантажувачі з хуками зміни датасету мають використовувати persistent_workers=False або відтворювати робочі процеси після зміни. Несумісні постійні копії кількох процесів тепер викликають помилку.

• Масиви зображень NumPy зчитуються як BGR, у порядку OpenCV. Передавайте color_format="rgb" там, де передаєте масив RGB, наприклад np.asarray(pil_image); вихід cv2.imread() і кадри відео змін не потребують.

• 4D масив NumPy або тензор є батчем: predict() повертає список з одним Results на зображення, а не використовує лише перше зображення.

• train(resume=True) і train(resume="path/to/last.pt") відновлюють збережені аргументи навчання запуску й продовжують записувати в його каталог запуску; явно передані аргументи мають перевагу. Відновлення опублікованих ваг або запуску, який уже досяг своїх epochs, спричиняє ValueError.

• Коли валідацію ввімкнено, остання епоха завжди валідується, тому запуски, коротші за eval_interval, тепер повідомляють метрики й записують best.pt. val=False вимикає валідацію, включно з останньою епохою. Валідація під час навчання записує в <run>/val, а не в runs/val/.

• Збої команди train у CLI повідомляють тип помилки, тому помилки конфігурації завершуються з кодом 2, а не з кодом 1 і io_error.

Повний реліз описано в журналі змін, а конверсію контрольних точок у розділі імпорту ваг.

З 1.4.0 до 1.5.0

Ця сторінка описує оновлення самої LibreYOLO. Якщо ви шукаєте спосіб завантажити контрольну точку з upstream-проєкту, дивіться імпорт наявних ваг, це інша тема.

Повний запис про реліз містить журнал змін. Нижче наведено лише те, що потребує дій із вашого боку.

Обов'язкові зміни коду

allow_experimental=True більше не існує

Механізм підтвердження вилучено разом із базовим механізмом ddp_aware(experimental_key=...). Раніше для навчання та експорту EC, RTMDet, PicoDet і FOMO був потрібний цей аргумент, тому зміна стосується кожного скрипту, що навчає одне з цих сімейств.

# 1.4.0model.train(data="data.yaml", epochs=100, allow_experimental=True) # 1.5.0: видаліть аргументmodel.train(data="data.yaml", epochs=100)

Проміжного шару для застарілого виклику немає. Виклик, який досі передає цей аргумент, отримує попередження Unknown training config keys (ignored), а сам аргумент не має жодного ефекту. Разом із ним вилучено BaseModel.EXPERIMENTAL_WEIGHT_FILENAMES. Перехоплювач get_download_notice() збережено, і його досі перевизначають MiDaS, SegFormer та YOLO9-P2.

Рівні підтримки досі публікуються, але більше не є аргументом: дивіться рівні стабільності.

Рівня експорту "experimental" більше не існує

from libreyolo.export.support import Tier # 1.4.0: Literal["validated", "experimental", "blocked"]# 1.5.0: Literal["validated", "available", "blocked"]

Код, що розгалужується за рядком рівня, має читати "available" там, де раніше читав "experimental". BaseExporter більше не виводить RuntimeWarning для цих форматів. Стан для кожного формату наведено в матриці експорту.

pretrained=False разом із resume тепер відхиляється

Раніше ця комбінація продовжувала роботу непослідовно. Тепер вона спричиняє:

ValueError: pretrained=False cannot be combined with resume.

Виберіть щось одне. pretrained=False починає з нової ініціалізації з фіксованим початковим значенням генератора; у 1.5.0 це працює для кожного придатного до навчання сімейства, а не лише для трьох. resume продовжує перерваний запуск із його контрольної точки. Обидва варіанти описано в розділі навчання.

Параметр CLI --imgsz є рядком, а не цілим числом

Зміна вужча, ніж здається. Обидва наведені нижче варіанти не змінюються:

libreyolo predict --model yolo9-t --source img.jpg --imgsz 640   # усе ще працює

model.predict("img.jpg", imgsz=640)   # усе ще працює

Змінити потрібно лише код, який безпосередньо викликає командні функції CLI з Python, оскільки predict, train і val розширили тип --imgsz з int до str, щоб приймати прямокутні розміри:

from libreyolo.cli.commands.predict import predict_cmd predict_cmd(..., imgsz=640)      # 1.4.0predict_cmd(..., imgsz="640")    # 1.5.0, тепер також працює "480x640"

Типовим значенням train тепер є рядок "640". Параметр export --imgsz уже був рядком, а profile не змінився.

Числа, що змінюються

Три зміни впливають на метрики з типовими налаштуваннями. Якщо ви відстежуєте результати між версіями, прочитайте це перед порівнянням запуску 1.5.0 із запуском 1.4.0.

faster-coco-eval є типовим бекендом метрик COCO

val() і валідація навчання після кожної епохи тепер обчислюють метрики COCO за допомогою бекенда faster-coco-eval на C++ замість pycocotools.

Рішення про перехід ухвалено за виміряним паритетом на всіх 100 тестових розбиттях RF100-VL: 1381 із 1400 значень метрик побітово ідентичні, максимальне відхилення 2.22e-16, зміни основних показників дорівнюють рівно 0, загальна швидкість вища у 15.6 раза, а на датасетах із великою кількістю виявлень у 56 разів. Ваші числа не повинні змінитися. Однак їх створює інша реалізація, тому ця зміна є в списку.

pycocotools залишається автоматичним резервним варіантом, якщо faster-coco-eval не встановлено. Щоб примусово використати його:

libreyolo val --model yolo9-t --data coco.yaml --no-faster-coco-eval

model.val(data="coco.yaml", faster_coco_eval=False)

LIBREYOLO_FASTER_COCO_EVAL=0 робить те саме глобально. Фактично використаний бекенд записується до журналу на рівні INFO, доступний як model.last_eval_backend після val() і включений як eval_backend до даних JSON CLI. Швидкий шлях можна встановити командою pip install libreyolo[fast-eval].

Контрольним точкам YOLOX, навченим до 1.5.0, потрібне перевизначення eps

Це пастка цього релізу. Прочитайте цей розділ, якщо ви донавчали YOLOX.

YOLOX задає для BatchNorm eps=1e-3 і momentum=0.03. До 1.5.0 ці значення застосовувалися як виправлення після створення, яке не переживало перебудову кількості класів, що виконується в train(), коли nc вашого датасету відрізняється від контрольної точки. Таке донавчання й валідація під час нього використовували типове значення torch eps=1e-5, а після повторного завантаження для інференсу застосовувалося 1e-3: ті самі тензори з іншою нормалізацією.

Розміри зі звичайними згортками майже не змінюються. Розмір n із роздільними за глибиною згортками змінюється значно, оскільки його поканальна running_var досить мала, щоб eps домінувало. На розбитті ball датасету RF100-VL та сама контрольна точка nano має 0.566 mAP50-95 під час оцінювання з eps, на якому її навчено, і 0.151 після стандартного повторного завантаження.

Контрольна точка, навчена до 1.5.0, має семантику eps=1e-5. Щоб отримати для неї достовірні числа, виконайте оцінювання з перевизначенням BN eps на 1e-5:

import torchfrom libreyolo import LibreYOLO model = LibreYOLO("my-yolox-finetune.pt")for module in model.model.modules():    if isinstance(module, torch.nn.BatchNorm2d):        module.eps = 1e-5 model.val(data="data.yaml")

Або один раз включіть sqrt((var + 1e-3) / (var + 1e-5)) у ваги BN і збережіть результат. Контрольним точкам, навченим у 1.5.0 або новішій версії, не потрібне жодне з цих рішень.

Багатомасштабне навчання D-FINE використовує upstream-рецепт для кожного розміру

Значення base_size_repeat було жорстко задано як 3 для кожного розміру. Тепер воно визначається окремо для кожного розміру згідно з upstream-рецептом: n навчається з фіксованим розміром і вимкненим багатомасштабним режимом, s використовує 20, m 6, l 4, x 3. Раніше збігався лише x, тому n, s, m і l бачать інший розподіл масштабів та збігаються до інших значень метрик.

Щоб відновити попередню поведінку, задайте значення явно:

from libreyolo.training.config import DFINEConfig config = DFINEConfig(base_size_repeat=3)

DEIM і далі використовує жорстко задане значення 3. Подробиці про сімейство наведено на сторінці D-FINE.

Варто знати, дії не потрібні

• Результати з прямокутним imgsz змінилися, оскільки раніше були неправильними. Координати рамок, зміна розміру масок RTMDet, перемасштабування YOLO-NAS і масштабування еталонних даних валідатором тепер використовують окремі висоту й ширину замість одного скалярного значення. Квадратний imgsz побітово не змінився. Прямокутний інференс або валідація у 1.4.0 мали неправильний масштаб. YOLO-NAS тепер повністю відхиляє прямокутний imgsz замість непомітного створення неправильних вихідних даних.
• Словники метрик отримали нові ключі. max_det, ar_max_det і AR_max_det від засобу оцінювання COCO, а також metrics/loss і metrics/loss/ce від FOMO. Значення з типовими налаштуваннями не змінилися, але все, що перебирає ключі метрик, зокрема користувацькі засоби журналювання і заголовки CSV, бачить нові стовпці.
• Запуски YOLO9 із фіксованим початковим значенням, що спричиняють перебудову голови, починають з іншої ініціалізації, оскільки початкове значення тепер застосовується до перебудови, а не після неї. Донавчання 1.4.0 з фіксованим початковим значенням для іншої кількості класів не відтворюється побітово у 1.5.0.
• libreyolo[hub-kernels] на CUDA тепер справді залучає нативне ядро MS-deform-attn. У 1.4.0 його було обмежено умовою, яку RF-DETR ніколи не виконував, тому ядро не запускалося. Передбачення RF-DETR та інших сімейств із деформованою увагою можуть змінитися в межах похибки float. Стандартних установлень це не стосується, а LIBREYOLO_HUB_KERNELS=0 вимикає ядро.
• libreyolo predict відкидає непідтримувані параметри замість помилки. CLI фільтрує kwargs за сигнатурою __call__ моделі, тому параметр, якого сімейство не приймає, ігнорується замість спричинення TypeError. Невідома назва прапорця, як і раніше, відхиляється з No such option.
• Живі джерела змінюють форму вихідних даних JSON. Вебкамери, потоки RTSP і захоплення екрана неявно вмикають потоковий режим, що виводить один запис для кожного кадру замість одного запису для виклику. Ці джерела з'явилися у 1.5.0, тому зміна не стосується скриптів 1.4.0.
• Повторний експорт rfdetr-pose або yolonas-pose до ONNX створює інші назви виходів. У 1.4.0 їхні багатотензорні голови пози помилково визначалися як сегментація за евристикою кількості виходів. Наявні файли .onnx на диску не змінюються.
• У встановленні без torch результати містять масиви numpy замість torch.Tensor, тому .boxes.data повертає інший тип, а розв'язання рівних значень у NMS може відрізнятися від torchvision. За встановленого torch поведінка побітово не змінилася. Дивіться полегшене встановлення.
• Об'єкти конфігурації перевіряють більше під час створення. TrainConfig отримав __post_init__ там, де його не було, тому вже некоректна конфігурація тепер спричиняє помилку негайно, а не в глибині виконання. Серіалізація ValidationConfig отримала ключ edge_thresholds, що порушує строгий круговий перехід ValidationConfig(**dump) із дампа 1.4.0.
• Назви файлів ваг для сімейств із суфіксом задачі визначаються інакше. segformer-b0 тепер перетворюється на LibreSegformerb0-sem.pt. Це виправляє помилки 404 автоматичного завантаження й порушує скрипти з жорстко заданою старою назвою без суфікса.
• Маркер pytest experimental_backend тепер має назву extended_backend. Це стосується лише запуску набору тестів із -m.

Контрольні точки та датасети

Контрольні точки, записані версією 1.4.0, завантажуються без змін. Схема отримала imgsz_h і imgsz_w для прямокутних моделей і досі записує скалярне значення imgsz = max(h, w) для старіших читачів. Для експорту ExecuTorch і MNN тепер потрібний супровідний файл, відповідно <program>.pte.json і <model>.mnn.json, а експорт HRNet містить pose_input: "person_crop". Формати датасетів не змінилися.