provide conversion functions between coordinate systems

[krachyon]

Figuring out how to go from the arc-second and magnitude coordinates with which the source templates are initialized to the position and counts on the detector are not straightforward.

In my opinion the following things would improve ScopeSim and flatten the learning curve a bit:

• A conversion function between arcseconds and pixel coordinates, given an instance of OpticalTrain
  • Ideally (x=0,y=0) as should correspond to the center of the detector grid.
  • Is there a sane way to provide an estimate of the source's flux on the detector given a filter, spectral type and magnitude?
  • Ideally a template that allows something like "I want a point source that will yield N counts, centered on this pixel" would help with debugging
• It would be nice to be able to easily inspect and easily change the overall properties of the OpticalTrain like the pixel scale, field of view, simulated detector area ...
• The available choices for things like filters and zoom mode should also be listable/selectable on OpticalTrain

[krachyon]

Hm, @astronomyk you seem to have had similar feelings about the magnitude<->flux conversions anyway ;) https://github.com/AstarVienna/HowManyBloodyPhotons

[hugobuddel]

There are pix2val and val2pix in https://github.com/AstarVienna/ScopeSim/blob/master/scopesim/optics/image_plane_utils.py , would those suffice? I have not used those functions directly myself, so I'm not sure.

I'm not sure what you mean with x=0 and y=0, if they are pixel coordinates, then they should be at the corner of the detector, not the center. If they are sky coordinates, then the layout of the detector array defines to which pixel they correspond. Instruments are free to define there detector layout, so it is not possible to force sky coordinates of (0,0) to any particular position on the detector array.

Note, in relation to #131, that to do any such conversion requires metadata about the projection that resulted in the pixel values. It makes sense to use the FITS standard to store that projection information, because ScopeSIM is not the place to reinvent that wheel. (This could also mean that it is not necessary to include the functions I mention / you want in ScopeSIM; I expect there would be suitable functions in astropy, but maybe those were overkill.)

But yeah, it can be difficult to figure out where things go. It took me a couple of hours to relate a src.shift() to changes on the detector. See https://github.com/AstarVienna/irdb/blame/daf0cf15d03261342ed77490beca862dfd88e06f/LFOA/tests/test_source_shift.py So there is definitely room for improvement.

As for the modes, and filters, they are quite well described in the instrument package:

• modes: https://github.com/AstarVienna/irdb/blob/master/MICADO/default.yaml
• filters: https://github.com/AstarVienna/irdb/blob/master/MICADO/MICADO.yaml

It would perhaps be nice to have some more interactive way to figure these things out, but I wouldn't think that is useful enough to focus on.

[krachyon]

There are pix2val and val2pix in https://github.com/AstarVienna/ScopeSim/blob/master/scopesim/optics/image_plane_utils.py , would those suffice? I have not used those functions directly myself, so I'm not sure.

I'm not sure what you mean with x=0 and y=0, if they are pixel coordinates, then they should be at the corner of the detector, not the center. If they are sky coordinates, then the layout of the detector array defines to which pixel they correspond. Instruments are free to define there detector layout, so it is not possible to force sky coordinates of (0,0) to any particular position on the detector array.

Well, you specify coordinates in arcseconds in the source templates and then you get an image back. I'd like to be able to easily relate the input values of the template function to the output values in the image plane. Either by having a function like as_to_pixel_values(x: as, y: as) -> (x: px, y:px) that I can call without having to worry about internal details like WCSs or by offering a way to specify the template in pixel-coordinates/counts as opposed to as/magnitude.

As for the modes, and filters, they are quite well described in the instrument package:

• modes: https://github.com/AstarVienna/irdb/blob/master/MICADO/default.yaml
• filters: https://github.com/AstarVienna/irdb/blob/master/MICADO/MICADO.yaml It would perhaps be nice to have some more interactive way to figure these things out, but I wouldn't think that is useful enough to focus on.

Ok, it's there alright but I'd consider this to be quite obfuscated: My journey through this was basically: I try following the examples, instantiate an OpticalTrain and then wonder where to go from there. Searching the docs for "mode" does not really get me anywhere, (e.g. https://scopesim.readthedocs.io/en/latest/use_examples/5-liners/A_rc_parameters.html). the attributes on the object also don't help because it's all a dictionary. I can't really figure out where that dictionary comes from at first because a bunch of defaults and configs get combined together. So then by chance I stumble upon the declarations in the yaml files. I don't really know how to select one of the declared options though, do I need to edit these files? Do I override some values? How do they interact with the global dictionary??? I can't figure out things from reading the code either, because nothing has explicit method arguments so I have no idea if the parameter I passed to a function or put into a dictionary did anything.

So, yeah this is less than ideal for someone who isn't intimately familiar with the internals and will actually make it really hard understand unless you explicitly document everything. Having explicit parameters/methods would do two things that are really desirable: Prevent code and documentation from drifting apart (nd have a basic form of self documentation, i.e. if I see the object has set_instrument_mode() I know that this is something that exists even if you don't mention it in the docs.