You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While testing #70 we've noticed that in certain situations evaluate_correlations can give peak coordinates which are outside of the frame if the input peaks are close to the frame edges and the crop_size therefore overlaps the border. This happens because we simply _shift the coordinate in the crop to the coordinate in the frame, without applying any bounds checking.
This doesn't have much impact on internal code as we refine/evaluate in the coordinate system of the crops, but could affect downstream code which might assume results will lie in the frame. I'd argue this is unexpected because the cropping / refinement process is quite opaque to the user (it's mostly just the search parameter on a MatchPattern and that isn't really clear in itself).
Another potential error (which I haven't actually observed!) is the fact we create the centers buffer as np.uint16, so this could overflow in some situations.
One option might be to supply float32 / np.nan results even for the integer centers to make this error case easier to identify.
The text was updated successfully, but these errors were encountered:
While testing #70 we've noticed that in certain situations
evaluate_correlations
can give peak coordinates which are outside of the frame if the input peaks are close to the frame edges and thecrop_size
therefore overlaps the border. This happens because we simply_shift
the coordinate in the crop to the coordinate in the frame, without applying any bounds checking.This doesn't have much impact on internal code as we refine/evaluate in the coordinate system of the crops, but could affect downstream code which might assume results will lie in the frame. I'd argue this is unexpected because the cropping / refinement process is quite opaque to the user (it's mostly just the
search
parameter on aMatchPattern
and that isn't really clear in itself).Another potential error (which I haven't actually observed!) is the fact we create the
centers
buffer asnp.uint16
, so this could overflow in some situations.One option might be to supply
float32 / np.nan
results even for the integercenters
to make this error case easier to identify.The text was updated successfully, but these errors were encountered: