第2楽章は、優しい旋律に囲まれた夢見るような楽章。それでいて、どこか寂しい雰囲気がただよう。
全体に流れるような雰囲気で、優しい風が吹いているかのよう。
何かを問いかけているのか、あるいは試行錯誤しているかのようだ。
眩しい光の中を進んでいくかのよう。
ゆっくりと歩いていくかのような旋律。
後半、ここで流れは止まり、色彩が消えていくが、またすぐに最初のテーマが帰ってくる。
最後に新しい流れるような旋律が現れて、かわいらしく終わる。
楽譜引用はヘンレ版から。
Apple Musicの方はこちら。
第27番も2楽章しかない小規模なソナタ。最初のテーマは葛藤なのか覚悟なのか。
2つ目のテーマは、1つ目に呼応するかのような静かなもの。
次第にテンポが上がって行き、嘆きを表現するかのような和音が連打される。
この楽章は10度が頻出する。左手の10度跳躍の上に、右手はテーマになり切れない音型が繰り返される。空虚な心情を表すかのようだ。
右手の速いとりとめもない動きの上で、左手で2つ目のテーマが奏される。
再度最初のテーマに戻る。
最後は2つ目のテーマがppで繰り返されて静かに終わる。
楽譜引用はヘンレ版から。
Apple Musicの方はこちら。
第2楽章は「不在」。形式は複合2部形式。寂しげな憂鬱なテーマで始まる。
2つ目のテーマは、昔の思い出を懐しむかのような明いもの。
この2つのテーマが繰替えされた後、休み無しで第3楽章に入る。
第3楽章は「再会」。最初に序奏があり、再会の喜びが表現される。
最初のテーマは、やはり懐しむかのような。透き通ったもの。
初期の作品に見られたような、色々なテーマのパレードが始まって、再会の喜びが表現される。。
展開部。展開部は最初のテーマの展開で始まることが多いが、新しいもので始まる。
すぐに再現部となる。
最後に、アンダンテとなって、しんみりとした場面となる。
自分の家に帰ってきて、今日1日の思い出を噛み締めているかのようだ。
楽譜引用はヘンレ版から。
Apple Musicの方はこちら。
ルドルフ大公との告別と再会をテーマにしたと言われる。曲はソナタ形式だが、最初に序奏が置かれ、最初の3音にLebewohlと書かれている。
アレグロで2つ目のテーマが奏される。
この部分はトリルが繰り返され、心の揺れ動きを表しているかのようだ。
展開部。
2つ目のテーマが左手で繰り返されるものの、あまり大きな展開は見られない。
再現部。
再現が一通り終わったあと、最初のテーマが右手と左手とで交互に奏され、2人で離れていきながら、手を振って別れを惜しんでいるかのようだ。
楽譜引用はヘンレ版から。
Apple Musicの方はこちら。
複合三部形式。なんとも陽気な民謡のようなテーマを用いた短い楽章。
踊っているかのような、あるいはおどけているかのようなテーマ。最初のテーマと、このテーマが曲全体で使われる。
楽譜引用はヘンレ版から。
Apple Musicの方はこちら。
三部形式。長い階段を登っていくかのような、あるいは人生の苦悩をつづるかのようなテーマで始まる。
中間部は左手で流れるような16分音符が奏され、夢の中のような、あるいは暖かな風が吹いているかのような場面となる。
最初のテーマが繰り返される。
最初のテーマが右手に現れつつ、左手には中間部の流れる音型が組み合わされるという興味深い展開が現れて終わる。
楽譜引用はヘンレ版から。
Apple Musicの方はこちら。
ここに来て、第2楽章に緩徐楽章を配置する3楽章制の古典的なソナタに回帰する。
第1楽章は主題の音型から「かっこう」と呼ばれることがある。
第1楽章は全体に明るいテーマで構成される。
展開部は転調するが長調のまま。
かっこうのテーマが展開される。
転調を織り交ぜるが、大きな発展は無くかっこうのテーマが繰り返される。
再現部。
展開部と再現部は繰り返しとなっている。
再現部の後に終わりを告げるパートがあり、左手で最初のテーマが奏される。
楽譜引用はヘンレ版から。
Apple Musicの方はこちら。
第12番の終楽章、第22番の終楽章と、このような調性の薄い高速な楽章がたまに現れる。
1つ目のテーマは、符点を主体としたもの。
もう1つは、16分音符2つがスラーでつながった音型。この2つが自由に展開される。
この音型が曲全体で繰り返し使用される。
曲は自由な構成だが、この音型が何度も使用されるため、不思議なまとまりを感じさせる。
楽譜引用はヘンレ版から。
Apple Musicの方はこちら。
前回の「冬休みの自由研究でOCRを作ってみた」では、最後の認識にMNISTを学習データとして使ったので、あまり精度が良くなかった。そこで、認識の部分にOSSのOCRであるtesseractを使用することで、再度検証してみることにした。tesseractには、-psmというパラメータで認識方法を指定できる。
Page segmentation modes:
0 Orientation and script detection (OSD) only.
1 Automatic page segmentation with OSD.
2 Automatic page segmentation, but no OSD, or OCR.
3 Fully automatic page segmentation, but no OSD. (Default)
4 Assume a single column of text of variable sizes.
5 Assume a single uniform block of vertically aligned text.
6 Assume a single uniform block of text.
7 Treat the image as a single text line.
8 Treat the image as a single word.
9 Treat the image as a single word in a circle.
10 Treat the image as a single character.
10を指定すれば、1つの文字として認識を行うことができる。もちろん、tesseractがあるなら、そのままOCRとして使えばいいわけで実用性あるの? という話になるが、tesseractは、特定の苦手なシーンがあり、今回の方法でそれが克服できないかを検証することが目的だ。合わせて、手軽に使えるOCRの中では個人的には一番精度が高いと評価している、Google Cloud Visionとの比較もしてみることにする。Google Cloud Visionは、このサイトで簡単に試してみることが可能だ。
今回は、こういう画像を使用。tesseractは二値化されていないと精度が著しく落ちるので、予め二値化してある。
Google Cloud Vision使ってみると、きちんと認識されている。さすがだ。
今回のOCRは数字が等幅フォントで1行で書かれたものを処理対象とするため、ここから切り出してから処理する。
まずは、普通に切り出したものを処理してみる。tesseractというオプション指定を追加して、分解した文字をtesseract -psm 10で1文字ずつ認識するようにしてみた。
$ docker run -it --rm -v /tmp:/tmp ruimo/lightocr tesseract /tmp/form000.png
3.14159265
正しく認識されている。もっともこれは、tesseractで-psm 7を指定しても正しく認識できる。
$ tesseract form000.png stdout -psm 7 digits
3.14159265
Google Cloud Visionでもok。
お次は、イメージ切り抜きの際にズレて右側の罫線が入ってしまったケース。
普通にtesseractで認識してみる。
$ tesseract form001.png stdout -psm 7 digits
3.141592651
罫線部分が1と認識されてしまう。無理もない。今回のOCRで処理してみる。
$ docker run -it --rm -v /tmp:/tmp ruimo/lightocr tesseract /tmp/form001.png
3.14159265
等幅フォントを仮定して切り離した後に、幅が極端に小さなものは捨てるためきちんと認識できている。Google Cloud Visionだと、正しく認識できている。さすがだ。
次は罫線がもっと数字に寄ってしまったケース。
普通にtesseractで認識すると、
$ tesseract form003.png stdout -psm 7 digits
3.14159263
最後の5が3と誤認識されていることが分かる。今回のOCRを使うと、
$ docker run -it --rm -v /tmp:/tmp ruimo/lightocr tesseract /tmp/form003.png
3.14159265
正しく認識できた。等幅フォントを仮定して切り取るため、罫線がうまく削除できたのだと思われる。Google Cloud Visionだと、
やはり正しく認識できていてさすがだ。次は下に罫線が残ってしまったケース。
普通にtesseractを使うと、
$ tesseract form004.png stdout -psm 7 digits
1 0 .
全然ダメになってしまった。今回のOCRだと、
$ docker run -it --rm -v /tmp:/tmp ruimo/lightocr tesseract /tmp/form004.png
3 11159255
幾分改善するが、やはり誤読が見られる。もっとも横方向の罫線については、黒成分が極端に高いものを除外することで、除去できるかもしれない。Google Cloud Visionだと、
やはりきちんと認識されている。ここまではGoogle Cloud Visionの圧勝だ。次に印字が不鮮明なケースを検証してみる。ドット・インパクト・プリンタの場合、良く一部が不鮮明になるケースがある。これは6の下部が消えてしまった例。
tesseractで認識してみる。
$ tesseract form005.png stdout -psm 7 digits
3.14159255
誤読してしまっている。今回のOCRでは、
$ docker run -it --rm -v /tmp:/tmp ruimo/lightocr tesseract /tmp/form005.png
3.14159265
正しく認識された。1文字として認識する場合には精度が上がるようだ。Google Cloud Visionでは、
やはり圧倒的な強さを見せつけている。最後に全体にもっと不鮮明な上に罫線がカブっているケースを見てみる。
tesseractで普通に認識すると、
$ tesseract form006.png stdout -psm 7 digits
70001393652
最後の2桁を誤読しているが、左の罫線による悪影響は出ていなかった。今回のOCRを試してみる。
$ docker run -it --rm -v /tmp:/tmp ruimo/lightocr tesseract /tmp/form006.png
7000139369
正しく認識できた。Google Cloud Visionでは、
Google先生、全勝はならず。tesseractは、ホワイト・リストで「数字しかない」という情報を与えることができる(引数のdigits)が、Google Cloud Visionはそういう指定が無く、言語の指定しかできないので印字が不鮮明な場合は、tesseractの方が良い結果が得られる場合もあるようだ。
というわけで、割と良い結果が得られたので満足。
24番は一転して小規模となり2楽章しかない。ここから27番あたりまでは、あまり規模の大きなものは書かれておらず、小規模指向になっている。
最初に夢見るような序奏が置かれている。
最初の符点が曲全体で繰り返し使われる。
この音型も曲全体で使われる。
この曲では、初期の頃と同じように色々なテーマが出てくる。
ここの右手は音型は伴奏のようだが、展開部で使われる。
展開部は短調で始まる。展開部は非常に短かい。
呈示部の2つの音型が組み合わされる。
再現部。この曲は最後まで達した後、展開部から繰り返しが行われるという珍しい構成がとられている。
楽譜引用はヘンレ版から。
Apple Musicの方はこちらから。