のんびり天体趣味

 またしても綺麗に晴れたので、撮影が捗ります。 M8とM20 少し前に工作してAZ-GTiにカメラを載せられるようにしたので、SEL55210で撮影してみました。 早速リザルトです。 機材：SEL55210(焦点距離210mm), ZV-E10未改造, QBP, AZ-GTi経緯台モード 条件：ISO1250, 30s露光×245枚 処理：トリミング、SPCC、AI デノイズ&デコンボリューション ダブルズームキットのレンズとカメラ（未改造）、かつ光害地のベランダ撮影 でここまで写れば文句はないです。 望遠鏡を買わなくてもここまで写せる のは少々驚きました。 エントリークラスの機種でもダブルズームキットを持ってる人なら経緯台とQBPフィルターを買うだけで星雲が写せる！ 周囲に光害が少なければQBPすら不要ですし。 天体撮影って思ってたより ハードルが低かった 。 望遠鏡が必須という思い込みがありましたが、むしろ経緯台さえあれば何とかなる事が分かりました。 ちなみに、QBPを使っているので三裂星雲の青色が苦しいと思っていましたが、ギリギリ何とか写りました。ぼんやりしていて青色と言えるレベルでは無いですが笑 また、エントリークラスの未改造カメラでこのレベルですから、天体用カメラを買うとどこまで綺麗になるのか楽しみです。 ただ、三裂星雲の右上に違和感があるので調べてみたところ、円形のゴースト(？)が出てしまいました。 スタックしただけの画像を思いっきり強調しています。 レンズの先にQBPフィルターを取り付けたので、レンズとフィルターが近すぎたせいかな？と妄想しています。 解決策が無いか、のんびり考えたいと思います。 これを撮影していて、200mm前後の鏡筒がたくさん出ている理由がちょっと分かりました。 複数の星雲が１枚に写るのってすごく良い。 やっぱりいろんな焦点距離の鏡筒が欲しくなってしまうんですね… 天文が 沼 と呼ばれる理由もホントによく分かりました。 pythonスクリプト 撮影ではない方のネタに移ります。 ここ最近は、あぷらなーとさん考案の処理法をSirilに実装しようと頑張っています。 前回悩んでいたseqcosme（cosmeのループ処理）を使用する方法からは一旦離れて、別の方法をとりました。 これでピクセルマッピングとクールファイル補正...

  土曜の夜、風呂に入る前に外を見ると完全に曇っていて、撮影を諦めました。 が、風呂から上がってしばらくして、ふと空を見ると綺麗に晴れてる！ という事で急遽撮影しました。 狙いは前回ゴミで酷いことになったM16です。 早速リザルトです。 機材：SE102, ZV-E10未改造, QBP, AZ-GTi経緯台モード 条件：ISO1250, 30s露光×179枚 処理：トリミング、SPCC、AI デノイズ&デコンボリューションあり 処理ですが、GraXpert の deconvolution（stellar）は使っていません。 というのも、stellar で処理すると画像の外周ばかりが強烈に補正されてしまいます。 M17の時も悩みましたが、今回は避けようがないくらいに酷かったので採用出来ませんでした。 どうすれば外周だけでなく全体的に補正がかかるのか… 何か良い条件が無いか探ってみたいと思います。 GraXpertの不具合なら逆にありがたいくらい。 また、以前効果が無いと言った deconvolution の object ですが、めっちゃ効果ありました。 創造の柱がクッキリしました。 左がdeconolution(object)なし、右がありです。 意味無いと言ってスイマセン…これからはobjectも使います。 ただ、以前の検討だとこんなに分かりやすい変化は無かったので、何か違いがあるんでしょうね。 ちなみに、objectでも strength を上げすぎるとアーティファクトが出ます。 何事もやりすぎは良くないです。 下は strength = 0.8まで上げたら出てきました。 続いて、前回の最後にちょろっと書いたクールファイル補正法のpythonスクリプトです。 引き続き検討を進めています。 この記事を書いた後、あぷらなーとさんのXの投稿で「星ナビ８月号に ノイズまみれの画像が付いてくる 」 と知る事ができたので、急いで購入して検証を始めてみました。 ノイズまみれの画像が手に入ると分かった瞬間に 猛烈に喜んで しまいました。 で、画像をダウンロードして圧倒的なノイズを見たら、 更に喜んでしまいました ｗ ノイズに喜んでしまうあたり、いい感じにイカれてきた気がしています。 が、やはり実装は思うようにいきません。 ピクセルマッピングを適用した画像にクール...

 天体撮影をする時に、天気予報が信用しにくいです。 普通の天気予報の「晴れ」は全く当てにならなくて、いつもwindyと睨めっこしています。 これを何とか指標化出来ないかなともがいてみます。 しかも、PCではなくandroidアプリで。 結論を最初に言うとアプリは出来上がりましたが使い物になっていません。 windy は API を提供しているので、ひとまずアカウント登録します。 point forcastのAPI キーを取得しました。 取得できるデータを 確認 し、計算式を考えて、計算アプリを作ってみます（もちろんコーディングは全部Gemini任せ）。 言語はpythonです。 早速、現段階の状況です。 見た目はともかく、私の端末（pixel6a）では狙い通り動いてます。 算出ロジックは下の通り。 総合スコア 総合スコア = (雲スコア * 0.75) + (シーイングスコア * 0.1) + (湿度スコア * 0.05) + (風スコア * 0.1) この計算式は、tomが何となく決めた式です。 何か根拠があるわけではありません。 結果を見ながら修正を加えようと思っています。 雲スコア (配点75%) 下層雲・中層雲・上層雲の合計雲量から算出します。 合計雲量 = min(下層雲[%] + 中層雲[%] + 上層雲 [%], 100)  ※足して100を超える場合、100を上限とする 雲スコア = 100 - 合計雲量 シーイングスコア (配点10%) シーイングはwindy APIで取得できるデータから算出できそうだったので頑張ってみました。 ここでは、大気屈折率構造定数(C n 2 )を、複数の大気層(850hPa〜200hPa)にわたって積分することでシーイングを推定します。 ...

  tomは軍資金が限られた環境で天体撮影をしています。 SE102の１本だけで撮影をしていましたが、他の焦点距離も試したいという気持ちが出てきています。 そこで、ZV-E10 ダブルズームキットに付属のSEL55210を使って撮影しようと思います。 望遠側はF6.3と暗いですが、安いからしょーがない。 まずは猛烈な光害をカットする為にQBPフィルターをレンズに取り付けます。 49-48mm ステップダウンリングで問題なく取り付けられました。 あとはカメラをAZ-GTiに取り付けるだけ。 ただし、L型アリミゾプレートって安いモノでも4400円なんですよね… という事で 安く作成してみました 。 木材 (348円) L型ブラケット (798円) 低頭ねじ (151円) プレート（25円） 木材が若干高くつきましたが… まぁ1300円程度で出来上がれば上等です。 木材はアリガタになる面を鉋で削ってテーパーをつけます。 本来は75°らしいですが、そんな細かい所は気にしません。 テキトーです。目分量で削りました。 もう片方にはプレートを付けて、ネジ締めした時に木材が凹まないようにしました。 木材は購入した長さの1/4くらいしか使わなかったので、今後DIYする際の木製アリ型プレートの予備にします。 これで55-210mmの望遠ズームも土俵に加わりました。 戦力になるかどうか、テストが楽しみです。 自作L字アリミゾブラケットの、もうひとつの使いみちも考えていました。 国立天文台望遠鏡キットを持ってたのですが、SE102を買って出番がなくなっていました。 接続は1/4ユニファイネジなので、今回作ったモノがそのまま流用出来ます。 これにチップスターの筒を投影版として望遠鏡に取り付けて黒点観測をしてみました。 あまりにやっつけ仕事で見た目がアレなので、スマホで撮影した結果だけ。 写真だと微妙ですが、目視だと黒点がそこそこ見えて満足です。 話は変わりますが、L字ブラケットと同時に延長筒も届きました（ 過去投稿参照 ）。 これで望遠鏡設置時のズレも落ち着けば嬉しいです。 ソフト面でもハード面でも着々と準備が整っています。 テスト&撮影が本当に待ち遠しい。

 Siril 1.4.0 beta3が公開されました。 このアップデートではpython scriptについての修正が多くされています。 私もGeminiを使ってpythonでプログラムを作成していたので、pythonスクリプトを作ってみようと思い立ちました。 第１弾として、コマンドでは実装されているもののGUIでは実装されていない「アンシャープマスク」をGUI操作できるようにしてみました。 ダウンロードは下のリンクから。 画面は下のような単純なものです。 適用量と半径を決めて、適用を押せば処理されます。 適用を押して満足する結果ではなかった場合は、Sirilのメインウインドウのundoボタンをクリックして元に戻し、スライダーを調整して再度適用する作業を繰り返す必要があります。 その際、スクリプトのウインドウが隠れてしまうと操作が非常にやりにくいため、ウインドウを常時最前面にする設定にしています。 Siril以外の他のアプリも含めて最前面に表示されてしまいます。 本来はプレビュー機能をつけたかったのですが、本日の時点においてsirilpyにはプレビュー機能がサポートされていないらしく、実装できませんでした。 思い立ってからこれが出来上がるまで（どうやってSirilのpython scriptをGeminiに作らせるかの検討も含めて）、１時間もかかりませんでした。 いやほんとAIって進歩が凄いですね。 また何か作れないか、のんびり考えてみたいと思います。

  ３部作最後の加工編になります。 １部手動前処理編 ２部スクリプト編 スクリプト編の終盤にコメントしましたが、加工に関しては勉強中です。 特にストレッチが難しくて、ここ最近はGHSを練習していますが何が正解なのか正直よく分かりません… まだまだ試行錯誤中なので、 tomが使えている（ = 素人でも比較的簡単に使える）ツールに重点を絞って 進めていきます。 GraXpertのインストール siril 1.4.0の新機能のため、GraXpertをインストールしておきます。 記事作成時点ではGraXpert 3.1.0 rc2です。 rc版なので、ダウンロードは github になります。 このバージョンからAIデコンボリューションが使えます。 ただし、リリース候補版なのでどんな不具合があるか分かりません。 安定版を使いたい場合は、 GraXpert のHPからダウンロードします。 Sirilでの設定は ゴンカネさんのブログ に詳しく載っています。 リニア処理 スタッキングが終わった画像を読み込みます。 画面はほとんど真っ黒のままです。 右下にある「線形」を「自動イコライゼーション」に変えると撮影したものが見えます。 画像の内、必要な所をトリミングします。 （もちろん、画面全体を使う場合は必要ありません） ここでGraXpert-AI.pyを起動させます。 Background Extractionを選択します。 Smoothingは0.2程度で良いと思います。 また、CUDAを使えるGPUを搭載していないPCの場合は「use GPU acceleration」のチェックを外します。 applyを押せば補正されます。 イマイチであれば戻るボタンで処理を取り消して数値を変更しやり直します。 続いてSPCCを実行します。 siril 1.4.0から導入されたSPCCは、画像の座標データが必須になります。 まず Tools から astrometryをクリックし、その先の「アストロメトリ」をクリックします。 画像パラメータに撮影した天体の名称を入れ、findをクリックします。 するとその下の枠に天体の名称が出てくるので、右下のOKを押します。 このウインドウが消えると座標データが取得できています。 たまに座標データが取得できない事がありますが、そうなった場合はSiri...

  前の投稿 でスケアリングが問題になったので、どれくらい傾いているのか調査から始めます。 何も処理していないraw画像をディベイヤーしてfitsファイルに変換します。 この画像を読み込んで Tool → image analysis → show tilt で下の画像が出てきます。 コンソールに表示される数値の意味は次の通りです。 stars：検出された星の数 Truncated mean：センサー全体で検出された星のFWHMの平均値です。外れ値を取り除くため、トランケート平均が使われています。 Sensor tilt：センサーの傾き。画像四隅のfwhmの最良値と最悪値の差です。括弧内には差の割合が表示されており、これが 10%以上だと調整が奨励 されます。 Off-axis aberration：中心部と周辺部のfwhmの差。コマ収差や像面歪曲を表す指標です。 分かっていたことですが、猛烈に傾いていますね。 調整が奨励される 閾値の ３倍 ですか・・・ 像面歪曲は仕方がありません。F5 格安アクロマートですから。 では、 30%を超えている傾きを10%未満になるまで頑張ります 。 と言いたいところですが、星が出てないと直せないのは厳しいです。 星が出てたら撮影したいのに、素人がスケアリング調整してたら撮影時間無くなっちゃうよ… という事で、星が出てなくてもスケアリングする方法を探りたかったのですが… tomの家の中ではピントを合わせられる直線距離がありません。 集合住宅だと、撮影時だけでなくこういう所も制限が多くなっちゃいますね。 どーすっぺ。 悩んでいる間に、薄曇りながら少しだけ星が見えたのでスケアリング調整にトライしました。 狙いとしては、Tリングマウントアダプターにアルミホイルを挟んでみようと思っています。 さて撮影。 お！ 15%まで改善した。 わりと良い感じ？と思ったのも束の間。 ここから迷走が始まります・・・ 調整したアクションと、チルトの結果が全く一致しないんです。 四苦八苦した結果、アルミホイルは思うような効果が出てない事が分かりました。 というのも、 他に支配的な因子が判明 したからです。 ネジを緩めて締め直せば傾きが変わる という、ごく初歩的な問題でした。 そりゃアルミホイルの厚みの約12μmよりも、ブレ幅は大きいでしょうな。 つまり...

タイトルの通り、スタック時の重み付けオプションが気になったので調べてみます。 もうひとつ、 前回の投稿 の後半で -equlize_cfa の有無では差異無しという結果でしたが、等高線グラフにして僅かな差も見えるようにしてみました。 （ちょっとは差があって欲しいという願望で追加調査です） スタック時の重み付け tomはスタック時の重み付けについて -weight=fwhm を使っています（ 備忘録 Siril 1.4.0 スクリプト編 参照）。 これはこれで良いとは思っているのですが、他のオプションとの違いは何だろう？と疑問に思いました。 対象によって向き不向きがあるかもしれません。 という事で、確認していきます。 オプションは次の３種類で、ざっくりした意味です。 noise：背景ノイズの値によって重み付けを行う nbstack：露光時間によって重み付けを行う nbstar or fwhm：fwhmに基づいて重み付けを行う。fwhmが同じ場合は星の数が多い方が良いと判断される。 tomは露光時間に差をつけて撮影していないので、nbstackは意味がなさそうです。 いつもはfwhmで処理しているので、今回はnoiseと比較してみます。 スタック後にノイズ評価と動的SPFで比較します。 fwhmで重みづけ noiseで重みづけ 確かに、若干ですがnoiseで重み付けした方はノイズが少なく、fwhmで重み付けした方がfwhmが小さいです。 ですが、これがどれくらいの差なのか素人には分かりません。 数値上の話だけかもしれないので、実際に画像処理してみます。 左がfwhm、右がnoiseです。 画像だと何にも変わらないです。 んー、オメガ星雲は全体に何かしら写っているので、バックグラウンドノイズの判定が難しいかも？ という事で、３月撮影のオリオン大星雲でも処理してみます。 左がfwhm、右がnoiseです。 変わらない… 数字上は僅かながら変化はありますが、私の撮影した画像では差が出ませんでした。 星団とかを写すときはfwhm、星雲や銀河の時はnoiseにするべきなのかなぁと思います。 が、差は大きくないと言うことですね。 -equlize_cfaの追加調査問題 前回の投稿で、-equlize_cfaの有無ではパっと見た感じでは変化がありませんでした。 有料ソフトでは等高線図...

 ようやく梅雨が明け、待ちに待った撮影が6/28に出来ました。 結果から先にいきます。 機材：SE102, ZV-E10未改造, QBP, AZ-GTi経緯台モード 条件：ISO1250, 25s露光×298枚 処理：トリミング、SPCC、AI デノイズ&デコンボリューションあり 撮影を始めてから７天体目。 初めて露光時間が２時間を超えました。 撮影よりも処理が難しかったです・・・ tomとしては満足のいく仕上がりになりました。 今回の撮影で試そうと思っていた事が２つあります。 ①撮影時にフラットを撮る 今まで撮影後に ダーク を撮って、 フラット は別日に撮っていました。 今回は撮影後に フラット を撮って、 ダーク を別日に撮りました。 ダークの温度合わせは出来ませんが、光学系は完全に同一なのでフラットは精度が上がるはずです。 どちらの方が良いのか調べていきます。 ②フラット補正時に、-equalize_cfa の有無で差異の確認 tomはQBPフィルターを用いているので、撮影した映像もフラットもRGBが偏っています。 このRGBが偏ったマスターフラットで補正をする場合、 -equlize_cfa でマスターフラットのRGB強度を強制的に均一化させる事で何かしらの影響があるかを確認します。 では①からです。 これはスタッキングが終わった瞬間に結果が分かりました。 上は過去撮影したM42、下は今回撮影したM17です。 M42は露光時間１時間、M17は２時間なので写野回転の影響はM17の方が大きいです。 が、M42にあった円形のカブリがM17ではなくなっています。 明らかにフラットを当日撮影した方が良くなっています。 フラットを当日撮影したデメリットとして、ダークの温度が合わなくなります。 これに加え、夏場の高温でダーク減算が更に合いにくくなるはずです。 …と思っていましたが、過補正や補正不足となっているピクセルが分かりません。 なんでだ…？？ 私はAZ-GTiを使っているので、写野回転が発生します。 過補正や補正不足によるノイズは写野回転に伴って同心円状に発生すると考えています。 また、家が鉄筋コンクリートのマンションなのでスマホのコンパスが狂ってしまい、真北が正確に分かりません。 追尾エラーはそこそこ大きいです。 今回の撮影でも、途中で鏡筒の向き...