なぜ、自前の顔画像データなのか

あなたの利用目的で、そのライブラリが十分な顔照合性能をもっているかどうかを評価するには、実際に使って評価することだ。
その評価を、再現性のあるものにするには、画像データを照合用のデータセットとして、利用可能になっていることだ。
さらに、顔照合を利用するシステムを作っていると、数年おきに顔照合ライブラリの見直しをする必要にせまられだろう。機械学習に関わるライブラリやその土台となるデバイスはまだまだ、進化の途中であるからだ。
そのため、自前で作った顔画像のデータセットは、数年後にも出番がやってくる。
そういうわけで、自前のデータセットの作り方について述べる。

想定するユースケースは

想定するユースケースでの顔の大きさ、画像サイズ中の比率。
カメラの設置高さ（視線と同じ高さか、見下ろし画像か）
顔の向きの多様性。
照明条件。
被験者の人数の規模
こういった条件の違いが、ユースケースの中での顔照合ライブラリの性能に影響してくる。
パスポートでの顔照合の精度が高いものが、そのままあなたのユースケースでの精度になるわけではない。

自前のデータセットを整備する目的を明確にする。

被写体の年齢層の分布はどうするのか。
撮影時の被写体は、協力行動がある（＝照合のために人がカメラを覗き込むなど）ときの画像か、協力行動なしの画像か。
被写体の顔を撮影するカメラは、天井にあるのか、目線高さにあるのか。
安定した照明条件が得られるのか、照明条件は変動が大きいのか
顔の一部が隠れるのをどの程度まで許容するか。
- 目的によって顔の隠れ具合の許容幅が違ってくる。
  − 被験者の人数の規模は、１：N照合をする際の精度に影響してくる。人数が増えてくると他人の空似が増えてくるから、運用目的によって、必要な評価用の人数の規模が変わってくる。顔だけの情報でビル内のコンビニでの支払いをしようとするならば、どれくらい間違いを減らすかが重要になってくるだろう。（ビル内のコンビニを利用する人の数に制限があったとしても）ユースケースによって許容できるものは変わってくる。
  犯罪捜査のための顔照合の場合には、上位何件の中にその人物が見つかればよいという運用もある。

既存ライブラリを利用して、評価用の顔データセットを作る。

顔が写っている一連の画像の中から、既存の顔検出ライブラリを使って、顔検出結果の顔切り出し画像を集める。
顔の未検出画像を集めて、それらに対しては、別の顔検出ライブラリを使って追加の顔検出を実行する。
その後の未検出画像に対しては、手作業で顔の切り出しを実施する。
自動検出と手作業での顔検出とによって、顔を切り出せば、全数手作業で顔検出の正解データを用意するよりは格段に楽になる。

照合用顔データは、切り出し画像を使うのが実際的

原画像を、そのままの解像度で保存すると、横の幅の10%くらいだと１００倍以上ディスクスペースを消費してしまう。
切り出し画像を使うことで、同じディスクスペースで100倍の顔を扱える。
照合について考えるときには、誤検出とか、元画像全域からの検出時間などについて考える必要はない。
だから、配布されている顔データベースも、マージン付きの顔の切り抜き画像であるのが大半だ。
ここでは、切り抜き画像での顔データベースを作る方法について述べる。

例：被写体になっている人物が少人数に限られている動画からの切り出し

この場合だと、少ない人数の範囲で画像を各人物ごとに１つのフォルダにグルーピングしていくのが簡単になる。顔照合の評価を、顔向きの変動や照明条件の変動、被験者の表情の変動などに対して実施したいのであれば、そのような変化のある動画を利用し、顔画像の自動での切り出しをすることだ。

おすすめしない例：若い女性アイドルグループが多数のメンバーが同時に写っている動画からの切り出し。

正解データを作る際の手間が増えてしまう。また間違ったラベリング（＝名前を間違って付ける）してしまう可能性が増えてしまう。そのためデータを用意する際の作業効率が落ちてしまう。若い女性でアイドルグループに属する人の顔は、平均顔に近い顔つきの人が多くなるので、人による顔照合でもだれがだれかわかりにくくなりやすい。どうしてもそのグループのメンバーでデータを作りたいときは、少人数だけ写っている動画を選んで切り出すことをおすすめする。

そのグループについて一人ひとりの名前を間違えずに言える人はその限りではない。

「愛があれば見分けられる」人はその限りではない。、

照合用の顔画像のデータセットのディレクトリ構造

顔照合用を評価するためのデータセットのための構造は、フォルダ名がその人物の名前になるようにしておくのがわかりやすい。それぞれの画像は、中央にその人物の顔が写っているように一定のマージンをつけて保存する。

        <train_dir>/
        ├── <person1>/
        │   ├── <somename1>.jpg
        │   ├── <somename2>.jpg
        │   ├── ...
        ├── <person2>/
        │   ├── <somename1>.jpg
        │   └── <somename2>.jpg
        └── ...
        <test_dir>/
        ├── <person1>/
        │   ├── <somename1>.jpg
        │   ├── <somename2>.jpg
        │   ├── ...
        ├── <person2>/
        │   ├── <somename1>.jpg
        │   └── <somename2>.jpg
        └── ...
        <valid_dir>/
        ├── <person1>/
        │   ├── <somename1>.jpg
        │   ├── <somename2>.jpg
        │   ├── ...
        ├── <person2>/
        │   ├── <somename1>.jpg
        │   └── <somename2>.jpg
        └── ...

valid フォルダには独立性の高いデータを

validデータには、撮影環境を変えたデータを用いよう。同じ日にち同じ照明環境の撮影にすると、test, trainのデータと似ているので、当然顔照合での類似度が高くなってしまうので、本当に顔照合に成功しているのかどうかが判明しなくなってしまう。そのことを防ぐために、独立性の高い撮影をしよう。

人物名を示すラベルはフォルダ名に

ここで重要なことは、人物名を示すラベルはフォルダ名で指定すること。そうすることで、フォルダを開くことで、その中にあるのが同一人物の顔画像だけであるのかを確認しやすい。
　ファイル名には、必ずしも人物名を含める必要はない。ただ、一連の画像の中でユニークなファイル名になるのがよいと考えている。
　ツールでの扱いやすさのためには、半角スペースやファイルシステムやシェルで特別な意味をもつような文字を含めないようにする。

ファイル名に対象の人物名を含むファイル名にしない理由

biden/biden01.jpg などとしない理由。
顔データセットを作る途中では、切り出し元の静止画・動画に関連付けて切り出し画像を管理したい。そうすれば、訓練用の画像と検証用の画像に、同じ動画から切り出していないかが確認できる。対象の人物名はフォルダにだけ含めていれば、フォルダ名こそが対象の人物名であることが明確になる。

整備中の顔画像のラベル名（＝フォルダ名）は一貫性のある名称を付ける。

"Joe_Biden", "J.Biden", "Biden"などのフォルダを混在させない。
整備中の顔画像のラベル名（＝フォルダ名）は"person000"などといった無機的なものにしない。間違った分類がされていても気づきにくくなるからだ。

ディレクトリ構造を標準化する利点

ツールを作る際の想定するディレクトリ構造・フォルダ・ファイルの命名規則が一貫性を想定できる。
そのため、顔につけたラベルが、フォルダ名、ファイル名、ファイル名に対応したテキストファイル、一覧のデータのcsvファイルの中などのどれにあるのかと悩まなくてすむ。常にフォルダ名に含めるというのが一貫していれば、とても扱いやすい。
さらに、異なる撮影データに対して、特定の人物に対するラベルの一貫性が保たれていれば、データセットをマージして使うのがとても簡単になる。
だから、顔画像のデータセットを作るときには、一貫性のある規則で標準化するのがよい。

似すぎている画像を減らす。

同一人物の同じ環境で同じ顔向きの画像は、当然ながら似ている。
そういった画像で顔照合を実施すれば、train とtestにほぼ同じ画像を含んでいるので、顔照合の成功率があがって当然だ。
似すぎている画像はwebで静止画を検出して画像を収集した際にも起こりがちだ。
類似度が所定の値以上の極端に似ている画像を取り除くツールを作成しよう。
- スクリプト例: https://github.com/waragai-katsunori/cv_dnn_face/blob/main/move_similar_faces.py

アノテーションを実施するのかどうか

今回のデータセットを作る理由を思い出そう。
しなくてもすむアノテーションはしないこと。

昔の顔データセットの場合

顔の検出枠の正解データ
両目の位置
顔ランドマークの位置（両目の位置・鼻の位置・口の両端の位置など）
こういったものがテキストファイルに記載してあることが多かった。

今の状況

顔自体の検出率が高くなっているので、顔検出枠について、そこまで評価で気にする必要が無くなってきている。
- 横向きの顔画像での顔の正解枠について、だれもが合意するような枠は存在しない。
- 深層学習の枠は、もはや正方形ではない。
- 顔の検出枠の評価をしようとするのでないかぎり、正解枠をアノテーションする必要性がない。
両目の中心位置
- 深層学習の顔検出ライブラリでは、顔ランドマークの位置を求めるものが増えていて、しかもその位置の精度が上がっているライブラリがある。
- 両目の中心位置を手入力する意味がない。
顔向きによる画像の分類は、労力が多すぎる。
- 顔の向きを条件をそろえて撮影することは、労力が多すぎる。
- 良いライブラリだと、顔の向きのyaw, pitch, roll が算出される。
- その値をまずは信用して十分なこともある。

作成した顔照合データセットは、社内・部署内で共有化する。

ディスクが死ぬ、PCが壊れるのはよくあることです。
肖像権の懸念が残るので、画像を公表は避ける。
あなたがかかわらなくても、社内でそのデータが活用されることが大事。
あなたは、いずれその部署を離れる。
社内・部署内で共有する際には、そのデータの制限事項に留意すること。

顔照合のライブラリは継続的に改良が進んでいます。

顔照合のライブラリを実装するターゲットが進化しています。
- CPU：マルチコアを最大限に利用するライブラリを用いた実装
- GPU：tensorflowなどCudaを利用するライブラリの他にも、TensorRTを用いたライブラリも出ています。
- Intel Movidius Neural Compute Stickを使った実装
- FPGAを使った実装
  こういったライブラリの実装の進化により、演算速度、消費電力当たりの演算速度などが従来よりも向上してきています。
顔照合ライブラリのマスク顔対応が進んだ
- 新型コロナウイルス感染症(COVID‑19)の流行以降、顔照合ライブラリでのマスク顔対応が進展しました。
- マスク顔を顔検出できる、マスクをしているかどうかを判定できる、マスクをしていてもだれか判定できる。
- その性能は、それぞれの実装のモデルに強く依存しています。
- 複数のライブラリを比較するには、実際に共通のデータセットで評価するのがいいでしょう。

顔照合ライブラリは、数年ごとに見直しを迫られることになる。

OSのLTS(Long Time Service)の終了
使用している言語のそのバージョンの終了
顔照合ライブラリとともに使用している各種ライブラリのバージョンの変更

参考

非商用目的なら利用できる顔データセット

企業で利用できる商用顔データセット

例：
https://www.datatang.co.jp/#solution