注意: この記事は過去の記事を移行したものです．

あいさつ

こんにちは．先程日本天文学会での発表を終えてきましたので，その内容を簡単にまとめておきたいと思います．そして，だいぶ前の記事
天体写真とその処理過程について【前編】
の伏線をここで回収したいと思います．なぜこのタイミングなのか？それは読み進めて行けばわかります笑

発表内容

今回発表してきた内容は，主にAFLAK（Advanced Framework for Learning Astrophysical Knowledge）と呼ばれる，天体データ処理用フレームワークについてでした．インストール方法等はこちら（http://aflak.jp）をご覧ください．

背景

最近，銀河等の天体に対して，面分光と呼ばれる技術を用いて得られる多波長データと呼ばれる類のデータを解析することが天文学者の間で盛んになされています．この多波長データというのは，通常RGBの3チャンネルを持つ写真のデータとは異なり，波長方向に数千～数万もの大きな次元サイズをもつデータを指します．それぞれのチャンネルの波長幅はなんと1nmほど，天体写真を撮っている方であれば，「究極のナローバンド」と考えれば良いでしょう笑．このような大規模かつ高次元なデータを扱うソフトウェアは従来から存在しますが，基本的にコマンドベースのもの，あるいは解析内容を天文学者自らがプログラムの形で記述するようなものでした．

提案手法（AFLAK）

そこで，AFLAKと呼ばれるフレームワークでは，ビジュアルプログラミング環境を提供することによって，ユーザがより効率的に解析を行うことを支援します．以下のようなメリットが挙げられます．

• パラメタの変更などが即座に反映され，ユーザに対する迅速なフィードバックを行う．
• **解析そのものの内容の管理が容易となる．**

以下のスクリーンショットをご覧ください．画面上側に何やらグラフのようなもの，画面下側に２つの出力結果が見て取れます．画面上側のエディタ（この中にあるそれぞれのボックスをノードと呼びまして，エディタ全体をノードエディタと呼びます）をユーザは操作し所望の解析を行います．データは左から右へと流れていくと考えてください．まずいちばん左上のPathというノードで，ファイルを選択します．このソフトウェアではfits形式のファイルを扱うことになっているので，選択したファイルを次のopen_fitsというノードで開きます．fitsにはHDUというデータユニット（データの塊です）が存在しており，複数の天体データを保持できるようになっているので，次のfits_to_imageというノードでどのデータを取り出すかを選択しています．この時点で，今回赤経赤緯および波長方向の三次元のデータになっていますので，ここからextract_waveノードとslice_one_frameノードを使って，結果のイメージを出しています．前者が輝度のスペクトル，後者が，ある波長でスライスした時の輝度の二次元イメージになります．

ここで，例えばslice_one_frameノードの中のパラメタを変更すると，フレームの画像はすぐに更新されます．これがユーザに対する迅速なフィードバックです．また，解析自体の内容はこのグラフの構造自体が持っています．このようなグラフ構造をデータとして保存するのはさほど難しくはないです．

…さて，発表ではこのあと私が実装した少し複雑な解析例を提示し，天文学者が解析したものと同様の結果が出ましたということを言って，その他の解析例や課題を示して終わったわけです．

で，この研究に携わり始めた頃から，ずっと自分の中で考えていたことがあるんです．

……これ，天体写真の画像処理にもめちゃくちゃ使えるのでは？

重要なのは，私が先程から赤で書いている部分，
「解析そのものの内容の管理が容易となる．」という部分です．これの「解析」を「現像」と読み替えると，理解していただけるのではないでしょうか．私が前回の記事で指摘した内容を簡単にまとめるとこうです．

• 編集過程は天体写真において，それが科学であろうと芸術であろうと重要ではないか．
• にも関わらず，編集過程を管理している人は限りなく少ない．
• それは人間の問題ではなく，ソフトウェア側の問題である．もともと，ソフトウェアがそういったことを管理すべきだった．
• 解決しようという動きがある．例えばステライメージ8にはワークフローの機能が追加されている．ただし，結局レイヤー的な処理にとどまるものと言え，複雑な処理に対応できない可能性がある．

私は，このAFLAKがもつ特長は，このソフトウェア側の問題を根本的に解決するものとなりえると考えています．このソフトウェアでは解析の「分岐」を表現することができるんです．これがステライメージ8との違いだと考えます．
例えば画像をRGB分解して，あるチャンネルだけに処理をかけて合成するということ，そしてその間にかけられる処理はユーザが自由に表現できるんです．そして，何より，その自由な表現を，グラフの形で保存し，共有することができます（当然公開の自由はあると思いますが）．

例えば，保存されたあのあこがれの人の処理過程を使って，自分の写真で開いて試してみよう．これはパクりを教唆するわけではありません．むしろ，あのあこがれの人に近づくには何が必要なのか，かえっては，自分なりの表現には何が必要なのかというヒントを得る．こういったことができるようになると考えます．科学において解析の内容を保持することは重要ですが，芸術においても重要なのではないでしょうか．

もちろん，このソフトウェアは未だ天体写真ではなく，天文学用のデータに特化したものです．どのような処理ノード，パラメタがあれば写真の用途にも使えるのかは，まだまだ検討していかなければならない段階であると思います．
しかし，このソフトウェアは，天体写真の「複雑な現像処理を必要とする」という特性を埋めるものであり，天体写真処理に革命を起こすのではないかと考えています．なぜなら，もし世に出ることがあれば，それは「天体写真は各人が持っている画像処理の腕では実質決まらない」世の訪れを示唆するものであるからです．

コメント，批判，提案等あるかもしれませんが，是非お願いいたします．

注意:以下コメントになります．

ぐっち:

現状は「天体写真は各人が持っている画像処理の腕で実質決まってしまう」事が多いので画像処理の習得に挫折する事で天文(あるいは天体写真撮影)から遠ざかってしまう人も多いと思います｡
“いい天体写真”“すごい天体写真”(この定義が難しいですが)に仕上げるために施された処理過程を解析し､再現可能な処理に再構築することができれば､
「天体写真は各人が持っている画像処理の腕では実質決まらない」世
が来るかもしれません｡それこそDeepLeaningの世界でしょうか｡
期待しています｡

astrodabo:

ぐっちさん
コメントありがとうございます。情報工学を学んでいる人間として本文のような文章を書きました。機械学習が多くの分野で流行っていることや、機械学習による恩恵は大きい、というのは事実です。が、このような芸術的な側面ももつ領域において、なんでもコンピュータにやらせる、というのは、私としてはちょっと違うのかなと思います。
「天体写真は各人が持っている画像処理の腕では実質決まらない」というのは、良くも悪くも、副産物のようなものだと考えています。処理が上手い人にとってそのようなことは受け入れがたいかもしれないという意味ではデメリットにもなりますし、逆に画像処理の敷居が下がるのはメリットだとも思います。
それよりも私が望んでいるのは、処理プロセスを可視化することによって「自分なりの表現を見つける機会が増える」ことです。従来のレイヤー的な処理しかできないソフトウェアでは発見しにくい自分の表現の利点や欠点を発見する機会が増えることで、天体写真という趣味がさらに深まればいいなと考えています。

ぐっち:

4月に入ってしまいましたが､時折思い出したときにこの件について考えていました｡
自動車のオートマが出てきたとき､この(当時の)新技術に対してかなりネガティブな批評や反感があったことと重なりました｡｢車を操る楽しみがなくなる｣｢変速段数が少ない｣｢燃費が悪い｣などけっこう散々でした｡開発を続けてきたことと意識が変わってきたこともあり､今は自動車は大半がオートまでマニュアルの方が少なくなってしまいました｡

天体写真の画像処理については､
・再現性(同じ素材に対して誰が､何度やっても同じ結果が出せる)､
・汎用性(異なる対象に対しても同じプロセスが適用できる)､
・普遍性(特定のソフトやそのバージョンに依存しない)
を持った手法が確立できれば､天体写真における画像処理の比重が少なくなるのではないかと思います｡

これは撮影の比重が相対的に大きくなることを意味するので､撮影地､光学系､カメラ等の差や撮影時の構図の取り方や追尾の手法など､｢天体撮影｣の本質で工夫する領域が増えるのではないかと思います
｢撮影｣した結果が｢画像処理｣のインプットになり､この｢画像処理｣のアウトプットを使って作者の好みによる｢最後の仕上げ｣を行うようなプロセスで天体写真ができるようになれば楽しいかな､と思います｡

astrodabo:

ぐっちさん
コメントありがとうございます。新年度が始まって忙しくなかなかブログを見れておらず遅くなって申し訳ありません。

このパラダイムはもともとゲーム開発や3Dモデリング/シェーディング等の分野で使われていまして、それを画像処理フローに輸入できないかという提案なので、(確かに計算資源が近年豊富となってきているというバックグラウンドはありますが)ATのような目新しいテクニックというわけではないですね。ただ何か新しいことをしようとした時に似たような指摘や批判は免れないと考えています。

再現性、汎用性、普遍性にプラスして、本文で記述し忘れていた重要なこととして、「ユーザが思いついた処理を即座にフローの形で表現できる」、すなわちラピッドプロトタイピング可能性というものも挙げられますね。

撮影の比重が重くなるというのは本当にその通りで、構図、追尾、写真の内容で「何か面白いことをする」ということでもって、今よりももっと天体写真の表現の幅が広がればいいな、と考えています。