团队，感谢你们提供的酷炫的库！
我正在做一个项目，其中输入图像可能被旋转(或包含多种方向的文本),所以尝试使用 rotation_info=[90, 180, 270] 来处理这个问题。
...但是在下游处理过程中，我需要知道输出中检测到的文本的方向。
我希望这能在输出框中反映出来，与检测到的文本具有一致的TL-TR-BR-BL关系：这样你可以通过比较前两个(和/或后两个)点来计算每个单词的倾斜/Angular 。不幸的是，这似乎并不是这样：框坐标似乎是相对于输入图像的TL-TR-BR-BL,而不管文本是朝上还是朝下。
如果我理解正确的话(?),EasyOCR在检测到文本之后的框检测和文本识别之间应用了rotation_info:在将裁剪/变换后的单词图像片段传递给识别器之前对其进行旋转。原始/原始框在这个过程中保持不变。

建议的解决方案

我的建议是根据应用的旋转Angular 对结果中的边界框点的顺序进行排列。
例如：

[
  [265.31671842700024, 19.658359213500127],
  [338.5868575814821, 3.48073443627241],
  [343.68328157299976, 27.341640786499873],
  [270.4131424185179, 43.519265563727586]
]

当在 180 Angular 下最有可能被识别时，变为：

[
  [343.68328157299976, 27.341640786499873],
  [270.4131424185179, 43.519265563727586],
  [265.31671842700024, 19.658359213500127],
  [338.5868575814821, 3.48073443627241]
]

...这样边界框/多边形就能反映文本的真实“倒置”Angular 。例如，仅使用顶部坐标：math.degrees(math.atan2(y0-y1, x1-x0)) ~ -167度(y0-y1作为y轴从上到下运行)

替代方案

上述假设只要求/适当支持90度的增量，我认为这是正确的，但可能遗漏了一些东西。既然检测器已经在寻找方向，那么是否可以说例如“将检测器找到的Angular 偏移10度”？
另一个选择可能是将选定的旋转值与框一起传递到输出中，但我认为这样做会暴露出比用户实际需要更多的内部复杂性？

披露

我现在在AWS工作(但帮助我们的客户构建解决方案，而不是构建AWS服务本身),也是亚马逊Textract的常规用户...所以并不打算以任何方式不当地引导你们的设计，但可能会受到我熟悉的使用方式的影响！