# Provide a (warning free) means of loading a FITS image plane with WCS

XMLWordPrintable

## Details

• Type: Improvement
• Status: Won't Fix
• Resolution: Done
• Fix Version/s: None
• Component/s: None
• Labels:
None
• Team:
Data Release Production

## Description

Since DM-2599 we issue one or more warnings when end-user code attempts to instantiate an Exposure or MaskedImage from a FITS file which does not contain the expected EXTTYPE metadata.

However, given the deprecation of DecoratedImage (see e.g. DM-3190), this means there's no supported way to load a single image plane with WCS from disk. (Likely, the end user would need to separately read image data and WCS, then combine them to form an Exposure).

This is a straightforward use case which we should support.

## Activity

Hide
Chris Walter added a comment -

I've also mentioned this bug to John. Perhaps the solution is to get that metadata into PhoSim files. But, we may also use DM to read data from other cameras so even then this might be an issue.

Show
Chris Walter added a comment - I've also mentioned this bug to John. Perhaps the solution is to get that metadata into PhoSim files. But, we may also use DM to read data from other cameras so even then this might be an issue.
Hide
John Swinbank added a comment - - edited

In part the confusion here stems from exactly what we mean when we talk about an an Exposure. Fundamentally, that's a data structure in the LSST stack which provides a combination of a data image, a mask, a variance plane and an appropriate WCS. Since it's convenient to be able to read and write these Exposure s from disk, we provide utility routines which can serialize them to FITS. The on-disk format of that serialization isn't well documented, and I'm not sure to what extent we'd regard it as a stable interface. In practice, though, there's nothing too obscure going on, and that means that when you pass a FITS filename to the ExposureF constructor, it does a pretty good job of figuring out what you actually want from the data, but it squawks a bit to let you know that something out of the ordinary is happening.

The much simpler interface which I think we do reliably support for reading external data from disk is to simply read it as a FITS image. That makes minimal assumptions about the structure of the data, and should work with basically whatever you throw at it. Once you've got the data in memory, you can then use it to create an Exposure (or a MaskedImage, or whatever). For example, I think you could avoid the warnings above by replacing your call to afwImg.ExposureF(fileName) with

 exposure = afwImg.makeExposure(afwImg.makeMaskedImage(afwImg.ImageF(filename))) 

Note that this will create an ExposureF which doesn't have a WCS attached – if you need that, you'll need to load it separately from disk and include it in the call to makeExposure. Ultimately, that could end up being a lot of typing. The goal of this issue is to provide a more convenient method.

Show
Hide
John Swinbank added a comment -

Given that it's getting on for four years since we created this ticket, and that (by my reading of the above; I forget the details of discussion four years ago) it's possible to satisfy the use case provided with a bit of extra typing, I propose to close this as “won't fix”. Please scream if you disagree!

Show
John Swinbank added a comment - Given that it's getting on for four years since we created this ticket, and that (by my reading of the above; I forget the details of discussion four years ago) it's possible to satisfy the use case provided with a bit of extra typing, I propose to close this as “won't fix”. Please scream if you disagree!
Hide
Chris Walter added a comment -

I can't remember this either

No screaming but while it is your brain, can you update the above comment to make it clear the suggested work around is (I think) your suggested code in the Jul 15 comment? That will help (probably me) in the future.

Show
Chris Walter added a comment - I can't remember this either No screaming but while it is your brain, can you update the above comment to make it clear the suggested work around is (I think) your suggested code in the Jul 15 comment? That will help (probably me) in the future.
Hide
John Swinbank added a comment -

Yes, I confirm that the suggested workaround was in this comment.

Show
John Swinbank added a comment - Yes, I confirm that the suggested workaround was in this comment .

## People

• Assignee:
Unassigned
Reporter:
John Swinbank
Watchers:
Chris Walter, Hsin-Fang Chiang, John Swinbank