This is closely related to #3, i.e. to the size of the PSF images from get_rec when PSFEx is run with PSF_SAMP different than 1.
The size of the PSF images (in number of pixels) is currently multiplied by PSF sampling (since bc2ef47).
Two concerns with this:
- Shouldn't the size be multiplied by 1/
PSF_SAMP (i.e. self->pixstep) instead?
- The PSFEx parameter
PSF_SIZE determines the size (in pixels) of the postage stamps in which the PSF model components are stored; I believe this is what determines the original size of the PSF images returned here, through self->masksize, before accounting for PSF sampling and handling odd/even number of pixels:
|
// and set the reconstruction size, using psf sampling factor. Make sure it's odd |
|
self->reconsize[0] = (long) ceil((float) self->masksize[0] * (float) psf_samp); |
|
if ((self->reconsize[0] % 2) == 0) { self->reconsize[0]++; } |
|
self->reconsize[1] = (long) ceil((float) self->masksize[1] * (float) psf_samp); |
|
if ((self->reconsize[1] % 2) == 0) { self->reconsize[1]++; } |
Suppose this parameter was fixed when running PSFEx, say at the same value as that chosen for the postage stamp sizes of a preceding SExtractor run, and PSF_SAMP was chosen smaller than 1. Wasn't the potential extra information (by the edges) already lost anyway?
Here is an example:
PSFEx is ran on a SExtractor catalog obtained from real data and containing stamps of 41x41 pixels, with different PSF_SIZE and PSF_SAMPLING values. Here are the PSF images we get from get_rec at an arbitrary location, with pixel values below 1e-12 shown in black:
Note images contain different number of pixels.
Beside the obvious artefacts due to small/slightly negative pixel values, the black areas show parts of the image where no information could be extrapolated.
(c) in both cases illustrates point 1.: the produced images are bigger, but contain no additional information. Conversely, images are smaller than they could be in both (a) cases.
And here are the same plots, for the actual (first) PSFEx component:
-
PSF_SIZE set to 41,41:

-
PSF_SIZE set to 83,83:

From my understanding, these components are the only sources of information used when running get_rec. Isn't the extra information PSFEx could provide already lost if it was run with excessively small PSF_SIZE values?
This is closely related to #3, i.e. to the size of the PSF images from
get_recwhen PSFEx is run withPSF_SAMPdifferent than 1.The size of the PSF images (in number of pixels) is currently multiplied by PSF sampling (since bc2ef47).
Two concerns with this:
PSF_SAMP(i.e.self->pixstep) instead?PSF_SIZEdetermines the size (in pixels) of the postage stamps in which the PSF model components are stored; I believe this is what determines the original size of the PSF images returned here, throughself->masksize, before accounting for PSF sampling and handling odd/even number of pixels:psfex/src/psfex.c
Lines 59 to 63 in 70843e6
Suppose this parameter was fixed when running PSFEx, say at the same value as that chosen for the postage stamp sizes of a preceding SExtractor run, and
PSF_SAMPwas chosen smaller than 1. Wasn't the potential extra information (by the edges) already lost anyway?Here is an example:
PSFEx is ran on a SExtractor catalog obtained from real data and containing stamps of 41x41 pixels, with different
PSF_SIZEandPSF_SAMPLINGvalues. Here are the PSF images we get fromget_recat an arbitrary location, with pixel values below 1e-12 shown in black:PSF_SIZEalso set to 41,41:PSF_SIZEset to 83,83:Note images contain different number of pixels.
Beside the obvious artefacts due to small/slightly negative pixel values, the black areas show parts of the image where no information could be extrapolated.
(c) in both cases illustrates point 1.: the produced images are bigger, but contain no additional information. Conversely, images are smaller than they could be in both (a) cases.
And here are the same plots, for the actual (first) PSFEx component:
PSF_SIZEset to 41,41:PSF_SIZEset to 83,83:From my understanding, these components are the only sources of information used when running
get_rec. Isn't the extra information PSFEx could provide already lost if it was run with excessively smallPSF_SIZEvalues?