Closed nabobalis closed 1 year ago
In GitLab by @markcheung on May 5, 2020, 14:27
added 1 commit
In GitLab by @wtbarnes on May 5, 2020, 22:30
Not opposed to this, but why do we need it? Does it make sense to define a WCS keyword for an image that does not have a world coordinate system?
In GitLab by @markcheung on May 7, 2020, 11:41
You don't have to think of these as WCS keywords. But they give the pixel size. It'd actually be good to check whether the input image to the deconv routine has CDELTs the same as the ones here. That would prevent someone from applying deconvolution on level 1.5 data.
Actually, am considering if we need to provide some other keywords, e.g., the following to tell the user the PSFs are centered at CRPIX[12] = (2049,2049).
psf = aiapy.psf.psf(wavelnth)
w = WCS()
w.wcs.crpix = [2048+1, 2048+1]
w.wcs.cdelt = [0.600758, 0.600758]
w.wcs.crval = [0.0, 0.0]
w.wcs.ctype = ["HPLN-TAN", "HPLT-TAN"]
w.wcs.cunit = ['arcsec', 'arcsec']
psfm = Map(psf, w)
In GitLab by @wtbarnes on May 7, 2020, 12:10
I don't think it makes sense to create a WCS and not think of them as WCS keywords. They have a specific meaning in terms of the FITS standard and I don't think that we should be re-purposing them.
If we wanted to stop people from applying the deconvolution to level 1.5 maps, isn't it enough to just check the level number keyword in the header and just an issue a warning (or raise an exception if we want to be really strict) if it is anything other than 1?
In GitLab by @markcheung on May 7, 2020, 12:31
I think WCS is less restrictive than I originally thought. See the example in section 6 of Greisen & Calabretta (2002) https://www.atnf.csiro.au/people/mcalabre/WCS/wcs.pdf If one fills in the appropriate keywords for WCSNAME (e.g. 'CCD FRAME') and CTYPE[12] (probably not HPLN-TAN and HPLT-TAN, though these are correct most of the time), we can meaningfully use WCS-keywords without deviating from the standard, and having to invent our own.
In GitLab by @wtbarnes on May 11, 2020, 20:12
It's worth noting that while this information may be useful, we're not actually returning it to the user. The output of aiapy.psf.psf
is still just a NumPy array. I guess aiapy.psf.filter_mesh_parameters
is a public function, but do we really expect users to use this? What is the context in which they would need the pixel size of the PSF?
In GitLab by @markcheung on May 11, 2020, 21:13
Yes. But this info can be exposed by the mesh info routine.
We can consider, perhaps later, whether the metadata and PSF should be returned togather as a Map.
In GitLab by @wtbarnes on Jul 15, 2020, 20:35
approved this merge request
In GitLab by @wtbarnes on Jul 15, 2020, 20:36
merged
In GitLab by @wtbarnes on Jul 15, 2020, 20:36
mentioned in commit f89d70e89979abae12cf3a170e5c9e33b552a6ad
In GitLab by @markcheung on May 5, 2020, 14:17
Merges pixelsizes -> master
Right now the mesh info does not actually give the pixel size.