设计一个通用的ocr框架太难了

文档结构千变万化，十分复杂，想要创建一个非常通用的，能处理各种情况的ocr框架是非常非常难的。我们暂时只能从最基本的情况开始处理，慢慢的增加复杂度，争取可以处理尽可能多的文档。

两个重要的点

• 翻译暂时不能用，改到前端。具体参考 https://www.docpartner-xy.com/feature/trans/
• 晚上12点之后，服务器睡觉（用户量多了之后不会）。

近期工作

先写近期工作吧，后面写问题，因为问题有一大堆。。

• 近期的推广工作：把主要精力放在推广上面。。。程序员（我等）都不太喜欢推广，只喜欢写代码解决问题。。。但推广一定要做的，而且还需要长时间做，下功夫做，盈利才是代码的本质。正如一位伟大的哲学家说的那样：市场决定价值，而金钱是衡量价值的重要标准。

• 代码工作：代码工作要把主要精力放在算法功能的设计和研发上，虽然前后端也很想搞，但是毕竟不是专业的，而且也并非核心竞争力，so...（ps：但你也不能把界面设计的那么丑吧。。而且前端功能还是一半一半的。。你看看，你看看，似乎处在能用不能用之间。额）

• 前端：可以在请求的同时，并行的打开编辑器，然后编辑器等待结果。目前是获取请求结果，然后打开编辑器。

  • 这需要编辑器窗口来获取请求结果，是跨窗口的。

• 近期要增加这样几个图像预处理方面的功能（虽然说是近期，但又不知道是哪个猴年马月）：

  • 支持旋转的图像。要求图像旋转角度在某个范围内，超多该范围则无法处理。这个原理简单，但工程上会有点小难度。图像预处理不能和ocr等解析模型一起运行，所以会增加用户时间，这要求算法在1s内，现在的算法是在 1s-2s 之间(还不算网络时间)，所以要重新工程化一下。
  • 支持多列图像。论文中常见的标题作者摘要然后双列的那种，或者新闻中常见的多列的那种。
  • 无线表格问题。目前有两个表格检测模型，一个可以检测到无线表格，一个不可以，需要将二者的结果综合一下，这里需要一点用户时间。

• 下一些软柿子（以后再说明）：

  • 支持透视变换图片。这是导致手机拍照功能无法正常进行的一个主要原因。
  • 文档检测。
  • 文档背景/颜色。
  • 支持不同方向的图像。90度方向，180度方向，270度方向等。

问题

• 要求不注册账户无法使用功能。之前设计的是，在不注册的情况下，每个ip都有一次试用机会。但现在由于一些原因，我拿不到ip，则只能去掉该功能，否则会有大量错误。
• 正常情况下，平均调用时间在 7-8s 左右，这个时间是有2s左右的网络时间(文件上传和下载一般很耗时)。如果是出现异常，或者某个模型挂了，则会导致解析时间延长到30s左右。
• 表格解析有一个重大的缺陷：表格解析模型对孤立噪声很敏感，而旋转之后的图片会有一些噪声和不清晰，这导致处理后的图片往往无法有效解析表格。
• latexocr 进程会莫名奇妙的没响应了。进程上是 cmd -> python -> worker 进程 -> conn等线程. 到底是哪个进程死了？如果是 conn 连接断了，会报错啊，worker 进程内的问题也会报错啊。后面我打算用 pm2 来挂 python 的 worker 进程，这样如果是 python 挂了 pm2 会重启，cmd 挂了不知道 pm2 会不会重启 cmd。后面进行后端改进的时候，要注意进程服务的稳定性（高可用性）。
• 整个框架是一个可拔插的框架，新增模型只需要添加进来就可以了。但随着逻辑的增多，模型的增多，添加新的模型会越来越难，要把这代码重新设计一下，规整好。
• 模型之间往往是牵一发而动全身。比如新增一个图像预处理模型，该模型会将原始图片分割为多个部分，但总有分割错的时候，这就需要后面的 latexocr、textocr 等等支持一截的图片样本，或者1.5截的图片样本。
• 初始化的时候就加载模型，不要等到调用的时候才加载；每个app进程都要加载一个？？？是的。