よくある質問（FAQ）ベータ版

原因①：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 ヘッダーの GAIN・OFFSET 値をライトとダークで必ず比較してください。

原因②：画像の上下反転

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

原因③：Optimize Master Dark の誤作動

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

解決策

• ライト／ダークの FITS ヘッダーを Image Header ウィンドウで開いて GAIN・OFFSET・CCD-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 程度）をマスターフラットに適用してからキャリブレーションに使用してください。

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

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

赤道儀が子午線を越えて望遠鏡が反転（フリップ）すると、カメラが 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% 縮小することでフレーム間のコントリビューションが重ならず解像度が向上します。

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

推奨フロー

多くのユーザーに支持されている一般的な順序：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 の自動処理から始めるのが取り組みやすい

原因

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 フィルター（特定輝線だけでなく光害帯域を広くカット）の方が銀河撮影に適しています。

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

原因

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 程度に上げてみてください。

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

原因

① 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 と入力します。

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

HDRComposition とは

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

推奨フロー

WBPP → StarAlignment → DBE/MGC → HDRComposition → SPCC

• 重要：HDRComposition 前に LinearFit をかける必要はありません。HDRComposition は内部で自動的に各入力画像の線形スケーリングを行います。事前に手動で LinearFit をかけると逆に精度が下がる可能性があります
• SPCC（カラーキャリブレーション）は HDRComposition 後のリニア画像に対して実行する
• 入力画像はすべて同一の FoV・位置合わせ済みであること（StarAlignment 後のファイルを使う）

パラメータのポイント

• Binarize：各露出の有効領域の境界を決めるしきい値。デフォルトで問題ないことが多い
• Generate mask：チェックしておくと露出の境界マスクが生成され、後から調整に使える

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

設定方法

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

HKIR 改造機の場合

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

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 で保存する

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

原因

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 で確認すると細部の損失が一目瞭然です。

例：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」内にあります。

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

方法①：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 と定義すれば式内で S・O が使えます。

背景

カラーカメラで通常撮影した 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 の組み合わせ

原因

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 あっても不足することがあります。

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

カラーカメラ（ベイヤー配列）で撮影した 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。

根本原因

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

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

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

適切な露出時間の設定

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

フラット枚数を増やす

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

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

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

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

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

Gain・Offset・温度・露出時間をライトフレームと完全に一致させてください。FITS ヘッダーの GAIN・OFFSET・CCD-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 対応の改善が反映されていることがある

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