【俺のやり方】【OCR】イングヴェイの自伝をGoogleのCloud Vision APIを使って電子書籍化した話【自炊】【ImageMagick】

## はじめに
果たしてQiitaの界隈にHR/HMリスナーがどのくらいいるのか分かりませんが…  
ごめんなさい、『Qiitaのタイトルに **[イングヴェイ](https://ja.wikipedia.org/wiki/%E3%82%A4%E3%83%B3%E3%82%B0%E3%83%B4%E3%82%A7%E3%82%A4%E3%83%BB%E3%83%9E%E3%83%AB%E3%83%A0%E3%82%B9%E3%83%86%E3%82%A3%E3%83%BC%E3%83%B3)** って**書きたいがため**』にこの記事を書いています。
あと、できればBGMとして[劇場版超速弾きロボ_マルム～スティンガー_の唄](https://www.nicovideo.jp/watch/sm29438884)を聴きながら読んでもらえると幸いです。

自分のスマホのBookアプリのライブラリを久々に見直したところ、数年前(2019年)に自分でEpub化したイングヴェイの『[Yng-WAY-俺のやり方(RELENTLESS THE MEMOIR)](https://www.amazon.co.jp/dp/4401638522/)』がありました。(発売は2013年)  
このデータは元々スキャンしたjpgしかなかったのですが、これをEpub化するのに当たって色々思い出したので備忘録として残しておこうと思います。

尚、結果としてはjpgをzip化したファイルが56MBだったものがepubだと7.2MBになったのでかなりダイエットになったと思います。

```bash
 56M -rw-r--r-- 1 kurokky  blacktree  56M  8月 30  2013 yjm.zip
7.6M -rw-r--r-- 1 kurokky  blacktree 7.6M  8月 16  2019 ymj.mobi
7.2M -rw-r--r-- 1 kurokky  blacktree 7.2M  8月 23  2019 ymj.epub
```

## きっかけ
私は日本でKindleが未発売の2009年頃にアメリカのAmazonで[Kindle 2](https://www.itmedia.co.jp/ebook/articles/1103/25/news031.html)を購入し、[scansnap](https://scansnap.fujitsu.com/jp/)を2回買い替えるぐらい[自炊](https://ja.wikipedia.org/wiki/%E8%87%AA%E7%82%8A_(%E9%9B%BB%E5%AD%90%E6%9B%B8%E7%B1%8D))してきた過去があります。

その中でずっと思っていることがありました。

『漫画ならまだしも、**テキストが主体の本をjpg化してzipで固めて固定レイアウトで読む**!のってなんだろうなぁ…』

『日本語のOCRってキッツイよなぁ…、OCRやってる間PC放置だし精度もイマイチだしなぁ。』

『いつか、どこかの会社が日本語のfontの網羅した**カタカナの「ヘ」とひらがなの「へ」をうまいことやってくれるOCR**を低価格で出してくれないかなぁ』

というか自炊経験者ならみんな思うことですが、2009年当時はこんな感じでしたが…

2019年に[AIで日本史研究者やマニアが狂喜乱舞する「くずし字」の翻訳ツールが開発](https://pc.watch.impress.co.jp/docs/news/1195499.html)を目にしました。

『**これは時代が追いついてきたぞ！**』

ということで！

## なんでもいいからGoogle OCRを試したい
という欲求が湧いてきました。  
ここでの『何でもいい』ってのは適当なwebページを1枚とかそういうテストというレベルじゃなく個人の利用として『**ある程度ちゃんと使えるのか？**』 という感じです。

なので、ベンチマークとしては以下を試そうと思いました

- 縦書きの本
- いい感じでカタカナとひらがなが織り混ざってるもの
- 図解は厳しいと思うので図解のないもの
- ラノベのような造語ではなく専門用語が結構入ってそうなマニアックなもの
- 無料枠でなんとかできる範囲


ここで、条件を満たしたのが、手持ちのイングヴェイの本だったんです。(こじつけ)

## トラップ発動！その1

6年前にスキャンした本をunzipして中のjpgを見て思いました「あ、これ**ポイっとAPIに投げればいいってわけじゃなくちょっと加工しなきゃいけないやつ**だ」と。  


今までのOCRを使った経験を踏まえて

- 各ページのフッターにページ数がある
- 書籍の奇数ページの上に章のタイトルが入っている

まぁ、この辺は許容範囲ないですが、何より面倒だと思ったのは

**文章がページの上下に分かれている** (分かれてないページもあったりする)
![yjm_sample2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1043424/6cece4cb-34c6-ff68-4dea-f5f801d24295.png)

これでした。

## はいはい、ImageMagick、ImageMagick

ということで、ImageMagickを使って下処理をしていきます。

まずヘッダー、フッター分の上下100pxを無くします。

```bash
convert test.jpg -shave 0x100 trimmed.png
```

上記のものを上下で分割します。

```bash
convert trimmed.png -crop 100%x50% splitted.png
```

横に結合(順番は引数の順番になるので引数の末尾側から最初の画像になる)

```bash
convert +append splitted-1.png splitted-0.png joined.png
```

↓こんな感じの1ファイルにできる

![img_00153_.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1043424/9910b92f-a455-9ef8-7d17-8c4ef42d1186.png)


## トラップ発動！その2

各章の一番最初のページのレイアウトが個性的！

![yjm_sample1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1043424/e5a88d39-e22a-d493-8427-c3d5a722b075.png)


最初の文字(この場合『俺』って漢字)と右側のデザインなんだよ！**いる？**

ということで、もくじから各章のページに該当するjpgの右側をトリミングするものを先に書いて、くっつけるbatにします。

```bash:sample.sh
# 目次ページの配列を用意
CHAPTER_PAGES=(32,35…)
max=279
for((i=32;i < $max;i++));do
	id=`printf "%05d" ${i}`
	#上下100pxなくす
	`convert img${id}.jpg -shave 0x100 trimmed.png`
	if `echo ${CHAPTER_PAGES[@]} | grep -q "${i}"`; then
		#こっちは一旦左右を50%に分割
		`convert -crop 50%x100% trimmed.png img${id}.png`
		#上記で勝手に-0.pngと-1.pngができるので左半分を上下に分ける
		`convert -crop 100%x50% -page +0+0 img${id}-0.png splitted.png`
		rm img${id}-0.png
	else
		`convert trimmed.png -crop 100%x50% -page +0+0 splitted.png`
	fi
	convert +append splitted-1.png splitted-0.png img_${id}.png
	rm splitted*.png
done
```

一旦上記のような感じでpngを作って、これを各ページでやっちゃうとOCRのリクエスト数が多くなるので**最終的には4ページぐらいを1つの画像とするbat**を書きました。  
が…

えぇ、お気づきの通りGoogleのOCRとかってより**下準備が面倒だって話が今回の趣旨**です。
(料理も開発もOCRも下処理が大事ですね。)

## やっと本丸のGoogle OCR（Cloud Vision API）へ！

公式の[ドキュメント](./https://cloud.google.com/vision/docs/detect-labels-image-client-libraries?hl=ja#client-libraries-install-python)とかを調べるとnode.jsやpythonが出てきます(Rubyとかもあります）ので好きな言語ででやりましょう。  
気になっていたのは、ここまで下準備しても **章の一番最初の文字が2行に渡っているのでこれが、OCRをかけた時にどうなるのか？** ということでした。

```text
俺
がスウェーデンの小さな子どもだった頃、Yngve (も
--以下略--
のだ。
この時代に、ある若者のグループがイングヴィ=フレイ
```

『**素晴らしい！**』

上記の通り結果のtextを見ると結構いい感じに思えます。(OCRなので改行も画像の通りになります)  
が、「やっぱり、こうなるよねー」ってところがたくさんありました。  
(それでもローカルでtensorflowのocrとかでやった時より素晴らしい精度でした。)

例を挙げておきますが

|画像|レスポンスのtext|事象|
|-|-|-|
|アルバム|ァルバム|アが小文字|
|『セヴンス･サイン/THE SEVENTH SIGN』|『セヴンス･サイン THE SEVENTH SIGN』|/がなくなっている|
|……|･･････|三点リーダーが個別になっている|
|――大体〜あったし――|――大体〜あったし―――|前後の「―」の数が違う|
|』 と 『|』 と『|『』の前後の半角スペースがあったりなかったり|

そこは、もう怒涛のgrepです。

## 縦書き用にxhtmlを色々やる

さて、この段階に来ても色々やることがあります。  
多分なろう系のラノベサイトなどを自分でepub化とかしたことある方なら分かると思うのですが、

```text
22歳の時、1日で40万枚を売り上げ
```

この半角の文字の桁数によって **[縦書きの扱い](https://kousei.club/numbers-in-vertical-writing/)をどうするか？** とかを自分で決めていきます。  
このイングヴェイの本では、途中で車の話が出てくるんですが

```text
V型12気筒のジャガー・Eタイプ
```

とか、

```
トライアンフTR6
```

とか、こういうのがメッチャ出てきます。

その度に、『この場合はこうしよう』みたいな定義を自分で作ってxhtmlの変換用の自作のプログラムに記載し、ブラウザで確認していきます。   

この作業が一番大変でした。

そして元の本の方は人名は一部のバンドはカタカナ表記なのに、アルバム名は半角英字表記になってるのが気持ち悪くて『作ってる人もきっと同じ感覚になって大変だっただろうなぁ』と思いました。

## まとめ

好奇心から始まったものでしたが、50MB以上あったものが、表紙やギターの写真集などの画像ファイルがあるものの7MB程度になり、**APIの無料枠内で文字の大きさを変更したりできるようになったEpubを作れた**のでかなり満足いく結果になりました。

その上で、声を大にして言いたいのは**マニアックな本こそ是非、電子書籍化してほしい**な、 **イングヴェイの2000年代以降の音質どうにかならんかな？** と思った次第です。