Consider unifying array types

[malikolivier]

Currently aflak_primitives uses a different type for each array dimension (1D, 2D, 3D, and 4D is currently being implemented).
This make it tedious to compose several types of nodes like integral, average. You need a node for each array size: one that takes 3D images as input, one that takes with 2D images as input, etc, even though these nodes basically do the same thing.

Thus we may unify all array types with the ArrayD struct defined in ndarray. This will improve usability.

[malikolivier]

@kazuyakusastro @dabokun ac09f4e から b68564a まで でimageの対応を再構築しました。
今まで、Image1d、 Image2d、Image3d、Image4dの4つの型がありました。これからImageのみという型になります。
Imageのサイズがダイナミックになりました。
これで、Imageの次元に依存しない処理は全部同じtransformを使えます。 前はlinear_composition_2d/linear_composition_1dなどがありましたが、現在はlinear_compositionに統一しました。fits_to_3d_imageとfits_to_4d_imageも同じく、fits_to_imageになりました。averageとintegralも、どんな入力画像でもn次元画像をn-1次元画像に変換できるようになりました。

もしImageの次元に依存するtransformに異なる次元の画像を入力すると、エラーが出力されます。

例： extract_waveは三次元画像をexpectしています、二次元画像を入力すれば「Expected 3-dimensional image, but got 2-dimensional image」というエラーになります。

結構大きい変更なので、ご確認だけをお願いします。これでaflakが使いやすくなり、transformの汎用性が広がります。

[kazuyakusastro]

はい、良い変更だと思います。
4以上の次元を持ったfitsファイルをfits_to_imageに入れた時、どの次元が空間次元かというのはheaderから読み取るのでしょうか？
それとも、1番目と2番目が空間方向であるとして、処理が進むのでしょうか？

[malikolivier]

それとも、1番目と2番目が空間方向であるとして、処理が進むのでしょうか？

ここは前と変わらず、FITSファイルの順で読み取っています。下流の処理で軸を変える機能が必要になるかもしれません。

現在私がもらっているFITSファイル（主にSDSSとALMAからの）は全部下記のパターンです：

• 1番: 偏光軸 (あるなら)
• 2番: 波長軸 (あるなら)
• 3/4番:画像の空間軸

時間軸の含まれているFITSフィアルは存在すると聞いていますが、まだ見たことないです。

私が知る限りHeaderにCTYPEnというキーワードが指定されれば、上記の順で必ず出力することが可能かと思います。
だが、どうしてもその順番を手動で変える必要性が出てくると思います。そういうユースケースがあれば、ぜひ教えてください。（その場合、例のFITSファイルもください）

[kazuyakusastro]

自分たちの観測装置で撮ったデータをaflakに読み込ませるために、一次処理後のファイルをどういう様式にするべきか気になって、質問しました。

SDSS/MaNGAのfits headerは
CTYPE1 = 'RA---TAN'
CTYPE2 = 'DEC--TAN
CTYPE3 = 'WAVE '
となっています。
RA = right ascension (赤経)、DEC = declination (赤経) で空間方向を、WAVE = wavelength で波長方向を表しています。
aflakのデータ読み取り順とは逆のようですね。

2次元画像ファイルも含めて、ほとんどのfitsファイルでCTYPE1と2が空間方向になっているため、空間方向と波長方向はこの順番で、と決めて読み取っても問題ないと思います。
(必要であれば、fitsファイルの方を書き換えてしまうこともできます。)
fits headerを読むようにすれば、より確実かと思います。

時間軸が入ったfitsファイルは僕も見たことがありません。
宇宙の天体が早く変動する様子を検出することは、一般の天体はできないためです。
(普通の銀河などは数年後に観測しても、全く変わりません。)
太陽の観測をしている研究者は、数分程度の早い変動を捉えて研究しているので、時間軸が入ったfitsファイルを作っている可能性があります。
そういうデータが無いか探してみます。

[malikolivier]

ありがとうございます。

aflakのデータ読み取り順とは逆のようですね。

Rustのvectorの順番はlittle-endianであり、翻ってFITSのdata arrayの順番はbig-endianであります。FITSファイルを読み込んだときにデータをrearrangeしていないので、結果としては順番が逆になります。
今までそれが問題だと思わなかったです。

fits headerを読むようにすれば、より確実かと思います。

そこの議論は #41 に移しましょう。それ専用のissueを作りました。

そういうデータが無いか探してみます。

今のところは太陽のデータなどはなくて大丈夫です。優先順位低いです。ああいうファールで解析をやりたい人がいれば検討します。

とにかく、このissueはこれで閉じます。