|
|
@@ -0,0 +1,30 @@
|
|
|
+简单用形态学做线检测（也就是你在 `paddle_table_classifier` 里的做法）在你的这个例子（数字原生 PDF，线条清晰）中效果确实很好，但在通用场景下，之所以还需要 UNet，是因为**鲁棒性（Robustness）**和**语义理解能力**。
|
|
|
+
|
|
|
+以下是详细对比：
|
|
|
+
|
|
|
+### 1. 核心差异
|
|
|
+
|
|
|
+| 特性 | 传统线检测 (OpenCV 形态学) | 深度学习模型 (UNet) |
|
|
|
+| :--- | :--- | :--- |
|
|
|
+| **原理** | **基于像素**：只看哪里有连续的黑像素。 | **基于上下文**：理解"表格长什么样"。 |
|
|
|
+| **断线处理** | **失败**：扫描件如果线条有断点或打印不清晰，它就认为是断开的，无法构成封闭单元格。 | **成功**：能够"脑补"连接断线，因为它学过表格的结构，知道这里应该有一条线。 |
|
|
|
+| **抗干扰** | **差**：容易把文字下划线、删除线、或者背景噪点误判为表格线。 | **强**：经过训练，能学会忽略文字内容的干扰（如下划线），只提取表格骨架。 |
|
|
|
+| **复杂场景** | **困难**：面对双线边框、虚线、或者线宽不一致的情况很难调参。 | **灵活**：预测的是逻辑上的网格，对线条样式不敏感。 |
|
|
|
+| **泛化性** | **低**：换个分辨率或线宽可能就需要重新调参（kernel size）。 | **高**：模型训练后能适应各种分辨率和来源的文档。 |
|
|
|
+
|
|
|
+### 2. 为什么分类器 ([Classifier](cci:2://file:///Users/zhch158/workspace/repository.git/ocr_platform/ocr_tools/universal_doc_parser/models/adapters/paddle_table_classifier.py:34:0-298:13)) 用简单方法？
|
|
|
+[PaddleTableClassifier](cci:2://file:///Users/zhch158/workspace/repository.git/ocr_platform/ocr_tools/universal_doc_parser/models/adapters/paddle_table_classifier.py:34:0-298:13) 的任务只是**快速筛选**：
|
|
|
+- 它只需要回答“这像不像一个有线表格？”
|
|
|
+- 它只需要一个大概的信号（比如“检测到了大量横竖线”）。
|
|
|
+- **速度至上**：OpenCV 运算极快，不需要加载沉重的模型权重。
|
|
|
+
|
|
|
+### 3. 为什么识别器 ([Recognizer](cci:2://file:///Users/zhch158/workspace/repository.git/ocr_platform/ocr_tools/universal_doc_parser/models/adapters/base.py:72:0-83:12)) 用 UNet？
|
|
|
+[MinerUWiredTableRecognizer](cci:2://file:///Users/zhch158/workspace/repository.git/ocr_platform/ocr_tools/universal_doc_parser/models/adapters/mineru_wired_table.py:29:0-482:64) 的任务是**精准重构**：
|
|
|
+- 它必须保证每一个单元格都是**闭合**的。
|
|
|
+- 它必须保证重构出的网格**严丝合缝**，不能切断文字。
|
|
|
+- 它需要处理歪斜、扭曲、模糊等各种现实世界的“脏”数据。
|
|
|
+
|
|
|
+### 总结
|
|
|
+对于你当前这种**高质量、数字原生**的银行流水单，简单的 OpenCV 线检测确实足够准，甚至可能比 UNet 更快更干净。
|
|
|
+
|
|
|
+但在工业级流水线中，为了兼容扫描件、拍照件、模糊传真等各种不可预测的输入，UNet 是目前的标准选择，因为它更“聪明”，能看懂图像的语义而不仅仅是像素。
|
