よくある質問(FAQ)ベータ版

質問コーナーに寄せられた投稿を「よくある質問(FAQ)」としてまとめました。現在、内容を精査しているところですが、いったん先行でベータ版リリースします。

1. 前処理

1.1 WBPP

原因①:Local Normalization の失敗

最も多い原因は、WBPP の Integration タブで有効になっている「Local Normalization(局所正規化)」の処理が途中で失敗することです。Local Normalization は各フレームの局所的な明るさのばらつきを補正する工程ですが、フレーム数が少ない・フレーム間の品質差が大きい・特定のカメラ機種との相性などで失敗し、その後の Image Integration がスキップされて masterLight が生成されないまま終了します。

原因②:キャッシュの破損

過去に別の設定で実行したキャッシュが残っていると、新しい処理に干渉してエラーを引き起こす場合があります。WBPP は処理の中間ファイルをキャッシュとして保持しており、パラメータ変更後もキャッシュが残っている場合に不整合が起きます。

原因③:パラメータの不整合

露出時間・Gain・Offset・カメラ温度の異なるフレームが同一グループに混在していると、統合処理が正常に完了しないことがあります。特に撮影途中でカメラ設定を変更した場合に発生しやすいです。

解決策①:Local Normalization を無効化

WBPP を開き、Integration タブ → Local Normalization のチェックをオフにしてから再実行してください。Local Normalization はない状態でも十分な品質の masterLight が生成されます。慣れてきたら後からオンにして比較することをお勧めします。

解決策②:キャッシュのクリア

WBPP 画面左下にある「Purge Cache」ボタンをクリックして中間ファイルをすべて削除し、再実行してください。また、WBPP 右上の「Reset」ボタンでパラメータ全体を初期値に戻すと、設定ミスによるエラーも解消できます。

解決策③:フレームの整理

Lights タブで各フレームの Gain・Offset 列を確認し、異なる値のフレームが混在していれば分離してください。PixInsight は FITS ヘッダーから自動的にグループ分けしますが、ヘッダーの情報が不正確な場合は手動でグループを設定する必要があります。

ヒント

問題の切り分けには、まず数枚(3〜5 枚)の小さなセットで WBPP を試し、成功するか確認する方法が有効です。masterLight が生成されているかどうかは、WBPP で指定した出力フォルダの中に「masterLight_*.xisf」が存在するかで確認できます。

関連スレッド:質問コーナーで見る

原因

WBPP のデフォルト設定では露出時間がわずかでも異なるフレームは別グループに分類され、それぞれ独立したマスターライトが生成されます。たとえば「300秒×10枚」と「600秒×5枚」を同一セッションで撮影した場合、デフォルトでは2つの masterLight が出力されます。

また、撮影ソフトが露出時間を整数ではなく小数点以下の値(299.8秒など)で FITS ヘッダーに記録していると、同じ300秒のつもりでも別グループになってしまうケースもあります。

解決策

WBPP の Post Calibration タブ → Exposure tolerance(露出許容差) の値を大きくしてください。たとえば 300 秒に設定すると、露出差が 300 秒以内のフレームはすべて同一グループとして扱われます。同一露出でも別グループになってしまう場合(小数点問題)は 10 秒程度で解決します。

ヒント①

露出時間が大きく異なるフレームをまとめる場合、WBPP の重み付け(Weight)機能が重要になります。露出時間の長いフレームは一般的に SNR が高く、重みが大きくなるため自動的に優遇されます。

ヒント②

Gain・Offset が異なるフレームは露出許容差で統合することは推奨できません。Gain が違うとノイズ特性が根本的に変わるため、キャリブレーションフレームも Gain ごとに用意し、別グループで処理するのが正しい手順です。

関連スレッド:質問コーナーで見る

原因

WBPP の Registration Reference Image の設定モードが「manual(手動)」になっているため、参照画像が指定されないままプロセスが開始され、エラーになります。以前に手動で参照画像を設定した後にその画像が削除・移動された場合や、パラメータをコピーして別のプロジェクトに適用した場合に起きやすいです。

解決策①:モードを auto に変更

WBPP 右パネル上部の Registration Reference Image Mode を「auto」 に変更してください。auto モードでは WBPP が品質の高いフレームを自動的に参照画像として選びます。

解決策②:パラメータのリセット

WBPP 右上の「Reset」ボタンでパラメータを全初期化してください。リセット後は Lights・Darks・Flats・Biases の各タブにフレームを再度登録してから実行します。

ヒント

WBPP を複数プロジェクト間で設定を使い回す場合は、Registration Reference Image Mode の設定が変わっていないか毎回確認する癖をつけてください。ファイル名については英数字・アンダースコア・ハイフンのみを使うよう統一すると予期しないエラーを防げます。

関連スレッド:質問コーナーで見る

原因

Image Integration は WBPP の中でも最もメモリを消費するステップです。フレーム数が多い・解像度が高い・Drizzle が有効などの条件が重なるとメモリ不足でクラッシュすることがあります。macOS では特に WBPP クラッシュが起きやすいことが知られています。

解決策①:Drizzle Integration を手動実行

StarAlignment 済みフォルダ内に .xdrz(Drizzle データ)と .xnml(正規化マップ)ファイルが存在していれば、Process メニュー → Image Integration → Drizzle Integration から手動で統合できます。ファイルをすべて追加して Scale(通常 2.0)と Drop Shrink(0.9 程度)を設定し実行します。

解決策②:StarAlignment から再実行

Drizzle データが生成フラグなしで作られている場合は、Calibrated フォルダのデータから StarAlignment(Generate drizzle data にチェック)→ Local Normalization(任意)→ Image Integration → Drizzle Integration の順で手動再処理します。

ヒント

再実行前にメモリを増やすため、他のアプリをすべて終了し、Edit → Preferences → Process でメモリ使用量を調整(物理 RAM の 60〜70%)してから試みてください。Drizzle を一時的に無効にするとメモリ消費を大幅に削減できます。

関連スレッド:質問コーナーで見る

原因

WBPP の Bad Frames Rejection は各フレームに算出された「Weight 値」を基準に、最大 Weight の一定割合を下回るフレームを自動除外します。デフォルトの閾値は Minimum Weight = 0.05(5%)です。空の透明度が大きく変動した夜は良質フレームと低品質フレームの Weight 差が開きやすく、閾値設定次第で多くが除外されます。

解決策

WBPP の Lights タブ → Image Integration → 歯車アイコン → Minimum weight パラメータを変更します。値を小さくすると除外が緩やかになります(例:0.05 → 0.02)。

ヒント

除外されたフレームは Weight が非常に低く、積分結果への寄与はほぼゼロのため採用しても最終画質の差はほとんどありません。「せっかく撮ったフレームを捨てたくない」という場合は Minimum weight を 0.01 まで下げても実害はほとんどないです。

関連スレッド:質問コーナーで見る

原因①:Gain・Offset の不一致

アンプグローはセンサーの増幅回路が発する熱ノイズで、カメラの Gain・Offset 設定に依存します。ライトフレームとダークフレームの Gain・Offset が 1 でも違うと、差し引きが正確に行われずアンプグローが残ります。FITS ヘッダーの GAINOFFSET 値をライトとダークで必ず比較してください。

原因②:画像の上下反転

撮影ソフトによっては画像の上下(フリップ)定義が変わることがあります。ライトフレームとダークフレームで上下が反転していると、グローの位置がずれて引き算しても消えません。

原因③:Optimize Master Dark の誤作動

WBPP の「Optimize Master Dark」はダークフレームの熱電子ノイズを補正するための機能ですが、設定が適切でないとキャリブレーション精度が下がることがあります。

解決策
  • ライト/ダークの FITS ヘッダーを Image Header ウィンドウで開いて GAINOFFSETCCD-TEMP を比較する
  • WBPP の Calibration タブ → Optimize Master Dark をオフにして再試行する
  • ダークフレームをカメラに布や遮光テープで完全に覆った状態で再撮影する

関連スレッド:質問コーナーで見る

Drizzle とは

Drizzle(ドリズル)は元々 Hubble Space Telescope の画像処理のために開発されたサブピクセル位置合わせ・統合アルゴリズムです。複数フレームのわずかなずれ(ディザリング)を活用して、元の解像度以上の詳細を復元します。

カラーカメラでの主なメリット

カラーカメラ(ベイヤー配列センサー)で Drizzle を使う最大のメリットは、デベイヤー処理(色補間)を省略できることです。通常のスタックではデベイヤーで各ピクセルの色が周囲から補間されますが、Drizzle では補間なしに4色のベイヤーピクセルをそのまま扱うため、より正確な色情報が保持されます。これにより SPCC の較正精度が上がります。

設定手順
  1. WBPP の Lights タブを開く
  2. 下部の「Generate Drizzle Data」にチェックを入れる
  3. Integration タブで「Drizzle Integration」を有効にする
  4. Scale を設定する(2.0 で元解像度の 2 倍、処理時間・ファイルサイズが大幅増)
ヒント

Drizzle の効果を最大限に引き出すには「ディザリング撮影」が必要です。オートガイダーにディザリング機能を有効にして、フレームごとに数ピクセルずつ位置をずらして撮影してください。また Drizzle は処理時間・メモリ消費が通常の 2〜4 倍になるため、RAM が少ない環境では注意が必要です。

関連スレッド:質問コーナーで見る

結論

PixInsight は主要一眼・ミラーレスカメラの RAW ファイル(CR3・ARW・NEF・ORF 等)をそのまま読み込める DSLR RAW モジュールを内蔵しているため、RAW のまま WBPP に入力して問題ありません。

RAW のまま使うメリット
  • 変換工程が不要で作業フローがシンプル
  • Drizzle 処理を使う場合は RAW 入力が推奨(デベイヤー情報を保持できる)
  • 余分な情報劣化がない
16bit TIFF に変換するメリット
  • 他ソフト(Siril・DeepSkyStacker 等)との互換性が確保できる
  • 新しいカメラで RAW が PixInsight に対応していない場合の回避策になる
TIFF への一括変換方法

Script → Batch Processing → Batch Format Conversion で変換できます。ビット深度は 16bit を選択し、RAW から変換する際にデベイヤーを行わない(グレースケール TIFF として出力)設定にすると、WBPP 内でデベイヤー処理させることができます。

ヒント

Fujifilm X-Trans など特殊なベイヤー配列のカメラは、WBPP での読み込みに問題が生じる場合があります。その場合はカメラメーカーの純正ソフトか Adobe Camera Raw で 16bit TIFF に変換してから使うのが安全です。

原因①:マスターフラット不良(最多原因)

縮緬ノイズの主因はほぼ例外なくマスターフラットフレームの品質不良です。フラット光源の輝度が低すぎると各フラットフレームの S/N 比が下がり、積分後のマスターフラットに細かいランダムムラが残ります。このムラでライトフレームを割り算するため、縮緬状のテクスチャが全面に現れます。

原因②:フラット枚数不足

フラットフレームは枚数を多く撮ってスタックすることで S/N 比を上げます。枚数が少ない(5〜10枚以下)とマスターフラットのノイズが高く、縮緬ノイズの原因になります。

解決策(撮影時)
  • フラット光源の輝度を最大にする、または専用フラットパネルを使用する
  • 露出時間を延ばしてヒストグラムのピークが 全体の 1/3〜中央付近 になるよう調整する
  • フラット枚数を 30 枚以上撮影する
解決策(処理時・既存データへの応急処置)

既に撮影済みのマスターフラットに数ピクセルのガウシアンブラーをかけてから適用すると、縮緬ノイズが軽減されます:Process → Convolution → GaussianBlur(Sigma 1.5〜3.0 程度)をマスターフラットに適用してからキャリブレーションに使用してください。

関連スレッド:質問コーナーで見る

FBPP(Fast Batch Pre-Processing)

大量フレームを高速に処理するために設計されており、StarAlignment・Normalization・Integration が簡略化されています。フレーム間の位置ずれが小さく、光学的歪みが少ない場合に適しています。

WBPP(Weighted Batch Pre-Processing)

より詳細な設定が可能で、輝度勾配の補正(Local Normalization)や歪み補正に優れています。複数日撮影・複数鏡筒の統合・フレーム間で輝度勾配が大きく異なる場合に有効です。

使い分けの目安

単一夜間の大量撮影には FBPP、複数日・複数条件・複雑なデータには WBPP が適しています。迷う場合は WBPP を選べば間違いありません。

原因①:ISO 値が揃っていない

Bias・Dark・Flat・Light のすべてが同じ ISO 値で撮影されている必要があります。Flat だけ ISO 100 で撮影していると、Flat を Bias で補正した際にピクセル値がマイナスになり Calibration が失敗します。

解決策①

Bias・Dark・Flat・Light のすべてを同じ ISO 値に統一して再撮影してください。

原因②:日本語フォルダ・ファイル名

PixInsight はパスに日本語が含まれるとエラーになることがあります。

解決策②

画像ファイルおよびフォルダ名をすべて英数字に変更してください。

原因

スタック済みのフラットマスターに FlatDark を後から引いている場合に起こります。正しくは Flat サブフレーム個々に FlatDark でキャリブレーションを行い、その後統合するという順序が必要です。

解決策

WBPP に Flat サブフレームと Flat 用 Dark フレームを両方登録して実行してください。WBPP が内部で正しい順序(Flat サブフレームごとに Dark 補正→統合)を自動処理します。

原因

CR3 形式は CR2 と内部オフセット処理が異なるため、Bias・Flat の ISO 値が Light と少しでも違うと Calibration が失敗しやすくなります。

解決策

Bias・Dark・Flat・Light のすべてを同じ ISO 値で撮影してください。ISO が揃っていれば CR3 でも正常に処理できます。

推奨設定:オフ

Autocrop はオフにするのが一般的です。オンにするとスタック後の画像サイズが自動変更され、後処理でサイズが揃わなくなることがあります。

トリミングが必要な場合は Dynamic Crop を使って処理後に手動でトリミングしてください。

原因

WBPP の Linear Defects Correction がオンになっている可能性があります。この機能は古い CCD カメラの劣化ピクセルによる黒い線を除去するためのものであり、CMOS カメラでは不要です。有効にすると逆に白い筋が生じることがあります。

解決策

Linear Defects Correction をオフにしてください。Light と Dark を同じ温度・露光時間で撮影している場合は Optimize Master Dark もオフで問題ありません。

原因

破損または肥大化した WBPP キャッシュファイルが起動を阻害している場合があります。

解決策:キャッシュを削除する

以下のキャッシュファイルを削除してから PixInsight を再起動してください:

Windows: C:\Users\[ユーザー名]\AppData\Roaming\Pleiades\WeightedBatchPreprocessing-001-pxi.cache

まれに 10〜20 分待つと起動することもありますが、キャッシュ削除が最も確実です。

原因

フラット撮影の露光時間が短すぎて、LED フラットパネルのフリッカーが縞として写り込んでいる可能性があります。「フラットなし」で WBPP を実行して縞が消えれば、フラットが原因と確定できます。

解決策
  • フラットの露光時間を 1 秒以上(推奨 2〜3 秒) に延長する
  • LED パネルが明るすぎる場合は ND フィルター で減光して長時間露光に対応する
  • 乳白色アクリル板で光を拡散してムラを軽減する
判断基準
  • 除外すべき:星が線状に伸びるほどの重大なガイドエラー
  • 含めてよい:星が楕円形程度のガイドエラー。PixInsight の Pixel Rejection が統合時に自動的に対処します

薄雲も同様です。ハロが生じるほどの雲は除外、シグナルが少し低下する程度なら統合したほうが S/N 比が向上します。

原則として Gain を統一する必要があります

リードノイズは Gain によって変化するため、異なる Gain の Bias では正確なキャリブレーションができません。

Dark と Light の露光時間が同じ場合の例外

Dark と Light を同じ温度・同じ露光時間で撮影している場合、WBPP は自動的に Bias を使用しません。「Dark に Bias が含まれているため、Light から Dark を引くと自然に Bias も除去される」ためです。この場合は Bias フレーム自体が不要になります。

露光時間が異なる場合(Optimize Dark オプション使用時など)は Bias が必要になります。

原因

Windows のデフォルト設定ではファイルパスの最大長が 260 文字に制限されています。PixInsight が深いフォルダ階層や長いファイル名の組み合わせでこの上限を超えると、ファイルが作成できないという Warning が発生します。

解決策:Windows のロングパスを有効にする
  1. スタートメニューで「regedit」と入力してレジストリエディタを起動する
  2. HKEY_LOCAL_MACHINE → SYSTEM → CurrentControlSet → Control → FileSystem を開く
  3. LongPathsEnabled をダブルクリックして値を 1 に設定する
  4. Windows を再起動する
注意

レジストリ編集は誤操作すると Windows が不安定になる可能性があります。操作には十分注意し、不明な場合は管理者に相談してください。なお、フォルダ名を短くすることでも回避できます。

原因

EFW フィルターホイール等でフィルター名を後から変更した場合、FITS ヘッダーに記録されたフィルター名が異なり WBPP が別々のフィルターと判断して分けてしまいます。

解決策:Add Custom でフィルター名を統一する
  1. WBPP の Lights タブ下部にある 「Add Custom」ボタンをクリックする
  2. Image type を Light に設定し、Filter name に統一したい名称(例:Ha)を入力する
  3. 名称が異なるファイルを選択して追加する

この方法で、異なるフィルター名で記録されたファイルを同一グループとして扱いインテグレートできます。

原因

Mosaic Pattern(CFA パターン)が Auto に設定されていて、ベイヤーパターンを正しく認識できない場合に発生します。露出時間が 0 秒と認識されるケースも同原因のことがあります。

解決策

WBPP の CFA 設定で Mosaic pattern を Auto から手動設定(通常は RGGB)に変更してください。カメラのベイヤーパターンは機種のマニュアルまたはメーカーサイトで確認できます。

仕様です

PixInsight はカラーカメラの RAW・FITS をベイヤーパターンのまま読み込み、グレースケールとして表示します。ASIFitsViewer やステライメージなどは自動でデベイヤー(カラー変換)しますが、PixInsight はデベイヤー前の生データを扱う仕様のため正常な動作です。

カラー画像にするには
  • WBPP を使う場合:WBPP が内部でデベイヤーを行うため、出力されたmasterLightはカラーになります
  • 手動でデベイヤーする場合:Process → ColorSpaces → Debayer を実行してください。Bayer パターンは通常 RGGB ですが、カメラ仕様書で確認してください
  • BayerDrizzle の場合:DrizzleIntegration の「Enable CFA drizzle」を使うとデベイヤーなしでカラーのスタック画像が得られます
原因

ステライメージや DeepSkyStacker など他ソフトで作成したマスターダークはヘッダー形式や内部データ仕様が PixInsight と異なる場合があります。またパスに日本語が含まれると PixInsight がパスを正しく解析できずエラーになります。

解決策
  • マスターダークを PixInsight で再作成する:ダークサブフレームを Image Integration で統合したマスターダークを使う
  • フォルダ・ファイル名を英数字に変更する:日本語パスを含まないよう作業フォルダはすべて英数字にする
原因

ダークフレームとフラットダークフレームのカメラ Offset 値が一致していない場合に発生します。フラット補正は割り算で行われるため、オフセット値の不一致が「明暗比率のずれ」として画像全面のムラに現れます。

解決策
  • FITS ヘッダーを確認し、ダーク・フラットダーク・ライトすべてで Gain 値と Offset 値が一致しているかチェックする
  • 画像を開いた状態で File → FITS Header を実行し GAINOFFSETCCD-TEMP を確認する
  • 値が異なる場合は同一設定で再撮影するか、対応するオフセット値のフラットダークを揃えて再処理する
ヒント

光害カットフィルター(QBP など)使用時は、フラット撮影時のフィルター ON/OFF を統一することも重要です。フィルターの有無で周辺減光パターンが変わります。

原因

ナローバンドフィルター(Hα・OIII など)を使った撮影は信号が極めて微弱です。ダークフレームを差し引くキャリブレーション処理を行うと、ライトフレームの背景輝度がダークとほぼ同じになり、キャリブレーション後の画像の背景値がゼロに近くなります。WBPP の Measurements はこれを「極端に低品質なフレーム」と判断してすべて除外してしまいます。

解決策①:ダークフレームを使用しない

ナローバンド撮影ではダークフレームなしで WBPP を実行することを試してください。信号が微弱な場合、ダーク補正を行わない方が Measurements が正常に動作します。

解決策②:Optimize Dark を活用する

WBPP の Calibration タブで Optimize Dark を有効にすると、ダークの適用スケールを自動調整するため過剰補正を抑えられます。

解決策③:露光時間またはゲインを見直す

根本的な解決には、ライトフレームの露光時間を延ばす(または Gain を上げる)ことでダークより十分に明るい信号を確保してください。

原因

WBPP 処理後にメモリの解放処理が正常に完了しないまま PixInsight を終了しようとすると「Fatal Error: Access violation: invalid memory read operation」エラーが発生します。WBPP 自体は正常に完了しており masterLight はすでに書き出されているため、データの損失はありません。

解決策①:PixInsight の再インストール

PixInsight を完全にアンインストールしてから公式サイトより最新版を再インストールしてください。再インストール後に Fatal Error が解消されるケースがほとんどです。

解決策②:BXT・NXT が動かない場合は IPv6 を無効化する

再インストール後に BXT(BlurXTerminator)や NXT(NoiseXTerminator)がエラーになる場合は、ネットワーク設定の干渉が疑われます。Windows の設定でネットワークアダプターの IPv6 を無効化してから PixInsight を再起動してください。

ヒント

Fatal Error で PixInsight が強制終了しても masterLight はすでに出力フォルダに書き出されているため、処理結果は保全されています。エラーを無視して次の作業を続けることができます。

関連スレッド:質問コーナーで見る

原因

外付け USB ドライブやポータブル HDD など転送速度が遅いストレージに保存したファイルを直接 WBPP で処理すると、読み書き速度の不足が原因でエラーが発生したり masterLight が生成されないことがあります。Celestron Origin Mark II などのオールインワン型スマート望遠鏡は内蔵ストレージが USB 接続で認識されるため、同様の問題が起きやすいです。

解決策:内蔵ドライブにコピーしてから処理する

画像ファイルをすべて PC の内蔵 SSD または HDD(C: ドライブや D: ドライブなど)にコピーしてから WBPP を実行してください。処理速度も大幅に向上します。

Celestron Origin Mark II でよくある問題
  • IMX678 センサーのベイヤーパターンは RGGB です。WBPP の CFA 設定が Auto の場合は手動で RGGB に設定してください
  • ダーク・フラットが揃っていない場合は、まず補正フレームなしで WBPP を実行して masterLight の生成を確認してから補正フレームを追加する方法が有効です
  • 出力画像が緑かぶりになる場合は Background Neutralization を適用してください

関連スレッド:質問コーナーで見る

1.2 Star Alignment / Integration / Drizzle

結論:物理的な回転は不要

赤道儀が子午線を越えて望遠鏡が反転(フリップ)すると、カメラが 180° 回転した状態になります。この状態で続けて撮影しても問題ありません。PixInsight の StarAlignment が 180° 回転を含む任意の変換を自動で処理し、正しく位置合わせされた統合画像を生成します。WBPP に反転前後のフレームをまとめて放り込んでも正確に処理されます。

物理回転すると何が問題か

カメラを物理的に回転させると、フラットフレームとライトフレームの向きが一致しなくなります。フラットフレームにはセンサーの周辺減光・ゴミ・ムラの情報が記録されていますが、カメラの向きが変わればこれらの位置もずれます。結果として、フラット補正後に円形のムラや黒点が残るなどのキャリブレーション不良を引き起こします。

フラットフレームの扱い

子午線反転を挟んで長時間撮影する場合、反転前と反転後でそれぞれフラットフレームを撮影するのが理想です。反転後のフラットが取れない場合でも、PixInsight の StarAlignment が十分に回転補正を処理してくれるため、単一のフラットセットでも実用上問題ないことがほとんどです。

関連スレッド:質問コーナーで見る

原因

Comet Alignment は彗星核をマニュアルでクリックして各フレームの核位置を登録するプロセスです。クラッシュの最大原因は彗星核の飽和(ピクセル値が最大値に達している白とびの状態)です。飽和したピクセル群は位置の中心を計算できないため、処理がエラーになります。明るい彗星を長露出で撮影した場合に起きやすい問題です。

解決策①:クリック位置をずらす

核の中心(最も明るい点)からわずかにずれた位置をクリックします。核の端に近い、まだ飽和していない半透明な部分をクリックするとエラーが回避できることが多いです。

解決策②:別のフレームを参照にする

核が飽和していない(露出が短い)フレームを選んで処理を進めてください。撮影時に露出時間の違うフレームを意図的に含めておくと、こうしたトラブル回避に役立ちます。

ヒント

彗星撮影では露出を短めにして核を飽和させないようにするのが根本的な対策です。核が飽和しない露出と、コマ(尾)を写すための長露出を組み合わせて、HDRComposition で合成する手法も有効です。

関連スレッド:質問コーナーで見る

手順
  1. Process メニュー → Image Integration → Drizzle Integration を開く
  2. Input タブで「Add Files」→ StarAlignment が生成した .xdrz ファイルをすべて選択して追加する
  3. Drizzle タブで Scale(通常 2.0)・Drop Shrink(0.9〜1.0)を設定する
  4. Output タブで出力先フォルダを指定する
  5. 「Execute」ボタンで実行する
前提条件

Drizzle Integration を手動で実行するには、StarAlignment 実行時に「Generate drizzle data」にチェックが入っていた必要があります。このチェックがなければ .xdrz ファイルが生成されないため、Drizzle Integration は実行できません。その場合は StarAlignment を最初からやり直す必要があります。

パラメータのヒント

Scale = 2.0 は縦横 2 倍(面積 4 倍)で詳細が増えますが処理時間も大幅に増加します。Drop Shrink = 0.9 が一般的な推奨値で、ドロップサイズを 10% 縮小することでフレーム間のコントリビューションが重ならず解像度が向上します。

関連スレッド:質問コーナーで見る

方法①:WBPP のグループ機能を使う(同じ鏡筒・同夜)
  1. Gain ごとに別フォルダを用意(例:GAIN_300GAIN_390)し、対応する Light・Flat・Dark を入れる
  2. WBPP の Post-Calibration タブ → Grouping Keywords に GAIN を入力して「+」ボタンを押す
  3. 両フォルダのファイルを通常通り読み込んで実行。WBPP が Gain ごとにキャリブレーションしながら1回で統合します
方法②:2段階処理(Gain が大きく異なる場合)
  1. 第1段階:Gain ごとに個別キャリブレーションのみ実行(Registration・Integration は無効化)
  2. 第2段階:キャリブレーション済みフレームをまとめて読み込み、Post-Calibration の Exposure Tolerance を調整して統合

異なる Gain のデータを混合すると、同 Gain のみの場合より S/N 比が向上することが確認されています。

結論:1〜2℃ 程度の差は問題なし

温度差による縞状ノイズが出る場合、原因は温度差よりも Image Integration の Pixel Interpolation 設定にあることが多いです。

縞ノイズが出た場合の確認事項

Image Integration の Pixel Interpolation が Auto または Lanczos になっている場合、他のアルゴリズム(Bilinear など)に変更すると改善することがあります。

可能です

サブフレームから再スタックするのが理想ですが、マスター同士を統合することも可能です。

PixelMath で露光時間加重平均する方法

例:60分のマスター(A)と30分のマスター(B)を統合する場合:

(60*A + 30*B) / 90

この式で露光時間の比率に応じた加重平均が得られます。総露出時間は 90 分として扱えます。

できます

Image Integration の Normalization(加算スケーリング) 機能が背景レベルの違いを補正します。デフォルトの「Additive with scaling」で対応可能です。

複数夜・背景ムラが大きい場合

Local Normalization を先に実行してから Image Integration で Local Normalization を指定する方法が有効です。WBPP を使うと Local Normalization と Integration が自動的に連携されるため推奨です。

対処方法

WBPP 内で画角ずれの境界を目立たなくする機能はありません。以下の対応が有効です:

  • モザイク合成:複数の画像を個別に WBPP で処理した後にモザイクとして統合する
  • Astro Pixel Processor(APP)の活用:PixInsight のモザイク機能より優れているとされ、複数画角の処理に向いています

根本的な対策は撮影時に画角のずれを最小限に抑えることです。

原因

露光時間が短くノイズが多い画像で、Star Alignment が星を正確に検出できない場合に発生します。

解決策:Star Detection パラメータを調整する
  • Noise Reduction を 0 → 5 に上げる(ノイズが多い画像に効果的)
  • Log(sensitivity) を下げる
  • 長焦点の場合は Detection scales を大きくする
原因

ホットピクセルが星として誤認識され、Star Registration が正しく機能していないことが多いです。

対処法
  • Star Alignment の Distortion Correction を有効化する
  • Registration Parameters を調整する(Noise Reduction を上げるなど)

Local Normalization の Failure 自体は画質への影響が限定的なことが多く、むしろ Image Registration の精度を上げることが優先事項です。Registration が正しく完了すれば Local Normalization のエラーも改善される場合があります。

DrizzleIntegration プロセスで実行する
  1. 通常の前処理(Debayer を含む)を実施し、.xdrz Drizzle データファイルを生成する
  2. DrizzleIntegration プロセスを開き「Add Files」で .xdrz ファイルを入力する
  3. Enable CFA drizzle をチェックする
  4. Scale:1、Drop shrink:1.00 に設定して実行(Apply Global)

DrizzleIntegration が完了するまで WBPP が生成した中間ファイルは削除しないでください。実際には「WBPP の前処理機能で .xdrz を生成 → DrizzleIntegration で最終処理」という混合アプローチが一般的です。

原因

Drizzle でピクセルサイズが変わるため、星検出パラメータが合わなくなります。

解決策①:ピクセルサイズを調整する

SPCC の Camera pixel size をドリズルスケールの逆数に設定します(例:2× Drizzle なら 1/2 のピクセルサイズ)。PCC では Growth Factor を 4.0 程度に上げます。

解決策②:非ドリズル画像で係数を取得して転用する

通常のスタック画像で SPCC を実行して White Balance Factors を取得し、その値をドリズル画像に PixelMath で適用する方法も有効です。

方法①:Sigma Clipping の調整

Image Integration の Sigma High 値を下げると、移動天体のように他フレームと一致しないピクセルが除外されやすくなります。デフォルト 3.0 から 1.8 程度に調整して試してください。ただし動きが遅い場合はあまり効果がないことがあります。

方法②:Linear Fit Clipping に変更

Rejection アルゴリズムを Linear Fit Clipping に変更し、high 値を下げると、通常の Sigma Clipping より積極的にアウトライヤーを除去します。

方法③:CloneStamp で手動消去(最終手段)

スタック後も残ってしまった場合は CloneStamp で手動消去します。Process メニュー → All Processes → CloneStamp を起動し、背景を Ctrl+クリックでサンプリングした後、消したいピクセルをクリックして塗りつぶします。

ヒント

小惑星は1夜で数 arcmin 程度移動するため、枚数が多いほど Rejection で消えやすくなります。フレーム数が少ない場合は CloneStamp が確実です。

Generate Star Image オプションを使う

SXT を実行する際に 「Generate Star Image」をチェックすると、1回の実行で「星なし画像」と「星のみ画像」の2枚が同時に生成されます。SXT を2回実行する必要はありません。

Large Overlap オプション

通常は Large Overlap をオフにして問題ありません。オンにするとノイズ状の結果になる場合があります。

彗星の核が星画像に残る問題

SXT は彗星の核を星として誤認識することがあります。その場合は Clone Stamp で核の跡を消去するか、SXT を使わずに PixInsight のコメット処理専用機能(Comet Alignment など)を活用してください。

WBPP の自動選定を信頼する

WBPP の LN レファレンスを手動指定したい場合は、WBPP で Interactive mode をチェックすることで選択肢が増えます。デフォルト(Interactive mode オフ)では PSF Signal Weight が最も高いフレームが自動でレファレンスに選ばれます。PSF Signal Weight は S/N 比と強く相関するため、複数日にまたがるデータでも最も品質の高いフレームが適切に選定されます。

複数日撮影の推奨フロー

分割インテグレーションは各日のフレーム数が少ないため Pixel Rejection の精度が落ちます。可能であれば以下の方法を推奨します:

  1. WBPP は Calibration までで処理を止める(Registration / Integration を無効にする)
  2. キャリブレーション済みフレームをまとめて StarAlignment → Local Normalization → Image Integration の順で手動処理する
  3. 全フレームを一度に Integration することで Pixel Rejection の精度が最大になる
Star Alignment を使う
  1. Star Alignment を開き、Reference Image にベース画像を設定する
  2. Add Files で位置合わせしたい画像を追加する
  3. 異なる光学系の場合は Registration Model を Thin Plate Spline に変更し、Distortion Correction にチェックを入れる
  4. 実行すると位置合わせ済みの画像が生成される(共通外の周辺は黒くなる)
黒い周辺をクロップするには

Dynamic Crop プロセスで手動クロップしてください。スタックする場合は Image Integration で統合すると自動的に黒縁の影響を最小化できます。

原因:ガイドエラーが大きすぎる

Drizzle は各フレームの数ピクセル程度のわずかな位置ずれ(ディザリング)を活用してサブピクセル解像度を復元するアルゴリズムです。ガイドエラーで数十ピクセル単位の位置ずれが頻繁に発生すると想定範囲を大きく超えた位置情報が入力され、特定領域にデータが集中・欠落する緑色の矩形アーティファクトが現れます。特に眼視観望向けの追尾精度が低い赤道儀で起きやすいです。

解決策①:Drizzle を無効にして通常スタックする

追尾精度が十分でない環境では Drizzle を無効にして通常の Image Integration でスタックしてください。ガイドエラーが大きい場合は Drizzle の恩恵よりもアーティファクトのリスクの方が大きくなります。

解決策②:追尾精度を改善する

Drizzle の効果を最大限に引き出すにはガイドエラーが数ピクセル以内に収まる追尾精度が必要です。OAG(オフアクシスガイダー)の導入や撮影専用の高精度赤道儀への移行を検討してください。

ヒント

PHD2 などのガイドログで RMS 誤差を確認してください。RMS が 1〜2 ピクセル以内に収まっていれば Drizzle の効果が期待できます。

関連スレッド:質問コーナーで見る

2. リニアフェーズ

2.1 かぶりとり

推奨フロー

多くのユーザーに支持されている一般的な順序:DBE(またはGraXpert)→ BXT → SPCC(またはSPFC)→ NXT(任意)→ ストレッチ

各ステップの理由

DBE を先に行う理由:背景グラジェントが残った状態で BXT や SPCC を実行すると、グラジェントの影響で処理精度が落ちます。特に SPCC は背景が均一であることを前提にしているため、DBE は先に行うのが基本です。

BXT をリニア段階で行う理由:BXT(BlurXTerminator)は PSF の線形的な特性を利用した deconvolution ベースの処理です。リニアデータはピクセル値が線形であるため PSF 推定が正確です。ストレッチ後のノンリニアデータでは非線形変換によって PSF が歪むため、補正精度が落ちます。

NXT をノンリニア段階で行う推奨理由:NXT(NoiseXTerminator)は AI ベースのノイズ除去です。ストレッチ後のノンリニア段階では暗部ノイズが視認しやすく調整しやすいため後処理が推奨されます。ただしリニア段階での使用も有効なことがあります。

「絶対の正解はない」

上記は広く支持される順序ですが、対象・機材・撮影条件によって最適な順序は変わります。GraXpert と DBE を両方かける・BXT を複数回に分けてかけるなど、自分のワークフローを確立することが大切です。

関連スレッド:質問コーナーで見る

この手法が有効なケース

センサーやフィルターの特性によって、R・G・B の各チャンネルで異なるグラジェントパターンが生じることがあります(特に 294MC など特定の CMOS センサーや、SV220 などの安価なフィルターで報告されています)。通常の DBE(カラー画像に対して一括で適用)では各チャンネルを個別に扱えないため、チャンネルごとにグラジェントが残ることがあります。

手順
  1. チャンネル分離:Process → Channels → Channel Extraction で R・G・B を別々の画像として抽出する
  2. 各チャンネルに DBE:R・G・B それぞれの画像を開き、サンプリング点を全チャンネルで同じ位置に配置しながら DBE を実行する
  3. チャンネル結合:Process → Channels → Channel Combination で補正済み R・G・B を再結合してカラー画像に戻す

関連スレッド:質問コーナーで見る

原因①:サンプリング点の配置ミス

DBE のサンプリング点が星雲・銀河・明るい星の上に配置されていると、対象天体の輝度を「背景」として誤認識し、実際の背景よりずっと明るいモデルが構築されてしまいます。差し引きした結果、その部分が暗くなりすぎてムラになります。

原因②:サンプリング点の偏り

サンプリング点が画像の端・角に集中していると、中央部のグラジェントが正確に推定されません。DBE は多項式で背景をフィッティングするため、サンプリング点の分布が偏ると補間精度が落ちます。

原因③:次数(Order)の設定

多項式の次数(Order)が高すぎると過学習が起きて本来平坦な部分に波紋状の補正が入ります。通常は 1〜3 次で十分です。

解決策
  • すべてのサンプリング点のミニプレビューを確認し、明らかに星雲や明るい星が入っているものを削除または移動する
  • サンプリング点を画像全体に均等に分散させる(中央部にも必ず配置する)
  • Order を 1 または 2 に下げて試す
  • DBE のプレビュー機能を使って補正前後の差分画像(Subtraction)を確認する
DBE(Dynamic Background Extraction)

PixInsight に内蔵された従来の背景抽出ツールです。ユーザーが手動でサンプリング点を配置する必要があり、正確に使えば非常に高精度ですが、設定に経験が必要です。多項式フィッティングによるシンプルな推定のため、複雑な形状のグラジェントには限界があります。PixInsight に標準内蔵なので追加インストール不要。

GraXpert

AI ベースの背景抽出ツールで、PixInsight プラグインとして提供されています(別途インストールが必要)。サンプリング点の配置が自動化されており、複雑な形状のグラジェントにも対応しやすく、天体が画角の大部分を占める場合でも精度よく処理できる特長があります。

使い分けの目安
  • シンプルな勾配状グラジェント(光害・空の明るさの差)→ DBE で十分
  • 複雑な多方向グラジェント・大きな天体で背景が取りにくい場合 → GraXpert が有利
  • 初心者 → GraXpert の自動処理から始めるのが取り組みやすい
原因

サンプリングポイントが天体に近すぎると、天体の輝度が背景として認識され、周囲が過補正されます。

解決策:DBE のパラメータを調整する
  • Tolerance を約 5.0 に上げる:天体周辺への影響を抑制します
  • Sample Generation を 20 前後に増やす:サンプル数を増やして補正精度を上げます

ABE より DBE のほうが制御しやすいため、銀河や大きな星雲を含む画像では DBE の使用を推奨します。

打点のコツ
  • できるだけ背景に近い暗い領域を優先して打点する
  • STF の Boost モード(Ctrl+クリックなど)で暗い部分を強調表示すると背景領域が見つけやすくなります
  • どうしても背景が見つからない場合は、星雲上の比較的暗い部分に打っても構いません。星雲が完全に消えることはありません

打点位置によって補正結果が変わるため、5〜6回試行しながら「かぶりが除去できているか」「天体の構造が保たれているか」を STF で確認しながら進めてください。

原因

QBP・デュアルバンドフィルターなどのナローバンド系フィルターを使用している場合、SPCC は連続光(ブロードバンド)を前提とした補正をするため正しく機能しません。

解決策

SPCC の代わりに Narrowband filters mode を有効にして波長を手動設定するか、DBE で背景補正の精度を上げることを優先してください。DBE のサンプル打点が天体対象に被っていると緑かぶりの原因になります。

原因

MGC が使用する MARS データベースはまだ全天をカバーしていません。リファレンスデータが存在しない領域の天体を処理するとこのエラーが発生します。

解決策

その天体では MGC が使用できません。代わりに GraXpert または DBE で背景補正を行ってください。MARS は順次カバー範囲を拡大しているため、将来的には使用できるようになる可能性があります。

2.2 色合わせ Color Calibration

原因

SPCC(Spectrophotometric Color Calibration)は画像内の星のスペクトル情報を Gaia DR3/SP カタログと照合して色較正を行います。このとき回帰分析に最低 5 個以上の有効サンプル(星)が必要ですが、それを下回るとこのエラーが出ます。

原因となる状況:① 露出時間が短く暗い星が写っていない ② 検出パラメータが厳しすぎて有効な星として認識されない ③ 背景グラジェントが大きく、星の検出アルゴリズムが誤動作している ④ デュアルバンドフィルターで写る星の数が極端に少ない ⑤ ImageSolver 未実行(WCS ヘッダーがない)。

解決策①:検出パラメータの緩和

SPCC ダイアログの Detection タブで以下を変更します:

  • Noise Reduction:0 → 5
  • Minimum Detection SNR:40 → 10
解決策②:ImageSolver の実行

SPCC は画像に天体認識情報(WCS ヘッダー)が付与されている必要があります。Script → Astrometry → Image Solver を先に実行して、画像に座標情報を付与してから SPCC を再実行してください。

ヒント

SPCC のエラーが出た場合でも、Background Neutralization → Color Calibration(旧来の方式)で色較正は行えます。SPCC ほど科学的な精度はありませんが実用には十分なことが多いです。

関連スレッド:質問コーナーで見る

原因

PixInsight の SPCC データベースには Canon・Nikon・Sony・ZWO など主要メーカーのカメラフィルター特性(QE カーブ)が収録されていますが、富士フイルムのカメラは現時点で収録されていません。これは富士フイルムが X-Trans センサーという独自のカラーフィルター配列を採用しており、標準的なベイヤー配列と異なるためです。

解決策

Canon・Nikon・Sony などの他メーカーのフィルター設定を代替として選択してください。実際の検証では、正しいフィルターと意図的に誤ったフィルターを比較した場合、最終画像における色調の差は肉眼ではほぼ識別できないレベルです。

SPFC の場合

SPFC(Spectrophotometric Flux Calibration)でも同様です。QE Curve 設定は「IdealQEcurve」を選択するのが無難です。

X-Trans のデベイヤー

WBPP での X-Trans データ処理は Lights タブの「Debayer Pattern」を「X-Trans」に設定することを忘れずに。デフォルトの RGGB ベイヤーパターンでデベイヤーすると色が大きくずれます。

関連スレッド:質問コーナーで見る

原因①:改造カメラ設定の誤り

カメラの IR カットフィルターを除去または変更した改造カメラを使用している場合、SPCC の Camera タブで改造カメラ用の設定(「Modified」や「Ha modified」)を選択しないと、Hα 波長の透過率が正確に反映されず色較正がずれて赤くなります。

原因②:背景グラジェントの残留

特に赤み系の光害が残っている状態で SPCC を実行すると、背景の赤みを参照して色較正がずれます。SPCC は背景が均一なニュートラルグレーであることを前提にしているため、グラジェントが残っていると精度が大きく落ちます。

解決策
  • SPCC の Camera タブで改造カメラの種類(HKIR 改造・BaaderModified など)を正確に設定する
  • SPCC 実行前に DBE または GraXpert でグラジェントを徹底的に除去する
  • デュアルバンドフィルター時は SPCC を使わず Background Neutralization → Color Calibration(旧方式)を使うか、SPCC の Narrowband フィルター設定を適用する
原因

Optolong L-Ultimate・STC DualBand などのデュアルバンドフィルターは、Hα(656nm)と OIII(500nm)の2つの輝線波長だけを透過し、それ以外の波長をカットします。銀河は輝線ではなく連続スペクトル(可視光全域)を放射しているため相性が悪いのです。アンドロメダ銀河の腕の外縁部には若い青白い恒星が多く、その光のピーク波長(400〜450nm の青色域)はデュアルバンドフィルターの透過帯域から外れています。

解決策①:ArcsinhStretch で補正

ストレッチ後に ArcsinhStretch を適用すると、銀河の連続スペクトル成分のバランスが改善されて青系の発色が戻りやすくなります。Script → Utilities → ArcsinhStretch から実行してください。

解決策②:根本的解決:フィルターなしで再撮影

銀河は光害の少ない場所ではフィルターなしで十分写ります。L-Pro や LP フィルター(特定輝線だけでなく光害帯域を広くカット)の方が銀河撮影に適しています。

関連スレッド:質問コーナーで見る

使えます

SPCC の Narrowband filters mode をオンにすると、RGB チャンネルごとに中心波長と帯域幅を指定する項目が現れます。

L-eXtreme(Hα + OIII デュアルバンド)の場合の設定例
  • R チャンネル:中心波長 656nm(Hα)、帯域幅 7nm
  • B・G チャンネル:中心波長 500nm(OIII)、帯域幅 7nm

擬似 AOO 合成より自然な色調に仕上がるとの報告があります。使用するフィルターの仕様書で波長と帯域幅を確認してください。

実用上は問題なし

Background Neutralization は背景の R・G・B 差分を全画素から均等に引くため、理論上は影響があります。しかし背景の輝度差は非常に小さく(0.0000105 程度)、飽和した星への影響は 0.001% 以下 でほぼ無視できます。

実用上は大差なし

SPCC の Camera QE Curve は、使用センサーに近いモデルを選べば十分です。例えば ZWO ASI071MC-Pro(IMX071)がリストにない場合は IMX183 を選ぶか、Ideal QE Curve を選択してください。

正確なモデルと他のモデルを比較した場合、最終画像での色調の差は目に見えるほどの違いが出ないことがほとんどです。Fujifilm X-Trans のようにリストに存在しないセンサーも Ideal QE Curve で実用的な結果が得られます。

ヒント

最終的に重要なのは QE Curve の選択より、DBE で背景グラジェントをしっかり除去すること、および ImageSolver で WCS ヘッダーを付与してから SPCC を実行することです。

原因:デュアルバンドフィルターは銀河に不向き

QBP・L-Ultimate などのデュアルバンドフィルターは Ha(656 nm)と OIII(500 nm)を透過するように設計されています。銀河は全波長に連続光が分布しているため、これらのフィルターが青い波長帯を大きくカットしてしまい、結果として黄色・茶色にかぶります。

解決策
  • 銀河撮影にはフィルターなし(クリア)または LPS フィルターを使用してください
  • 既に撮影済みの場合は、SPCC の代わりに Color Calibration(旧 PCC 方式)で色補正し、その後 CurvesTransform で青チャンネルを調整する
  • ArcsinhStretch を使うと非線形なコントラスト調整ができ、青さを引き出しやすくなります
原因①:採用される参照星の変動

PCC(Photometric Color Calibration)は画像内の星と参照カタログを照合して色較正を行います。Limit Magnitude(等数上限)と Aperture(測定円直径)の設定で採用される星が変わり、結果の色味が変化します。パラメータを大きくすると赤みが増す傾向があります。

原因②:Background Neutralization の影響

Background Neutralization の処理が天体の一部にも影響し、色合いを変化させることがあります。

対処法
  • Limit Magnitude・Aperture を毎回同じ値に固定して結果を統一する
  • PCC の結果が不満な場合は Background Neutralization のみ再実行して微調整する方法も有効
  • SPCC(Spectrophotometric Color Calibration)は PCC より再現性が高いため、移行を検討してもよい

2.3 BXT(BlurXTerminator)

原因

BlurXTerminator(BXT)は TensorFlow ライブラリを内部で使用しており、PixInsight の bin フォルダ内に特定バージョンの tensorflow.dll(Windows)または libtensorflow.dylib(macOS)が必要です。

最も多い原因は StarNet2 のインストールです。StarNet2 も TensorFlow を使っていますが、BXT が要求するバージョンと異なる古いバージョンの tensorflow.dll を同じフォルダに上書きインストールする場合があります。エラーメッセージに「GraphDef version mismatch」のような文言が含まれていればこの原因が確定的です。

解決策(Windows)
  1. RC Astro の公式 FAQ ページ(rcastro.com)から BXT 用の正しい tensorflow.dll をダウンロードする
  2. C:\Program Files\PixInsight\bin フォルダ内の古い tensorflow.dll を新しいファイルで上書きする
  3. PixInsight を再起動して BXT を実行する
StarNet2 インストール時の注意

StarNet2 をインストールする際に「TensorFlow ファイルを PixInsight フォルダにコピーする」オプションが出た場合は、必ずスキップしてください。コピーすると BXT が再び壊れます。

関連スレッド:質問コーナーで見る

原因①:スタック枚数不足

BXT は高 S/N 比の滑らかな画像で最も効果的に機能します。スタック枚数が少ない(特に 10 枚以下)画像ではランダムノイズが多く、BXT の deconvolution アルゴリズムがノイズをリンギングとして増幅してしまいます。目安として 180 秒 × 36 枚(合計 1.8 時間)以上あると BXT がきれいにかかりやすくなります。

原因②:FWHM が仕様範囲外

BXT の開発者(RC Astro)は FWHM が 8 ピクセルを超える場合にリンギングが出やすいと述べています。シーイングが悪い夜・焦点がわずかにずれている場合などに FWHM が大きくなります。

解決策
  • Sharpen Stars を下げる:0.8 → 0.5 程度に調整。対象によっては 0.3 でも十分なシャープさが出る
  • Adjust Star Halos を上げる:ハロ補正を強めることでリンギング状の周辺アーティファクトを抑制できる
  • 星マスクをかける:星周辺の処理にマスクをかけて BXT の効果を星本体に限定する

関連スレッド:質問コーナーで見る

原因

BXT は星の PSF を deconvolution によって補正するため、処理後に星がシャープになります。このとき元々光学系の収差・フォーカスのにじみで隠れていたハロが、星がシャープになることで相対的に目立つようになります。つまりハロは BXT が「作った」わけではなく、元から光学系に存在していたものが顕在化したものです。

解決策①:GHS の Local Intensity

GHS(GeneralisedHyperbolicStretch)の Local Intensity パラメータを使うと、星の中心輝度と周辺(ハロ領域)の輝度バランスを調整できます。

解決策②:星マスク+ CurvesTransformation
  1. StarNet2 でスターレス画像を生成し、差し引きで星マスクを作る
  2. 星マスクを反転して「星周辺のみを選択するマスク」を作成
  3. CurvesTransformation でハロ部分の輝度を下げる(マスクを適用した状態で)
解決策③:BXT の Adjust Star Halos パラメータ

BXT 実行時に Adjust Star Halos パラメータを事前に調整することでハロの拡大を抑制できます。デフォルト値が 0 の場合は 0.3〜0.5 程度に上げてみてください。

関連スレッド:質問コーナーで見る

ハロはある程度自然なもの

BXT の Sharpen Stars スライダーを上げすぎると、輝星の周囲にリング状のアーティファクトが発生することがあります。また Adjust Star Halos パラメータを最小値(−0.5)に設定していても、元画像に既存のハロがあれば残ることがあります。

対処法
  • Sharpen Stars の値を下げる:0.3〜0.5 程度から始めて調整する
  • Adjust Star Halos の活用:プラス方向に調整することでハロに色が乗り、自然な星の色表現になることがある
  • GHS の Local Intensity 調整:ノンリニア段階で中心部の明るさとハロの色表現を両立できます
考え方

「ハロがある方が星の色が出やすい」という見方もあります。完全にハロを消すことに執着せず、最終的な画像として自然に見えるかどうかを判断基準にしてください。

手順
  1. Resources → Updates → Manage Repositories を開き、https://www.rc-astro.com/BlurXTerminator/PixInsight/ が登録されているか確認する
  2. Resources → Updates → Check for Updates を実行する
  3. BXT が一覧に表示されたら選択して Apply を押す
アップデートが表示されない場合

BXT AI4 以降は PixInsight 1.8.9-2 以上が必要です。PI のバージョンが古い場合は先に PI をアップデートしてください。それでも解決しない場合は RC-Astro 公式 FAQ の tensorflow.dll ファイルの置き換え手順を参照してください。

リニア段階で使用できます

BXT は L 画像のリニアフェーズに適用できます。

LRGB 合成時の注意

L 画像とカラー画像の両方に BXT を適用する場合、Stellar Adjustment など主要なパラメータを同じ値に揃えてください。パラメータが異なると LRGB 合成後に色ズレや不自然な仕上がりになる場合があります。

2.4 ImageSolver

原因

① Gaiaカタログに「DR3/SP」(スペクトルデータ版)を使用しているケース。SPはImageSolverには不適切です。
② ビニング設定がImageSolverのピクセルサイズと合っていないケース(例:2×2ビニングなのにピクセルサイズが等倍のまま)。

解決策
  • 「Gaia DR3/SP」ではなく「Gaia DR3」(通常版)を使用してください。
  • 2×2ビニング使用時はピクセルサイズを2倍に設定してください(例:3.76µm → 7.52µm)。

関連スレッド:元のスレッドを見る

原因

ImageSolver は画像内の星をカタログと照合して天球座標を同定しますが、有効な星として認識できる数が少なすぎると照合できずエラーになります。検出パラメータが厳しすぎる・露出が短くて暗い星が写っていない・焦点距離・ピクセルサイズの設定ミスによるスケール不一致などが原因です。

解決策①:検出パラメータの調整

ImageSolver の Star Detection タブで以下の値に変更します:

  • Detection Scales:3 → 8
  • Noise Reduction:0 → 5
  • Log(Sensitivity):−1.0 → −2.0
解決策②:ローカル Gaia DR3 の使用

Gaia DR3 データをローカルにダウンロードし、ImageSolver の Model Parameters で「Local XPSD server → Gaia DR3」を選択します。オンラインサーバーに依存しないため安定して動作します。

関連スレッド:質問コーナーで見る

確認箇所

ImageSolver は Script メニューの「Astrometry」サブメニューにあります:Script → Astrometry → Image Solver。メニューの並び順が変わっているだけで、サブメニューには残っているケースがあります。

見つからない場合
  • Resources → Updates → Check for Updates でスクリプトを再インストールする
  • Resources → Updates → Manage Repositories でリポジトリが正しく登録されているか確認する
  • PixInsight を再起動してメニューを再構築する

関連スレッド:質問コーナーで見る

ダウンロードと設定手順
  1. PixInsight の公式サイト(pixinsight.com)のダウンロードページから「Gaia DR3 Database」を選択してダウンロードする(数 GB〜数十 GB の大容量)
  2. ダウンロードしたデータを任意のフォルダ(例:D:/Catalogs/GaiaDR3)に展開する
  3. PixInsight で Process → Astrometry → XPSD Server Configuration を開く
  4. 「Gaia DR3」を選択し、展開したフォルダのパスを設定する
  5. ImageSolver の Model Parameters で「Server」を「Local XPSD server」に変更する
ヒント

SPCC・SPFC 用には別途「Gaia DR3/SP」データが必要です。ImageSolver 用の DR3 と SPCC 用の DR3/SP は異なるデータセットなので、両方使う場合はそれぞれダウンロードして別フォルダで管理してください。

関連スレッド:質問コーナーで見る

結論

ImageSolver(天体認識・座標付け)には Gaia DR3 を使用してください。DR3/SP は不適切です。

DR3 と DR3/SP の違い

Gaia DR3:位置・固有運動・視差データを含む標準的な星表。ImageSolver はこのデータを使って画像の座標を同定します。

Gaia DR3/SP:DR3 に加えて各星のスペクトルエネルギー分布(SED)データを含む特殊な拡張版。SPCC・SPFC での色較正専用カタログです。ImageSolver で DR3/SP を指定するとエラーになるか正しく認識されません。

ビニングとピクセルサイズの注意点

カメラのカタログスペックのピクセルサイズを入力してしまい、実際に 2×2 ビニングで撮影しているのに 1×1 のピクセルサイズを入力するとスケールが合わず認識に失敗します。例として ZWO ASI2600MCPro のピクセルサイズは 3.76μm ですが、2×2 ビニングで撮影した場合は 7.52μm と入力します。

関連スレッド:質問コーナーで見る

2.5 HDRComposition

HDRComposition とは

HDRComposition は異なる露出時間で撮影した複数のマスターライトを統合して、明るい部分から暗い部分まで幅広いダイナミックレンジを持つ画像を生成するツールです。明るい部分が白飛びした長露出画像と、核部が適切に写っている短露出画像を組み合わせる場合に使います(典型例:M42 オリオン大星雲)。

推奨フロー

WBPP → StarAlignment → DBE/MGC → HDRComposition → SPCC

  • 重要:HDRComposition 前に LinearFit をかける必要はありません。HDRComposition は内部で自動的に各入力画像の線形スケーリングを行います。事前に手動で LinearFit をかけると逆に精度が下がる可能性があります
  • SPCC(カラーキャリブレーション)は HDRComposition 後のリニア画像に対して実行する
  • 入力画像はすべて同一の FoV・位置合わせ済みであること(StarAlignment 後のファイルを使う)
パラメータのポイント
  • Binarize:各露出の有効領域の境界を決めるしきい値。デフォルトで問題ないことが多い
  • Generate mask:チェックしておくと露出の境界マスクが生成され、後から調整に使える

関連スレッド:質問コーナーで見る

原因:露出ごとの StarAlignment を行っていない

HDRComposition は複数の露出時間の画像を合成しますが、各露出セットを個別に StarAlignment で位置合わせしてから HDRComposition に渡す必要があります。位置合わせせずに合成すると、明るい星が黒く抜けたり、対象がずれた不正な結果になります。

解決策:露出ごとに StarAlignment を実行する
  1. 長露出スタック画像を「Reference Image」として StarAlignment を実行する
  2. 短露出スタック画像を「Target Image」として位置合わせする(露出セットごとに実行)
  3. 位置合わせ済みの各露出画像を HDRComposition に入力する
ヒント

ABE/DBE などの前処理は HT でストレッチする前のリニアな段階で実施してください。HDRComposition 自体はリニア段階の画像を入力として想定しています。

2.6 SPFC

設定方法

カラーカメラのフィルター情報にはセンサーの感度も含まれているため、QE Curve は「IdealQEcurve」を指定してください。このとき GrayFilter の情報は無視されます。

HKIR 改造機の場合

HKIR 改造はオリジナルのローパスフィルターを取り除いた後に UV/IR カットフィルターを装着する改造です。そのため RGB フィルターの指定は通常のカラーカメラと同様の設定で問題ありません。

関連スレッド:質問コーナーで見る

問題ありません

SPCC / SPFC は RGB の色バランス係数を求めるシンプルな処理です。フィルター仕様の個体差によってグラフのばらつき(標準偏差 0.4〜0.6 程度)が大きく見えることがありますが、傾向が捉えられていれば十分です。

グラフの数値よりも、最終的な処理結果(星の色・銀河のカラーバランス)が自然に見えるかどうかで判断してください。

原因

SPFC が使用する Gaia DR3/SP データが正しく読み込まれていない場合に発生します。ダウンロードしたデータが正しい場所に配置されていない、または Gaia 設定が壊れていることが多いです。

解決策:Gaia Preferences をクリアして再設定する
  1. PixInsight の Edit → Preferences → Astrometry → GAIA Preferences を開く
  2. 既存の DR3/SP データのリストをクリア(削除)する
  3. DR3/SP を再度選択し、スパナアイコンをクリックしてデータフォルダを再指定する
  4. 左下の○ボタン(有効化)をオンにして確定する
ヒント

Gaia DR3/SP のダウンロードが不完全な場合も同じエラーが出ます。Resources → Database Files → GAIA DR3/SP でダウンロードが完了しているか確認してください。データは数十 GB あるため、完了まで数日かかることがあります。

関連スレッド:質問コーナーで見る

3. ノンリニアフェーズ

3.1 ストレッチ

GHS とは

GHS(GeneralisedHyperbolicStretch)は PixInsight の高機能ストレッチツールで、従来の Histogram Transformation では難しかった「特定の輝度域を選択的に伸ばす」操作を数学的なパラメータで精密に制御できます。Script → Utilities → GeneralisedHyperbolicStretch から実行します。

b 値(Symmetry Point Parameter)の役割
  • b 値を正の値(例:+0.5〜+2):明るい部分を重点的に伸ばす。明るい星雲・輝星雲に向く
  • b 値を 0 付近:全体的に均等にストレッチ(HT に近い挙動)
  • b 値を負の値(例:−0.5〜−2):暗い部分(分子雲・淡い構造)を重点的に伸ばしながら明るい部分の白飛びを抑制。分子雲の強調に非常に有効
分子雲強調の実践設定例

b 値 = −1 から始め、SP(Stretch Point:ストレッチの中心輝度)を画像の背景輝度付近に設定します。LP(Lower Limit Protection:暗い部分の保護下限)を設定することで真の黒(0値)が壊れるのを防ぎます。

ヒント

GHS はリアルタイムプレビューが使えるので、各パラメータを動かしながら画像の変化を見て直感的に学ぶことができます。HT に慣れてから GHS に移行するのが習得の近道です。

関連スレッド:質問コーナーで見る

STF と HT の関係

STF(Screen Transfer Function)はモニターの表示だけを変えるツールで、実際のピクセルデータは変えません。STF を使って「どのようにストレッチするか」を決め、その設定値を HT(Histogram Transformation)に転送して初めてデータが変換されます。

転送の手順
  1. STF ウィンドウを開き(View → Screen Transfer Function または F11 キー)、Auto Stretch ボタン(☆アイコン)をクリックして自動適用する
  2. HT(Histogram Transformation)ウィンドウを開く
  3. STF ウィンドウ内の三角形マーカーをつかんで HT ウィンドウにドラッグする
  4. 重要:HT ウィンドウの最下部にある「▲ ■ ▲」の3つのコントロールが並んだ Input Range エリアにドロップする
  5. HT の「Execute」ボタンを押してストレッチを実行する
よくある失敗

HT ウィンドウの上部グラフ領域(ヒストグラムが表示されている大きなエリア)にドロップしても転送されません。必ず下部のスライダーコントロールエリアを目標にしてください。

関連スレッド:質問コーナーで見る

原因

STF(Screen Transfer Function)は「画面表示の明るさを調整するメガネ」であり、ファイルのピクセルデータ自体には何の変化も与えません。STF で明るく見えている状態でも、ファイルに保存されるのは変換前のリニアデータ(0〜1 の範囲でほぼ 0 に近い値)です。これを 8bit や 16bit JPEG/TIFF で保存すると、ほぼ黒一色のファイルになります。

正しい手順
  1. STF で明るさを調整してプレビューを確認する(この段階では保存しない)
  2. STF のマーカーを Histogram Transformation(HT)の下部コントロールエリアにドラッグ&ドロップする
  3. HT の「Execute」ボタンを押してデータをノンリニア変換する
  4. File → Save As で保存する

関連スレッド:質問コーナーで見る

通常はオフで問題なし

オフにすると RGB 比率が 1:1:1 になり、天体写真では標準的な設定です。オンにすると RGB Working Space の重み付けで輝度を計算しますが、これは人間の視覚特性(緑寄り)に基づくため、天体写真では通常不要です。

Hα や OIII など特定波長を意図的に強調したい場合のみ、オンにして調整することがあります。

L 画像に適用して Local Normalization を活用する

モノクロカメラの場合は L 画像に対して分子雲強調処理を適用します。

ツールの選択

PixInsight 1.8.9 以降では Local Normalization が大幅に強化されており、NSG(スクリプト)より Local Normalization の使用が推奨されます。NSG はスクリプトメニューから削除されています。

方法①:星のみ画像をぼかして合成
  1. SXT または StarNet2 で星なし画像と星のみ画像を作成する
  2. 星のみ画像に Process → Convolution で Gaussian Blur(StdDev 4.0 程度)をかける
  3. PixelMath で Stars_Blurred + Starless を合成する
方法②:元画像をクローンしてぼかし合成
  1. 元画像をクローン(複製)する
  2. 複製に Histogram Transformation で暗部を切り詰め、その後 Convolution(StdDev 5〜20)をかける
  3. PixelMath で 元画像 + a × ぼかし画像(係数 a で効果を調整)で合成する
ヒント

係数 a(0.1〜0.3 程度)を変えることで柔らかさを調整できます。やりすぎると不自然になるため、Preview で確認しながら少しずつ調整してください。

CurvesTransform(CT)とは

CT は RGB の各チャンネルや輝度に対してトーンカーブを個別に適用できるプロセスです。ストレッチだけでなく色補正・コントラスト強調・暗部持ち上げなど幅広い用途に使えます。

Track View を使ったリアルタイム確認

CT にはヒストグラム表示がありませんが、Track View モードで HT と連携できます:

  1. HistogramTransform を開いておく
  2. CurvesTransform タイトルバー左の チェックマーク(Track View) をクリックしてオンにする
  3. この状態で CT のカーブを動かすと HT ヒストグラムにリアルタイム反映される
Preview で安全に試す

画像の一部に Preview を作成してから CT を適用すると、元画像を変えずに効果を確認できます。気に入れば全体に適用、不要なら Undo します。

3.2 NXT / StarNet2

原因

PixInsight がクラッシュした後、モジュールファイルが破損してプロセスリストから MAS が消えることがあります。特に WBPP 実行中のクラッシュで報告されています。MAS は PixInsight のコアモジュールではなく追加スクリプトとして提供されているため、モジュール管理の問題で消えやすいです。

解決策①:Check for Updates で再インストール

Resources → Updates → Check for Updates を実行し、利用可能なアップデート一覧に MAS が出てきたらインストールします。

解決策②:リポジトリの再登録

Manage Repositories でリポジトリ一覧が空になっているか確認してください。削除されている場合は PixInsight 公式サイトから正しいリポジトリ URL を取得して再登録します。

解決策③:完全再インストール

上記で解決しない場合は PixInsight を完全にアンインストール(設定ファイルも削除)して再インストールしてください。

関連スレッド:質問コーナーで見る

推奨タイミング

NXT(NoiseXTerminator)はノンリニア段階(ストレッチ後)での使用が推奨されています。ストレッチによって暗部が引き伸ばされた後の方がノイズが視認しやすく、除去量の調整がしやすいためです。

パラメータの目安
  • Denoise(0〜1):0.7〜0.9 が一般的。1.0 に近づけると細部がつぶれやすくなる
  • Detail Preservation(0〜1):0.7〜0.85 が目安。高いと星雲のフィラメント構造が残りやすい
ヒント

処理前後の画像を 1:1 ズームで比較しながら調整することが重要です。全体を縮小表示して見ると過剰にかけていてもわかりにくいですが、1:1 で確認すると細部の損失が一目瞭然です。

推奨:Screen 合成(飽和しない)

SXT などで生成した星なし画像と星のみ画像を別々に強調後に合成する場合、PixelMath で Screen 合成が推奨されます:

Combine(Starless, Stars, op_screen())

計算式は 1 – (1-A) × (1-B) で、ピクセル値が常に 0〜1 に収まるため単純加算で起きる白とびが発生しません。

単純加算との違い

例:Starless=0.5、Stars=0.6 の場合

  • 単純加算:0.5 + 0.6 = 1.1 → 飽和(白とびで情報損失)
  • Screen 合成:1 – (1–0.5)(1–0.6) = 0.8 → 飽和なし
ヒント

Photoshop の「スクリーン」レイヤーモードと同じ演算です。天体写真以外でも広く使われている標準的な合成手法です。

3.3 マスク

例:M81とM82が同じ画角に入っている場合にM81だけ処理したい

RangeMask だけでは同じ輝度域にある M82 も一緒に選択されてしまいます。GAME スクリプトで対象天体の領域を二値マスク化し、RangeMask と組み合わせることで目的の天体だけを選択できます。

手順
  1. RangeMask で両天体のマスクを作成:輝度範囲を指定して、対象・非対象の両方を含むマスク画像(range_mask)を生成する
  2. GAME スクリプトで対象天体だけのマスクを作成:Script → Utilities → GAME を開き、対象天体の位置・形状を設定して実行。対象天体の領域だけを白く塗った二値マスク画像(game_mask)を生成する
  3. PixelMath で合成:range_mask * game_mask と入力して実行する(積算により「両方のマスクが重なる部分」=対象天体だけが残る)
銀河のような輪郭がはっきりした天体

M82 のようにシルエットが明確な天体は GAME スクリプト単独で直接マスク化できます。RangeMask との合成が不要な場合もあります。

なお、CloneStamp は Process メニューの「All Processes」内にあります。

注意:GAME が起動しない場合

GAME スクリプトは画像ウィンドウが開いた状態でないと起動できません。「No active image」エラーが出た場合は、処理対象の画像を先に開いてから実行してください。

関連スレッド:質問コーナーで見る

方法①:StarNet2 を使う(推奨)

StarNet2 でスターレス画像を生成し、PixelMath でオリジナルから差し引くことで星のみの画像(星マスク)が得られます:

  1. StarNet2 を実行してスターレス画像を生成
  2. PixelMath 式:max(0, original - starless)
  3. 生成された画像を適切にストレッチして使用する
方法②:StarMask スクリプト

Script → Utilities → StarMask で直接生成する方法もあります。ただし StarNet2 の方が精度の高いマスクが生成できることが多いです。

星マスクの活用例
  • CurvesTransformation で星の明るさ・色を個別に調整
  • StarReduction で星を小さくする処理のベースマスク
  • ハロ処理時の保護マスク(星周辺だけに処理を限定)
方法①:StarReduction スクリプト

Script → Utilities → StarReduction を使います。主なパラメータ:

  • Amount(0〜1):縮小の度合い。0.3〜0.5 が自然な範囲
  • Iteration:繰り返し回数。増やすと星がより小さくなるが不自然になりやすい
方法②:スターレス合成による方法(より精密な制御が可能)
  1. StarNet2 でスターレス画像を生成する
  2. PixelMath でオリジナルから星の部分だけを抽出:max(0, original - starless)
  3. Morphological Transformation(Erosion または Median Filter)を stars 画像に適用して星を物理的に収縮させる
  4. PixelMath で縮小した stars とスターレス画像を再合成:starless + stars_reduced

関連スレッド:質問コーナーで見る

よく使う PixelMath 式集

2つのマスクの AND(両方明るい部分のみ):
mask1 * mask2

2つのマスクの OR(どちらかが明るい部分):
max(mask1, mask2)

マスクの反転:
1 - mask

2枚の画像の差(星マスク生成):
max(0, original - starless)

マスクのブレンド(2枚の画像をマスクで合成):
mask * img_a + (1 - mask) * img_b

Symbols タブの活用

PixelMath の Symbols タブで変数名と画像 ID の対応を定義すると、式が読みやすくなります。例:S=starless_img, O=original_img と定義すれば式内で SO が使えます。

原因

ストレッチ済みの値同士を加算すると合計が 1.0 を超えてクリッピング(白飛び)します(例:0.8 + 0.3 = 1.1)。

解決策:Screen ブレンドを使う(推奨)

combine(A, B, op_screen()) — Screen 合成は値が 1 を超えないため飽和が起きません。

その他の対処法
  • Rescale result をオンにする(全体が暗くなるため追加ストレッチが必要)
  • 各画像のストレッチ量を下げて合計が 1.0 以内に収まるよう調整する

3.4 ナローバンド処理

背景

カラーカメラで通常撮影した RGB データに、Hα フィルターをかけて撮影したモノクロデータを合成することで、Hα の輝線領域(赤い星雲構造・HII 領域)を強調した画像が作れます。特に銀河の星形成領域や星雲の赤い部分の強調に有効です。

手順
  1. カラー画像をチャンネル分離:Process → Channels → Channel Extraction で R・G・B を別画像として抽出する
  2. Channel Combination で再結合:「R = Hα画像、G = 元G画像、B = 元B画像」として組み合わせる
エラーが出る場合

「色空間が一致しない」というエラーが出る場合は、すべての画像を同一の色空間(RGB またはグレースケール)に統一してください。Channel Combination の適用ボタンは「⚫(全画像に処理)」を使うこと。

関連スレッド:質問コーナーで見る

HOO パレット(Hα + OIII)

デュアルバンドフィルターや Hα・OIII 個別フィルターで撮影したデータを Channel Combination で:

  • R チャンネル:Ha
  • G チャンネル:OIII
  • B チャンネル:OIII

合成後、SCNR(Script → Utilities → SCNR)でグリーンノイズを除去し、CurvesTransformation で色バランスを整えます。

SHO パレット(Hubble パレット)

モノクロカメラ + SII・Hα・OIII フィルターで撮影したデータを Hubble 宇宙望遠鏡風の色に割り当てる方式:

  • R チャンネル:SII
  • G チャンネル:Ha
  • B チャンネル:OIII
ヒント

Foraxx Palette Utility(PixInsight プラグイン)を使うと HOO・SHO・RGB+Ha などの合成を GUI で簡単に実行できます。Resources → Updates からインストールしてください。

関連スレッド:質問コーナーで見る

原因

SPCC は画像内の星が広帯域の連続スペクトルを持つことを前提に色較正を行います。しかし Hα(656nm)と OIII(500nm)の2つの輝線波長のみを透過するデュアルバンドフィルターを使用した画像では、星のスペクトルが2点しかサンプリングされず、SPCC が想定する連続スペクトルとの乖離が大きくなります。

解決策
  • SPCC の Narrowband フィルター設定を使う:SPCC の Filter タブで「Narrowband」を選択し、実際に使用したフィルター(Hα / OIII など)を指定する
  • 旧来の色較正に切り替える:Background Neutralization → Color Calibration の組み合わせ
手順
  1. ナローバンド画像の星を除去:StarNet2 または StarXTerminator でスターレス画像を作成する
  2. PixelMath でブレンド:チャンネルごとに比率を調整して合成する
    • Lighten モード(最大値比較):max(rgb_R, nb_R * boost) など
    • 加算ブレンド:rgb_R + nb_R * boost

ブレンド後に全体の色調が変わりやすいため、boost パラメータを調整しながら複数回試行が必要です。

手順
  1. Star Alignment で RGB 画像と Hα 画像の位置を合わせる
  2. Hα 画像を Histogram Transformation でストレッチ・調整する
  3. PixelMath で各チャンネルに数式を適用する:
    • R: max(R, Ha * boost)(Hα を R チャンネルに加算)
    • G: G(そのまま)
    • B: iif(Ha > threshold, B - Ha * B_boost, B)(条件付きで調整)

boost・B_boost の値は画像に合わせて実験的に調整してください。マスクを使うと対象天体周辺のみに効果を限定できます。

手順
  1. WBPP でそれぞれの画像をキャリブレーション・スタックする(LRGB 合成は WBPP では行われません)
  2. リニアフェーズで L 画像・RGB 画像それぞれに DBE/ABE を適用する
  3. RGB 画像の RGB Working Space を 1:1:1 に調整する
  4. L 画像と RGB 画像を同程度の明るさにストレッチする
  5. LRGBCombination ツールでストレッチ済みの L 画像と RGB 画像を合成する

LRGB 合成はストレッチ後(ノンリニアフェーズ)に実行してください。

PixelMath で比較明合成する

StarAlignment でカラー画像と Hα 画像を位置合わせした後、PixelMath で以下の式を適用します(「単一 RGB 式」ではなくチャンネル別に設定):

  • R チャンネル:max($T[0], boost * Ha_Blend)
  • G チャンネル:$T[1](変更なし)
  • B チャンネル:iif($T[0] < boost*Ha_Blend, $T[2] + B_boost*Ha_Blend, $T[2])
  • Symbols:boost=1.2, B_boost=0.06
パラメータの意味
  • boost:Hα の強度倍率。値を上げると赤い部分が強調される
  • B_boost:Hα 領域に微量の青成分を加えてマゼンタへのかぶりを防ぐ
ヒント

Hα 画像はストレッチ後のノンリニア画像で合成します。Hα 画像を HT で背景をカットしてから合成すると、背景ノイズの影響を抑えられます。

比較明(max 関数)合成が有効

Channel Extraction で QBP 画像を RGB に分解し、各チャンネルを max 関数でブレンドします:

max($T[0], QBP-R * 1.2)(R チャンネルの例)

手順
  1. SXT で QBP 画像の星を除去する(星なし QBP 画像を作成)
  2. Process → Channel Management → Channel Extraction で QBP 画像を R・G・B に分解
  3. PixelMath でチャンネルごとに max 関数を適用する
  4. Process → Channel Management → Channel Combination で RGB を再結合する
カラーバランス調整

ノンフィルター画像と QBP 画像はカラーバランスが異なります。合成後に SPCC や CurvesTransform で色調を整えてください。

注意:モノクロカメラ × デュアルバンドフィルターの制約

モノクロカメラにデュアルバンドフィルター(Ha+OIII など)を装着すると、Ha と OIII が 1 枚のモノクロ画像に混在します。これらを分離することはできません。

この組み合わせの問題点
  • Ha と OIII が分離できないため RGB ブレンド時に両者が同比率で加算されてしまう
  • デュアルバンドフィルターはバンド幅が数十 nm と広く、3〜7 nm のナローバンドと比べてコントラストが低い
  • 結果として単色の茶色い画像になり LRGB+Ha の効果が出ない
推奨

LRGB+Ha 合成を意図する場合は通常の Ha ナローバンドフィルター(3〜7 nm)を使用してください。デュアルバンドフィルターはカラーカメラで星を減らしながら星雲を写すことに特化した用途向けです。

4. 環境整備、その他

4.1 インストール

原因

macOS では WBPP や重い処理のクラッシュ後に PixInsight が再起動できなくなることが頻繁に報告されています。クラッシュ時にロックファイルや設定ファイルが破損した状態で残り、次回起動時にそのファイルを読もうとして処理が止まることが原因と考えられます。PixInsight の再インストールだけでは設定ファイルが残るため解決しないことがあります。

解決策①:Mac の再起動(まず試す)

完全に Mac を再起動してください。単純ですが、多くのケースでこれだけで解決します。

解決策②:PixInsight の設定ファイル削除

PixInsight のユーザー設定フォルダを削除または移動してから再インストールします。設定フォルダは通常 ~/Library/Application Support/PixInsight/ にあります。このフォルダを削除するとすべての設定が初期化されますが、PixInsight 自体が起動するようになります。

ヒント

WBPP クラッシュ前に masterLight ファイルが出力フォルダに書き出されていれば、データは保全されています。PixInsight を再インストールした後は処理を継続できます。

関連スレッド:質問コーナーで見る

原因

サードパーティのリポジトリ(StarNet2・RC Astro など)の URL が変更されていたり、一時的にサーバーが停止していたりすると、Check for Updates 時にエラーになります。PixInsight 本体のメジャーバージョンアップ後、古いリポジトリ URL が新バージョンに対応していないために発生するケースもあります。

解決策
  1. Resources → Updates → Manage Repositories を開く
  2. エラーになっているリポジトリを特定する
  3. そのリポジトリを一時的に無効化(チェックオフ)してから Check for Updates を再実行する
  4. 問題のリポジトリの公式サイトで最新の URL を確認して更新する
Activation Code の取得手順
  1. PixInsight 公式サイト(pixinsight.com)にアカウントでログインする
  2. マイページの「Your Orders」または「Activations」セクションを開く
  3. 「Request Activation Code」から新しい PC 用コードを発行する
  4. PixInsight インストール時の「Activate Software」画面でコードを入力する
ライセンス管理

PixInsight のライセンスは購入した1つのシリアルナンバーで最大2台まで同時にアクティベートできます。3台目をアクティベートしたい場合は、先に不要になった端末の登録をマイページから解除(Deactivate)する必要があります。

関連スレッド:質問コーナーで見る

原因

PixInsight は高解像度天体写真の処理に大量のメモリを使います。特に Drizzle(Scale 2.0 では面積が 4 倍)・Image Integration・BXT・NXT などの処理はメモリを大量消費します。RAM が不足するとスワップ(仮想メモリ)を使い始め、SSD でも速度が数十倍低下します。

解決策
  • PixInsight のメモリ設定を調整:Edit → Preferences → Process → Max Memory Usage を物理 RAM の 60〜75% に設定する
  • 不要なウィンドウを閉じる:開きっぱなしの大きな画像ウィンドウがあれば閉じる
  • Drizzle Scale を下げる:2.0 → 1.5 にするだけでメモリ使用量が大きく減る
  • macOS の場合:PixInsight を定期的に再起動してメモリリークを防ぐ
推奨 RAM

快適に使うには 32GB 以上を推奨します。Drizzle × 高解像度カメラ(例:60MP の ASI6200MC)では 64GB あっても不足することがあります。

原因

PixInsight はファイルパスに日本語(全角文字)が含まれると、アップデートの失敗・カラーキャリブレーションのグラフ非表示など様々な問題を引き起こします。

解決策
  • 画像ファイルと処理フォルダはすべて英数字のパスに移動する
  • 根本的な解決策:Windows のユーザーアカウント名を英字で新規作成し、そのアカウントで PixInsight を使用する(アカウント名自体が日本語の場合、Global Preference の変更だけでは解決しないことがあります)
手順
  1. 試用版を完全にアンインストールする
  2. 公式サイトから正規版を新たにダウンロードしてインストールする
  3. アクティベーション画面でライセンスコードを入力する

試用版にそのままライセンスコードを入力するのではなく、再インストールが必要です。

できます

新しい PC で公式サイトから PixInsight を再インストールし、アクティベーション画面で新しいコードをリクエストして認証します。ファイルを直接コピーする必要はありません。

複数台のPCへのインストールは公式FAQ(2.7)でもサポートされています。

原因

Foraxx のリポジトリが最新 PixInsight バージョンに未対応の場合があります。

手動インストール手順
  1. ZIP ファイルを直接ダウンロードする(公式サイトまたは配布 URL から)
  2. PixInsight の Script メニュー → Feature Script を開く
  3. 「Add」をクリックし、ダウンロードした ZIP 内の scripts/ForaxxPalette フォルダを指定する
  4. Script → Utilities に表示されるようになります
原因

EzStarReduction は StarNet2 ではなく旧バージョンの StarNet を使用します。StarNet2 のみインストールした状態では動作しません。

解決策

PixInsight を再インストールすると、パッケージに含まれる元の StarNet が復元されます。

原因:リポジトリが削除されている

誤って Resources → Updates → Manage Repositories から公式リポジトリを削除してしまった場合や、アップデート後にリポジトリ設定がリセットされた場合にモジュールが消えることがあります。

解決策①:公式リポジトリを再追加する

Resources → Updates → Manage Repositories を開き、PixInsight 公式リポジトリ(https://pixinsight.com/update/ など)が登録されているか確認してください。ない場合は追加して Check for Updates を実行します。

解決策②:再インストール

上記で解決しない場合は PixInsight を完全にアンインストールしてから再インストールしてください。設定・アイコンは再インストール後に Loss of Modules ウィザードで復元できます。

原因

よく紹介されている URL の中にはダウンロードサイトではなく「インストール方法の説明ページ」のものがあり、これを Manage Repositories に追加すると 404 エラーになります。また RC-Astro(BXT・NXT)のリポジトリが原因でエラーが表示されている場合も、GraXpert のエラーと混同されることがあります。

解決策
  • 追加したリポジトリ URL が 404 の場合は Manage Repositories から削除して、公式サイト(graXpert-astro.eu)で最新のリポジトリ URL を確認してから再追加する
  • エラーメッセージが BXT/NXT 関連の場合は RC-Astro のリポジトリ URL を確認・修正する
GraXpert の使い方

GraXpert は PixInsight プラグインとしてもスタンドアローン版としても動作します。PixInsight に組み込む場合は Manage Repositories から公式プラグインリポジトリを追加してください。

対処法(順番に試してください)
  1. Mac をシャットダウンして再起動する:単なる再起動ではなくシャットダウンから起動し直すと解決することが多い
  2. WBPP キャッシュを削除する:WBPP 実行中のクラッシュが原因の場合は、PixInsight のキャッシュフォルダ(ユーザー Library 内)を削除してから再起動する
  3. PixInsight を再インストールする:公式サイトから最新版をダウンロードして再インストールする(ライセンスは再取得不要)
ヒント

Mac 環境では WBPP の大量処理中に PixInsight がクラッシュすることが知られています。処理中は他のアプリを閉じ、スリープを無効にしておくことをお勧めします。

原因

リポジトリ URL を追加してもアップデートリストに表示されない場合は、古いアップデートキャッシュが残っていることが原因です。

解決策:アップデートキャッシュをリセット
  1. Resources → Updates → Reset Updates を実行する
  2. PixInsight を再起動する
  3. Resources → Updates → View Installed Updates を開く
  4. GHS を選択してインストールする

この手順でキャッシュがクリアされ、新しいリポジトリが認識されるようになります。

Gaia DR3/SP カタログとは

SPCC(Spectrophotometric Color Calibration)および SPFC の実行には Gaia DR3/SP 星表のローカル保存が必要です。約 3 GB のファイルが 20 個以上あり、総容量は数十 GB に達します。

ダウンロード方法
  1. Resources → Database Files → GAIA DR3/SP を選択
  2. Small Set(少ファイル数)または Complete Set(全天)を選択
  3. エラーが出たら再試行することで順次ダウンロードが進む
ヒント

完全ダウンロードには数日かかる場合があります。夜間のバックグラウンドダウンロードを活用してください。よく撮影する天域をカバーする Small Set でも実用的ですが、Complete Set を推奨します。

原因:PixInsight バージョンに対応していないインストーラーを使用している

PixInsight 1.9.0 以降ではモジュールの署名仕様が変更されたため、旧バージョン向けの StarNet2 インストーラーを使うと「Required module signature not found」エラーになります。Mac M1/M2 では「Module initialization error: Exit code: 1」として現れることもあります。また旧バージョンでは lib フォルダへの配置でしたが、現在は bin フォルダへの配置に変更されています。

解決策(Windows)
  1. StarNet 公式サイトから 「PI versions 1.9.0 and higher」対応版のインストーラーを再ダウンロードする
  2. インストーラーを実行し、ファイルを bin フォルダC:\Program Files\PixInsight\bin)に配置する
  3. PixInsight を再起動して StarNet2 が認識されるか確認する
解決策(Mac M1 / M2)

公式ガイド(masahiko.me/starnet2_m1_mac/)の手順に従い、ターミナルからコマンドを実行してインストールしてください。通常のダブルクリックインストールは Mac M1/M2 では動作しません。

ヒント

PixInsight 本体をメジャーバージョンアップした後は StarNet2 の再インストールが必要なことがあります。動作しない場合はまず公式サイトで使用中の PI バージョンに対応した StarNet2 ファイルが提供されているか確認してください。

関連スレッド:質問コーナーで見る

4.2 ファイル操作

原因①:デベイヤーされていない

カラーカメラ(ベイヤー配列)で撮影した masterLight がデベイヤー処理されていない状態です。WBPP の Lights タブで「Debayer」が無効になっていた場合に発生します。

原因②:モノクロカメラ使用(正常)

モノクロカメラを使っている場合は GRAY 表示が正常です。単色フィルター(L・R・G・B・Ha 等)で撮影した場合のマスターライトはグレースケールです。

解決策

カラーカメラを使っているのに GRAY と表示される場合:WBPP を開き、Lights タブで Debayer のチェックをオンにして再実行してください。Bayer Pattern は使用しているカメラに合わせて選択します(多くのカラー CMOS は RGGB)。

後からデベイヤーする方法

WBPP を再実行したくない場合は、Process → Debayer を masterLight に直接適用することで後からデベイヤーできます。

関連スレッド:質問コーナーで見る

形式の特徴

XISF:PixInsight のネイティブ形式。ピクセルデータに加えて WCS ヘッダー・FITS 情報・プロセス履歴・プレビューなど豊富なメタデータを保持できます。処理途中の全段階で XISF 保存を推奨。

TIFF:業界標準の高品質形式。8/16/32bit をサポートし、他ソフトとの互換性が高い。処理完了後の保存や他ソフトへの受け渡しに使用。

JPEG:非可逆圧縮。Web 公開・SNS 投稿用の最終出力に使用。品質 90〜95 が一般的。処理に使う中間ファイルとしては不適。

一括変換(Batch Format Conversion)
  1. Script → Batch Processing → Batch Format Conversion を開く
  2. 変換したいファイルを追加する
  3. Output Format(TIFF / JPEG など)とビット深度を設定する
  4. Output Directory を指定して実行する
推奨ビット深度

リニア処理中:32bit float XISF。最終出力 TIFF:16bit。Web 用 JPEG:sRGB 8bit。

必ず残すもの

masterLight(スタック済み最終フレーム)は必ず保持してください。

削除してよいもの
  • calibrated フォルダ:キャリブレーション済みの中間ファイル。処理完了後は削除可
  • registered フォルダ:位置合わせ済みフレーム。削除可
  • logs フォルダ:処理ログ。削除可

masterDark・masterBias・masterFlat は、同じ条件(温度・ISO・露光時間)で再撮影しない場合は再利用できるため、ストレージに余裕があれば残しておくと便利です。

FITS ヘッダーで確認する
  1. File メニュー → FITS Header を開く
  2. EXPTIME:1枚あたりの露光時間(秒)
  3. HISTORY → numberOfImages:採用された画像の枚数
  4. 総露光時間 = EXPTIME × numberOfImages で計算

WBPP の Post-Calibration タブでも目安の総露光時間が表示されますが、リジェクトされたフレームも含まれるため実際より長くなります。

ImageContainer + Process Container を使う
  1. ImageContainer に対象ファイルを登録し STF 処理を適用する
  2. その結果に HistogramTransformation を実行する
  3. BatchFormatConversion で TIFF に変換する

さらに自動化する場合は Process Container を併用すると、上記の処理を1回の操作でまとめて実行できます。

FITS ヘッダーで確認する
  1. マスターライト画像を開いた状態で File → FITS Header を実行する
  2. EXPTIME で 1 フレームの露光時間(秒)を確認する
  3. HISTORY セクション内の numberOfImages で採用枚数を確認する
  4. 総露光時間 = EXPTIME × numberOfImages で算出する

例:EXPTIME=300 秒、numberOfImages=282 → 総露光 300 × 282 ÷ 3600 ≈ 23.5 時間

WBPP 画面の表示について

WBPP の Post-Calibration タブに推定露光時間が表示されますが、リジェクトフレームも含むため実際より長くなります。正確な値は FITS ヘッダーで確認してください。

注意:画像を単体保存すると履歴は消える

History Explorer でやり直せるのはその画像が現在のセッションで開いている間だけです。Save As で XISF/FITS として保存すると処理履歴は消え、以降はやり直しができません。

処理履歴を残したい場合:プロジェクトファイルで保存

File → Save Project でプロジェクトファイル(.xosm)として保存してください。開いている全画像の処理履歴・ウィンドウ配置・アイコン設定がすべて保存されます。File → Open Project で前回終了時の状態から再開できます。

ヒント

マスターライトは重要なマイルストーンで個別保存し、以降の編集作業はプロジェクトファイルで管理するのが一般的なワークフローです。

方法①:Process Icons として保存
  1. プロセスの ▲マークをワークスペースにドラッグ&ドロップしてアイコンを作成する
  2. アイコンを右クリック → Set Icon Identifier で名前を付ける
  3. Process → Save Process Icons… でアイコンセットを保存する
  4. 次回起動時は Process → Load Process Icons… で呼び出す
方法②:Process Container で連続実行

複数処理を 1 枚の画像に連続適用したい場合は Process Container を使います。各プロセスの▲マークを Process Container にドラッグして登録し、まとめて適用できます。

制限事項

Debayer のようにファイル入出力を伴う処理や STF→HT のような値の受け渡しを要する処理は Process Container では連続実行できません。STF→HT の代替として Auto Histogram を使うと似た結果が得られます。

手順
  1. Process → ColorSpaces → ColorManagementSetup を開く
  2. Default Profiles の RGB を Adobe RGB に設定して Apply Global を実行する
  3. 対象画像をアクティブにした状態で File → Save As → TIFF(16bit)を選択して書き出す
Windows 環境での注意

Windows では AdobeRGB 指定で保存しても sRGB が埋め込まれる場合があります(PixInsight の既知のバグの可能性)。Mac 環境では正常に動作します。Windows の場合は Adobe Photoshop や別ツールでプロファイルを付け直す方法も検討してください。

4.3 撮影・機材

根本原因

縮緬ノイズはマスターフラットフレームの S/N 比不足が原因で、処理側での完全な除去は困難です。撮影段階で高品質なフラットフレームを取得することが根本的な解決策です。

フラット光源の輝度を上げる

モニターを光源とする場合は輝度を最大(100%)に設定します。モニターでは不十分な場合は専用のフラットパネル(EL パネル・LED パネル)の使用を検討してください。

適切な露出時間の設定

フラットフレームのヒストグラムピークが 左から 1/3 〜 中央付近(ADU 値で最大値の 30〜50%)になるよう露出を調整してください。

フラット枚数を増やす

最低でも 20 枚、できれば 30〜50 枚を撮影してください。フラットは毎回の撮影セッションで新規に撮影するのが理想です。

関連スレッド:質問コーナーで見る

完全遮光でダークを撮影する

CMOS カメラはレンズキャップを取り付けただけでは不十分な場合があります。カメラ本体を布や遮光袋で完全に覆った状態でダークフレームを撮影してください。

ライトと同一条件でダークを撮影する

Gain・Offset・温度・露出時間をライトフレームと完全に一致させてください。FITS ヘッダーの GAINOFFSETCCD-TEMP の値をライトとダークで比較して確認します。

キャリブレーションフレームを定期的に撮り直す

特に CMOS センサーは経年変化があるため、3〜6ヶ月ごとにキャリブレーションフレームを更新することを推奨します。

関連スレッド:質問コーナーで見る

なぜ銀河に不向きか

デュアルバンドフィルター(Hα・OIII のみ透過)は輝線星雲専用に設計されています。銀河は内部の恒星が放つ連続スペクトル(可視光全域)で光っており、デュアルバンドフィルターをかけると銀河光の大部分がカットされて極端に暗くなります。アンドロメダ銀河(M31)を例にすると、青い外縁の腕はデュアルバンドの透過帯域外にあるためカットされ、Hα で光る赤い HII 領域だけが残って黄色っぽい発色になります。

銀河に適したフィルター選択
  • フィルターなし:光害の少ない場所では最もナチュラルな色が出る。推奨
  • LP フィルター(光害カットフィルター):主要な光害波長帯のみをカット。銀河の連続スペクトルは保持される。L-Pro(Optolong)など
  • UHC フィルター:光害が強い都市部での折衷案

関連スレッド:質問コーナーで見る

X-Trans とは

富士フイルムのミラーレスカメラ(X-T・X-S シリーズ等)に採用されている独自のカラーフィルター配列で、通常のベイヤー(RGGB)とは異なる 6×6 の周期パターンを持ちます。

WBPP の設定

Lights タブの「Debayer Pattern」で「X-Trans」を選択してください。デフォルトの RGGB や BGGR で処理すると色が大きくずれた画像になります。

SPCC の設定

Fujifilm のフィルター情報は SPCC にないため、他社フィルターを代替として選択します。実用上の精度差は無視できる程度です。

X-Trans 特有の注意点
  • X-Trans は通常のベイヤーよりもデベイヤー処理が複雑で、CPU 処理時間が長くなる傾向がある
  • PixInsight の最新バージョンを使うと X-Trans 対応の改善が反映されていることがある

関連スレッド:質問コーナーで見る

優先順位:CPU > メモリ > SSD >> GPU
  • CPU:最新世代の Core i7 以上、または Ryzen 5700 以上を推奨。マルチスレッド処理が重要です
  • メモリ:最低 32GB、可能なら 64GB。32GB → 64GB にするだけで大幅に高速化します
  • SSD:メモリ不足時の仮想メモリとして重要。NVMe SSD を推奨
  • GPU:StarNet v1 では NVIDIA GeForce(2〜3 万円程度)が有効でしたが、StarNet2 以降は CPU 処理で十分です。Quadro は不要です
対処法
  • Pixel Rejection を活用(推奨):子午線後の画像を複数グループに分けて統合し、Image Integration の外れ値除去(Sigma Clipping など)で光条を除外する。Sigma High 値の調整が有効です
  • マスク処理:グループごとに個別統合後、PixelMath で光条部分を抽出してマスクで置き換える
  • Median 合成:Average ではなく Median を使うと、少数派の光条が除外されやすくなります

いずれの方法も S/N 比とのトレードオフがあります。

広角フラット補正の難しさ

広角系は周辺光量落ちが大きく、フラット補正が極めて難しいです。背景ムラが残りやすいため、StarNet でスターレス画像を作成し、Convolution + PixelMath で自作フラット補正する手法が有効な場合があります。

分子雲には長時間露光+ナローバンドフィルターが有効

分子雲は極めて淡いため、30分程度の総露光時間では十分なデータが得にくいです。デュアルバンドパスフィルターの活用で光害を抑えつつ Hα などの輝線成分を強調できます。

キーワードに一致する質問が見つかりませんでした。別のキーワードで検索してみてください。
タイトルとURLをコピーしました