维基文库讨论:光学字元辨识
对于手写古籍 古籍酷与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)