技術 約11分で読めます

Z-Image i2iでドット絵変換できるか試した

Z-Image 画像生成 Apple Silicon 実験
いけさん目次

Qwen Image Editで写真をドット絵に変換できるか試すで写真→ドット絵変換のパイプラインを5パターン比較した。結論はIllustrious i2i + pixel-art-xl LoRA（パターンE）が処理時間1:30、メモリ6.5GBで最速・最軽量だった。

ところが、もうひとつ試していない選択肢があった。Z-Imageのi2i。

このブログでもZ-Imageは何本か記事を書いている。FLUX・SDとの比較、RunPodでの動作検証、派生モデルの調査、蒸留版Z-Image-Distilled。ただドット絵変換の文脈では検討すらしていなかった。Z-Image用のピクセルアートLoRAが複数出ていると知って、調べた。

pixel-art-xl LoRAはZ-Imageで使えない

前回使ったpixel-art-xl v1.1はSDXL用のLoRA。IllustriousもSDXLベースだからそのまま動く。

Z-ImageはS3-DiT（Single-Stream Diffusion Transformer）という別アーキテクチャ。テキストと画像を最初から単一シーケンスで処理する方式で、SDXLのU-Net構造とはレイヤー構成が根本的に違う。LoRAはモデルの特定レイヤー（注意機構の重み行列など）に低ランク行列を挿入する手法なので、アーキテクチャが違えば互換性はない。

graph LR
    subgraph SDXL系
        A[pixel-art-xl LoRA] --> B[Illustrious<br/>WAI-SDXL]
        A --> C[NoobAI-XL]
    end
    subgraph Z-Image系
        D[Z-Image用<br/>pixel art LoRA] --> E[Z-Image Turbo]
        D --> F[Z-Image Base]
    end
    A -..->|互換性なし| E

つまりZ-Imageでドット絵変換するには、Z-Image専用のピクセルアートLoRAが必要になる。

Z-Image用ピクセルアートLoRA

調べたら複数見つかった。

LoRAプラットフォーム特徴
Pixel Art Style LoRAHuggingFaceSNES風レトロドット絵。強度0.6で細密、1.0でクラシック
PixelArt PerfectCivitaiピクセルシェーダー的な変換。トリガーワード pixelart
Elusarca’s Detailed Pixel ArtCivitai高ディテール寄り
ZIT - PixelSINCivitaiZ-Image Turbo専用

いずれもZ-Image Turbo向け。pixel-art-xl（SDXL用）が1つしかなかったのに対して、Z-Image用はすでに複数あるのが意外だった。Z-Imageのエコシステムが急速に育っている証拠かもしれない。

融合QKV注意機構の罠

Z-Image Turboは推論を高速化するためにQKV注意機構を融合（fuse）している。通常のLoRAはQ/K/V投影を別々に扱うが、融合QKVでは1つの結合行列になっているため、標準的なComfyUI LoRAノードでは読み込めない。

Comfyui-ZiT-Lora-loaderというカスタムノードが自動変換を担当する。Z-Image TurboでLoRAを使うなら必須。

Z-Image（基盤モデル、非Turbo）は融合QKVを使っていないので標準ローダーで動くが、ステップ数が28〜50と多く、ドット絵変換パイプラインの速度要件には合わない。

Amazing Z-Image Workflow

ComfyUIの統合ワークフローAmazing Z-Image Workflow v4.0もスタイルプリセットを持っている。

ワークフロー内容
amazing-z-image-a汎用スタイル（18種）
amazing-z-image-bユニークなスタイル
amazing-z-comicsコミック・アニメ・ピクセルアート系
amazing-z-photo写真系

amazing-z-comicsにピクセルアートプリセットがある。LoRA不要でスタイル変換できるなら手軽だが、LoRAほど強いスタイル適用は期待できない。txt2iメインのワークフローなので、i2iでの変換精度は未知数。

Z-Image-Edit: 編集特化モデル

Z-Imageシリーズには画像編集に特化した Z-Image-Edit もある。

モデルアプローチ用途
Z-Image Turboi2i + LoRAスタイル変換（ドット絵LoRAで変換）
Z-Image-Edit指示ベース編集「ドット絵に変換して」とプロンプトで指示

Qwen-Image-Editと同じ発想で、入力画像に対してプロンプトで編集指示を出す方式。Qwen Image Editで写真をドット絵に変換できるか試すのパターンAで試した「Qwenのみ（プロンプト強化）」と同じアプローチがZ-Image版でもできることになる。

img2imgやinpaintingにも対応しているとされ、ドット絵変換だけでなく部分的なスタイル変更も可能。公式によれば、人物の表情変更と背景の差し替えとキャプション追加を1回のプロンプトで同時に処理できるとのこと。

ウェイトは未公開（2026年4月時点）

ただし、Z-Image-Editのウェイトはまだ公開されていない。GitHubのmodel zooでは “To be released” のまま。HuggingFaceにもModelScopeにもウェイトはない。

モデル公開状況
Z-Image（基盤）公開済み（2026年1月）
Z-Image-Turbo公開済み（2026年1月）
Z-Image-Omni-Base未公開
Z-Image-Edit未公開

Webデモ（z-image-edit.com等）でAPI経由の利用はできるが、ローカルで動かすことはできない。ドット絵変換パイプラインに組み込むにはローカル実行が前提なので、現時点ではZ-Image-Editは選択肢に入らない。

公開されたらQwen Image Editで写真をドット絵に変換できるか試すと同じ条件で比較したい。Qwenは「なんちゃってドット絵」止まりだったが、Z-Image-Editはどうか。

パイプライン比較（予想）

graph TD
    A[元画像]
    A --> B1[Illustrious i2i<br/>+ pixel-art-xl LoRA]
    A --> B2[Z-Image Turbo i2i<br/>+ pixel art LoRA]
    A --> B3["Z-Image-Edit（未公開）<br/>プロンプト指示"]
    B1 --> C1[ドット絵<br/>1:30 / 6.5GB]
    B2 --> C2[ドット絵<br/>速度不明 / 20GB]
    B3 --> C3[ドット絵<br/>未検証]

Illustrious i2i（現行）

項目値
アーキテクチャU-Net (SDXL)
パラメータ数~6.6B
メモリ~6.5GB
推論ステップ25
LoRA読み込み標準ノード
処理時間(M1 Max)1:30

Z-Image Turbo i2i（候補）

項目値
アーキテクチャS3-DiT
パラメータ数6B
メモリ(BF16)~20GB(モデル12GB + エンコーダ7GB + VAE)
メモリ(量子化)~6GB(Q4_K_M)
推論ステップ8
LoRA読み込み専用ローダー必要
処理時間(M1 Max)不明

Z-Image-Edit（未公開）

項目値
アーキテクチャS3-DiT
パラメータ数6B
メモリ不明
LoRA不要(プロンプト指示)
公開状況未公開(To be released)

ステップ数だけ見ればZ-Image Turboの8ステップが圧倒的に少ない。ただしS3-DiTの1ステップあたりの計算量がU-Netと同じとは限らないし、テキストエンコーダにQwen 3 4B（7GB）を使っているぶん初回エンコードのオーバーヘッドもある。

メモリはBF16だとZ-Imageが3倍重い。量子化すれば6GBまで落ちるが、量子化でドット絵のエッジが甘くなる可能性はある。ドット絵はピクセル境界の鮮明さが命なので、ここは実際に出力を見ないとわからない。

セットアップ

環境はM1 Max 64GB + ComfyUI(Metal対応済み)。BEYOND_REALITY_Z_IMAGEの記事でZ-Image TurboがComfyUI + Metal環境で動作することは確認済み。BF16で約20GBなので64GBなら余裕。

モデルファイル

Comfy-Org/z_image_turboからComfyUI用の単一ファイル版をダウンロード。公式リポジトリ(Tongyi-MAI/Z-Image-Turbo)はdiffusers形式のシャード分割なので、ComfyUI用にはComfy-Org版を使う。

ComfyUI/models/
├── diffusion_models/
│   └── z_image_turbo_bf16.safetensors
├── text_encoders/
│   └── qwen_3_4b.safetensors
└── vae/
    └── ae.safetensors

LoRA

Pixel Art Style LoRAをダウンロードして ComfyUI/models/loras/ に配置。ComfyUIのワークフローでもデフォルトで指定されているLoRA。

カスタムノード

Comfyui-ZiT-Lora-loaderをインストール。Z-Image Turboの融合QKV対応に必須。

テスト1: txt2i(まず普通に出せるか)

Z-Image Turboで普通にテキストから画像を生成できるか確認する。ComfyUIの公式テンプレート「Text to Image(Z-Image-Turbo)」をそのまま使う。

設定

項目値
ステップ8
CFG1.0
サンプラーeuler
スケジューラsimple
解像度1024x1024

注意: —fp16-vae は使えない

ComfyUIを--fp16-vaeで起動するとZ-ImageのVAE(ae.safetensors)が正しく動かず、出力が真っ黒になる。Z-ImageのVAEはBF16が必要なので、--fp16-vaeなしで起動すること。

結果

Z-Image Turbo txt2i

普通に出た。プロンプトどおりの青髪キャラが生成されている。

  • 処理時間: 87秒(初回モデルロード込み)
  • BF16で約20GB消費

初回はモデルロードで時間がかかるが、2回目以降はキャッシュが効くので75秒前後。

テスト2: i2i(入力画像を渡せるか)

txt2iが動いたら、次は入力画像を渡してi2i変換できるか。Qwen Image Editで写真をドット絵に変換できるか試すで使った入力画像と同じかなちゃんのイラストを使う。

入力画像

設定

項目値
入力kana-il-source.webp
denoise0.6
プロンプト1girl, full body, pixel art style
他テスト1と同じ

denoise 0.6はQwen Image Editで写真をドット絵に変換できるか試すのIllustrious i2iテストと同じ値。元画像の構図を残しつつスタイルを変える強さ。

結果

入力
入力画像
Z-Image Turbo i2i
i2i出力

i2iも動く。元画像の構図とキャラクターの雰囲気を維持しつつ、Z-Image Turboの画風に変換されている。

  • 処理時間: 75秒

テスト3: i2i + pixel art LoRA(ドット絵変換)

本題。i2iにピクセルアートLoRAを載せて、ドット絵変換できるか。

設定

項目値
入力kana-il-source.webp
LoRApixel_art_style_z_image_turbo
LoRA強度1.0
トリガーワードPixel art style
LoRAローダーZImageTurboLoraLoader(auto_convert_qkv有効)

LoRAローダーは標準のLoraLoaderModelOnlyではなく、Comfyui-ZiT-Lora-loaderのZImageTurboLoraLoaderを使う。auto_convert_qkvを有効にすることで、融合QKV注意機構に自動変換してくれる。

標準LoRAローダーではLoRAが一切効かない。 実際に試したところ、LoRAなしのi2iと全く同じ出力が出た。記事前半で書いた「融合QKV注意機構の罠」の実証になった。

denoise別の比較

denoise 0.8
denoise 0.8
denoise 1.0
denoise 1.0

denoise 0.8ではドット絵にならない。元画像の影響が強すぎてLoRAのスタイルが潰される。denoise 1.0まで上げるとようやくピクセルアート風になるが、そこまで上げると元画像の面影はほぼ消える。

Z-Image Turboは8ステップしかないので、低denoiseだとLoRAによるスタイル変換のための「余地」が足りない。Illustriousは25ステップあるので、denoise 0.6でもLoRAが効く。ステップ数の少なさは速度の利点だが、i2iでのスタイル変換には不利に働く。

txt2i + LoRAは問題なし

参考までに、txt2i(入力画像なし)でLoRAを使った場合はちゃんとドット絵が出る。

txt2i + pixel art LoRA

LoRA自体は正常に動作している。Turboのi2iとの相性が悪い。

テスト4: Z-Image基盤モデル i2i + LoRA

Turboが8ステップでダメなら、基盤モデル(28-50ステップ)ならどうか。基盤モデルは融合QKVを使っていないので標準LoRAローダーで動く。

設定

項目値
モデルz_image_bf16.safetensors(基盤モデル)
ステップ30
CFG4.0
denoise0.6
LoRApixel_art_style_z_image_turbo(強度1.0)
LoRAローダー標準LoraLoaderModelOnly

Comfy-Org/z_imageからComfyUI用の単一ファイル版をダウンロード。テキストエンコーダとVAEはTurboと共通。

結果

入力
入力画像
Z-Image基盤 i2i + LoRA
基盤モデル ドット絵
Z-Image Turbo i2i + LoRA
Turbo ドット絵

LoRAの影響は出ているが、これはドット絵ではない。画像全体にノイズのような格子パターンがかかっているだけで、ピクセルのエッジもくっきりしていないし、減色もされていない。ただ掠れているだけ。Turbo用に作られたLoRAを基盤モデルに無理やり当てているので、スタイルの適用がうまくいっていない。

処理時間も520秒(8分40秒)。これだけ待ってこの品質では使い物にならない。

比較

Illustrious i2iZ-Image Turbo i2iZ-Image基盤 i2i
処理時間1:3075秒520秒
メモリ6.5GB~20GB~20GB
推論ステップ25830
denoise 0.6でLoRA効く効かない反応するが劣化のみ
LoRAローダー標準ノード専用ローダー必須標準ノード

どのルートもダメだった。

ルート結果
Turbo i2i + LoRA8ステップでは低denoiseでLoRAが効かない。denoise 1.0なら効くが元画像の面影が消える
基盤モデル i2i + LoRALoRAの影響は出るが、ドット絵ではなくただの劣化。520秒かけてこれ
Turbo txt2i + LoRAドット絵は出るが、i2i(入力画像の変換)ではないので用途が違う

Z-Image系でのi2iドット絵変換は現時点では実用的でない。Qwen Image Editで写真をドット絵に変換できるか試すの結論どおり、Illustrious i2i + pixel-art-xl LoRA(denoise 0.6、処理時間1:30、メモリ6.5GB)が最適解。