关于Tablemaster模型的解码

🔎 Search before asking

I have searched the PaddleOCR Docs and found no similar bug report.
I have searched the PaddleOCR Issues and found no similar bug report.
I have searched the PaddleOCR Discussions and found no similar bug report.

🐛 Bug (问题描述)

请教一下ppocr/postprocess/table_postprocess.py第184行x1和y1坐标为什么需要减去w //2呀？这样推理出的结果似乎会产生bbox漂移的问题，去掉之后是正常的。

PaddleOCR/ppocr/postprocess/table_postprocess.py

Lines 175 to 186 in c833dfc

    
           def _bbox_decode(self, bbox, shape): 
        
               h, w, ratio_h, ratio_w, pad_h, pad_w = shape 
        
               if self.box_shape == 'pad': 
        
                   h, w = pad_h, pad_w 
        
               bbox[0::2] *= w 
        
               bbox[1::2] *= h 
        
               bbox[0::2] /= ratio_w 
        
               bbox[1::2] /= ratio_h 
        
               x, y, w, h = bbox 
        
               x1, y1, x2, y2 = x - w // 2, y - h // 2, x + w // 2, y + h // 2 
        
               bbox = np.array([x1, y1, x2, y2]) 
        
               return bbox

🏃‍♂️ Environment (运行环境)

🌰 Minimal Reproducible Example (最小可复现问题的Demo)

Tablemaster模型的解码部分，特别是您提到的 x1 和 y1 坐标减去 w // 2 的操作，主要是与解码逻辑、模型特定的实现有关。以下是对您提到的问题的详细分析：

1. 为什么需要减去 `w // 2`？

在 ppocr/postprocess/table_postprocess.py 的第 184 行，x1 和 y1 减去 w // 2，这一操作可能是为了对预测的边界框中心点坐标进行调整。一般来说：

在表格数据解码中，某些模型（如 SLANet）可能会预测出表格单元格的中心点坐标以及宽高。
为了将预测的中心点坐标还原为矩形框的左上角坐标，需要做以下转换：
```
x1 = center_x - w / 2
y1 = center_y - h / 2
x2 = center_x + w / 2
y2 = center_y + h / 2
```
上述公式中的 w 和 h 是预测出的宽度和高度。

因此，减去 w // 2 是为了从中心点坐标计算矩形框的左上角坐标。这种转换是常见的坐标计算逻辑。

2. 为什么去掉会正常，保留可能导致 bbox 漂移？

如果模型的预测本身已经输出了左上角坐标（而不是中心点坐标），再减去 w // 2 会导致左上角坐标错误地向左上角偏移，进而引起 bbox 漂移。
如果去掉减去 w // 2 的操作后结果正确，说明模型的预测值已经是左上角坐标而非中心点坐标。

可能的原因包括：

坐标预处理问题： 在输入模型时，数据预处理是否改变了坐标体系。例如，某些模型可能将输入图像进行了缩放或平移，导致解码时需要额外的调整。
模型实现问题： 不同版本的模型训练方式和输出可能略有差异。如果使用的模型版本与解码逻辑不匹配，就可能导致坐标计算错误。
代码逻辑问题： 如果代码逻辑默认假设模型输出的是中心点，而实际上模型输出的是左上角坐标，则会出现漂移现象。

3. 如何验证并修复？

要验证和修复此问题，可以按照以下步骤操作：

检查模型输出：
- 打印模型解码前的输出值，确定 x1, y1 的实际含义：
```
print(f"Raw x1, y1: {x1}, {y1}")
```
  如果模型输出的值已经是左上角坐标，则不需要减去 w // 2。
检查训练配置：
- 检查模型训练时的配置文件，特别是数据增强（如 resize、padding）是否改变了输入图像的坐标体系。
- 确认解码逻辑与训练配置是否匹配。
调整解码逻辑：
- 如果模型输出的是左上角坐标，可以直接使用预测值。
- 如果模型输出的是中心点坐标，则需要保留减去 w // 2 的操作。
测试更多样本：
- 在调整后，用多张测试图片验证 bbox 是否匹配实际目标。如果仍有漂移，可进一步调试解码逻辑。

4. 参考 Issue 中的类似讨论

在 Issue #14007 中，有用户报告过 SLANet 推理 bbox 坐标异常的问题，其原因与模型解码逻辑中坐标处理不匹配有关。此外，用户通过直接将 bbox 解码逻辑修改为乘以原图宽高解决了问题。

5. 总结建议

短期解决方案： 如果去掉 w // 2 后结果正常，可以暂时保留去掉的逻辑。但需要进一步验证多个样本，确保没有潜在错误。
长期优化方向： 检查模型的训练配置和实现文档，确保解码逻辑与模型输出匹配。

如果您有更多具体代码或模型配置问题，可附上相关信息以便进一步分析！

Response generated by 🤖 feifei-bot | chatgpt-4o-latest

@flow3rdown 你是对的，是有bug。

@flow3rdown 你是对的，是有bug。

用Tablemaster的原始训练权重推理的时候要去掉 w// 2，但是自己微调之后就不能加w // 2了，有点困惑。请问是Tablemaster原始模型在训练时候的数据集有什么特殊之处吗？

模型的实现有变化，导致无法匹配上了。