Skip to content

Creating a HIERARCH card in a compressed image header fails (sometimes) #5313

Closed

Description

@MSeifert04

This is a follow-up on astropy/ccdproc#390.

It seems that under some unknown circumstances the header of the compressed image wouldn't allow a HIERARCH card to be appended (for example https://www.dropbox.com/s/4w7orq06ss2z5a6/kmts.20151202.030382.fits.fz?dl=0 hdu=1).

@crawfordsm has created a minimal example for which it fails in astropy/ccdproc#390 (comment) and he may have some more insights why this happens.

This can be avoided by reparsing the header with header = fits.Header(header) but it would be good to also find and fix the root of the problem.

Activity

  1. crawfordsm commented on Sep 9, 2016

    @crawfordsm
    Member

    I've been looking a little further in this, and can actually reproduce the error with an even simpler setup which hopefully points to what needs to be fixed:

    hdu = fits.open('kmts.20151202.030382.fits.fz')
    key = 'trim_image'
    short_name = 'trimim'
    card = (key, short_name, "Shortened name for command")
    hdu[3].header.append()
    hdu[3].header.append(card)
    

    This will replicate an error in which the last entry in the table is a blank. However, the primary error of this is within the function _keyword_from_index' inHeader` and can essentially be replicated even in a normal header by the following:

    short_name = 'trimim'
    card = (key, short_name, "Shortened name for command")
    card = Card(*card)
    hdu= fits.PrimaryHDU(np.ones((100,100)))  
    hdu.header.append()
    hdu.header.append()
    hdu.header.append(card)
    hdu.header._keyword_from_index(-1)
    

    Now, the main issue here is there is a list of keywords, _keyword_indices where all the keywords in that list have been normalized (essentially made upper case) before entering into that list. In a number of Header functions, prior to looking for the keyword, it will normalize the keyword like in append and contain before using it. However, it follows a different behavior in insert.

    I've just submitted a pull request to address these issues and hopefully return more consistent behavior.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions