[WIP] Group OCR line detections by mutual gap, not absolute pixel buckets#2570
Draft
PawelPeczek-Roboflow wants to merge 2 commits into
Draft
[WIP] Group OCR line detections by mutual gap, not absolute pixel buckets#2570PawelPeczek-Roboflow wants to merge 2 commits into
PawelPeczek-Roboflow wants to merge 2 commits into
Conversation
…kets group_detections_by_line snapped top-y to fixed multiples of tolerance, so two boxes on the same line whose y1 straddled a bucket boundary (e.g. 14 and 16 at tolerance=10) landed on different lines, producing a spurious line break. Sort by primary coordinate and start a new line only when the gap to the previous detection exceeds tolerance, honoring the documented 'within this tolerance distance are grouped into the same line' contract. Applied to both v1 and v2 (identical logic). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
🚧 Work in progress — not ready for review
Draft PR from a batch addressing findings from an in-depth engineering review. Fixes review finding 26 (Medium, Correctness).
The bug
group_detections_by_lineinstitch_ocr_detections/v1.py:315(and the byte-identicalv2.py:400) assigns each OCR detection to a line vianp.round(y1 / tolerance) * tolerance, snapping the top-y coordinate to the nearest absolute multiple oftolerance. Two boxes on the same physical text line whosey1values straddle a bucket boundary land on different lines even though they are far closer thantolerance— directly contradicting the documented contract "Detections within this tolerance distance are grouped into the same line."Root cause
Grouping was done by fixed pixel-grid bucket membership, not by mutual distance. With
tolerance=10,y1=14 -> round(1.4)*10 = 10andy1=16 -> round(1.6)*10 = 20, so two boxes 2px apart are placed on separate lines and the output becomesA\nBinstead ofAB.Fix
Rewrote
group_detections_by_linein bothv1.pyandv2.pyto group by mutual gap (the same greedy approachv2.adaptive_word_groupingalready uses for lines): sort detections by the primary coordinate, then start a new line only when the gap to the previous detection exceedstolerance. Each line is keyed by its first detection's primary coordinate, so the caller'ssorted(boxes_by_line.keys(), reverse=...)top-to-bottom / bottom-to-top ordering is preserved unchanged. Both blocks'tolerancestitching mode are affected (v2's defaultstitching_algorithm="tolerance"routes to the same function).Verification
Standalone before/after on the review's exact repro (Box A
xyxy=[0,14,10,30]'A', Box Bxyxy=[20,16,30,32]'B', left_to_right, tolerance=10):'A\nB'-> NEW'AB'(fixed)'A\nB'(still splits correctly)'AB'== NEW'AB'(unchanged)'BA'(correct)Scope
Focused change; one of a coordinated batch (one PR per finding).
🤖 Generated with Claude Code