技術 約10分で読めます

Qwen Image Editで写真をドット絵に変換できるか試す

Qwen 画像生成 Apple Silicon 実験
いけさん目次

前回の記事でローカルVLMによるRPGパラメータ抽出を試した。あの記事の冒頭に書いた構想はこうだった。

写真をドット絵に変換して、RPGの戦闘シーン風の画像を自動合成するパイプラインを組みたくなった。

VLMでパラメータを抽出できることはわかった。次はパイプラインの入口、写真→ドット絵の変換を固める。

構想しているパイプライン

graph TD
    A[カメラで写真撮影] --> B[ドット絵に変換]
    B --> C[Vision LLM<br/>RPGパラメータ抽出]
    C --> D[戦闘シーン合成]
    D --> E[HP Sprocket 200<br/>ZINK印刷]

今回検証するのはBの部分。ドット絵変換の手段として、Qwen Image Edit（AI画像編集）とJSによるアルゴリズム的な減色・縮小を組み合わせて、どの手順が一番使えるか比較する。

テスト画像

Geminiで生成したキャラクターイラストを使う。後日、実写（フィギュア等）でも試す予定。

テスト用キャラクターイラスト

使う道具

Qwen Image Edit（mflux経由）

過去の記事で検証した通り、M1 Max 64GBでの最速構成はmflux + Lightning LoRA + 8bit量子化。ComfyUIなしでCLIから直接叩ける。

mflux-generate-qwen-edit \
  --image-paths input.png \
  --prompt "..." \
  --steps 4 --guidance 1.0 \
  --quantize 8 \
  --lora-paths Qwen-Image-Edit-Lightning-4steps-V1.0-bf16.safetensors \
  --lora-scales 1.0 \
  --output output.png

モデルはPhr00t AIO v16（Qwen-Image-Edit-2509ベース）。バージョン比較の記事ではv23（2511ベース）のほうがプロンプト追従性が高いとされているが、mfluxは現時点でEdit 2509のみ対応なのでv16で試す。

JS減色変換

ラボのドット絵変換ツールと同じロジック。画像をnearest-neighbor補間で縮小し、Median Cutアルゴリズムで減色する。ブラウザ上で動くツールだが、今回はNode.js + sharpでCLIスクリプトとして使う。

処理の流れ:

  1. 画像を指定サイズ（例: 長辺64px）にnearest-neighbor縮小
  2. Median Cut減色で指定色数（例: 16色）のパレットを生成
  3. 全ピクセルを最近傍のパレット色に置換

AIは使わない。純粋にアルゴリズムで処理するので一瞬で終わる。

3パターンの比較

graph LR
    A[元画像] --> B1[パターンA<br/>Qwenのみ]
    A --> B2[パターンB<br/>JS → Qwen]
    A --> B3[パターンC<br/>Qwen → JS]

    B1 --> C1[Qwen Image Edit<br/>プロンプトで指示]
    B2 --> C2a[JS減色・縮小]
    C2a --> C2b[Qwen Image Edit<br/>ディテール追加]
    B3 --> C3a[Qwen Image Edit<br/>プロンプトで指示]
    C3a --> C3b[JS減色・縮小]

パターンA: Qwen Image Editのみ（プロンプト強化）

プロンプトでがっつりドット絵を指示して一発変換を狙う。

Transform into low-resolution pixel art with visible square pixels,
like a Super Nintendo RPG character sprite, limited color palette,
no anti-aliasing, blocky pixelated style
入力出力
入力Qwenプロンプト強化

まあドットと言えばドットだが、なんちゃって感が強い。ドット感はほぼない。v16はキャラ追随性が高い分、スタイル変換の指示に追従しにくい傾向がある。

  • 処理時間: 2:30
  • メモリ: 約30GB

パターンB: JS減色 → Qwen Image Edit

先にJSでドット絵に落としてから、Qwenでディテールを追加する。

JS変換は長辺64px・16色で実行した。

JS変換後（64px, 16色）→ Qwen仕上げ
JS 64pxJS→Qwen

JS変換のドット絵をQwenに渡したら、ロボコップみたいになった。低解像度の入力に対してQwenが「補完」しようとして、余計なディテールを足した結果がこれ。造形が完全に崩れている。

もう一つの問題は速度。入力が512x910px（JSの64pxをnearest-neighborで拡大したもの）なのに5:10かかった。通常の2:30の倍以上。低解像度のブロック状入力はQwenの処理効率が落ちるらしい。

  • 処理時間: 5:10（通常の2倍）
  • メモリ: 約30GB

パターンC: Qwen Image Edit → JS減色

Qwenの出力をJSで後処理してドット絵化する。

Qwen出力→ JS減色（64px, 16色）
Qwen出力Qwen→JS

Qwenが出した「ドット絵っぽいイラスト」をJSで強制的に低解像度・減色に落とす。ドットではあるが、原型が残っているかは微妙なライン。ただ3パターンの中では一番マシで、Qwenがある程度線を整理してくれているおかげでJS減色後も形が崩れにくい。

  • 処理時間: 2:30（Qwen） + 一瞬（JS） = 2:30
  • メモリ: 約30GB（JS処理は誤差）

JS変換のサイズ比較

パターンCの後処理で、JS変換のサイズを変えた比較。

64px48px32px
64px48px32px

32pxまで落とすとスーファミ感が出てくる。64pxは情報量が多くて「小さい絵」感が拭えない。用途次第だが、RPG戦闘シーン用なら32〜48pxあたりがちょうどよさそう。

…と思ったが、実際に見てみると32〜64pxはただのモザイクにしか見えない。解像度を上げて再挑戦。

128px / 256pxで再挑戦

JS単体（元画像→JS減色）とパターンC（Qwen出力→JS減色）の両方で、128pxと256pxを試した。

JS単体（元画像から直接変換）

128px256px
JS 128pxJS 256px

JS単体は全然ダメ。ボケてるだけというか、怖い。減色＋縮小だけだと情報が落ちすぎて不気味の谷に落ちる。

パターンC（Qwen→JS）

128px256px
Qwen→JS 128pxQwen→JS 256px

こっちはQwenが線を整理してくれているおかげで、JS減色後もキャラの形が見やすい。256pxならドット絵として成立しなくもない。

パターンD: Qwen → Illustrious i2i + LoRA

ここまでのパターンA〜Cはどれも微妙だった。そこで手元に残っていたComfyUIのワークフロー（PixelArtチビテスト）を思い出した。WAI-Illustrious + pixel-art-xl LoRA + chibistylexl LoRAの組み合わせで、ドット絵スタイルのチビキャラを生成するやつ。

ただしこのワークフローはテキストからの生成（t2i）用で、キャラLoRA前提。本番パイプラインでは任意の写真が入力になるので、キャラLoRAは使えない。代わりにQwenの出力をi2i（img2img）として渡し、スタイル変換LoRAだけで回す。

graph LR
    A[元画像] --> B[Qwen Image Edit]
    B --> C[Illustrious i2i<br/>+ pixel-art-xl LoRA<br/>+ chibistylexl LoRA]
    C --> D[ドット絵]

設定

項目値
チェックポイントWAI-Illustrious SDXL v16.0
LoRA 1pixel-art-xl-v1.1 (strength: 0.7)
LoRA 2chibistylexl-v1-2 (strength: 0.8)
プロンプトchibi character, pixel art, dot art, 1girl, full body, simple background, white background
ネガティブlowres, bad anatomy, worst quality, low quality, blurry, realistic, photo, 3d
ステップ25
CFG7.0
サンプラーeuler_ancestral
denoise0.6

結果

Qwen出力（入力）→ Illustrious i2i + LoRA
Qwen出力Qwen→Illustrious

ピクセルのエッジがくっきりしていて、ちゃんと「ドット絵」に見える。Qwenが元画像の特徴を維持しつつ、Illustrious + LoRAが「ドット絵としての品質」を担保する役割分担がうまくハマった。

  • 処理時間: 2:30（Qwen） + 約1:30（Illustrious i2i） = 約4分
  • キャラLoRA不要なので任意の入力画像に対応できる

…と喜んだが、ここで疑問が湧いた。Illustrious i2iがドット絵に変換してくれるなら、Qwenいらなくない？

パターンE: Illustrious i2iのみ（Qwen不要）

元画像を直接Illustrious i2i + LoRAに突っ込む。Qwenを挟まない最短ルート。

graph LR
    A[元画像] --> B[Illustrious i2i<br/>+ pixel-art-xl LoRA]
    B --> C[ドット絵]

LoRAについて

今回使っているLoRAはどちらもCivitaiで公開されているSDXL用のスタイルLoRA。

  • pixel-art-xl v1.1: 画像をピクセルアート風に変換する。Civitaiの推奨設定では、プロンプトに「pixel art」を入れないほうがよく、出力後に8倍nearest-neighbor縮小するとピクセルパーフェクトになるとのこと
  • ChibiStyleXL v1.2: チビ（デフォルメ）スタイルに変換する。他のLoRAとの併用を前提に設計されている

パターンDではこの2つを重ねていたが、LoRAを重ねるとぼやける。ドット絵変換が目的ならpixel-art-xlだけでいい。

chibi LoRA有無の比較

pixel-art-xl + chibistylexlpixel-art-xlのみ
2LoRA1LoRA

正直あまり差がない。chibi LoRA（strength 0.8）をかけても頭身はほとんど変わっていない。denoise 0.6だと元画像の構図が強く残るので、chibiの効果が出にくいのかもしれない。いずれにしてもドット絵変換が目的ならpixel-art-xl単体で十分。LoRA1枚のほうが処理も軽い。

なお右端にグレーの縦ラインが出ているが、これは入力画像の幅（572px）がSDXLの推奨サイズ（8の倍数）に対して中途半端だったことによるVAEのアーティファクト。本番ではリサイズで回避できる。

結果

入力（元画像）→ Illustrious i2i
元画像直接変換

Qwen不要で普通にドット絵になった。

  • 処理時間: 約1:30（Illustrious i2iのみ）
  • メモリ: Illustrious 6.5GB（Qwen不要なので30GB節約）

パターンD vs E

D: Qwen→IllustriousE: Illustriousのみ
処理時間4:001:30
メモリ30GB + 6.5GB6.5GB
パイプライン複雑シンプル

見た目の好みでいうとQwenを通した方（D）のほうが味がある。Qwenが一度解釈し直している分、元画像と少し違うニュアンスが出る。ただ処理としてはEのほうが圧倒的にスマートで、パイプラインに組み込むならEが現実的。

速度・メモリまとめ

パターン処理時間ドット絵度備考
A: Qwenのみ2:30低なんちゃってドット絵
B: JS→Qwen5:10低ロボコップ
C: Qwen→JS2:30中原型は残るが納得いかない
D: Qwen→IL i2i（LoRA 2枚）4:00高ちゃんとドット絵、味がある
E: IL i2iのみ（LoRA 1枚）1:30高Qwen不要、LoRA最小、最速

パターンEが速度・メモリ・シンプルさすべてでベスト。Qwenの30GBもchibi LoRAも不要。Illustrious 6.5GB + VLM（Gemma 3 12B: 9.6GB）= 16GBで、64GBの4分の1しか使わない。LoRAも1枚で済むので処理も軽い。

印刷ターゲット

最終出力先はHP Sprocket 200（2x3インチ ZINK、668x1002px）。パターンEの出力は元画像のアスペクト比を維持するので、トリミングしてnearest-neighborで668x1002に合わせればドットのエッジがくっきり残る。

おまけ: Qwenが本当に必要な変換

ドット絵変換ではQwenの出番がなかったが、Qwen Image Editにしかできないことがある。「意味レベルの変換」、つまりキャラクターをモンスターに変えるような変換はLoRAでは不可能。

Transform this character into a Dragon Quest style monster,
cute slime-like creature inspired by the character's colors and outfit
入力DQスライム風悪魔風
入力DQモンスター悪魔風

スライム風は、よく見ると制服を「着ている」というより体に取り込まれている。赤ネクタイと紺スカートがスライムの体表に溶け込んでいて、捕食後みたいな状態。人型から離れすぎると元画像の要素が溶けるらしい。

悪魔風はサキュバスを指定したが、角と翼がごつすぎてドラゴン娘になった。ただ制服のまま人型を維持しているのはいい。元画像の特徴（髪色、服装、ポーズ）がそのまま残っていて、パーツを足す方向の変換はQwenが得意。LoRAは「見た目のスタイルを変える」だけだが、Qwenは「何であるかを変える」ことができる。パイプラインに「モンスター変換モード」のような分岐を入れるなら、Qwenの出番がある。

採用フローと次回の構成

ドット絵変換のパイプラインはパターンEで確定。

graph TD
    A[カメラで写真撮影] --> B[Illustrious i2i<br/>pixel-art-xl LoRA]
    B --> C[Vision LLM<br/>RPGパラメータ抽出]
    C --> D[戦闘シーン合成]
    D --> E[HP Sprocket 200<br/>ZINK印刷]

Qwenを外したことでパイプラインがシンプルになり、処理時間も4分→1.5分に短縮。メモリも大幅に軽くなった。

次回はカメラを繋いで実写入力のテスト、最終回で全フローを一気通貫で回す予定。