You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
An issue in the HDU header information created by astropy.io.fits.GroupsHDU seen at least after v3.2.1 #9193
It seems that the recent updates in astropy.io.fits cause some bugs in the generation of the GroupHDU's header at astropy.io.fits.GroupsHDU.
Here, I would show what I got if I typed the example commands in the documentation. For this particular run, I'm using Python 3.7.3 in Anaconda 2019-7 installed from pyenv.
>>> import astropy
>>> astropy.version.version
'3.2.1'
>>> import numpy as np
>>> from astropy.io import fits
>>> imdata = np.arange(150.0).reshape(10, 1, 1, 3, 5)
>>> pdata1 = np.arange(10) + 0.1
>>> pdata2 = 42
>>> x = fits.GroupData(imdata, bitpix=-32,parnames=['abc', 'xyz', 'xyz'],pardata=[pdata1, pdata2, pdata2])
>>> hdu = fits.GroupsHDU(x)
>>> hdu.header
SIMPLE = T / conforms to FITS standard
BITPIX = 8 / array data type
NAXIS = 1 / number of array dimensions
NAXIS1 = 0
EXTEND = T
GROUPS = T / has groups
PCOUNT = 0 / number of parameters
GCOUNT = 1 / number of groups
Compared with the documentation, you can see that information of random parameters (PCOUNT, PTYPEX) is not correctely reflected in the header information.
I haven't seen this issue at least until version "3.1" which I am using in another pc. Thus, it should be attributed to recent updates in astropy.io.fits module after this version. Here are the outputs for this particular version, which are consistent with the documentation.
>>> import astropy
>>> astropy.version.version
'3.1'
>>> import numpy as np
>>> from astropy.io import fits
>>> imdata = np.arange(150.0).reshape(10, 1, 1, 3, 5)
>>> pdata1 = np.arange(10) + 0.1
>>> pdata2 = 42
>>> x = fits.GroupData(imdata, bitpix=-32,parnames=['abc', 'xyz', 'xyz'],pardata=[pdata1, pdata2, pdata2])
>>> hdu = fits.GroupsHDU(x)
>>> hdu.header
SIMPLE = T / conforms to FITS standard
BITPIX = -32 / array data type
NAXIS = 5 / number of array dimensions
NAXIS1 = 0
NAXIS2 = 5
NAXIS3 = 3
NAXIS4 = 1
NAXIS5 = 1
EXTEND = T
GROUPS = T / has groups
PCOUNT = 3 / number of parameters
GCOUNT = 10 / number of groups
PTYPE1 = 'abc '
PTYPE2 = 'xyz '
PTYPE3 = 'xyz '
I believe this is not a critical issue, but it may cause a bug for many (radio) astronomy software packages handling popular uvfits formats. Indeed, I saw this was causing a problem in some radio astronomy software packages. I would appreciate if the function can be fixed.
The header is however correct if you write the file:
>>> import io
...
>>> hdu = fits.GroupsHDU(x)
>>> hdu.writeto(io.BytesIO())
>>> hdu.header
SIMPLE = T / conforms to FITS standard
BITPIX = -32 / array data type
NAXIS = 5 / number of array dimensions
NAXIS1 = 0
NAXIS2 = 5
NAXIS3 = 3
NAXIS4 = 1
NAXIS5 = 1
EXTEND = T
GROUPS = T / has groups
PCOUNT = 3 / number of parameters
GCOUNT = 10 / number of groups
PTYPE1 = 'abc '
PTYPE2 = 'xyz '
PTYPE3 = 'xyz '
Thanks for prompt checking! Yes, I also saw that PCOUNT, GCOUNT and PTYPEs were indeed corrected when hdu or a hdulist including this hdu was written to a file.
However, in actual usage, I think people won't generally write a single hdu file in this stage. If one edits the header after this command by assuming that the correct information already inputted as in previous versions, there will be a still risk to cause an issue. It yet seems a minor bug to me, and I hope to see a fix so that this function works consistently with previous versions.
Activity
Temporal fix to avoid a potential error attribute to a bug in astropy…
MSeifert04 commentedon Sep 2, 2019
@kazuakiyama Thank you for the report. I quickly checked and can reproduce the issue.
MSeifert04 commentedon Sep 2, 2019
The header is however correct if you write the file:
which is also why the documentation did not fail.
It's a regression...
MSeifert04 commentedon Sep 2, 2019
There's another issue with FITS Groups that haven't been written to a file: #6688
kazuakiyama commentedon Sep 2, 2019
@MSeifert04
Thanks for prompt checking! Yes, I also saw that PCOUNT, GCOUNT and PTYPEs were indeed corrected when hdu or a hdulist including this hdu was written to a file.
However, in actual usage, I think people won't generally write a single hdu file in this stage. If one edits the header after this command by assuming that the correct information already inputted as in previous versions, there will be a still risk to cause an issue. It yet seems a minor bug to me, and I hope to see a fix so that this function works consistently with previous versions.
pllim commentedon Sep 2, 2019
@kazuakiyama , would you be interested to investigate the fix?
kazuakiyama commentedon Sep 2, 2019
@pllim Sure. Although I'm not sure if I can find the solution easily, I can take a look at source codes.
Update header when creating GroupsHDU from data (fix astropy#9193)
kazuakiyama commentedon Sep 12, 2019
@saimn Thank you very much! I confirmed that this indeed solved the issue.
Create Header instance when _BasicHeader fails
Create Header instance when _BasicHeader fails
Create Header instance when _BasicHeader fails
Create Header instance when _BasicHeader fails