Closed wmwv closed 10 months 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!
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?
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?
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 window
s 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.
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.
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.
Thanks! That works.
Should this issue be closed then?
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.