-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RCAL-943: Add a step for creating multiband source catalogs #1485
RCAL-943: Add a step for creating multiband source catalogs #1485
Conversation
b7a2d26
to
28b33e5
Compare
8341427
to
58926be
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good. Let's touch base later this afternoon.
# background subtracted, have the same shape, and are pixel | ||
# aligned. | ||
# TODO: Do we need a separate background subtraction step | ||
# prior to this one? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The incoming L3s have been sky matched but not background subtracted; we probably do want to follow source_catalog and subtract a background.
) | ||
detection_var += convolve_fft( | ||
wht**2 * model.var_rnoise, kernel, mask=coverage_mask | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For discussion later, I've been staring at code like this in a different package recently as well, and maybe I am missing something important? But in my head you have something like:
signal(i) = sum_j PSF(i, j) * image(j) * weight(j)
variance(i) = sum_j PSF(i, j)^2 * sigma^2(j) * weight^2(j)
this code has the sigma^2 and weight^2 terms but not the PSF^2 term.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I saw in your doc file the kernel**2
term, but I have questions about it. Since kernel
is normalized to sum to 1, convolving the variance with kernel**2
does not conserve the variance. Convolution is a linear operation, so why would you want to square the kernel?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I claim that the detection significance image should be the local significance of the kernel at each location. This is a linear fit with a profile P. For a normal linear least squares problem, if the uncertainties were given by a covariance matrix C, the best fit fluxes would be:
x = (P^T C^-1 P)^-1 P^T C^-1 y
with variance
(dx)^2 = (P^T C^-1 P)^-1
The ratio of x / dx is the significance is x / (dx) = P^T C^-1 y / sqrt(P^T C^-1 P) . The term in the denominator with P^T P is the sum of the square of the PSF.
Similarly, I claim if you compute signal(i) = sum_j PSF(i, j) * image(j) * weight(j) and ask what the variance is, you likewise get a PSF^2 term that would correspond to convolving with the square of the kernel.
|
||
kernel_fwhm : float | ||
The full-width at half-maximum (FWHM) in pixels of the 2D | ||
Gaussian kernel used to smooth the detection image. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And maybe not for right now, but remembering my thinking... for a PSF, we want to use the appropriate PSF for each band, so a different FWHM for each band. For an extended object, it's less important, but technically we would want a true source profile convolved with the appropriate PSF.
# TODO: SED weights to be defined in the asn file for each | ||
# input filter image | ||
try: | ||
sed_weight = library.asn["products"][0]["members"][i]["sed_weight"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This does a single SED for right now, which makes sense, though we probably want to extend that.
|
||
# NOTE: I'm assuming here that all of the input images have been | ||
# background subtracted, have the same shape, and are pixel | ||
# aligned. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same shape and pixel aligned seems good to me for the DR catalogs. We do want to do background subtraction.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think a separate background subtraction step that saves the background-subtracted images may make sense. These background subtraction files are used in a couple places and I'd rather not keep them all around in memory (the are all needed initially to create the detection image) or recompute them.
# source_catalog will ultimately get these filter-dependent | ||
# values from a reference file based on EE values; | ||
# do we want filter-dependent aperture parameters for the | ||
# multiband catalog? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's discuss more. We did recently get aperture reference file schemas into roman_datamodels, but we don't have those files in CRDS yet. And given the modest range of aperture sizes we may prefer a handful of fixed sizes anyway.
} | ||
|
||
# TODO: do we want to save the det_img and det_err? | ||
det_img, det_err = make_detection_image(library, self.kernel_fwhms) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have talked about adding these to the current segmentation image product.
|
||
# this is needed for the DAOFind sharpness and roundness | ||
# properties; are these needed for the Roman source catalog? | ||
star_kernel_fwhm = np.min(self.kernel_fwhms) # ?? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have said we will compute these.
|
||
# save the segmentation image and multiband catalog | ||
# TODO: I noticed that the catalog is saved twice; | ||
# once here and once when the step returns |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, good catch. I think we hit this with the original source catalog and worked around it somehow, e.g., by only saving the segementation image in sae_base_results.
star_kernel_fwhm, | ||
self.fit_psf, | ||
detection_cat=det_catobj, | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just recording for my thinking---this does totally separate fits on each filter. e.g., for the PSFs, the centers will jump around a little from filter to filter, or for the krons, they will have separate shapes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, the Kron shapes are fixed by the Kron radius (with some scaling parameterization) and shape parameters, which are calculated only from the detection image. The initial PSF centers will also be from the detection image centroids (as will the circular aperture centers).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can also do forced PSF photometry with fixed positions (based on the detection image centroids).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, good, I had misunderstood this. This is good behavior for now.
58926be
to
f357b05
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1485 +/- ##
==========================================
+ Coverage 76.21% 76.68% +0.47%
==========================================
Files 115 120 +5
Lines 7639 7832 +193
==========================================
+ Hits 5822 6006 +184
- Misses 1817 1826 +9 ☔ View full report in Codecov by Sentry. |
I added a test_multiband_catalog regression test. We should update that with the new files after we adjust the step defaults for the background subtraction size. But here is the resulting log messages:
The deblending and multiple kernel messages we will use for demonstrating the requirements. |
ff78cd7
to
e86639e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's wait for regtests to finish to merge, but this looks good.
for kernel_fwhm in kernel_fwhms: | ||
img, err = make_det_image(library, kernel_fwhm) | ||
det_img = np.maximum(det_img, img) | ||
det_err = np.maximum(det_err, err) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't actually use det_err right now, so let's not change anything, but FWIW: the way I was thinking about this is that we want the SNR image and take the maximum of that, so one maximum. Conceptually I think we want the highest significance points, so probably if we wanted two images it would be something like
m = img / err > det_img / det_err
det_img[m] = img[m]
det_err[m] = err[m]
but let's not do anything now.
I'm going to wait to rebase this after #1457 is merge, but I suspect there could be conflicts. |
c23a1bd
to
8b50067
Compare
for more information, see https://pre-commit.ci
for more information, see https://pre-commit.ci
for more information, see https://pre-commit.ci
8b50067
to
e5ff765
Compare
Resolves RCAL-943
Closes #1486
This PR adds a new pipline step,
MultibandCatalogStep
, for creating multiband catalogs from a detection image, representing the combination of all bands. It also adds Kron photometry toSourceCatalogStep
(incl. the multiband catalog).I think this work falls under RCAL-873.
CC: @schlafly
Tasks
24Q4_B15
(use the latest build if not sure)no-changelog-entry-needed
)changes/
:echo "changed something" > changes/<PR#>.<changetype>.rst
(see below for change types)docs/
pageokify_regtests
to update the truth filesnews fragment change types...
changes/<PR#>.general.rst
: infrastructure or miscellaneous changechanges/<PR#>.docs.rst
changes/<PR#>.stpipe.rst
changes/<PR#>.associations.rst
changes/<PR#>.scripts.rst
changes/<PR#>.mosaic_pipeline.rst
changes/<PR#>.patch_match.rst
steps
changes/<PR#>.dq_init.rst
changes/<PR#>.saturation.rst
changes/<PR#>.refpix.rst
changes/<PR#>.linearity.rst
changes/<PR#>.dark_current.rst
changes/<PR#>.jump_detection.rst
changes/<PR#>.ramp_fitting.rst
changes/<PR#>.assign_wcs.rst
changes/<PR#>.flatfield.rst
changes/<PR#>.photom.rst
changes/<PR#>.flux.rst
changes/<PR#>.source_detection.rst
changes/<PR#>.tweakreg.rst
changes/<PR#>.skymatch.rst
changes/<PR#>.outlier_detection.rst
changes/<PR#>.resample.rst
changes/<PR#>.source_catalog.rst