@gschramm, @AnderBiguri, @gfardell, @paskino I've created the PR now as it is now set-up (once gschramm/parallelproj#3 is set-up).

Of course, Travis doesn't really test this, as it won't have parallelproj. It'd be easy enough to add it I guess.

The next step is to get required geometric info. This more or less corresponds to

• Filling a Bin with the relevant segment/view etc
• Calling proj_data_info.get_LOR() with a LORAs2Points object
• Finding the relation between voxel and bin coordinate systems (still a bit messy at the moment pending Prepare for origin shift 2020 #618).

I might have done the backprojection now for OpenMP. Forward projection should be trivial.

A test with non-TOF backprojection of the NEMA acquired on the Signa:
top: parallelproj, bottom: STIR's default ray-tracing

(I have no idea if we expect the interesting effects at the edge of the FOV).

Execution time on my HP Firefly laptop (8 cores, STIR will default to using 7) inside an Ubuntu VM.

• parallelproj:
  • real 1m10
  • user 5m18
• STIR projmatrix using raytracing
  • real 0m49
  • user 4m32

There seems to be a few seconds overhead in creating the arrays with the coordinates. That doesn't matter now, but of course would when doing GPU stuff. (We can easily change this to do it only once during set_up, such that for a reconstruction, that overhead becomes negligible).

the edge effect is a bug that i hope to fix soon. it is because the start and end points lie within the image volume and I step through all planes of the volume instead of only considering planes between the start and end points.
I hope to get that fixed by next week

Good to hear this is progressing!

parallelproj:
real 1m10
user 5m18

This is about 2 orders of magnitude slower than the cuda code (the real part). Is the STIR overhead for LORs that large?

the edge effect is a bug that i hope to fix soon. it is because the start and end points lie within the image volume and I step through all planes of the volume instead of only considering planes between the start and end points.
I hope to get that fixed by next week

Should be just having an if conditions to crop the "start" and "end" of the ray in these chuncks of code, right?
https://github.com/gschramm/parallelproj/blob/master/cuda/src/joseph3d_fwd_cuda.cu#L128-L129

This is about 2 orders of magnitude slower than the cuda code (the real part). Is the STIR overhead for LORs that large?

Timings above are for the non-CUDA OpenMP code! STIR-LOR overhead is probably ~4s (and most of that would be a once-only operation). It would be easy to OpenMP that bit. It can be further optimised, but that'll be more work.

I suggest to create an issue at parallelproj for the start/end code, and discuss there.

new issue is parallelproj created:
gschramm/parallelproj#5 (comment)

seems that I had forgotten to push my last commit that I used to obtain the above results. I've done it now.

@gschramm @AnderBiguri @paskino I have now a version that works fine on CPU with a minimal test (some manual tests are fine as well). I have also pushed a short commit to use the GPU code if parallelproj was built with it. (Currently I cannot switch back to the non-GPU code in that case, but maybe that doesn't matter).

I'd very much appreciate it if someone with a GPU and CUDA could try this. Essentially,

cmake -Dparallelproj_DIR=/where/ever/install/lib/cmake whateverotherSTIRoptions /where/ever/source/STIR
make -j8
ctest

you could save yourself some time if you'd say

ctest -R test_OS

as that's currently the only one with the projector.

If that works, it'll be easy to test on other data as well (just change the projector pair)

This is ready now, as soon as somebody tests the CUDA projector.

We should now remove the fill(0) before forward projection. See gschramm/parallelproj#7 (comment)

Example result of forward projection of a very crude mu-map of the NEMA phantom (54x54x127) with the Siemens mMR span=11 template (data is at https://github.com/SyneRBI/SIRF_data/blob/0e5ac5978e76017d741d2cc4ae8d188e09f9f7c2/examples/PET/mMR/)
top is parallelproj, bottom is ray-tracing.

seg 0:

seg -5:

This is as expected as the Joseph projector interpolates, while ray-tracing (Siddon) is more sensitive to discretisation (which why we have the number of tangential LORs option, the above is with the default 1).

(This phantom is centered, so I cannot see the difference between segment +5 and -5, but the underlying code to determine geometry is the same)