PaddleOCR常見問題彙總

更新（2021.2.22）

Q3.1.42: 訓練識別任務的時候，在CPU上運行時，報錯The setting of Parameter-Server must has server_num or servers。

A：這是訓練任務啟動方式不對造成的。

1. 在使用CPU或者單塊GPU訓練的時候，可以直接使用python3 tools/train.py -c xxx.yml的方式啟動。

2. 在使用多塊GPU訓練的時候，需要使用distributed.launch的方式啟動，如python3 -m paddle.distributed.launch --gpus '0,1,2,3' tools/train.py -c xxx.yml，這種方式需要安裝NCCL庫，如果沒有的話會報錯。

Q3.1.43：使用StyleText進行數據合成時，文本(TextInput)的長度遠超StyleInput的長度，該怎麼處理與合成呢？

A：在使用StyleText進行數據合成的時候，建議StyleInput的長度長於TextInput的長度。有2種方法可以處理上述問題：

1. 將StyleInput按列的方向進行複製與擴充，直到其超過TextInput的長度。

2. 將TextInput進行裁剪，保證每段TextInput都稍短於StyleInput，分別合成之後，再拚接在一起。

實際使用中發現，使用第2種方法的效果在長文本合成的場景中的合成效果更好，StyleText中提供的也是第2種數據合成的邏輯。

Q3.4.37: 在windows上進行cpp inference的部署時，總是提示找不到paddle_fluid.dll和opencv_world346.dll，

A：有2種方法可以解決這個問題：

1. 將paddle預測庫和opencv庫的地址添加到係統環境變量中。

2. 將提示缺失的dll文件拷貝到編譯產出的ocr_system.exe文件夾中。

Q3.4.38：想在Mac上部署，從哪裏下載預測庫呢？

A：Mac上的Paddle預測庫可以從這裏下載：https://paddle-inference-lib.bj.bcebos.com/mac/2.0.0/cpu_avx_openblas/paddle_inference.tgz

Q3.4.39：內網環境如何進行服務化部署呢？

A：仍然可以使用PaddleServing或者HubServing進行服務化部署，保證內網地址可以訪問即可。

【精選】OCR精選10個問題

Q1.1.1：基於深度學習的文字檢測方法有哪幾種？各有什麼優缺點？

A：常用的基於深度學習的文字檢測方法一般可以分為基於回歸的、基於分割的兩大類，當然還有一些將兩者進行結合的方法。

（1）基於回歸的方法分為box回歸和像素值回歸。a. 采用box回歸的方法主要有CTPN、Textbox係列和EAST，這類算法對規則形狀文本檢測效果較好，但無法準確檢測不規則形狀文本。 b. 像素值回歸的方法主要有CRAFT和SA-Text，這類算法能夠檢測彎曲文本且對小文本效果優秀但是實時性能不夠。

（2）基於分割的算法，如PSENet，這類算法不受文本形狀的限製，對各種形狀的文本都能取得較好的效果，但是往往後處理比較複雜，導致耗時嚴重。目前也有一些算法專門針對這個問題進行改進，如DB，將二值化進行近似，使其可導，融入訓練，從而獲取更準確的邊界，大大降低了後處理的耗時。

Q1.1.2：對於中文行文本識別，CTC和Attention哪種更優？

A：（1）從效果上來看，通用OCR場景CTC的識別效果優於Attention，因為帶識別的字典中的字符比較多，常用中文漢字三千字以上，如果訓練樣本不足的情況下，對於這些字符的序列關係挖掘比較困難。中文場景下Attention模型的優勢無法體現。而且Attention適合短語句識別，對長句子識別比較差。

（2）從訓練和預測速度上，Attention的串行解碼結構限製了預測速度，而CTC網絡結構更高效，預測速度上更有優勢。

Q1.1.3：彎曲形變的文字識別需要怎麼處理？TPS應用場景是什麼，是否好用？

A：（1）在大多數情況下，如果遇到的場景彎曲形變不是太嚴重，檢測4個頂點，然後直接通過仿射變換轉正識別就足夠了。

（2）如果不能滿足需求，可以嚐試使用TPS（Thin Plate Spline），即薄板樣條插值。TPS是一種插值算法，經常用於圖像變形等，通過少量的控製點就可以驅動圖像進行變化。一般用在有彎曲形變的文本識別中，當檢測到不規則的/彎曲的（如，使用基於分割的方法檢測算法）文本區域，往往先使用TPS算法對文本區域矯正成矩形再進行識別，如，STAR-Net、RARE等識別算法中引入了TPS模塊。 Warning：TPS看起來美好，在實際應用時經常發現並不夠魯棒，並且會增加耗時，需要謹慎使用。

Q1.1.4：簡單的對於精度要求不高的OCR任務，數據集需要準備多少張呢？

A：（1）訓練數據的數量和需要解決問題的複雜度有關係。難度越大，精度要求越高，則數據集需求越大，而且一般情況實際中的訓練數據越多效果越好。

（2）對於精度要求不高的場景，檢測任務和識別任務需要的數據量是不一樣的。對於檢測任務，500張圖像可以保證基本的檢測效果。對於識別任務，需要保證識別字典中每個字符出現在不同場景的行文本圖像數目需要大於200張（舉例，如果有字典中有5個字，每個字都需要出現在200張圖片以上，那麼最少要求的圖像數量應該在200-1000張之間），這樣可以保證基本的識別效果。

Q1.1.5：背景幹擾的文字（如印章蓋到落款上，需要識別落款或者印章中的文字），如何識別？

A：（1）在人眼確認可識別的條件下，對於背景有幹擾的文字，首先要保證檢測框足夠準確，如果檢測框不準確，需要考慮是否可以通過過濾顏色等方式對圖像預處理並且增加更多相關的訓練數據；在識別的部分，注意在訓練數據中加入背景幹擾類的擴增圖像。

（2）如果MobileNet模型不能滿足需求，可以嚐試ResNet係列大模型來獲得更好的效果 。

Q1.1.6：OCR領域常用的評估指標是什麼？

A：對於兩階段的可以分開來看，分別是檢測和識別階段

（1）檢測階段：先按照檢測框和標注框的IOU評估，IOU大於某個閾值判斷為檢測準確。這裏檢測框和標注框不同於一般的通用目標檢測框，是采用多邊形進行表示。檢測準確率：正確的檢測框個數在全部檢測框的占比，主要是判斷檢測指標。檢測召回率：正確的檢測框個數在全部標注框的占比，主要是判斷漏檢的指標。

（2）識別階段： 字符識別準確率，即正確識別的文本行占標注的文本行數量的比例，隻有整行文本識別對才算正確識別。

（3）端到端統計： 端對端召回率：準確檢測並正確識別文本行在全部標注文本行的占比； 端到端準確率：準確檢測並正確識別文本行在 檢測到的文本行數量 的占比； 準確檢測的標準是檢測框與標注框的IOU大於某個閾值，正確識別的的檢測框中的文本與標注的文本相同。

Q1.1.7：單張圖上多語種並存識別（如單張圖印刷體和手寫文字並存），應該如何處理？

A：單張圖像中存在多種類型文本的情況很常見，典型的以學生的試卷為代表，一張圖像同時存在手寫體和印刷體兩種文本，這類情況下，可以嚐試”1個檢測模型+1個N分類模型+N個識別模型”的解決方案。 其中不同類型文本共用同一個檢測模型，N分類模型指額外訓練一個分類器，將檢測到的文本進行分類，如手寫+印刷的情況就是二分類，N種語言就是N分類，在識別的部分，針對每個類型的文本單獨訓練一個識別模型，如手寫+印刷的場景，就需要訓練一個手寫體識別模型，一個印刷體識別模型，如果一個文本框的分類結果是手寫體，那麼就傳給手寫體識別模型進行識別，其他情況同理。

Q1.1.8：請問PaddleOCR項目中的中文超輕量和通用模型用了哪些數據集？訓練多少樣本，gpu什麼配置，跑了多少個epoch，大概跑了多久？

A： （1）檢測的話，LSVT街景數據集共3W張圖像，超輕量模型，150epoch左右，2卡V100 跑了不到2天；通用模型：2卡V100 150epoch 不到4天。 （2） 識別的話，520W左右的數據集（真實數據26W+合成數據500W）訓練，超輕量模型：4卡V100，總共訓練了5天左右。通用模型：4卡V100，共訓練6天。

超輕量模型訓練分為2個階段： (1)全量數據訓練50epoch，耗時3天 (2)合成數據+真實數據按照1:1數據采樣，進行finetune訓練200epoch，耗時2天

通用模型訓練： 真實數據+合成數據，動態采樣(1：1)訓練，200epoch，耗時 6天左右。

Q1.1.9：PaddleOCR模型推理方式有幾種？各自的優缺點是什麼

A：目前推理方式支持基於訓練引擎推理和基於預測引擎推理。

（1）基於訓練引擎推理不需要轉換模型，但是需要先組網再load參數，語言隻支持python，不適合係統集成。

（2）基於預測引擎的推理需要先轉換模型為inference格式，然後可以進行不需要組網的推理，語言支持c++和python，適合係統集成。

Q1.1.10：PaddleOCR中，對於模型預測加速，CPU加速的途徑有哪些？基於TenorRT加速GPU對輸入有什麼要求？

A：（1）CPU可以使用mkldnn進行加速；對於python inference的話，可以把enable_mkldnn改為true，參考代碼，對於cpp inference的話，在配置文件裏麵配置use_mkldnn 1即可，參考代碼

（2）GPU需要注意變長輸入問題等，TRT6 之後才支持變長輸入

【理論篇】OCR通用問題

基礎知識

Q2.1.1：CRNN能否識別兩行的文字?還是說必須一行？

A：CRNN是一種基於1D-CTC的算法，其原理決定無法識別2行或多行的文字，隻能單行識別。

Q2.1.2：怎麼判斷行文本圖像是否是顛倒的？

A：有兩種方案：（1）原始圖像和顛倒圖像都進行識別預測，取得分較高的為識別結果。 （2）訓練一個正常圖像和顛倒圖像的方向分類器進行判斷。

Q2.1.3：目前OCR普遍是二階段，端到端的方案在業界落地情況如何？

A：端到端在文字分布密集的業務場景，效率會比較有保證，精度的話看自己業務數據積累情況，如果行級別的識別數據積累比較多的話two-stage會比較好。百度的落地場景，比如工業儀表識別、車牌識別都用到端到端解決方案。

Q2.1.4 印章如何識別

A：1. 使用帶tps的識別網絡或abcnet,2.使用極坐標變換將圖片拉平之後使用crnn

Q2.1.5 多語言的字典裏是混合了不同的語種，這個是有什麼講究嗎？統一到一個字典裏會對精度造成多大的損失？

A：統一到一個字典裏，會造成最後一層FC過大，增加模型大小。如果有特殊需求的話，可以把需要的幾種語言合並字典訓練模型，合並字典之後如果引入過多的形近字，可能會造成精度損失，字符平衡的問題可能也需要考慮一下。在PaddleOCR裏暫時將語言字典分開。

Q2.1.6 預處理部分，圖片的長和寬為什麼要處理成32的倍數？

A：以檢測中的resnet骨幹網絡為例，圖像輸入網絡之後，需要經過5次2倍降采樣，共32倍，因此建議輸入的圖像尺寸為32的倍數。

Q2.1.7：類似泰語這樣的小語種，部分字會占用兩個字符甚至三個字符，請問如何製作字典。

A：處理字符的時候，把多字符的當作一個字就行，字典中每行是一個字。

數據集

Q2.2.1：支持空格的模型，標注數據的時候是不是要標注空格？中間幾個空格都要標注出來麼？

A：如果需要檢測和識別模型，就需要在標注的時候把空格標注出來，而且在字典中增加空格對應的字符。標注過程中，如果中間幾個空格標注一個就行。

Q2.2.2：如果考慮支持豎排文字識別，相關的數據集如何合成？

A：豎排文字與橫排文字合成方式相同，隻是選擇了垂直字體。合成工具推薦：text_renderer

Q2.2.3：訓練文字識別模型，真實數據有30w，合成數據有500w，需要做樣本均衡嗎？

A：需要，一般需要保證一個batch中真實數據樣本和合成數據樣本的比例是1：1~1：3左右效果比較理想。如果合成數據過大，會過擬合到合成數據，預測效果往往不佳。還有一種啟發性的嚐試是可以先用大量合成數據訓練一個base模型，然後再用真實數據微調，在一些簡單場景效果也是會有提升的。

Q2.2.4：請問一下，豎排文字識別時候，字的特征已經變了，這種情況在數據集和字典標注是新增一個類別還是多個角度的字共享一個類別？

A：可以根據實際場景做不同的嚐試，共享一個類別是可以收斂，效果也還不錯。但是如果分開訓練，同類樣本之間一致性更好，更容易收斂，識別效果會更優。

Q2.2.5： 文本行較緊密的情況下如何準確檢測？

A：使用基於分割的方法，如DB，檢測密集文本行時，最好收集一批數據進行訓練，並且在訓練時，並將生成二值圖像的shrink_ratio參數調小一些。

Q2.2.6: 當訓練數據量少時，如何獲取更多的數據？

A：當訓練數據量少時，可以嚐試以下三種方式獲取更多的數據：（1）人工采集更多的訓練數據，最直接也是最有效的方式。（2）基於PIL和opencv基本圖像處理或者變換。例如PIL中ImageFont, Image, ImageDraw三個模塊將文字寫到背景中，opencv的旋轉仿射變換，高斯濾波等。（3）利用數據生成算法合成數據，例如pix2pix等算法。

Q2.2.7: 論文《Editing Text in the Wild》中文本合成方法SRNet有什麼特點？

A：SRNet是借鑒GAN中圖像到圖像轉換、風格遷移的想法合成文本數據。不同於通用GAN的方法隻選擇一個分支，SRNet將文本合成任務分解為三個簡單的子模塊，提升合成數據的效果。這三個子模塊為不帶背景的文本風格遷移模塊、背景抽取模塊和融合模塊。PaddleOCR計劃將在2020年12月中旬開源基於SRNet的實用模型。

模型訓練調優

Q2.3.1：如何更換文本檢測/識別的backbone？

A：無論是文字檢測，還是文字識別，骨幹網絡的選擇是預測效果和預測效率的權衡。一般，選擇更大規模的骨幹網絡，例如ResNet101_vd，則檢測或識別更準確，但預測耗時相應也會增加。而選擇更小規模的骨幹網絡，例如MobileNetV3_small_x0_35，則預測更快，但檢測或識別的準確率會大打折扣。幸運的是不同骨幹網絡的檢測或識別效果與在ImageNet數據集圖像1000分類任務效果正相關。飛槳圖像分類套件PaddleClas彙總了ResNet_vd、Res2Net、HRNet、MobileNetV3、GhostNet等23種係列的分類網絡結構，在上述圖像分類任務的top1識別準確率，GPU(V100和T4)和CPU(驍龍855)的預測耗時以及相應的117個預訓練模型下載地址。

（1）文字檢測骨幹網絡的替換，主要是確定類似與ResNet的4個stages，以方便集成後續的類似FPN的檢測頭。此外，對於文字檢測問題，使用ImageNet訓練的分類預訓練模型，可以加速收斂和效果提升。

（2）文字識別的骨幹網絡的替換，需要注意網絡寬高stride的下降位置。由於文本識別一般寬高比例很大，因此高度下降頻率少一些，寬度下降頻率多一些。可以參考PaddleOCR中MobileNetV3骨幹網絡的改動。

Q2.3.2：文本識別訓練不加LSTM是否可以收斂？

A：理論上是可以收斂的，加上LSTM模塊主要是為了挖掘文字之間的序列關係，提升識別效果。對於有明顯上下文語義的場景效果會比較明顯。

Q2.3.3：文本識別中LSTM和GRU如何選擇？

A：從項目實踐經驗來看，序列模塊采用LSTM的識別效果優於GRU，但是LSTM的計算量比GRU大一些，可以根據自己實際情況選擇。

Q2.3.4：對於CRNN模型，backbone采用DenseNet和ResNet_vd，哪種網絡結構更好？

A：Backbone的識別效果在CRNN模型上的效果，與Imagenet 1000 圖像分類任務上識別效果和效率一致。在圖像分類任務上ResnNet_vd（79%+）的識別精度明顯優於DenseNet（77%+），此外對於GPU，Nvidia針對ResNet係列模型做了優化，預測效率更高，所以相對而言，resnet_vd是較好選擇。如果是移動端，可以優先考慮MobileNetV3係列。

Q2.3.5：訓練識別時，如何選擇合適的網絡輸入shape？

A：一般高度采用32，最長寬度的選擇，有兩種方法：

（1）統計訓練樣本圖像的寬高比分布。最大寬高比的選取考慮滿足80%的訓練樣本。

（2）統計訓練樣本文字數目。最長字符數目的選取考慮滿足80%的訓練樣本。然後中文字符長寬比近似認為是1，英文認為3：1，預估一個最長寬度。

Q2.3.6：如何識別文字比較長的文本？

A：在中文識別模型訓練時，並不是采用直接將訓練樣本縮放到[3,32,320]進行訓練，而是先等比例縮放圖像，保證圖像高度為32，寬度不足320的部分補0，寬高比大於10的樣本直接丟棄。預測時，如果是單張圖像預測，則按上述操作直接對圖像縮放，不做寬度320的限製。如果是多張圖預測，則采用batch方式預測，每個batch的寬度動態變換，采用這個batch中最長寬度。

Q2.3.7：識別訓練時，訓練集精度已經到達90了，但驗證集精度一直在70，漲不上去怎麼辦？

A：訓練集精度90，測試集70多的話，應該是過擬合了，有兩個可嚐試的方法：

（1）加入更多的增廣方式或者調大增廣prob的概率，默認為0.4。

（2）調大係統的l2 dcay值

Q2.3.8：請問對於圖片中的密集文字，有什麼好的處理辦法嗎？

A：可以先試用預訓練模型測試一下，例如DB+CRNN，判斷下密集文字圖片中是檢測還是識別的問題，然後針對性的改善。還有一種是如果圖象中密集文字較小，可以嚐試增大圖像分辨率，對圖像進行一定範圍內的拉伸，將文字稀疏化，提高識別效果。

Q2.3.9：對於一些在識別時稍微模糊的文本，有沒有一些圖像增強的方式？

A：在人類肉眼可以識別的前提下，可以考慮圖像處理中的均值濾波、中值濾波或者高斯濾波等模糊算子嚐試。也可以嚐試從數據擴增擾動來強化模型魯棒性，另外新的思路有對抗性訓練和超分SR思路，可以嚐試借鑒。但目前業界尚無普遍認可的最優方案，建議優先在數據采集階段增加一些限製提升圖片質量。

Q2.3.10：對於特定文字檢測，例如身份證隻檢測姓名，檢測指定區域文字更好，還是檢測全部區域再篩選更好？

A：兩個角度來說明一般檢測全部區域再篩選更好。

（1）由於特定文字和非特定文字之間的視覺特征並沒有很強的區分行，隻檢測指定區域，容易造成特定文字漏檢。

（2）產品的需求可能是變化的，不排除後續對於模型需求變化的可能性（比如又需要增加一個字段），相比於訓練模型，後處理的邏輯會更容易調整。

Q2.3.11：對於小白如何快速入門中文OCR項目實踐？

A：建議可以先了解OCR方向的基礎知識，大概了解基礎的檢測和識別模型算法。然後在Github上可以查看OCR方向相關的repo。目前來看，從內容的完備性來看，PaddleOCR的中英文雙語教程文檔是有明顯優勢的，在數據集、模型訓練、預測部署文檔詳實，可以快速入手。而且還有微信用戶群答疑，非常適合學習實踐。項目地址：PaddleOCR

Q3.12：如何識別帶空格的英文行文本圖像？

A：空格識別可以考慮以下兩種方案：

(1)優化文本檢測算法。檢測結果在空格處將文本斷開。這種方案在檢測數據標注時，需要將含有空格的文本行分成好多段。

(2)優化文本識別算法。在識別字典裏麵引入空格字符，然後在識別的訓練數據中，如果用空行，進行標注。此外，合成數據時，通過拚接訓練數據，生成含有空格的文本。

Q2.3.13：中英文一起識別時也可以加空格字符來訓練嗎

A：中文識別可以加空格當做分隔符訓練，具體的效果如何沒法給出直接評判，根據實際業務數據訓練來判斷。

Q2.3.14：低像素文字或者字號比較小的文字有什麼超分辨率方法嗎

A：超分辨率方法分為傳統方法和基於深度學習的方法。基於深度學習的方法中，比較經典的有SRCNN，另外CVPR2020也有一篇超分辨率的工作可以參考文章：Unpaired Image Super-Resolution using Pseudo-Supervision，但是沒有充分的實踐驗證過，需要看實際場景下的效果。

Q2.3.15：表格識別有什麼好的模型 或者論文推薦麼

A：表格目前學術界比較成熟的解決方案不多 ，可以嚐試下分割的論文方案。

Q2.3.16：彎曲文本有試過opencv的TPS進行彎曲校正嗎？

A：opencv的tps需要標出上下邊界對應的點，這個點很難通過傳統方法或者深度學習方法獲取。PaddleOCR裏StarNet網絡中的tps模塊實現了自動學點，自動校正，可以直接嚐試這個。

Q2.3.17: StyleText 合成數據效果不好？

A：StyleText模型生成的數據主要用於OCR識別模型的訓練。PaddleOCR目前識別模型的輸入為32 x N，因此當前版本模型主要適用高度為32的數據。 建議要合成的數據尺寸設置為32 x N。尺寸相差不多的數據也可以生成，尺寸很大或很小的數據效果確實不佳。

Q2.3.18: 在PP-OCR係統中，文本檢測的骨幹網絡為什麼沒有使用SE模塊？

A：SE模塊是MobileNetV3網絡一個重要模塊，目的是估計特征圖每個特征通道重要性，給特征圖每個特征分配權重，提高網絡的表達能力。但是，對於文本檢測，輸入網絡的分辨率比較大，一般是640*640，利用SE模塊估計特征圖每個特征通道重要性比較困難，網絡提升能力有限，但是該模塊又比較耗時，因此在PP-OCR係統中，文本檢測的骨幹網絡沒有使用SE模塊。實驗也表明，當去掉SE模塊，超輕量模型大小可以減小40%，文本檢測效果基本不受影響。詳細可以參考PP-OCR技術文章，https://arxiv.org/abs/2009.09941.

【實戰篇】PaddleOCR實戰問題

使用谘詢

Q3.1.1：OSError： [WinError 126] 找不到指定的模塊。mac pro python 3.4 shapely import 問題

A：這個問題是因為shapely庫安裝有誤，可以參考 #212 這個issue重新安裝一下

Q3.1.2：安裝了paddle-gpu，運行時提示沒有安裝gpu版本的paddle，可能是什麼原因?

A：用戶同時安裝了paddle cpu和gpu版本，都刪掉之後，重新安裝gpu版本的padle就好了

Q3.1.3：試用報錯：Cannot load cudnn shared library，是什麼原因呢？

A：需要把cudnn lib添加到LD_LIBRARY_PATH中去。

Q3.1.4：PaddlePaddle怎麼指定GPU運行 os.environ["CUDA_VISIBLE_DEVICES"]這種不生效

A：通過設置 export CUDA_VISIBLE_DEVICES='0'環境變量

Q3.1.5：windows下訓練沒有問題，aistudio中提示數據路徑有問題

A：需要把\改為/（windows和linux的文件夾分隔符不一樣，windows下的是\，linux下是/）

Q3.1.6：gpu版的paddle雖然能在cpu上運行，但是必須要有gpu設備

A：export CUDA_VISIBLE_DEVICES=''，CPU是可以正常跑的

Q3.1.7：預測報錯ImportError： dlopen： cannot load any more object with static TLS

A：glibc的版本問題，運行需要glibc的版本號大於2.23。

Q3.1.8：提供的inference model和預訓練模型的區別

A：inference model為固化模型，文件中包含網絡結構和網絡參數，多用於預測部署。預訓練模型是訓練過程中保存好的模型，多用於fine-tune訓練或者斷點訓練。

Q3.1.9：模型的解碼部分有後處理？

A：有的檢測的後處理在ppocr/postprocess路徑下

Q3.1.10：PaddleOCR中文模型是否支持數字識別？

A：支持的，可以看下ppocr/utils/ppocr_keys_v1.txt 這個文件，是支持的識別字符列表，其中包含了數字識別。

Q3.1.11：PaddleOCR如何做到橫排和豎排同時支持的？

A：合成了一批豎排文字，逆時針旋轉90度後加入訓練集與橫排一起訓練。預測時根據圖片長寬比判斷是否為豎排，若為豎排則將crop出的文本逆時針旋轉90度後送入識別網絡。

Q3.1.12：如何獲取檢測文本框的坐標？

A：文本檢測的結果有box和文本信息, 具體 參考代碼

Q3.1.13：識別模型框出來的位置太緊湊，會丟失邊緣的文字信息，導致識別錯誤

A：可以在命令中加入 --det_db_unclip_ratio ，參數定義位置，這個參數是檢測後處理時控製文本框大小的，默認1.6，可以嚐試改成2.5或者更大，反之，如果覺得文本框不夠緊湊，也可以把該參數調小。

Q3.1.14：英文手寫體識別有計劃提供的預訓練模型嗎?

A：近期也在開展需求調研，如果企業用戶需求較多，我們會考慮增加相應的研發投入，後續提供對應的預訓練模型，如果有需求歡迎通過issue或者加入微信群聯係我們。

Q3.1.15：PaddleOCR的算法可以用於手寫文字檢測識別嗎?後續有計劃推出手寫預訓練模型麼？

A：理論上隻要有相應的數據集，都是可以的。當然手寫識別畢竟和印刷體有區別，對應訓練調優策略可能需要適配性優化。

Q3.1.16：PaddleOCR是否支持在Windows或Mac係統上運行？

A：PaddleOCR已完成Windows和Mac係統適配，運行時注意兩點：

（1）在快速安裝時，如果不想安裝docker，可跳過第一步，直接從第二步安裝paddle開始。

（2）inference模型下載時，如果沒有安裝wget，可直接點擊模型鏈接或將鏈接地址複製到瀏覽器進行下載，並解壓放置到相應目錄。

Q3.1.17：PaddleOCR開源的超輕量模型和通用OCR模型的區別？

A：目前PaddleOCR開源了2個中文模型，分別是8.6M超輕量中文模型和通用中文OCR模型。兩者對比信息如下：

• 相同點：兩者使用相同的算法和訓練數據；

• 不同點：不同之處在於骨幹網絡和通道參數，超輕量模型使用MobileNetV3作為骨幹網絡，通用模型使用Resnet50_vd作為檢測模型backbone，Resnet34_vd作為識別模型backbone，具體參數差異可對比兩種模型訓練的配置文件.

Q3.1.18：如何加入自己的檢測算法？

A：1. 在ppocr/modeling對應目錄下分別選擇backbone，head。如果沒有可用的可以新建文件並添加 2. 在ppocr/data下選擇對應的數據處理處理方式，如果沒有可用的可以新建文件並添加 3. 在ppocr/losses下新建文件並編寫loss 4. 在ppocr/postprocess下新建文件並編寫後處理算法 5. 將上麵四個步驟裏新添加的類或函數參照yml文件寫到配置中

Q3.1.19：訓練的時候報錯reader raised an exception，但是具體不知道是啥問題？

A：這個一般是因為標注文件格式有問題或者是標注文件中的圖片路徑有問題導致的，在tools/train.py文件中有一個test_reader的函數，基於這個去檢查一下數據的格式以及標注，確認沒問題之後再進行模型訓練。

Q3.1.20：PaddleOCR與百度的其他OCR產品有什麼區別？

A：PaddleOCR主要聚焦通用ocr，如果有垂類需求，您可以用PaddleOCR+垂類數據自己訓練； 如果缺少帶標注的數據，或者不想投入研發成本，建議直接調用開放的API，開放的API覆蓋了目前比較常見的一些垂類。

Q3.1.21：PaddleOCR支持動態圖嗎？

A：動態圖版本正在緊鑼密鼓開發中，將於2020年12月16日發布，敬請關注。

Q3.1.22：ModuleNotFoundError: No module named 'paddle.nn'，

A：paddle.nn是Paddle2.0版本特有的功能，請安裝大於等於Paddle 2.0.0的版本，安裝方式為

python3 -m pip install paddlepaddle-gpu==2.0.0 -i https://mirror.baidu.com/pypi/simple

Q3.1.23： ImportError: /usr/lib/x86_64_linux-gnu/libstdc++.so.6:version CXXABI_1.3.11 not found (required by /usr/lib/python3.6/site-package/paddle/fluid/core+avx.so)

A：這個問題是glibc版本不足導致的，Paddle2.0.0版本對gcc版本和glib版本有更高的要求，推薦gcc版本為8.2，glibc版本2.12以上。 如果您的環境不滿足這個要求，或者使用的docker鏡像為: hub.baidubce.com/paddlepaddle/paddle:latest-gpu-cuda9.0-cudnn7-dev hub.baidubce.com/paddlepaddle/paddle:latest-gpu-cuda9.0-cudnn7-dev，安裝Paddle2.0rc版本可能會出現上述錯誤，2.0版本推薦使用新的docker鏡像 paddlepaddle/paddle:latest-dev-cuda10.1-cudnn7-gcc82。 或者訪問dockerhub獲得與您機器適配的鏡像。

Q3.1.24: PaddleOCR develop分支和dygraph分支的區別？

A：目前PaddleOCR有四個分支，分別是：

• develop：基於Paddle靜態圖開發的分支，推薦使用paddle1.8 或者2.0版本，該分支具備完善的模型訓練、預測、推理部署、量化裁剪等功能，領先於release/1.1分支。

• release/1.1：PaddleOCR 發布的第一個穩定版本，基於靜態圖開發，具備完善的訓練、預測、推理部署、量化裁剪等功能。

• dygraph：基於Paddle動態圖開發的分支，目前仍在開發中，未來將作為主要開發分支，運行要求使用Paddle2.0.0版本。

• release/2.0-rc1-0：PaddleOCR發布的第二個穩定版本，基於動態圖和paddle2.0版本開發，動態圖開發的工程更易於調試，目前支，支持模型訓練、預測，暫不支持移動端部署。

如果您已經上手過PaddleOCR，並且希望在各種環境上部署PaddleOCR，目前建議使用靜態圖分支，develop或者release/1.1分支。如果您是初學者，想快速訓練，調試PaddleOCR中的算法，建議嚐鮮PaddleOCR dygraph分支。

注意：develop和dygraph分支要求的Paddle版本、本地環境有差別，請注意不同分支環境安裝部分的差異。

Q3.1.25: 使用dygraph分支，在docker中訓練PaddleOCR的時候，數據路徑沒有任何問題，但是一直報錯reader rasied an exception，這是為什麼呢？

A：創建docker的時候，/dev/shm的默認大小為64M，如果使用多進程讀取數據，共享內存可能不夠，因此需要給/dev/shm分配更大的空間，在創建docker的時候，傳入--shm-size=8g表示給/dev/shm分配8g的空間。

Q3.1.26: 在repo中沒有找到Lite和PaddleServing相關的部署教程，這是在哪裏呢？

A：目前PaddleOCR的默認分支為dygraph，關於Lite和PaddleLite的動態圖部署還在適配中，如果希望在Lite端或者使用PaddleServing部署，推薦使用develop分支（靜態圖）的代碼。

Q3.1.27: 如何可視化acc,loss曲線圖,模型網絡結構圖等？

A：在配置文件裏有use_visualdl的參數，設置為True即可，更多的使用命令可以參考：VisualDL使用指南。

Q3.1.28: 在使用StyleText數據合成工具的時候，報錯ModuleNotFoundError: No module named 'utils.config'，這是為什麼呢？

A：有2個解決方案

• 在StyleText路徑下麵設置PYTHONPATH：export PYTHONPATH=./

• 拉取最新的代碼

Q3.1.29: PPOCRLabel創建矩形框時隻能拖出正方形，如何進行矩形標注？

A：取消勾選：“編輯”-“正方形標注”

Q3.1.30: Style-Text 如何不文字風格遷移，就像普通文本生成程序一樣默認字體直接輸出到分割的背景圖？

A：使用image_synth模式會輸出fake_bg.jpg，即為背景圖。如果想要批量提取背景，可以稍微修改一下代碼，將fake_bg保存下來即可。要修改的位置：https://github.com/PaddlePaddle/PaddleOCR/blob/de3e2e7cd3b8b65ee02d7a41e570fa5b511a3c1d/StyleText/engine/synthesisers.py#L68

Q3.1.31: 怎麼輸出網絡結構以及每層的參數信息？

A：可以使用 paddle.summary， 具體參考:https://www.paddlepaddle.org.cn/documentation/docs/zh/develop/api/paddle/hapi/model_summary/summary_cn.html。

Q3.1.32 能否修改StyleText配置文件中的分辨率？

A：StyleText目前的訓練數據主要是高度32的圖片，建議不要改變高度。未來我們會支持更豐富的分辨率。

Q3.1.33 StyleText是否可以更換字體文件？

A：StyleText項目中的字體文件為標準字體，主要用作模型的輸入部分，不能夠修改。 StyleText的用途主要是：提取style_image中的字體、背景等style信息，根據語料生成同樣style的圖片。

Q3.1.34 StyleText批量生成圖片為什麼沒有輸出？

A：需要檢查以下您配置文件中的路徑是否都存在。尤其要注意的是label_file配置。 如果您使用的style_image輸入沒有label信息，您依然需要提供一個圖片文件列表。

Q3.1.35 怎樣把OCR輸出的結果組成有意義的語句呢？

A：OCR輸出的結果包含坐標信息和文字內容兩部分。如果您不關心文字的順序，那麼可以直接按box的序號連起來。 如果需要將文字按照一定的順序排列，則需要您設定一些規則，對文字的坐標進行處理，例如按照坐標從上到下，從左到右連接識別結果。 對於一些有規律的垂類場景，可以設定模板，根據位置、內容進行匹配。 例如識別身份證照片，可以先匹配"姓名"，"性別"等關鍵字，根據這些關鍵字的坐標去推測其他信息的位置，再與識別的結果匹配。

Q3.1.36 如何識別竹簡上的古文？

A：對於字符都是普通的漢字字符的情況，隻要標注足夠的數據，finetune模型就可以了。如果數據量不足，您可以嚐試StyleText工具。 而如果使用的字符是特殊的古文字、甲骨文、象形文字等，那麼首先需要構建一個古文字的字典，之後再進行訓練。

Q3.1.37: 小語種模型隻有識別模型，沒有檢測模型嗎？

A：小語種（包括純英文數字）的檢測模型和中文的檢測模型是共用的，在訓練中文檢測模型時加入了多語言數據。https://github.com/PaddlePaddle/PaddleOCR/blob/dygraph/doc/doc_en/models_list_en.md#1-text-detection-model。

Q3.1.38: module 'paddle.distributed' has no attribute ‘get_rank’。

A：Paddle版本問題，請安裝2.0版本Paddle：pip install paddlepaddle==2.0.0。

Q3.1.39: 字典中沒有的字應該如何標注，是用空格代替還是直接忽略掉？

A：可以直接按照圖片內容標注，在編碼的時候，會忽略掉字典中不存在的字符。

Q3.1.40: dygraph、release/2.0-rc1-0、release/2.0 這三個分支有什麼區別？

A：dygraph是動態圖分支，並且適配Paddle-develop，當然目前在Paddle2.0上也可以運行，新特性我們會在這裏更新。 release/2.0-rc1-0是基於Paddle 2.0rc1的穩定版本，release/2.0是基於Paddle2.0的穩定版本，如果希望版本或者代 碼穩定的話，建議使用release/2.0分支，如果希望可以實時拿到一些最新特性，建議使用dygraph分支。

Q3.1.41: style-text 融合模塊的輸入是生成的前景圖像以及背景特征權重嗎？

A：目前版本是直接輸入兩個圖像進行融合的，沒有用到feature_map，替換背景圖片不會影響效果。

Q3.1.42: 訓練識別任務的時候，在CPU上運行時，報錯The setting of Parameter-Server must has server_num or servers。

A：這是訓練任務啟動方式不對造成的。

1. 在使用CPU或者單塊GPU訓練的時候，可以直接使用python3 tools/train.py -c xxx.yml的方式啟動。

2. 在使用多塊GPU訓練的時候，需要使用distributed.launch的方式啟動，如python3 -m paddle.distributed.launch --gpus '0,1,2,3' tools/train.py -c xxx.yml，這種方式需要安裝NCCL庫，如果沒有的話會報錯。

Q3.1.43：使用StyleText進行數據合成時，文本(TextInput)的長度遠超StyleInput的長度，該怎麼處理與合成呢？

A：在使用StyleText進行數據合成的時候，建議StyleInput的長度長於TextInput的長度。有2種方法可以處理上述問題：

1. 將StyleInput按列的方向進行複製與擴充，直到其超過TextInput的長度。

2. 將TextInput進行裁剪，保證每段TextInput都稍短於StyleInput，分別合成之後，再拚接在一起。

實際使用中發現，使用第2種方法的效果在長文本合成的場景中的合成效果更好，StyleText中提供的也是第2種數據合成的邏輯。

數據集

Q3.2.1：如何製作PaddleOCR支持的數據格式

A：可以參考檢測與識別訓練文檔，裏麵有數據格式詳細介紹。檢測文檔，識別文檔

Q3.2.2：請問一下，如果想用預訓練模型，但是我的數據裏麵又出現了預訓練模型字符集中沒有的字符，新的字符是在字符集前麵添加還是在後麵添加？

A：在後麵添加，修改dict之後，就改變了模型最後一層fc的結構，之前訓練到的參數沒有用到，相當於從頭訓練，因此acc是0。

Q3.2.3：如何調試數據讀取程序？

A：tools/train.py中有一個test_reader()函數用於調試數據讀取。

Q3.2.4：開源模型使用的訓練數據是什麼，能否開源？

A：目前開源的模型，數據集和量級如下：

• 檢測：

• 英文數據集，ICDAR2015

• 中文數據集，LSVT街景數據集訓練數據3w張圖片

• 識別：

• 英文數據集，MJSynth和SynthText合成數據，數據量上千萬。

• 中文數據集，LSVT街景數據集根據真值將圖crop出來，並進行位置校準，總共30w張圖像。此外基於LSVT的語料，合成數據500w。

其中，公開數據集都是開源的，用戶可自行搜索下載，也可參考中文數據集，合成數據暫不開源，用戶可使用開源合成工具自行合成，可參考的合成工具包括text_renderer、SynthText、TextRecognitionDataGenerator等。

Q3.2.5：請問中文字符集多大呢？支持生僻字識別嗎？

A：中文字符集是6623， 支持生僻字識別。訓練樣本中有部分生僻字，但樣本不多，如果有特殊需求建議使用自己的數據集做fine-tune。

Q3.2.6：中文文本檢測、文本識別構建訓練集的話，大概需要多少數據量

A：檢測需要的數據相對較少，在PaddleOCR模型的基礎上進行Fine-tune，一般需要500張可達到不錯的效果。 識別分英文和中文，一般英文場景需要幾十萬數據可達到不錯的效果，中文則需要幾百萬甚至更多。

Q3.2.7：中文識別模型如何選擇？

A：中文模型共有2大類：通用模型和超輕量模型。他們各自的優勢如下： 超輕量模型具有更小的模型大小，更快的預測速度。適合用於端側使用。 通用模型具有更高的模型精度，適合對模型大小不敏感的場景。 此外基於以上模型，PaddleOCR還提供了支持空格識別的模型，主要針對中文場景中的英文句子。 您可以根據實際使用需求進行選擇。

Q3.2.8：圖像旋轉90° 文本檢測可以正常檢測到具體文本位置，但是識別準確度大幅降低，是否會考慮增加相應的旋轉預處理？

A：目前模型隻支持兩種方向的文字：水平和垂直。 為了降低模型大小，加快模型預測速度，PaddleOCR暫時沒有加入圖片的方向判斷。建議用戶在識別前自行轉正，後期也會考慮添加選擇角度判斷。

Q3.2.9：同一張圖通用檢測出21個條目，輕量級檢測出26個 ，難道不是輕量級的好嗎？

A：可以主要參考可視化效果，通用模型更傾向於檢測一整行文字，輕量級可能會有一行文字被分成兩段檢測的情況，不是數量越多，效果就越好。

Q3.2.10：crnn+ctc模型訓練所用的垂直文本（旋轉至水平方向）是如何生成的？

A：方法與合成水平方向文字一致，隻是將字體替換成了垂直字體。

Q3.2.11：有哪些標注工具可以標注OCR數據集？

A：推薦您使用PPOCRLabel工具。 您還可以參考：https://github.com/PaddlePaddle/PaddleOCR/blob/develop/doc/doc_en/data_annotation_en.md。

Q3.2.12：一些特殊場景的數據識別效果差，但是數據量很少，不夠用來finetune怎麼辦？

A：您可以合成一些接近使用場景的數據用於訓練。 我們計劃推出基於特定場景的文本數據合成工具，請您持續關注PaddleOCR的近期更新。

Q3.2.13：特殊字符（例如一些標點符號）識別效果不好怎麼辦？

A：首先請您確認要識別的特殊字符是否在字典中。 如果字符在已經字典中但效果依然不好，可能是由於識別數據較少導致的，您可以增加相應數據finetune模型。

Q3.2.14：PaddleOCR可以識別灰度圖嗎？

A：PaddleOCR的模型均為三通道輸入。如果您想使用灰度圖作為輸入，建議直接用3通道的模式讀入灰度圖， 或者將單通道圖像轉換為三通道圖像再識別。例如，opencv的cvtColor函數就可以將灰度圖轉換為RGB三通道模式。

Q3.2.15: 文本標注工具PPOCRLabel有什麼特色？

A：PPOCRLabel是一個半自動文本標注工具，它使用基於PPOCR的中英文OCR模型，預先預測文本檢測和識別結果，然後用戶對上述結果進行校驗和修正就行，大大提高用戶的標注效率。同時導出的標注結果直接適配PPOCR訓練所需要的數據格式，

Q3.2.16: 文本標注工具PPOCRLabel，可以更換模型嗎？

A：PPOCRLabel中OCR部署方式采用的基於pip安裝whl包快速推理，可以參考相關文檔更換模型路徑，進行特定任務的標注適配。基於pip安裝whl包快速推理的文檔如下，https://github.com/PaddlePaddle/PaddleOCR/blob/develop/doc/doc_ch/whl.md。

Q3.2.17: 文本標注工具PPOCRLabel支持的運行環境有哪些？

A：PPOCRLabel可運行於Linux、Windows、MacOS等多種係統。操作步驟可以參考文檔，https://github.com/PaddlePaddle/PaddleOCR/blob/develop/PPOCRLabel/README.md

Q3.2.18: PaddleOCR動態圖版本如何finetune？

A：finetune需要將配置文件裏的 Global.load_static_weights設置為false，如果沒有此字段可以手動添加，然後將模型地址放到Global.pretrained_model字段下即可。

模型訓練調優

Q3.3.1：文本長度超過25，應該怎麼處理？

A：默認訓練時的文本可識別的最大長度為25，超過25的文本會被忽略不參與訓練。如果您訓練樣本中的長文本較多，可以修改配置文件中的 max_text_length 字段，設置為更大的最長文本長度，具體位置在這裏。

Q3.3.2：配置文件裏麵檢測的閾值設置麼?

A：有的，檢測相關的參數主要有以下幾個： det_limit_side_len：預測時圖像resize的長邊尺寸 det_db_thresh: 用於二值化輸出圖的閾值 det_db_box_thresh:用於過濾文本框的閾值，低於此閾值的文本框不要 det_db_unclip_ratio: 文本框擴張的係數，關係到文本框的大小

這些參數的默認值見代碼，可以通過從命令行傳遞參數進行修改。

Q3.3.3：我想請教一下，你們在訓練識別時候，lsvt裏的非矩形框文字，你們是怎麼做處理的呢。忽略掉還是去最小旋轉框？

A：現在是忽略處理的

Q3.3.4：訓練過程中，如何恰當的停止訓練（直接kill，經常還有顯存占用的問題）

A：可以通過下麵的腳本終止所有包含train.py字段的進程，

ps -axu | grep train.py | awk '{print $2}' | xargs kill -9

Q3.3.5：可不可以將pretrain_weights設置為空呢？想從零開始訓練一個model

A：這個是可以的，在訓練通用識別模型的時候，pretrain_weights就設置為空，但是這樣可能需要更長的迭代輪數才能達到相同的精度。

Q3.3.6：PaddleOCR默認不是200個step保存一次模型嗎？為啥文件夾下麵都沒有生成

A：因為默認保存的起始點不是0，而是4000，將eval_batch_step [4000, 5000]改為[0, 2000] 就是從第0次迭代開始，每2000迭代保存一次模型

Q3.3.7：如何進行模型微調？

A：注意配置好合適的數據集，對齊數據格式，然後在finetune訓練時，可以加載我們提供的預訓練模型，設置配置文件中Global.pretrain_weights 參數為要加載的預訓練模型路徑。

Q3.3.8：文本檢測換成自己的數據沒法訓練，有一些”###”是什麼意思？

A：數據格式有問題，”###” 表示要被忽略的文本區域，所以你的數據都被跳過了，可以換成其他任意字符或者就寫個空的。

Q3.3.9：copy_from_cpu這個地方，這塊input不變(t_data的size不變)連續調用兩次copy_from_cpu()時，這裏麵的gpu_place會重新malloc GPU內存嗎？還是隻有當ele_size變化時才會重新在GPU上malloc呢？

A：小於等於的時候都不會重新分配，隻有大於的時候才會重新分配

Q3.3.10：自己訓練出來的未inference轉換的模型 可以當作預訓練模型嗎？

A：可以的，但是如果訓練數據量少的話，可能會過擬合到少量數據上，泛化性能不佳。

Q3.3.11：使用帶TPS的識別模型預測報錯

A：TPS模塊暫時不支持導出，後續更新。

Q3.3.12：如何更換文本檢測/識別的backbone？報錯信息：Input(X) dims[3] and Input(Grid) dims[2] should be equal, but received X dimension[3](320) != Grid dimension[2](100)

A：直接更換配置文件裏的Backbone.name即可，格式為：網絡文件路徑,網絡Class名詞。如果所需的backbone在PaddleOCR裏沒有提供，可以參照PaddleClas裏麵的網絡結構，進行修改嚐試。具體修改原則可以參考OCR通用問題中 "如何更換文本檢測/識別的backbone" 的回答。

Q3.3.13： 訓練中使用的字典需要與加載的預訓練模型使用的字典一樣嗎？

A：分情況，1. 不改變識別字符，訓練的字典與你使用該模型進行預測的字典需要保持一致的。 2. 改變識別的字符，這種情況可以不一樣，最後一層會重新訓練

Q3.3.14: 如何對檢測模型finetune，比如凍結前麵的層或某些層使用小的學習率學習？

A：

A：如果是凍結某些層，可以將變量的stop_gradient屬性設置為True，這樣計算這個變量之前的所有參數都不會更新了，參考：https://www.paddlepaddle.org.cn/documentation/docs/zh/develop/faq/train_cn.html#id4

如果對某些層使用更小的學習率學習，靜態圖裏還不是很方便，一個方法是在參數初始化的時候，給權重的屬性設置固定的學習率，參考：https://www.paddlepaddle.org.cn/documentation/docs/zh/develop/api/paddle/fluid/param_attr/ParamAttr_cn.html#paramattr

實際上我們實驗發現，直接加載模型去fine-tune，不設置某些層不同學習率，效果也都不錯

Q3.3.15: 使用通用中文模型作為預訓練模型，更改了字典文件，出現ctc_fc_b not used的錯誤

A：修改了字典之後，識別模型的最後一層FC緯度發生了改變，沒有辦法加載參數。這裏是一個警告，可以忽略，正常訓練即可。

Q3.3.16: cpp_infer 在Windows下使用vs2015編譯不通過

A：1. windows上建議使用VS2019工具編譯，具體編譯細節參考鏈接

A：2. 在release模式下而不是debug模式下編譯，參考issue

Q3.3.17: No module named 'tools.infer'

A：1. 確保在PaddleOCR/目錄下執行的指令，執行'export PYTHONPATH=.'

A：2. 拉取github上最新代碼，這個問題在10月底已修複。

Q3.3.18: 訓練模型和測試模型的檢測結果差距較大

A：1. 檢查兩個模型使用的後處理參數是否是一樣的，訓練的後處理參數在配置文件中的PostProcess部分，測試模型的後處理參數在tools/infer/utility.py中，最新代碼中兩個後處理參數已保持一致。

Q3.3.19: 使用合成數據精調小模型後，效果可以，但是還沒開源的小infer模型效果好，這是為什麼呢？

A：

（1）要保證使用的配置文件和pretrain weights是對應的；

（2）在微調時，一般都需要真實數據，如果使用合成數據，效果反而可能會有下降，PaddleOCR中放出的識別inference模型也是基於預訓練模型在真實數據上微調得到的，效果提升比較明顯；

（3）在訓練的時候，文本長度超過25的訓練圖像都會被丟棄，因此需要看下真正參與訓練的圖像有多少，太少的話也容易過擬合。

Q3.3.20: 文字檢測時怎麼模糊的數據增強？

A：模糊的數據增強需要修改代碼進行添加，以DB為例，參考Normalize ,添加模糊的增強就行

Q3.3.21: 文字檢測時怎麼更改圖片旋轉的角度，實現360度任意旋轉？

A：將這裏 的(-10,10) 改為(-180,180)即可

Q3.3.22: 訓練數據的長寬比過大怎麼修改shape

A：識別修改這裏 , 檢測修改這裏

Q3.3.23：檢測模型訓練或預測時出現elementwise_add報錯

A：設置的輸入尺寸必須是32的倍數，否則在網絡多次下采樣和上采樣後，feature map會產生1個像素的diff，從而導致elementwise_add時報shape不匹配的錯誤。

Q3.3.24: DB檢測訓練輸入尺寸640，可以改大一些嗎？

A：不建議改大。檢測模型訓練輸入尺寸是預處理中random crop後的尺寸，並非直接將原圖進行resize，多數場景下這個尺寸並不小了，改大後可能反而並不合適，而且訓練會變慢。另外，代碼裏可能有的地方參數按照預設輸入尺寸適配的，改大後可能有隱藏風險。

Q3.3.25: 識別模型訓練時，loss能正常下降，但acc一直為0

A：識別模型訓練初期acc為0是正常的，多訓一段時間指標就上來了。

Q3.3.26: PaddleOCR在訓練的時候一直使用cosine_decay的學習率下降策略，這是為什麼呢？

A：cosine_decay表示在訓練的過程中，學習率按照cosine的變化趨勢逐漸下降至0，在迭代輪數更長的情況下，比常量的學習率變化策略會有更好的收斂效果，因此在實際訓練的時候，均采用了cosine_decay，來獲得精度更高的模型。

Q3.3.27: PaddleOCR關於文本識別模型的訓練，支持的數據增強方式有哪些？

A：文本識別支持的數據增強方式有隨機小幅度裁剪、圖像平衡、添加白噪聲、顏色漂移、圖像反色和Text Image Augmentation（TIA）變換等。可以參考代碼中的warp函數。

Q3.3.28: 關於dygraph分支中，文本識別模型訓練，要使用數據增強應該如何設置？

A：可以參考配置文件在Train['dataset']['transforms']添加RecAug字段，使數據增強生效。可以通過添加對aug_prob設置，表示每種數據增強采用的概率。aug_prob默認是0.4.由於tia數據增強特殊性，默認不采用，可以通過添加use_tia設置，使tia數據增強生效。詳細設置可以參考ISSUE 1744。

Q3.3.29: 微調v1.1預訓練的模型，可以直接用文字垂直排列和上下顛倒的圖片嗎？還是必須要水平排列的？

A：1.1和2.0的模型一樣，微調時，垂直排列的文字需要逆時針旋轉 90°後加入訓練，上下顛倒的需要旋轉為水平的。

Q3.3.30: 模型訓練過程中如何得到 best_accuracy 模型？

A：配置文件裏的eval_batch_step字段用來控製多少次iter進行一次eval，在eval完成後會自動生成 best_accuracy 模型，所以如果希望很快就能拿到best_accuracy模型，可以將eval_batch_step改小一點，如改為[10,10]，這樣表示第10次迭代後，以後沒隔10個迭代就進行一次模型的評估。

預測部署

Q3.4.1：如何pip安裝opt模型轉換工具？

A：由於OCR端側部署需要某些算子的支持，這些算子僅在Paddle-Lite 最新develop分支中，所以需要自己編譯opt模型轉換工具。opt工具可以通過編譯PaddleLite獲得，編譯步驟參考lite部署文檔 中2.1 模型優化部分。

Q3.4.2：如何將PaddleOCR預測模型封裝成SDK

A：如果是Python的話，可以使用tools/infer/predict_system.py中的TextSystem進行sdk封裝，如果是c++的話，可以使用deploy/cpp_infer/src下麵的DBDetector和CRNNRecognizer完成封裝

Q3.4.3：服務部署可以隻發布文本識別，而不帶文本檢測模型麼？

A：可以的。默認的服務部署是檢測和識別串聯預測的。也支持單獨發布文本檢測或文本識別模型，比如使用PaddleHUBPaddleOCR 模型時，deploy下有三個文件夾，分別是

• ocr_det：檢測預測

• ocr_rec: 識別預測

• ocr_system: 檢測識別串聯預測

每個模塊是單獨分開的，所以可以選擇隻發布文本識別模型。使用PaddleServing部署時同理。

Q3.4.4：為什麼PaddleOCR檢測預測是隻支持一張圖片測試？即test_batch_size_per_card=1

A：測試的時候，對圖像等比例縮放，最長邊960，不同圖像等比例縮放後長寬不一致，無法組成batch，所以設置為test_batch_size為1。

Q3.4.5：為什麼使用c++ inference和python inference結果不一致?

A：可能是導出的inference model版本與預測庫版本需要保持一致，比如在Windows下，Paddle官網提供的預測庫版本是1.8，而PaddleOCR提供的inference model 版本是1.7，因此最終預測結果會有差別。可以在Paddle1.8環境下導出模型，再基於該模型進行預測。 此外也需要保證兩者的預測參數配置完全一致。

Q3.4.6：為什麼第一張張圖預測時間很長，第二張之後預測時間會降低？

A：第一張圖需要顯存資源初始化，耗時較多。完成模型加載後，之後的預測時間會明顯縮短。

Q3.4.7：請問opt工具可以直接轉int8量化後的模型為.nb文件嗎

A：有的，PaddleLite提供完善的opt工具，可以參考文檔

Q3.4.8：請問在安卓端怎麼設置這個參數 --det_db_unclip_ratio=3

A：在安卓APK上無法設置，沒有暴露這個接口，如果使用的是PaddledOCR/deploy/lite/的demo，可以修改config.txt中的對應參數來設置

Q3.4.9：PaddleOCR模型是否可以轉換成ONNX模型?

A：目前暫不支持轉ONNX，相關工作在研發中。

Q3.4.10：使用opt工具對檢測模型轉換時報錯 can not found op arguments for node conv2_b_attr

A：這個問題大概率是編譯opt工具的Paddle-Lite不是develop分支，建議使用Paddle-Lite 的develop分支編譯opt工具。

Q3.4.11：libopenblas.so找不到是什麼意思？

A：目前包括mkl和openblas兩種版本的預測庫，推薦使用mkl的預測庫，如果下載的預測庫是mkl的，編譯的時候也需要勾選with_mkl選項 ，以Linux下編譯為例，需要在設置這裏為ON，-DWITH_MKL=ON，參考鏈接 。此外，使用預測庫時，推薦在Linux或者Windows上進行開發，不推薦在MacOS上開發。

Q3.4.12：使用自定義字典訓練，inference時如何修改

A：使用了自定義字典的話，用inference預測時，需要通過 --rec_char_dict_path 修改字典路徑。詳細操作可參考文檔

Q3.4.13：能否返回單字字符的位置？

A：訓練的時候標注是整個文本行的標注，所以預測的也是文本行位置，如果要獲取單字符位置信息，可以根據預測的文本，計算字符數量，再去根據整個文本行的位置信息，估計文本塊中每個字符的位置。

Q3.4.14：PaddleOCR模型部署方式有哪幾種？

A：目前有Inference部署，serving部署和手機端Paddle Lite部署，可根據不同場景做靈活的選擇：Inference部署適用於本地離線部署，serving部署適用於雲端部署，Paddle Lite部署適用於手機端集成。

Q3.4.15： hubserving、pdserving這兩種部署方式區別是什麼？

A：hubserving原本是paddlehub的配套服務部署工具，可以很方便的將paddlehub內置的模型部署為服務，paddleocr使用了這個功能，並將模型路徑等參數暴露出來方便用戶自定義修改。paddle serving是麵向所有paddle模型的部署工具，文檔中可以看到我們提供了快速版和標準版，其中快速版和hubserving的本質是一樣的，而標準版基於rpc，更穩定，更適合分布式部署。

Q3.4.16： hub serving部署服務時如何多gpu同時利用起來，export CUDA_VISIBLE_DEVICES=0,1 方式嗎？

A：hubserving的部署方式目前暫不支持多卡預測，除非手動啟動多個serving，不同端口對應不同卡。或者可以使用paddleserving進行部署，部署工具已經發布：https://github.com/PaddlePaddle/PaddleOCR/tree/develop/deploy/pdserving ，在啟動服務時--gpu_id 0,1 這樣就可以

Q3.4.17： 預測內存泄漏問題

A：1. 使用hubserving出現內存泄漏，該問題為已知問題，預計在paddle2.0正式版中解決。相關討論見issue

A：2. C++ 預測出現內存泄漏，該問題已經在paddle2.0rc版本中解決，建議安裝paddle2.0rc版本，並更新PaddleOCR代碼到最新。

Q3.4.18：對於一些尺寸較大的文檔類圖片，在檢測時會有較多的漏檢，怎麼避免這種漏檢的問題呢？

A：PaddleOCR中在圖像最長邊大於960時，將圖像等比例縮放為長邊960的圖像再進行預測，對於這種圖像，可以通過修改det_limit_side_len，增大檢測的最長邊：tools/infer/utility.py#L42

Q3.4.19：在使用訓練好的識別模型進行預測的時候，發現有很多重複的字，這個怎麼解決呢？

A：可以看下訓練的尺度和預測的尺度是否相同，如果訓練的尺度為[3, 32, 320]，預測的尺度為[3, 64, 640]，則會有比較多的重複識別現象。

Q3.4.20：文檔場景中，使用DB模型會出現整行漏檢的情況應該怎麼解決？

A：可以在預測時調小 det_db_box_thresh 閾值，默認為0.5, 可調小至0.3觀察效果。

Q3.4.21：自己訓練的det模型，在同一張圖片上，inference模型與eval模型結果差別很大，為什麼？

A：這是由於圖片預處理不同造成的。如果訓練的det模型圖片輸入並不是默認的shape[600, 600]，eval的程序中圖片預處理方式與train時一致 （由xxx_reader.yml中的test_image_shape參數決定縮放大小，但predict_eval.py中的圖片預處理方式由程序裏的preprocess_params決定， 最好不要傳入max_side_len，而是傳入和訓練時一樣大小的test_image_shape。

Q3.4.22：訓練ccpd車牌數據集，訓練集準確率高，測試均是錯誤的，這是什麼原因？

A：這是因為訓練時將shape修改為[3, 70, 220], 預測時對圖片resize，會把高度壓縮至32，影響測試結果。注釋掉resize代碼 可以解決問題。

Q3.4.23：安裝paddleocr後，提示沒有paddle

A：這是因為paddlepaddle gpu版本和cpu版本的名稱不一致，現在已經在whl的文檔裏做了安裝說明。

Q3.4.24：DB模型能正確推理預測，但換成EAST或SAST模型時報錯或結果不正確

A：使用EAST或SAST模型進行推理預測時，需要在命令中指定參數--det_algorithm="EAST" 或 --det_algorithm="SAST"，使用DB時不用指定是因為該參數默認值是"DB"：https://github.com/PaddlePaddle/PaddleOCR/blob/e7a708e9fdaf413ed7a14da8e4a7b4ac0b211e42/tools/infer/utility.py#L43

Q3.4.25: PaddleOCR模型Python端預測和C++預測結果不一致？

正常來說，python端預測和C++預測文本是一致的，如果預測結果差異較大， 建議首先排查diff出現在檢測模型還是識別模型，或者嚐試換其他模型是否有類似的問題。 其次，檢查python端和C++端數據處理部分是否存在差異，建議保存環境，更新PaddleOCR代碼再試下。 如果更新代碼或者更新代碼都沒能解決，建議在PaddleOCR微信群裏或者issue中拋出您的問題。

Q3.4.26: 目前paddle hub serving 隻支持 imgpath，如果我想用imgurl 去哪裏改呢？

A：圖片是在這裏讀取的：https://github.com/PaddlePaddle/PaddleOCR/blob/67ef25d593c4eabfaaceb22daade4577f53bed81/deploy/hubserving/ocr_system/module.py#L55， 可以參考下麵的寫法，將url path轉化為np array（https://cloud.tencent.com/developer/article/1467840）

response = request.urlopen('http://i1.whymtj.com/uploads/tu/201902/9999/52491ae4ba.jpg')img_array = np.array(bytearray(response.read()), dtype=np.uint8)img = cv.imdecode(img_array, -1)

Q3.4.27: C++ 端側部署可以隻對OCR的檢測部署嗎？

A：可以的，識別和檢測模塊是解耦的。如果想對檢測部署，需要自己修改一下main函數， 隻保留檢測相關就可以:https://github.com/PaddlePaddle/PaddleOCR/blob/de3e2e7cd3b8b65ee02d7a41e570fa5b511a3c1d/deploy/cpp_infer/src/main.cpp#L72

Q3.4.28: PP-OCR係統中，文本檢測的結果有置信度嗎？

A：文本檢測的結果有置信度，由於推理過程中沒有使用，所以沒有顯示的返回到最終結果中。如果需要文本檢測結果的置信度，可以在文本檢測DB的後處理代碼的155行，添加scores信息。這樣，在檢測預測代碼的197行，就可以拿到文本檢測的scores信息。

Q3.4.29: DB文本檢測，特征提取網絡金字塔構建的部分代碼在哪兒？

A：特征提取網絡金字塔構建的部分:代碼位置。ppocr/modeling文件夾裏麵是組網相關的代碼，其中architectures是文本檢測或者文本識別整體流程代碼；backbones是骨幹網絡相關代碼；necks是類似與FPN的頸函數代碼；heads是提取文本檢測或者文本識別預測結果相關的頭函數；transforms是類似於TPS特征預處理模塊。更多的信息可以參考代碼組織結構。

Q3.4.30: PaddleOCR是否支持在華為鯤鵬920CPU上部署？

A：目前Paddle的預測庫是支持華為鯤鵬920CPU的，但是OCR還沒在這些芯片上測試過，可以自己調試，有問題反饋給我們。

Q3.4.31: 采用Paddle-Lite進行端側部署，出現問題，環境沒問題。

A：如果你的預測庫是自己編譯的，那麼你的nb文件也要自己編譯，用同一個lite版本。不能直接用下載的nb文件，因為版本不同。

Q3.4.32: PaddleOCR的模型支持onnx轉換嗎？

A：我們目前已經通過Paddle2ONNX來支持各模型套件的轉換，PaddleOCR基於PaddlePaddle 2.0的版本（dygraph分支）已經支持導出為ONNX，歡迎關注Paddle2ONNX，了解更多項目的進展： Paddle2ONNX項目：https://github.com/PaddlePaddle/Paddle2ONNX Paddle2ONNX支持轉換的模型列表

Q3.4.33: 如何多進程運行paddleocr？

A：實例化多個paddleocr服務，然後將服務注冊到注冊中心，之後通過注冊中心統一調度即可，關於注冊中心，可以搜索eureka了解一下具體使用，其他的注冊中心也行。

Q3.4.34: 2.0訓練出來的模型，能否在1.1版本上進行部署？

A：這個是不建議的，2.0訓練出來的模型建議使用dygraph分支裏提供的部署代碼。

Q3.4.35: 怎麼解決paddleOCR在T4卡上有越預測越慢的情況？

A：

1. T4 GPU沒有主動散熱，因此在測試的時候需要在每次infer之後需要sleep 30ms，否則機器容易因為過熱而降頻(inference速度會變慢)，溫度過高也有可能會導致宕機。

2. T4在不使用的時候，也有可能會降頻，因此在做benchmark的時候需要鎖頻，下麵這兩條命令可以進行鎖頻。

nvidia-smi -i 0 -pm ENABLEDnvidia-smi --lock-gpu-clocks=1590 -i 0

Q3.4.36: DB有些框太貼文本了反而去掉了一些文本的邊角影響識別，這個問題有什麼辦法可以緩解嗎？

A：可以把後處理的參數unclip_ratio適當調大一點。

Q3.4.37: 在windows上進行cpp inference的部署時，總是提示找不到paddle_fluid.dll和opencv_world346.dll，

A：有2種方法可以解決這個問題：

1. 將paddle預測庫和opencv庫的地址添加到係統環境變量中。

2. 將提示缺失的dll文件拷貝到編譯產出的ocr_system.exe文件夾中。

Q3.4.38：想在Mac上部署，從哪裏下載預測庫呢？

A：Mac上的Paddle預測庫可以從這裏下載：https://paddle-inference-lib.bj.bcebos.com/mac/2.0.0/cpu_avx_openblas/paddle_inference.tgz

Q3.4.39：內網環境如何進行服務化部署呢？

A：仍然可以使用PaddleServing或者HubServing進行服務化部署，保證內網地址可以訪問即可。