-
Notifications
You must be signed in to change notification settings - Fork 269
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Core algorithms for star trajectories analysis #2439
Comments
Hi @mexanick Thanks for bringing this up.
This seems to be a private repository in the CERN gitlab and CERN does not seem to let me login into the Gitlab with my external account anymore, this used to work some time ago. Could you move it somewhere where we can see it? E.g. the calibpipe group in the CTAO gitlab?
Given that you already have standalone package for a well-defined scope, what would be the advantages of integrating it into ctapipe itself compared to having the startracker module maintained by calibpipe and as a dependency of it?
This sounds more like it should go into
What does this extractor do? The job of the extractors in |
Hi @maxnoe, thank you for a quick feedback! I've made the repo public, you can browse it now. Considering the advantages of integrating it with the
This was actually my first choice, but I was a bit confused by the
Right, it extracts a variance image from waveform. It is indeed specific to calibration purposes (pointing and, eventually, PSF), so indeed, we can have it under |
The instrument module is for static information about the instrument like the location of pixels and which camera is attached to which structure, not for things that change with time, which I would call calibration. Here "static" means rarely updated, or updated at about the same frequency as large hardware changes or simulation model upgrades (e.g. swapping of a camera). It is the implementation of the InstrumentDescription data model (at least up to the SubarrayDescription). Currently the only "measured" quantity we include in the instrument module is the effective focal length. So the question is if the optical PSF is a similar quantity (something measured rarely when the instrument as a whole changes due to an upgrade), or something measured more often. Or is this more like the optical efficiency, which degrades in time, and should not be part of the instrument module? |
The PSF will be measured much more frequently than the focal length. Whether it will evolve over time is a different question... I can't answer it right now. The PSF model however should not change often, only its parameters. But indeed, it doesn't fit very well under "static" or "pseudo-static" instrument configuration. |
@kosack @maxnoe following your comments, can we agree on this implementation proposal?
|
Please describe the use case that requires this feature.
The reconstruction of the star positions and analysis of their apparent shape and trajectories can be used for pointing and optical PSF monitoring. Assuming the known optical PSF, one can reconstruct the star trajectories and deduce the telescope pointing without using auxiliary hardware, and vice versa, assuming precise knowledge of pointing, one can reconstruct the PSF by identifying the cluster of pixels observing the light from a point-like source (a star).
The analysis of the star trajectories has been implemented in a standalone startracker package and the results of the corresponding analysis of the LST-1 data are accepted to publication by Astronomy & Astrophysics.
Describe the solution you'd like
I propose to port the algorithms and containers of the
startracker
code to thectapipe
and implement the orchestration tools in the calibration pipeline of the dpps. Currently, the implemented code contains the following modules:startracker.analysis.image
: contains a set of containers and aStarExtractor
component, providing the methods to reconstruct star positions. Proposal: implement containers inctapipe.containers
, implementStarExtractor
inctapipe.image.extractor
. The output of theStarExtractor
is aStarImageCollection
container, similar to a DL1 container.startracker.analysis.fitter
: contains two classes, providing methods to fit the star trajectories and extract the pointing correction. Proposal: implement inctapipe.calib.pointing
startracker.analysis.psf_model
: contains a class, providing a PSF parametrization model. Proposal: implement inctapipe.calib.psf
Additional context
Current class diagram, extracted from a standalone implementation. Subject to a heavy refactoring during the porting.
The text was updated successfully, but these errors were encountered: