Autostronomy / AstroPhot

A fast, flexible, automated, and differentiable astronomical image 2D forward modelling tool for precise parallel multi-wavelength photometry
https://astrophot.readthedocs.io
GNU General Public License v3.0
87 stars 9 forks source link

How do I fit multi images with different WCS reference points? #120

Closed wmwv closed 10 months ago

wmwv commented 1 year ago

example use case

In general, if I have a set of images covering a region of sky, they won't have the same WCS crval reference points. What is a reliable and robust way of making AstroPhot happy with having the same internal model projection plane for these images?

An example in the documentation in Window (for translating windows) and in a Notebook would be good ways to share this example.

ConnorStoneAstro commented 1 year ago

If the different WCS have different crval points, then I think there's no perfect way to align them. But it should be fairly accurate to just pick one of them, or some average value and work from there, right? I actually kind of have an example like this already in the updated joint modelling tutorial. However, I agree it would be much more helpful for users to have a dedicated tutorial notebook just for this!

wmwv commented 1 year ago

I guess what I'm trying to tease out is that ideally we shouldn't have to align them. What the user wants is an analytic/noiseless model in sky coordinates that can then be projected to whatever WCS solution for each image.

My understanding is that what is implemented in AstroPhot is that models are instead defined in the projection plane. Is that correct?

ConnorStoneAstro commented 1 year ago

Hmmm, yes right now the models are defined in the projection plane. The current way that everything is expected to work is that all images are mapped into the same projection plane. Perhaps that's something that could change now that we have a better interface to world coordinates. Still, it would be pretty hard to have a solid footing for parameters other than position, like the position angle which isn't as easy to translate between coordinate systems.

Are there cases where you think it would be critical to have the ability to fit models using the world coordinates as the link instead of a common projection plane?

wmwv commented 12 months ago

Here's a concrete example I'm working on to add to AstroPhot-tutorials (and for my own interest). I want to model a SN+galaxy on some simulated Roman images. What should I do to adjust the transformations so that the transformation happen analytically rather than pre-warping the images to agree?

https://github.com/Autostronomy/AstroPhot-tutorials/blob/issues/2/tutorials/TimeVariableModels.ipynb

I've pushed a rendered version of the Notebook so you can easily read the WCS and windows without downloading several GB of images. In the future, when I finally submit to merge in the PR in that repo, I'll clear the rendered version from the branch history.

wmwv commented 12 months ago

Yes, these images use SIP, but the SIP correction is minor and it shouldn't be the issue here. Ignoring the SIP terms works fine as can be seen from the plotted image cutouts.

ConnorStoneAstro commented 12 months ago

Hmmm, I think the issue is arising when making the target images before getting the cutout. You need to pass the reference_radec to the target on creation. So to modify the relevant part of your notebook it would look something like:

target = ap.image.Target_Image(
        data=np.array(img, dtype=np.float64),
        variance=var,
        zeropoint=22.5,
        psf=psf,
        wcs=wcs,
        reference_radec=(coord.ra.degree, coord.dec.degree),
    )

Although this would require that coord is always passed.

AstroPhot will guess a reference_radec on creation of a target unless it is given explicitly. I really should have it throw an error if the image and window have incompatible reference_radec. However, the target[window] operation is called a lot during optimization so I would have to make sure that the check doesn't mess with performance. Generally Pytorch discourages including control flow in heavy calculations.

wmwv commented 12 months ago

Thanks! That works.

ConnorStoneAstro commented 12 months ago

Should this issue be closed then?