-
Notifications
You must be signed in to change notification settings - Fork 95
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Added downsampling of BlocksOnCylindrical scanners in scatter #1291
Added downsampling of BlocksOnCylindrical scanners in scatter #1291
Conversation
5a4f139
to
beeeea9
Compare
Therefore it looks like choosing integer factors for the downsampling isn't required, and the intersections between the modules remain problematic (sometimes over 10% errors in the scatter estimate). However, on the final image the differences caused by the downsampled scatter are below 3% of the average hot values. |
…for-blocks-geometry
As part of this investigation, a bug was found: #1396 STIR/src/scatter_buildblock/ScatterEstimation.cxx Lines 937 to 946 in 8ced2d7
And then we run upsample_and_fit_scatter_estimate a second time here: STIR/src/scatter_buildblock/ScatterEstimation.cxx Lines 1017 to 1026 in 8ced2d7
The second call will fail once #1396 is fixed, since the input ProjData are correctly identified as not homogeneously sampled in axial direction. However, we also don't need the second interpolation step, because input and output ProjData have the same dimensions. Therefore, I would propose to replace that call with a simple inverse_SSRB followed by scatter_normalisation.undo(). This is all that is needed at this point. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm hoping that once this is done, we can avoid the almost repeated code for the blocks and cylindrical case, but maybe do that in stages.
Do you mean in interpolate_projdata? This would indeed be very nice. I'll have a look at it! |
there's some in the ray-tracing projector as well, but that's on our wish-list :-) |
ok, although we could at least in principle make that check more sophisticated to see if needs to interpolate or not, but I'm fine with not doing that!
good point! |
…_filter_width and inverse_SSRB to swig.
…for-blocks-geometry
…uration of downsampled rings to scatter estimation.
…id interpolating across modules.
…ng-up-scatter-simulation-for-blocks-geometry
… a per module basis and then bilinear interpolation to find the best view/tangential position for the floating point crystal IDs.
…instead fill in the interpolated values directly.
… couple of fixes for edge cases.
…for-blocks-geometry
Co-authored-by: Kris Thielemans <KrisThielemans@users.noreply.github.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I haven't checked the actual interpolation code, but trust you! However, some documentation what the code is doing would be good, as it's quite hard to see.
…ng-up-scatter-simulation-for-blocks-geometry
Ok, I will add an overall description. |
… not change during scanner downsampling.
Changes in this pull request
Added the functionality to downsample BlocksOnCylindrical scanners in views and detectors per ring during scatter simulation, in order to speed up the computations. The default behaviour did not change.
Testing performed
This was tested with iterative scatter estimation and simulation on NeuroLF and BPET blocks geometry and compared to non-downsampled scatter estimation. The differences were of the order of 1% when the crystals per ring and views were both downsampled by a factor of 2.
Related issues
fixes #1290
fixes #1393
fixes #1497
Checklist before requesting a review
documentation/release_XXX.md
has been updated with any functionality change (if applicable)