Create a deblending observation transformer plugin

[dbenn]

The DATA-MINING section of the VSX FAQ web page https://www.aavso.org/vsx/index.php?view=about.faq links to a spreadsheet for deblending the magnitude to counter the effects of a nearby star.

In feedback on a data mining based revision of a star, Sebastian Otero suggested that this would make a useful VStar plugin.

An observation transformer plugin would be the way to go here.

[mpyat2]

A couple of years ago I created an improved spreadsheet for deblending that takes several contaminating stars. I think it would be useful if the plugin could also take several contaminating stars. The spreadsheet: https://1drv.ms/x/s!AvI6mlBbwVZZg24IMjafs7aM7RzU?e=wZadng

[dbenn]

I told Sebastian about this issue when I created it. I might point him to this comment.

[mpyat2]

Ok. Techically, its easy to calculate an effective contaminating magnitude for several stars, however it would be better to do it authomatically.

[BradWalter]

David,

I don’t understand how this is “easy” except when individual magnitudes of all but one of the stars are accurately known and your aperture contains the complete profiles of all the stars above the background. Otherwise, you need the magnitudes of all except one of the stars, the centroid locations of all the stars and point spread function in that region of the image so that you can calculate the portion of each star’s flux inside the measurement aperture. That doesn’t seem to be an easy calculation.

Brad

From: mpyat2 @.> Sent: Sunday, May 9, 2021 1:34 AM To: AAVSO/VStar @.> Cc: Subscribed @.***> Subject: Re: [AAVSO/VStar] Create a deblending observation transformer plugin (#147)

Ok. Techically, its easy to calculate an effective contaminating magnitude for several stars, however it would be better to do it authomatically.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/AAVSO/VStar/issues/147#issuecomment-835710460 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ACAV73L4UDFPRIOYYCZR64LTMYUENANCNFSM42WJBKCA .

[mpyat2]

"Easy" only if we assume that all contaminating stars are fully covered by the aperture, of course. However, sometimes it works more or less.

[dbenn]

And presumably in the data mining context (as per the description of this issue), that assumption may be necessary? Unless you are doing the photometry yourself the centroid and PSF won't be known. Right?

[mpyat2]

The spreadsheet mentioned in the issue uses the simple approach, it takes a magnitude of a contaminating star (this can be an 'effective' magnitude). The were cases in my practice when two or three faint stars were very close to the target so they almost fully lied inside the photometric aperture. Anyway, it would be useful to have such a plugin to make a crude estimation of real variability range of contaminated star.

[BradWalter]

If it isn’t your photometry, you need access to the images or the survey or paper needs to provid Psc data. In most cases you will have to data mine one of the surveys anyway to get magnitudes of the contaminating stars. Sloan, Pan STARRS and particularly Gaia (but Gaia has no transform to J-C B mag)provid good photometry for stars with very small angular separation. If you turn the Gaia layer on in Aladin and zoom the field to about 3 at min or less you will see what I mean, particularly if you pick a crowded field.

Sent from my iPhone

On May 9, 2021, at 09:07, dbenn @.***> wrote:

 And presumably in the data mining context (as per the description of this issue), that assumption may be necessary? Unless you are doing the photometry yourself the centroid and PSF won't be known. Right?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[dbenn]

I don't think I can add much more to this discussion just at the moment. Since the spreadsheet appears in the VSX FAQ and I created this issue after correspondence (re: period analysis and VSX update I was doing) with Sebastian in which using this was recommended and he said that a VStar plugin would be a nice alternative to the spreadsheet, perhaps we should have a discussion in email, here or in a forum with Sebastian?

[mpyat2]

I also think that a discussion with Sebastian is needed.

On Sun, May 16, 2021, 04:39 dbenn @.***> wrote:

Well, I don't think I can add much more to this discussion just at the moment. Since the spreadsheet appears in the VSX FAQ and I created this issue after correspondence (re: period analysis and VSX update I was doing) with Sebastian in which using this was recommended and he said that a VStar plugin would be a nice alternative to the spreadsheet, perhaps we should have a discussion in email, here or in a forum with Sebastian?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/AAVSO/VStar/issues/147#issuecomment-841751633, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKWWZCNGLPJM4PE46W5JV53TN4O65ANCNFSM42WJBKCA .

[mpyat2]

I know that in general, the problem is not easy, as @BradWalter described already. However, for practical purposes, with a high level of simplification, this problem arises while submitting data to the VSX. The practical approach is described here: https://www.aavso.org/vsx/_images/Manual.pdf. look for "A spreadsheet to correct magnitudes for light contamination from companions (deblending)". The referenced spreadsheet uses a very simple approach assuming that contaminating stars are completely covered by the aperture. Implementing such (simplified) approach would be useful anyway.

[dbenn]

In support of your last comment @mpyat2, there's a question about the level of abstraction at which this operation is to be carried out. I this case, we're operating at a level above the photometry processing level, where the simplification is to a very real extent, unavoidable. As you say, what we're really talking about is a plugin implementation of an existing spreadsheet method that is considered to have utility.