Automatically shrink reconstruction volume

[hrobarts]

Changes

Code to create a reduced reconstruction volume from an AcquisitionData object
If using method='manual'

• Creates an image geometry with limits specified with the limits argument. If a dimension is not included in the limits dictionary, the full size of the axis is used
  If using method='otsu or threshold
• Performs a binned reconstruction
• Finds the maximum pixel intensity along each direction
• Finds pixels above the threshold or a threshold found with an Otsu filter
• Identified limits between sample and background where no pixels above the threshold are found
  If preview=True
• Plots the limits on the maximum intensity reconstruction
  kwargs
• buffer applies a buffer around the automatically calculated limits
• mask_radius applies a mask to the reconstruction before finding limits
• otsu_classes changes number of material classes to assume in the Otsu thresholding
• min_component_size specified a minimum number of connected components in pixels to consider when choosing the limits - to avoid a small amount of noise changing the limits

vs = VolumeShrinker(data, recon_backend='astra')
ig_reduced = vs.run(limits={'horizontal_x':(10, 150), 'vertical':(5, 50)}, preview=True)

vs = VolumeShrinker(data, recon_backend='astra')
ig_reduced = vs.run(method='threshold', preview=True, threshold=0.9, buffer=10)

If debug logging is enabled, we plot a histogram with the threshold and reduced box

vs = VolumeShrinker(data, recon_backend='astra')
ig_reduced = vs.run(method='otsu', preview=True, otsu_classes=2, buffer=10, min_component_size=10)

Testing you performed

Demo TomographicImaging/CIL-Demos#283

I think it makes sense for this code to be in utilities and possibly be called by AcquisitionData.get_ImageGeometry() however when I did this I had trouble with circular imports. Maybe it should be moved to utilities under framework?

Related issues/links

May close #1998

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]

For discussion:

Could this be a method on image_data

• The user would have to reconstruct their data themselves before calling the get reduced image geometry method
• Once they have reconstructed the full thing they might not be interested in reducing the volume
• If they bin the data they will have to convert the binned reduced geometry to their unbinned reduced geometry

Could this be a method on acquisition_geometry

• The method needs access to the data so would have to pass the data as an argument?
• Similar to the ag.get_ImageGeometry() method we could have ag.get_reduced_ImageGeometry(data)

Could this be a method on acqusition_data

• Makes the most sense, but confusing get_ImageGeometry is a method on acquisition_geometry and this would be a method on acqusition_data. Could allow both?

[hrobarts]

What should the name be

• get_reduced_ImageGeometry()
• get_optimal_ImageGeometry() - makes more sense if we also do rotation at some point
• get_shrunk_ImageGeometry()
  or
  get_ImageGeometry() with argument method=auto (or rotate in future?) or enums like in labels

[lauramurgatroyd]

Hi @hrobarts
The shrinker tool is looking very useful!
I had some questions about the structure, plus some docstring and unit test suggestions, and maybe some more checking of valid parameters. Also wasn't sure about the mask parameter in the 'manual' case

[lauramurgatroyd]

You will need to add the volume shrinker to this file in the documentation:
https://github.com/TomographicImaging/CIL/blob/master/docs/source/utilities.rst

[hrobarts]

Hi @lauramurgatroyd thank you for your review! I think I've addressed all the comments now.

[Neonbluestoplight]

Hi @hrobarts,

There's one change but the first comment about AcquisitionType is just for my own understanding and doesn't have to be changed.

[hrobarts]

Hi @hrobarts,

There's one change but the first comment about AcquisitionType is just for my own understanding and doesn't have to be changed.

Thank you for your review @Neonbluestoplight, I think I have addressed your comments!

[lauramurgatroyd]

Hi @hrobarts
Not sure whether the CIl-Demos branch has the latest version of VolumeShrinker but I noticed in the laminography misc demo, the boundary line seems to render in slightly the wrong place (I can see some sample outside). I think this is a rendering issue not a bounds issue (as in a problem with the way its plotted):

[hrobarts]

Hi @hrobarts Not sure whether the CIl-Demos branch has the latest version of VolumeShrinker but I noticed in the laminography misc demo, the boundary line seems to render in slightly the wrong place (I can see some sample outside). I think this is a rendering issue not a bounds issue (as in a problem with the way its plotted):

Good point it was not the most up to date version, I've copied the current file but we can import it once it's merged. I think the problem is actually in how the bounds are calculated because we use a binned reconstruction the boundary which is found can never be more precise than the binning. At the moment the binning level is calculated internally based on the panel size but we could make this an argument the user can choose. Another way to get round this is by adding a buffer around the found boundaries. Here is the new output from the demo using a buffer. Perhaps by default the buffer=binning to avoid these edge issues.

[hrobarts]

Hi @hrobarts Not sure whether the CIl-Demos branch has the latest version of VolumeShrinker but I noticed in the laminography misc demo, the boundary line seems to render in slightly the wrong place (I can see some sample outside). I think this is a rendering issue not a bounds issue (as in a problem with the way its plotted):

Good point it was not the most up to date version, I've copied the current file but we can import it once it's merged. I think the problem is actually in how the bounds are calculated because we use a binned reconstruction the boundary which is found can never be more precise than the binning. At the moment the binning level is calculated internally based on the panel size but we could make this an argument the user can choose. Another way to get round this is by adding a buffer around the found boundaries. Here is the new output from the demo using a buffer. Perhaps by default the buffer=binning to avoid these edge issues.

We discussed this and decided to always add the binning level to the bounds, this is separate from the buffer