メカ馬

隣り合う情報を使った手法 複数のスタイルに対応できないか 前回述べた方法は段落はすべて共通のスタイルであることを仮定している。しかしながら複数のスタイルが混在する場合が存在しないわけではないのでどうにか対応出来ないか…。 前回確認したデータからは以下のことがわかる。 段落境界で値の変動がある 同一段落内で"行送り"はほぼ変わらない 同一段落内で値がほぼ変わらないのは同一スタイルであるためである。したがって、複数スタイルが存在する場合にあっても同一段落内で値が変わらなければ、その変動から段落境界は見つけ出せそうという感触はある。 必須行数のはなし はい、OK。じゃあ、上から順に走査していって変動があったところを段落境界とすればいいね。 となれば良いがやってみると意外な形で失敗する。 段落境界の前後で行送りがほぼ等しいなど、段落境界をまたぐところで誤判定が生じることがある。 それというのも段落境界を行の空間的距離から推測するにあたって少なくとも３行は必要となる。１個だけだとそれが大きめの行送りかあるいは段落境界なのか比較できる対象がなく判定ができないためである。 順に捜査していく場合、基準となる行はもっともらしいものである必要があるのだが、段落境界毎にそれはリセットされる必要があり、どうにかしてもっともらしい基準を見つける方法が必要になる。 どうやって基準を見つけるか 対象をデータテキストに限った方法ではあるが、隣接行の行送りの値が近い場合にそれを基準とするというアイデアがある。要するに段落境界付近の値は使用せずに段落の中心から先頭・末尾に向かって走査していくような方法である。 ただし、依然として段落境界でもっともらしい基準として誤って採用されることがあるという問題は残っている。 どう実現するか 色々やってみてそれらしく動いたのは以下のような手順である。 もっともらしい基準値を見つける もっともらしい基準から段落境界に出くわすまで下に走査する もっともらしい基準から段落境界に出くわすまで上に走査する 統計量を基準値として段落検出する そう、最終的に統計量を使ってしまっているのである。全くもって遺憾。 それというのももっともらしい基準値を見つけられない場合などもあるため、最終的には何か理由をつけて判定する必要があるのである。 また、２と３の走査ではそれ

統計量に基づく手法 行送りと行間 行送りと行間の定義については前回の通りとし、実際にどちらを基準とするか。 人間が目視で判断する場合、行と行の距離を追っていると言うよりは行と行の隙間（空白）の大きさを元に判断しているように思われる。したがって、直感的には"行間"が基準に適しているように思うが…。 以下はいずれもとあるゲーム画面の文章について"文字の高さ"、"行間"、"行送り"を記したもので、実際に段落の境界が存在する行を青くハイライトしている。 一見すると"行間"にしても"行送り"にしても段落境界で前後と値が大きく離れており、前後との差から十分に段落境界を判断できるように見える。一方でPCOT界隈では行間狭すぎ問題なる問題があるように行間は0はおろかマイナスの値すら取り得る。そのため、比率のようなものでしきい値を設定する場合には注意が必要である。 また、上の図では"行間"が0, 1, 4 | 9, 12, 18となっており、9以上は段落境界である。しかしながら、0と1が多い中での4は一見すると段落境界のようにも思える。実際には、たまたまディセンダがない行の影響を受けて結果的に４と"行間"が広くなっているだけであり、段落境界ではない。一方でこの影響は"行送り"には大きく出ていない点に着目する必要がある。理由は行送りはToptoTopで求めているためディセンダの影響を受けないためである。もちろんアセンダがない場合は行送りであっても影響を受けることになるが、行間に比べて行送りは値が大きいためその影響度合いは相対的に下がる。つまるところ、"行間"、"行送り"ともに基準となるポテンシャルはあるが"行間"はアセンダ・ディセンダの影響を受けやすく、また非常に小さな値（あるいは負）となる場合があるため"行送り"の方が扱いやすいと言えそうだ。 統計量 統計量と書くとなにやら大仰であるが、ここで取り扱うのは平均値、中央値、最頻値のことである。単にそれらの値をもとにしきい値を設定しそれ以上の値であれば段落境界が存在すると判断する。

タスクと用語の整理 OCRを使って読み出した英文テキストについて、段落を検出する方法について検討します。同タスクを実現する方法はいくつか考えられますが、ここでは文字列間の空間的な距離を元に検出する方法について取り扱います。また、レイアウトはシンプルに縦方向にのみ存在するものとします（２段組などは考えない）。 まず用語の整理を行います。 空間的な距離 文字列における各行間の距離について行送りと行間が挙げられる。Wordだと行間は上記の行送りに相当するし、それぞれを逆に定義しているものも存在する。 ここでは 行送りと行間・文字送りと字間・文字サイズについて解説 などいくつかのサイトを参考にし、行と行の距離を行送り、行の隙間（上側の行の下部から下側の行の上部まで）を行間とする。 タイポグラフィ的な用語の整理 ベースライン（baseline）：文字の下部に沿って引かれた仮想的な線 ミーンライン（mean line）：x-height（"xの高さ"）の上部に沿って引かれた仮想的な線 アセンダ（ascender）：文字におけるミーンラインより上側の部分 ディセンダ（descendr）：文字におけるベースラインより下側の部分 ここで理想的な行送りと行間は以下で求められる。 行送り = ベースラインからベースラインまでの距離  行間 = 上側の行の最下端(ディセンダの部分)から下側の行の最上端(アセンダの部分)までの距離 OCRで取得可能な値 OCRでは認識した文字の矩形領域が取得できる。したがって、同一行のすべての文字の領域が持つ座標値の最小値、最大値から行全体の矩形領域が算出できる。 n行目の最上端をTop_n、最下端をBottom_nとしたとき、行送りと行間は以下のように算出する。 行送り ≒ |Top_n+1 - Top_n| 行間 ≒ |Top_n+1 - Bottom_n| 注意点は行送りにしても行間にしてもテキスト内容によって影響を受けること、行送りはベースラインが取得できないためTopで代替していること。 理想的にはベースラインを基に行送りを算出する必要があるが、OCRではベースラインは取得できないため算出可能なTopもしくはBottomを使う必要がある。一方で同一フォントサイズであってもアセンダ・ディセンダの有無によってTopおよびBottom

CapCapのV.0.9.2.7をリリース 主な変更内容 HTTP POST設定でヘッダの設定に対応 HTTP POST設定でJSONのオブジェクトおよび配列に対応 HTTP POST設定を大項目ごとに折りたためる機能に対応 サンプルプリセット（ChatGPT API）を追加 プリセット複製時に複製先の変更が複製元に及んでいた不具合を修正 HTTP POST設定 新たにリクエストヘッダを設定できるようになりました。これによりAuthorizationによる認証などヘッダが必要なAPIにも対応できるようになりました。合わせて、これまで設定することが出来なかったJSON ObjectおよびArrayについても設定できるようになりました。 ChatGPT APIについて サンプルプリセットを追加しました。HTTP POSTのヘッダおよびJSON ArrayとObjectに対応したため、その対応例となります。 継続的に使おうとすると費用が発生することになるので、無料枠が残っている間に遊んでもらえると幸いです。 DLページ： Home