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.

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.

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!

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.

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