Forced-photometry mode(s)

[WillHartley]

We've discussed this a few times, and I've promised to write up the issue for some time. Here it (finally) is.

A common approach to measuring multi-band photometry is to fit a model (e.g. bulge+disk or Sersic model) to an image, and to then fix the model parameters (effective radius, position angle etc.) and vary only the model amplitudes when fitting additional bands.

We currently cannot run in this mode in SX++. Software packages such as The Tractor and the ngmix-based fitvd (used in DES) are able to run in this manner, and so users will adopt those solutions instead of SX++ if that is their need. This mode may also help SX++ to be adopted as a component of the Euclid mission pipeline.

Example use cases:

1. I wish to use only a high-resolution image (e.g. from HST, Euclid) to fit a bulge+disk model, but I want model-based photometry from both space-based and ground-based data. A concern may be that the apparent effective radius of a galaxy is much smaller than the PSF as viewed from the ground, implying the need for an extremely accurate PSF for model fitting - that ground-based image might nevertheless be very high signal-to-noise. Fitting to only the space-based data for the model parameters side-steps the issue, to a degree.

2. I may want to know what the morphology of a galaxy is in a particular band, but have consistent colours across a range of bands.

3. I have many bands - e.g. the PAUS survey of 40 narrow bands, plus COSMOS medium and broad bands. Fitting so many bands simultaneously is possible, but requires a large amount of memory and processor time. A light-weight way to do it would be to fit the model to some privileged band / bands first, and then simply apply it to each of the remaining bands.

4. I wish to use SX++ measurements in a cosmic shear or GG-lensing analysis, and I don't want all of my bands to contribute to the galaxy shape measurement, but I do want photometry in all bands.

5. I want measurements for a set of sources that may or may not have detections in my target images - e.g., I have a list of sub-mm sources and want optical / near-ir fluxes for them. Or perhaps I have high-redshift galaxy candidates detected in JWST data and I want to measure optical fluxes at their locations.

These use cases break some of the assumptions about how SX++ runs, so might imply substantial development, maybe even a new mode of operation. There are two approaches that we've discussed so far, though I don't know how practical either of them are to implement.

A) Allow the user to upload a catalogue as part of the python config file. Allow the user to associate quantities in that catalogue with quantities they declare in the flexible model fitting - Sersic index, effective radius etc. - that are to be kept fixed during FMF. It could be required that this catalogue is based on the same detection image and detection configuration as the current run, so that the object IDs in the catalogue are uniquely and correctly assigned to the objects being fit. It would be up to the user to ensure that this is the case.

B) Detach the stages of detection and measurement. The user supplies sufficient information (positions, half-light radii etc.) in the form of a fits catalogue that the detection step can be bypassed, and proceed directly to measurement. This would perhaps amount to a "super-ASSOC" mode, where several parameters are supplied, not only positions. The meaning of each parameter would still need to be configured somehow.

[mkuemmel]

Just to add my two cents. In the use cases with a separation between the morphology bands and the photometry bands two subsequent SE++ runs could do the job, with the first one focusing on determining the morphology and then using the output in a second run for the photometry. Having more then one fitting in a single SE++ run (might also be Sersic and then Disk+Bulge on the same set of measurement images) has been discussed earlier but was estimated to be difficult.
Which makes B) the central issue that needs to be implemented. Choosing which parameters are static or get a prior or are fitted is already possible.

[marcschefer]

I identify two features we are missing:

The most critical feature being the ability to use values from the ASSOC catalog as initial/fixed values or priors.

Then being able to bypass the detection completely.

[mkuemmel]

The most critical feature being the ability to use values from the ASSOC catalog as initial/fixed values or priors.

Does that mean that right now the parameters of the models such as:
DeVaucouleursModel(x, y, flux, bulge_radius, bulge_ratio, angle)
all need to be either of type FreeParameter() or DependentParameter() right now?

[marcschefer]

@mkuemmel I'm not sure what you mean we have 3 types of parameters: ConstantParameter, FreeParameter or DependentParameter

The problem here is that we want to assign different values to them depending on the source, we can only do that with the lambda functions (like lambda o: o.get_radius()) So what we are missing is something like o.get_assoc_param(1)

[mkuemmel]

Right. I think I understand.