sino_360_to_180 breaks in httomo if its memory estimator is called

[yousefmoazzam]

In the main branch of httomo, the 360 pipeline runs without error. However, in the gpuloop branch of httomo, it produces an error that is a result of the memory estimator not providing the output shape of the data:

httomolibgpu/httomolibgpu/misc/morph.py

Line 45 in 9f0a97c

return int(np.floor(available_memory / (in_slice + out_slice))), dtype

despite httomo requiring it in the definition of the "maximum number of slices that can be processed": https://github.com/DiamondLightSource/httomo/blob/adc1614891c6c8c77db070083329cdc0807363c7/httomo/task_runner.py#L725-L727.

The reason that this doesn't produce an error in the main branch of httomo is that in main, the _update_max_slices()
function is never called, and hence, the memory estimator of the stitching function is never called.

From playing with the test 360 data, it seems that the output shape of the stitching method is able to be determined in advance by the overlap value that is outputted by the find_center_360 method and passed to the stitching method, doing something like the following:

stitched_sino_width = original_sino_width * 2 - math.ceil(overlap)

where original_sino_width is the width of the original 360 sinogram, and overlap is the overlap value produced by the find_center_360 method.

So in principle, I think the correct shape of the output of the stitching method could be returned by its memory estimator.

[dkazanc]

@yousefmoazzam is this relevant after the fixes above?

[yousefmoazzam]

This has been fixed by DiamondLightSource/httomo#363 and other related 360 stitching stuff, so can close methinks