Uploaded image for project: 'Data Management'
  1. Data Management
  2. DM-3191

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

    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.

        Attachments

          Issue Links

            Activity

            Hide
            cwalter 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
            cwalter 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
            swinbank 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
            swinbank 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.
            Hide
            swinbank 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
            swinbank 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
            cwalter 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
            cwalter 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
            swinbank John Swinbank added a comment -

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

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

              People

              • Assignee:
                Unassigned
                Reporter:
                swinbank John Swinbank
                Watchers:
                Chris Walter, Hsin-Fang Chiang, John Swinbank
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Summary Panel