Open dkazanc opened 3 months ago
Something that popped into my head which I wondered if it's relevant.
I think the find_center_pc
method works differently to find_center_vo
, which was why the RotationWrapper
class was modified in the past to do some different logic when executing find_center_pc
.
I don't actually know what is the different logic for find_center_pc
though: would it clash with the idea of providing multiple slices to calculate the CoR from, or would that different logic for find_center_pc
be ok with this update to the wrapper?
yes, find_center_pc
does not need any vertical slice index as it uses the whole projection by default. So it works in a different space compared to find_center_vo
, which works with sinograms. So I think the modification should be find_center_vo
specific or rather for all centering methods that work with sinograms. As I remember that the pattern is actually set to projections for that method anyway, which is slightly confusing, but at least we're aware of it.
As it was raised by beamlines scientists, we probably need to implement an option of providing a list of vertical slices instead of just a single slice to the centering methods that work on sinograms (currently only Vo Centering). The main reason is to be able to identify that the center of rotation is different for different vertical positions in the sample.
What should be done next to those values is the a matter of the discussion. In Savu the average can be taken or even the three values get interpolated between all points therefore resulting in a vector of CoRs for each vertical slice. The latter is probably not needed and also would lead to more involved modifications of the framework. The former is also questionable. If the values are different then by taking the mean we can end up with the value that won't be correct for all vertical positions.
Here are my suggestions to start with: