WBPP 完全ガイド：インターフェース、マスターキャリブレーションフレーム、そして実行パイプライン
本記事は 2021–2024 年のメモをまとめたものです。一部のツールやワークフローはその後更新されているため、お読みの際はご留意ください。文中で触れているインターフェース、オプション、バージョン固有の挙動（2.1.2、2.5 など）は、いずれも当時の状態です。実行時に遭遇するエラーや既知のバグについては、別記事「WBPP トラブルシューティング」をご覧ください。
WBPP（WeightedBatchPreprocessing）は、PixInsight で「キャリブレーション・位置合わせ・インテグレーション」を一気通貫で自動実行してくれるスクリプトで、驚くほど便利です。ここ数年は改版が頻繁で、私もあちこちに断片的なメモを書き溜めてきました。この記事では、それらをまとめて比較的まとまった一本の解説にし、三つのレイヤーに分けて語ります。バージョンが変わってもあまり変わらない核となる考え方、現行の実行フロー、そして歴代バージョンでのいくつかの重要な変化です。どのバージョンを使っていても、まず考え方をしっかり押さえておけば、インターフェースがどう変わっても慌てずにすみます。
核心となる考え方 その 1：WBPP がスタックした成果物は、あくまでプレビュー
これは私が真っ先に伝えたい点であり、同時に最も多くの人が見落としている点でもあります。
私自身も落とし穴にはまりました。あるとき Drizzle Integration を使ったあと、星の中心（飽和した部分）が真っ黒になっていることに気づいたのです。原因を追っていくと、元凶は WBPP でインテグレーションしたことにありました。
WBPP は便利は便利ですが、それが自動でスタックして出力するマスターライトについて、公式の見解は非常にはっきりしています——それは「達成しうる仕上がり」を手軽に確認するためのプレビューにすぎず、使い終わったら捨てるべきもので、正式な成果物として扱ってはいけない、と。公式がフォーラムで返した回答を、以下に抜粋します。
The integrated image generated by WBPP is just a convenience preview of the achievable image, but it should always be deleted/ignored, and the integration should always be done manually with the registered frames. This is the only way to obtain an optimal integrated image with full control over the normalization, pixel rejection and noise reduction tasks.
公式はさらに半分冗談めかして、この一言を「n+1 回、ただし n はすでに無限大に近い」ほど繰り返したい、とまで言っています。つまり、WBPP が生成するマスターライトは正式な用途に使うべきではなく、あくまでプレビューであって、最良の結果は手動の Image Integration でピクセルリジェクションと S/N 比を最適化してはじめて得られる、ということです。
そこで私の習慣はこうです。WBPP は「スターレジストレーション（位置合わせ）」のステップまでしか使わず、本当のインテグレーションは Image Integration の手動処理に戻す。 正攻法のプロセス分割——キャリブレーション（WBPP に任せる）、位置合わせ（Star Alignment）、インテグレーション（Image Integration）——は、手順こそ数ステップ増えますが、いざ問題が起きたとき、どの工程が壊れたのかを突き止めやすくなります。これは後々、私の確固たる持論になりました。初期の日本の愛好家の方による、あの二本のとても詳しい WBPP 解説動画も私は大いにおすすめしますが、同じく一言だけ添えておきたいのです——インテグレーションの結果は参考程度に、と。
核心となる考え方 その 2：Master フォルダの中で、どれが成果物なのかを見分ける
WBPP をひととおり実行し終えると、デフォルトの Master フォルダの下にはたくさんのファイルが並び、どれが自分の欲しい 1 枚なのか分からないという方が少なくありません。ここで説明しておきます。
- 赤枠の画像が、あなたの欲しいインテグレーション済みのマスターライトです。
- 黄枠の画像は Local Normalization の参照（Ref）画像であって、マスターライトではありません。混同しないように。
- 枠のない画像はマスターキャリブレーションフレームで、ここにはマスターフラット、マスターバイアス（bias）、マスターダークが含まれます。
（とはいえ前節のとおり、この「マスターライト」も WBPP のプレビュー的な性格のものなので、こだわるなら自分でもう一度インテグレーションし直すべきです。）
現行の実行フロー：カラーカメラのフルコース
WBPP はワンクリックで最後まで走りますが、その裏では実際には順番に実行される自動化プロセスの長い連なりが動いています。カラー（OSC）カメラを例にとると、完全な実行順序は次のとおりです。
- Calibration File Integration：マスターキャリブレーションフレームを作成
- Calibration：ライトフレームをキャリブレーション
- Cosmetic Correction：ホットピクセルや不良ラインを除去
- Debayer：デベイヤー（RGB を分離）
- Measurements：ライトフレームを測定し、重み付けを行う
- Reference frame selection：位置合わせの参照画像を選定
- Plate solving reference frames：参照画像をプレートソルブ（天体測定）
- Registration：スターレジストレーション（位置合わせ）
- LN reference generation：Local Normalization の参照画像を生成
- Local Normalization：Local Normalization を実行
- Integration：ライトフレームをインテグレーション
- RGB Combination：RGB の 3 チャンネルを再合成
もっと簡潔に言えば、8 つのステップに凝縮することもできます。キャリブレーション画像ファイルの作成 → 画像のキャリブレーション → Cosmetic Correction → デベイヤー（RGB 3 チャンネルの分離）→ スターレジストレーション → Local Normalization → 画像のインテグレーション → RGB 3 チャンネルの合成。
ここで、2 つのステップについて少し補足しておきます。RGB 分離は色分散（星の縁が左右で違う色に見える現象）を克服するためのもので、その代償として実行時間が余計にかかります。Drizzle Integration を使う場合、ここでの目的は画像を拡大することではなく、偽像（アーティファクト）を避けることにあります。そのため十分な dither の枚数がそろってはじめて意味があり、一般的には 50 枚を下回るなら実はやらなくてかまいません。ついでに実際の時間感覚も。以前、900 万画素の画像 360 枚を、キャリブレーションから Drizzle Integration 1x まで通しで処理したところ、1 時間ちょっとかかりました。画素数がもっと高ければ、さらに「スリリング」になるだけです。
マスターキャリブレーションフレーム：WBPP の賢いところ
WBPP はキャリブレーションフレーム（フラット、ダーク、バイアスなど）の扱いに、気の利いた工夫をいくつも忍ばせていて、一節を割いて語る価値があります。
キャリブレーションフレームは、WBPP の中で元ファイルから作り直すのがいちばんです。 キャリブレーション後にライトフレームがおかしいと気づく人は少なくありませんが、その主因はたいてい「他のソフトやプロセスで作った Master ファイル」（マスターフラット／バイアス／ダーク）を適用してしまったことにあります。いちばん安全なのは、キャリブレーションファイルの元ファイルを WBPP に放り込み、Master を作り直させることです。
露出時間にわずかな誤差がある？ それは Exposure tolerance に任せましょう。 以前、ある愛好家の方がグループでこんな質問をしていました。彼は Eqmod の信号制御でダークを撮っていたのですが、遅延の問題で、5 秒のダークが実際には 4.980〜5.02 秒のあいだに収まってしまうことがあり、NINA での撮影に切り替えたい、と。じつは WBPP はとうにこれを見越しています。一定の時間差以内のキャリブレーションフレームは同一グループとして指定でき、WBPP は同じグループのキャリブレーションフレームに対して必要な処理を自動で行い、ライトフレームとも自動でペアリングしてくれます。この許容値こそが Exposure tolerance です。
別々の日に撮った画像は、Grouping Keywords でまとめて片づける。 改版後の WBPP にはグループ分けの機能が加わり、たとえ違う日付に撮った画像でも、一度に放り込んでまとめて処理できます——Grouping Keywords でキーワード（たとえば日付）を使って分類しさえすれば。私のあのファイル群のように、日ごとにフラットが違っていても、WBPP は日付ごとに自動で分けてキャリブレーションしてくれるので、違う日付のライトとフラットのペアを一つひとつ手動で設定する必要がなく、とても便利です。
マスターキャリブレーションフレームだけ作りたい？ ライトフレームを入れなくても大丈夫。 これは知らない人が多い使い方です。ライトフレームがない状態で、ダーク、バイアス、フラット、フラットダークを WBPP に放り込むと、正しい手順に沿ってこれらのキャリブレーションフレームを賢くマスターキャリブレーションフレームに仕上げ、指定したフォルダへ出力してくれます。あれこれ別々のプロセスを使って手作業で作る手間が省けます。
Light ページのオプションと高速化のコツ
WBPP の Light ページには一列のオプションが並んでいて、必要に応じてチェックを入れられます。デフォルトでは、subframe weighting 以外はすべてチェックが外れています。
これらのステップを取捨できるとなると、実用的な疑問が浮かびます。要らない処理をオフにすると、どれだけ時間を節約できるのか？ 海外で自由にダウンロードできるデータ一式を使って実測してみました。1600 万画素の画像、計 372 枚。要らない処理を取り除いたところ、時間はおよそ 7〜8 倍速くなり（25 分 03 秒 vs. 03 分 30 秒）、画質の劣化はごくわずか——手元のマシンで約 15% の差、ネット経由で圧縮したあとではほとんど見分けがつきません。締め切りに追われているときや、まずはざっと見たいという場面では、このトレードオフはかなりお得です。
どのステップがいちばん時間を食うのか、どれをオフにするのが最も効果的なのかについては、「WBPP トラブルシューティング」の記事であらためて触れます。
バージョンの変化：これらは後から加わったもの
WBPP はここ数年でずいぶん多くの機能を加えてきました。重要な節目をいくつか整理しておくので、お手元のバージョンと照らし合わせる際の参考にしてください。
バージョン 2.1.2 での出来事いくつか。 このバージョン以降、注目に値する点が三つあります。一つめ、キャリブレーション後にライトフレームがおかしくなるのは、たいてい外部で作った Master ファイルを混ぜてしまったため（前述）。二つめ、Dark frame optimization は主に、ライトとダークの長さが合わないとき（たとえば 20 分のライトに 30 分のダーク）に使うもので、長時間露出かつ複数枚あるのが最良の前提。このオプションはライトフレームのファイルをクリックしないと表示されません。三つめ、CCD を使っている人は、使ううちに徐々に defect、とりわけ column defect（縦筋の欠陥）が出てきます。以前は defect map を作って除去せねばならず非常に手間でしたが、WBPP はこれに対処するための Linear Pattern Subtraction を用意しました。
Execution Monitor（実行モニターウィンドウ）。 新しめのバージョンに更新すると、WBPP は実行中に WBPP Execution Monitor というウィンドウを表示し、いまどのステップまで進み、どんな作業をしたのかを教えてくれます。内容は上下にスクロールしたりドラッグしたりできます。旧バージョンでは、ユーザーは今の console を見つめる以外に進捗を知るすべがなく、全部走り終わるか、エラーで止まるのを待って、ようやく console で確認できるという有様でした。
Cache（キャッシュ）機能（バージョン 2.5 以降）。 これは非常に重要な改善です。フルコースを走らせ終えたあと、間違いや期待外れが見つかって設定をいくつか変えたら、また丸ごと走らせ直しなのか？ その必要はありません。WBPP のキャッシュはこう判断します——変更した設定が画像に影響しないかぎり、前回のキャッシュ結果をそのまま流用する。本当に影響が及ぶ部分の画像だけが再処理されるので、2 回目の実行時間は大幅に短縮されます。
log フォルダにある再現可能なスクリプト。 最新版の WBPP は実行後、log フォルダに詳細な log と実行スクリプトを残します。PI の Script Editor でスクリプトを読み込み、コンパイルして実行すると、Process Container が現れ、その中に WBPP メインウィンドウの Pipeline サブメニューにある全プロセスのアイコンが収められています。どれも PI 上で単独で開くことができます。これはデバッグにこの上なく便利です——たとえば Cosmetic Correction がなぜ正しく実行されなかったのか、あるいは効果がなかったのかを調べたければ、ここからそのステップを開いて、パラメータの問題なのか、それともプログラムのバグなのかを確かめられます。もう一つの使い道として、前処理に不慣れな人は、この方法で WBPP の各ステップのプロセスとパラメータを読み出し、自分で手動実行するときの参考テンプレートにできます。
WBPP を開いて最初にすべきことは、じつはファイルの読み込みではない
最後に、いちばん基本的でありながら、いちばん間違えやすいところに戻りましょう。WBPP を開いたあとの最初のステップは、あわてて「ライト・ダーク・フラット・バイアスのファイルを読み込む」ことではありません。
WBPP は、前回使った内容を保持する数少ないスクリプトの一つです。以前に使っていれば、設定はすべてそのまま残っています。ですから最初のステップはファイルリストをクリアすることであるべきです。ほかのパラメータも一緒にクリアするかどうかは、必要に応じて判断してください。
そして第二のステップはうっかり抜けがちで、多くの解説動画でも触れられていません——Purge Cache を押すことです。先ほど、キャッシュ（バージョン 2.5 以降）の利点を述べました。一部のパラメータだけを変えたときは、WBPP は変えた箇所だけを走らせ、残りはキャッシュを流用します。しかし逆に、すでに一度走らせていて、そのキャッシュ内容がもう要らないときは、それらをすべて消去する必要があります。さもないと、新しいファイルを実行する際にキャッシュ内容の重複が原因で、予期せぬエラーが起きることがあります。
Windows ユーザーのための環境の事前設定
Windows で WBPP を走らせるなら、最初のうちに片づけておくとよい環境設定が二つあります。あとで起きる訳の分からないエラーの数々を避けられます（関連するエラーメッセージと診断については、「WBPP トラブルシューティング」に詳しく載せています）。
長いパス（ロングパス）のサポートを有効にする。 あるアップデート後、Windows 上の WBPP はしょっちゅうロングパスの警告を出すようになり、256 文字を超えるパスを生成できないと言ってきました。私自身、パスが長すぎたせいで WBPP の出力ファイルが欠損したことがあります（ファイルを保存できなかったため）。解決策は、タスクバーで regedit を検索してレジストリエディターを開き、該当の場所を見つけて LongPathsEnabled の値を 1 に変更すること。PixInsight を再起動すれば、この警告はもう出なくなります。
日本語や中国語など非 ASCII 文字を含むパスを避ける。 これも、私がファイルのパスに日本語や中国語などの非 ASCII 文字を使うことをおすすめしない理由です。Windows 下で、ファイルの既定の起動プログラムが PI になっていると、非 ASCII 文字を含むパスのファイルをダブルクリックしただけでエラーメッセージが出ます。下の例で文字化けして見えている箇所が、じつは元の中国語の文字なのです。回避策としては、パスを変えないまま、ファイルを直接ドラッグして PI に放り込めば開けます。
以上をつなぎ合わせれば、WBPP の全体像はおおよそ見えてきます。それは強力な自動前処理エンジンですが、そのインテグレーション成果物はあくまでプレビューにすぎないことを忘れず、どうグループ分けしてキャリブレーションするか、どうキャッシュを使いこなすか、そして作業を始める前に何をクリアし、どんな環境を設定しておくべきかを心得ておく必要があります。考え方さえ合っていれば、あとは習熟度の問題です。