生成されたバケット
このベースモデルと刻みでの学習解像度（総ピクセル数を native 付近に保つ）。ここに画像をドロップ
読むのは幅×高さだけ — 画像データはブラウザの外に出ません。
画像か寸法を追加すると、どのバケットに振り分けられるか表示します。
| 収まり | 元画像 | 比 | バケット | 倍率 | クロップ |
|---|
LoRA や DreamBooth を kohya_ss / sd-scripts などで学習するときに使う、アスペクト比バケット（bucketing）の振り分けプレビューです。ベースモデル（SDXL=1024・SD2.x=768・SD1.5=512）とバケット刻み（64／32／8）を選ぶと、そのモデルが学習した native な総ピクセル数を保ったままの学習解像度（バケット）一覧を生成します。続けてデータセットの画像をドロップ（または「1920x1080」のように寸法を直接入力）すると、各画像が比のいちばん近いバケットへ割り当てられ、cover で合わせるための倍率・拡大が必要かどうか・センタークロップで切り落とされる割合を一覧表示します。各行の小さな図は、スケール後の元画像（赤）と残るバケット領域（緑）を寸法から描いたもので、どの方向がどれだけ切れるかが直感で分かります。kohya の bucketing は「アスペクト比ごとにバケットを作り、画像を一番近いバケットに寄せてセンタークロップする」挙動なので、極端な縦長・横長の画像は端が大きく切れたり、小さい画像は拡大（no-upscale を切っている場合）されたりします。学習を回す前にこの振り分けを把握しておくと、構図の端が切れる・顔が見切れるといった事故や、無駄な拡大によるボケを避けられます。読み取るのは画像の幅×高さだけで画像の中身はデコードしてもどこにも送信せず、計算もすべてブラウザ内で完結します。アップロードは一切ありません。
使い方
- ベースモデル（SDXL=1024・SD2.x=768・SD1.5=512）とバケット刻み（64が標準）を選びます。生成されるバケット一覧がすぐ更新されます。
- データセットの画像をドロップ（複数可）するか、「1920x1080」のように寸法を直接入力して追加します。読むのは幅×高さだけです。
- 各画像のバケット・倍率・クロップ割合と小さな模式図を見て、端が大きく切れる画像や拡大される画像を学習前に把握します。
よくある質問
画像はサーバーにアップロードされますか？
いいえ。画像は寸法（幅×高さ）を読むためにブラウザ内でデコードするだけで、ファイルもサイズもどこにも送信しません。バケットの計算もすべて端末内で完結します。寸法だけを手入力して使うこともできます。
ここで出るバケットは kohya の結果と完全に一致しますか？
考え方（面積を native 付近に保ち、刻みの倍数で幅×高さを作り、画像を比の近いバケットへ寄せてセンタークロップする）は kohya_ss / sd-scripts の bucketing と同じ筋です。ただし min/max のバケット解像度や no-upscale、丸めの細部は学習スクリプトの設定で変わります。本ツールは『どの画像がどの程度切れる／拡大されるか』の目安を素早く掴むためのもので、最終的な値は使用するスクリプトの設定に従ってください。
「拡大」バッジは何を意味しますか？
その画像がバケットを覆うために拡大（倍率が1より大きい）される、という意味です。no-upscale を有効にして学習する場合、拡大される＝元が小さい画像は画質が甘くなりやすいので、解像度の高い素材に差し替える判断材料になります。
クロップ割合とは何ですか？
割り当てられたバケットに合わせて cover で拡大縮小したあと、センタークロップで切り落とされる面積の割合です。「ぴったり」はほぼ切れない（比がバケットと一致）、数値が大きいほど端が大きく切れます。極端な縦長・横長の画像で大きくなりがちです。
バケット刻みは64と32・8のどれにすべきですか？
SD/SDXL の標準は64です。32や8にするとバケットが増えてアスペクト比により細かく合わせられ、クロップは減りますが、解像度の種類が増えて学習のバッチがまとまりにくくなります。まずは64で確認し、特定の比でクロップが気になるときに細かくするのがおすすめです。
縦横の向きは関係ありますか？
はい。バケットは縦長・横長の両方が生成され、画像は向きを含めて比が最も近いバケットへ割り当てられます。例えば横長写真は横長バケットへ、縦長イラストは縦長バケットへ寄せられ、それぞれ反対方向の端が切られます。