Proposal: optional Pillow backend to avoid OpenCV/Shapely dependency

[MomiJiSan]

Summary

Would the RapidOCR maintainers be open to an optional Pillow/numpy/scipy image-processing backend for the legacy rapidocr-onnxruntime package, so deployments that already use ONNX Runtime can avoid pulling OpenCV and Shapely when they do not otherwise need them?

I am working on a downstream desktop app that embeds rapidocr-onnxruntime==1.4.4 as an OCR backend. In that dependency chain, OpenCV and Shapely are the only heavy transitive packages that are not otherwise needed by the app runtime.

Downstream experiment

I built a local proof-of-concept fork based on rapidocr-onnxruntime==1.4.4 with the import package name kept as rapidocr_onnxruntime for compatibility.

Dependency changes in the fork:

• Removed: opencv-python, opencv-python-headless, shapely, six, tqdm
• Kept: numpy, onnxruntime, Pillow, pyclipper, PyYAML, scipy

PyYAML is intentionally kept because the read_yaml() configuration path still needs it.

Replacement mapping used in the experiment

The v1.4.4 code path mostly uses OpenCV for image I/O, resizing, channel conversion, DB post-processing, perspective crop, and visualization helpers. The downstream fork replaced those with:

• Pillow for image read/write and simple visual drawing
• numpy for channel conversion, arithmetic, polygon area/perimeter, and perspective matrix solving
• scipy.ndimage for dilation / coordinate mapping where needed
• pyclipper remains responsible for the DB unclip offset operation

One important detail from the experiment: cv2.dilate(..., kernel=np.ones((2, 2))) needed a matching anchor/origin behavior. Using scipy's default origin shifted the DB mask enough to change OCR results. Matching OpenCV's 2x2 anchor fixed the detected box parity in our tests.

Validation performed downstream

The local fork currently passes these checks in our downstream app:

• No cv2 or shapely imports/usages remain in the fork source
• Fork metadata excludes OpenCV/Shapely/six/tqdm and keeps PyYAML/pyclipper
• Helper parity checks against OpenCV/Shapely for color conversion, masks, add, border, polygon area/perimeter, min-area boxes, resize, and perspective point mapping
• Full RapidOCR smoke test with cv2 and shapely absent from the active environment
• Synthetic OCR corpus exact text comparison against upstream rapidocr-onnxruntime==1.4.4 + opencv-python==4.11.0.86
  • 60 generated samples total
  • 20 Chinese-like text images
  • 20 Japanese-like text images
  • 10 mixed CJK/English images
  • 5 vertical text images
  • 5 tilted text images
  • Result: all OCR text outputs matched exactly in that corpus

Question

Would you be interested in a PR that introduces this as an optional backend or otherwise removes the hard OpenCV/Shapely dependency for the onnxruntime package?

If yes, I can prepare the change in the structure you prefer. If no, we will keep maintaining this as a downstream fork.

[SWHL]

I'm wondering why you're planning to remove the dependencies on OpenCV and Shapely. Do these two packages consume a lot of resources? Is Pillow a better alternative?

[MomiJiSan]

I'm wondering why you're planning to remove the dependencies on OpenCV and Shapely. Do these two packages consume a lot of resources? Is Pillow a better alternative?

The reason we’re considering removing OpenCV and Shapely is that they are introduced through RapidOCR’s upstream dependency chain and add extra package size and native dependency complexity to our program. Based on our current usage, we don’t directly rely on OpenCV or Shapely in our own code, and the parts RapidOCR uses them for may be replaceable with lighter alternatives.
That said, we’re not saying Pillow is definitely a better choice yet. The plan is to first test whether Pillow, together with numpy/scipy where needed, can cover the OpenCV/Shapely-related functionality without affecting OCR accuracy or stability. If the replacement works well, we can reduce the dependency footprint. If it causes regressions, we should keep the original dependencies.

Thank you for taking the time to reply.

[SWHL]

I understand your point. So far, replacing OpenCV with Pillow is a feasible solution, as long as there is no significant loss in accuracy. We can extract only the necessary code implementations from the Shapely source code and integrate them directly into the project.

Given that this is not a general-purpose requirement, I won't merge this into the main codebase for now. That said, you're welcome to build it as a standalone library, and I’d be glad to help promote it.

If this solution gains popularity among users later on, I can always port it to the existing repository then. What do you think?

[MomiJiSan]

我明白你的意思。目前来看，只要精度损失不大，用 Pillow 替换 OpenCV 是一个可行的方案。我们可以从 Shapely 的源代码中提取必要的代码实现，并直接集成到项目中。

鉴于这不是一个通用需求，我暂时不会将其合并到主代码库中。不过，欢迎您将其构建为一个独立的库，我很乐意协助推广。

如果这个方案以后受到用户的欢迎，我可以把它移植到现有的代码库里。你觉得怎么样？

Thanks for the detailed reply!We have validated the Pillow-based replacement in our downstream use case, and so far it looks workable: OCR results are stable, and it helps us remove the heavy OpenCV dependency from our packaged app.That said, we currently do not have enough spare bandwidth to maintain this as a standalone library. We will keep it as a downstream fork/patch for now.Thanks again for the guidance and for considering the use case.