-
Notifications
You must be signed in to change notification settings - Fork 272
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
Drop support for CameraFrame in ImageProcessor #2141
Conversation
Codecov ReportBase: 92.75% // Head: 92.61% // Decreases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## master #2141 +/- ##
==========================================
- Coverage 92.75% 92.61% -0.14%
==========================================
Files 216 216
Lines 18050 17888 -162
==========================================
- Hits 16742 16567 -175
- Misses 1308 1321 +13
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
Thanks this will clean up a lot of redundant code! It's clear a lot of pieces need to be touched, so that is ok. The only consequence is that it means pointing corrections and the focal length are "baked in" to the DL1 parameters (assuming they are applied in the CameraFrame → TelescopeFrame transition), but I think that is a small price to pay for simplicity, and if the need arises we can add a way to correct them. |
You'll need to update some of the tutorials as well, as some were written before there was a TelescopeFrame I'm afraid! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since so much had to change, it may be a good idea for somebody to run an analysis (both regular reconstruction as well as muon analysis) on a large number of events and compare the results to the old version before we merge this. Just in case it introduces some unexpected typos.
There is a lot of code in |
Check out this pull request on See visual diffs & provide feedback on Jupyter Notebooks. Powered by ReviewNB |
af5140c
to
b4c3235
Compare
I checked the dl1 parameters for this branch and master for regular and for the muon analysis. Works fine. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks almost done to me. Some comments:
- If we do not support loading camera frame files, we need to put that in the changelog. I am fine with it, it is bound to happen at some point
- Strip notebooks
- Fix merge conflicts
b4c3235
to
1e3f59b
Compare
469b958
to
dd1b6d1
Compare
dd1b6d1
to
467be42
Compare
467be42
to
de32018
Compare
ctapipe/image/extractor.py
Outdated
@@ -1051,7 +1052,9 @@ def _apply_second_pass( | |||
# Apply correction to 1st pass charges | |||
charge_1stpass = charge_1stpass_uncorrected * correction[selected_gain_channel] | |||
|
|||
camera_geometry = self.subarray.tel[tel_id].camera.geometry | |||
camera_geometry = self.subarray.tel[tel_id].camera.geometry.transform_to( | |||
TelescopeFrame() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this might need some thought - we shouldn't be transforming the geometry for each event inside a calibration/image-extraction algorithm like this as that adds quite a bit of overhead. This algorithm does not care about the frame of the camera geometry or pointing corrections, so it should not require a transform.
Since we do eventually need to transform for the ImageProcessor, it may be better to do the transform outside of these algorithms, perhaps in the CameraCalibrator (which eventually should also apply pointing correcions), so that a single TelescopeFrame is available to all algorithms that need it. That would avoid re-doing the transform many times.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, this should be done inside the ProcessorTool
in setup
after writing out the subarray description but before setting up telescope components. The telescope components should just get a subarray with cameras in CameraFrame
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe add transform_camera_geometries
to SubarrayDescription
returning a new Subarray with transformed geometries
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is creating a whole new SubarrayDescription each time efficient? This was an issue I think we discussed a while back (need to find where): during analysis, the TelescopeFrame needs to be updated once per event for observations, and could be simplified to only once per run for simulations in fixed Alt/Az mode.
The TelescopeFrame requires:
- the latest pointing position, which changes in time in ICRS tracking mode (the default for most observations)
- pre-computed pointing corrections which could include not just a shift in RA/Dec, but also a rotation (this is not currently implemented, but will need to be done eventually)
Therefore where to store these frames is a question. Normally the SubarrayDescription is a static thing, but it could go there, but re-generating a whole SubarrayDescription might be wasteful if we could just update the info. Note that we don't want to re-generate neighbor pixel info in CameraGeometry
for each event, as that does not change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is creating a whole new SubarrayDescription each time efficient?
Not each time. Once in the tool in setup
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, sorry, forgot about pointing corrections.
But it stands: we could also do the pointing corrections in the transformation from / to TelescopeFrame to higher frames. That would actually make the most sense to me, since pointing direction is not important for the CameraFrame
<-> TelescopeFrame
transformation.
To me that means we should transform the whole subarray once to TelescopeFrame
and apply corrections in the transformation AltAz
<-> TelescopeFrame
, we don't need to change telescope frame for this, as the attributes needed for the transformation can be specified on the SkyCoord
as seen here:
ctapipe/ctapipe/visualization/mpl_camera.py
Lines 434 to 439 in 8a7a367
coord : `~astropy.coordinates.SkyCoord` | |
The coordinate to plot. Must be able to be transformed into | |
the frame of the camera geometry of this display. | |
Most of the time, this means you need to add the telescope | |
pointing as a coordinate attribute like this: | |
``SkyCoord(..., telescope_pointing=pointing)`` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remember there are in principle rotation corrections and maybe others, so you have to apply pointing corrections before Hillas parameterization (doing it while going to Alt/Az wouldn't work), as you need to have correctly shifted/rotated parameters before you do shower geometry reconstruction. But that can be solved when the ShowerProcessor is moved to TelescopeFrame later (right now e.g. HillasReconstructor supports both frames, but that's ugly).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
y=0.3 * u.m, | ||
width=0.05 * u.m, | ||
length=0.15 * u.m, | ||
x=0.2 * u.deg, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did you check that these images make sense when just changing meters to degrees?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I checked for the notebooks, I can recheck for all other files
@@ -80,8 +87,8 @@ def obtain_time_image(x, y, centroid_x, centroid_y, psi, time_gradient, time_int | |||
|
|||
""" | |||
longitudinal, _ = camera_to_shower_coordinates(x, y, centroid_x, centroid_y, psi) | |||
longitudinal_m = longitudinal.to_value(u.m) | |||
time_gradient_ns_m = time_gradient.to_value(u.ns / u.m) | |||
longitudinal_m = longitudinal.to_value(u.deg) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
variable names still contain the old units
@@ -0,0 +1 @@ | |||
Fix for Hillas lines in ``ArrayDisplay`` being wrong in the new ``EastingNorthingFrame``. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is that part of this PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think something went wrong while rebasing. It's not part of the PR, I thinks it's an old one
@@ -0,0 +1 @@ | |||
Replace usage of ``$HOME`` with ``Path.home()`` for cross-platform compatibility. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not part of this PR
superseded by #2396 |
Initially I wanted to remove the option to use the CameraFrame for calculating the Hillas parameters, but I had to change a lot of stuff and ended up removing the CameraFrame completely from the ImageProcessor.
fixes #2061