处理前后FITS文件大小不同

Question

处理后文件大小有问题...我编写了创建编辑图像的脚本...（从原始图像数据中扣除平场图像数据和暗图像数据）...这是代码Convert float NumPy array to big endian 我的问题是...在开始时我有适合文件大小为 2.8MiB 类型 >2i...处理后我有适合文件 11MiB 和类型 float64 我不知道为什么？ IDL 中有一些修复方法 http://www.exelisvis.com/docs/FIX.html 。在 Python 中，我使用 imgg=imgg.astype(np.int16,copy=False)。所以我得到了 2.8MiB 的图像文件，但只有白色和黑色...

有什么建议吗？

Answer 1

来自http://docs.astropy.org/en/stable/io/fits/appendix/faq.html#why-is-an-image-containing-integer-data-being-converted-unexpectedly-to-floats

如果图像的 header 包含可选 BSCALE and/or BZERO 关键字的 non-trivial 值（即 BSCALE != 1 and/or BZERO != 0 ), 那么文件中的原始数据必须根据公式重新缩放到它的物理值:

physical_value = BZERO + BSCALE * array_value

由于 BZERO 和 BSCALE 是浮点值，因此结果值也必须是浮点数。如果原始值为 16 位整数，则结果值为 single-precision（32 位）浮点数。如果原始值为 32 位整数，则结果值为 double-precision（64 位浮点数）。

如果您没有预料到这种自动缩放，它很容易让您措手不及，因为它在访问 HDU 的数据部分之前不会发生（允许像更新 header 这样的事情而无需重新缩放数据）。例如：

>>> hdul = fits.open('scaled.fits')
>>> image = hdul['SCI', 1]
>>> image.header['BITPIX']
32
>>> image.header['BSCALE']
2.0
>>> data = image.data  # Read the data into memory
>>> data.dtype
dtype('float64')  # Got float64 despite BITPIX = 32 (32-bit int)
>>> image.header['BITPIX']  # The BITPIX will automatically update too
-64
>>> 'BSCALE' in image.header  # And the BSCALE keyword removed
False

这样做的原因是，一旦用户访问了数据，他们也可能会对其进行操作并对其进行计算。如果数据被迫保留为整数，则会损失大量精度。所以最好在不丢失数据的情况下犯错，以一开始造成一些混乱为代价。

如果数据在保存前必须返回整数，使用ImageHDU.scale方法：

>>> image.scale('int32')
>>> image.header['BITPIX']
32

或者，如果使用模式='update' 和 scale_back=True 参数打开文件，原始 BSCALE 和 BZERO 缩放将自动 re-applied 到之前的数据保存。通常这是不可取的，尤其是从浮点数转换回无符号整数值时。但这在需要根据物理值的变化修改原始数据的情况下可能很有用。

为了完全防止重新缩放（有利于更新 headers——即使您不打算让代码访问数据，也最好在此谨慎行事），打开文件时使用 do_not_scale_image_data 参数：

>>> hdul = fits.open('scaled.fits', do_not_scale_image_data=True)
>>> image = hdul['SCI', 1]
>>> image.data.dtype
dtype('int32')

处理前后FITS文件大小不同

Size of FITS file different before and after processing

python

pyfits