dcc-lab / polarization Goto Github PK

List all publications and public code on polarization APIs. Document features of each to help us narrow down what we want to include in our package.

(No coding involved, we will implement it later)
Sometimes it can be hard to display such information, particularly when you have multiple states to analyse. We need to find nice ways to visualise the polarization state(s) of a single photon, multiple photons, a large beam, a depolarized beam, etc.

Something like this could be nice to visualize propagation of a single vector.

I would also like a poincaré sphere showing the polarization state and how it evolved. Similar to this

We could also add interactivity and have a slider to view the polarization state at different point in the 'optical path'.

In testsJonesMatrix.py

We need to create proper documentation for the API with usage examples.

Starting with testRetarders in testsJonesMatrix.py

To allow for the design and visualisation of a path with multiple PS elements (polarized light source, waveplates, birefringent material, tissues, etc.).

And be clear about it. We can keep the convention currently used in the code as long as it is coherent everywhere, but we need to document it so the users know.

Here are the different valid conventions:

We need examples for basic polarization calculations.

There are some in the README (maybe deprecated), but we need them to be in seperate python files, inside an 'examples' directory.
The current file name examples.py is deprecated.

These usage examples will help to spot missing features.

Later we will also write more involved examples targetting OCT, dMRI, and other stuff.

Paired with good polarization visualisation to play with tissue properties (birefringence, thickness, scattering, optic axis) and light source.

We need to take the time to break down PS scattering and propagation in tissues in smaller cases to test it better.

Brainstorm a list of what a user aims to do with our software.

There seems to be a discontinuity in the fringes at interfaces. With the traditional processing we should see an undershoot in birefringence at interfaces. With the new simulated data we instead see an increase in intensity (overshoot) which probably indicates a discontinuity in the fringes.

We clearly see this discontinuity in the stokes vector at depth 220 and 300

Reconstructed birefringence

Stokes vector components for SV1 and SV2 (Without noise)

New simulation

Old Simulation

When a circularly polarized jones vector passes through a linear polarizer, isLinear returns False while it should be True...

The code as it stands provide the right answers (similar to MATLAB code), but is abysmally slow. It does not matter, this can be optimized.

There are several things that can be implemented to improve the performance considerably. As it stands, there are 3 lines of optimizations to follow:

1. The most important penalty is the redundancy of several calculations: because we made the choice to encapsulate the k-dependence in the JonesMatrix (i.e. the numerical values of certain matrices are not available until the JonesVector is known), then we often end up re-calculating a matrix for a given k over and over. The obvious optimization here is to cache the forward and backward matrices for a given k and simply return the computed values if it is for the same k. This all boils down to implementing a caching mechanism in computeMatrix for JonesMatrix, but also for MatrixProduct.
2. The object penalty. Going through objects for various calculations adds a performance penalty. For instance, @properties are slower than variables, __init__ takes time, etc... In some cases, this penalty is unacceptable. The best example is the internal calculation of the backscatterMatrix for a TissueLayer from all scatterers. It is better to explicitly compute a single matrix rather than take all the individual matrices from each scatterers.
3. Finally, there appear to be various performance enhancements possible with numpy versus other means of calculations but this looks less promizing.

This could be approached two ways:

1. Local caching mechanisms in objects
2. Global pre-flight optimization, pre computing everything.

Since the real problem is the redundancy of the calculations, I don't think the global strategy will blow the local strategy out of the water: the real gain is to compute everything just once, and the local/global strategies are two means to an end. I would much prefer a local optimization, but we may experiment with both.

Let's implement these changes individually in a unique branche for each optimization.
Let's always confirm the unittests are still passing, because the current branch gives results that are similar to the original MATLAB code.