search

cta-observatory / ctapipe

Low-level data processing pipeline software for CTAO or similar arrays of Imaging Atmospheric Cherenkov Telescopes
https://ctapipe.readthedocs.org
BSD 3-Clause "New" or "Revised" License
65 stars 269 forks source link

Confusion with Camera Coordinates and Rotations #255

Closed ParsonsRD closed 5 years ago

ParsonsRD commented 8 years ago

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 commented 8 years ago

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 commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

or this: lst_b

moralejo commented 7 years ago

In the LST camera one corner-to-corner line must be vertical, as you look at the camera from the mirror, with the telescope in parking position. From the HESS camera coordinate system (in which two flat sides of the LST camera are horizontal), this corresponds to x = -y_hess; y = -x_hess

On 18 May 2017 at 15:53, Karl Kosack notifications@github.com wrote:

Better asked: should the LST cam look like this: [image: lst_a] https://cloud.githubusercontent.com/assets/11677812/26205468/1a9d735a-3be2-11e7-95c7-2668308ecdf5.png

or this: [image: lst_b] https://cloud.githubusercontent.com/assets/11677812/26205473/1fa9ad0a-3be2-11e7-9681-ec5e88ceba83.png

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/cta-observatory/ctapipe/issues/255#issuecomment-302410414, or mute the thread https://github.com/notifications/unsubscribe-auth/ANghOkNQKF_UW-_rOBQZq32-zET21K6Vks5r7E1ygaJpZM4K3840 .

--

Abelardo Moralejo Olaizola Institut de Física d'Altes Energies Tel : +34 931641662 Fax: +34 935811938 Avís - Aviso - Legal Notice - (LOPD) - http://legal.ifae.es

-- Avís - Aviso - Legal Notice - (LOPD) - http://legal.ifae.es

moralejo commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

On 18 May 2017 at 17:36, Dan Parsons notifications@github.com wrote:

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.

​Konrad can clarify it, but I do think that the simulation is done properly, according to the LST design, i.e. "one corner up" as viewed from the mirror ​in park position. This means that, when pointed to zenith (from park), the x,y "hess" camera system matches Corsika's x,y. ​

--

Abelardo Moralejo Olaizola Institut de Física d'Altes Energies Tel : +34 931641662 Fax: +34 935811938 Avís - Aviso - Legal Notice - (LOPD) - http://legal.ifae.es

-- Avís - Aviso - Legal Notice - (LOPD) - http://legal.ifae.es

mdpunch commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

On 19 May 2017 at 10:24, mdpunch notifications@github.com wrote:

Trying to be a bit more precise, @moralejo https://github.com/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!

​Indeed :) To be more precise, it is "when you point to zenith going up from the Nort direction" (instead of "from park"). Sorry for that! Note also that the hess camera system hence corresponds to the camera as "viewed from behind".​

--

Abelardo Moralejo Olaizola Institut de Física d'Altes Energies Tel : +34 931641662 Fax: +34 935811938 Avís - Aviso - Legal Notice - (LOPD) - http://legal.ifae.es

-- Avís - Aviso - Legal Notice - (LOPD) - http://legal.ifae.es

orelgueta commented 7 years ago

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 commented 7 years ago

Summary of Konrad's mail,

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

mdpunch commented 7 years ago

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 commented 7 years ago

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

GernotMaier commented 7 years ago

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 commented 7 years ago

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

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:

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

... 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 commented 7 years ago

On 20 May 2017 at 18:27, mdpunch notifications@github.com wrote:

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

  • Konrad: x up, y right
  • Abelardo: x down, y left

I think Konrad's is right, ours not. For us, on the camera plane, as viewed from the mirror, x is right and y is up. This means that on the sky frame x is left and y is down.

  • 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)

​Ok, xyz is like Corsika's ​except for the difference between magnetic and geographic north.

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).

Comments?

​I think both Konrad's camera system (for its easy relation to Corsika's) and the one we use (for its intuitiveness ​as the natural system when looking towards the camera) are useful, and both should be defined. The latter is the natural choice when displaying single cameras, whereas the former is what you need when displaying e.g. an "array view" from above, showing the images in different cameras at the corresponding telescope positions. This is for single-mirror telescopes.

For double-mirror telescopes Konrad's camera system is such that images appear "as if" it was a single-mirror telescope, so that no change is needed in the transformations leading to reconstruction. Our system relates to Konrad's in the same way as for single mirror telescopes, x => -y, y =>-x, but I am not sure that "makes sense" in terms of camera access for double-mirror telescopes.

--

Abelardo Moralejo Olaizola Institut de Física d'Altes Energies Tel : +34 931641662 <931%2064%2016%2062> Fax: +34 935811938 <935%2081%2019%2038> Avís - Aviso - Legal Notice - (LOPD) - http://legal.ifae.es

-- Avís - Aviso - Legal Notice - (LOPD) - http://legal.ifae.es

kosack commented 7 years ago

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 commented 7 years ago

On 23 May 2017 at 10:16, Karl Kosack notifications@github.com wrote:

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?

The second figure is in the Konrad's coordinates we have discussed; the first one is simply a rotated system in which the pixel hexagons have two vertical sides.

​The LSTCam has two vertical camera sides​ "in the real world", e.g. in park position. And it is also true in the simulation, when you consider the definition of Konrad's camera system.

--

Abelardo Moralejo Olaizola Institut de Física d'Altes Energies Tel : +34 931641662 Fax: +34 935811938 Avís - Aviso - Legal Notice - (LOPD) - http://legal.ifae.es

-- Avís - Aviso - Legal Notice - (LOPD) - http://legal.ifae.es

kosack commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

On 23 May 2017 at 14:31, Karl Kosack notifications@github.com wrote:

I guess I'd prefer "natural" as the standard CameraSystem.

I assume there is a flip in either x or y between the two?

​The transformation is x' = -y; y' = -x

Are the coordinates defined as if looking at the camera, or through it?

​The x and y in Konrad's system are well oriented when you look at the camera from behind. ​In the camera system we use (in MARS) they are well oriented (x is right, y is up) when you look into the focal plane.

What about SC telescopes? We just have to be consistent and make sure the

reconstruction treats it correctly.

​Regarding reconstruction, for the simulated events the trick is done already by Konrad through the pixel coordinates. For SC cameras, he defines the pixel coordinates in the simulation such that for the reconstruction they can be treated exactly the same as if they were pixels of a single-mirror telescope (using a certain equivalent focal length). That is, if you plot a shower image as seen by an SCT and by an MST in the same location, using the pixel coordinates as given by simtelarray, the two images will be in the same area of the cameras and have the same orientation.

for displaying purposes, ​what we need is to know what SC telescope teams consider the natural coordinate system for their cameras.

--

Abelardo Moralejo Olaizola Institut de Física d'Altes Energies Tel : +34 931641662 Fax: +34 935811938 Avís - Aviso - Legal Notice - (LOPD) - http://legal.ifae.es

-- Avís - Aviso - Legal Notice - (LOPD) - http://legal.ifae.es

mdpunch commented 7 years ago

@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 commented 7 years ago

@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 commented 7 years ago

On 23 May 2017 at 16:24, mdpunch notifications@github.com wrote:

@moralejo https://github.com/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".

I mean that a 90-degree counter-clockwise rotation of the x-axis would bring it on ​top of the y axis. Sorry for the sloppy wording. ​

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"

​We agree. What we say is that the natural way of displaying camera images is the following:

x = -y_konrad y = -x_konrad

--

Abelardo Moralejo Olaizola Institut de Física d'Altes Energies Tel : +34 931641662 Fax: +34 935811938 Avís - Aviso - Legal Notice - (LOPD) - http://legal.ifae.es

-- Avís - Aviso - Legal Notice - (LOPD) - http://legal.ifae.es

kosack commented 7 years ago

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 commented 7 years ago

@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:

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

kosack commented 7 years ago

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.

maxnoe commented 5 years ago

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?

maxnoe commented 5 years ago

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