Fix max_box_w calculation bug in extract_polygon_points_by_masks

[WenbinHou]

Scope

This patch fixes one bug in the installed PaddleX package inside paddlex/inference/models/layout_analysis/processors.py.
The patched function is extract_polygon_points_by_masks().

Problem

The original code computed:

max_box_w = max(boxes[:, 4] - boxes[:, 3])

Within this function, each row in boxes is treated as:

[cls_id, score, x_min, y_min, x_max, y_max]

The same function later unpacks:

x_min, y_min, x_max, y_max = boxes[i, 2:6]
box_w, box_h = x_max - x_min, y_max - y_min

So boxes[:, 4] - boxes[:, 3] is x_max - y_min, not width.

That value is then used as the fallback max_allowed_dist in the polygon
vertex extraction path:

if box_w > max_box_w * 0.6:
    max_allowed_dist = box_w
else:
    max_allowed_dist = max_box_w

This affects extract_custom_vertices() via mask2polygon(), so the mistake
changes how many intermediate vertices are kept or inserted on long polygon
edges.

Fix

The local fix replaces that line with:

max_box_w = max(boxes[:, 4] - boxes[:, 2])

This is the correct x_max - x_min width calculation.

Validation

I checked this in two ways.

1. Static code check

Inside the same function, the code clearly treats boxes[i, 2:6] as
x_min, y_min, x_max, y_max. Under that schema, the original expression mixes
x and y axes and cannot represent width.

2. Real-image A/B comparison

I compared the current implementation against a corrected version on
Real5-OmniDocBench, using the first 20 images from each subset:

• Real5-OmniDocBench-Illumination
• Real5-OmniDocBench-Scanning
• Real5-OmniDocBench-Screen-Photography
• Real5-OmniDocBench-Skew
• Real5-OmniDocBench-Warping

Totals:

• 100 images checked
• 10 images changed under layout_shape_mode='poly'
• 11 polygons changed under layout_shape_mode='poly'
• 1 image changed under layout_shape_mode='auto'
• 2 polygons changed under layout_shape_mode='auto'

The computed current_max_box_w / fixed_max_box_w ratio ranged from about
0.736 to 1.958, which is consistent with a coordinate-indexing mistake,
not an intentional heuristic.

Representative cases:

• Real5-OmniDocBench-Warping/PPT_1637904769_page_008.png
  • one text polygon changed from 8 vertices to 9
• Real5-OmniDocBench-Skew/PPT_B14_Claeys_Consistent Presentation of Images_v2_page_013.png
  • two text polygons changed under both poly and auto
  • one changed from 10 vertices to 12
  • another changed from 10 vertices to 11

Why this matters

This bug does not change the model forward pass itself. It affects the Python
postprocess stage that converts:

• masks -> contour -> polygon_points

Specifically, it changes the geometric simplification / densification threshold
used after contour extraction, so the resulting polygons may lose or gain
vertices unexpectedly.

[paddle-bot]

Thanks for your contribution!

[CLAassistant]

All committers have signed the CLA.

[WenbinHou]

Or ... should I target develop branch instead? Tell me if so. TIA.