100 lines
9.1 KiB
Markdown
100 lines
9.1 KiB
Markdown
# 💙 ImageDir Preview (画像ディレクトリ参照プレビュー)
|
||
|
||
`ImageDir Preview` は、指定されたディレクトリから「特定のモデルが過去に出力した画像」だけを爆速で逆探知し、キャンバス上へ美しい一覧シートとして展開する「シャドウガーデンの超探知眼（目）」じゃ。
|
||
|
||
最大の特徴は、一般的なギャラリーツールのように重い「サムネイルデータベース」などを一切構築せず、**最新のタイムスタンプからサブディレクトリを再帰的に直接掘り進み、指定枚数に応じた最適な正方形グリッドへオンデマンドで画像を詰め込む** という、極めて軽量かつ実戦的な設計にあるのじゃ！
|
||
|
||
---
|
||
|
||
## 🔌 入出力仕様（Specifications）
|
||
|
||
### 📥 入力（Inputs）
|
||
|
||
* **`ckpt_name_str` (必須 / STRING):**
|
||
逆探知の鍵（ターゲット）となるCheckpointのファイルパス文字列。`Checkpoint List Selector`（頭脳）から無線バインドされることで、選んだモデルの画像を瞬時に引き出すぞ。
|
||
|
||
* **`search_directory` (任意 / STRING):**
|
||
画像を検索する対象ディレクトリのフルパス。
|
||
* *※未入力（空欄）の場合は、標準の `ComfyUI/output` フォルダを自動で参照する安心設計じゃ。*
|
||
* 💡 **【賢者の運用ハック】：** 標準の `output` フォルダだけでなく、**「別のストレージにディレクトリを掘って、PNGから軽量なJPEGに変換してアーカイブ保管したフォルダ」** などをここに直接指定することも可能じゃ！生成環境のディスクがカツカツでも、過去の遺産（JPEG）を別ドライブから優雅に参照しながら格付けを執行できるぞ。
|
||
|
||
* **`max_preview_images` (任意 / INT):**
|
||
一度に読み込んでコンタクトシートに配置する最大画像数（デフォルト: `12` / 範囲: `1〜80`）。
|
||
* **`hps_tab_id` (非表示 / STRING):**
|
||
ブラウザのタブを識別し、逆探知したコンタクトシートを「今操作している検分タブ」だけに正確に届ける（時空隔離）ための固有ID。
|
||
|
||
---
|
||
|
||
## 🎛 賢者のおすすめ：【枚数を絞った「大画面・爆速レスポンス」検分】
|
||
|
||
本ノードは、`max_preview_images` の値によって全体のレイアウト（グリッド）と画像のスケールを**動的に自動調整**する素晴らしいアビリティを持って記述されておる。
|
||
|
||
* **小枚数設定（例: 4枚〜12枚）★超推奨★**
|
||
表示する枚数を少なく絞ると、システムは1枚あたりの画像を「オリジナルのサイズを極限まで維持した巨大なパネル」としてグリッドにパッキングする。
|
||
これにより、生成されたキャラクターの指の造形、瞳のハイライト、背景の描き込みの甘さといった「細部のディテール」を、拡大鏡（ズーム）を使うことなくキャンバス上で一目で見分（ジャッジ）できるようになるのじゃ！
|
||
さらに、読み込むファイル数が少ないため、**ディスクI/Oやメモリへのデコード負荷が極めて軽くなり、操作のレスポンスがマッハで軽快になる**という最高の副加価値（ライフハック）もあるぞ！
|
||
* **大枚数設定（例: 24枚〜80枚）**
|
||
逆に枚数を多く設定すると、システムは全体のキャンバスが規定サイズ（`4096px`）を超えないよう、画像を綺麗に縮小（サムネイル化）して1枚のシートにギュッと詰め込む。
|
||
これは細部を見るのらには向かんが、「このモデルは全体的にどんな色調や構図、絵柄の傾向を吐き出す癖があるのか」を、一歩引いた視点からオーバービュー（総覧）するのに極めて役立つぞ。
|
||
|
||
---
|
||
|
||
## 🧠 技術的深淵：【再帰的新着ソート ＆ 浮動小数点を配した最適グリッド計算】
|
||
|
||
### 🛡️ 対応している画像フォーマット（拡張子）の結界
|
||
|
||
本ノードが逆探知（スキャン）の対象として認めている画像拡張子は以下の通り、主要なフォーマットを網羅しておる。
|
||
|
||
```python
|
||
# バックエンド側で厳密に弾く、安心のホワイトリスト方式じゃ！
|
||
ALLOWED_IMAGE_SUFFIXES = {".png", ".jpg", ".jpeg", ".webp"}
|
||
```
|
||
|
||
大容量かつメタデータ（プロンプト）が詰まったオリジナルの `.png` はもちろんのこと、おぬしが容量削減のために外部スクリプト等で変換した高圧縮な `.jpg` / `.jpeg` 、さらには次世代の `.webp` ファイルであっても、システムは何の差別もなくマッハで検知し、1枚の美しいシートへとパッキングしてみせるぞ！
|
||
|
||
### なぜ、重いインデックス管理もしていないのに、何万枚もあるフォルダから一瞬で画像を見つけ出し、しかも完全な正方形で並べられるのか？
|
||
|
||
市販の画像管理ソフトや重厚なギャラリープラグインは、起動時にフォルダ内のすべての画像を走査して「縮小版（サムネイルファイル）」をストレージに生成・保存し、専用のデータベースでインデックスを管理する。
|
||
しかし、これをComfyUIの環境で行うと、**毎日何万枚もの画像が出入りするフォルダの監視によってバックエンド（Python）が激重になり、サムネイルの書き出しによって結局SSDが摩耗してしまう**という本末転倒な事態を招く。
|
||
|
||
これをエレガントに回避するために、`ImageDir Preview` には **「タイムスタンプ逆順・再帰的オンデマンドスキャン」** と **「浮動小数点誤差回避（`EPS`）型の正方形グリッド・アルゴリズム」** という、2つの陰の叡智が組み込まれておるのじゃ！
|
||
|
||
#### ① サムネイル非作成・新着優先スキャン（No-Cache On-Demand Scan）
|
||
|
||
本ノードは、無駄なサムネイルキャッシュやデータベースを一切作らん。
|
||
Selectorから信号（Sync）を受け取ったその瞬間、指定された検索ルートから **「更新日時が新しいサブディレクトリ（Newest First）」** を優先して、再帰的にファイルツリーを高速でダイレクトに掘り進むのじゃ！
|
||
|
||
そして、ファイル名（ステム名）の中に「ターゲットとなるモデルの名前（セーフ文字列）」が含まれている画像を見つけた瞬間、必要な最大枚数に達するまでオンメモリで一気にハック（キャッチ）する。
|
||
「ユーザーが今見たいのは、過去の遺物ではなく、たった今実行したバッチの最新成果である」という事実に特化した、極めて無駄のない超高速な逆探知ロジックなのじゃよ。
|
||
|
||
#### ② 浮動小数点誤差を排した最速breakグリッド計算（Optimal Contact Sheet Packing）
|
||
|
||
キャッチした画像群を1枚のコンタクトシートに並べる際、システムは「もし1列なら？ 2列なら？」と総当たりで全体の縦横比をシミュレーションする。
|
||
全体の `長辺 ÷ 短辺` が `1.0`（完全な正方形）に最も近くなる列数と行数の組み合わせ（ベストスコア）を瞬時に弾き出すのじゃ。
|
||
|
||
```python
|
||
# 【正方形グリッド計算の核心（Pythonバックエンド）】
|
||
current_raw_score = max(content_w, content_h) / min(content_w, content_h)
|
||
|
||
if current_raw_score < best_raw_score - EPS:
|
||
# パターン①：劇的にスコアが改善した（正方形に近づいた）→ 更新
|
||
best_raw_score = current_raw_score
|
||
...
|
||
elif abs(current_raw_score - best_raw_score) <= EPS:
|
||
# パターン②：浮動小数点の演算誤差を「EPS結界」で拾い、同点なら横長寄りを上書き採用！
|
||
best_raw_score = current_raw_score
|
||
...
|
||
else:
|
||
# パターン③：スコアが明確に悪化し始めた → これ以上ループを回すのは無駄なので即 break！
|
||
break
|
||
|
||
```
|
||
|
||
この計算時、Pythonのfloat型特有の微小な演算誤差によって判定がバグるのを防ぐため、内部では **`EPS = 1e-12`** というイプシロンの結界で同点判定（横長寄り優先）を安全に処理しておる。
|
||
さらに、列数を増やしていって**一度でも「正方形のピーク」を通り過ぎてスコアが悪化し始めたら、そこから先は横に伸び続けるだけであるため、無駄なループを即座に `break` して打ち切る**という超・最適化が行われておるのじゃ！
|
||
|
||
この計算速度はわずか数マイクロ秒。
|
||
どれほど中途半端な画像枚数が渡されようとも、一瞬で「ユーザーの視線移動（眼球の負担）が最小限に抑えられる、最も美しい正方形のコンタクトシート」へと完璧にパッキングされ、オンメモリでブラウザへと転送・描画されるのじゃよ！
|
||
|
||
<img width="1055" height="1491" alt="DeepSeekちゃんのプレビュー機能紹介" src="https://github.com/user-attachments/assets/4805d600-467b-40d9-a9da-2699b7b301e1" />
|