Interpolation light profile and inverted coordinates

The 'INTERPOL' light profile does not accept coordinates arrays, like it is the case of the 'INTERPOL' mass profile. I think it instead considers that coordinates are positive going right for x and up for y.

This leads to the interpolated surface brightness map being incorrectly oriented when the coordinates were obtained through inverse=True (in utility functions), i.e. East is on the left instead of right.

[aymgal]

I agree this would make sense to support same arguments that coordinates-related classes. I’m not sure to come to a full implementation very soon, but I put it on my TODO list 👍

[sibirrer]

The grid_interp_x and grid_interp_y in the lens model module is also not optimal as it requires rectangular orientation. I’d prefer not having a mix of interpolation schemes defining a coordinate system with schemes defining an axis. The coordinate scheme is much more general and I hopefully can replace the lens model part with such a scheme too. So if you implement an new profile, I would prefer it to be one with inputs consistent with the PixelGrid(). It’s a bit more work but can ensure consistency. Then the difference to what I coded up would be:

• need to calculate the rotation angle and potential flipping based on the transformation matrix. Then you don’t even have to worry about the axes themselves as the user from outside the class. Does this make sense?