Initial implementation of iterative axis alignment

[matze]

This PR addresses #237. Waiting for feedback from @Tomago.

[tfarago]

Looks good but I think we would have much better results if we did flat correction. Have a look how align_rotation_axis is implemented. We could also just pass the flat field frame as a keyword argument. I think I will simplify it there too. The thing is that the user needs to find the flat position anyway so once they are in it they might as well grab a frame and pass it to the respective routines.

I am sure you tested it, that's where the file camera commit came from 😉. Can you post here some plots with the measures you tried? I would like to see how different measures behave. If you don't have them don't bother, we will see it on real data next week.

Anyway, I can help with this too, so if you agree I can implement what I mentioned before and push it.

[matze]

I am sure you tested it, that's where the file camera commit came from 😉. Can you post here some plots with the measures you tried? I would like to see how different measures behave. If you don't have them don't bother, we will see it on real data next week.

No, I haven't tested yet, because changing the motor position obviously doesn't change a projection. I could, for a test, make the reconstruction axis dependent on the motor position.

Anyway, I can help with this too, so if you agree I can implement what I mentioned before and push it.

Yes, please. Less redundancy = good. I was already pretty surprised how easy this reconstruction chain was to set up but we definitely need some better documentation because all those important things are scattered around.

[tfarago]

I could, for a test, make the reconstruction axis dependent on the motor position.

That's what I meant, then when you off-center the axis you see the artifacts and can apply the measure and see how it changes.

[tfarago]

Actually that doesn't make much sense, because then you introduce the ring artifacts (misaligned reconstruction axis), whereas when the sample is away we just see less of it. Let's wait for the real data.
BTW the issue and PR names got me confused, they should be called something like sample-centering I guess.

[matze]

Actually that doesn't make much sense, because then you introduce the ring artifacts (misaligned reconstruction axis), whereas when the sample is away we just see less of it.

No, no. For 180° tomography we want the axis aligned with the center of the detector, therefore if the reconstruction rotation axis is fixed and we move the actual reconstruction axis we still get the artifacts.

About the name ... well that's again due to the fact that we have two reconstruction axes. The real one and the one assume for reconstruction.

[tfarago]

Yes, yes 😃 Right, the sample moves with the axis. Anyway, do we actually need to do it iteratively with the devices and tomograph reacquisition? Wouldn't doing it the other way around (changing the reconstruction axis instead of the real one) be simpler?

@async
def find_rotation_axis(sinogram):
    axis_pos = width_2
    while is_better(tomo_slice):
        tomo_slice = backproject(axis_pos)
        axis_pos = calculate_new_axis(tomo_slice)

    return axis_pos

@async
def center_rotation_axis(motor, sinogram, pixel_size):
    motor.position = (sinogram.shape[1] / 2 - find_rotation_axis(sinogram).result()) * pixel_size

(Don't take the code too seriosly, it's just a quick brain dump).

[matze]

But I'd really much prefer a pixel-perfect alignment to the center. I assume image quality being best in the center, right? I mean stuff like lens distortion and reduced light in the corners.

P.S.: We should actually do both. Perfect alignment for acquisition and sub-pixel precise axis determination for final reconstruction.

[tfarago]

But I'd really much prefer a pixel-perfect alignment to the center. I assume image quality being best in the center, right? I mean stuff like lens distortion and reduced light in the corners.

I think that +/- a couple of pixels don't matter from the image quality point of view. If you want a high quality reconstruction you can use the simplified method, then acquire another tomograph (with the sample in the center) and calculate the reconstruction axis again.

P.S.: We should actually do both. Perfect alignment for acquisition and sub-pixel precise axis determination for final reconstruction.

I think the sub-pixel precise reconstruction axis is enough. But let's see how things turn out during the beam time. I will also ask another possible users of this stuff.

[matze]

I like what I see 👍

[tfarago]

Sorry for the forced push but I had to rebase against master to get rid of the bug dealt with in a16064e.
Now the computation works (at least for my test data).

[matze]

@Tomago: I'd say it's ready, so if you like you can squash 'n' merge.

[tfarago]

Simplified and squashed. I will test it today and if that works we can merge.

[matze]

👏

[tfarago]

Still needs some work on the backprojection side, shifting.

[tfarago]

🎆 I changed the filtering to the padded one so the algorithm should be more robust. I tested the compute_rotation_axis. I think it can be merged now.

[matze]

Great 👍

But on the other hand, we could wait another two weeks and celebrate yet another birthday ;-)

[tfarago]

This thread will be available also by then. Feel free to do so ;D