Asterpy.io.Fits一般的な問題解答¶
一般的な問題¶
PyFITSとは何ですか？それは何と関係がありますか？ astropy そうですか。¶
PyFITS 作成されたライブラリであり Python 読み書きや操作のためのプログラミング言語 FITS ファイルをフォーマットする。タイトルを高レベルおよび低レベルで動作する能力に適合させ、画像およびテーブルデータの読み取りをサポートする高度なインターフェースを含む Numpy 配列していますそれはまた、いくつかのFITSファイルで発見されたより曖昧で非標準的なフォーマットをサポートします。
♪the astropy.io.fits モジュールはPyFITSと同じであるが，名前は異なる.…の発展に当たる. astropy 最初は、核心的な需要の一つがFITSリーダーであることは明らかだった。Pythonが利用できる最も柔軟なFITSリーダーとして、PyFITSは最初からではなく、移植されています astropy それがそうです。PyFITSを独立モジュールとして段階的に淘汰し，それを破棄する計画がある. astropy.io.fits それがそうです。この点についてのより多くの情報は、次の問題を参照してください。
PyFITSは主にPythonで書かれているが、Cで書かれたオプションのモジュールを含み、圧縮画像データを読み書きするにはこのモジュールが必要である。ただし，PyFITSの残りはこの拡張モジュールなしで動作する.
PYFITSの現状はどうですか？¶
PyFITSは科学ソフトウェア科によって書かれ維持されています Space Telescope Science Institute そして、そして AURA 1つは 3-clause BSD license それがそうです。
It is now exclusively developed as a component of astropy
(astropy.io.fits) rather than as a stand-alone module. There are a few
reasons for this: The first is simply to reduce development effort; the
overhead of maintaining both PyFITS and astropy.io.fits in separate code
bases is nontrivial. The second is that there are many features of astropy
(units, tables, etc.) from which the astropy.io.fits module can benefit
greatly. Since PyFITS is already integrated into astropy, it makes more
sense to continue development there rather than make astropy a dependency
of PyFITS.
PyFITSの過去の主要開発者と積極的な保守者はErik Brayである.ある GitHub project PyFITSに対しては，PyFITSは積極的に開発されていないため，パッチや問題報告はAstropy問題トラッカに配布すべきである.
現在(最後でもある)安定バージョンは3.4.0である。
使用問題¶
私が予想していたように仕事をしていないことがある。私は何か間違ったことをしましたか？¶
可能性はあります。しかし，文書で操作しても予想どおりに動作していない場合には，文書に誤りがあり，コードにbugがあるか，あるいは両者がある可能性が十分である.したがって、いつでもそれを間違いとして報告してください。FITSファイルには隅の箱がたくさんあり、ほとんど毎週新しい箱が発見されています。 astropy.io.fits いつも改善されているが、すべての状況を完璧に支持するわけではない。FITフォーマットのいくつかの機能(例えば、スケーリングデータ)を正確にサポートすることは困難であり、意外な行動を引き起こす可能性がある。
しかしながら、FITSヘッダ、画像、およびテーブルの読み出しおよび更新など、最も一般的な場合には、 astropy.io.fits 非常に安定しており、良好なテストが行われた。一定時間ごとに astropy リリースは、そのすべてのテストが様々なプラットフォーム上で通過できることを保証し、これらのテストは、ほとんどの用例(新しい用例が発見されるまで)をカバーしています。
astropy クラッシュして長い列のコードを出力します私はどうすればいいですか。¶
このコードリストはよく知られています stack trace (あるいはPythonの言葉で言えば“バックトラック”です)。プログラム終了を招くコードに未処理の例外が発生した場合，例外発生の位置と例外を引き起こすコードの経路を表示する方式である.
AS astropy 他のソフトウェアプロジェクトの一部として使用すべきでしたが astropy デザインされています例えば最も一般的な異常の1つは KeyError タイトルに存在しないキーワードの値の読み取りを試みると：
>>> from astropy.io import fits
>>> h = fits.Header()
>>> h['NAXIS']
Traceback (most recent call last):
...
KeyError: "Keyword 'NAXIS' not found."
これは存在しない“NAXIS”というキーワードを探していることを示している。以下の命令を用いた他のソフトウェアで類似したエラーが発生すると astropy ファイルに存在しないキーワードを見つけたいので、ソフトウェアにエラーがあることを表すことができる。
多くの“予想された”例外はバックトラックの末尾にメッセージを出力し，例外発生の原因やどのように処理するかを説明する.異常なエラーメッセージが曖昧に表示されるほど神秘的になる可能性があります astropy それがそうです。したがって、もしあなたが異常を受け取った場合、あなたは本当にそれをなぜまたはどのように処理するのか分からないなら、いつでもbugとして報告してください。
なぜCFITSIO、DS 9などでファイルを開くことができますが、中でファイルを開くことができません astropy そうですか。¶
本よく見られる問題解の他の部分で述べたように，FITSファイルを扱う際には異常なコーナーが多い.文書は正常に作動するかもしれないが、ミスで支持されない。時々ファイルは古いバージョンの astropy しかし、回帰はまだテストされていないので、より新しいバージョンではありません。
FITSフォーマットのもう1つの問題は，古いにもかかわらず，あるソースのファイルにFITS規格に適合しない約定が多く出現していることである.しかし、それらは非常に一般的で、適切な読者の中でそれらを支持する必要がある。連続カードはこのような例である.支持非標準約束 astropy それらはCFITSIOによってサポートされておらず、その逆も同様である。あなたは事件の一つにぶつかったかもしれません。
もし astropy ファイルを開く時に問題が発生し、これは問題があるかどうかを排除する良い方法です astropy この書類を通過させることです fitsverify プログラムです。小さなファイルに対してもご利用いただけます online FITS verifier それがそうです。これらの文書は舞台裏でCFITSIOを用いており，文書に誤りがあるかどうかをうまく指示できるはずである.ファイルフォーマットがエラーである場合、fitsVerifyはエラーおよび警告を出力します。
FitsVerifyがファイルに問題がないことを確認した場合、 astropy まだ開くことができません(特にバックトラックを生成すれば) astropy それがそうです。
どうやって警告情報を消しますか？ astropy 私のコンソールに出力するのでしょうか？¶
astropy Pythonの内蔵を使用して warnings 回復可能であるが、ユーザに異常を通知する必要がある場合があることを通知するためのサブシステム。最も一般的な警告の1つは astropy.io.fits 注釈を切断して空間を保持するようにヘッダ値を更新しなければならない場合：
Card is too long, comment is truncated.
生成された任意のコンソールから出力されます astropy これは警告サブシステムからのものと仮定することができる.Astropyのドキュメントについては、ご参照ください Python警告システム 沈黙警告をどのように制御するかの詳細については、参照されたい。
慣例の役割は何ですか。 astropy インデックス、例えば画像座標のインデックスに使われますか？¶
配列と配列の全ては astropy ゼロから始まるインデックスプランを用いる.例えばタイトルの最初のキーワードは header[0] やめて！ header[1] それがそうです。これはPython自体およびPythonがベースとなるC言語と一致する。
これは，IRAFはFortranからの起源であるため，IRAFは通常1ベースのインデックスを使用しているため，IRAFからのベテランFITSユーザを驚かせる可能性がある.
同様に，Nx N配列中の左上画素は data[0,0] それがそうです。2次元配列のインデックスは行優先順位であり、1番目のインデックスは行番号であり、2番目のインデックスは列番号であるからである。または軸に関しては、第1の軸はy軸であり、第2の軸はx軸である。これはFortranで使用されている列-主順序とは逆であるため，これと一致する.例えば、第2のインデックスは、FITSヘッダのNAXIS 1によって指定される軸を参照する。
通常，N次元配列に対して行優先順位は，配列データ上を線形に移動する際に，最右の軸の変化が最も速いことを意味する.例えば、3次元配列：：
[[[1, 2],
[3, 4]],
[[5, 6],
[7, 8]]]
行を主とする順序線形表現は：
[1, 2, 3, 4, 5, 6, 7, 8]
2は1の直後であるため，最右(または最内側)の軸の変化が最も速いことが分かる.
軸順位の違いは適応するのに時間がかかるかもしれないが、これは必要な悪い結果だ。他のPythonおよびCソフトウェアの多くは行優先順位を採用しているため、返された配列から列優先順位付けを強制的に実行しようと試みています astropy その価値よりも多くの困難をもたらすかもしれない。
どうやってメモリに格納できない非常に大きな画像を開くのでしょうか？¶
astropy.io.fits.open メモリマッピングでHDUにアクセスするデータ部分を選択することができます mmap それがそうです。はい。 astropy デフォルトでこのオプションを使用します。
これは，上の例に示すように，データにアクセスする際に必要に応じて部分データのみをメモリに読み込むことを意味する.例えば画像の一部だけを要求すれば例えば hdul[0].data[100:200] 100￣200行目のみがメモリに読み込まれる.これはまるで画像全体がメモリに入っているかのように透明である.この時計も同じです。ほとんどの場合、これは大きなファイルを処理するための最適な選択だ。
メモリマッピングの使用を確保するためには、追加してください memmap=True はいの論点です。 fits.open それがそうです。同様に使用しています memmap=False 強制的にデータをメモリに完全に読み込む.
デフォルト値は、名前の構成オプションで制御することもできます USE_MEMMAP それがそうです。これを 0 デフォルトでmmapを無効にします。
残念ながら，メモリマッピングは現在スケーリング画像データをうまく扱うことができず，スケーリング画像データでは，データにBSCALEとBZERO因子を適用して物理値を生成する必要がある.現在、これは未来に改善される領域であるにもかかわらず、アレイ全体を収容するのに十分なメモリを必要とする。
別の方法は、Sectionsインタフェースであり、現在は画像データ(すなわち、非テーブル)にのみ適用されている。これは、mmapのより良いサポートに大きく置き換えられているが、32ビットシステムのような仮想メモリ空間のより限られたシステムにおいても有用である可能性がある。スケーリング画像データのサポートも不安定であるが，この問題は解決される.上の文書を参照してください image sections このインタフェースを用いたより詳細な情報については，参照されたい.
どのようにして非常に大きなFITSファイルを最初から作成しますか？¶
見 最初から非常に大きな協力ファイルを作成します それがそうです。
非常に大きなテーブルを作成するためには、1つのテーブルが何行必要かを事前に決定することは困難であるが、この方法を使用することもできる。一般的には astropy.io.fits module is currently discouraged for the creation and manipulation of large tables. The FITS format itself is not designed for efficient on-disk or in-memory manipulation of table structures. For large, heavy-duty table data it might be better too look into using HDF5 通過する. PyTables 図書館です。♪the Astropy Table インターフェースはまた、異なるディスクテーブルフォーマット間に抽象化層を提供することができる(例えば、FITSとHDF 5との間でテーブルを変換するために使用される)。
PyTablesは舞台裏でNumPyを使用しており，FITS要求の同じフォーマットでバイナリテーブルデータをディスクに書き込むために利用可能である.そして、配布のためにテーブルをFITS形式に整列化することができます。ある程度、この一般的な問題解答は、これをどのようにするかの例を提供するかもしれない。
どのように最初からマルチ拡張子FITファイルを作成しますか？¶
見 マルチ拡張フィッティング(MEF)ファイルを最初から作成します それがそうです。
なぜ整数データを含む画像が意外に浮動小数点数に変換されるのですか？¶
画像のタイトルが任意のBSCALEおよび/またはBZEROキーワードの非平凡値(すなわち、BSCALE！=1および/またはBZERO！=0)を含む場合、ファイル内の元のデータは、式に従ってその物理値に再スケーリングされなければならない：
physical_value = BZERO + BSCALE * array_value
BZEROとBSCALEは浮動小数点値であるため，結果値も浮動小数点値でなければならない.プリミティブが16ビット整数である場合、結果値は単精度(32ビット)浮動小数点数となる。元の値が32ビット整数である場合、結果値は倍精度(64ビット浮動小数点数)となる。
予期しない場合、この自動スケーリングはHDUのデータ部分にアクセスする前に発生しないので、この自動スケーリングは容易になります(データを再スケーリングすることなく新しいヘッダを更新することを可能にします)。例えば：
>>> fits_scaledimage_filename = fits.util.get_testdata_filepath('scale.fits')
>>> hdul = fits.open(fits_scaledimage_filename)
>>> image = hdul[0]
>>> image.header['BITPIX']
16
>>> image.header['BSCALE']
0.045777764213996
>>> data = image.data # Read the data into memory
>>> data.dtype.name # Got float32 despite BITPIX = 16 (16-bit int)
'float32'
>>> image.header['BITPIX'] # The BITPIX will automatically update too
-32
>>> 'BSCALE' in image.header # And the BSCALE keyword removed
False
これは，ユーザがデータにアクセスすると，操作や計算を行うことができるからである.データを整数に強制的に残すと，大きな精度が失われる.したがって，データを失わずに誤りを犯し，その代償として最初に何らかの混乱を招くことが望ましい.
保存する前にデータを整数に返さなければならない場合は、ご利用ください scale 方法：
>>> image.scale('int32')
>>> image.header['BITPIX']
32
>>> hdul.close()
あるいは、開いたファイルを使うと mode='update' そして scale_back=True パラメータは、保存する前に、元のBSCALEおよびBZEROスケーリングが自動的にデータに再適用される。一般に、これは不要であり、特に浮動小数点値から符号なし整数値に変換する場合には不要である。しかし、元のデータが物理値の変更に対応して修正される必要がある場合には、これは有用である可能性がある。
再スケーリングを完全に防ぐためには(ヘッダの更新にメリットがあります-コードをデータにアクセスさせるつもりがなくても、ここでは慎重にエラーをしたほうがいいです)、ご利用ください do_not_scale_image_data ファイルを開く際のパラメータ：：
>>> hdul = fits.open(fits_scaledimage_filename, do_not_scale_image_data=True)
>>> image = hdul[0]
>>> image.data.dtype.name
'int16'
>>> hdul.close()
なぜ見出しに浮動小数点値を割り当てると精度が失われるのですか？¶
FITS規格では，2つのフォーマットがヘッダ値に浮動小数点数を格納することを可能にしている.固定“フォーマットが数字を要求するASCIIは、タイトルカードのバイト11~30に表され、右に整列される。これは，任意のアノテーション文字列のための標準文字数を保持する.
FIXEDフォーマットは幅が十分ではなく，64ビット浮動小数点型に全精度で格納できるすべての値範囲を表すのに十分ではない.したがってFITSは，ASCIIがどこにも格納可能であり，カードの全70バイト(キーワードの後)を使用できることを表す“自由”フォーマットをサポートしている.
目下 astropy 書き込み固定フォーマット(2つのフォーマットを読み取ることができる)のみをサポートするため、ヘッダに割り当てられたすべての浮動小数点値は固定フォーマットで格納される。より柔軟な形式の支援を増加させる計画がある。
一方、文字列中のカード画像を手動でフォーマットすることにより、FITSファイルに出現すべきであるので、カードを追加または更新することができる：
>>> c = fits.Card.fromstring('FOO = 1234567890.123456789')
>>> h = fits.Header()
>>> h.append(c)
>>> h
FOO = 1234567890.123456789
以下のように“foo”に割り当てない限り h['FOO'] = 123 ヘッダ値のフォーマットを完全に保持する(FITS規格に従って有効であれば).
なぜFITS表から行を読むのはこんなに遅いのですか？¶
返された表データ配列ごとの基礎 astropy.io.fits is a numpy recarray which is a numpy array type specifically for representing structured array data (i.e., a table). As with normal image arrays, astropy accesses the underlying binary data from the FITS file via mmap (see the question "What performance differences are there between astropy.io.fits and fitsio? “これに対するより深い解釈を得るために)。そして、底層mmapは、 recarray 一般に，これは非常に効率的にデータを読み取る方式である.
しかし、多くの人(ほとんどの人でなければ)にとって、これはそんなに簡単ではない。多くの列に対して，“ディスク上”(FITSファイル中)の実データとユーザに返されたデータ値との間で変換しなければならない.例えば，FITバイナリ表はブール値を表す方式と numpy それらが表現されたい場合、“論理”列を1つのフォーマットに動的に変換する必要がある numpy (したがってユーザは)理解できる.この問題は通過にも適用される TSCALn そして TZEROn 見出しキーワード。
これらすべての“適切な原則”をサポートすることは、多くのオーバヘッドをもたらすが、これらのオーバヘッドは、すべてのテーブルに必要なものではないかもしれないが、依然として一般的である。これは，FITSの特性をサポートしても，それ以上速くはならないということではない-たとえば，CFITSIOはすべての同じ機能をサポートしているが，数桁高速である. astropy ここではまたもっとよくすることができ、多くの既知の問題が速度の鈍化を招く。加速する機会が多く、パッチも人気があります。また，FITSテーブルを持つ高性能アプリケーションについては，一部のユーザが発見する可能性がある. fitsio 図書館の方が彼らの好みに合っている。
私はループで複数のFITSファイルを開きましたが、OSErrorを受け取りました：開いているファイルが多すぎます¶
以下のようなコードを持っているとしましょう
from astropy.io import fits
for filename in filenames:
with fits.open(filename) as hdul:
for hdu in hdul:
hdu_data = hdul.data
# Do some stuff with the data
詳細は異なるかもしれないが、定性的な点は、多くのHDUおよび/またはFITSファイルのデータが循環的にアクセスされることである。これは異常を引き起こすかもしれません
Traceback (most recent call last):
File "<stdin>", line 2, in <module>
OSError: [Errno 24] Too many open files: 'my_data.fits'
例えば…。 note on working with large files なぜなら、 astropy デフォルトでは、mmapを使用してFITSファイルのデータを読み込み、使用しても HDUList.close メモリマッピングされたデータアレイを依然として透明に読み取り続けることができるように、ファイルのハンドルが開いているままである。
この道は numpy サポートされているmmapは、ファイルマッピングが上書きされるまで閉じません。 ndarray オブジェクトはそれを参照せず，メモリを解放した.しかしながら、大量のファイル(さらにはHDUのみ)を高速に循環トラバースする場合、これは直ちに起こらない可能性がある。または場合によっては、HDUオブジェクトが継続的に存在する場合、それに付加されたデータ配列も継続的に存在する可能性がある。提案された解決策は 人工的に 削除 .data 属性は、 ndarray 参照は解放され、mmapは閉じることができます：
from astropy.io import fits
for filename in filenames:
with fits.open(filename) as hdul:
for hdu in hdul:
hdu_data = hdul.data
# Do some stuff with the data
# ...
# Don't need the data anymore; delete all references to it
# so that it can be garbage collected
del hdu_data
del hdu.data
極端な場合、ファイルの開閉速度は十分に速く、Pythonのゴミ収集器はそれらを十分に頻繁に解放することができない(それによってファイルハンドルを解放する)。この問題を緩和するために、コードは手動でゴミ回収を強制することができます。方法は呼び出しです。 gc.collect() ループの末尾にあります。
将来のバージョンでは，必要な場所でFITSファイルを閉じる際にこのようなクリーニングを自動的に実行する方が便利である.
見出しを使う [“NAXIS 2”] +=1私の表に他の行は追加されません¶
NAXIS 似たようなキーワードと一致する 構造物. キーワードは、ユーザによって修正されてはならない。自動的に更新されます astropy.io.fits データとヘッダの有効性をチェックする場合。参照してください 構造キーワード より多くの情報を得ることができます
表に行を追加するためには，実データを修正することができる.
他のFITSリーダとの比較¶
Asterpy.io.fitsとfitsioの違いは何ですか？¶
♪the astropy.io.fits module (originally PyFITS) is a "pure Python" FITS reader in that all of the code for parsing the FITS file format is in Python, though numpy is used to provide access to the FITS data via the ndarray interface. astropy.io.fits currently also accesses the CFITSIO FITSタイル圧縮約定をサポートしているが，この機能はオプションである.圧縮画像の読み取り以外はCFITSIOを用いない.
fitsio 一方，_はCFITSIOライブラリのPythonラッパである.FITSフォーマットの読み込みのすべての激務はCFITSIOによって処理されます。 fitsio 提供することを含む、オブジェクト指向APIをより良く使用する方法を提供する numpy インタフェースはCFITSIOから読み込むファイルに適している.その大部分はCで書かれており(PythonとCFITSIO間のインタフェースを提供するため)、残りはPythonで書かれています。Python側は主に文書とユーザレベルのAPIを提供します。
なぜなら fitsio CFITSIOをパッケージ化することは、CFITSIOを直接使用するよりも便利なAPIを提供するにもかかわらず、その利点および欠点の大部分を継承する。
なぜAstropyはFitsioではなくPyFITSをFitsリーダーとして採用しているのですか？¶
Astropyプロジェクトが初めて起動された場合，そのコアコンポーネントの1つは，多くの他のコンポーネントがこの機能に依存する可能性があるため，FITSファイルを読み書きするためのサブモジュールであるべきであることが最初から明らかになった.当時は fitsio コースはまだ初期段階(約2011年まで)ですが、PyFITSは成立しています(2000年までにさかのぼります)。それは、野外で発見されたほとんどのFITSファイルをサポートする成熟したパッケージであり、“Random Groups”FITSファイルのようなまだ電波天文学コミュニティで広く使用されている古いフォーマットを含む。
PyFITSインタフェースの多くは過去数年間変化しているにもかかわらず，その大部分は不変であり，PythonでFITSファイルを扱う天文学者にはよく知られている.既存の訓練材料の多く(すべてでなければ)もPyFITSに基づいている.PyFITSはSTScIによって開発され，STScIもAstropyを開発する重要な資源を提供し，AstropyをSTScI自身のソフトウェアスタックに統合することに着目した.STScIの多くのPythonソフトウェアはPyFITSを使用しているため，この移行を実現するための唯一の実際的な選択である.
最後にCFITSIOが拡張しているにもかかわらず fitsio )FITS規格に準拠する任意のFITSファイルを読み取ることができるが、野外でFITSファイルに追加されたすべての非標準約定をサポートしていない。それは、いくつかのコミットメントのサポート(例えば、連続カードおよび(限られた程度の)階層カード)を有するが、他のコミットメントのサポートを膨大で複雑なCコードライブラリに追加することは容易ではない。
PyFITSのオブジェクト指向設計は，多くの場合非標準約定をサポートすることが容易になるため，PyFITSは読み取りおよび返却可能なFITファイルタイプをより柔軟に選択することができる. 役に立つ データから来ています。これには、FITS規格に準拠していないファイルに対してより良いサポートを提供することが含まれているが、FITS規格に違反している場合を訂正するのに十分な読み取り可能な有用なデータが依然として含まれている。たとえば，非英語領域の一般的な誤りは，非ASCII文字をFITヘッダに挿入することである.これは有効なFITSファイルではないが，ある意味では依然として可読であるはずである.CFITSIOでは，このような構造誤差をサポートすることは困難であり，CFITSIOは構造を仮定した方が剛性であるためである.
Asterpy.io.fitとFitsioの間にはどのような性能差がありますか？¶
主な性能領域には，FITSヘッダの読み出し/解析とFITSデータの読み出し(類似画像の配列と表)の2つがある.
ヘッダ領域では fitsio ほとんどの場合ずっと速いです。これは，純Cが実現されていること(CFITSIOを用いているため)が大きいが，それがより厳しく，それのような多くのローカル約束や他の特殊な場合をサポートしていないためである. astropy.io.fits 純粋なPython実装でサポートしようとしています。
すなわち，数千個のHDUを含むファイルを開いても，数千個のFITファイルからヘッダファイルを連続して読み出した場合でも，差異は小さく，ボトルネックとなる可能性がある(いずれの場合も差異は1桁ではない).
データの面では、状況は少し複雑で、どのように理解する必要がありますか astropy.io.fits CFITSIOに対して実施されており、 fitsio それがそうです。まず，メモリ管理における違いを知ることが重要である.
astropy.io.fits デフォルトでは、mmapを使用してFITSファイル中の元のバイナリデータへのアクセスを提供します。Mmapは、システムコール(または多くの場合、libcにおけるより低いレベルのシステムコールのためのラッパ)であり、ユーザ空間アプリケーションは、オペレーティングシステムが仮想メモリのためにページファイル(交換空間)を使用する場合と本質的に同じ動作を実行することを可能にする：ディスク上のファイル中のデータを必要に応じて1ページ(実際には数ページ)に物理メモリにページ分けすることを可能にする。システム上のすべてのプロセスもファイルのこれらのキャッシュページにアクセスできるため，複数のプロセスは同一ファイルからデータを読み出すことができ，オーバヘッドをほとんど増加させることはない.ファイル中のすべてのデータを読み込む場合，mmapを用いることと物理メモリ全体を一度に読み込むこととの性能差は，システム，ハードウェア，およびシステムが現在発生している他の場合によって大きく異なる可能性があるが，mmapはほぼつねに良い.
原則として、各ページへのアクセスはページエラーを招き、システムはより多くのディスクの要求を必要とするため、より多くのオーバヘッドが必要となる。しかし，実際には，オペレーティングシステムはこれを非常に積極的に最適化し，特に最も一般的な順序アクセスの場合には，同様に現実には，コンテンツ全体をメモリに読み込むことは依然として大量のページ誤りを招く.ランダムアクセスに対しては，すべてのデータを物理メモリに置くことがつねに最良であり，mmapを用いても通常は良い.(ほとんどのユーザは、通常、ファイル中のすべてのデータに完全にランダムな順序でアクセスすることはない-通常、最もアクセス頻度が高いのはファイルのいくつかの部分であるので、オペレーティングシステムは、これらのページを物理メモリに保持するために最善を尽くすであろう)。したがって、FITファイル(またはディスク上の大部分の大部分のデータ)を読み取る最も一般的な場合には、これは最適な選択であり、特に一時ユーザのためには、デフォルトで有効である。
一方，CFITSIO/≡fitsio``はmmapやページキャッシュなどの技術が存在するとは仮定していない.そこで，独自のI/OバッファLRUキャッシュを実現し，ディスクから読み出したFITファイルの部分をFITSで有名な2880バイトブロックサイズでメモリに格納する.I/Oバッファの使用量は大きく，特にヘッダをメモリに保存するために用いられる.大規模なデータ読み取り(例えば、ファイルから画像全体を読み出す)については、 does キャッシュを迂回して，ディスクからユーザが提供するメモリバッファを直接読み込む.
しかし，CFITSIOがファイルから直接読み出した場合でも，mmapを用いた場合よりもはるかに効率が悪い.一般に、オペレーティングシステムがディスクからファイルを読み出すとき、それは、これらの同じページに後続してアクセスする際に、後続の高価なディスク読み取りを必要としないように、物理メモリ(そのページキャッシュ内)に可能な限り多くの読み出しコンテンツをキャッシュする。Mmapを用いた場合にもこのような場合があり，ある場合にはディスクからRAMにデータをコピーしなければならないためである.異なる点は，mmapを用いてデータにアクセスした場合，プログラムがそのデータを読み込むことができる点である. 直接. オペレーティングシステムのページキャッシュから取り出す(それのみが読み取られる限り).一方，ファイルからローカルバッファ(Fread())にデータを読み込む場合，データはまずページキャッシュに読み込まれ(存在しなければ)，ページキャッシュからローカルバッファにコピーされる.したがって、読み出し毎に少なくとも各ページ読み出しに対して1つの追加のメモリコピーを実行する必要がある(ファイルが大きく、キャッシュからページを削除する必要がある場合には、大量のページが必要となる場合がある)。
CFITSIOのユーザAPIは、通常、ユーザに十分な大きさのメモリバッファを割り当てさせることによって、読み取りたい画像/テーブル(または少なくとも興味のある部分)を保存することによって動作する。割り当てられるべき適切な空間量を決定するために使用されることができるいくつかのブースタ関数がある。そして、CFITSIOはバッファへのポインタを入力し、すべての読み出しを処理し(一般に上述したプロセスを使用して)、その結果をユーザバッファにコピーする。大規模読み出しの場合、ファイルからバッファに直接読み込みますが、データがスケーリングされる必要がある場合、まずCFITSIO自身のバッファで停止し、再スケーリングされた値をユーザバッファに書きます(再スケーリングが要求された場合)。いずれにしても、これは、あなたのプログラムが一度にメモリに画像全体を保存することを望む場合、データサイズと同じくらいの多くのRAMを使用することを意味する。ほとんどのアプリケーションの場合、より小さいデータ部分を処理することはより良い(十分である)が、これは追加の複雑さを必要とする。一方、mmapを使用することは、この複雑さをより効率的に管理することができる。
非公式的なテストはこの違いを証明した。このテストは、256 x 256、1024 x 1024、4096 x 4096、および256 x 1024 x 1024の4つの単純適合画像(うちの1つは立方体)上で実行された。各画像は、テスト前に生成され、ランダム化された64ビット浮動小数点値が充填されている。2つの方法を用いて類似したテストを行った astropy.io.fits そして fitsio それがそうです。各ライブラリの基本意味を用いてFITSファイルのハンドルを開き，ファイルのデータ配列全体をメモリ中の一時配列にコピーする(たとえば，画像をビデオバッファに転送する場合).上の astropy 試験はこう書きました
def read_test_astropy(filename):
with fits.open(filename, memmap=True) as hdul:
data = hdul[0].data
c = data.copy()
テストはLinuxシステム上のIPythonで行い、カーネルバージョンは2.6.32、6コアIntel Xeon X 5650 CPUはコアあたり2.67 GHz、RAMは11.6 GB、使用：
for filename in filenames:
print(filename)
%timeit read_test_astropy(filename)
どこだ？ filenames 上記で生成されたサンプルファイルのリストのみである.結果は以下のとおりである.
256x256.fits
1000 loops, best of 3: 1.28 ms per loop
1024x1024.fits
100 loops, best of 3: 4.24 ms per loop
4096x4096.fits
10 loops, best of 3: 60.6 ms per loop
256x1024x1024.fits
1 loops, best of 3: 1.15 s per loop
上の fitsio テストの結果は
def read_test_fitsio(filename):
with fitsio.FITS(filename) as f:
data = f[0].read()
c = data.copy()
これはまた、すべてのサンプルファイル上で循環的に実行され、以下の結果を生成します。
256x256.fits
1000 loops, best of 3: 476 µs per loop
1024x1024.fits
100 loops, best of 3: 12.2 ms per loop
4096x4096.fits
10 loops, best of 3: 136 ms per loop
256x1024x1024.fits
1 loops, best of 3: 3.65 s per loop
サンプルファイルは新しいランダムデータで書き換えられていることが明らかになるべきである astropy テストとFitsioテストのため，オペレーティングシステムのページキャッシュから同じデータを読み込むことはない.小さい(256 X 256)画像に対しては，Fitsioの方がはるかに高速であり，この場合，見出しを解析する時間が支配的であるからである.前述したように，これはCFITSIOでははるかに速い.しかしながら、データサイズが増加し、ヘッダ解析が時間を支配しなくなるにつれて、 astropy.io.fits Mmapを用いた速度はmmapを用いた約2倍であった.先に説明したように，この違いは，データを読み出すために約半分のメモリコピーが必要であるためである.つまり、より広い基準テストは非常に面白いかもしれない。
それもそうではありません astropy.io.fits すべての状況でもっとよくできました。いくつかの場合、それは現在Fitsioによって吹き飛ばされている。後続の問題を参照してください。
なぜFitsioはFitsioよりもずっと速いのですか astropy 時計を見ることができますか。¶
多くの場合そうではありません astropy これはあなたが時計に何をしようとしているのか、時計にどのようなタイプの列があるか、いくつの列があるかにかかってしかし場合によっては fitsio 根本的に速いといえるが，これは主に“なぜFITS表から行を読むのがこんなに遅いのか？”_で説明されているためである.
原則として，テーブルは画素配列とあまり変わらない.しかしながら、画素とは異なり、配列内の各要素は、何らかの記録構造(例えば、2つの浮動小数点数、1つのブール値、および1つの20文字の文字列フィールド)である。64ビット浮動小数点数が配列内の8バイトレコードであるように、このような表中の行は、1次元行配列内の37バイト(前の例では)記録と見なすことができる。したがって，原則として，“”Asterpy.io.fitとfitsioの間にどのような性能差があるか？‘_“という質問に答える際に解釈されるすべてが表に適用され，他の配列に適用されるようになる.
しかし，FITSテーブルには多くの余分な複雑さがあり，ディスクから直接データをストリーミングすることを排除するのではなく，ディスク上のFITSフォーマットからユーザにとってより直接的に有用なフォーマットに変換する必要がある場合がある.一般的な例の1つは、FITがバイナリテーブルにおいてブール値をどのように示すかである。もう1つのはるかに複雑な例は可変長配列である.
“なぜFITS表からの行を読むのはこんなに遅いの？‘_”で説明されているように。 `astropy.io.fits 現在、特にユーザがテーブルからいくつかの行のみを読み出すことを望む場合には、そのいくつかの場合が可能な限り効率的に処理されていない。一方，Fitsioは一度に1行を表にコピーし，その行に対して必要な変換を行うことができるより良いインタフェースを持つ. only 行の列全体または複数列を取り出すのではなく、そこから取り出す。多くの場合 fitsio より良い性能を得ることは，多くの性能キー表操作の第一選択であるべきである.
Fitsioはまた、テーブルに対して効率的な同様のSQLの問合せを行うためのマイクロ言語(CFITSIOで実装されている)を開示している(ただし、単一のテーブルに限定される-接続または同様のものはない)。この形式をご参照ください CFITSIO documentation 場合によっては、使用よりも効率的な行選択を実行することができる numpy これは、行選択を実行するために中間マスクアレイを作成する必要がある。