fix(ocr): support Japanese kana word boxes#5168
Open
Ikwus wants to merge 1 commit into
Open
Conversation
3 tasks
|
Thanks for your contribution! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fix Japanese kana word-box grouping when OCR is run with
return_word_box=True.Japanese Hiragana, Katakana, the prolonged sound mark, and halfwidth Katakana are now treated as character-level word-box characters while keeping the existing
cnstate name for backward compatibility.Fixes PaddlePaddle/PaddleOCR#18222
Prior Art / Search
I searched the PaddleOCR docs, issues, and discussions. I found related
return_word_boxreports and fixes for accented Latin text and Arabic text, but I did not find a Japanese kana-specific report.This PR is still worth tracking separately because Japanese kana currently gets phrase-level boxes while Japanese/Chinese Han characters already get character-level boxes. That makes Japanese mixed-script output inconsistent for downstream consumers of
text_wordandtext_word_boxes.Related context:
Root Cause
BaseRecLabelDecode.get_word_info()only classified CJK Unified Ideographs (\u4e00-\u9fff) ascn. Japanese kana fell intosymbol.cal_ocr_word_box()expandsstate == "cn"groups to character-level boxes, but non-cngroups are returned as one grouped box. Therefore kana-only Japanese text could be returned as a single phrase-level word box, while Han characters already returned character-level boxes.Fix
Add a small kana classifier for:
Then route those characters to the existing
cnstate so the downstream word-box logic keeps returning character-level boxes without renaming or changing the public state value.Reproduction
A synthetic image is enough; no real document image is required.
Observed grouping with PP-OCRv6 medium OCR and
return_word_box=True:りんごジュースストレート東京都中央区請求書東京りんごジュース東,京,りんごジュースI checked the same synthetic patterns with Noto Sans CJK JP Medium, Noto Sans CJK JP Bold, and Noto Serif CJK JP SemiBold.
Tests
There was no existing unit test file for
BaseRecLabelDecode.get_word_info()orreturn_word_boxword grouping in PaddleX, so this PR adds focused unit coverage undertests/.python -m py_compile paddlex/inference/models/text_recognition/processors.py tests/test_text_recognition_word_info.pypython -m pytest tests/test_text_recognition_word_info.py