mavdac 0.1.1__tar.gz

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
mavdac-0.1.1/PKG-INFO ADDED
@@ -0,0 +1,154 @@
1
+ Metadata-Version: 2.3
2
+ Name: mavdac
3
+ Version: 0.1.1
4
+ Classifier: Programming Language :: Rust
5
+ Classifier: Programming Language :: Python :: Implementation :: CPython
6
+ Classifier: Programming Language :: Python :: Implementation :: PyPy
7
+ Summary: MAVIS Differential Astrometric Calibrator
8
+ License: MIT
9
+ Requires-Python: >=3.8
10
+ Description-Content-Type: text/markdown; charset=UTF-8; variant=GFM
11
+ Project-URL: Source Code, https://github.com/jcranney/mavdac
12
+
13
+ # mavdac
14
+ MAVIS Differential Astrometric Calibration. This image processing pipeline is designed to ingest images acquired during astrometric calibration of (e.g.) [MAVIS](https://mavis-ao.org), and output the estimated distortion field derived from these images. The bulk of the pipeline is written in Rust, but the most useful functions and the CLI tool are wrapped in Python.
15
+
16
+ # Install
17
+ Eventually this will be pip installable, but for now, the easiest way to get going
18
+ is through `maturin` (which is `pip install`able). Clone this repo then build it:
19
+ ```bash
20
+ git clone https://github.com/jcranney/mavdac
21
+ cd mavdac
22
+ maturin develop --release
23
+ ```
24
+ If successful, you should now be able to run `mavdac` as per [Usage](#usage)
25
+
26
+ # Quickstart
27
+ The simplest usage of this software is by calling
28
+ ```bash
29
+ mavdac "./some/pattern*.fits"
30
+ ```
31
+ which tries to parse all images on disk matching the glob pattern argument, and prints the distortion basis-function coefficients to stdout. These are not very useful on their own, so a user can also provide a set of coordinates to evaluate the distortion functions:
32
+ ```bash
33
+ mavdac "./some/pattern*.fits" ./coordinates.txt
34
+ ```
35
+ In this case, `mavdac` prints the sampled distortion function values to stdout, which the user can (e.g.) cat to some output file:
36
+ ```bash
37
+ mavdac "./some/pattern*.fits" ./coordinates.txt > output.txt
38
+ ```
39
+
40
+ # Usage
41
+
42
+ There are a few ways to use `mavdac`, e.g.,:
43
+ - Through the Python CLI,
44
+ - As a Python module (part of another python-based application),
45
+ - As a Rust crate (part of another rust-based application),
46
+
47
+ Here, I assume you are a standard user, hoping to perform astrometric calibration of an optical system using the MAVIS Differential Astrometric Calibration technique. In that case, the workflow is as follows:
48
+
49
+ 1) **Collect images** of calibration source into `./some/dir/img_0*.fits`,
50
+ 2) **Define coordinates** in pixel space to evaluate the measured distortions, e.g., `./some/dir/coords`:
51
+ ```
52
+ 0,0,
53
+ 0,8,
54
+ 0,16,
55
+ 0,32,
56
+ ...
57
+ 4096,4088,
58
+ 4096,4096,
59
+ ```
60
+ 3) **Write a `grid.yaml` file**, specifying the geometry of the pinhole mask/calibration source.
61
+ 4) **Run `mavdac`** pipeline, specifying image filename pattern and coordinates filename path, piping `stdout` to some `./results` file.
62
+
63
+ Below we provide the requirements for each of the above tasks.
64
+ ### 1) Collecting images
65
+ - Each image must be saved in FITS format, as any of: `{u8, f32, f64, i32, u32}` type. Note that internally, all images are converted to `f64` upon loading.
66
+ - Each file must contain only a single 2D array in the primary HDU, and must contain the FITS header keywords:
67
+ - `XSHIFT`: shift in pixels along x-axis of the calibration mask for that exposure (from some nominal "home" position),
68
+ - `YSHIFT`: shift in pixels along y-axis of the calibration mask for that exposure (from some nominal "home" position),
69
+ ### 2) Defining coordinates
70
+ - The internal mavdac pipeline will fit a set of distortion basis functions (e.g., 2D bivariate polynomials) to the measured distortions. If you run the CLI without a second argument, e.g.:
71
+ ```bash
72
+ mavdac "./some/dir/imgs_*.fits"
73
+ ```
74
+ then the software will print some status updates to stderr, and eventually the coefficients of the fitted basis functions to stdout. This is mostly unusable, unless you write your own software to parse these coefficients. The intended usage is to provide a set of coordinates in pixel space, in which case you will get the distortions at those coordinates printed to stdout. E.g., with a coordinates file, `./some/coords`:
75
+ ```
76
+ 0,0,
77
+ 0,2000,
78
+ 2000,0,
79
+ 2000,2000,
80
+ ```
81
+ you can run:
82
+ ```bash
83
+ mavdac "./some/dir/imgs_*.fits" ./some/coords
84
+ ```
85
+ which will output:
86
+ ```
87
+ 0,0,0.0966850540113886,0.3300609989212976,
88
+ 0,2000,0.07252484678180265,0.007773570343281411,
89
+ 2000,0,0.004342546567941594,0.26372826456406706,
90
+ 2000,2000,-0.0018909241959087534,-0.0036487693998900166,
91
+ ```
92
+ to stdout. The expected usage is something like:
93
+ ```bash
94
+ mavdac "./imgs_*.fits" ./coords > ./out
95
+ ```
96
+ which cats only the stdout to a file, `./out`. I've spent a bit of time thinking about the simplest user interface with this software, and that is the best I can come up with, but if you have a better idea (perhaps inspired by experience using similar pipelines), please contact me or raise an issue in this repo.
97
+
98
+ ### 3) Writing a `grid.yaml` file
99
+ The coordinates of the pinhole grid are specified by a `grid.yaml` file, which currently only supports the "Hex" geometry. Here is an example:
100
+ ```yaml
101
+ !Hex
102
+ pitch: 133.33333333333334
103
+ rotation: 0.0
104
+ offset:
105
+ x: 0.0
106
+ y: 0.0
107
+ ```
108
+ All of these parameters are required, they are described below:
109
+ - `pitch`: distance between adjacent pinholes (in pixel units),
110
+ - `rotation`: orientation of hexagonal pinhole geometry (in radians),
111
+ - `offset`: shift of overall grid in pixel units, in `x` and `y` dimensions. Note that for `x=0` and `y=0`, there is a point in the grid at the exact middle of the image.
112
+
113
+ ### 4) Running `mavdac`
114
+ Finally, once you have:
115
+ - the images in `./some/dir`,
116
+ - a `grid.yaml` file,
117
+ - and optionally, a `./coords` text file,
118
+
119
+ you can run mavdac from the command line by:
120
+ ```bash
121
+ mavdac "./some/dir/*.fits" ./coords > ./out
122
+ ```
123
+ For a reminder, you can check `mavdac --help`:
124
+ mavis_acm/lab/inputs
125
+ ```
126
+ $ python -m mavdac --help
127
+ usage: process mavis differential astrometric calibrations [-h] pattern [coordinates]
128
+
129
+ positional arguments:
130
+ pattern glob pattern for matching fits files to use for calibration
131
+ coordinates file containing coordinates to map through distortions
132
+
133
+ options:
134
+ -h, --help show this help message and exit
135
+ ```
136
+
137
+
138
+ # Validating mavdac
139
+ All versions of mavdac < 1.0.0 are subject to breaking changes between any two releases. The tests and validations are being developed side-by-side with the software, so will become populated as the pipeline matures. It is envisioned that there will be 3 levels of validation for the software that should be re-satisfied for any release:
140
+ - unit tests,
141
+ - system tests, and
142
+ - hardware tests.
143
+
144
+ ## Unit tests
145
+ Unit tests for the rust package will be found within each rust module, e.g., within `./rust/src/lib.rs`, under `mod tests {...}`.
146
+
147
+ ## System tests
148
+ System tests for the rust + python package (e.g., the CLI), can be found in `./src/tests`. These will include tests that generate images with known distortions that are piped through mavdac, and the measured distortion field can be checked for quality.
149
+
150
+ ## Hardware tests
151
+ The final validation of this software package is through it's use on data acquired in a real optical system with introduced distortions. To demonstrate the challenges associated with this kind of validation - try to construct an experiment which can verify that the software works as intended. The following are the most direct:
152
+ - **measurement of known distortion**: By injecting a known distortion source into the optical path of a simple imaging system, one can estimate the level of distortion introduced by this optic, and compare it to the truth. The challenge here is finding some optical component that introduces a known distortion with some high level of absolute precision.
153
+ - **measurement of known calibration source**: By using a highly calibrated pinhole mask at the entrance of the optical system, one can perform a classical distortion calibration, measuring the observed spots and taking their offset as the "true distortion", then compare this with the recovered distortion using the differential calibration method. The challenge here is finding a calibration source which is accurate and stable down to 10s of nanometres. It is worth noting that the calibration object does not need to be the full pinhole grid, but could be a smaller set of sources with precise relative positioning that are moved around the field through different exposures.
154
+ - The third and most flexible method we considered allows the use of an **unknown distortion** with an **unknown calibration source** - that is, a calibration source with some unknown pinhole position errors, then to characterise the distortions with this mask. This will allow us to estimate the true positions of the pinholes (assuming that the mavdac pipeline works well). Then, we can insert the pinhole mask in a different orientation (e.g., rotated by 180 degrees), and measure the observed pinhole positions. These new pinhole positions should be the original estimated pinhole positions with distortion removed, rotated by 180 degress, plus the recovered distortion evaluated at the new pinhole positions. This should first be done without a strong distortion in the system, and then repeated with stronger distortions to assess the practical limitations of this method.
mavdac-0.1.1/README.md ADDED
@@ -0,0 +1,142 @@
1
+ # mavdac
2
+ MAVIS Differential Astrometric Calibration. This image processing pipeline is designed to ingest images acquired during astrometric calibration of (e.g.) [MAVIS](https://mavis-ao.org), and output the estimated distortion field derived from these images. The bulk of the pipeline is written in Rust, but the most useful functions and the CLI tool are wrapped in Python.
3
+
4
+ # Install
5
+ Eventually this will be pip installable, but for now, the easiest way to get going
6
+ is through `maturin` (which is `pip install`able). Clone this repo then build it:
7
+ ```bash
8
+ git clone https://github.com/jcranney/mavdac
9
+ cd mavdac
10
+ maturin develop --release
11
+ ```
12
+ If successful, you should now be able to run `mavdac` as per [Usage](#usage)
13
+
14
+ # Quickstart
15
+ The simplest usage of this software is by calling
16
+ ```bash
17
+ mavdac "./some/pattern*.fits"
18
+ ```
19
+ which tries to parse all images on disk matching the glob pattern argument, and prints the distortion basis-function coefficients to stdout. These are not very useful on their own, so a user can also provide a set of coordinates to evaluate the distortion functions:
20
+ ```bash
21
+ mavdac "./some/pattern*.fits" ./coordinates.txt
22
+ ```
23
+ In this case, `mavdac` prints the sampled distortion function values to stdout, which the user can (e.g.) cat to some output file:
24
+ ```bash
25
+ mavdac "./some/pattern*.fits" ./coordinates.txt > output.txt
26
+ ```
27
+
28
+ # Usage
29
+
30
+ There are a few ways to use `mavdac`, e.g.,:
31
+ - Through the Python CLI,
32
+ - As a Python module (part of another python-based application),
33
+ - As a Rust crate (part of another rust-based application),
34
+
35
+ Here, I assume you are a standard user, hoping to perform astrometric calibration of an optical system using the MAVIS Differential Astrometric Calibration technique. In that case, the workflow is as follows:
36
+
37
+ 1) **Collect images** of calibration source into `./some/dir/img_0*.fits`,
38
+ 2) **Define coordinates** in pixel space to evaluate the measured distortions, e.g., `./some/dir/coords`:
39
+ ```
40
+ 0,0,
41
+ 0,8,
42
+ 0,16,
43
+ 0,32,
44
+ ...
45
+ 4096,4088,
46
+ 4096,4096,
47
+ ```
48
+ 3) **Write a `grid.yaml` file**, specifying the geometry of the pinhole mask/calibration source.
49
+ 4) **Run `mavdac`** pipeline, specifying image filename pattern and coordinates filename path, piping `stdout` to some `./results` file.
50
+
51
+ Below we provide the requirements for each of the above tasks.
52
+ ### 1) Collecting images
53
+ - Each image must be saved in FITS format, as any of: `{u8, f32, f64, i32, u32}` type. Note that internally, all images are converted to `f64` upon loading.
54
+ - Each file must contain only a single 2D array in the primary HDU, and must contain the FITS header keywords:
55
+ - `XSHIFT`: shift in pixels along x-axis of the calibration mask for that exposure (from some nominal "home" position),
56
+ - `YSHIFT`: shift in pixels along y-axis of the calibration mask for that exposure (from some nominal "home" position),
57
+ ### 2) Defining coordinates
58
+ - The internal mavdac pipeline will fit a set of distortion basis functions (e.g., 2D bivariate polynomials) to the measured distortions. If you run the CLI without a second argument, e.g.:
59
+ ```bash
60
+ mavdac "./some/dir/imgs_*.fits"
61
+ ```
62
+ then the software will print some status updates to stderr, and eventually the coefficients of the fitted basis functions to stdout. This is mostly unusable, unless you write your own software to parse these coefficients. The intended usage is to provide a set of coordinates in pixel space, in which case you will get the distortions at those coordinates printed to stdout. E.g., with a coordinates file, `./some/coords`:
63
+ ```
64
+ 0,0,
65
+ 0,2000,
66
+ 2000,0,
67
+ 2000,2000,
68
+ ```
69
+ you can run:
70
+ ```bash
71
+ mavdac "./some/dir/imgs_*.fits" ./some/coords
72
+ ```
73
+ which will output:
74
+ ```
75
+ 0,0,0.0966850540113886,0.3300609989212976,
76
+ 0,2000,0.07252484678180265,0.007773570343281411,
77
+ 2000,0,0.004342546567941594,0.26372826456406706,
78
+ 2000,2000,-0.0018909241959087534,-0.0036487693998900166,
79
+ ```
80
+ to stdout. The expected usage is something like:
81
+ ```bash
82
+ mavdac "./imgs_*.fits" ./coords > ./out
83
+ ```
84
+ which cats only the stdout to a file, `./out`. I've spent a bit of time thinking about the simplest user interface with this software, and that is the best I can come up with, but if you have a better idea (perhaps inspired by experience using similar pipelines), please contact me or raise an issue in this repo.
85
+
86
+ ### 3) Writing a `grid.yaml` file
87
+ The coordinates of the pinhole grid are specified by a `grid.yaml` file, which currently only supports the "Hex" geometry. Here is an example:
88
+ ```yaml
89
+ !Hex
90
+ pitch: 133.33333333333334
91
+ rotation: 0.0
92
+ offset:
93
+ x: 0.0
94
+ y: 0.0
95
+ ```
96
+ All of these parameters are required, they are described below:
97
+ - `pitch`: distance between adjacent pinholes (in pixel units),
98
+ - `rotation`: orientation of hexagonal pinhole geometry (in radians),
99
+ - `offset`: shift of overall grid in pixel units, in `x` and `y` dimensions. Note that for `x=0` and `y=0`, there is a point in the grid at the exact middle of the image.
100
+
101
+ ### 4) Running `mavdac`
102
+ Finally, once you have:
103
+ - the images in `./some/dir`,
104
+ - a `grid.yaml` file,
105
+ - and optionally, a `./coords` text file,
106
+
107
+ you can run mavdac from the command line by:
108
+ ```bash
109
+ mavdac "./some/dir/*.fits" ./coords > ./out
110
+ ```
111
+ For a reminder, you can check `mavdac --help`:
112
+ mavis_acm/lab/inputs
113
+ ```
114
+ $ python -m mavdac --help
115
+ usage: process mavis differential astrometric calibrations [-h] pattern [coordinates]
116
+
117
+ positional arguments:
118
+ pattern glob pattern for matching fits files to use for calibration
119
+ coordinates file containing coordinates to map through distortions
120
+
121
+ options:
122
+ -h, --help show this help message and exit
123
+ ```
124
+
125
+
126
+ # Validating mavdac
127
+ All versions of mavdac < 1.0.0 are subject to breaking changes between any two releases. The tests and validations are being developed side-by-side with the software, so will become populated as the pipeline matures. It is envisioned that there will be 3 levels of validation for the software that should be re-satisfied for any release:
128
+ - unit tests,
129
+ - system tests, and
130
+ - hardware tests.
131
+
132
+ ## Unit tests
133
+ Unit tests for the rust package will be found within each rust module, e.g., within `./rust/src/lib.rs`, under `mod tests {...}`.
134
+
135
+ ## System tests
136
+ System tests for the rust + python package (e.g., the CLI), can be found in `./src/tests`. These will include tests that generate images with known distortions that are piped through mavdac, and the measured distortion field can be checked for quality.
137
+
138
+ ## Hardware tests
139
+ The final validation of this software package is through it's use on data acquired in a real optical system with introduced distortions. To demonstrate the challenges associated with this kind of validation - try to construct an experiment which can verify that the software works as intended. The following are the most direct:
140
+ - **measurement of known distortion**: By injecting a known distortion source into the optical path of a simple imaging system, one can estimate the level of distortion introduced by this optic, and compare it to the truth. The challenge here is finding some optical component that introduces a known distortion with some high level of absolute precision.
141
+ - **measurement of known calibration source**: By using a highly calibrated pinhole mask at the entrance of the optical system, one can perform a classical distortion calibration, measuring the observed spots and taking their offset as the "true distortion", then compare this with the recovered distortion using the differential calibration method. The challenge here is finding a calibration source which is accurate and stable down to 10s of nanometres. It is worth noting that the calibration object does not need to be the full pinhole grid, but could be a smaller set of sources with precise relative positioning that are moved around the field through different exposures.
142
+ - The third and most flexible method we considered allows the use of an **unknown distortion** with an **unknown calibration source** - that is, a calibration source with some unknown pinhole position errors, then to characterise the distortions with this mask. This will allow us to estimate the true positions of the pinholes (assuming that the mavdac pipeline works well). Then, we can insert the pinhole mask in a different orientation (e.g., rotated by 180 degrees), and measure the observed pinhole positions. These new pinhole positions should be the original estimated pinhole positions with distortion removed, rotated by 180 degress, plus the recovered distortion evaluated at the new pinhole positions. This should first be done without a strong distortion in the system, and then repeated with stronger distortions to assess the practical limitations of this method.
@@ -0,0 +1,18 @@
1
+ [build-system]
2
+ requires = ["maturin>=1.7,<2.0"]
3
+ build-backend = "maturin"
4
+
5
+ [project]
6
+ name = "mavdac"
7
+ requires-python = ">=3.8"
8
+ classifiers = [
9
+ "Programming Language :: Rust",
10
+ "Programming Language :: Python :: Implementation :: CPython",
11
+ "Programming Language :: Python :: Implementation :: PyPy",
12
+ ]
13
+ dynamic = ["version"]
14
+ [tool.maturin]
15
+ features = ["pyo3/extension-module"]
16
+
17
+ [project.scripts]
18
+ mavdac = "mavdac.__main__:__name__"