Ticket #302 (closed defect: wontfix)

Opened 11 years ago

Last modified 10 years ago

Image's and MaskedImage's getSubImage method should modify metadata

Reported by: becker Owned by: TimAxelrod
Priority: normal Milestone:
Component: fw Keywords: getsubimage, metadata, fw
Cc: Blocked By:
Blocking: Project: LSST
Version Number:
How to repeat:

not applicable


Header keywords such as DATASEC represent the "good" data sections in an image. When grabbing a subImage using the getSubImage methods, these metadata should be modified accordingly. As an example, an image with

DATASEC = '[33:2080,1:4612]'

will crash ds9 when you write out a subimage that is less than 33 pixels in the first dimension.

Change History

comment:1 Changed 11 years ago by ktl

We don't currently have columns in the database to persist the DATASEC metadata item. Should it be added, or can it be regenerated or ignored?

comment:2 Changed 11 years ago by TimAxelrod

  • Status changed from new to assigned

The getSubExposure() method of the Image class was modified on 12/20/07 [r3857] to change the CRPIX metadata in the subExposure. I posted the following comments to LSST-Data at that time:

Note further that I am not worrying about FITS keywords like DATASEC, which should also be different in the subImage. This process would have no real end, since FITS keywords proliferate without control. The method that is used in the Image class to keep track of offsets, _offsetRows and _offsetCols, is unchanged, and is not FITS specific. The coexistence of class variables and FITS metadata continues to be uneasy, as I think we all knew it would be. We need to think more about this for DC3.

I continue to think this is the right decision. There are quite a number of xxxSEC keywords that some IRAF packages generate and use, eg BIASSEC, TRIMSEC. None of them are part of the FITS standard. Each would require its own treatment (eg BIASSEC, which may need to be deleted if the subImage does not contain any of the original BIASSEC). If we take the road of incorporating IRAF semantics into our framework classes, it isn't clear that it has an end (or at least a nice one).

FWIW, I have been misled more times than I like to remember by ds9 silently showing only the part of the image given by DATASEC! It might be a better solution for us to just routinely clean all non-standard FITS keywords from our image metadata on read.

I will wait for further comments before taking any action on this ticket.

comment:3 Changed 11 years ago by becker

Either solution is OK with me - actually change the header keywords, or scrub them on read.

comment:4 Changed 11 years ago by TimAxelrod

  • Status changed from assigned to closed
  • Resolution set to wontfix

Obsoleted by design changes for image metadata, and reimplementation of Image classes by RHL.

comment:5 Changed 10 years ago by robyn

  • Milestone DC2 Support Class Implementation deleted

Milestone DC2 Support Class Implementation deleted

Note: See TracTickets for help on using tickets.