Platesolving（画像での天体位置解析機能）のインデックスファイルについて

AstRPiではローカル環境（ネット接続しなくても使用できる）で3つのPlatesolvingが利用できます。

サーバとインデックスファイルの一部はすでにインストールされていますので、電子ファインダー程度（50mm）の焦点距離であればなにもせずにすぐにご使用いただけますが、ご使用になる鏡筒の焦点距離に応じてインデックスファイルを追加する必要があります。
（本当は全て含めておきたいのですが、非常に容量が大きいためインデックスファイルを全てインストールすると配布できなくなります。）

Platesolvingの種類によっても扱いなどが異なりますのでそれぞれにインストールやバックアップ方法などを記載します。

●StellarSolver
SExtractorの画像処理を利用したPlatesolvingになります。
Platesolvingの処理エンジン自体はAstrometry.netを使用しますのでインデックスファイルの追加などはAstrometry.netのものを利用します。

インストール方法としては2種類あります。
・Ekosのアライメントモジュールオプションを利用する方法はこちら

ドライバを起動する必要がありますが（ドライバ起動しないとアライメントモジュールが表示されないので）、シミュレーションドライバなどで起動すれば簡単にインデックスファイルを追加できます。
この方法でインデックスファイルをインストールすると以下のディレクトリにインデックスファイルが配置されます。

/home/astrpi/.local/share/kstars/astrometry

面倒なことに不可視フォルダになっていますので通常では見ることができません。
そのため、AstRPiはこのディレクトリへのシンボリックリンクを作成してあります。

/home/astrpi/INDI-config/astrometry

INDI-configフォルダは共有フォルダになっていますのでファイル共有でインデックスファイルにアクセスすることも可能です。

ここにあるインデックスファイルを外付けSSDやファイル共有でアクセスしたPCにコピーすれば簡単にインデックスファイルのバックアップが取れます。（新しい環境へのインストールはバックアップしたインデックスファイルをこのフォルダにコピーするだけ）

・インストーラーを使用してインストールする方法はこちら

開発者のサイトにインデックスファイルをdebファイルにまとめてあります。
インストールするには
SpaceFMを立ち上げてメニュー→ファイル→RootWindowを選択→ダウンロードしたDEBファイルを右クリック→GDebiで開くを選択
これでインストーラが立ち上がりますのでインストールできます。

この方法には2つ欠点があります。
・オプションのTycho2インデックスをインストールできない（サイトに用意されていません。）→AstRPiではすでにインストール済みです。
・インストールされるディレクトリがシステム領域のため、上記SpaceFMを使用してRootWindowで操作しないと変更ができない（Root権限が必要）

/usr/share/astrometry

KStarsがインストールされていれば、Astrometry.netサーバ自体はどちらのディレクトリにインデックスファイルがあっても認識されます。

後々のことを考えるとユーザー領域にインデックスファイルがある方が取り扱いが楽なので、インストーラでインデックスファイルをインストールした場合は

/home/astrpi/INDI-config/astrometry

にインデックスファイルを移動してください。


●Astrometry.net
上記StellarSolverと同じです。


●ASTAP
全く異なる方法で解析するため上記Astrometry.netのインデックスファイルを使用しません。

こちらからインストーラタイプのインデックスファイルをダウンロードしてインストールします。

インデックスファイルはG17、G18の2種類あり、通常使用ではG17を使用します。
G18インデックスは焦点距離が長いシュミカセなどを使用する場合に使います。

AstRPiではすでにデフォルトのインデックスファイルG17がインストールされています。

ASTAPのインデックスファイルは排他になっており、長焦点の鏡筒でG18のインデックスファイルを使用したい場合はG17インデックスは削除する必要があります。
上記Astrometry.netインデックスのインストール同様SpaceFMでG17のインストーラをGDebiで立ち上げるとデイントール（削除）ができますので、その後、G18のインデックスファイルをインストールしてください。

ASTAPは上記の通り、G17、18のいずれかのインデックスファイルをインストールすればよいだけなのでバックアップしなくても簡単に環境構築できます。
AstRPiではG17インデックスをすでにインストールしてありますので、よほど焦点距離の長い望遠鏡を使うのでなければそのままご使用いただけます。


Platesolvingはインデックスファイルの追加など初期段階で作業が必要ですが、非常に便利な機能です。
（使うとこれなしでは天体観望・撮影を考えられなくなるほど快適です。）

上記ご確認の上、ご自身が使用する環境に合わせて準備してください。
（AstRpiの場合、ファイルサイズが大きく扱いが面倒なAstrometry.netのインデックスファイルは共有フォルダとしてもアクセスできるため、一度インストールすれば、後はバックアップのコピーなどで簡単に構築できます。）

キーテクノロジー・Platesolving（画像による天体位置解析）

私が天体趣味を再開してから気がつけば10年以上経過していますが、観望（EAA・電視観望も含む）、撮影いずれにおいても最もキーテクノロジーになると思われる部分がタイトルのPlatesolving（画像による天体位置解析）になります。

天体導入を行う方法としてはすでにエンコーダーを利用したDigital Setting Circlesや自動導入がありますが、いずれも事前に手動でのアライメント作業が必要であり、アライメントを行ったとしても完全に正確な導入ができない（視野内に入れば良いというレベル）ことは、これらの架台をお使いの方はご存知だと思います。

Platesolving（画像による天体位置解析）が使用できる環境を整えれば、撮影した場所の位置解析が正確に行われますので、どのような天体でも正確に捉えることが容易になります。
煩わしいアライメント作業を軽減することもできますし、より正確なアライメントを行うための補助としても活用できます。

EAA（電視観望）においては、Platesolvingの有無で観望の快適性が全く異なるほど大きな役割を果たします。

使える環境を整えることが出来れば撮影や観望の効率が大幅に向上します。
まだ使用したことが無い方は是非お試しいただきたい機能なのでそれぞれの環境での構築のポイントを記載します。

●Windowsの場合
無料も含め、環境構築の選択肢が最も多くあります。
しかし、Platesolvingの解析エンジンとなる部分は実はそれほど多くありません。

WindowsでPlatesolving環境を構築するにあたって最も重要になるのはマウントのドライバになります。


組み合わせの種類は非常に多いのですが、大きく分けると2方向になります。

1.Platesolving、架台制御、オートフォーカスなど天体機器の制御をフルセットで対応する環境（独自ドライバ）

2.Platesolving、マウント制御、オートフォーカスなど個別に対応したソフトを連動する環境（ASCOMドライバを使用）

1に関してはインストールしてすぐに使用できる環境は私が知る限りアストロアーツ社が販売するステラショットのみです。The SkyXなどは幾つかのアドオンを追加すれば使用できます。
この方法はPlatesolvingの解析エンジン、機器のドライバ共ソフトオリジナルのものを使用するのが特徴です。
そのため、最も簡単に環境構築が可能になります。

2に関しては多数のPlatesolvingエンジンを選択（PlateSolve2、ASTAP、Astrometry.netなど）できますが、マウント制御、フォーカス制御、カメラ制御など個別のアプリを連動しながら使用できる環境を整える必要があります。
幾つかののカメラ制御アプリはフォーカスやマウントを連動して制御できますが、それらの制御のためにはASCOMと呼ばれるミドルウェアドライバが必要になります。

そのため、Platesolvingを快適に使用するにはお使いの機器のASCOMドライバの対応状況に左右されることになります。
特にマウントドライバが以下の機能に対応しているか否かで使用の可否が決定するほど影響があります。
・マルチクライアント対応（ドライバ自体が複数のアプリでドライバを共用できるようになっているもの）
・POTH対応（ASCOM独自のドライバ共有機能）

ASCOMは多数の機器を制御できる非常に便利なミドルウェアですが、制約事項も多数あります。
このあたりに関してはかなり情報量が多いので後日記載します。

Windowsに関してはお使いの機器が対応していればアストロアーツ社のステラショットを使用するのが最も簡単です。
独自に環境を整えるとなると実はもっとも大変な作業が必要になる環境です。（ASCOMドライバの制約事項、Platesolvingエンジンの選択、制御アプリの選択など）

個人的におすすめなのはPlatesolvingエンジンにASTAP、天体機器のコントロールにNINA or APT or CCDCielを使用する方法です。制御ソフトは一部のカメラのネイティブドライバを持ち高機能なNINA or APT、SKYChartとの連携に優れ使い勝手の良いCCDCielとそれぞれ特長があります。好みで選択しましょう。
プラネタリウムソフトとも連携を取るとなるとマウンドドライバがASCOMのPOTH、もしくはマルチクライアントに対応している必要があります。


●Macの場合
環境構築は非常にシンプルです。
Platesolvingを使用できる環境はINDIサーバ・ドライバを使用するか、INDIGOサーバ・ドライバを使用するかのいずれかになります。

INDIサーバ・ドライバを使用する場合はKStarsをアプリケーションフォルダにコピーすれば、後はインデックスファイルをダウンロードするだけで全ての環境が揃います。（Astrometry.net＋SExtractor）
ASTAPとASTAP用のインデックスファイルを追加すればASTAPのPlatesolvingエンジンも使用できます。

INDIGOサーバ・ドライバを使用する場合はCloudMakers社のサイト、アップルストアから必要なアプリをダウンロード後、インデックスファイルを追加すれば使用できます。
最低限必要になるものはINDIGO Server（無料）、Astrometry（無料）、AstroImagerまたはAstroDSLR（いずれも有料）になります。
Platesolvingとして使用できるエンジンはAstrometry.netのみです。


●Linuxの場合（シングルボードコンピューター含む
こちらもMac同様INDIサーバ・ドライバまたはINDIGOサーバ・ドライバの2択になります。
しかしINDIGOサーバ・ドライバに関してはクライアントアプリがありませんので実質的にINDIサーバ・ドライバ一択になります。
使用できるPlatesolvingエンジンもMacに準じます。（Astrometry.net、ASTAP、SExtractor）

Macと大きく異る部分は環境構築に手間がかかることです。（リポジトリの登録やサーバ・ドライバのインストールなど）
Linuxになれた方であればそれほど苦痛な作業ではありませんが、慣れない方にとってはLinuxの理解も必要になります。

Linuxの場合はシステム自体が軽量なのでシングルボードコンピューターなどに必要な環境をインストールして使用することも可能です。
当ブログでラズパイ用のディストリビューションも配布していますので、興味ある方はお試しください。

商品としては、ZWO社のASIAir　Pto はINDIサーバ・ドライバにスマートフォンのオリジナルフロントエンドを追加して簡単に使えるようにセットアップされています。

最も手軽にPlatesolvingを体験できるのはフルセットで商品として販売されているステラショットかASIAir Proです。

次点でMacにINDIまたはINDIGO環境をインストールでしょうか。

独自に環境を構築するとなるとひと手間必要になりますが、それだけの価値は充分にある機能です。
Platesolvingを体験したことが無い方は是非上記を参考にしてご自身が使いやすい環境を構築してみてください。

PlateSolving（画像による天体位置分析機能）の謎に迫る Windows編ーその1

昨日久々にWindows、SharpCapを使ってPlateSolvingの結果が芳しくなかったので、ちょっと考察してみることにしました。
普段はラズパイ4でEkosを使用していますが、こちらに関してはラズパイ3で環境を作った頃から安定していたので、昨日使用したWindows環境との相違点を洗い出します。（カメラ、レンズ、マウンドは同じです）

●Windows、SharpCapでのPlateSolving環境
使用したSolver
・AllSkyPlateSolver（Astrometry.netラッパー、32ビット（シングルスレッド）、インデックスファイルは画角計算で算出されたもの（4207～4212））
・ASTAP（オリジナル解析、インデックスファイルはG18（長焦点対応インデックス）、64ビット）

解析に使用した画像
・SharpCapのカラー画像（RGB24ビットモード、カラー、BIN２）、おそらくFITインデックスなし、2秒露出

マウントの位置情報はASCOMデバイスHubにてSharpCap、CielSkaycharts、AllSkyPlateSolver連携済み

●ラズパイ4、KStar、EkosでのPlateSolving環境
使用したSolver
・Ekos内蔵Solver（Stella Solver（Sextractorでの明度解析→Astrometry.netでの位置解析（マルチスレッド））、インデックスファイルは4219～4202、オプションのTycho2（4119～4107）も全てインストール
※上記の他、Astrometry.netローカルサーバ（インデックスファイルは上記同様）、ASTAPを使用可能（G17をインストール）

解析に使用した画像
・Ekosのアライメントウインドウで設定した画像（モノクロ、BIN２、ダウンサンプル2）、FITインデックスあり、2秒露出
※INDIのCCDドライバは撮像画像を自動でマウント位置情報を付加したFITSファイルに変換している

解析範囲はどちらも直径30度にしてあります。
今までに色々使ってきましたので、大分解析グセがつきました。（苦笑）

実はAstrometry.netのローカルサーバはシングルスレッドでしか解析してくれません。
Ekosに関しては最近独自に星を検出するためにSextractorを使用し、Astrometry.netサーバをマルチスレッドで計算できるStellaSolverが組み込まれました。
これが功を奏して解析速度が半分くらいに速くなりました。

しかし、このシステムが無く、ローカルAstrometry.netサーバを使用して非力なラズパイ3を使っていたときでもほとんど失敗なしで8秒位で解析してくれていました。
Linux環境に乗り換えて疑問に感じたのはEkosとCCDCielを併用して使用したとき、明らかにEkosの方が解析の失敗が少ないということです。
CCDCielはStellaSolverが出来る前のEkosの環境（ローカルAstrometry.netとASTAP）と同じですが、CCDCielを使用してPlateSolvingすると解析が失敗することが非常に増えます。

使っているドライバや解析設定は同じなので、CCDCielとEkosの違いは解析する画像の処理にあるのではないかと感じています。

実際EkosでEAAを行っている記事を再確認すると、アライメントWindowに表示される画像は非常にノイジーですが、コントラストが高く、かなり星が多く写っています。

このことから、EkosのアライメントWindowで解析用に撮影される画像はドライバ設定を自動的に変更してかなりゲインアップしているのではないかと考えられます。

Astrometry.neｔ（StellaSolverも同様）は多少ノイジーであっても、画像が軽く星が多く検出出来る画像の方が解析の成功率が高くなるのではないかと推測します。
更に使っているうちに気づいたのは、オプションのTycho2インデックスを追加したほうが解析の成功率が高くなったということです。
あくまでも推測ですが、Astrometry.netのインデックスファイルは領域によって精度にばらつきがあるのかもしれません。
オプションのTycho2インデックスを追加することで、時間はかかっても精度不足を補えるのではないかと考察できます。

Ekosでもこの設定でASTAPを使用すると成功率が低くなります。
ASTAPの成功率が上がるのはある程度の画素数、露出時間をかけた品質の良い画像になります。
品質の良い画像を用意すると大分成功率が高くなりますが、それでもAstrometry.netよりは成功率は劣ります。


ここまで検証したところでWindowsのシステムと照らし合わせてみましょう。

Windowsは残念ながらネイティブのAstrometry.netサーバがありません。
Astrometry.netでの解析はエミュレーションで行っています。（AllSkyPlateSolverもAstrometry.netラッパーの一つです。）
しかし、Windowsが動作するマシンの方が圧倒的に処理速度が速いのでエミュレーションでの動作の遅さは相殺できると考えます。
ASTAPに関してはネイティブに対応しているのでLinux環境と同じです。（処理速度が速いためラズパイより圧倒的に速くなるはず）

ではなぜ昨日SharpCapからの解析が失敗ばかりだったのでしょうか。
上記から考察するに一番大きな原因は処理をするための画像にあると考えられます。

Linuxでの検証を基にすればPlateSolvingで解析するときはSharpCapの画像を以下のように変更すると成功率が高くなる可能性が高くなります。

●AllSkyPlateSolverで解析する場合
・カラー→モノクロに変更
・Bin2
・FX項目のブーストをオン
・有料版を使用している場合は稲妻マークをオン
・ゲインは高め
・ラズパイ同様4219～4213のインデックスも追加、Type2も含めインデックスファイルを手動で入れる（ラズパイからコピー）

SharpCapにはダウンサンプルは無かったと思いますので画像を縮小することはできませんが、ノイジーでもとにかくモニターで多数の星が見える状態に調整したほうが解析の成功率が高まる可能性が高くなると思います。
AllSkyPlateSolverは焦点距離や撮像素子のピクセル数から自動的にインストールするインデックスを計算してくれますが、実はこれが解析を失敗させる原因の一つになっているのではないかと推測できます。

インデックスファイル自体はWindowsもLinuxも同じなので、ラズパイ同様かなり画角の広いインデックスファイルからオプションのTycho2インデックスまでぶち込んでおいたほうが解析の成功率が高くなる可能性があります。
ここで、問題になるのがAllSkyPlateSolverがオプションのTycho2インデックスを読み込んで解析に使用してくれるのか、ということです。使用してくれれば確実に成功率が高くなると思いますが、読み込まない場合はそれなりでしょう。。。

●ASTAPで解析する場合
・カラー→モノクロに変更
・Binは使用しない（画素数の多いカメラの場合は2）
・FX項目のブーストをオン
・有料版を使用している場合は稲妻マークをオン
・ゲインは若干高め
・露出を長めに（4～8秒）

ASTAPの場合短編が1000ピクセル以下になると解析の成功率が下がってしまうようです。
Astrometry.netと比較してかなり画像の質を上げないと成功しづらくなります。
ゲインはノイジーにならない程度に留め、その代わり露出を長くして認識される星の数を増やします。
Linuxでの経験則ではAstrometry.netよりは若干解析速度は速いですが、解析の成功率は低めです。

Windowsを使用していて気になったのはAllSkyPlateSolverの処理の遅さと解析成功率の低さです。
ラッパーなのでネイティブのサーバよりは処理速度が落ちるとしても明らかに速度が遅すぎます。。（Astrometry.netは設定が決まれば結構高速です。）
ネイティブのAstrometry.netサーバ同様オプション設定などをテキスト記述出来る場所（Configファイル）が見つかればコピペで変更できるかもしれませんが、独自仕様の場合はお手上げです。（ダウンサンプルとか。。この辺ご存知の方いらっしゃいますか？）

もし、設定などが固定されてしまって変更できない場合はWindowsの場合はASTAP使用したほうが良いかもしれません。
（アストロアーツのステラショットとか処理速度や成功率どうなんでしょうね？）

追伸
ラズパイからインデックスファイルをコピーしたところ無事Tycho2ファイルも含め認識されました。
しかしダウンサンプルほか様々なオブション項目を記述する設定ファイルが見つかりません。

Linuxで使用していたときにもオプションの記述により成功率が変化しましたのでこの部分が調整できるといいのですが。。

PlateSolving（画像による天体位置分析機能）の謎に迫る Windows編ーその2

前回WindowsのPlateSolving環境について考察しましたが、非常にざっくり分けるとAstrometry.netサーバ機能を使用するものと、独自エンジンを使用するものに分けられるようです。

今回はAstrometry.netサーバ機能を使用するものに焦点を当ててみます。
尚、Astrometry.netサーバ自体はUNIXのサーバ環境になりますので、Windowsで使用する場合は何かしらのエミュレーションで動作させることになります。

All Sky Plate Solver
AnSvr
Astro Tortilla

ざっと調べてみたところこの3つがAstrometry.netサーバのエミュレータとしてWindowsで利用できるようです。

私はAllSkyPlateSolverをインストールしましたが、どうやらこのアプリはサーバ部分をプログラムでエミュレーションしているようなので、Linux環境を丸ごとエミュレーションしてAstrometry.net環境をインストールして使用するAstrotortillaもインストールして比較してみました。（Ansvrも同様の環境です。）

上記の通り、同じエミュレーターでも方向性が異なります。
AllSkyPlateSolverはおそらくサーバをアプリでエミュレーション、AstrotortillaとAnsvrはcygwinというLinuxエミュレーターを丸ごとインストールし、Astrometry.netサーバを組み込み、アプリでサーバをブラウジングして使用する構造のようです。

と、いうことはAstrotortillaとAnsvrはまんまLinuxのAstrometry.net環境です。アプリはそのブラウザーでしかありません。
Astrometry.net環境は以下に格納されています。

本体
C:\cygwin\usr\include
設定ファイル
C:\cygwin\etc\astrometry\bin\solve-field
インデックスファイル
C:\cygwin\usr\share\astrometry\data

cygwin自体の動作状況、Astrometry.netの動作状況などはインストール時に組み込まれたターミナルで確認できます。（デフォルトではデスクトップにショートカットが作成されます。）
configの名称などは本家と異なりますが、Cドライブ直下に出来るcygwinというフォルダがエミュレーション用のシステムフォルダなので、Linuxをお使いの方は理解しやすいかと思います。


それに対してAllSkyPlateSolverは以下のようになります。
サーバのエミュレーター＝アプリ本体
設定ファイル
C:\Users\ユーザー名\AppData\Local\Astrometry\bin\solve-field
インデックスファイル
C:\Users\ユーザー名\AppData\Local\Astrometry\usr\share\astrometry\data

本家と大分構造が異なります。。。
しかも鬱陶しいことにAppDataというフォルダが隠しフォルダになっていますのでそのままではアクセスできません。（エクスプローラーで隠しファイルを表示する設定にしてください。）

サーバの動作などはアプリ自体がエミュレータなのでわかりやすいですが、インデックスや設定ファイルの場所がかなり特殊です。
インデックスファイル自体は上記3つのアプリとも同じものですが、インストールされる場所がAllSkyPlateSolverだけ異なるのでインデックスが格納されているdataフォルダをどちらかシンボリックリンクにして節約しましょう。

私はcygwin環境を後にいれたのでC:\cygwin\usr\share\astrometry\dataのdataフォルダをdata-oldに変更し、C:\Users\ユーザー名\AppData\Local\Astrometry\usr\share\astrometry\dataのdataフォルダのシンボリックリンクを作りました。



こんな感じです。

これでAllSkyPlateSolverもAstrotortillaも同じインデックスを使って操作できるようになります。

ちなみにインデックスファイルはLinuxもMacも共通ですので、他のOSでAstrometry.netを使用している方はインデックスファイルをコピーして使用できます。

Windowsでシンボリックリンクを簡単に作成するためにはこれを利用します。

WindowsとUnixという高い国境（笑）を乗り越えて環境を作ってくれた作者の方には感謝しかありませんね。

WindowsだとINDIサーバ・ドライバのようにシミュレーションドライバで動作確認ができないので変更した設定の動作確認はできませんが、おそらくLinux同様のオプション設定が出来るAstrotortillaを使用すればそこそこ快適にPlateSolvingが動作してくれると思います。（Ansvrも同じ、cygwinが動作しないと使えないという煩わしさはありますが。。）

あとはWindowsの場合はASCOM、プラネタリウムアプリ、CCD撮像アプリなど連携するアプリが多くなりますのでそれぞれのアプリで緯度経度日時、座標系（J2000orJNow）などを揃えておくことでしょうか。

設定などはあらかた終わったので、後はエミュレーションの精度に期待ですね。（うまくいかない原因がエミュレーション自体の出来という落ちは勘弁してほしいところです。。）

追伸
SharpCapで確認してみたところ、ASPSとAstrotortillaを両方インストールすると自動的にcygwinにインストールされたAstrometry.netを使用するように変更されます。
と、いうことはPlateSolvingの設定などはAstrotortillaで行わないと反映されないのではないかと思います。（おいおい。。）
インデックスファイルも上記のように両方使えるようにしておかないとトラブルが起きますね。
（Astrotortillaでインストールする際、インストールされるインデックスファイルは少なかったように記憶しています）

SharpCapはライブスタッキング機能は本当に魅力的ですが、PlateSolvingやASCOMとの連携機能は難ありですね。。

更に追記
AstrotortillaをインストールするとSharpCapではAstrometry.netのPlateSolvingが使用できなくなるようです。
詳細はこちら

PlateSolving（画像による天体位置分析機能）の謎に迫る Windows編ー備忘録

先週あたりからWindows で環境を再構築し、いろいろ試していましたがある程度状況がつかめてきたので備忘録としてまとめます。
特にPlateSolvingに関しは私にとっては必須なのでそこをメインに調べました。

私の環境ではという前提がありますが、いくつか確認できたことを列記しておきます。

●SharpCapに関して
・Solverとして認識するのはAllSkyPlateSolverとASTAPのみ（AnsvrやAstroTortillaはNG）詳細は別記→Ansvrも認識されました。
・Solverに使用する画像がPNGに固定されてしまい、解析出来ない。（外部アプリでJpegに書き出しが必要）
・PlateSolve2は使えない（実質ASAPとASTAPの二択だがいずれもアプリの操作では解析しない、外部アプリを使用してFITSやJPEGに書き出す必要がある）
・Astrometry.netを使用するSolverはAstroTortillaをインストールすると使用できなくなる。（Astrometry.net環境が複数あるとCygwin内部のAstrometry.netが優先されてしまい、設定変更を受け付けなくなる。Cygwin内部にインストールされるAstrometry.netサーバはAstroTortilla用で、そのサーバは動作していないため全て使えなくなる）
原因はコチラ

●N.I.N.Aに関して
・Ansvrはローカルソルバー項目では無く、nova.astrometory.netのアドレスを127.0.0.1：8080などに打ち替えれば使用できる可能性がある。（未検証、ローカルソルバーの設定項目ではNG）
・ローカルソルバー項目でで使用できるローカルAstrometry.netサーバは実質AllSkyPlateSolverのみ（Ansvrは登録自体ができないし、AstroTortillaはサーバか稼働していない）
・ASTAPは接続可能（未検証）

●APTに関して
・接続方式がアプリ呼び出しなので記載してあるAllSkyPlateSolver、PlateSolve2、ASTAPの三択（AnsvrやAstroTortillaは構造上無理）

●WindowsローカルのAstrometry.netサーバに関して
・AllSkyPlateSolverはアプリでサーバ機能をシミュレーション（だと思う）、Ansvr、AstroTortillaはLinux仮想環境のCygWinにAstrometry.netサーバをインストールして使用するが、両者ともインストールされるAstrometry.netサーバは別（設定ファイルやインデックスファイルの保存位置がバラバラ）
・AstroTortillaはインストールすると、フロントエンドのアプリ、Cygwinは動作するが、肝心のAstrometry.netサーバが動作しない。（よって使えない）、インストールするとSharpCapで他のAstrometry.netサーバを選択できなくなる。（原因は上記参照）
・AllSkyPlateSolverは単独で使用すると動作する（解析に約30秒くらい。。）が、デバイスHubで接続したマウントドライバに座標を送らない（解析ができるだけ）
・AnsvrはCygwin、Astrometry.netサーバとも動作するが、astrometory.netのサーバにアクセスするためにポート番号で設定（127.0.0.1:8080など）する必要があるため、実質私の環境ではN.I.N.Aでしか登録出来ない。（他のアプリは設定ファイルやアプリのディレクトリ登録のため）

ASCOMに関して
・私の架台（スカイエクスプローラーAT100N架台）は同社の、USBシリアル変換器、
SynScanAPP＋デバイスHubで問題なく接続可能。
・自作Moonlightフォーカサーはシリアル変換チップがシリアル変換チップがch340のため動作しない（FTDIチップが必須）
・AllSkyPlateSolverとはデバイスHubを通じて接続できるがSyncが不可能


・・・・・・なかなかのカオスっぷりです。（苦笑）
ヘッドレスリモート環境は無事できましたが、PlateSolvingがなんとも鬼門状態です。（本当に題名通りになってきました。。）
Astrometry.net勢ではAnsvrが良さそうなんですが、私が使いたいアプリがほとんど対応していません。（N.I.N.Aは接続出来る可能性があります。）

AnsvrとAstroTortillaはLinux仮想環境のCygwinにAstrometry.netサーバをそのままインストールするような形態なので、本来であればIPアドレスでアクセスするのが理にかなっていると思うのですが、そのような接続が出来るアプリがほとんどありませんね。。。
（私が所有するアプリだけでしょうか。。。謎です）

AllSkyPlateSolverは解析出来ますが、速度が遅く（速くても30秒、遅いと1分）、マウントドライバと座標をSyncしてくれません。。（これが出来ないと意味がないですね）

フォーカサーはASCOMでは使用出来ませんが、同社が開発した単独アプリに直結であれば使用できます。
4年前と異なり、マウントドライバがデバイスHubを通じて連携できたので喜んだのですが、PlateSolvingとSyncしてくれません。。。
（SharpCapだと解析もNG)

現状でもPlateSolvingさえ諦めれば使用できますが、遠隔リモートが必須の私の環境では使いづらいものになります。（寒さ我慢して普通に架台のアライメントすればいいのですが、ヘッドレスリモートだとその作業が結構面倒です。。。）

皆さんの環境ではSharpCapでスナップショットするときにFitsやJPEG使えてるんでしょうか？（これさえできればAllSkyPlateSolverが使えそうなんですが。。。まあ、マウントと同期というもう一つの関門がありますが。）

まあ、ここまで環境を作ったので、星見の環境はラズパイに戻してWindowsに関しては時間をかけて検証してみましょう。
（INDIのようにシミュレーションドライバが使えないので正直動作確認が大変です。。。。（特にPlateSolving））

追伸
SharpCapのフォーラムを確認したらやはり同様にAstrometry.netを使用するのに苦しんでいる方がいらっしゃいました。（苦笑）
内容を読むにおそらくSharpCapが自動で設定するディレクトリとconfigファイルが問題があるように感じます。
SharpCapはAllSkyPlateSolverのみがインストールされているときは問題なく動作する設定になりますが、AstroTortillaもインストールすると自動的にAstroTortillaがインストールしたｃｙｇWinの中にあるAstrometry.netサーバを読み込むように切り替わってしまい、更にはAllSkyPlateSolverに変更もできなくなってしまいます。

私はAstroTortillaとAstroTortilaがインストールするcygwinをアンインストールしました。
そうするとAllSkyPlateSolverに切り替わりました。

追記
SharpCapでAnsvrを認識させることができました。
C:\Users\ユーザー名\AppData\Local\cygwin_ansvr\usr\share\astrometry\data
というファイルを削除し、シンボリックリンクを貼り直したら認識しました。

しかし、初期設定のsolve-fieldを読み込んでいないような表示は消えません。。。
C:\Users\ユーザー名\AppData\Local\cygwin_ansvr\bin\solve-field
に切り替えても駄目（一筋縄ではいかないな。。）

ASILiveの謎とStellaSolverの謎

以前こちらの記事に記載したこの2つの謎技術でフルリモートで多段ライブスタッキングを楽しんでいます。




晴れて観望出来れば1～2時間で数十の対象を楽しめます。（似たような写真ばかりなので一枚のみで他は割愛）
最初の頃はMiniPCの環境を切り替えたりしながら観望していましたが、最近はトラブルフリーのUBUNTU側が主になってきています。

写真の画像も1秒、2秒、5秒、10秒と切り替えながら多段ライブスタッキングしていますが、星が全く流れません。（経緯台なので時間と共に画像が回転していますね。）
秒数を変えると明るさや星の数が変わりますので見ながら秒数を変えて見やすく調整するような観望をしています。

StellaSolverにしても多少の障害物があっても物ともせず、数秒（大体は2～4秒）で位置解析が終了します。

どちらも本当に謎技術ですが、このおかげで機材を設置したらアライメントも取らずすぐ家に入り観望出来ています。
当地のような寒冷地での観望は身体にこたえるので本当にありがたいことです。

しかし、昨年ズーム観望の楽しさを知ってしまったので、早く暖かくなって外でリアルタイムズーム観望も楽しみたいです。
（まだ当分かかるかな。。）

天体の位置解析、導入支援の考察

1.適当な場所に移動して高感度広角カメラでPlateSolving→現在の位置同定+画像の中心点を同期ポイントとして送信
2.現在位置を基準に広角カメラの画角で全天をマッピング+PlateSolvingのインデックスファイルでマッピングしたの全天分の基準星を設定
3.移動時に高感度広角カメラのストリーム映像で全天分の基準星を追いかけ、位置に変更があった場合は画像の中心点の座標を常に送信
4.プラネタリウムアプリで送信されてきた座標（現在地）を表示

2と3が非常に重要な部分です。（そして現状不足している部分）
要は最初にカメラの撮影画像で現在位置とその画角に合わせた全天分の基準星データベースを作ってしまい、カメラのストリーム映像をリアルタイムに解析して全天分の基準星を追いかけながら、フレームの中心になる座標を送信し続けることで現在位置情報を把握するという方法です。

広角のインデックスであれば処理も非常に軽量で済みますし、事前に全天分基準星を設定しておけば、都度PlateSolvingを行わなくても映像に写っている基準星の移動方向で現在地を計算して現在地（画像中央の座標）を送信するだけで済みます。（PlateSolving画像を基準点としてフレーム画像による追いかけ同期）
プラネタリウムアプリで送信されてきた座標情報を表示すればリアルタイムで正確な位置を視覚的にも把握出来ます。
（雲などでフレームに基準星が見えない状態になったら1からやり直し）

この程度の処理であればシングルボードコンピュータ+広角カメラでも充分実現できそうです。（シングルボードコンピュータは位置情報送信専用機にしても良いですね。）

広角カメラの映像+PlateSolvingのインデックスのみで位置解析できるのでどんな架台でも使えます。

観望ならこの装置を設置するだけで常に正確な位置情報を把握出来ます。
撮影に使用する場合は1の工程で撮影用のカメラの位置情報もPlateSolvingで取得→広角カメラの中心点とのずれを差分として計算し基準点にしておけば撮影用のカメラに正確に対象を導入できますね。
導入が済んだら広角カメラの画角を変更してガイドカメラにしてしまえると便利そうです。（ガイド時はフレームからの位置情報を自動送信するのを自動的に停止し、その代わりガイド用の補正信号を送る）

この方法なら手動架台でもでも自動導入架台でも使えますね。
自動導入架台なら指定した対象に移動した際、ズレがある場合は最後のフレームで目標天体とのズレを計算しズレ分補正移動すれば正確に導入できます。（赤道儀の場合は極軸調整も楽になります。）
PlateSolvingのシステムやプラネタリウムアプリはすでにあるので、上記解析部分のみ開発できれば実現できそうです。
実現したら非常に便利そうですが私はプログラミングが出来ないのでお手上げです。。。

誰かこの解析システム作ってくれないかな。。。

前回記事の導入支援構想を超簡単（原始的）に実現する方法

前回の記事でPlateSolvingで位置同定した後、映像で位置同定した座標の移動を追いかけるアイデアを記載しましたが残念ながら現状この構想を実現するドライバがありません。。。

原理自体はとても単純なのでPlateSolvingが可能な環境さえあればファインダーを広角レンズを取り付けた天体カメラ（またはCマウントカメラ）に変更すればどのような機材でも簡単な手順でかなり正確に対象導入が可能になりますのでご紹介します。

事前準備
1.プラネタリウムアプリでPlateSolvingに使用するカメラの視野角を表示できるようにしておく
2.広角レンズを取り付けた天体カメラ（またはCマウントカメラ）をファインダーと交換し、ファインダー同様主鏡の中心点と合わせておく
3.PlateSolvingを行った際、プラネタリウムアプリに同期点（写野枠）が表示されるようにしておく

経緯台の場合は準備はこれだけです。
赤道儀で使用したい場合は画像が回転して見づらいので、プラネタリウムアプリの動きを赤道儀に合わせる設定にしておきましょう。（どのアプリでも可能です。この設定にしておけば設定したカメラの視野角が赤道に合わせて回転しますので映像が確認しやすくなります。）


導入の操作手順
1.プラネタリウムアプリを見ながら導入したい目標天体の位置に大雑把に鏡筒を向ける
2.PlateSolvingを実行（プラネタリウムアプリにカメラの現在地の視野角が表示される）
3.目標天体が中心になるようにプラネタリウムアプリの表示を移動させる（その際、PlateSolvingの視野枠とカメラの視野枠が両方見える拡大率にしておく）
4.カメラの視野枠（目標天体が中心にある状態）で見える状態とカメラの映像が同じ状態になるように鏡筒を動かす。（この際PlateSolvingの視野枠、ズレて表示されているカメラの視野枠両方で、基準となるような見やすい星を設定しておくと移動が楽）
5.導入完了

広角のカメラでPlateSolvingすれば、大雑把に目標天体方向に移動したとしてもまずPlateSolvingの視野枠とカメラの視野枠で重なる部分を作ることが出来ます。
それぞれの視野枠で見やすそうな星を基準にして映像を見ながら鏡筒を移動して、映像がプラネタリウムアプリのカメラの視野枠と同じ星の配列に見えれば導入できてしまいます。

上記の手順を絵にすると下図のようになります。



白枠がPlateSolving時のカメラの視野枠（中心の緑の円が鏡筒の位置）になります。
白枠内に月やディプタが見えますのでこれを移動の際の基準星にします。（黄枠部分）

青枠でくくったNGC253が目標対象なので、NGC253が中心になるようにプラネタリウムアプリの表示を移動します。
そうするとPlateSolvingの視野枠（白枠）とカメラの視野枠（赤枠）がズレて表示されます。（このズレ分が鏡筒の移動距離になります。）

赤枠内で表示されている星の状態とカメラの映像が同じように見えるように鏡筒を移動します。
ディプタが右上、赤枠左下の黄枠にある3つ星が赤枠と同じように見えるように動かせば導入終了です。
（この図の場合は緑の矢印方向に移動します。）

前回の記事で考えた構想はPlateSolving時の中心座標を起点としてインデックスファイルから全天分の基準星を設定して、鏡筒が移動した場合、基準星を追いかけ続け中心座標の変化をプラネタリウムに送信し続ける（映像で基準星を追尾することで緑枠部分をリアルタイムに動かしエンコーダー代わりにする）というものでしたが、それが実現できるドライバなどが存在しません。（実現できるドライバができればどんな機材でも加工なしで常に現在の鏡筒位置が確認できるのでありがたいのですが。。。）

上記の方法であれば、非常に簡単にその原理をつかって天体導入が可能になります。
手動導入機器などでもPlateSolving用のカメラさえ取り付けることができれば正確な導入が可能です。

興味ある方はお試しください。

追伸
もっとシンプルなアイデアとしてはこの記事で紹介したCマウントZOOMレンズ+Cマウント高感度カメラ（撮像素子が同サイズ程度の天体カメラでも良いです。）をファインダーとして利用する方法になります。
幅広い視野角+正立像+（人間の目より）高感度+プラネタリウムアプリの組み合わせはEAA（電視観望）のみならず導入支援としても絶大な効果があります。

広角でも望遠でも対象が見えていれば（しかも正立像で）導入は非常に簡単になります。
ZOOMすることでより正確に対象を導入できます。
もちろん今回紹介した導入方法と併用も出来ますが、それが不要なほど多くの対象を確実に確認できます。
撮影するのであればガイドカメラにも出来ますし、CマウントZOOMレンズ+Cマウント高感度カメラで観望も楽しめますよ。
多用途に使用できますので興味ある方はお試しください。

PlateSolving+ライブスタッキング専用機

以前の記事でPlateSolvingを利用するDSCのアイデアを記載しました。

ネットを検索すると同じようなことを考える人はいるようです。
https://www.cloudynights.com/topic/773229-digital-finder-scope-diy-from-camera-pcb-to-web-interface/

リンク記事を読むとラズパイとカメラユニットを使用してPlateSolvingを利用したDSC+ライブスタッキング専用機を考案している方がいらっしゃいました。

今回の記事のようなPlateSolvingの座標を利用してDSCのように利用できる環境はほとんどありません。
（セレストロンのStarSense Explorerはスマホのセンサーを利用して擬似的に似たような操作が可能です）

プラネタリウムアプリ+PlateSolving環境の併用のみ（撮影場所の確定）であれば、ラズパイ+KStars・Ekosでも可能ですが、INDIドライバの設定などかなり複雑な操作を覚える必要があります。（PlateSolvingの速度は非常に快適ですが、慣れない方にとってはドライバの設定などで苦しむことになるかと思います。）

Windows環境ではアストロアーツのステラショットかTheSkyX+エクステンションがKStarsと同様の環境になりますが、いずれも有料です。（PlateSolvingの速度などは不明）
無料のAscomベースの場合、PlateSolving、プラネタリウムアプリ、キャプチャーアプリの3要素の連携を強いられることになるので、正常に動作する環境が限られてきます。。。（Pothが不具合なく安定して動くかにかかってきます）

PlateSolvingを利用したDSCが専用機として気軽に使える状況が出来れば、架台を選ばず使用することが可能になります。
更にライブスタッキングも可能であればEAAではすばらしいソリューションになるのではないかと感じています。

すでに大分プロジェクトが進んでいるようなので楽しみです。（購入するかも）

PlateSolvingの高速化

アップデートでマウントドライバの追尾がおかしくなってしまいEAA環境をWindowsに移行しました。

一通り安定して動作していますが、どうしても不満が残るのがPlateSolvingの遅さです。

ASTAPだとそこそこ速いのですが、こちらは解析が失敗することが多く、反対にAstrometry.netは解析の失敗はありませんが非常に遅いです。。。。

INDI環境で使用しているStellarSolverの快適さに慣れきってしまっていたので、使用していてストレスが溜まります。。。

幸いなことにCCDCielを利用するとLinuxやMac同様Astrometry.netのオプション設定が可能ですし、ASTAPとの切り替えも容易です。

Astrometry.netは解析が速くなるように、ASTAPは解析の失敗を減らすように調整します。（ちなみにここで行う調整はLinuxやMacでも有効です。）



まずはAstrometry.netからです。

Astrometry.netは
・解析画像が小さい方が速い（かなり小さくても問題ない）
・Tycho2インデックスファイルを追加すると解析の失敗が減る（41○○番のインデックスを追加（これは既に実施済み）
・無駄な解析処理を減らすと速くなる
・ノイズに強い

という特徴がありますので、設定で最適化します。

上図の赤枠部分を変更します。

上から検索範囲
デフォルト30→20へ（検索範囲を狭める、15でも良い）

ダウンサンプル
可能な限り小さな画像に→私は4にしました。

オプション設定
デフォルトは
--no-fits2fits（fitsファイルのヘッダの不具合を治す）
だけでしたが、以下のように修正します。

--no-fits2fits --scale-units degwidth --scale-low 1 --scale-high 2 --guess-scale --no-plots --no-verify --no-remove-lines --uniformize 0

--scale-units degwidth --scale-low 1 --scale-high 2→で撮影画像の横幅を定義します。
--guess-scale→これも同様に画像サイズの取得です。（Fitsヘッダから読み取り）
--no-plots --no-verify→プロットしない、ベリファイしない
--no-remove-lines --uniformize 0→座標テーブルから線を削除しない、星の抽出をしない

画像サイズの定義が結構劇的に効きます。私の場合自分の環境の画角に合わせて--scale-low 1 --scale-high 2（横幅1～2°）にしましたが、この数字は環境に合わせて書き換えてください。
ここで画像の大きさを大まかに指定し、--guess-scaleでFitsヘッダから画像サイズを取得と二段階に画像サイズを定義することで取りこぼしなく画像サイズに合わせた処理を行うようになります。

--no-remove-lines --uniformize 0はnekomesiさんが検証していましたのでありがたく知識を流用させていただきました。（ありがとうございました）


次はASTAPの設定

こちらの特徴は
・そこそこ速い
・解析に使用する画像にシビア（大きすぎても小さすぎてもダメ、ノイズも少なくないとダメ）

Windowsの場合、Astrometry.netと比較すると速いですが、解析の失敗が多いです。。。
そのため、解析の失敗を減らす方向で調整します。

まずはCCDCielから



Astrometry.net同様解析範囲を狭めます。
デフォルト30→20

ダウンサンプルは私のカメラがASI224なので行いません。（減らすと解析が失敗する）

最後に"Advanced Setting"ボタンでASTAP側で設定




・解析の最小角をAUTOに変更（デフォルトは1）
・解析の最大角を180に変更（この設定でブラインドSolverも可能になる）
・インデックスファイルの読み込みをAUTOに変更（これで複数インデックスファイルを解析する）

私はEAAで焦点距離が短いため、インデックスファイルはG05、W08、V50の3つを入れてあります。
インデックスファイルに関しては使用する画角の最小限と記載するサイトが多いですが、可能な限り複数の選択肢を持たせたほうが解析の失敗が減ります。（ASPSで解析の失敗が多いのはこのため）

上記設定の結果ですが、Astrometry.netは解析速度が4～5倍（ブラインドSolverで1～2分かかっていたものが2～30秒に）、ASTAPは解析の成功率が2割程度→9割程度に増加しました。

Astrometry.netはWindowsではエミュレーション環境なので、どうしても本家のLinuxやMacに比べると遅くなりますが、ブラインドSolverでこれだけの速度がでればマウント座標を取得する状況であればおそらく10秒以内で解析してくれると思います。（多分もっと速そう、ASTAPと比較してもそれほど見劣りしません。。。というか下手したらASTAPより速いかも）
ASTAPもかなり解析の失敗が減りましたので、通常はこちらをメインにして解析が出来ない対象はAstrometry.netを使用してもそれほどストレス無く使用できそうです。

CCDCielを使えば解析後のマウントへの同期なども安定して行なえますのでようやくこれで不満部分は消し込めたと思います。

Solverの不調でお悩みの方はお試しください。


追記
なんとCCDCielとSharpCapでカメラのドライバを接続したまま利用できます。
今までSharpCapは広角のファインダー映像確認に使用していましたが、CCDCielでSolver→同期後、CCDCiel側のループを止めればSharpCapでそのままスタッキングが可能です。

EAA環境はSolverも速くなったので、もうこれでいいかも

ちなみにMacやLinux系はAstrometry.netに関してはINDIが入っていれば上記対策しなくてもバリバリにオプション設定がされていたので不要でした。（逆にデフォルト状態じゃないとエラーが出る）