In the intersection-check logic, the condition:
if b1[2] < b2[0] or b2[2] < b1[0] or b1[1] > b2[3] or b2[1] > b2[3]:
return None
appears to contain a mistake. Specifically, b2[1] > b2[3] is used to check non-intersection — but this compares the same bbox’s y1 > y2, not between b1 and b2. Under standard bbox conventions ([x1, y1, x2, y2] with y1 ≤ y2), this condition effectively checks whether b2 is invalid (top > bottom), not whether b1 and b2 do not overlap.
As a result, two valid bboxes may be considered overlapping (or produce invalid intersection) incorrectly, or empty intersections may be erroneously discarded.
The typical robust check for “no intersection” between two bboxes should be something like:
if b1[2] < b2[0] or b2[2] < b1[0] or b1[3] < b2[1] or b2[3] < b1[1]:
return None
I may be misunderstanding the intended coordinate convention here, but based on standard bbox definitions and the rest of the function, this condition appears unintended. If I’m mistaken, please feel free to correct me — otherwise I’d be happy to contribute a patch or PR.
In the intersection-check logic, the condition:
appears to contain a mistake. Specifically, b2[1] > b2[3] is used to check non-intersection — but this compares the same bbox’s y1 > y2, not between b1 and b2. Under standard bbox conventions ([x1, y1, x2, y2] with y1 ≤ y2), this condition effectively checks whether b2 is invalid (top > bottom), not whether b1 and b2 do not overlap.
As a result, two valid bboxes may be considered overlapping (or produce invalid intersection) incorrectly, or empty intersections may be erroneously discarded.
The typical robust check for “no intersection” between two bboxes should be something like:
I may be misunderstanding the intended coordinate convention here, but based on standard bbox definitions and the rest of the function, this condition appears unintended. If I’m mistaken, please feel free to correct me — otherwise I’d be happy to contribute a patch or PR.