TOF bin fix for RayTracingMatrix

[z-k-li]

Changes in this pull request

Project LOR to mean z-plane for maintaining the concentric-circle model for TOF bins. Edit: fix mismatch in image/projdata coordinate system affecting TOF calculation

Testing performed

Tested the same as issue 1537 and got consistent results with paralleproj.

Related issues

Fixes issue #1537

Checklist before requesting a review

• I have performed a self-review of my code
• [] I have added docstrings/doxygen in line with the guidance in the developer guide
• [] I have implemented unit tests that cover any new or modified functionality (if applicable)
• The code builds and runs on my machine
• [] documentation/release_XXX.md has been updated with any functionality change (if applicable)

Contribution Notes

Please tick the following:

• The content of this Pull Request (the Contribution) is intentionally submitted for inclusion in STIR (the Work) under the terms and conditions of the Apache-2.0 License.
• I (or my institution) have signed the STIR Contribution License Agreement (not required for small changes).

[z-k-li]

[KrisThielemans]

@z-k-li @NikEfth it seems to work! However, can you explain the geometric reasoning? I don't understand why the z-axis should be treated different from the others (aside from the difference in z-origin between coordinate systems flagged up in #1537).

This PR effectively sets diff.z=0 I believe. (it doesn't change middle, but once diff.z==0, middle.z no longer matters). The (unchanged) formula for computing the TOF location is

STIR/src/include/stir/recon_buildblock/ProjMatrixByBin.inl

Line 132 in 1f2556b

const float d2 = -inner_product(image_info_sptr->get_physical_coordinates_for_indices(c) - middle, diff_unit_vector);

so this now becomes a distance of the projection in the transverse plane, as opposed to a projection along the line.

So, in my opinion, this PR gives "circular TOF bins" in the transverse plane, not circular along the LOR. This could be how the Quadra works, and seems to could be how parallelproj works (@gschramm might confirm), but it makes no sense to me...

Maybe my geometrical insight is wrong.

[NikEfth]

If I understand your comment correctly; TOF bins are no different from views. They do not depend on the theta of the LOR. They are just circles from the center of the scanner to the edge of the FOV.
Before, the code was saying voxels in LORs with the same angle but in different ring distances should be assigned to different views.

[KrisThielemans]

Right, that's what this PR does. However, it makes no sense to me that a scanner would do that. It measures a time difference. It would surprise me if they then do a TOF bin assignment that depends on the ring difference. (With this PR, the TOF bin will "stretch" for higher ring diff). Of course, the actual time difference would become larger for a longer LOR, and a vendor could try and compensate for that.

(I don't think the test in #1537 actually tests this stretching. It tests if the TOF bin is in the centre. So we cannot infer from it what parallelproj does regarding stretching)

[NikEfth]

The stretching is true regardless of tof. LORs in higher segments are longer by definition. So, tangential positions also stretch, but are still independent. Actually, tangential positions would be a better example than views

…

On Fri, Oct 24, 2025 at 12:07 PM Kris Thielemans ***@***.***> wrote: *KrisThielemans* left a comment (UCL/STIR#1645) <#1645 (comment)> Right, that's what this PR does. However, it makes no sense to me that a scanner would do that. It measures a time difference. It would surprise me if they then do a TOF bin assignment that depends on the ring difference. (With this PR, the TOF bin will "stretch" for higher ring diff). Of course, the actual time difference would become larger for a longer LOR, and a vendor could try and compensate for that. (I don't think the test in #1537 <#1537> actually tests this stretching. It tests if the TOF bin is in the centre. So we cannot infer from it what parallelproj does regarding stretching) — Reply to this email directly, view it on GitHub <#1645 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACEUB7XVQBLEHWP26N44GXL3ZH25DAVCNFSM6AAAAACKCNQQB2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTINBSGMYDSNBUHE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[KrisThielemans]

sure, but the question is what a scanner does for TOF.

@z-k-li easy to do a sim of a line source close to the edge of the transaxial FOV? forward project with parallelproj and this PR, ideally even do a GATE sim. Look at oblique segments. The question is if the line source appears in the same TOF bin for all segments (I think it should with this PR), or not.

[gschramm]

the tof bins in parallelproj have a fixed length (in spatial units). meaning that you need more bins to cover a "full" oblique LOR compared to a direct LOR. For all scanners I have seen so far (no TB scanners), vendors fix the number of fixed length TOF bins such that the most oblique LOR are fully covered.

[KrisThielemans]

Thanks @gschramm!

@z-k-li In my opinion, we're back to fixing #1537 (comment). (The current PR is insensitive to the z-mismatch mentioned there). I'm not sure why my original suggestion doesn't work for that.

[z-k-li]

sure, but the question is what a scanner does for TOF.

@z-k-li easy to do a sim of a line source close to the edge of the transaxial FOV? forward project with parallelproj and this PR, ideally even do a GATE sim. Look at oblique segments. The question is if the line source appears in the same TOF bin for all segments (I think it should with this PR), or not.

Yes, I will do this!

[z-k-li]

A new update, as suggested by Kris, I tested the line source from edge of FOV. The ray_new is the new solution which is overlapped fully with the parallelproj. However, as expected, the circular TOF bins in the transverse plane solution suffers from strenching so it is not matching the parallelproj.

[KrisThielemans]

Looks like my review didn't get onto GitHub.

@z-k-li Could you confirm that with this version, everything seems fine?

Ideally, we add some test to test_time_of_flight.cxx.

In fact, I see the same code appearing in the TOF_Tests::export_lor functions. @NikEfth I think we should just cut that. It doesn't seem useful anymore to repeat the code and (manually) check if it gives the same result. (we could keep the export_lor functionality to just output one row).

Also, @NikEfth what is the "test" code here supposed to check?

[KrisThielemans]

I have some tests for this. And they work.

I'm tempted to squash-merge this, and then do a new PR for the test. Ok?

Ideally, you add somethng in release_6.4.htm (might have to merge master first)

[NikEfth]

It's been a while, but I was plotting the tof kernels. I don't remember now.

[NikEfth]

A few things were replaced by the simulated tests.