技術 約14分で読めます

AIイラストを漫画モノクロに変換するときグレスケではなくスクリーントーンにしたい話

AI 画像生成 ComfyUI LoRA 漫画 スクリーントーン 実験 Apple Silicon SDXL Qwen Z-Image Anima
いけさん目次

カラーのアニメ系AIイラストを、漫画原稿っぽいモノクロに変換したい。
ただ彩度を落とすだけならフィルタ一発で終わるけれど、それは漫画にはならない。原稿に見せるには、肌は白く抜き、髪や衣装の暗部は黒ベタかスクリーントーンで置き換え、影を網点や斜線で表現する必要がある。
ここを M1 Max のローカル ComfyUI で詰められないかをずっと触っていて、いまの段階での失敗の切り分けを残しておく。

大前提として、1 枚にかけられる時間は長くて 2〜3 分まで。「数時間回せば綺麗に出ます」では実用にならないので、検証中に応答が重くて 1 枚回すのが面倒になった時点で、その候補は早々に打ち切っている。品質と速度はトレードオフではなく、速度が成立しない時点で品質を語る前に落ちる、というスタンス。

元画像と、雰囲気として狙っているゴールはこの並び。

元画像

雰囲気としてのゴール

元画像はローカル WAI-Illustrious (SDXL) で出したカラーアニメ絵。ゴール側はそれを Codex に投げて漫画モノクロ化させた絵で、ほぼ同じ構図・同じ顔のまま、肌が白く抜け、髪と衣装暗部にトーンが入り、線が整理されている。Codex が出してきたこの仕上がりを、自分のローカル環境で再現できるかが今回の主題。

ちなみにこのブログの日記に載せているキャラ絵は過去ぶんの大半が Gemini の Gem 経由で、最近は Anima ベースで回した自前 LoRA に切り替えている。本文で Anima が候補に入るのはこの流れがあるため。

なぜ単純なグレスケでは漫画にならない

漫画原稿が漫画に見えるのは、影が「グレーの面」ではなく「網点・斜線・ハッチングの集合」になっているからだ。
ここで重要なのは網点の粒の大きさで、出力サイズに対して点が細かすぎると、人間の目が網点を統合してしまって結局グレーに見える。網点が漫画に見える条件は階調の量子化と粒の粗さの両方で、自動グレスケ変換が漫画に見えないのはここを満たしていないため。

つまり「明度を取って網点に置き換える」だけでも、最終解像度に合わせて十分に粗い点を、2〜4段階くらいに量子化して貼る必要がある。連続グレーで貼ると意味がない。

AI再生成系で起きること

AI に「漫画モノクロにして」と指示する系は、低denoiseだと色が消えず、高denoiseだと絵が変わる、という同じ壁に当たり続けた。

Qwen Image Edit

ローカルの Qwen Image Edit 2511 を Lightning 4steps で回した。
4ステップ設定でも 1 枚の応答に数分以上かかり、時間予算を即オーバーした時点で打ち切り。MPS 上の Qwen はもともと ComfyUI アプデ後に 10 分まで遅くなる件 を踏んでいて、最近のアプデで類似の劣化が再発している（その記事に追記済み）ので、検証ループ自体が成立しない。
仮に速度を許容しても、QIE は ポーズや角度を強めに指示すると造形側まで再解釈してくる傾向 があり、構図とキャラを固定したまま処理だけかける用途とは噛み合いにくい。今回の主軸からは外した。

SDXL + 漫画 LoRA で img2img

waiIllustriousSDXL に漫画系 LoRA を載せて img2img を試した。LoRA のメタデータを開くと、学習タグに monochrome greyscale hatching (texture) がしっかり入っていたので素直に効きそうな見立てだった。

SDXL + 漫画LoRA 比較

実際に出たのは、低 denoise だと色がほぼ残ったまま線だけ少し漫画寄りになる、上げていくと服のディテールから髪型まで変わる、という典型的な振り切り。monochrome をプロンプトに足しても、低 denoise では色を消し切る力が足りない。
組み合わせとして筋が良かったのは「ローカル後処理で先にモノクロ寄せした画像を入力にして、SDXL は低 denoise の整え役に回す」構成だった。AI に変換を全部任せず、変換の主導権はローカル側に置くという反転。

SD1.5 ControlNet Lineart

手元の SD1.5 用 Lineart ControlNet を counterfeitV30 と組み合わせて、線で構図を固定したらどうかを見た。

ControlNet Lineart 比較

Anime Lineart プリプロセッサが黒地白線を出し、それを ControlNet に流すと色が薄く残ったまま顔は崩れた。白地黒線に反転すると ControlNet の効きは強まったが、今度は黒背景・白アウトラインに寄った絵になった。SD1.5 系は SDXL より顔・衣装の保持が弱く、1 枚 100 秒前後かかるので試行ループも重い。
ControlNet が効くのは「構図を固定して描き直す」用途で、いまほしいのは「描き直さずに見た目だけ漫画にする」なので、軸からは外した。

Z-Image-Turbo

z_image_turbo_bf16.safetensors を ComfyUI に置いて i2i を回した。

Z-Image-Turbo direct i2i

カラー原画を直接食わせると、構図と顔の保持はかなり良い。崩れない。ただし色も同じくらい強く残るので、漫画化としては失敗。

ローカル前処理で色面分解 + 線整え + 肌白化を済ませた中間画像を、Z-Image 低 denoise で整えに行くのが現状一番マシだった。

Pre-tone + Z-Image 低denoise

色は消え、顔保持も実用範囲。ただし Z-Image が清書に回ると描き込みは整理寄りに減る。線の破断やトーンの機械感が根本的に解消するわけではなく、Turbo の蒸留特性も合わせて「補正としては有能、漫画密度を増やす役には向かない」という位置づけになった。

Anima Turbo (waiANIMA)

waiANIMA_v10 + anima-turbo-lora-v0.1、10steps / cfg 1.0 / er_sde の運用条件で確認。最初に Turbo LoRA を外して 30steps で回してしまい比較として不適切だったので、運用と同条件で取り直した。

txt2img で漫画モノクロを直接出させると、土台としては今回試した中で一番強い。

Anima Turbo txt2img manga

服・肌・線の整理は出る。ただし「新規生成」なので、元のキャラとは別人になる。

かなちゃん LoRA を重ねるとキャラ側の情報が強く出て、漫画モノクロが押し戻されて淡いグレスケや水彩寄りに戻ってしまう。

Kanachan LoRA + Anima Turbo

かなちゃん LoRA を弱めれば漫画化は戻るが、今度はキャラ固定が落ちる。いまのキャラ LoRA をそのまま重ねるだけでは漫画モノクロとキャラ固定の両立にはならない。

元絵を単純グレスケ化して i2i に入れる方向も試したが、denoise 0.48 ではきれいなグレスケ再描画にしかならず、0.62 にしてタグと自然言語でトーン語彙を盛っても基本グレスケのままで、スクリーントーンまでは行かなかった。

Anima グレスケ → i2i

Anima は Edit 系ではないので、このタイプの変換タスクで「同じ造形のままトーンだけ置換」は本筋ではない、というのが結論。txt2img の漫画モノクロ生成器としてはむしろ筆頭候補。

決定論的なローカル処理を詰める

AI に変換を任せる側で詰まったので、絵を勝手に書き換えない側（決定論的な画像処理）をどこまで持ち上げられるか試した。

最初の素朴な構成は、輝度から肌・暗部・背景を分けて、暗部を粗めの網点に量子化、最後に Canny / 色差エッジから抽出した線を黒で重ねる、というもの。v1 が粗い量子化版、v2 は色から「肌・茶髪・青衣装」を簡易分離して領域ごとに強度を変えた版で、髪寄り (v2 hair)・印刷風 (v2 print)・ハッチ (v2 hatch) の3方向を試した。

ローカル処理 v1 と v2 の方向違い（左上から原画 / Codexゴール / v1 coarse、下段が v2 hair / v2 print / v2 hatch）

網点を意図的に粗く、階調を 2〜4 段階に量子化したことで、グレスケ感はかなり消えた。一方で線抽出が荒く、色境界や影境界まで線として拾うので画面が汚れる。v2 で領域別にトーン強度を変えてだいぶマシにはなる。

v2 hair（線消しを入れる前で、これ単体でもかなり読める）

この v2 hair の単体だけ見ると、肌は白く抜け、髪に halftone が乗り、コルセット・蝶ネクタイ・フリルが普通に読める仕上がりにはなっていて、ここで止めても用途次第では使える水準には届いている。ぶっちゃけ小さく表示するとそれなりっぽく見える。ただし拡大するとフリルや髪の毛先で線と網点が密集して固く、髪の境界周りで黒が乗って細部が潰れる。この「線が暗部としてトーン算出に流れ込んでしまう」のが残課題。

ここで処理順を変えた。線がそのまま暗部としてトーン算出に流れ込んでいるのが原因なので、

  1. まず線画レイヤーを抽出する
  2. トーン密度算出用には、その線をいったん塗り潰して消した「色面だけの画像」を使う
  3. 色面から肌・髪・衣装暗部を判定し、肌は白、髪は中トーン、衣装暗部は濃トーンか黒ベタへ寄せる
  4. 最後に、最初に抜いた線画を黒で戻す

途中の試行 v3 では領域強度を強めすぎて、髪と衣装の暗部が大きな黒塊になり絵が完全に潰れた（下のパネル v3 failed）。そこから領域強度を引き戻し、線抽出と色面処理を分離したのが v6 で、ここで初めて噛み合った。

上段: 原画 / v2 (線を消す前) / v3 failed、下段: v6 fine / v6 print / Codex のゴール

v6 fine は線重視で網点を控えめにした版、v6 print は印刷想定で網点をしっかり乗せた版。線の黒さがトーン密度に混ざらないので、線周りの黒潰れが減り、髪のトーンと肌の白抜きが両立する。元絵の形は AI 再生成より圧倒的に保てる。
ただし、これは漫画というより「下手な絵」に見える。線は太くて硬く、トーンも均一に貼ってあるだけで意図を感じない。先の v2 hair が小さく表示すれば成立していたのと違って、v6 はサイズに関係なく違和感が出る。理屈の上では「線が暗部として混ざらない」処理として正しい方向に進んでいるのに、見た目としてはむしろ後退していて、これ単体では使えない。

決定論的処理は「絵を変えない」「再現性がある」が強みだが、漫画の説得力までは詰め切れない。

部位分離してから機械的に貼る筋

ここまでの試行は、トーン密度を画面全体に対して一括で決めようとしていた。これがそもそも筋が悪い。

漫画原稿は「肌」「髪」「衣装の明部」「衣装の暗部」「フリル」「装飾の金属」のそれぞれに対して、違う密度・違う角度・違うパターンのトーンが指定されている。手描きで「ここは60番、ここは50番、ここは黒ベタ」と部位ごとに指定を変えていくのが本質で、画面全体に均一な網点を貼って終わる v6 のような処理は、漫画とは別物の処理になっている。

この発想に最も近い構成は、過去に書いた See-throughでアニメ立ち絵を23レイヤーに自動分解する処理 を流用して、画面を部位ごとに分けてから、

  • 各レイヤーに対して、決定論的に違う密度・違う角度のドットパターンを貼る
  • 線画レイヤーは別途抽出して維持する
  • 最後に全部合成する

という流れにすること。AI は部位分解にだけ使い、トーン処理はすべて機械的に決めるので、再現性が出るし、絵の主導権を完全にこちら側に置ける。v6 で試した「線が混ざらないトーン処理」を、面ではなく部位の単位で実現する形になる。

See-through 本体は M1 Max では即動かない

記事を書きながら手元で See-through 本体を回そうとしたが、リポジトリ (shitagaki-lab/see-through) を clone して中を覗くと、common/utils/inference_utils.py の中で device='cuda' が複数箇所にハードコードされていた。LayerDiff パイプラインの VAE / trans_vae / UNet / text encoder すべてが cuda 固定で、bfloat16 も合わせて指定されている。

layerdiff_pipeline.vae.to(dtype=torch.bfloat16, device='cuda')
layerdiff_pipeline.trans_vae.to(dtype=torch.bfloat16, device='cuda')
layerdiff_pipeline.unet.to(dtype=torch.bfloat16, device='cuda')

requirements も torch==2.8.0+cu128 を明示で指定していて、CUDA 前提の構成。M1 Max で動かすにはコードを MPS 向けに patch し、依存関係を MPS ビルドで揃え直し、その上で 14GB 近いモデル（LayerDiff 9.5GB + Marigold 3.1GB + SAM 1.3GB）を落として配置する必要がある。これは 2〜3 分の検証ループに収まる作業ではないので、See-through 本体は時間予算内パスとして記録しておく。元の See-through 検証も RunPod で RTX PRO 6000 を借りて回している。

代わりに、ローカルで成立する近似版を回した

See-through 級の分解は無理でも、提案の骨子（部位ごとに違う密度のドットパターンを機械的に貼って合成）は HSV クラスタリングで粗いマスクを作るだけでも検証はできる。OpenCV だけで 1 秒以下に終わる。

部位分離は色のしきい値だけ。背景（明度高・彩度低）、肌（暖色・低彩度・高明度）、髪（茶系・中明度）、コルセット（暗い青）、青系装飾（蝶ネクタイ・差し色）、フリル（白寄り）、その他、の 7 区分。

HSV しきい値で粗く分離した部位マスク

その上で、各部位ごとに違う密度・違うセルサイズのドットパターンを乗せて、最後に DoG ベースの線画を黒で重ねた。肌と背景はトーンなしで純白、コルセットは黒ベタ、髪と装飾は中密度、フリルは超薄、というシンプルな割り当て。

部位ごとに違う密度のドットパターンを貼って合成した結果

結果として、はっきり言って絵としてはぼやけて散らかっただけにしか見えない。コルセットが黒ベタになっている・フリルが白いまま残っている、という割り当ての差は理屈では出ているが、HSV しきい値で振り分けたマスクが粗すぎて、髪と目と肌の境界が網点側ににじみ、DoG 線画も破断して画面全体が散らばる。「部位ごとの書き分け」と言える状態には到達していない。

このラウンドで確認できたのは、ポジティブな結果ではなく、むしろ逆の知見だった。

  • 提案の骨子（部位ごとに違う密度のドットを機械的に合成する）は、合成側の処理を雑に書いても回るくらいには軽い
  • 一方で、合成側がいくら正しくても、マスクの精度が低い時点で出力は破綻する。HSV 7区分では足りない
  • 結局、この方向の成否は「See-through 級のマスク（前髪と後ろ髪が分離されている、目が独立している、フリルと肌が分かれている）が手に入るかどうか」にすべて寄っている

つまり「マスクが雑なら合成は無意味」「合成だけ詰めても無意味」というのが今回の局所近似で取れた唯一の実用情報。本来狙っていた品質に届かせるには、See-through で精度のあるマスク + アルファ込みのオクルージョン補完をクラウドで生成 → マスクをローカルに持ち帰って per-region halftone composite を回す という分担に切り替える必要がある。

もう一本の筋、Anima にグレスケ専用 LoRA を載せる

ここまで「合成側で網点を貼る」前提で考えていたが、視点を逆にできる。Anima の txt2img は、それ単体だとすでに漫画モノクロをかなり綺麗に出している（前述の Anima Turbo (waiANIMA) 節 で出した絵で、服・肌・線・トーンが全部それなりに整理された状態で出てくる）。土台モデルが「漫画モノクロを描く」能力を持っている以上、合成は外注ではなく、モデル本体に出させてしまったほうが筋が通る。

その方向の LoRA は、

  • キャラ学習データを グレスケ + 黒ベタ + 線画だけで揃える（halftone / screentone は混ぜない、理由は後述）
  • カラー絵は学習データに 1 枚も入れない
  • これを Anima 系（漫画モノクロが出る土台）に乗せて学習する

という構成にする。学習データに色情報がなければ、LoRA はキャラ固定の信号として「色」を持てない。結果として、キャラの形状・髪型・顔立ち・衣装の構造だけが固定され、出力モードは Anima 由来の漫画モノクロに寄る。

これまでの「カラーかなちゃん LoRA + Anima」では、LoRA を強くするほど淡いグレスケや水彩寄りに押し戻されていた。グレスケ専用 LoRA はそもそもカラーを覚えていないので、この問題が原理上発生しない。

halftone を抜く理由は VAE 側にある。混ぜると VAE エンコード/デコードを通る間に dot pattern が潰れ、LoRA が覚えるのは halftone そのものではなく、崩壊形の汚いグレスケになる。Illustrious や Qwen Image にプロンプトで screentone halftone を足しても綺麗な網点が出ず、薄いグレスケに寄った絵が出るのは、学習データ側で halftone がベタやグレスケと混在して dot が壊れたまま記憶された結果と見るのが自然。

幸い、Anima base は txt2img で既に halftone を綺麗に出してくれる。だから LoRA 側は halftone を覚えなくていい。LoRA はキャラの形状と、白・グレー・黒ベタの面の配置だけを覚えればよくて、推論時に halftone は Anima base が乗せる。LoRA はカラー情報を持たないキャラ条件付けだけを供給する分担。

他の土台モデルは今回の用途では落ちる。

候補不採用理由
WAI-Illustrious過去に同じ方向で試したが、出力が「ドット」ではなく荒いグレスケに寄り、漫画原稿のトーンには届かなかった
Z-Image / Z-Image-Turbo入力に対して精細に書き直そうとする傾向が強く、トーンを保ったまま走らせる用途と噛み合わない
Qwen Image + LoRAQIE と同じく書き直しが発生する見込み。さらに M1 Max での実行コストが時間予算（2〜3 分）を即超える

結局、漫画モノクロを安定して出せる土台でかつ自分の手元で回せるのは Anima しかない、という形になる。本案は、上の See-through 部位分離 + 合成と独立に成立する。Anima txt2img の品質を見るに、こちらのほうが実装コストは低い。

ただし上はあくまで仮説段階で、実際にやってみないと何とも言えない。「LoRA がそもそもグレスケでは出力しない」「halftone を混ぜなくても VAE 越えで dot 側が崩れる」あたりで方針自体が破綻することも普通にあり得る。

前回 Anima 向けキャラ LoRA を 12,000 ステップまで回した時 は、学習データ自体は過去に整備済みでキャプションを微修正しただけ、それでも学習 + 当たりエポック抽出までで 17 時間かかっている。今回は学習データをグレスケ専用に新規生成するパイプラインを組むところから始まるので、丸 1 日以上は確実にかかる見込み。

正直前回の記事みたいにグレスケのかなちゃんを延々と並べて、またゲシュタルト崩壊すると精神に異常をきたしそうなんで、多分お料理番組並みに「ここに完成したLoRAがあります」からスタートする、予定…