Remove deprecated code in v25.0
Description
A list of things we need to remember to deprecate
It looks like the following has been deprecated for at least 2 years i.e. since 23.0.0. Any objections to deleting any of the following?
- [x] use of integer compression in NEXUSDataWriter https://github.com/TomographicImaging/CIL/blame/72d147cd2d780406f6b8a1728f6efd075e1c59fc/Wrappers/Python/cil/io/utilities.py#L31 https://github.com/TomographicImaging/CIL/blame/72d147cd2d780406f6b8a1728f6efd075e1c59fc/Wrappers/Python/cil/io/utilities.py#L67 https://github.com/TomographicImaging/CIL/blame/72d147cd2d780406f6b8a1728f6efd075e1c59fc/Wrappers/Python/cil/io/utilities.py#L94
Not sure about this one as it has technically been deprecated - in the NEXUSDataWriter init there's no option to set as int, but in setup it is only listed as int and hadn't been marked as deprecated https://github.com/TomographicImaging/CIL/blob/72d147cd2d780406f6b8a1728f6efd075e1c59fc/Wrappers/Python/cil/io/NEXUSDataWriter.py#L68-L70
- [x] axpby https://github.com/TomographicImaging/CIL/blame/72d147cd2d780406f6b8a1728f6efd075e1c59fc/Wrappers/Python/cil/framework/block.py#L341
For the following to see how long things had been deprecated I had to check the old framework file: https://github.com/TomographicImaging/CIL/blame/48d89c92ce721b0f07f521a38822a3c379a748bc/Wrappers/Python/cil/framework/framework.py
- [x] shape setter in ImageGeometry and DataContainer: https://github.com/TomographicImaging/CIL/blob/72d147cd2d780406f6b8a1728f6efd075e1c59fc/Wrappers/Python/cil/framework/data_container.py#L70-L71
https://github.com/TomographicImaging/CIL/blob/72d147cd2d780406f6b8a1728f6efd075e1c59fc/Wrappers/Python/cil/framework/image_geometry.py#L67
- [x] setting dimension_labels in allocate
https://github.com/TomographicImaging/CIL/blob/72d147cd2d780406f6b8a1728f6efd075e1c59fc/Wrappers/Python/cil/framework/image_data.py#L59
https://github.com/TomographicImaging/CIL/blob/72d147cd2d780406f6b8a1728f6efd075e1c59fc/Wrappers/Python/cil/framework/acquisition_geometry.py#L2178
astra-> utilities > convert geometry to astra 3d - there's an if statement that catches behaviour after cil version x
https://github.com/TomographicImaging/CIL/blob/6a65e801de208de8d266f697da0c25098bf326b0/Wrappers/Python/cil/plugins/astra/utilities/convert_geometry_to_astra_vec_3D.py#L46-L50
Not sure which of the 2 methods we should be using:
update_reference_frame "transforms the system origin to the rotation axis position"
https://github.com/TomographicImaging/CIL/blob/a5def19dffd681c6eba9180d1c1ebb4cd64cb42a/Wrappers/Python/cil/framework/acquisition_geometry.py#L275-L289
"align_reference_frame": "sets the origin to the rotation axis and aligns the y axis with the ray-direction"
https://github.com/TomographicImaging/CIL/blob/a5def19dffd681c6eba9180d1c1ebb4cd64cb42a/Wrappers/Python/cil/framework/acquisition_geometry.py#L349-L365
Other things to note: "align_reference_frame" "definition" parameter is redundant - should we deprecate?
@lauramurgatroyd
Other things to note: "align_reference_frame" "definition" parameter is redundant - should we deprecate?
for some geometry definitions definition is the same, for others it is different. take Cone2D:
https://github.com/TomographicImaging/CIL/blob/a5def19dffd681c6eba9180d1c1ebb4cd64cb42a/Wrappers/Python/cil/framework/acquisition_geometry.py#L808-L822
This is necessary as astra/tigre/cil/... may have different ways to orientate the reconstruction grid w.r.t. the system. This means behaviour is consistent no matter which blackened you call.
update_reference_frame probably isn't needed, but I'm not sure it harms anything by being there. It's used, it's tested it's just a building block.
astra-> utilities > convert geometry to astra 3d - there's an if statement that catches behaviour after cil version x
CIL/Wrappers/Python/cil/plugins/astra/utilities/convert_geometry_to_astra_vec_3D.py
Lines 46 to 50 in 6a65e80
#this catches behaviour modified after CIL 21.3.1 try: sinogram_geometry.config.system.align_reference_frame('cil') except: sinogram_geometry.config.system.update_reference_frame()
This try/catch is safe to go.
Sorry I hadn't noticed the override of the method where the 'definition' is used - that makes a lot of sense!