維基文庫討論:光學字元辨識
對於手寫古籍 古籍酷與google OCR的比較
編輯
光處漿最多或雲植物之 漿猶動物之脂也 此體生於葉中木中者其初細胞甚小且少近管處又生 新者漸生漸多體以漸而大故葉與木亦以漸而大也 諸細胞相粘合必有隙隙中或有油或有香膠充滿焉又 或有養氣或有液道其液如水液道之或通皮外或通 葉外以接外氣凡有油與養氣者其口或大或小於細胞 不定惟液道口必甚小非顯微鏡不能察焉 其功用令流質徧行植物體中胞雖無漏孔流質自能沁 入復沁出焉 嫩木中聚胞體節節相聯如甲木老則中之細胞消盡而 成長管剖其管細察之有無數細點凹跡也如心 此體最易爛凡葉花果落地後與 植物生命之氣隔絕其中之炭質 卽合養氣散爲炭氣輕氣卽合養 氣化爲水餘如硫磺鄰謙青鹽等質卽仍入土故葉花果 墮地後其軟處必先壞核置乾處不壊遇濕亦卽爛也 木體 木體乃合無數長管爲一體管柔而勒長而甚細合七管
光處漿最多或雲植物之漿猶動物之脂也 此體生於葉中木中者其初細胞甚小且少近管處又生 新者漸生漸多體以漸而大故葉與木亦以漸而大也 諸細胞相粘合必有隙隙中或有油或有香膠充滿 或有養氣或有液道其液雄水液 液如水液道之口或通皮外或通 以接外氣凡有油與養氣者其口或大或小於細胞 心惟液道之口必甚小非顯微鏡不能察焉 流質編行植物體中胞雖無漏孔流質自能沙 其功用令流質編 入復沁出焉 嫩木中聚胞體節相聯如甲木老則中之細胞消盡而 成長管剖其管 Q有無數細點凹跡也如乙 此體長易爛凡葉花果落地後與 植物生命之氣隔絕其中之屍質 配合養氣散爲炭氣輕氣郎合養 氣化爲水餘如硫花 靑鹽等質卽仍入土故葉 墮地後其軟處必先壞核置乾處不壞遇濕亦自爛也 木體 木體乃合無數長管爲一體管柔而靳長而甚組合七管 學 葉
https://zh.wikisource.org/w/index.php?title=Wikisource%3A%E6%B2%99%E7%9B%92&diff=2292668&oldid=2292667
比較二者可以發現，古籍酷的識別準確率更高。但是古籍酷的缺點是不能識別標點符號。 維基小霸王（留言） 2023年5月30日 (二) 04:19 (UTC)
公有領域文獻整理的幾個階段
編輯理想的完整步驟是：掃描上傳到維基共享資源、OCR、加標點、自動寫成百科全書。
掃描上傳到維基共享資源：現在已經傳了很多了，以後還要繼續。
挑選出最好的版本：一些書有很多版本，同一版本有多個來源的掃描。人工挑選出其中最好的一個文件，用於OCR。
OCR：對於不同時代的作品，印刷和排版方式不同。挑選最合適的OCR工具，轉換為文本。
加標點：電腦自動加標點。
自動寫成百科全書：這是最終極的一步。有的文本就像天書一樣。現在有chatgpt這樣的工具，可以將這些書提取信息寫成百科全書條目。由於來源是公有領域的，條目大篇幅引用也沒關係，只要註明來源即可，這樣可便於讀者查證。
大型語言模型可以綜合多個語言的文本，這樣就可以使用所有語言的所有共有領域材料寫成所有語言的條目，真正實現「地球上的每一個人都可以自由訪問所有人類知識的總和」，這是人類過去從未實現的。
希望有專業的人士來做這一步，這會是一項歷史性的創舉。 維基小霸王（留言） 2023年6月29日 (四) 02:50 (UTC)
NDL古典籍OCR ver.3
編輯出新版了，據說對古籍有改良。（@維基小霸王：）Fish bowl（留言） 2024年2月7日 (三) 23:50 (UTC)
- 謝謝 以後我看看 維基小霸王（留言） 2024年2月7日 (三) 23:58 (UTC)
大規模OCR圖書館
編輯之前討論過Wikisource:寫字間/存檔/2023#OCR圖書館，但遇到了Google OCR無法訪問圖片的問題。現在此問題已經解決了。我們可以開始大規模識別圖書掃描了。
一個潛在的問題是，很多書具有多份掃描檔。每個都識別是沒有意義的，最好的方式是像@midleading：提出的那樣，開發一個工具，允許各位用戶批量識別不同的書。我已經提出了功能需求，有更多需求請提出。
另一個問題是，使用哪種OCR軟件。Google OCR對於識別1900年以來的印刷體合適，但是無法識別豎排排版位於行外的標點。對於古文，古籍酷效果更好，而且支持自動加標點，對開源項目有支持。我還測試了日本國立國會圖書館開發的OCR軟件，打開是因為是針對日文訓練的，效果不好。請大家考慮在Wikisource:OCR/測試加入各種類型文件的例子，以及測評更多OCR軟件。 維基小霸王（留言） 2024年1月15日 (一) 13:33 (UTC
- 我剛才錄入了來自這裡的文本，感覺還不錯，這也是一個選擇。 Midleading（留言） 2024年1月15日 (一) 13:37 (UTC)
- 匹配文本與文件也是個問題。 維基小霸王（留言） 2024年1月15日 (一) 13:51 (UTC)
- 2017年錄入四部叢刊的時候就是人工匹配的，匹配中發現了大量缺頁和重複，現在我認為也可以人工匹配。 Midleading（留言） 2024年1月15日 (一) 14:22 (UTC)
- 導入現在已有的文本應該要優先於自己識別，有很多書其實已經有已有的數字化文本，沒必要再重來一遍。目前這個來源的文本已經具備導入維基文庫條件了。 Midleading（留言） 2024年1月16日 (二) 09:45 (UTC)
- 2017年錄入四部叢刊的時候就是人工匹配的，匹配中發現了大量缺頁和重複，現在我認為也可以人工匹配。 Midleading（留言） 2024年1月15日 (一) 14:22 (UTC)
- 匹配文本與文件也是個問題。 維基小霸王（留言） 2024年1月15日 (一) 13:51 (UTC)
- 這種識別作業會有方便後續人工追蹤維護標籤對吧？—— Eric Liu（留言） 2024年1月15日 (一) 14:38 (UTC)
- 有沒有用戶願意維護就不知道了，關鍵是看有沒有用戶在維基文庫讀我們錄入的書。 Midleading（留言） 2024年1月15日 (一) 14:46 (UTC)
- 最基本的一個作用是作為圖書的全文搜索庫。現在，維基共享資源上傳了那麼多圖書，是無法全文搜索的。維基百科的搜索引擎和維基文庫是相連的，完成這個項目後，在搜索維基百科的時候，右邊就會有一個框框顯示出幾乎所有中文公有領域圖書的搜索結果，這不是很棒嗎？
- 至於標籤，這種校對頁面默認的未校對標籤就描述了這些頁面的狀態。即使不是大規模的機器識別，很多用戶輸入之後不校對，跟這樣做的結果是一樣的。 維基小霸王（留言） 2024年1月15日 (一) 23:39 (UTC)
- 有沒有用戶願意維護就不知道了，關鍵是看有沒有用戶在維基文庫讀我們錄入的書。 Midleading（留言） 2024年1月15日 (一) 14:46 (UTC)
- 對於印刷體Google OCR效果很好，但它的標點符號大多是半角的，建議OCR之後都替換一次。簡體測試文本剛好就是我用Google OCR錄入並校對的。--Kcx36（留言） 2024年1月15日 (一) 15:47 (UTC)
- 竪排古籍中低幾格或有空白的短段落，Google OCR有時無法保證行序、字序，還會把一行拆成幾塊。對雙行注文識別弱，即使是較高像素的圖片。Andayunxiao（留言） 2024年1月15日 (一) 16:04 (UTC)
- 錄入古文還是用古籍酷最好，不僅識別效果好，還能用人工智能加標點。 維基小霸王（留言） 2024年1月15日 (一) 23:32 (UTC)
- @Andayunxiao 對於古文，gj.cool優於Google。Google gj.cool 維基小霸王（留言） 2024年1月16日 (二) 04:51 (UTC)
- gj.cool給的額度很小 應該用不了 維基小霸王（留言） 2024年1月16日 (二) 08:48 (UTC)
- 沒關係，我們可以把這個功能放到WMCS裡面，讓其他用戶使用，估計用戶應該不會用完這些額度 Midleading（留言） 2024年1月16日 (二) 09:40 (UTC)
- 古籍酷看來效果很好，而且沒有缺字。中文古書通常行列分明，惜 Google OCR 未能利用這一點。額度就算小，能利用也是對用戶有益的。我無意用 OCR 錄入大量內容，僅作範例。 Andayunxiao（留言） 2024年1月17日 (三) 15:34 (UTC)
- gj.cool給的額度很小 應該用不了 維基小霸王（留言） 2024年1月16日 (二) 08:48 (UTC)
- @Andayunxiao 對於古文，gj.cool優於Google。Google gj.cool 維基小霸王（留言） 2024年1月16日 (二) 04:51 (UTC)
- 錄入古文還是用古籍酷最好，不僅識別效果好，還能用人工智能加標點。 維基小霸王（留言） 2024年1月15日 (一) 23:32 (UTC)
豎版圖書行外標點無法識別的問題可能將會解決，2月19日Google API更新後，請大家注意測試。--維基小霸王（留言） 2024年1月19日 (五) 02:03 (UTC)
藉此話題提個想法：我很喜歡Ctext的 字符識別連結頁面，不僅美觀，容易定位，而且其底層支持兩種輸入和修改模式，不需要用戶會使用排版代碼。效果上更是同一段源碼有三種展示模式——簡單修改模式（不合併行）、竪排陣列模式，和正文橫排模式（合併行）。不知道在 Mediawiki 的框架下我們能否實現類似功能，讓用戶只輸入一次，就可以有不同的展示方式。Andayunxiao（留言） 2024年1月19日 (五) 17:02 (UTC)
OCR軟件使用指引
編輯我認為維基文庫對OCR軟件的使用需要提出指引，避免將來某些用戶大量創建低質量的文本頁面充斥整個維基文庫，避免管理員刪除上百個甚至上千個低質量頁面：
- 當維基文庫收錄了原文對應數字化文本時，不應大量創建錯誤率高於該數字化文本的頁面。
- 當維基文庫尚未收錄原文對應數字化文本，但可公開訪問的外部網站收錄了原文對應數字化文本時，不應大量創建錯誤率高於該外部網站所提供的數字化文本的頁面。
Midleading（留言） 2024年1月16日 (二) 05:35 (UTC)
- 我用chatgpt將討論內容轉換成了方針，請修改：Wikisource:OCR#大規模OCR計劃。 維基小霸王（留言） 2024年1月16日 (二) 13:35 (UTC)
- 新手提問！請問有給古籍PDF免費做OCR的網站嗎？ Fremax（留言） 2024年1月17日 (三) 10:47 (UTC)
- @Ericliu1912：Wikisource:OCR有必要移動到Wikisource:光學字元辨識嗎？英文縮寫更常用，中文還涉及地區詞，地區詞轉換不知道為什麼沒生效。--Kcx36（留言） 2024年1月17日 (三) 11:22 (UTC)
- 正式名詞的話，第一次提到使用中文名稱為宜，之後可以多用簡稱。地區詞轉換已經修復，我也不知道是怎麼回事（ —— Eric Liu（留言） 2024年1月17日 (三) 12:04 (UTC)
- 維基文庫是沒有地區詞轉換的，因為不需要轉換原文中的地區詞 Midleading（留言） 2024年1月17日 (三) 14:37 (UTC)
- 文庫目前只有簡體和繁體模式，沒有開啓地區詞轉換。技術上，w:維基百科:繁簡處理 提到， 繁簡轉換總共通過三個轉換表來實現，這三個表所有維基項目共用，其中不包括地區詞。這一點是百科的周全考慮，而不是疏忽。見w:維基百科:字詞轉換/2015年轉換表更新說明，轉換表收錄相對保守，有些地區用字差異也未收入，如「著」，「着」。Andayunxiao（留言） 2024年1月17日 (三) 15:54 (UTC)
- 不贊同在作品頁使用地區詞轉換。文庫作品是對已有作品的複制。應該保持這些作品的完整性和原貌。幫助空閒提供轉換有益。 Andayunxiao（留言） 2024年1月17日 (三) 16:00 (UTC)
- 我和Ericliu1912在說的僅僅是Wikisource:光學字元辨識的頁面標題「光學字元辨識」和「光學字符識別」。--Kcx36（留言） 2024年1月17日 (三) 16:07 (UTC)
- 是我離題太遠了，抱歉抱歉。標題轉換是怎樣生效的，是不是通過地區詞轉換，我還不清楚。 Andayunxiao（留言） 2024年1月17日 (三) 16:23 (UTC)
- 我和Ericliu1912在說的僅僅是Wikisource:光學字元辨識的頁面標題「光學字元辨識」和「光學字符識別」。--Kcx36（留言） 2024年1月17日 (三) 16:07 (UTC)
- 我覺得沒必要移動，大家都知道OCR是什麼意思。w:Wikipedia:格式手冊/縮寫上說：「『大家都這麼用』，那麼我也可以這麼用。」--維基小霸王（留言） 2024年1月19日 (五) 02:02 (UTC)
- 正式名詞的話，第一次提到使用中文名稱為宜，之後可以多用簡稱。地區詞轉換已經修復，我也不知道是怎麼回事（ —— Eric Liu（留言） 2024年1月17日 (三) 12:04 (UTC)
- @Blahhmosh Lemonaka（留言） 2024年1月24日 (三) 00:32 (UTC)
- Yes? What's up? @Lemonaka Blahhmosh（留言） 2024年1月24日 (三) 02:15 (UTC)