Skip to content
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

ROI selection service #300

Open
SimonHeybrock opened this issue Jan 27, 2025 · 1 comment · May be fixed by #303
Open

ROI selection service #300

SimonHeybrock opened this issue Jan 27, 2025 · 1 comment · May be fixed by #303
Assignees

Comments

@SimonHeybrock
Copy link
Member

SimonHeybrock commented Jan 27, 2025

Users need to select a single pixel or regions on a detector (or projection thereof) and obtain a result for this region. The result could be:

  • Time-of-arrival histogram (simple case).
  • Reduced data, such as I(Q) for the detector region (more complex case).

There are roughly two options:

  1. Include the ROI selection in multiple places, such as the data-reduction service and in a TOF histogram service.
  2. Create a dedicated ROI selection service that can restream the selected subset of data.

The latter is way more flexible, since it can allow for, e.g., having two data reductions done, one for the full data, one for the ROI (or even support multiple ROIs), etc. The downside is that for ROIs containing a substantial fraction of the total counts the restreamed data volume would approach the raw data volume.

On the other hand, data reduction groups incoming data by pixel id anyway, making ROI selection itself very easy and efficient. It therefore seems wasteful to not use this. Should/could the grouping be performed separately, independently of the data reduction and then restreamed? Or should TOF histograms be produced as a "side effect" of data reduction? The latter would put limits on how quickly they could update.

I am not sure we have enough data to make a final decision on this right now.

In terms of implementation, a quick benchmark indicates that numpy.isin with boolean indexing is generally fast enough (unless we reach very high even rates). Break-even with scipp.group with boolean indexing is reached only at higher event numbers, i.e., unless we reuse the grouping for data reduction a NumPy-based approach seems like a good choice. Update: After scipp/scipp#3643 is released, scipp.group should be more suitable.

@SimonHeybrock
Copy link
Member Author

SimonHeybrock commented Jan 28, 2025

Based on the improved scipp.group performance, we may consider the following solution:

  1. Extract numpy.bincount from ess.reduce.live.raw.RollingDetectorView.
  2. Instead, scipp.group in a preprocessor.
  3. Results will be added in 2 accumulators:
    • RollingDetectorView. This will now just perform grouped.bins.size() (or bins.sum()) and a projection.
    • ROI filtering using boolean indexing and TOF histogramming.

@SimonHeybrock SimonHeybrock self-assigned this Jan 28, 2025
@SimonHeybrock SimonHeybrock moved this from Triage to In progress in Development Board Jan 28, 2025
@SimonHeybrock SimonHeybrock linked a pull request Jan 31, 2025 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: In progress
Development

Successfully merging a pull request may close this issue.

1 participant