Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Confusion with Camera Coordinates and Rotations #255

Closed
ParsonsRD opened this issue Nov 21, 2016 · 34 comments
Closed

Confusion with Camera Coordinates and Rotations #255

ParsonsRD opened this issue Nov 21, 2016 · 34 comments
Labels
bug help wanted

Comments

@ParsonsRD
Copy link
Member

Currently the default behaviour of the CameraGeometry class is to return the position of the camera pixels de-rotated by the camera rotation angle defined in sim_telarray. But I'm not really sure this is the right thing to do as the de-rotated position of the pixels isn't really useful for anything and in order to place the images in the nominal system you need to rotate the images back.

Would it not make more sense just to return the pixel positions in their regular rotated position to remove a step from the analysis?
@kosack
Copy link
Contributor

kosack commented Nov 21, 2016

That sounds reasonable. It was mainly done this way so that we could draw the camera correctly in the display, but if we have a proper coordinate transform system, we can just apply that before displaying (which makes more sense and is more general)

@mdpunch
Copy link

mdpunch commented Jan 5, 2017 •
edited
Loading

@ParsonsRD & @kosack
I don't understand why the pixel positions are changed at all!? At least for Hillas analyses, it's much simpler to determine them in camera coordinates, and then translate/rotate the Hillas parameters which require it (i.e. length + width are invariant).

Maybe model-type analyses need the pixel positions in sky coordinates? I would argue to keep separate paths for analyses which require pixel translations/rotations and the much faster analyses which don't.

@kosack
Copy link
Contributor

kosack commented Jan 10, 2017 •
edited
Loading

In this case, it's a quirk of the MC simulations, which are not in camera coordinates, but in some rotated camera coordinate system that is different for each camera (to keep the hexagons aligned I think), so you do still need to do one derotation from MC coordinates to Camera coordinates when you first read them. You could also track that extra rotation for the hillas params, but it would be quite confusing. We should however support rotating hillas params when going to other coordinate systems, to avoid lots of pixel transforms.

@ParsonsRD
Copy link
Member Author

Hi, yeah this 100 deg rotation factor can make things a bit difficult. To be honest I think it would be a little nicer if we draw the cameras, to do so in the true pixel positions in the camera. Which would be a bit nicer when comparing the image in a camera with a rotation to one without. That would require rotating the pixels in the drawing routine which may be a bit of a pain.

With regards to calculating the Hillas parameters in the current scheme (which I admit it is not optimal) it is as fast to convert all the pixel positions to the nominal system. But this will likely not be the case in the future so I will into the conversion of the Hillas parameter objects, this should be fairly simple I think.

@kosack
Copy link
Contributor

kosack commented May 18, 2017

Ok, I'm trying to fix the camera and pixel rotations, as well as writing out nicer cached camera files and I'm a bit confused as to the meaning of each.

If I understand correctly. the pixel positions in simtelarray output files should be the correct positions, assuming the camera is installed on the telescope (so no de-rotation should be done), even though we do it now. Therefore I should remove the derotation done when loading the CameraGeometry. What then is the real meaning of the camera rotation angle? Why is it there?

The pixel rotation angle is I guess the one needed to draw hexagons (or rectangles) aligned to the right frame. Is that correct? So it should be applied in the visualization routines.

So then, we have pixel_rotation applied in CameraDisplay, and camera rotation is not used at all (correct?)

@kosack
Copy link
Contributor

kosack commented May 18, 2017

Better asked: should the LST cam look like this:
lst_a

or this:
lst_b

@moralejo
Copy link
Contributor

moralejo commented May 18, 2017 via email

@moralejo
Copy link
Contributor

So probably the answer to your question is just: the second one! :)

Still, I think it would be nice to have camera displays with the option to show cameras in their "natural" orientation as viewed in parking position.

@ParsonsRD
Copy link
Member Author

ParsonsRD commented May 18, 2017 •
edited
Loading

But this does not seem to be how the LST camera is defined in the simulation configs.

 # Camera rotation angle [deg].
 # New Keyword: Requires 2012-08-21 or newer sim_telarray AND hessio[xxx].
 # Rotates the whole camera with all the pixels by the given angle.
 # Note that Hillas parameters are given in the 'de-rotated' system
 # to avoid portability issues of analysis programs.
 Rotate 100.893

When Konrad defines the pixel positions he does so, such that the flat size of the hexagon runs along the top of the camera. Then during the reading of the config file he rotates the position of each by 100 deg. So the actual position he uses in sim_telarray is the upper picture.

The camera rotation value is only there to make it easier for the rotation value to change and to define the points on a hexagonal grid.

@moralejo
Copy link
Contributor

moralejo commented May 18, 2017 via email

@mdpunch
Copy link

mdpunch commented May 19, 2017 •
edited
Loading

Trying to be a bit more precise, @moralejo when you say :

This means that, when pointed to zenith (from park), the x,y "hess" camera system matches Corsika's x,y.

you mean this for LSTs on CTA-North, which have parking position towards the North? So that when the telescope unparks to Zenith, "up" is pointing South.

For CTA-South, where the telescopes a parked pointing South, when the telescope unparks to Zenith then "up" is pointing North!

No?

@mdpunch
Copy link

mdpunch commented May 19, 2017 •
edited
Loading

I just checked the Corsika coordinate system, and in the original document by Heck, Knapp et al they give:

The coordinates in CORSIKA are defined with respect to a Cartesian coordinate
system with the positive x -axis pointing to the magnetic north, the positive y -axis to
the west, and the z -axis upwards.

... so it's not even true North (?!).

Simtelarray's coordinate system is maybe more relevant, but I can't find the description of this! Does anyone know it, or where to find it (or just ask Konrad!)

@moralejo
Copy link
Contributor

moralejo commented May 19, 2017 via email

@orelgueta
Copy link
Contributor

orelgueta commented May 19, 2017 •
edited
Loading

Hi,
Since this week I exchanged a couple of emails with Konrad about this, please allow me to paste here his explanation. (sorry for the long post).
For context, my original question referred to a left-handed coordinate system because of the effect of the camera "viewed from behind", as Abelardo mentioned.

The 3-D coordinate system is always right-handed.
x -> North, y -> West, z -> Up in the ground system.
At azimuth=0, zenith angle=0 all systems are aligned.
When you turn the telescope the "normal" way towards
the horizon, the x-axis points downwards, the z-axis
points in any case from (primary) dish towards camera,
x/y/z is still right-handed.

When you look from camera onto the dish (telescope
pointing to horizon), x points downward, y points right,
and z points towards you.
Same if you look from in front of the telescope onto
the backside of the camera.

When you look from the dish onto the camera, you
still have x downward but y is now seen pointing left
and z points away from you. (You see the x/y plane
from the backside, so to say - that is why you say
it is 'left-handed' - but x/y/z remains right-handed.)

The nasty trick to avoid a special case for the
reconstruction of dual-mirror-telescope data is that
pixels are reported as given but internally, at the
end of the ray-tracing, the x coordinate is flipped.
As this sounds counter-intuitive - you would expect
y flipped - you can also say that y was flipped and
then it was rotated by 180 degrees. I need to check
again but I think showing a dual-mirror-telescope
camera as you would see it from the front would
thus have the configured pixel x upward.

I usually present camera images in 'sky orientation',
such that increasing altitude is shown upward and
increasing azimuth (counted clockwise, astronomy!)
is shown to the right.
For single reflector telescopes this results in
x now pointing upward (mirror!) and y pointing right.
For dual-mirror telescopes with the internal flipping
it looks just like for single reflector telescopes.
(I know this does not help much the engineer standing
in front of the camera but that is what I do.)

In the second e-mail below, Konrad also added the attached plots of all the cameras.
demotest-off.pdf

Here is an example PS-plot from read_hess, in a single event
with four telescopes of each type (LST, MST-FC, MST-NC, SCT,
GCT-S, GCT-M, SST-1M, ASTRI, in that order) with pixel IDs
shown. You can also see the rotated x-y arrows (and rotated
pixel ID text) with the LST and MST-NC cameras.
The shower was simulated at zenith angle 20 deg, azimuth 180 deg
(i.e. coming from South), the telescopes were pointing to
zenith angle 22 deg, azimuth 176 deg, which is lower and to the
left of the shower direction. In the 'sky-oriented' camera images
all camera types are shown correctly - the shower direction is
to the right and above the camera center (for the LSTs actually
already outside the Fov).
The x-y arrows are shown in the system as configured, before
applying the rotation, and they are not aware of the internal
flip in the dual-mirror ray-tracing. The x/y coordinates that
I was talking of are, of course, after applying the camera-internal
rotation. If you stand in front of a camera in a single-reflector
telescope, they are all rotated 180 deg with respect to
what the read_hess plots show (think of the "Alt" arrow as "x"
after camera rotation and the "Az" arrow as "y" after camera rotation;
as explained before this "Alt"/"x" goes down and this "Az"/"y" goes
left for the guy standing in front of the camera).

My conclusion so far is that the FlashCam configuration file is
not properly oriented w.r.t. images of the prototype (cannot tell
if flipped upside down or rotated 180 deg) while
the SST-1M agrees with the TDR; all others are too symmetric to
tell if any of them is flipped or rotated by 180 deg, SCT, GCT, and
ASTRI even too symmetric to tell if they were thinking of
x in some horizontal direction. At least none where you can tell
(LST, both MSTs, SST-1M) is rotated by 90 degrees.

Karl, regarding your camera plot, if I am not mistaken, the second plot is correct up to a 90 degree rotation, as seen in the plot attached below.
pixelLayout-LST.pdf
This plot is taken from the report listing the sim_telarray parameters used to describe the LST - https://forge.in2p3.fr/projects/cta/repository/entry/ASWG/Simulations/MCModelDescription/trunk/reports/LST.pdf

@mdpunch
Copy link

mdpunch commented May 20, 2017 •
edited
Loading

Summary of Konrad's mail,

  • on the Ground, x is N, y is W, and z is up... but az is clockwise (from 0 at N)
  • in Sky coordinates, x is up / towards-zenith and y is right / towards-+-az

Everything else should follow, no (if we adopt Konrad's conventions)?

@mdpunch
Copy link

mdpunch commented May 20, 2017

But, this is maybe different from the conventions used by others. e.g. MAGIC? http://www.astro.uni-wuerzburg.de/wikineu/index.php/Coordinate_Systems where on the sky y is up and x is in the -ve azimuth direction. So, rotated 90° anti-clockwise w.r.t. Konrad's.

Is there a "CTA convention"?

@mdpunch
Copy link

mdpunch commented May 20, 2017

@GernotMaier could you tell us what the convention is in EventDisplay?

@GernotMaier
Copy link
Contributor

A definition of the CTA coordinate systems (or at least a documentation) is overdue since years. If one of you would volunteer?

Eventdisplay uses the definition from the grisudet detector simulations. Here the description from the manual:

We use three connected coordinate systems associated with the atmospheric shower, the ground, and the telescope, respectively. The shower record in the output of cherenkf.c describes the primary and associated photons in a coordinate system located at the telescope with the z-axis pointed down, the x-axis to the East, and the y-axis pointed South. Upon reading the shower record, grisudet immediately converts the shower and photon information to its standard ground coordinate system: z-axis pointed to the zenith, x-axis to the East, and y-axis pointed North. The third reference system, the reference system attached to the telescope, coincides with the standard ground coordinate system when the telescope is pointed to the zenith. For non-zenith primary showers, the telescope rotates its optical axis to point in a direction parallel to the shower line, first by a rotation about its z axis to place its y axis in the plane created by the vertical axis and the direction of the incoming primary. A following rotation about the new x axis (which is still in the horizontal plane) points the telescope z axis in the direction of the primary. The rotation point of the telescope is located on its optical axis a distance equal to the "telescope center offset" below the focal point of the telescope. The horizontal plane through the rotation point defines the ground location of the telescope.

(see http://www.physics.utah.edu/gammaray/GrISU/GrISU/Documentation/GrISUDet/gri_codeparameters.html)

@mdpunch
Copy link

mdpunch commented May 20, 2017 •
edited
Loading

Sigh... So everyone is different? Do I have this right, on the Sky Frame (perpendicular to optical axis):

  • Simtelarray/HESS/Konrad: x up, y right
  • MARS/MAGIC: x down, y left
  • EventDisplay/VERITAS/Gernot: x left, y up
    (I had forgotten that Whipple defines Azimuth from East, differently to standard)

Which means, we are free to do as we like!

This xkcd on standards is appropriate:
https://xkcd.com/927/

After reflection, I though that maybe the best would be to keep as close as possible to astropy conventions. Then working along these lines, I found this:
http://gamma-astro-data-formats.readthedocs.io/en/latest/general/coordinates.html
... which is the work from Christoph Deil & co.

Maybe we could adopt something like this as the CTA convention, so for the coordinates in the Horizon frame:

  • Azimuth zero at North, increasing towards East (clockwise)
  • x at North (corresponding to zero Azimuth)
  • z towards Zenith
  • y at West (to keep a right-handed system)

The consider a telescope pointing a Azimuth 0 degrees, Zenith 1 degree
... in the Camera Sky frame, then:

  • x points away from North (so on the Sky, up / towards Zenith / in positive Elevation direction)
  • y points away from West (so on the Sky, right / in positive Azimuth direction)

... which becomes the same as Konrad's convention, I think (z is then outwards towards the source).

So, in sum, x/y is the same as Alt/Az

Comments?

@moralejo
Copy link
Contributor

moralejo commented May 22, 2017 via email

@kosack
Copy link
Contributor

kosack commented May 23, 2017

Still, I think it would be nice to have camera displays with the option to show cameras in their "natural" orientation as viewed in parking position.

This all points to needing a common description of camera coordinates from the camera groups. Is there one? It should probably go in Jama somewhere if so. It would need to specify which way is "up" and "left", what angles are needed (e.g. a pixel rotation at least to show which way the hexagons of the winston cones align, for cameras that have them), and how to map to SimTelArray coordinates (which may not be the same definition?)

I'm still a bit confused as to the "natural" position: you said the LSTCam should have vertical edge lines, but in the second figure there are only horizontal ones, so is there still a mirroring of coordinates or a bad rotation?

@moralejo
Copy link
Contributor

moralejo commented May 23, 2017 via email

@kosack
Copy link
Contributor

kosack commented May 23, 2017

And it is also true in the simulation, when you consider the definition of Konrad's camera system.

Can you point me to where Konrad's system is defined and where the "natural" one is defined? I guess I'd prefer "natural" as the standard CameraSystem. I assume there is a flip in either x or y between the two? Are the coordinates defined as if looking at the camera, or through it? What about SC telescopes? We just have to be consistent and make sure the reconstruction treats it correctly.

@orelgueta
Copy link
Contributor

Perhaps the newer plots below from Konrad can help clarify the relation between the simulation coordinate system to the "natural" one.
https://www.mpi-hd.mpg.de/hfm/CTA/MC/Prod3/Config/showcam.pdf
The pixel IDs are given in the configuration files of sim_telarray. These configuration files were prepared by the instrument groups (except for the LST/NectrarCam, which were prepared by Konrad).
In order to plot the cameras in the "natural" coordinate system, using the pixel lists in the configuration files, I had to apply a 90 degree rotation. In addition, for 1M telescopes, I had to flip the y-axis. See plots in the file below.
pixelLayout.pdf

@mdpunch
Copy link

mdpunch commented May 23, 2017

Can you point me to where Konrad's system is defined and where the "natural" one is defined? I guess I'd prefer "natural" as the standard CameraSystem. I assume there is a flip in either x or y between the two? Are the coordinates defined as if looking at the camera, or through it? What about SC telescopes? We just have to be consistent and make sure the reconstruction treats it correctly.

If we just have look at the sky, and forget about cameras, then everyone will know what AltAz axes are in the sky plane.
.^ Alt
.|
.|
.------> Az

Is this what you mean by "looking through the camera", Karl?

For a 1-mirror camera, everything on the sky becomes a mirror image (translation through the optical axis), so that on the camera we have, looking from the front to an image on the focal plane or on the lid:
.Az <----
. |
. |
. v Alt
... in which case, if Karl's idea of "Natural coordinates" are x horizontal to left, and y vertical up, then <x = -Az> and <y = -Alt> (where the input coordinates are given in Alt, Az order).

For a 2-mirror camera, I think it's just a double mirroring, so the camera looks like the sky if you stand in front of it (except you'll get in the way!). So <x = Az> and <y = Alt>.

So, maybe don't think of Konrad's coordinate system as xy, but as AltAz.

@moralejo
Copy link
Contributor

moralejo commented May 23, 2017 via email

@kosack kosack mentioned this issue May 23, 2017
Merged
@mdpunch
Copy link

mdpunch commented May 23, 2017

@orelgueta

In order to plot the cameras in the "natural" coordinate system, using the pixel lists in the configuration files, I had to apply a 90 degree rotation. In addition, for 1M telescopes, I had to flip the y-axis. See plots in the file below.
If we take the pixel lists to be in AltAz, then when we read them as x,y we have
^ Alt = x
|
|-----> Az = y
... then applying a 90degree rotation (anti-clockwise)
.....^ Alt = y
.....|
<---
-Az = x
... and finally flipping the y axis makes:
-Az = x
<---
.....|
.....v -Alt = y
...
... which is the same thing I said above.

So, turning by 90 and flipping y is the same as just making a mirror image through zero and then swapping the names of the coordinates.

@mdpunch
Copy link

mdpunch commented May 23, 2017 •
edited
Loading

@moralejo Abelardo

The x and y in Konrad's system are well oriented when you look at the camera from behind.

Not sure what you mean by "well-oriented".

In Konrad's system, the first coordinate is on the vertical axis, which if you call it x is not, I think, what Karl means by "Natural"

These discussions of coordinate systems don't go very well by this forum, I think, it would be much easier if we were all in front of a whiteboard!

@moralejo
Copy link
Contributor

moralejo commented May 23, 2017 via email

@kosack
Copy link
Contributor

kosack commented May 23, 2017

Ok, thanks this clears things up a bit (and points out the confusion!). In any case, we discussed that the CameraGeometry or CameraDisplay needs a way to specify the coordinate system, so we can display images in various systems (reconstruction "nominal", telescope "sky" coordinates, etc), so we can certainly add a new system (or systems) to describe all the ones we would like to be able to show. the current "CameraSystem" is the SimTelArray one, but we can add one for these flipped systems as well, along with transfroms between them. Then in the CameraGeometry we can just change pix_x, pix_y into a astropy coordinate array with the appropriate system.

@kosack
Copy link
Contributor

kosack commented May 23, 2017

@AMWMitchell this may be something that could be useful to standardize in the PO: a list of coordinate systems with an official name "CameraSystem", "NaturalCameraSystem", or whatever, and their definitions:

  • reference point of center
  • x and y axes directions
  • dimensionality (2d, 3d)
  • cartesian or spherical
  • default unit (m, deg)

Just the camera and ground coordinates are a good starting point, and then up through sky coords as well.

@kosack kosack changed the title Rotation of pixel positions in camera.py Confusion with Camera Coordinates and Rotations May 23, 2017
@kosack kosack mentioned this issue May 23, 2017
Closed
@kosack
Copy link
Contributor

kosack commented Oct 6, 2017

It was pointed out at the last workshop that all cameras are currently rotated 90 deg with respect to their real parking positions. This seems to be due to the strange coordinate system used for the MCs, where the x-axis is up, so we should probably apply this as well to the base system.

@kosack kosack added the bug label Oct 6, 2017
@maxnoe
Copy link
Member

maxnoe commented Feb 20, 2019 •
edited
Loading

I just produced a PROD4 simtel file, doing this:

import matplotlib.pyplot as plt
from eventio import SimTelFile
from ctapipe.visualization import CameraDisplay
from ctapipe.instrument import CameraGeometry
import numpy as np
import astropy.units as u


f = SimTelFile('./gamma_test_prod4.simtel.gz')

keys = set()
geoms = []
for tel_id, desc in f.telescope_descriptions.items():

    cam = desc['camera_settings']
    key = cam['n_pixels'], cam['mirror_area'], cam['focal_length']

    if key not in keys:
        keys.add(key)
        print(key)

        if cam['pixel_shape'][0] == 1:
            pix_type = 'hexagonal'
            pix_rotation = '0d'
        elif cam['pixel_shape'][0] == 3:
            pix_type = 'hexagonal'
            pix_rotation = '30d'
        elif cam['pixel_shape'][0] == 2:
            pix_type = 'rectangular'
            pix_rotation = '0d'

        geoms.append(CameraGeometry(
            'telescope_{}'.format(tel_id),
            np.arange(cam['n_pixels']),
            cam['pixel_x'] * u.m,
            cam['pixel_y'] * u.m,
            cam['pixel_area'] * u.m**2,
            pix_type=pix_type,
            pix_rotation=pix_rotation,
            cam_rotation=-cam['cam_rot'] * u.rad,
            apply_derotation=True,
        ))


for geom in geoms:
    fig = plt.figure()
    ax = fig.add_subplot(1, 1, 1)
    d = CameraDisplay(geom, ax=ax)
    d.image = geom.pix_id
    d.add_colorbar()

    fig.tight_layout()
    fig.savefig('camgeom_{}.png'.format(geom.cam_id), dpi=200)

I get this:

camgeom_telescope_1
camgeom_telescope_5
camgeom_telescope_30

Is this what's expected?

@watsonjj watsonjj mentioned this issue Feb 20, 2019
Closed
@maxnoe maxnoe mentioned this issue May 17, 2019
Merged
@maxnoe maxnoe mentioned this issue May 27, 2019
Closed
@maxnoe maxnoe mentioned this issue Jun 6, 2019
Closed
@kosack kosack mentioned this issue Jun 7, 2019
Merged
@maxnoe
Copy link
Member

maxnoe commented Nov 25, 2019

I think this can be closed now, EngineeringCameraFrame and CameraFrame have documentation how they are defined and transformation is possible between the two.

@maxnoe maxnoe closed this as completed Nov 25, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug help wanted
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
7 participants
@maxnoe @kosack @GernotMaier @moralejo @ParsonsRD @mdpunch @orelgueta