Support for comps from AAVSO finder charts

[andreok]

Hello,

I would like to ask if it would be possible to use Astrosource with comps from AAVSO finder charts, instead of the standard identification of non-varying stars from the FOV to use as comps. Also, would it be possible to use the last two zeroed columns from the target file to flag the target(s) and comps, much like AstroImageJ does with its Ra/Dec list file (for AIJ, the 3rd column flags if the star is a target or a comp: (0,1) for target and (1,1) for comps)?

Thanks, Andre

[mfitzasp]

Howdy,

I think the more generic case is that you could provide a list of comp stars to astrosource to override the automatic detection of comp stars. This could be possible. However, the ensemble photometry algorithm (astrosource uses as many comp stars as it can - usually it settles down on the best 5-10 stars) in astrosource should far outperform any single AAVSO finder chart comp and realistically most fields do not have AAVSO finder charts (I just searched for a few of my recent targets and none of them provided comp stars in VSP). astrosource already pulls from APASS which is realistically where AAVSO comps are likely to come from. However, it would certainly be an interesting test to undertake! I can also imagine a variety of generic reasons beyond that you might want to provide or override comps or use an external calibration catalogue. I imagine it could be a flag --useprovidedcomps and --useprovidedcalibration and you provide a file listing your comps and a file with your calibrated magnitudes. If those options were available then you could provide a list of comp stars (including a list from AAVSO VSP) to astrosource. Do you have a set of data that you are intending to use that I could trial?

The target file only refers to actual targets that you are analysing, not the comps. The identified comps are output to other csv files while it is processing. Hence the targets and the comps are already segregated into separate csv files. The zeroed columns are there for a future reason actually. He says mysteriously.

Michael

[andreok]

Hi Michael,

I was testing it with your RX Eri data and the following AAVSO finder chart: AAVSO VSP finder chart for RX Eri But we could arrange a trial via your OSS Pipeline, if necessary!?

Thanks, Andre

[mfitzasp]

Hmmmm. This is not to do with the functionality of incorporating these two features into astrosource - which I will do anyway....

... BUT... from a scientific point of view, there are a few issues with that chart:

• What filters are you looking in? It looks like info is only available for B and V, what happens if you are looking in ugriz?
• The second and third star are from the Tycho catalogue and the V and B Tycho filters are NOT the same as the standard B and V filter so they aren't good calibration magnitudes
• The first star is from the Bright Star Catalogue which are largely derived from observations from the 1980s and earlier, pre-ccd with photoelectric photometry. It was very far out of date.
• The last two stars are from APASS, which is great - that is a modern up to date calibration catalogue that is actually already built into astrosource, which begs two questions: APASS also provides gri mags, where are they AND if I search on the coordinates of that VSP chart with the 0.5 degree radius it uses, I get 925 potential comparison stars from APASS10. Why would I only use those two when I could use nearly one thousand?

[mfitzasp]

I was getting a strange sense of deja vu from RX Eri.....

.... turns out it has already been studied with astrosource! :)

https://rtsre.org/index.php/atom/article/view/42

[mfitzasp]

Interestingly, astrosource - in this paper - automatically picked those two APASS stars for V, one of those stars for B but neither of the two stars for sdss-i and sdss-z. It picked the second tycho star for B, i and z (but would have got the magnitudes from APASS and Skymapper, not Tycho).

[mfitzasp]

Oh also, are you using the straight LCO fz files? I am happy to provide some OSS Pipeline files as well.

[andreok]

I think you probably recognize RZ Eri since I got the data from the Cookbook. ;-) I agree, this finder chart might not be an ideal case for analysis.

My interest is not in this star in particular, but in automation for PSF photometry. So I simply used the .psx files from the Cookbook to try it out.

[andreok]

I was looking for an existing pipeline supporting PSF photometry that could integrate to AIJ, to use with robotic telescopes, and I found the OOS Pipeline + Astrosource combination.

[mfitzasp]

Ahh :) The psx files are from the pipeline.

The best tool at the moment for the actual photometry is PSFEx (https://www.astromatic.net/software/psfex/), which is primarily a c-based linux command-line program which the OSS Pipeline uses. I would love it if someone made a cross-platform python version of it!

If you use the OSS Pipeline to astrosource route, there is no need for AIJ. I am happy to take a look at a dataset of fits files if you'd like to run some through the pipeline?

[andreok]

Yes, I'm still not using LCO, but I have data from another robotic telescope that I could upload for processing using the OSS Pipeline.

[andreok]

I would like to compare the results from PSFEx and the DAOPhot implementation from photutils, if possible. I have some issues with tracking and other systematics with this data that I would like to see if PSF photometry could help.

[andreok]

I have a custom pipeline in Python based on PSFEx that I run locally, but I think I'm going to need something else for LCO.

[mfitzasp]

So would I!

Send through a good dataset of fits files and we will see what pops out :)

OSS Pipeline also uses DAOPhot, the fortran linux command line version.... PSFEx seems to perform better. But I am intrigued!

Email me here: psyfitz@gmail.com and we will take a look!

[mfitzasp]

As in, you run locally on a linux machine?

[andreok]

Mac OS X. I'm also working on a version based on the DAOPhot from the photutils package, but it still in its early stages right now.

[mfitzasp]

From memory there is some fiddle faddling with the settings in both PSFEx(&SExtractor) and DAOPhot that infuriated me for a long time but that seems to be in the distant past for me. Email me and we will have a peek.

[mfitzasp]

Howdy!

I know it has been a while but I am close to the software being able to take a set of comparison stars. If so, it will check what images contain those comparison stars and reject other images.... that is sort of the reverse order to it's usual process but it has been natural to build it in with a few other things.

Michael

On Fri, Feb 11, 2022 at 9:40 AM Andre Kovacs @.***> wrote:

Mac OS X. I'm also working on a version based on the DAOPhot from the photutils package, but it still in its early stages right now.

— Reply to this email directly, view it on GitHub https://github.com/zemogle/astrosource/issues/19#issuecomment-1035604698, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEAHGNT5GMU6XNZZSMXGJ2TU2Q5EHANCNFSM5NGNVFEQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were assigned.Message ID: @.***>

[andreok]

Hello Michael,

That's great news.

I would like to ask, if possible, you instead reject comps not found instead of rejecting the whole image?

Thanks, Andre

[mfitzasp]

Well, thats the chicken and the octopus problem. It does actually try to reject comps first before rejecting the image (you will notice as it trundles by that it will reject stars far more often than images). But at some point in any set of data there is going to be an image that doesn't have comp X... so if you absolutely specify that it MUST only reject comps then the vast majority of sets of data will fail to process unless you have meticulously gone through and removed all images that don't have that comp already (which sorta defeats the purpose of a fast automated routine).

You can influence it's starting ratios though by using the --imgreject and --starreject ratios (set between 0 and 1) ..... astrosource's primary goal is to successfully process the image set you give it and if it has to crack a few eggs, whether they be chicken eggs or octopus eggs, along the way it will get rid of a comp or an image to be successful. It is a little ruthless like that, but it has your success in mind.

[mfitzasp]

The latest dev branch has the option --usecompsused which will use the file "compsUsed.csv" as the comparison stars. The thing that may make you unhappy is that the first thing it will do is go through and reject any images that don't have any one of the comparison stars within them. But I hope you come to realise that is a happy thing... because you cannot use an image that doesn't have one of your requested comparison stars in it.

If you don't know how to get the dev branch, I've attached a zip of the latest version -- just overwrite your astrosource file with these is the very brute force way of updating it!

astrosource_30May2022.zip

A sample comps used is below, the columns are RA, Dec, variability

155.09687010,-34.48382370,0.02702204 155.23925510,-34.43600500,0.03252753 155.06527620,-34.40121920,0.03473374 154.90547070,-34.41380080,0.03527344 155.02412990,-34.57886260,0.03554691 154.86404250,-34.52983710,0.03664750 155.32027640,-34.47538160,0.03687228

[mfitzasp]

oh, make sure you have --verbose on to see all the info