search

LouisDesdoigts / dLux

Differentiable optical models as parameterised neural networks in Jax using Zodiax
https://louisdesdoigts.github.io/dLux/
BSD 3-Clause "New" or "Revised" License
52 stars 6 forks source link

Coordinates. #163

Closed Jordan-Dennis closed 1 year ago

Jordan-Dennis commented 1 year ago

Hi all, a source of constant pain has been access to the coordinates. It was decided that they would only be accessible from the Wavefront but we recently allowed StaticAperture to have pre-mature access to them. With the addition of a floating point parameter controlling the width of the soft region we again start to encounter the same problems (see #146).

In this case it is just the pixel scale that is needed, but this again raises the same questions as (technically) the information contained in the pixel scale and the number of pixels is equivalent to a set of coordinates in dLux. I have hacked together a solution but it is not jit friendly if you decide to change the parameter later (unlikely).

I think that there are many ways to skin the cat here, but I thought I would propose an alternative, which is a bit more technical. The singleton design pattern involves a class of which there can only be one initialised instance in the global scope at a time. Based on just that sentence you can see that it parallels our coordinate problems.

If all of our classes have a Coordinates instance and coordinates is a singleton class then Coordinates is accessible everywhere and defined once. I thought that singleton classes could not be implemented in python effectively but it turns out I was wrong.

Using metaclasses we can implement a Singleton interface for a Coordinates class. This might simplify some of our code and allow static to be a flag again instead of requiring additional classes to handle (technically it can be a flag at the moment, but it is better suited to being broken out into different classes).

Let me know what you think. This is not something I would want to address in #146, but would come later so there is no rush.

Regards

Jordan.

LouisDesdoigts commented 1 year ago

So I don't think this should be an issue for us because we should be fine having the softening parameter in units of pixels always. This allows init time generation of soft-edged apertures that can match run-time generated, however I would hazard a guess that soft-edged static apertures are not actually going to be needed and that hard edged should be fine. This should also work fine for dynamic apertures as we can trivially convert the pixel units to physical units at run-time generation.

Also I am not sure I follow this comment about needed conditionals? Maybe this is not the right place to discuss this though...

Jordan-Dennis commented 1 year ago

blank

Jordan-Dennis commented 1 year ago

I had a meeting with @LouisDesdoigts and we have decided that coordinates can sometimes be shared (without the singleton) but that we want to minimise this. When shared we are going with the garbage in -> garbage out philosophy. If you give two different pixel scales then you get rubbish, back.