「Ovis2.5」を試す
Ovis 2.5の紹介 - 最新のマルチモーダルLLMのブレークスルー!
強化された視覚認識と推論能力を備え、主要なベンチマークで一貫してより大きなモデルを上回っています。
#Ovis #MLLM
Ovis2.5-9B:
- OpenCompassで78.3
- 40B未満の#OpenSourceモデルの中で#1
試してみる:
https://huggingface.co/AIDC-AI/Ovis2.5-9B
Ovis2.5-2B:
📈OpenCompassで73.9
エッジデバイス向け最高クラス
今すぐ試す: https://huggingface.co/AIDC-AI/Ovis2.5-2B
過去、軽量なVLMとして日本語も使えて、特に文字読み取り性能が高かったOvisシリーズの最新版、ということでこれは期待。
過去のOvisシリーズ
Ovis1.6。この頃はまだ日本語文字読み取り性能は低かった
Ovis2。VITエンコーダがSigLipからAIMv2に、LLMがGemma2/Llama3からQwen2.5ベースに変わって、日本語性能が大きく向上。
Ovis-U1。Ovis2ベースで画像生成・編集ができるようになったモデル。
モデルのバリエーションは、2B / 9B の2つ。
Ovis2 は、 1B / 2B / 4B / 8B / 16B / 34B の6種類あったので、ここはちょっと残念。
モデルカードを読む。2Bも9Bも同じっぽいので、9Bの方を。GP-T-5で翻訳。
Ovis2.5-9B
はじめに
Ovis2.5 のリリースをお知らせします。これは Ovis2 の後継モデルで、ネイティブ解像度での視覚認識とマルチモーダル推論の強化を目的として設計されています。本モデルには、画像を元の可変解像度で処理するネイティブ解像度ビジョントランスフォーマー(NaViT)が統合されており、固定解像度タイル化の必要がなく、チャートや図表のような情報密度の高いコンテンツにおいて重要な細部と全体構造を損なわずに保持します。推論能力を強化するため、Ovis2.5 は線形的な Chain-of-Thought(CoT)に加え、自己検証や修正を含む反省型推論でも訓練されています。 この高度な機能は推論時にオプションとして利用可能な thinking mode として提供され、複雑な入力に対してレイテンシと精度のトレードオフを可能にします。
これらの進歩に基づき、Ovis2.5-9B は OpenCompass マルチモーダル評価スイートで平均スコア 78.3 を達成し、40B パラメータ未満のオープンソース MLLM の中で SOTA を記録しました。一方、軽量な Ovis2.5-2B はスコア 73.9 を達成し、リソース制約のある環境において「小型モデルで高性能」という理念を継続しています。
referred from https://huggingface.co/AIDC-AI/Ovis2.5-9B主な特長
- ネイティブ解像度認識 — NaViT ビジョンエンコーダにより、損失のあるタイル化なしで細部と全体構造を保持。
- 深い推論能力 — 線形 CoT を超えた自己検証と修正を可能にするオプションの thinking mode。
- チャート & ドキュメント OCR — 複雑なチャート解析、文書理解(表やフォームを含む)、OCR において同規模帯で最先端。
- 幅広いタスク対応 — 画像推論、動画理解、グラウンディングのベンチマークで高性能を示し、強力な汎用マルチモーダル能力を発揮。
referred from https://huggingface.co/AIDC-AI/Ovis2.5-9B
モデル一覧
Ovis MLLM ViT モデル重み デモ Ovis2.5-2B siglip2-so400m-patch16-512 Qwen3-1.7B Huggingface Space Ovis2.5-9B siglip2-so400m-patch16-512 Qwen3-8B Huggingface Space パフォーマンス
Ovis2.5 は VLMEvalKit を使用し、OpenCompass のマルチモーダルおよび推論評価スイートで評価されました。
referred from https://huggingface.co/AIDC-AI/Ovis2.5-9B
referred from https://huggingface.co/AIDC-AI/Ovis2.5-9B
ライセンス
本プロジェクトは Apache License, Version 2.0 に基づきライセンスされています(SPDX-License-Identifier: Apache-2.0)。
Ovis2からのアーキテクチャ的変更点は、
- LLMは、Qwen2.5からQwen3ベースに変更
- VITエンコーダは、AIMv2からsiglip2に変更
あたり。
以前、GLM-4.1Vを試した時に、日本語文字の読み取り精度が高くて、調べてみるとこれもAIMv2で、どうもこのVITエンコーダの性能が高いのでは?と思っていた。
今回、Ovis-2.5ではsiglip2が採用されていてどうなのかな?と思ったら、siglip2はAIMv2よりも高いらしい。
とりあえずそのあたりは実際に試してみて確認。
なお、どちらもデモが用意されているので、お手軽に試すならそちらで。
Colaboratory A100で。
パッケージインストール。モデルカードでは以下のパッケージが記載されている。
torch==2.4.0
transformers==4.51.3
numpy==1.25.0
pillow==10.3.0
moviepy==1.0.3
flash-attn==2.7.0.post2
Colaboratoryだとこんな感じかな。numpyとpillowで、ランタイムの再起動が必要。
!pip install torch==2.4.0 torchvision==0.19.0 torchaudio==2.4.0 --index-url https://download.pytorch.org/whl/cu124
!pip install transformers==4.51.3 numpy==1.25.0 pillow==10.3.0 moviepy==1.0.3
!pip install flash-attn==2.7.0.post2 --no-build-isolation
モデルをロード。ちょいちょいパッケージのwarningが出るが、とりあえず気にせず進める。
import torch
from transformers import AutoModelForCausalLM
MODEL_PATH = "AIDC-AI/Ovis2.5-9B"
model = AutoModelForCausalLM.from_pretrained(
MODEL_PATH,
torch_dtype=torch.bfloat16,
trust_remote_code=True
).cuda()
モデルロード後のVRAM消費は18GB程度。
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 550.54.15 Driver Version: 550.54.15 CUDA Version: 12.4 |
|-----------------------------------------+------------------------+----------------------+
| GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. |
| | | MIG M. |
|=========================================+========================+======================|
| 0 NVIDIA A100-SXM4-40GB Off | 00000000:00:04.0 Off | 0 |
| N/A 33C P0 52W / 400W | 18021MiB / 40960MiB | 33% Default |
| | | Disabled |
+-----------------------------------------+------------------------+----------------------+
では推論。まずサンプルの画像はOvisのアーキテクチャ図の画像となっている。
from IPython.display import Image
image_url = "https://cdn-uploads.huggingface.co/production/uploads/658a8a837959448ef5500ce5/TIlymOb86R6_Mez3bpmcB.png"
display(Image(url=image_url, width=1024))
これを使って推論。Ovis2.5では新たにThinkingモードで深い推論の有効・無効を設定できる。なお、Ovis2でもCoTスタイルの推論というのがあったようなのだが、自分が以前試した際はそれに全然気づいてなかった。
import requests
from PIL import Image
image_url = "https://cdn-uploads.huggingface.co/production/uploads/658a8a837959448ef5500ce5/TIlymOb86R6_Mez3bpmcB.png"
pil_image = Image.open(requests.get(image_url, stream=True).raw)
messages = [{
"role": "user",
"content": [
{
"type": "image",
"image": pil_image},
{
"type": "text",
"text": "図 (c) の中央のボックス内の数の合計を計算してください。"},
],
}]
input_ids, pixel_values, grid_thws = model.preprocess_inputs(
messages=messages,
add_generation_prompt=True,
enable_thinking=True # Thinkingモード
)
input_ids = input_ids.cuda()
pixel_values = pixel_values.cuda() if pixel_values is not None else None
grid_thws = grid_thws.cuda() if grid_thws is not None else None
outputs = model.generate(
inputs=input_ids,
pixel_values=pixel_values,
grid_thws=grid_thws,
max_new_tokens=3072
)
response = model.text_tokenizer.decode(outputs[0], skip_special_tokens=True)
print(response)
15秒ほどで結果が出た。比較的速いのでは?
<think>
用户现在需要计算图(c)中央盒子内的数的总和。首先看中央盒子里的三个数:0.2、0.5、0.3。然后把它们加起来,0.2 + 0.5 + 0.3 = 1.0。所以总和是1.0。</think>
図 (c) の中央のボックス内には 0.2、0.5、0.3 の 3 つの数が含まれています。これらの数を合計すると、
\( 0.2 + 0.5 + 0.3 = 1.0 \)
となります。
したがって、合計は \( 1.0 \) です。
中国語ではあるけども、<think></think>
タグが出力されていて Thinkingモードが有効になっているのがわかる。
なお、推論後はVRAM消費が一気に跳ね上がった。おそらく同じ画像で推論する分にはある程度このまま推移するんだろうけど、別の画像を読み込んだ場合にはまたまた上がりそうな気がする。
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 550.54.15 Driver Version: 550.54.15 CUDA Version: 12.4 |
|-----------------------------------------+------------------------+----------------------+
| GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. |
| | | MIG M. |
|=========================================+========================+======================|
| 0 NVIDIA A100-SXM4-40GB Off | 00000000:00:04.0 Off | 0 |
| N/A 33C P0 53W / 400W | 36505MiB / 40960MiB | 0% Default |
| | | Disabled |
+-----------------------------------------+------------------------+----------------------+
ちょっとお試しするにはなかなか厳しいので、以降は2Bで。モデル名を変えるだけ。
import torch
import requests
from PIL import Image
from transformers import AutoModelForCausalLM
MODEL_PATH = "AIDC-AI/Ovis2.5-2B"
model = AutoModelForCausalLM.from_pretrained(
MODEL_PATH,
torch_dtype=torch.bfloat16,
trust_remote_code=True
).cuda()
モデルロード後のVRAM消費は5.4GB程度。
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 550.54.15 Driver Version: 550.54.15 CUDA Version: 12.4 |
|-----------------------------------------+------------------------+----------------------+
| GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. |
| | | MIG M. |
|=========================================+========================+======================|
| 0 NVIDIA A100-SXM4-40GB Off | 00000000:00:04.0 Off | 0 |
| N/A 32C P0 49W / 400W | 5367MiB / 40960MiB | 0% Default |
| | | Disabled |
+-----------------------------------------+------------------------+----------------------+
一応上と同じことをやってみる。
import requests
from PIL import Image
image_url = "https://cdn-uploads.huggingface.co/production/uploads/658a8a837959448ef5500ce5/TIlymOb86R6_Mez3bpmcB.png"
pil_image = Image.open(requests.get(image_url, stream=True).raw)
messages = [{
"role": "user",
"content": [
{
"type": "image",
"image": pil_image},
{
"type": "text",
"text": "図 (c) の中央のボックス内の数の合計を計算してください。"},
],
}]
input_ids, pixel_values, grid_thws = model.preprocess_inputs(
messages=messages,
add_generation_prompt=True,
enable_thinking=True
)
input_ids = input_ids.cuda()
pixel_values = pixel_values.cuda() if pixel_values is not None else None
grid_thws = grid_thws.cuda() if grid_thws is not None else None
outputs = model.generate(
inputs=input_ids,
pixel_values=pixel_values,
grid_thws=grid_thws,
max_new_tokens=3072
)
response = model.text_tokenizer.decode(outputs[0], skip_special_tokens=True)
print(response)
<think>
用户现在需要计算图(c)中央的盒子里的数的和。首先看每个数:0.2、0.5、0.3。然后把它们加起来。计算过程是0.2 + 0.5 + 0.3。先算0.2+0.5=0.7,然后0.7+0.3=1.0。所以总和是1.0。</think>
図 (c) の中央のボックス内の数は \( 0.2 \)、\( 0.5 \)、\( 0.3 \) です。これらの数の合計を計算すると:
\[
0.2 + 0.5 + 0.3 = 1.0
\]
よって、数の合計は \( 1.0 \) です。
推論後のVRAM消費は17GB程度。2BならランタイムL4でいけそう。
Fri Aug 15 13:02:26 2025
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 550.54.15 Driver Version: 550.54.15 CUDA Version: 12.4 |
|-----------------------------------------+------------------------+----------------------+
| GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. |
| | | MIG M. |
|=========================================+========================+======================|
| 0 NVIDIA A100-SXM4-40GB Off | 00000000:00:04.0 Off | 0 |
| N/A 33C P0 65W / 400W | 17293MiB / 40960MiB | 34% Default |
| | | Disabled |
+-----------------------------------------+------------------------+----------------------+
ということで、以降はL4ランタイムで。
複数画像
複数の画像をまとめて処理できる。以下の3つの画像を使ってみる(画像感の関連性はあまりないけれど)
神戸の風景
書籍の画像
架空の請求書の画像
!wget https://storage.googleapis.com/zenn-user-upload/82968d23b6c5-20250228.jpg -O kobe.jpg
!wget https://storage.googleapis.com/zenn-user-upload/caa14aef4b7e-20250226.png -O book.png
!wget https://storage.googleapis.com/zenn-user-upload/4697c3aef653-20250226.png -O invoice.png
推論。サンプルコードエはThinkingモード無効だったが有効にした。
multi_image_files = [
"kobe.jpg",
"book.png",
"invoice.png",
]
content = [
{"type": "image", "image": Image.open(p).convert("RGB")}
for p in multi_image_files
]
content.append({"type": "text", "text": "これらの画像についてそれぞれ説明して。"})
messages = [{"role": "user", "content": content}]
input_ids, pixel_values, grid_thws = model.preprocess_inputs(
messages=messages,
add_generation_prompt=True,
max_pixels=896*896,
enable_thinking=True
)
input_ids = input_ids.cuda()
pixel_values = pixel_values.cuda().to(model.dtype) if pixel_values is not None else None
grid_thws = grid_thws.cuda() if grid_thws is not None else None
with torch.no_grad():
outputs = model.generate(
inputs=input_ids,
pixel_values=pixel_values,
grid_thws=grid_thws,
max_new_tokens=2048,
do_sample=True,
eos_token_id=model.text_tokenizer.eos_token_id,
pad_token_id=model.text_tokenizer.pad_token_id
)
response = model.text_tokenizer.decode(outputs[0], skip_special_tokens=True)
print(response)
<think>
用户现在需要分别描述三张图片的内容。首先看第一张:
第一张是滨良港(横滨的大本营)的景观图。图中可以看到水面、港口设施,岸边有现代化建筑,最显眼的是赤坂塔(Toranomon Tower,东京的标志性塔)。建筑风格现代,还有另一座白色的网状结构建筑(应该是横滨湾国际广场Terra),远处有山峦,天空晴朗。水面平静,建筑物倒影可见,整体是城市海滨风光,充满都市活力,结合地标建筑,说明这是日本横滨的滨良港区域。
第二张是书的封面。书名是《ドキュメント・コミュニケーションの全体観:上巻 原則と手順 中三形 酒史》(Document Communicationの全体観:原原則と手順 下巻?不对,看文字:上巻原理と手順 中三形酒史?哦,可能是《ドキュメント・コミュニケーションの全体観》(Document Communication的全体观),重点在文档和沟通,封面上有白色背景,绿色横幅写着“コミュニケーションはすべて解・動・早で進めよ”(沟通要解、动、早速推进,是“解を進める・動く・進めよ”?需要准确描述:封面上部是书名和副标题,有文字说明文档、报告、宣传资料的准备与高效处理,中间有流程图,下方绿色横幅文字是“解・動・早で進めよ”。封面设计简洁,白色为主,突出绿色区域的标语和流程图,属于书籍的商务沟通指南类,用于提升文档和沟通效率。
第三张是一份正式的申请书表格(謝請求書/Suggestive Request Form)。顶部是标题“御請求書”(申请书),请求书编号INV-2024-0820。发件方是“模範商事株式会社”,地址在东京千代田区,电话传真信息。表格部分详细列了项目:送付和纸(A4)的数量(1000张)、单价(¥50)、金额(¥50,000);高级墨(松烟)20件,每件¥2,000,总计¥40,000;笔套装(各种)50个,每件¥1,000,总计¥50,000。小计¥140,000,还计算了10%税费¥14,000,总计¥154,000。底部有备忘事项和审批人名“担当:営業部 見本 太郎”(营业部 常本 郎)。整体是黑色打印(?)的文档,布局正式,属于商务申请书,用于请求采购或购买特定办公用品,细节丰富,包含金额计算、项目明细、税费等,是典型的正式商务文件。
现在要把每张图的信息组织清楚,用日语描述的话要准确,中文描述要简洁明了,突出每个图的主体元素:风景、书籍、正式文档。
总结:
1. 第一张图是**日本横滨的滨良港(大本营)**景观。画面中可见平静的海面,岸边停泊游艇,近处是现代化建筑(包括色彩鲜艳的赤坂塔、横滨湾国际广场Terra 楼等标志性建筑),背景有山峦,天空晴朗。整体呈现城市海滨与建筑地标结合的现代都市风貌,赤坂塔作为视觉焦点,展现了横滨作为港口城市的活力与地标特色。
2. 第二张图是**一本名为《ドキュメント・コミュニケーションの全体観:原原則と手順》**(Document Communication的全体观:原理与手順)的书籍封面。封面以白色为主色调,中央绿色横幅显示宣传标语“コミュニケーションはすべて解・動・早で進めよ”(沟通要解、动、速进)。封面中上部有书名、副标题(关于文档、报告、宣传资料的高效处理),中间嵌入流程图,下方文字说明侧重提升文档与沟通效率。整体设计简洁专业,属于商务沟通与文档管理类书籍,突出专业性与实用性。
3. 第三张图是**一份正式的商务申请书(謝請求書)**,请求采购特定办公用品。文档包含顶部标题“御請求書”、请求书编号(Inv-2024-0820)、发件方“模範商事株式会社”的地址(东京千代田区)、电话/传真信息,中下部表格详细列出“送付和纸(A4)、高级墨、笔套装”三项项目的数量、单价、金额(小计¥140,000,含10%税费后的总计¥154,000),底部有备忘说明与审批人信息。整体以正式的黑白色调呈现,布局严谨,突出商务场合的严谨性与文书规范性,是典型的公司采购申请文书。</think>
### 1. 第1枚画像:日本横浜のベイヤー港(大本営)の風景
画面は**日本横浜のベイヤー港(大本営)**の海岸と都市景観を描いています。前景には穏やかな海が広がり、港湾施設や停泊するヨット、近代的な建物が配置されます。建物の中でも目立つのは、赤坂タワー(Toranomon Tower)という都市の象徴的な建造物です。さらに右側には、横浜湾国際広場(Terra)のような流線形の建物も確認できます。背景には山々がそびえ、青空が広がる澄んだ天気の中、現代的な建築と自然の融合が印象的です。全体として「港湾都市の活気+ランドマーク建築」を特徴とする風景写真です。
### 2. 第2枚画像:ブック・ジャケット「ドキュメント・コミュニケーションの全体観〈原原則と手順〉」
この画像は**ビジネス用書籍「ドキュメント・コミュニケーションの全体観〈原原則と手順〉」**の表紙です。
- 表面は白を基調とし、中央に**緑色の横帯**で「コミュニケーションはすべて「理解→行動→早期進捗」で進めよ」というメッセージが大きく記載されています。
- 中央部には「文書提出」「情報収集」「事前に準備」「事後の効果測定」といった要素を示す**流程図**が配置され、書籍が「文書・コミュニケーションの効率化」に焦点を当てていることがわかります。
- 上部には書名、「文書管理」「準備手順」などの側テーマが軸となって掲載されたことで、「文書を効率的に作成・管理・発信するための知恵を凝縮した書籍」であることが伝わります。
シンプルで洗練されたデザインで、ビジネスシーン向けの実用書としての“専門性”“明瞭性”を強調しています。
### 3. 第3枚画像:公式申請書(謝請求書)
この画像は**「模範商事株式会社」の公式申請書(謝請求書)**です。
- 公式的な文書であることから、上部にタイトル「御請求書」、請求番号「INV-2024-0820」、発送元情報(住所、電話・ファックス)が確認できます。
- 中下部は**項目別詳細(送付和紙(A4)・上級墨・筆セット)**の計上金額が記載されたテーブル形式で整理されており、合計小計(¥140,000)含税額(¥154,000)も明示されています。
- 底部に「担当者名(営業部 見本 太郎)」などの仕様が記記し、業務の正式性や記録性を重視した文書デザインが特徴です。
全体として、都市発行する公司が“特定の文房用品を購入するための申請”を行う標準的な業務書であることを伝える文書であることがわかります。
これらの画像は、「都市景観・ビジネス書・公式文書」の3つの異なる文脈を捉えており、それぞれが独自の主題とデザインスタイルを持ちます。
日本語の文字は概ね読めているけども、漢字が中国語になっているものがチラホラ・・・。あと日本に関する知識は流石に2Bだと足りないかも。
知識面については、そういえばOvis2でも確認してなかった(当時はOCR的な使い方を想定していたので)。ということでOvis2-8B / Ovis2.5-9B のデモで、上の神戸の風景画像を確認してみた。
なるほど、以前のOvis2-8Bでも日本の知識はそれほどなかったのかもしれないが、Ovis2.5-9Bだと一応神戸ということは認識できているみたい。
動画
適当な動画がないので、Qwen2.5-Omniのサンプルコードで使用されていた動画を流用させていただく。
Qwen2.5-Omniのサンプル動画では、タブレットで絵を書いている動画になっていた(以下は画像。)
動画をダウンロード
!wget https://qianwen-res.oss-cn-beijing.aliyuncs.com/Qwen2.5-Omni/draw.mp4
推論。動画はフレームに分割している様子。
from moviepy.editor import VideoFileClip
video_file = "draw.mp4"
num_frames = 8
with VideoFileClip(video_file) as clip:
total_frames = int(clip.fps * clip.duration)
indices = [
int(i * total_frames / num_frames)
for i in range(num_frames)
]
frames = [
Image.fromarray(clip.get_frame(t))
for t in (idx / clip.fps for idx in indices)
]
messages = [{"role": "user", "content": [
{"type": "video", "video": frames},
{"type": "text", "text": "この動画について詳しく説明して。"},
]}]
input_ids, pixel_values, grid_thws = model.preprocess_inputs(
messages=messages,
add_generation_prompt=True,
max_pixels=896*896,
enable_thinking=True,
)
input_ids = input_ids.cuda()
pixel_values = pixel_values.cuda().to(model.dtype) if pixel_values is not None else None
grid_thws = grid_thws.cuda() if grid_thws is not None else None
with torch.no_grad():
outputs = model.generate(
inputs=input_ids,
pixel_values=pixel_values,
grid_thws=grid_thws,
max_new_tokens=8196,
do_sample=True,
eos_token_id=model.text_tokenizer.eos_token_id,
pad_token_id=model.text_tokenizer.pad_token_id
)
response = model.text_tokenizer.decode(outputs[0], skip_special_tokens=True)
print(response)
<think>
用户现在需要详细描述这个视频关于绘图板和吉他绘画的过程。首先,得分析每个画面的动作和细节。
首先看视频主体:平板电脑(数码绘图板)上的吉他绘画,用户用触控笔(白色带银色部分)操作。画面主要人物是双手,左手托平板,右手拿触控笔。
步骤分解:
1. 起始画面:平板上已有部分吉他轮廓,右手在画,左手托着平板。背景是木质桌面,色调温暖,光线均匀,突出绘图动作。
2. 绘画过程:用户通过触控笔绘制更详细的吉他轮廓,包括吉他主体、琴身、弦轴等结构。可以看到过程中笔触的流畅,背景白屏,工具栏在顶部(绘图软件界面)。
3. 造型变化:从简单的轮廓到更精细的琴弦、琴头,逐步完善吉他造型。每个镜头都聚焦手部动作和画布变化,展示从草稿到成品的动态过程。
4. 环境与操作:桌面上木质纹理清晰,光线从上方或侧方打亮,让画面层次分明。用户的手部姿态稳定,左手固定平板,右手精准描绘,体现绘图时的专注和工具使用(触控笔操作平板)。
5. 动画连续性:多个镜头切换,展示不同阶段的绘图,比如添加琴弦、琴头细节,调整形状等。每个动作都清晰呈现,观众能看到绘画的步骤和成果渐变。
现在组织语言,把这些元素连贯起来,描述视频内容:
这个视频展示了一位用户用数码绘图板创作吉他的过程,通过手部动作和屏幕内容的变化,呈现从初始轮廓到精细完成的绘画步骤。画面中,平板放置在木质桌面上,用户左手稳稳托住平板,右手手持白色的触控笔在屏幕上绘制。
### 过程细节:
- **初始阶段**:屏幕上已有部分吉他的基本轮廓(如琴身形状、琴颈),右手在快速绘制,左手辅助固定平板,展现绘制的起始动态。
- **线条与细节添加**:用户通过触控笔逐步完善吉他形态,包括琴弦、琴头、按键等细节。每个镜头聚焦手部动作,清晰呈现笔触的流畅性与对细节的把控。
- **造型精进**:从简单的轮廓逐步向完整的吉他造型靠拢,琴身曲线、弦轴、琴头的细节在连续动作中逐渐清晰,突出绘图的精细度与创作的连续性。
### 视觉元素:
整体画面采用高光均匀的光线,木质桌面纹理自然,让环境清新;屏幕为纯白色画布,工具栏在上方,直观呈现数字绘图软件界面。手部动作稳定,左手托平板,右手灵活绘画,展现创作时的专注与熟练。
视频通过动态切换的手势与屏幕内容对比,完整呈现数码绘图板创作吉他的全过程,从草稿到成品的演变,让观众清晰感知数字工具在创意创作中的作用。</think>
この動画は**デジタルデバイス(タブレット型のデジタルツール)でギターを描画するプロセス**を、手と画面の動きを通して詳しく紹介します。以下に舞台裏と内容をステップごとに説明します。
### 【舞台裏・環境】
画面の主役はタブレットとその上に配置された**木目調のテーブル**、そして操作に使われている**白いタッチペン**です。手が左右対称に配置された構図で、「タブレットを安定させる左手」vs「描画を支える右手」の動きが繰り返されるルーティンを見せる。背景の光と色は明るく統一されており、タッチペンに白い光が当たる瞬間が特に印象的です。
### 【描画プロセスとステップ展開】
デジタルツール(タッチペン・画面設定)を使った作業は、「草稿→詳細な形状→最終ロール」の順に進みます。各ブロックの流れは以下の通りです。
1. **開始:基本の形との描画の連続**
タブレット画面には先のうの吉他的外形がわずかに確認でき、右手が画面いっぱいに広げて線を引く姿勢です。左手は体軸線のバランスを保ちながら固定。全体の流れが「誰が最初から描いてる」「素手で勾配を合わせる」ような素朴な動きで始まります。
2. **細部追加:弦・ヘッドなどの微細な表現**
オフホワイトのタッチペンが一貫して白い画布を滑らかに描く様子が視覚的に強調されます。画面の一部はまだ完璧ではない「線の連続」「形状の崩し合い」があり、右手が軽いペン押しづけながらも「弦を増やす」「ヘッドの細部を描く」「音穴の形を完成させる」など、徐々に精緻さを高めるアニメーションが続きます。
3. **完成への近さ:形の最終統合**
シェイプがほぼきつい場面でも、タッチペンを手首から握る指使いや「線が曲がる角度」「弦の細部の隙間を調整する動き」は一貫性を持ちます。画面の中央部に近づき、最終的に完成形として「吉他的外形が崩れなく安定した線画」「弦が均一に配置」「ヘッドの穴の小細工が丁寧に作られている」結果が明確に見えること。
### 【視覚的特徴と演出**】
- **ダイナミックなショット切り替え**:作業のどのステップにも「左手が画面の下部に閉じる」「右手が画面に曲線を描く」「筆先の光がタッチペンに当たる」などの瞬間が切り替わって描かれ、進行の途中を直感的に理解させます。
- **画面との連動**:デジタルツールの操作(タッチペンの挿入・押し分け、画面の画布の切り替え)とアーティストの手の動きが同時になすり、**「デジタルツールを使う」という動作」と「形を作る」という創造性の違い**を明確視させます。
- **環境との一体感**:木目調の背景は温かみを演出し、デジタル作業が日常の一場面(「机の上で何を作って行けるか?」感覚)を感じてもらいます。
### 【全体としての解説**】
この動画は**「デジタルツールを使った創造性」を通して、物理的な手の動き」「デジタル画面のコントロール」「素人のアプローチで完璧にできる形状の調整」のサプライズ演出**を含んでいます。単なる描画の動画ではなく、**「工具を使う楽しさ」「完成形への旅路」**を視覚的に伝える効果的な動画であることが分かります。
もし、何かの質問点があれば、デジタルツールの種類(タッチペンの使い方・画面設定の一例)、描画の難易度(線画→陰影→完成形)などを更に検討する視点でも理解しやすくなります!
その他
その他、以下のようなこともできるらしい。今回は割愛。
- テキストのみの推論も可能
- 特定のプロンプトでバウンディングボックスの座標を出力させることが可能
まとめ
Ovis2を初めて試したとき、軽量サイズでも日本語の文字をきちんと読み取ってくれるというところでとても感動した。それがあるので、自分の中で過去が美化されすぎてしまっているところはあるかもしれないが、以下がOvis-2.5の個人的な印象。
- Ovis2に比べて、モデルのバリエーションが減って、あと動かしてみた感じからはOvis2よりもリソース要件が高くなっている感(Ovis2はL4で8Bが十分動いていた)もあり、選択の幅が狭くなってしまった印象。
- Ovis2よりも日本語がちょっと怪しい、というか中国語の漢字がちらほら目立つような印象。
この辺を踏まえると、日本語で使うならばOvis2のほうがいまだ扱いやすいのでは?と感じる。試した限り文字の認識精度自体は悪くはないと思うし、また今回Reasoningにも対応したことでもおそらく精度は上がっているのだろうとは思うのだが、率直に自分はまだOvis2で十分かなと思ってしまった。このあたり、精度と使いやすさのバランスをどう考えるかは人それぞれ違うと思うので、各自で実際に試して判断すると良い。
ただReasoning対応VLMという流れは間違いなく今後も続きそう。