provide means for ultimate pixel coordinate conversion

[dneise]

"There is a rich world of indices and coordinates right in front of your doorstep, just go outside and pick any."

No really .. there are so many coordinates in FACT, just have a look at the FACTmap
And in that the pixel chid is even missing, just like that index, which references to the order of trigger patches in the aux files dealing with trigger patches. And just like the index dealing with the bias patches. It is simply missing.

I'd like to provide a way for users to literally convert anything into anything here.

Say:

• position in camera plane, to pixel (any pixel coordinate)
• also position in camera plane to bias- or trigger patch
• pixel_id to central position of that pixel in the camera
• neighbours of a certain pixel

Maybe even something like:

• pixel to a viewing direction

[dneise]

There is a confusion about pixel coordinates in the camera plane, I think.

fact.pixel.get_pixel_coords does not even mention in which order the pixel coords come. In does however perform an important conversion of the (x,y) coordinates. It says:

Calculate the pixel coordinates from the standard pixel-map file
by default it gets rotated by 90 degrees clockwise to show the same
orientation as MARS and fact-tools

fact.pixel.pixel_mapping states which order the (x,y) coordinates come in, named here (pos_X, pos_Y).
But these are unusable for consistent plotting
Wouldn't it make sense to drop coordinates like pos_X and pos_Y, which are not useful at all and can be re-created from the coordinates output by get_pixel_coors.

Following this train of though, wouldn't it also make sense to simply attach the useful pixel coors to the pixel_mapping?

And finally wouldn't it be good if pixel_mapping was a pandas.DataFrame?

[maxnoe]

These functions all come from the really first days, where pandas wasn't in our toolkit. I think it's a good idea to migrate those to pandas.

To the rotation thingy: There are to different ways one can handle these: define new rotated coordinates or rotate only for the view. In get_pixel_coordinates I kind of did the first thing, in fact-tools we do the second.

[dneise]

I think one shouldn't think about it as "the rotation thingy", but about "what coordinates are people interested in?". There are these coordinates called pos_X and pos_Y in the file FACTmap111030.txt, but who needs them? They are coodinates in the unit of "pixel-center-distance" and in "how the camera was positioned in the lab during construction"-frame.

However, I think delivering multiple coordinates for pixels inside a DataFrame is extremely cheap. We can deliver them in all kind of coordinate systems, which might help somebody later to accomplish her research goal quicker. The only important this is: "It must be clear what coordinates do we deliver".

Even saying "(x,y) are the center coordinates of the pixels in the camera plane in mm" is not enough, since one needs to say where the x-axis and y-axis are actually pointing to.

[dneise]

So in short:

Let's kick what was called pos_X and pos_Y from the fact.pixel.get_pixel_dataframe() and put in the only meaningful positional coordinates for pixels, we can imagine:

x : center coordinate of a pixel in mm measured from the center of the focal plane. positive numbers point east, when FACT is parking.

y: center coordinate of a pixel in mm measured from the center of the focal plane. positive numbers point to zenith, when FACT is parking

[maxnoe]

I agree

[maxnoe]

For the other things you mentioned in the first post, we need hexagon grid tools. I started implementing them a while ago here: https://github.com/maxnoe/pyhexgrid

It already can do conversion from cartesian to hexgrid cube coordinates and neighbor finding.