I think the headline here should be that this new paper seems to prove the null hypotheses. As it says
A Bruehl-style calendar-day comparison gives
a descriptive post-test asymmetry (RR = 1.35, 95%
CI [0.91, 2.00]), but that statistic is tied...
Fixed! (2.44.6)
Also, ICYMI, there's now a "Satellte Mode" under the Camera Menu that works a lot better when pointing the camera more straight up or down.
Also, fixed that annoying judder when panning rotated camera.
The stars are fine. The satellite is just a bit off.
It's because it's a manually created TLE, made from visual observations. Based on that, the angular difference is perfectly acceptable.
A new paper has been submitted to ArXiv:
Independent Recovery of Vanishing Sources on POSS-I Photographic Plates Using Automated Source Detection and Cross-Epoch Matching by Zachary Hayes
Source:
https://arxiv.org/abs/2604.04810
PDF attached. I...
It seems to be a query around the tile center, not stars.
Vasco60 use the 90' as you have a default
search_radius_arcmin: float = 90.0
in class SpikeConfig: and cli_pipeline.py:610 does not override it to 1.5
No, it's not. It's reducing the PS1 bright star fetch from 35' to 3.0' (which should actually be 45' to cover the 60x60' tile). The 90' is still there.
But it seems in your code, the 5-arcsecond Gaia cone match is done before the PM back-propagation, and the back-propagation is then only applied to the sources that matched — i.e., the ones already eliminated as known Gaia stars. The sources that...
Your code also uses 90', is this to replicate their code?
https://github.com/jannefi/vasco60/blob/5dbf452/vasco/mnras/spikes.py#L117
class SpikeConfig:
rmag_key: str = "rMeanPSFMag"
rules: List[Any] | None = None...
I got some of the code running and experimented with visualizing the filtering.
What the pipeline is doing is finding all the blobs of light in the planes, and then rejecting ones that are known stars or that don't look like points of light...