ヘッダー画像は、txt2img-gridsフォルダに自動保存されてる普段のグリッド画像から選べばいーやと思ったのですが……

くわ～っ!! 駄目だ駄目だ駄目だ!!

序文

皆さんは生成後にギャラリーに表示されるグリッド画像を見ていますか？

私はほとんどの場合、すべての画像の生成が終わるのを待たずにひよこ鑑定作業(=残すか削除するか)を始めてしまいます。先に出来上がった画像からMassiGraで1枚ずつ確認していきます。
MassiGraを愛用している理由は、キーボード右下の矢印キーにショートカット操作を割り当てできるからです。
・←→キーで前後のファイルに表示を切り替え
・↑キーまたは↓キーでファイルリストを更新
・Delキーで現在のファイルを削除
という割り当てにすると、鑑定中に新しい画像の生成が完了してもF5キーまで手を伸ばす必要がなくなる(↑キーで済む)ので、とても捗ります。
欠点は、2013/4を最後に更新が途絶えているという点ですね。ちょっとおすすめしづらいなぁ……。

一般的には、現在も更新が継続されているIrfanViewをおすすめしています。某wikiのよくある質問ページでもこちらを紹介する文を書きました。
ただ、私が1年くらい前に試した限りでは矢印キーへの割り当てができなかった記憶があります……。

たまにグリッド画像を見ることもあります。プロンプトやパラメータを調整する際、○○枚中の何枚で上手くできたか？という確認に向いていますね。
他にX/Y/Z plotもまあグリッド画像の兄弟みたいなものかな。

しかし、画像の出力先をHDDに設定した場合や、グリッド内に大量の画像を含む場合、あるいはVRAMを目一杯使用した場合などは、個々の画像生成が完了した後もグリッド画像の表示までに数秒かかる場合がありますね。
グリッド画像の保存と表示は、速度にどの程度影響しているのでしょうか？
記事タイトルに書いてあります
早速調べてみましょう！

テスト環境

• RTX 4070 (12GB) power limit 100%
  ドライバー 546.01 (2023/10/31) (共有GPUメモリは使用しない設定)

• animagineXLV3_v30 [1449e5b0b9]

• Size: 1024x1536, Steps: 15, Sampler: Euler a, Batch count: 5, Batch size: 1

• 画像の出力先: M.2 SSD gen3 INTEL SSDPEKNW010T8 1024GB (2018/9)

走者

• 1111 v1.7.0 (2023/12/16)
  --xformers

• Forge f0.0.12-latest-150-g3cdae096 (2024/2/12)
  --always-GPU

1111とForgeの比較については後日別のnoteを書く予定ですが、
Forgeでは--xformersを使わない方が若干高速になるようです。
　(参考) xformers N/A · Issue #150
私の手元でも同様の結果が出ています。ほんとにごく僅かな差なのですが。

また、Forgeでは出力画像の解像度を大きくすると、medvram的な機能が自動的に働いてしまい、速度低下の原因になってしまいます。
それを回避するために--always-GPUを使用しています。

速度比較

• ライブプレビュー
  Settings → Live previews → Show live previews of the created image

• グリッド画像の保存
  Settings → Saving images/grids → Always save all generated image grids

• グリッド画像の表示
  Settings → Gallery → Show grid in gallery

ライブプレビューについては5か月前に一度検証したのですが、まあ関連項目なので、今回も何となく。
　(関連note) Live previewsは生成速度に影響するのか？(答: デフォルト設定のままならほぼ影響しない) (2023/9/17)

Hires.fixを使わずに、1024x1536の画像5枚を直接出力しました。
人体が崩れるかどうか微妙な解像度だと思います。個人的にはちょっと胴体の長さが気になりがちなので、普段は768x1152にHires.fix x1.5をかけて1152x1728で出力することが多いです。2:3のアス比が好み。

それはさておき、どー見てもグリッド画像の保存と表示は生成速度に影響してませんね……。計測誤差でひっくり返ってるレベルでしょ、これ。
SSDだからってのもあるかなあ。1024x1536とはいえ、5枚程度では大した処理時間にならない、ってのもありそう。
何にせよ、この程度の時間的影響だったら、遠慮せずにグリッド画像を表示しても全然問題なさそうです。
それよりもストレージ容量や寿命への影響、グリッド画像フォルダを時々掃除する手間等の方がよほど考慮に値しそう。

ま、Forgeの方がちょびっとだけ高速ということも確認が取れたので、良しとしましょう。

使用VRAM量

今回はついでにVRAM量についても記録を取ってみました。

まあ、グリッド画像うんぬんは個々の画像生成が完了した後の処理なので、グリッド画像がよほど巨大にならない限りは、使用VRAM量のピークを更新することはないと思います。

1111とForgeの比較……は、また別の話かな。
でもVRAM 12GB環境ではあまり大きな差にはならない気もしています。