Qiitaの17日目のエントリーになります。こんにちは、弥生のつじのです。普段は弥生のインフラチームで商用環境の構築・運用などを主に担当しています。Azure(以下Azure)に触れる機会が比較的多いので、Azureに絡めた話題としてAzureのOCRサービスについて紹介したいと思います。Readerの略です。画像データ内の文字を認識してtxt、csvなど文字列データへ変換する装置のことです。今回Azureで使用する主なリソースについてです。Azure内部の操作を自動実施したり、外部からのトリガーで特定の操作が可能なリソースです。GUI上からある程度直感的に処理の作成が可能です。Azureが提供しているOCRサービスです。Azure上に以下の様な環境を構築します。次はAzureのOCRの精度検証です。アップロードする画像はアドベントカレンダーなので、冬らしい和歌を調べて画像にしました。...これは...元々24文字ある和歌ですが、OCR結果内に和歌に含まれる文字は15文字しか無いですね。『朝ぼらけ』の行に関しては欠落している。この結果からAzureのOCRサービスは精度出ませんでしたで終わってはなんとも味気ない...そこで多少頭を捻り何が悪かったのか考えてみました。予測1:このOCRサービスは左から読み込み、その結果を最終的に左から横書きで出力しているように見えるので元画像も横書きがよいのでは?予測2:また選んだ書体には文字の見え方を意識した線や太さの強弱が発生してる、機械に読み込ませるならゴシックのような書体が良いのではないか?このような予測を立てた上で、一つずつ修正して結果を確認しました。書体を行書体からゴシックに変更してみます。文字単位で見れば正しく変換されていますね!しかし、行単の順番が入れ替わっており、これでは読めない。縦横を入れ替えてみるだけだとどうでしょう。『朝ぼらけ』の行は出てきましたが、文字単位では正解率では書体の変更ほど変わらないですね。最後に書体、縦横両方の変更を加えた結果を確認します。雪!?読める!間違いもなく正確に画像データから文字列データに変換されています。※今回の検証では画像の空白は考慮せず、文字サイズのみ統一しています。今回の簡単な検証の結果、文字の変換精度という観点で見ると『書体の変更>縦書き横書きの変更』、行順序の変換精度という観点では『書体の変更<縦書き横書きの変更』でした。AzureのOCRサービスに画像データを取り込む際にはゴシックのような書体で横書きが良いようです。(書いてみると当たり前ですが...)しかし文字精度に書体が影響するのはわかるのですが行順序については、OCRサービス側でどのようなロジックとなっているのかもう少し検証してみたいと思います。OCRサービス側で前後の行と意味のつながりを意識していたりするのかなど。Igniteにて機械学習に力を入れていくという発表があり触れてみたいと思っていましたが、このアドベントカレンダーが良いきっかけとなりました。Azureには引き続き新しいリソース機能がGAされてゆくと思いますので、置いて行かれないようこまめに新しい情報に触れていきたいと思います。去年のアドベントカレンダーも12/17に記事を書いたので、それから色々あったな―と思い返して楽しく記事を書いてました。18日目は、mugi_unoさんです。