はじめに
果たしてQiitaの界隈にHR/HMリスナーがどのくらいいるのか分かりませんが…
ごめんなさい、『Qiitaのタイトルに イングヴェイ って書きたいがため』にこの記事を書いています。
あと、できればBGMとして劇場版超速弾きロボ_マルム～スティンガー_の唄を聴きながら読んでもらえると幸いです。
自分のスマホのBookアプリのライブラリを久々に見直したところ、数年前(2019年)に自分でEpub化したイングヴェイの『Yng-WAY-俺のやり方(RELENTLESS THE MEMOIR)』がありました。(発売は2013年)
このデータは元々スキャンしたjpgしかなかったのですが、これをEpub化するのに当たって色々思い出したので備忘録として残しておこうと思います。
尚、結果としてはjpgをzip化したファイルが56MBだったものがepubだと7.2MBになったのでかなりダイエットになったと思います。
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を購入し、scansnapを2回買い替えるぐらい自炊してきた過去があります。
その中でずっと思っていることがありました。
『漫画ならまだしも、テキストが主体の本をjpg化してzipで固めて固定レイアウトで読む!のってなんだろうなぁ…』
『日本語のOCRってキッツイよなぁ…、OCRやってる間PC放置だし精度もイマイチだしなぁ。』
『いつか、どこかの会社が日本語のfontの網羅したカタカナの「ヘ」とひらがなの「へ」をうまいことやってくれるOCRを低価格で出してくれないかなぁ』
というか自炊経験者ならみんな思うことですが、2009年当時はこんな感じでしたが…
2019年にAIで日本史研究者やマニアが狂喜乱舞する「くずし字」の翻訳ツールが開発を目にしました。
『これは時代が追いついてきたぞ！』
ということで！
なんでもいいからGoogle OCRを試したい
という欲求が湧いてきました。
ここでの『何でもいい』ってのは適当なwebページを1枚とかそういうテストというレベルじゃなく個人の利用として『ある程度ちゃんと使えるのか？』 という感じです。
なので、ベンチマークとしては以下を試そうと思いました
- 縦書きの本
- いい感じでカタカナとひらがなが織り混ざってるもの
- 図解は厳しいと思うので図解のないもの
- ラノベのような造語ではなく専門用語が結構入ってそうなマニアックなもの
- 無料枠でなんとかできる範囲
ここで、条件を満たしたのが、手持ちのイングヴェイの本だったんです。(こじつけ)
トラップ発動！その1
6年前にスキャンした本をunzipして中のjpgを見て思いました「あ、これポイっとAPIに投げればいいってわけじゃなくちょっと加工しなきゃいけないやつだ」と。
今までのOCRを使った経験を踏まえて
- 各ページのフッターにページ数がある
- 書籍の奇数ページの上に章のタイトルが入っている
まぁ、この辺は許容範囲ないですが、何より面倒だと思ったのは
文章がページの上下に分かれている (分かれてないページもあったりする)
これでした。
はいはい、ImageMagick、ImageMagick
ということで、ImageMagickを使って下処理をしていきます。
まずヘッダー、フッター分の上下100pxを無くします。
convert test.jpg -shave 0x100 trimmed.png
上記のものを上下で分割します。
convert trimmed.png -crop 100%x50% splitted.png
横に結合(順番は引数の順番になるので引数の末尾側から最初の画像になる)
convert +append splitted-1.png splitted-0.png joined.png
↓こんな感じの1ファイルにできる
トラップ発動！その2
各章の一番最初のページのレイアウトが個性的！
最初の文字(この場合『俺』って漢字)と右側のデザインなんだよ！いる？
ということで、もくじから各章のページに該当するjpgの右側をトリミングするものを先に書いて、くっつけるbatにします。
# 目次ページの配列を用意
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）へ！
公式のドキュメントとかを調べるとnode.jsやpythonが出てきます(Rubyとかもあります）ので好きな言語ででやりましょう。
気になっていたのは、ここまで下準備しても 章の一番最初の文字が2行に渡っているのでこれが、OCRをかけた時にどうなるのか？ ということでした。
俺
がスウェーデンの小さな子どもだった頃、Yngve (も
--以下略--
のだ。
この時代に、ある若者のグループがイングヴィ=フレイ
『素晴らしい！』
上記の通り結果のtextを見ると結構いい感じに思えます。(OCRなので改行も画像の通りになります)
が、「やっぱり、こうなるよねー」ってところがたくさんありました。
(それでもローカルでtensorflowのocrとかでやった時より素晴らしい精度でした。)
例を挙げておきますが
| 画像 | レスポンスのtext | 事象 |
|---|---|---|
| アルバム | ァルバム | アが小文字 |
| 『セヴンス･サイン/THE SEVENTH SIGN』 | 『セヴンス･サイン THE SEVENTH SIGN』 | /がなくなっている |
| …… | ･･････ | 三点リーダーが個別になっている |
| ――大体〜あったし―― | ――大体〜あったし――― | 前後の「―」の数が違う |
| 』 と 『 | 』 と『 | 『』の前後の半角スペースがあったりなかったり |
そこは、もう怒涛のgrepです。
縦書き用にxhtmlを色々やる
さて、この段階に来ても色々やることがあります。
多分なろう系のラノベサイトなどを自分でepub化とかしたことある方なら分かると思うのですが、
22歳の時、1日で40万枚を売り上げ
この半角の文字の桁数によって 縦書きの扱いをどうするか？ とかを自分で決めていきます。
このイングヴェイの本では、途中で車の話が出てくるんですが
V型12気筒のジャガー・Eタイプ
とか、
トライアンフTR6
とか、こういうのがメッチャ出てきます。
その度に、『この場合はこうしよう』みたいな定義を自分で作ってxhtmlの変換用の自作のプログラムに記載し、ブラウザで確認していきます。
この作業が一番大変でした。
そして元の本の方は人名は一部のバンドはカタカナ表記なのに、アルバム名は半角英字表記になってるのが気持ち悪くて『作ってる人もきっと同じ感覚になって大変だっただろうなぁ』と思いました。
まとめ
好奇心から始まったものでしたが、50MB以上あったものが、表紙やギターの写真集などの画像ファイルがあるものの7MB程度になり、APIの無料枠内で文字の大きさを変更したりできるようになったEpubを作れたのでかなり満足いく結果になりました。
その上で、声を大にして言いたいのはマニアックな本こそ是非、電子書籍化してほしいな、 イングヴェイの2000年代以降の音質どうにかならんかな？ と思った次第です。