Default Photometry and Centroid Routes

[bensharkey]

Adding API routes for a default aperture photometry step, including centroided astrometry route

[mkelley]

I can't start up the service because one of the routes is missing:

connexion.exceptions.ResolverError: Cannot resolve operationId "catch_analysis_tools.app.services.subtract_median_background.perform_median_subtraction"! Import error was "No module named 'catch_analysis_tools.app.services.subtract_median_background'"

Also, could you pin the numpy version to <= 2.2? I couldn't start the service with 2.4 because of this error, that I don't understand:

connexion.exceptions.ResolverError: module 'numpy' has no attribute 'in1d'

AFAICT, in1d is not used in our code, but down-grading numpy solved the issue.

[bensharkey]

Done. Sorry that the perform_median_subtraction route wasn't tracked on my end!

[bensharkey]

FYI that the in1d problem seems to pop up in random places with astropy, I know I've seen it pop up a couple of time over the past year for me, it's often hidden somewhere in photutils.

[mkelley]

Ah, got it. So the right solution is astropy>=7.1.2 numpy>=2.0. Now I can start it up.

[mkelley]

I can run the API, but I get an error on the photometry and centroid routes because I don't have a .wcs file. Can the code use the FITS header by default? In addition, how will a user provide the WCS solution?

[mkelley]

Edit to reflect the fact that this is a windowed median filtering (as opposed to subtraction of the image median).

[mkelley]

Rename "photometry/circular_aperture"?

[mkelley]

Rename "background/median_filtered"? or similar?

[mkelley]

Rename "centroid"?

[bensharkey]

I can run the API, but I get an error on the photometry and centroid routes because I don't have a .wcs file. Can the code use the FITS header by default? In addition, how will a user provide the WCS solution?

The WCS file is created by the astrometry pipeline, and I had things built assuming the astrometric step had already been run. I'm happy to change those assumptions, and it would be ok to use the FITS header by default, but then I would need to look closer at the headers for the different surveys to figure that out. The convenience of using Yaeji's output file was that it standardized some parameters.

[mkelley]

The WCS file is created by the astrometry pipeline, and I had things built assuming the astrometric step had already been run. I'm happy to change those assumptions, and it would be ok to use the FITS header by default, but then I would need to look closer at the headers for the different surveys to figure that out. The convenience of using Yaeji's output file was that it standardized some parameters.

The user won't always run that calibration step, e.g., there's not much of a reason to do so with the PanSTARRS images, which are already distortion corrected.

[bensharkey]

The WCS file is created by the astrometry pipeline, and I had things built assuming the astrometric step had already been run. I'm happy to change those assumptions, and it would be ok to use the FITS header by default, but then I would need to look closer at the headers for the different surveys to figure that out. The convenience of using Yaeji's output file was that it standardized some parameters.

The user won't always run that calibration step, e.g., there's not much of a reason to do so with the PanSTARRS images, which are already distortion corrected.

Ok, should I then be relying on the zero points in the headers? That's the main thing that the calibration step provides from the photometry perspective. Will we need to have logic laid out for every filter type in the database? I'm just trying to get a handle on what level of complexity I should be building towards.

[mkelley]

Ok, should I then be relying on the zero points in the headers?

Yes, we will want that, too 🙏🏻

[bensharkey]

Ok, should I then be relying on the zero points in the headers?

Yes, we will want that, too 🙏🏻

Thanks for the back and forth - the reason why the wcs file is currently required by the photometry route is because that's where the zero point information lives, too. Is it a better approach overall for me to make the centroid and photometry paths agnostic about all of the header information? I could see a path forward where photometry works entirely in pixel-space (not RA/Dec) and in ADU space, without asking about anything other than the fits image itself.

Then, the translation to world coordinates and magnitudes would happen from other routes?

[mkelley]

Yeah, that could work. Converting flux to magnitudes is trivial. The WCS world<-->pixel conversions is harder, so could you make a new route to handle that?

[bensharkey]

Sounds good - those are already individual functions in the code (and one-liners in astropy), so it's just a the relatively simple matter of specifying input/output formats for the interfaces.

…

On Fri, Apr 24, 2026 at 12:25 PM Michael Kelley ***@***.***> wrote: *mkelley* left a comment (Small-Bodies-Node/catch-analysis-tools#34) <#34 (comment)> Yeah, that could work. Converting flux to magnitudes is trivial. The WCS world<-->pixel conversions is harder, so could you make a new route to handle that? — Reply to this email directly, view it on GitHub <#34 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQ2VQGGPICWC5PDBRMJIGZL4XOIPZAVCNFSM6AAAAACYEEADGCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DGMJUGY4TQNJZG4> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AQ2VQGCHHJLXT4WLX2SH3ET4XOIPZA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMZRGQ3DSOBVHE32M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KUZTPN52GK4S7NFXXG> and Android <https://github.com/notifications/mobile/android/AQ2VQGE3BW5DLNBYDNW5QQT4XOIPZA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMZRGQ3DSOBVHE32M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA>. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***>