PPStructureV3 emits cell_box_list coordinates outside the source table bbox

[carvvf]

PPStructureV3 emits final cell_box_list coordinates outside the source table bbox

Summary

PaddleX can emit final non-empty cell_box_list coordinates that extend outside
the source table block_bbox in PPStructureV3 output. The resulting cell grid
is geometrically invalid even when table layout detection and OCR signals are
high-confidence.

The issue was first observed in a GPU run. A subsequent CPU run changed the
affected pages and predicted structures, but still produced final cell boxes
outside their source table bbox.

GPU environment and configuration

• PaddleX: 3.7.2
• PaddleOCR: 3.7.0
• PaddlePaddle: paddlepaddle-gpu 3.3.1, CUDA 13 build
• Pipeline: PP-StructureV3
• Runtime: GPU (gpu:0), normal inference
• Operating system: Linux Mint 22.2
• Python: 3.12.3
• NVIDIA driver: 580.173.02
• cuDNN: version not recorded by the fixture
• Input: arXiv paper 1912.13295

The GPU preset enables document orientation classification and table
recognition, and disables document unwarping. Its table-recognition components
are PP-LCNet_x1_0_table_cls, SLANeXt_wired, SLANeXt_wireless,
RT-DETR-L_wired_table_cell_det, and RT-DETR-L_wireless_table_cell_det.

Reproduction command

paddlex --pipeline PP-StructureV3 \
  --input 1912.13295.pdf \
  --use_doc_orientation_classify True \
  --use_doc_unwarping False \
  --save_path ./output \
  --device gpu:0

Retain the per-page JSON output and inspect the table results for zero-based
page indices 6 and 8. These pages have doc_preprocessor_res.angle: 270.
Page index 7 has the same preprocessor angle but did not exhibit the GPU
geometry defect.

GPU observed results

Source page index	Table bbox	Valid cell boxes	Mean cell-box containment	OCR-to-cell containment	Mean OCR score	Layout table score
6	[131, 193, 1485, 1056]	28	76.77%	58.53%	0.9950	0.9923
8	[131, 142, 1485, 639]	7	50.61%	73.73%	0.9964	0.9890

GPU page index 6 cell-box overlay

Several final cell boxes extend below y=1056, up to roughly y=1224.

GPU page index 8 cell-box overlay

All final cell boxes extend below the table bottom y=639, up to roughly
y=1213.

Both GPU tables have equal HTML logical-cell and valid cell-box counts, so
their count agreement is 100%. This makes count-only validation insufficient.

CPU rerun update

A CPU rerun on the same PDF produced different table geometry:

Source page index	CPU cell-box containment	Result
6	100.00%	no out-of-bounds condition
7	69.71%	final cell boxes outside the source table bbox
8	67.83%	final cell boxes outside the source table bbox

This is not a controlled same-model CPU/GPU comparison. The CPU preset uses
lighter or reduced layout/OCR components and higher batch sizes: PP-DocLayout-M
instead of PP-DocLayout_plus-L, PP-OCRv5_mobile_det with
limit_side_len: 512 instead of PP-OCRv5_server_det with 736, and
PP-LCNet_x0_25_textline_ori instead of PP-LCNet_x1_0_textline_ori. It also
disables chart recognition and uses PP-FormulaNet_plus-M instead of
PP-FormulaNet_plus-L.

The table-recognition components listed above are unchanged between the CPU and
GPU presets. The CPU result is therefore additional evidence of the final
geometry defect, not a backend-only comparison.

Expected behavior

Every final cell_box_list box should remain within the table region used to
produce the table crop. Coordinate conversion and post-processing must not
introduce boxes outside the original table bbox.

Diagnostic status

Classification: UNCONFIRMED / HYPOTHESIS. Direct inference with
RT-DETR-L_wired_table_cell_det and RT-DETR-L_wireless_table_cell_det on the
same table crops produced raw detector boxes contained in the crop. The
incorrect geometry appears downstream, possibly during crop-to-page coordinate
conversion or cells_det_results_reprocessing, but the exact transformation
has not yet been isolated.

The direct-detector comparison was a separate CPU diagnostic run; it is not
claimed to be a bit-for-bit reproduction of the GPU fixture.

Requested investigation

1. Persist or log cell boxes at the following stages for the supplied input:
   raw cell-detector output, crop-to-page conversion, and final output after
   cells_det_results_reprocessing.
2. Verify that every final cell box is contained by the source table bbox.
3. Add a regression test covering cells that escape the source table bounds.

Clipping final boxes to the table bbox alone is not proposed as a fix: it would
mask the incorrect grid reconstruction rather than correct the coordinate or
reconciliation error.

Related work

I searched existing PaddleX and PaddleOCR issues and found no report for
non-empty final cell_box_list boxes escaping their source table bbox.

PaddleX PR #5140 modifies cells_det_results_reprocessing for a separate
zero-cell/KMeans crash. This report concerns non-empty tables whose final cell
geometry escapes the table bbox.