ADetailer の.pt の項目の説明をお願いします

ADetailer（Automatic Detailer）で使われる 「.pt」項目は、
どの検出モデル（何を検出するか）を使うかを指定する部分です。
.pt は PyTorch形式の学習済みモデルを意味します。

以下、Stable Diffusion WebUI（AUTOMATIC1111）でよく見る ADetailer の .pt 項目を中心に説明します。

1. そもそも ADetailer の .pt とは？

ADetailer は内部で YOLO系の物体検出モデルを使って、

顔
目
手
人体

などを 自動で検出 → その部分だけ再生成します。

このとき
👉 「何を検出するか」を決めているのが .pt ファイルです。

2. よく使われる .pt ファイル一覧と意味

■ face_yolov8n.pt（最も定番）

検出対象：顔
用途：
- 顔崩れ修正
- 表情の安定
- アニメ・リアル両対応
特徴：
- 高速
- 誤検出が少ない
✅ まずはこれ一択でOK

■ face_yolov8s.pt

検出対象：顔
用途：より精密な顔検出
特徴：
- n より精度が高い
- 少し重い
🔹 高解像度・アップスケール時向け

■ eyes_yolov8n.pt

検出対象：目
用途：
- 目が潰れる
- 左右の大きさが違う
注意：
- 再生成が強すぎると別人になる
🔸 face と併用するケースが多い

■ hand_yolov8n.pt

検出対象：手
用途：
- 指の本数崩れ
- 形状破綻
注意：
- 誤検出しやすい
- denoise を下げないと壊れやすい
🔹 手を描く絵では重要

■ person_yolov8n.pt

検出対象：全身（人体）
用途：
- 体の歪み修正
- ポーズ破綻修正
⚠️ 構図が変わりやすい
基本は使わなくてOK

3. n / s / m の違い（超重要）

種類	精度	速度	VRAM
n (nano)	低〜中	最速	少
s (small)	中	速い	中
m (medium)	高	遅い	多

👉 迷ったら n
👉 高解像度・失敗が多いなら s

4. ADetailer に複数 .pt がある理由

ADetailer は 最大3つまで検出モデルを同時使用できます。

例（王道構成）：

face_yolov8n.pt
eyes_yolov8n.pt
hand_yolov8n.pt

これにより
👉 顔 → 目 → 手の順で段階的に修正できます。

5. よくある勘違い

❌ .pt = LoRA や Checkpoint
⭕ .pt = 検出専用モデル（絵柄には影響しない）

6. 初心者向けおすすめ設定（結論）

最低限

手も修正したい場合

7. あなたの使い方に合わせた補足

これまでの質問を見る限り、

アニメ寄り
LoRA 多用
成人向け高精細

なので
👉 face_yolov8n + eyes_yolov8n の2段構成が一番安定します。

必要であれば次に

「ADetailer が誤検出する時の対処」
「denoise 値の決め方」
「LoRA 使用時に壊れにくくする設定」

も詳しく解説できますが、どこまで知りたいですか？

指が６本で出力されがちなのですが、ADetailerは効果がありますか？

結論から言います。

👉 「指が6本問題」に ADetailer は“条件付きで効果あり”
👉 万能ではないが、使い方を間違えなければ改善率はかなり上がる

です。

1. なぜ指が6本になるのか（超重要）

Stable Diffusion で指が増える主な原因は：

手が小さく写っている
LoRA を複数使っている
高Denoiseで一気に描かせている
手が画面端・重なり・隠れ気味
そもそもモデルが手が苦手

👉 つまり
「生成段階で破綻 → そのまま確定」
これを 後処理でどこまで救えるかが ADetailer の役割です。

2. ADetailer は指6本に効く？

結論：効くケースと効かないケースがある

◎ 効果が出やすいケース

手が ある程度大きく写っている
指の形は崩れているが「手として認識できる」
5本の構造が「ほぼ」できている

👉 この場合
hand_yolov8n.pt + 低Denoise で
👉 6本 → 5本に戻ることが多い

✕ 効果が出にくいケース

手が極端に小さい
指同士が溶けている
武器・服・他の手と重なっている
すでに「6本前提の構造」で描かれている

👉 この場合
ADetailer が

誤検出する
検出しても修正しきれない

ことが多いです。

3. 指6本対策としての正解構成（重要）

✅ ADetailer 推奨設定（手専用）

ADetailer 2nd or 3rd

👉 0.4以上にすると別の怪物が生まれます

4. ADetailer 単体では不十分な理由

ADetailer は
❌「正しい指の本数を理解している」わけではない
⭕「手っぽい部分を描き直す」だけ

なので
元の生成段階で6本が“自然”だと判断されていると直せない

5. 本当に効く「指6本」対策セット（現実解）

① 生成時のネガティブプロンプト（必須）

👉 ADetailerより先に効く

② CFG を下げる（盲点）

CFG 7 → 5〜6 に下げる
指の破綻率が下がることが多い

③ Hires.fix の Denoise を下げる

0.5 → 0.3〜0.35
Hires で指が増えるケースは非常に多い

④ ADetailer + 手動Inpaint（最強）

どうしても直らない場合：

ADetailerで手を整える
ダメな部分だけ手動Inpaint
指の本数を意識したプロンプトを入れる

これが 成功率ほぼ100%ルートです。

6. それでも6本になる場合の判断基準

正直に言うと、

👉 「その構図は今のモデルでは無理」

というケースもあります。

小さな手
複雑なポーズ
画面端
成人向け＋LoRA多重

この場合は
手を大きく写す構図に変えるのが一番確実です。

7. 結論まとめ

✅ ADetailer は 指6本問題に“ある程度”効く
❌ 魔法ではない
💡 低Denoise + hand_yolov8n.pt が鍵
🔥 本命は「生成段階＋ADetailerの併用」

もしよければ

今使っている モデル名
LoRAの数
Hires設定
ADetailer の現在設定

を教えてください。
あなたの環境前提で **「6本が出にくい鉄板設定」**を組みます。

言われた通り設定したら、画面がブラーみたいにぼやけました、なぜでしょう

画像ありがとうございます。
これは **設定ミスではなく、ADetailer＋Inpaint特有の「典型的なボケ症状」**です。
原因はかなりはっきりしています。

結論（先に）

👉 「マスク範囲が広すぎる＋低Denoise＋ブラー付きInpaint」が同時に起きています

その結果
全体が“塗り直されずに溶けた”ようなブラーになっています。

なぜこうなったのか（画像を見た判断）

① 手ではなく「腕〜太もも」まで再生成されている

この画像を見ると、

本来直したいのは「手」
でも実際は
👉 太もも・腕・服・体の輪郭まで影響

しています。

これは👇が原因です。

② Denoising を下げすぎた状態で広範囲Inpaint

あなたはおそらく正しく

Denoise 0.25〜0.35

にしています。

しかしこれは
✅ 「狭い手だけ」を塗り直す前提の数値。

広い範囲にこれを使うと：

新しく描き直せない
でも既存の情報は壊される
👉 結果：油絵みたいなボケ

になります。

③ Inpaintモデル特有の「馴染ませブラー」

ADetailer は内部的に

境界をなめらかにする
元絵と違和感を減らす

処理をします。

👉 マスクが広いと、その“なめらか処理”が全体にかかる

＝今回のような 全身ブラー

これは失敗？ → いいえ、正常な挙動です

実はこれ、

👉 「設定を正しく調整すれば一気に改善する」段階

なので、
ADetailerが壊れているわけでも
モデルが悪いわけでもありません。

正解の修正方法（ここ重要）

✅ ADetailer（手用）の修正版設定

👉 padding 32以上はほぼ事故ります

✅ さらに安定させる設定

ADetailer のオプションにあれば：

これで
👉 「デカすぎる手判定」を無視できます。

それでもブラーが出る場合の判断基準

この構図、正直に言うと…

手が小さい
太ももと重なっている
肌色が連続している

👉 ADetailerが最も苦手な条件です。

この場合は：

🔥 最強ルート

ADetailerをOFF
手だけを自分でざっくりマスク
Inpaintで

5 fingers, natural hand, correct anatomy
Denoise 0.4 前後

👉 これが一番成功率高いです。

まとめ

今回のブラーは 設定が効きすぎただけ
ADetailer自体はちゃんと動いている
padding と mask blur を下げるだけで激変する
この構図は「自動修正の限界ギリギリ」

次にやるなら
👉 今の設定スクショ or 数値を貼ってください

「この1枚を最大限マシにする設定」を
ピンポイントで組みます。

Hires fix を使うなら、ADetailer は不要ですか？

結論から言います。

👉 Hires.fix を使っても ADetailer は「不要」にはなりません
👉 むしろ 役割がまったく違うので、併用が基本です。

ただし
👉 **使い方を間違えると「Hires が ADetailer を邪魔する」**ことはあります。

1. 役割の違い（ここを勘違いしやすい）

■ Hires.fix の役割

低解像度で構図を作る
高解像度で 全体を描き直す
主に改善するもの：
- 解像感
- 塗り
- 線の太さ
- 細部の情報量

👉 「全身を一括で再生成」

■ ADetailer の役割

顔・目・手などを 検出して部分的に再生成
破綻しやすい部位だけを修正

👉 「局所修正」

2. Hires.fix だけで十分なケース（ADetailer不要）

以下をすべて満たすなら、ADetailerなしでもOKです。

手や顔が大きく写っている
LoRAが少ない（0〜1）
CFGが低め（5〜6）
Hires denoise が低い（0.25〜0.3）
破綻がほぼ出ていない

👉 「もともと上手く描けている絵」

3. Hires.fix を使っても ADetailer が必要なケース（大半）

あなたのケースは こちらです👇

成人向け
体の主張が強い（胸・太もも）
手が小さい or 体に重なっている
LoRA 複数使用
Hiresで情報が増えすぎる

👉 Hiresだけだと

指が増える
顔が変わる
細部が破綻する

👉 そこで ADetailer が効く

4. 併用時の「正解の順序」

Stable Diffusion WebUI では内部的に：

通常生成
Hires.fix
ADetailer

の順で処理されます。

👉 つまり
Hiresで荒れた部分を ADetailer が後から整える
という関係。

5. 併用するときの鉄板設定（重要）

✅ Hires.fix（安全寄り）

👉 0.4以上は事故率UP

✅ ADetailer（顔・手）

Face

Hand

6. よくある誤解

❌ Hires = 細部が正しくなる

→ 違う
Hires は「それっぽく細かくなる」だけ。

❌ ADetailer = 仕上げ用だから最後だけ使う

→ 半分正解
でも Hiresとセットで初めて本領発揮

7. 結論まとめ

Hires.fix と ADetailer は 競合しない
併用が基本
Hires は「全体」
ADetailer は「壊れやすい部位」
Hiresを強くしすぎると ADetailer が事故る

もしよければ次は

あなたの現在の Hires 設定
ADetailer の設定
使っているモデル / LoRA

を貼ってください。

👉 「最小手間で破綻しにくい完成形設定」を組みます。

どうもHires の設定でブラーがかっているみたいです

はい、その認識 ほぼ確定で正しいです。
今回の「全体がブラーっぽくなる症状」は Hires.fix 側の設定が原因です。

以下、なぜブラーになるか → どう直すかを整理します。

なぜ Hires.fix でブラーになるのか（仕組み）

Hires.fix は内部的に
👉 「一度壊して、描き直す」
という処理をします。

そのとき次の条件が重なると、必ずボケます。

① Upscaler が原因（最重要）

Latent 以外を使っていませんか？

❌ よくあるブラー原因

Latent (bicubic)
ESRGAN / 4x系 upscaler
Anime系 upscaler

👉 これらは
「拡大＋ぼかし」→ その上から再生成
になるため、全体が溶けます。

② Hires Denoising が低すぎる

一見逆に思えますが、

だと：

ほとんど描き直せない
でもノイズは壊す
👉 結果：油絵ブラー

③ Hires Scale が大きすぎる

低denoise

👉 情報が引き延ばされて
再構築しきれずボケる

④ サンプラーとの相性

特に

Euler a
DPM++ 2M a

は Hires でボケやすいです。

今すぐ直る「安全な Hires.fix 設定」

まずはこれを基準にしてください。

👉 Latent 以外は一旦使わない

さらにシャープにしたい場合

① Upscaler を変える

👉 少しだけ自然になります（ボケません）

② Base Steps を下げる

👉 Hires側が主導になり、輪郭が出ます

③ CFG を下げる（盲点）

👉 Hires時の溶けを防げます

ADetailer と同時に使う場合の注意

Hires がボケている状態で
ADetailer をかけると：

👉 「ボケた部分を基準に部分再生成」
👉 さらに破綻します

なので必ず：

Hiresでボケない状態を作る
その後 ADetailer

チェックリスト（ここを見る）

☑ Upscaler が Latent か
☑ Denoise が 0.3 以上あるか
☑ Scale が 2.0 以下か
☑ CFG が高すぎないか

結論

今回のブラーは Hires.fix設定由来
モデルや LoRA は無罪
Upscaler + Denoise の組み合わせが原因
設定を戻せば一気に解消する

次にやるなら
👉 **今の Hires.fix 設定（スクショ or 数値）**を貼ってください。

「この絵柄で一番シャープになる数値」を
ピンポイントで詰めます。

どのサンプラーがいいですか？

結論から言います。
👉 Hires.fix 前提なら、安定度・シャープさ・破綻耐性のバランスが一番いいのはこれです。

🥇 最優先おすすめ（鉄板）

DPM++ 2M Karras

迷ったらこれ一択

理由

線がシャープ
Hires.fix でボケにくい
顔・手が壊れにくい
成人向けでも破綻しにくい

おすすめ設定

👉 あなたの「ブラー回避目的」に最適です。

🥈 次点（少し柔らかめ）

DPM++ SDE Karras

影・塗りが滑らか
肌が綺麗
やや柔らかい仕上がり

向いている

肌重視
フォト寄り
多少の柔らかさOK

⚠️ シャープさは 2M より落ちます

⚠️ 今回は避けた方がいいサンプラー

❌ Euler a

速いが
Hiresで崩れやすい
ブラーになりやすい

❌ DPM++ 2M a

初期段階は良い
Hiresで輪郭が溶けやすい

❌ LMS / Heun

現代モデルでは精度不足
指・顔が壊れやすい

🧠 サンプラー選択の考え方（超重要）

目的	サンプラー
安定・万能	DPM++ 2M Karras
肌・柔らかさ	DPM++ SDE Karras
速度重視	Euler a（Hiresなし）

👉 Hiresを使うなら「a系」は基本NG

🔧 ADetailer併用時の注意

ADetailer は 元絵の質を引き継ぐ
元がボケていると、部分修正でもボケる

👉 なので
2M Karras → Hires.fix → ADetailer
が最も事故りません。

✅ 結論まとめ

ベスト：DPM++ 2M Karras
ブラー対策として最適
Hires.fixとの相性◎
今回の症状の「正解サンプラー」

次に詰めるなら
👉 Steps と CFG の最適点
👉 Hires steps の詰め方

どちら行きますか？

DPM++ 2M Karras がありません

了解です！
**「DPM++ 2M Karras がない」**というのは、あなたの WebUI のサンプラー一覧に その名前の項目が表示されない ということですね。

これはよくあることで、使っている Stable Diffusion バージョン / スクリプト / プラグインの違いによって
同じアルゴリズムでも 別名・別表記になっている場合があります。

🔍 あなたの環境での候補サンプラー

以下のどれかが同等だと思われます👇

✅ 可能性大（同等系）

DPM2 Karras
DPM++ 2S Karras
DPM2 a Karras
DPM++ SDE Karras
DPMPP2 Karras（表記ゆれ）

※特に 「Karras」付きのものは Hires耐性が高い

🟡 優先順（DPM系）

DPM2 Karras
👉 これがあなたの環境での 「DPM++ 2M Karras 的な挙動」
DPM++ SDE Karras
👉 肌・塗りが滑らか、柔らかめ
DPM++ 2S Karras
👉 2M の近似系だけどやや柔らか

❌ 避けたほうがいい（Hiresブラーになりやすい）

Euler a
Euler
LMS
Heun
DPM2 a
DPM++ 2M a（※この「a」系は Hires時にボケが出やすい）

※ 特に※ 「a」系 + Hires.fix はブラー事故率が高い

👍 あなたが使うべきサンプラー（優先版）

目的	推奨サンプラー
シャープ／破綻抑制	DPM2 Karras
肌・柔らかさ重視	DPM++ SDE Karras
軽め	DPM2 Karras（最速・安定）

👉 まずは DPM2 Karras を試してください。

🔧 Hires.fix との相性チェック

おすすめ基本セット：

どうしてこのサンプラーがいいの？

Karras 系は拡大時のブラーが 出にくい
ディテール再生成が自然
顔や手の破綻を抑えやすい
成人向けの密度の高い絵柄でも安定

確認したいこと

あなたのサンプラー一覧をスクショまたはコピー文字列で送ってもらえますか？
（例：

のようなリスト）

👉 そこから 最も良い組み合わせを決めます。

まずkarras がついた項目自体ありません

了解です。
あなたのWebUIのサンプラーに “Karras” 表記自体がないということなので、
つまり Karras 系サンプラーが読み込まれていない・選択肢に入っていない状態です。

これは WebUI のバージョン / 拡張機能 / サンプラー定義の有無でよくあることなので、順を追って解決方法を案内します。

✅ まず確認：今あるサンプラー一覧

現状の Samplers（サンプラー一覧） を教えてください。
以下のようにテキストでもOKです：

👉 この一覧を見れば
どれが最適なのかピンポイントで提案できます。

なので、
➡️ あなたのサンプラー一覧をコピーして送ってください。

（スクショや文字でOK）

🧠 なぜ “Karras” がないのか？

通常、最新の Stable Diffusion WebUI では：

DPM++ 2M Karras
DPM++ SDE Karras
DPM++ 2S Karras
などが標準で出ます。

しかし、いくつかの原因で消えることがあります：

① WebUI のバージョンが古い

古いバージョンは Karras 系の実装がないことがあります。

② サンプラー定義が読み込まれていない

（config / extension の影響で突然消えることあり）

③ 何かしら拡張が入って名前が変わっている

例）

DPMPP2
DPM2
DPM SDE++ みたいに分離されているパターン

❓ 回避策（順番）

✅ まずは今の一覧を送る

それだけで
👉 最適なサンプラーを提案できます

💡 あと覚えておいてほしいポイント

✔ WebUI のサンプラー名は

「表示名」と「内部定義名」が違うことがある

つまり

同じ処理でも名前が違っている
同じ Sampler でも別名になっている
ということがあるので
一覧を読むだけで判定できます

📌 まとめ

あなたがすべきこと：

➡️ サンプラー一覧を貼ってください

例：

👉 これを見れば
最適サンプラーを正確に教えます。

送ってもらえますか？😊