-
|
如题所述。我之前在使用 RapidLayout 的时候，使用 doclayout_d4la 是可以直接识别出来我常用文档的区域块的。但是更新到 V1.0 再做测试的时候。我发现预览图片变成反色了，而且以前能识别出来的区域现在基本都识别不出来了。而且我试了所有模型，都无法直接开箱即用了。现在想要问一下如下的两个问题：
纯小白，过蠢勿怪，还希望大佬能够解答🙏 |
Beta Was this translation helpful? Give feedback.
Replies: 4 comments 9 replies
-
|
敢于提出问题就难能可贵了。可否说的详细一些呢？ 给出详细可复现的例子来，我这里也好跟进呢。比如颜色反转问题？啥样的？ 开箱即用？v1.0属于大版本号升级，接口不向下兼容，因此，需要根据返回结果适配一下 |
Beta Was this translation helpful? Give feedback.
-
|
谢谢大佬回复，是这样的，我们是做信鸽相关的，极为小众的一个行业。我们这边会有很多血统书。然后我们在做OCR识别血统书信息，并进行入库。大概血统书是长这个样子的（这是模版，全部内容不方便展示，见谅）： 
但是每个方块里的内容类似下面的： 在以前，这些模版直接通过 RapidLayout 的 doclayout_d4la进行解析，是可以直接标记出这些方框的。 
之后我们会针对每一个方框内的内容进行裁剪识别，解析具体的字段。 最近我们的要求更进了一步，要求也能识别别人家的血统书（比我们的更加不规整，甚至连线框都不会有）。于是我尝试使用 RapidLayout V1，对服务进行一次升级。结果测试过程中，我发现我使用V0.4版本的模型和参数，出现了无法识别的问题。我查看了 Layout 的输出，发现文件出现了反色，如下： 
因为红色的字体变成了蓝色的，黑色的字体变成了白色的，所以我推测是做了反色？（应该不是，不太确定） 我该怎么调整才能保证不会颜色变换？ 或者说其实颜色变换不不变换都无所谓，因为后续识别别人家的血统书几乎都不会带有线框的。我应该训练模型来识别这种大块的文本区域？ |
Beta Was this translation helpful? Give feedback.
-
|
颜色反转，我猜测原图是PNG格式，本身就是透明的。你可以试试先将图像转为jpg格式，再试试看 |
Beta Was this translation helpful? Give feedback.
-
刚才试了一下，发现不是这个原因，我转换了jpg 格式，然后再进行识别，输出结果依旧是颜色反转的 😓 |
Beta Was this translation helpful? Give feedback.
-
|
颜色反转的原图可以打包一下，发给我不。可以邮箱给我liekkaskono@163.com，方便的话，直接贴在这里也可。 |
Beta Was this translation helpful? Give feedback.
-
已发送，感谢大佬抽时间帮忙看🙏 |
Beta Was this translation helpful? Give feedback.
-
|
get |
Beta Was this translation helpful? Give feedback.
-
|
哈喽，问题解决了吗？实在不好意思，之前事情太多，一来二去就给忘记了。现在问题解决了吗？ |
Beta Was this translation helpful? Give feedback.
-
|
已经解决了。我后来又仔细的看了一遍源码。发现 if img.ndim == 3:
img = cv2.cvtColor(img, cv2.COLOR_RGB2BGR)所以导致PNG图像加载后， RGBA -> BGR 缺失了白底。正好我也在使用 RapidOCR，RapidUndistorted，仔细都看了一下发现每个库的 def convert_img(self, img: np.ndarray, origin_img_type: Any) -> np.ndarray:
if img.ndim == 2:
return cv2.cvtColor(img, cv2.COLOR_GRAY2BGR)
elif img.ndim == 3 and (channel := img.shape[2]):
if channel == 1:
return cv2.cvtColor(img, cv2.COLOR_GRAY2BGR)
elif channel == 2:
return self.cvt_two_to_three(img)
elif channel == 3:
if issubclass(origin_img_type, (str, Path, bytes, Image.Image)):
return cv2.cvtColor(img, cv2.COLOR_RGB2BGR)
return img
elif channel == 4:
img = self.cvt_four_to_three(img)
return cv2.cvtColor(img, cv2.COLOR_RGB2BGR)
raise LoadImageError(f"The ndim({img.ndim}) of the img is not in [2, 3]")然后问题就完美的解决了。 如果有空的话，我可以帮忙提交一下PR， 把三个库的 |
Beta Was this translation helpful? Give feedback.
-
|
我刚才查看了RapidOCR中这部分的最新代码 → link，我看着应该是和你这里一样了。我不太确定是不是已经修复了。可否帮忙看一下这里。 我刚才看错了。欢迎您这里提交一下PR哈。统一功能和调整 |
Beta Was this translation helpful? Give feedback.
-
|
好的，我有空了看一下。有些内容我可能需要测试一下。因为我这个修复方法的前提是我的 png 图片都是白底的，像你说的之前兼容了透明图层的话，那我得多花些时间测试一下才行。 |
Beta Was this translation helpful? Give feedback.
-
|
好的，我来跟进统一一下
…---- 回复的原邮件 ----
| 发件人 | ***@***.***> |
| 发送日期 | 2026年02月12日 08:55 |
| 收件人 | RapidAI/RapidLayout ***@***.***> |
| 抄送人 | SWHL ***@***.***>,
Comment ***@***.***> |
| 主题 | Re: [RapidAI/RapidLayout] 【提问】V1.0 之后是不是代码底层流程改变了？ (Discussion #44) |
已经解决了。我后来又仔细的看了一遍源码。发现 load_image.py 文件中 类 LoadImage 在后续的提交中，主动去除掉了 __call__ 函数中对这里的调用：
ifimg.ndim==3:
img=cv2.cvtColor(img, cv2.COLOR_RGB2BGR)
所以导致PNG图像加载后， RGBA -> BGR 缺失了白底。正好我也在使用 RapidOCR，RapidUndistorted，仔细都看了一下发现每个库的 load_image 文件 实现细节都不一样。我为了统一使用同一个文件夹加载器，并且避免已经加载过的 ndarray 在流转的时候反复的去做额外的判断，就继承了 LoadImage 类，重写了 convert_img 方法，把 cv2.cvtColor(img, cv2.COLOR_RGB2BGR) 的逻辑补充回去了。
defconvert_img(self, img: np.ndarray, origin_img_type: Any) ->np.ndarray:
ifimg.ndim==2:
returncv2.cvtColor(img, cv2.COLOR_GRAY2BGR)
elifimg.ndim==3and (channel:=img.shape[2]):
ifchannel==1:
returncv2.cvtColor(img, cv2.COLOR_GRAY2BGR)
elifchannel==2:
returnself.cvt_two_to_three(img)
elifchannel==3:
ifissubclass(origin_img_type, (str, Path, bytes, Image.Image)):
returncv2.cvtColor(img, cv2.COLOR_RGB2BGR)
returnimgelifchannel==4:
img=self.cvt_four_to_three(img)
returncv2.cvtColor(img, cv2.COLOR_RGB2BGR)
raiseLoadImageError(f"The ndim({img.ndim}) of the img is not in [2, 3]")
然后问题就完美的解决了。
如果有空的话，我可以帮忙提交一下PR， 把三个库的 load_image.py 功能统一一下。并把 vis 功能也规整一下，避免同一个系列的不同库相互之间加载文件，保存预览效果不统一的问题。
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
那太好了，那就麻烦你了，相信以后体验会越来越好！😊 |
Beta Was this translation helpful? Give feedback.
已经解决了。我后来又仔细的看了一遍源码。发现
load_image.py文件中 类LoadImage在后续的提交中，主动去除掉了__call__函数中对这里的调用：所以导致PNG图像加载后， RGBA -> BGR 缺失了白底。正好我也在使用 RapidOCR，RapidUndistorted，仔细都看了一下发现每个库的
load_image文件 实现细节都不一样。我为了统一使用同一个文件夹加载器，并且避免已经加载过的 ndarray 在流转的时候反复的去做额外的判断，就继承了LoadImage类，重写了convert_img方法，把cv2.cvtColor(img, cv2.COLOR_RGB2BGR)的逻辑补充回去了。