画像から文字列を認識するOCRシステムを、SSDとCRNNで。
最初に、SSDで文字列領域を矩形として抽出、矩形領域に対してCRNNで文字列を出力する構成です。
SSDはTensorflow Object Detection APIで、COCOだけでは十分な精度が出なかったので、SynthTextとCOCOを使って自前学習、CRNNはPytorchで実装されているモデルを利用しました。（学習は、EC2のP2インスタンスで約1.5日かかりました）
検出のSSDモデルは傾きとスケール変化には弱かったり、CRNNはアルファベットのみの学習モデルで記号は認識できない等の制約がありますが、簡易的なOCRであれば簡単に作れそうです。
CVPR2019で発表された、元画像と元画像をターゲット画像に変換するためのクエリ文を組み合わせた画像検索方式。以下、論文について簡単にまとめてみます。
これは図を見ると理解しやすいと思います。エッフェル塔の画像と「人が写ってない、夜間」というクエリ文を組み合わせて検索すると、塔がズームされた夜のエッフェル塔画像が結果として得られるようにする。
こういった検索をしたいケースというのは、結構あるように思います。新しいコートを買おうとして検索、画像検索結果を眺めていると良さそうな物を見つける。色は良いけど丈がもう少し短ければなぁと思って「丈短め」と検索、みたいなことが出来ると望んだ結果を得ることが容易になりそうです。
これも図を見て全体像を把握するとわかりやすいと思います。まず最初に、ResNet-17を用いてクエリ画像（参照画像）の特徴マップを得ます。また、クエリ文もLSTMを用いて特徴ベクトル
に変換します。そして、この二つを統合した特徴を用いてターゲット画像を検索するのですが、ここでTIRGという新しい統合方式を提案しています。
特徴ベクトルの統合は、以下のように計算されます。
と
は図中のgated featureとresidual featureに対応していて、
と
は学習により得られるパラメータです。
この数式の直感的な理解には、ResNetのResidual Blockを考えると良いようです。求めたいクエリ画像に対する変換結果（ResBlockで言うに相当）は、クエリ画像に基づいた特徴マップ
（Identity mappingの
に相当）をReferenceとして、クエリ文に基づいた特徴マップ
（残差の
に相当）で補正することで得られるというのが提案方式のアイデアです。
また、と
は次のように計算されます。
はシグモイド関数、
はelement wiseの積、
は2d convolutionとbatch normalizationを表し、
は3x3のconv filterです。
の方は、クエリ画像の特徴マップを変換するのではなく、シグモイド関数のゲートで元画像の情報をどの程度保持するかを制御するようになっています（0に近いと元画像の特徴マップをほとんど残さないが、1だとそのまま）。
TIRGを使って求めた特徴ベクトルとターゲット画像の特徴ベクトルを近づけ、非類似画像の特徴ベクトルから遠ざけるように学習する。学習に用いるのは、Softmax Cross-Entropy Loss。
はmini batchのサイズで、
は少しわかりにくいですが、mini batchの中で1つのpositiveなサンプル
と
個のnegativeなサンプル
を持つ集合
を作成するプロセスの繰り返し回数となっています。あと、類似度カーネル
ですが、内積とnegative L2ノルムを使ったそうです。
3つのデータセットを使った評価が行われています。メインの評価指標はrecall at rank k(R@K)。R@Kは、こちらのPDFを見るとわかりやすいです。
https://ils.unc.edu/courses/2013_spring/inls509_001/lectures/10-EvaluationMetrics.pdf
数値比較の詳細は論文を参照。
画像につけられたdescription文が、1語違いになっているペアをクエリ画像とターゲット画像とし、異なる1語をクエリ文とする。
| method | R@1 | R@10 | R@50 |
|---|---|---|---|
| TIRG | 14.1 | 42.5 | 63.8 |
既存手法と比べて、R@1で8pt近く向上。TIRG以外の統合方式に対して比較した場合でもR@1、R@10、R@50のいずれにおいてもBestな結果となった。結果画像の一部は以下の通り。
60k枚の画像と、"red tomato"や"new camera"のような物体に対する名詞と形容詞のラベルがついたデータセット。Image retrievalのタスクにおける評価では、同じ物体ラベルで異なる形容詞を持つペアをクエリ画像とターゲット画像とし、ターゲット画像の形容詞をクエリ文として評価。
| method | R@1 | R@10 | R@50 |
|---|---|---|---|
| TIRG | 12.2 | 31.9 | 43.1 |
R@1ではBestではなかったが、R@10とR@50ではTIRG以外の統合方式の中でBestな値となった。
この論文で新しく導入されたデータセット。既存データセットにはない、複雑な修正クエリ文を含む。ちなみに、データセットはコードと併せて公開する予定だそう。
| method | 3D to 3D | 2D to 3D |
|---|---|---|
| TIRG | 73.7 | 46.6 |
実際に検索システムに導入されると、ユーザーが本当に検索したい情報に辿り着く可能性が高まる、面白いアイデアだと思いました。クエリ画像とクエリ文からターゲット画像を検索するというものですが、例えば洋服を探しているときは、最初に「グレーのコート」などと検索して、その結果を見ながら、修正クエリ文を入れるというステップになると思うので、一連の検索のコンテキストや、「ボタンは黒」みたいな空間的な修正対象の位置なども使えるとより良い結果が得られるかもしれません。（空間的な情報の有無は論文内でもAblation studyで論じられてます）
https://arxiv.org/pdf/1705.03098.pdf
画像から3次元の関節を推定する論文。ただし、入力は画像ではなく2次元の関節座標で、そこから3次元の関節を回帰する。
2次元から3次元へのマッピングをDNNとして学習する手法は、これまでにも提案されてきているが、それらに共通するのは、3次元座標を2次元（画像や関節座標）から直接推定することはそもそも困難という認識である。本論文では、Dropout、Batch NormalizationとReLU、Redisual Connectionを用いたシンプルなDNNにより、SOTAな手法に負けない精度で3次元座標の推定が可能であることを示している。
3次元の関節座標へ変換するを定義し、変換後の関節座標と正解関節座標の差を最小にする
を求める。
は、DNNでモデル化し、次の図のような構成を提案している。
図には書かれてないが、二つのlinear layerが入力直後と出力直前に存在し、また図のブロックは二層存在するので、linear layerは合計で6となる。学習パラメータ数は4Mから5M。
Residual connectionsを設けることで、エラーが10%も低下した。
Linear-ReLuとResidual connectionsを用いたシンプルなネットワークの場合、2次元座標のGTで学習すれば良い精度を得られるが、 detectorの2次元座標で学習した場合や、2次元座標のGT で学習してdetectorの2次元座標で推論した場合には精度低下が見られた。Batch normとdropoutを併用することで、これらのケースでの精度を改善することが出来た。
Batch normと組み合わせて、各層の重みのノルムの上限を1.0に正規化することで、汎化性能の向上が見られた。
学習時のハイパーパラメータは表のようになっている。
| epochs | 200 |
| optimizer | Adam |
| learning rate | 0.001 (exponential decay) |
| Initialization | Kaiming initialization |
評価に使ったデータセットは、Human 3.6MとMPII。Human3.6Mはその名の通り、3.6millionの画像があり、2d / 3d jointsやカメラパラメータのground truth を含む大規模なデータセット。一方のMPIIはもう少し小規模。
Linear-ReLu + Batch norm + Dropout + Residual connectionのシンプルな基本構成で、既存手法を超える性能を達成しているのは驚き。論文タイトルにもあるように、これらからの研究のベースラインになる（改善が色々とできそう）手法だと思われるし、detectorの2次元座標があれば手軽に3次元座標が得られるので、応用もしやすそうである。
以前、ナンバープレート認識モデルを参考にして、ロゴ認識CNNを作りました。
前回のモデルは独自モデルだったのと、物体候補領域はSelective Searchで実行していたため計算時間が大きかったので、one stageで標準的なモデルを使用するように変更してみました。
Tensorflow Object Detection APIにあるSSDモデルで、Flickr Logos 27 datasetを学習してみたところ、割と簡単にロゴ検出ができました。
検出した結果を見ると、誤検出はない一方で、未検出が結構多い印象です。領域サイズが小さかったり、向きや傾きが大きい場合に未検出が増えている様子なので、Data augmentationを見直すなどは必要になる感じですね。
CNNの中でもよく使われるアーキテクチャの一つであるGoogLeNet。GoogLeNetの層を構成するのがInceptionで、今までにv1からv4までの改良が行われていて、またresidual blockを導入したinception-resnetも提案されています。
Mediumの解説記事を参考に、基本となるGoogLeNet（V1）とKerasなどのフレームワークでもよく使われるV3を簡単にメモ。
A Simple Guide to the Versions of the Inception Network | by Bharath Raj | Towards Data Science
Inception V4の論文では、以下のように定義されているので、ここでもそれを参照します。
# The total loss used by the inception net during training. total_loss = real_loss + 0.3 * aux_loss_1 + 0.3 * aux_loss_2
42層のモデルで、GoogLeNetに対して2.5倍程度の計算コストで、Top1 errorを5.6%ほど改善している。
例えば、ファイルに含まれる数の合計を計算する場合。
int DoSum(const std::string& file);
ファイルに含まれるのが正の値だけであれば、負の値でエラーを示すことができるが、正も負も含まれる場合には適用できない。
int DoSum(const std::string &file, int &sum) { /* return value of zero indicates a sum has been computed other values indicate an error status */ }
struct ReturnData { int sum; int error_indicator; }; struct ReturnData DoSum(const std::string &file) { }
int DoSum(const std::string &file) { /* do calculations */ if (error_has_occurred) throw some_appropriate_exception(); else return calculated_sum; }
1と2の場合、エラーが致命的でなければ呼び出し側で何もする必要がない一方で、エラー処理をしなくても動くので変な結果で処理が進んでしまうことがある。 3の場合、例外をcatchしなくても処理が異常終了するので変な結果が処理が進むことはないのに対し、この関数を使う全ての呼び出し側でcatchして適切に扱うようにしないといけない。
Googleのコード規模でということなので、自分たちのサイズで考える必要がありますが、既存のコードに対して、例外を導入するコストが高いので、 Google C++ Style Guideでは例外は使わないとしています。 ただ、自分たちの問題で考えてみても、関係する全てのコードで新しく例外処理を実装するのはやはり大変なので、1か2を使うことが多い印象です。
