ENH: allow choice of ASTRA projector type

[kohr-h]

I suggest we switch to the linear for 2D parallel beam projections. The CPU line kernel gives quite bad results in terms of interpolation artifacts (@wjp: is that to be expected? I didn't imagine it to be this severe.). For comparison a projection-backprojection cycle:

Line kernel

Linear kernel

[kohr-h]

Note: the images come from the ray_trafo_parallel_2d.py example.

[adler-j]

Is the linear kernel matched?

[wjp]

ASTRA's CPU projectors all have matched FP and BP, yes.

[wjp]

By the way, if you're evaluating 2D CPU projection kernels, I've just added a new 2D parallel beam CPU projector to astra called distance_driven ( from http://ieeexplore.ieee.org/abstract/document/1239600/ ), which is supposedly quite nice in terms of discretization artifacts. We're still evaluating its behaviour here.

[kohr-h]

How about this now?

[adler-j]

This would be a step away from getting the interpolation from the space. After some thought I've concluded that I'm in favor of this.

However this means that we should fully make the transition and actually allow users to pick the method as a parameter to the RayTransform method. Could you do this instead?

[kohr-h]

Yes, I've done exactly that in the #1459 PR. I can move it into this one instead.

[pep8speaks]

Checking updated PR...

• In the file odl/tomo/backends/astra_cpu.py:

Line 64:80: E501 line too long (82 > 79 characters)

Comment last updated at 2019-07-18 16:58:02 UTC

[kohr-h]

I've pulled over the changes as mentioned, ready for review.

[adler-j]

Overall looks good, but needs some minor changes.

Also needs to add tests.

[kohr-h]

Overall looks good, but needs some minor changes.

Done that.

Also needs to add tests.

Frankly I don't really know what to test. The tests would end up just copying what's in the implementation.
If at all, such tests should be in the ray transform test code, to make sure all versions run.

[kohr-h]

Ping for re-review @adler-j

[kohr-h]

Ping again. How about we merge this one after resolving the conflicts? I think the job is done here.

[adler-j]

Merge after conflicts are resolved. Sorry about the delay, rather busy atm.

[kohr-h]

Merge after conflicts are resolved. Sorry about the delay, rather busy atm.

I can imagine that. Thanks for popping in here anyway :-)

I'll fix the conflicts and you keep the mouse pointer ready to click "approve"^^.

[kohr-h]

I'll inspect the CI for errors other than the "normal" ones, after that I'd like to merge.

[kohr-h]

Just the "usual" errors in CI, merging.