Add automatic laminography alignment tool

[hrobarts]

Changes

Add automatic laminography alignment tool.
Projection matching method to optimise laminography reconstruction by searching tilt and centre of rotation offset

• Bins projection data with coarse_binning and final_binning
• Reduces angles to Nyquist or angle_binning
• Searches a range of tilt and CoR defined by parameter_bounds starting with an initial guess initial_parameters.
• Reconstructs at each geometry guess, either reconstructs a full volume or a user defined reduced_volume
• Forward projects and compares to measured projections. Residual is real minus reprojected data, loss is high pass and Sobel filtered
• Minimises for tilt and CoR using the Powell method

Testing you performed

New demo script: TomographicImaging/CIL-Demos#280

Related issues/links

Checklist

• I have performed a self-review of my code
• I have added docstrings in line with the guidance in the developer guide
• I have updated the relevant documentation
• I have implemented unit tests that cover any new or modified functionality
• CHANGELOG.md has been updated with any functionality change
• Request review from all relevant developers

[hrobarts]

Comments from code review meeting

[hrobarts]

@gfardell I think I've addressed all the comments from the code review meeting and also added a test with the simulated data

[gfardell]

This will be a great tool.

My major comments are:

• Backend selection and compatibility

  • Consistency with FDK and CoR would be to accept a backend parameter
  • I know it's only astra for now but could it be written in a way that would extend it to tigre for free once #2238 is in?
  • A concern is that as ASTRA is GPL2, so we keep it as an optional import at runtime so the user is in control. This means code shouldn't silently depend on astra and it should be a user choice.

• Documentation and doc strings

  • Add a section in the documentation explaining the geometry and tested cases. Not everyone will have the same definition of the angle as "tilt" for example.
  • Internal methods should start with _ and need docstrings and clear parameter names.

• Memory use

  • We need to think about reducing and reusing buffers where we can, both in terms of peak RAM and not reallocating memory each iteration where we could reuse it.
  • For the acquisition and image data especially we need to be clear how many copies are used, this could be part of the documentation.
  • We need to balance the cost of storing results with recomputing i.e. when we filter, or for the reference volume.

Overall it looks solid and well structured. Let me know when you need me to look again/talk it through.

I have not looked at tests yet.

[gfardell]

Is scipy a required or optional CIL dependency?

[hrobarts]

It's in the run requirements but I'm not sure that's clear from the documentation

[gfardell]

Do we require the geometry to have angles in degrees?

[hrobarts]

No we update the rotation axis each time, we require the tilt to be defined in degrees to create the rotation matrix but it doesn't matter the initial units of the geometry

[gfardell]

How much memory is used by this processor? I see data, y_ref, yhat, r and recon here, but there's also various filtered versions. Are there savings to be found by reusing buffers and calculating in place?

[hrobarts]

I think I've reduced some copies now, I think it could still be improved