【画像認識AI】Ultralytics YOLO v8 解説

2024年6月22日

【画像認識AI】Ultralytics YOLO v8 解説

物体検出ライブラリである Ultralytics社の YOLOv8の使い方をご紹介します。

公式サイト https://www.ultralytics.com/yolo
公式github https://github.com/ultralytics/ultralytics
本投稿は v8.2を参考にしています。

シリーズ投稿記事

YOLOv8 インストール
パラメータ解説
ファイル構造の解説
トラッキング
枠や点、線の色や太さを変える
ソースコードを改変せずに、見た目を変える
ライブ配信のリアルタイム処理
supervisionの利用

他のYOLOとの違い

「YOLO」自体は特定の研究機関などやチームが管理している商標などではありません。

例えとして適切か分かりませんが、
かつてベトナムではバイクのことを「ホンダ」と呼んだという面白いハナシがあります。
同様に、ものすごい雑に言えば、YOLOは同じようなライブラリに付けられている名称です。

英文ですが、こちらに樹形図としてまとまっています。

https://blog.roboflow.com/guide-to-yolo-models

こちらでご紹介しているYOLO v8は、Pytorch実装をしたグレン氏が率いるUltralytics社がリリースしたものです。

さらにPYPIパッケージとしてultralyticsフレームワークがリリースされており、今ではv8以降のYOLOは読み込むモデルを変更するだけで実行することができるようになりました。

from ultralytics import YOLO

# yolo version12、モデル名を書くだけで動く
model = YOLO("yolo12n.pt")

# 画像ファイル 'bus.jpg' を指定し、実行
results = model("path/to/bus.jpg")

Ultralyticsライセンスと料金について

ライセンス：エンタープライズライセンスもしくは AGPL-3.0

製品などプロダクトに組み込む場合はエンタープライズライセンス、
愛好家や研究者はAGPL-3.0を選択すればよいとのこと。
下記の通り、企業等によるコミュニティへの還元もしくはユーザーによる貢献を実現することを強く意識しています。

アップデートも頻繁に行われており、ultralyticsを中心としたエコシステムが形成されつつあります。

私たちのライセンス戦略は、オープンソースプロジェクトの改善が確実にコミュニティに還元されるように設計されています。私たちはオープンソースの原則を常に大切にしており、私たちの貢献がすべての人にとって有益な方法で活用され、拡張されることを保証することが私たちの使命です。

https://docs.ultralytics.com

AGPL-3.0とは

https://www.tohoho-web.com/ex/license.html

このライセンスでは、配布したり、もしくはネットワーク経由で利用可能にした場合に改変したコードを開示することになります。
ただし、このAGPL-3.0のベースとなっているGPLライセンスでは、そこから得られた画像などの生成物の著作権はその人に属すとされています。つまりアノテーションを付けた画像などはライセンスの対象に入りません。

GNUライセンスに関してよく聞かれる質問 – GNUプロジェクト – フリーソフトウェアファウンデーション

エンタープライズライセンスの考え方

最初から・誰もが、エンタープライズライセンスを使わなければならないというわけではない。

Githubにて意見交換が行われています。
https://github.com/orgs/ultralytics/discussions/1260#discussioncomment-9060215

こちらのディスカッションでは以下のようなコメントがあります。

Enterprise License would indeed be required once the project transitions from an R&D stage to being used commercially within the company.

（意訳）
プロジェクトが研究開発段階から社内で商業的に使用される段階に移行するときに、エンタープライズライセンスが必要になります。

実際の商業プロジェクトではMVP(Minimum Viable Product)を制作し、実現できるのか、マーケットに受け入れられるのかなどを確認する段階が必要でしょう。

研究段階の結果、場合によっては研究プロジェクトのまま終わる…という場合もあると思います。

費用：非公開

費用は公開されているわけではなく、ultralytics社に問い合わせる形です。
Unityのように、収益が$xxx未満の個人および企業に対しては無料…などとはなっていません。

コストは特定のニーズに応じて異なる場合があります。導入規模、統合レベル、サポート要件などの要因に応じて、1 回限りの料金またはサブスクリプションモデルになる可能性があります。
A question about the license · ultralytics · Discussion #1260 · GitHub

これは想像なのですが、エンタープライズライセンスとして提供する事ができない部分を書き換えたり(!?)、利用者の規模、提供範囲などに依って変わるのかなと考えています。
Githubのディスカッションに以下のような投稿がありました。
https://github.com/orgs/ultralytics/discussions/1260#discussioncomment-8696997

個人スタートアップに提示された金額が年間4500ドル？

For a single person startup with no earning, I requested their enterprise licensing but they stated $5000/year!
With only 2k downloads, I don’t think they saw the scope or the scale of my venture before quoting their fees. Posting here the email so developers can be aware of their fee structure and work on other models if needed without investing time and energy on Ultralytics YOLO.

(意訳)
収入のない個人スタートアップがエンタープライズライセンスをリクエストしたら年間 5000 ドルとのことでした。
ダウンロード数がわずか2,000 件なので、私の事業の規模を確認してから見積もりしたように思えません。

I got a reply in the mail but only $500 was reduced and the final fee was $4500. Seems developers like me can’t use your yolov8. Never mind, I’ll switch to another model.

メールで返事が来たのですが、500ドルしか減額されず、最終的な料金は4500ドルでした。

2,000ダウンロードしかないのに$4500もかかるのか、という書き込みでした。
日本円で70万円前後になるかと思います。
利益やビジネスモデルにも依るかと思うのですが単に頒布量で計算しているわけではないのではないかと思われます。

マーケティングが終わり、利益の見通しが立っている状態で
エンジニア1人を1ヶ月雇って他のライブラリに換装させるか、
ライセンス契約をしてサポートを受けるのとどっちが良いか　を選択するようなイメージ…ですかね。

モデルについて

ultralyticsパッケージは至れり尽くせりで、どんなYOLOモデルでも読めるんじゃないかというレベルでサポートが行き届いています。

そのため、モデルよっては専門家に確認してどこに置くか・どう利用するかによりケースバイケースでの確認が必要になるだろうという書き込みもあります。
https://github.com/orgs/ultralytics/discussions/2127#discussioncomment-8380408

(※意訳※詳細は必ず原文をご確認ください)

以下に、各シナリオごとの一般的なガイドラインを示します。

・サードパーティサービスでのデプロイ:
モデルをホストするためにサードパーティサービスを使用する場合、モデルのソースコードと、加えた変更を提供する必要があります。また、そのサービス上でモデルをデプロイする手順も提供する必要があります。

・サードパーティのDockerコンテナ:
最初のシナリオと同様に、モデルの重み、設定ファイル、デプロイ手順を含めたすべての情報を提供する必要があります。Dockerコンテナの使用方法についても明示する必要があります。

・カスタムサービスでのデプロイ:
モデルに加えた変更を含め、カスタムサービスのソースコードを公開する必要があります。さらに、デプロイ手順も提供する必要があります。

・Webサーバーとの連携:
モデルと直接連携するサービスのソースコードは公開する必要があります。ただし、Webサーバーがフロントエンドとして機能する場合、モデルの動作と密接に結びついていない限り、必ずしもオープンソースにする必要はありません。

・中間サービスとの連携:
モデルと直接連携するサービスのソースコードは公開する必要があります。一方で、モデルと直接やり取りしないクライアントアプリケーションや中間サービスは、オープンソース化の対象外となる可能性があります。

・モバイルアプリ/PWAへの組み込み:
アプリ全体（モデル、重み、設定ファイルを含む）を提供する必要があります。これは、派生作品（Derivative Work）とみなされるためです。

AGPL-3.0 ライセンスでは、ネットワーク経由でソフトウェアを利用するユーザーに対して、改変部分と元のソースコードを公開する必要があることを忘れないでください。