face_recognition: dlib in drei Zeilen Python verpackt

Was face_recognition 1.2.2 eigentlich kapselt

face_recognition nennt sich die einfachste Gesichtserkennungsschnittstelle für Python und die Befehlszeile. Das Repository ist in Python geschrieben, lizenziert unter MIT, der Standardzweig heißt master, und eine eigene Projektseite ist nicht angegeben. Die letzte erfasste Änderung am Repository datiert vom 2. April 2018, und die letzte Ausgabe trägt die Bezeichnung v1.2.2 vom selben Tag. Die vorletzte erfasste Ausgabe v0.1.12 stammt vom 13. April 2017.

Technisch steht das Paket auf dlib. Laut README nutzt es dessen Gesichtserkennung, die auf tiefen neuronalen Netzen beruht, und erreicht auf dem Maßstab Labeled Faces in the Wild eine Trefferquote von 99,38 Prozent. Diese Zahl ist eine Angabe des README mit Verweis auf die LFW-Veröffentlichung, keine eigene Messung, und sie beschreibt die Modellgüte auf genau diesem Datensatz.

Der eigentliche Nutzen liegt weniger im Modell als in der Verpackung. Statt eine Kette aus Erkennung, Ausrichtung, Kodierung und Vergleich selbst zusammenzusetzen, genügen wenige Zeilen. Das erklärt, warum das Paket auch Jahre nach der letzten Ausgabe noch in vielen Projekten auftaucht.

Installation: dlib zuerst, dann pip3 install face_recognition

Die Installation hat eine Reihenfolge, und die ist nicht verhandelbar. Zuerst muss dlib samt Python-Bindungen installiert sein; das README verweist dafür auf eine eigene Anleitung für macOS und Ubuntu. Danach wird cmake benötigt, unter macOS über brew install cmake. Erst am Ende folgt pip3 install face_recognition, für Python 2 entsprechend pip2.

Als Voraussetzung nennt das README Python 3.3 oder neuer beziehungsweise Python 2.7 sowie macOS oder Linux. Windows wird ausdrücklich nicht unterstützt, und das README verweist auf eine von Nutzern beigesteuerte Anleitung in Ausgabe 175 des Repositories. Wer unter FreeBSD arbeitet, kann pkg install graphics/py-face_recognition verwenden.

Für Sonderhardware gibt es eigene Wege: eine Anleitung für Raspberry Pi 2 und neuer, eine für das Nvidia Jetson Nano und ein vorkonfiguriertes VM-Abbild. Wer die lokale Einrichtung scheut, findet alle drei im README verlinkt. Eine Paketquelle, die dlib und face_recognition gemeinsam auflöst, wird dort nicht genannt.

Drei Operationen: face_locations, face_landmarks, face_encodings

Drei Operationen tragen den größten Teil der Arbeit. face_locations() findet alle Gesichter in einem Bild und liefert Pixelkoordinaten. face_landmarks() gibt Umrisse für Augen, Nase, Mund und Kinn zurück. face_encodings() erzeugt aus einem Gesicht eine numerische Kodierung, und compare_faces() stellt zwei solcher Kodierungen gegenüber.

Der Ablauf aus dem README ist kurz. Zwei Bilder werden mit load_image_file() geladen, aus beiden wird die erste Kodierung gezogen, und der Vergleich läuft über compare_faces([biden_encoding], unknown_encoding). Diese drei Zeilen sind der Grund für die weite Verbreitung des Pakets, nicht das Modell dahinter.

Für die Gesichtspunkte nennt das README ein Anwendungsbeispiel, das die Ernsthaftigkeit der Sache sofort unterläuft: digital_makeup.py legt digitales Make-up über ein Foto. Für Kameraeingaben existiert facerec_from_webcam_faster.py. Eine vollständige Beschreibung der Schnittstelle liegt unter face-recognition.readthedocs.io.

Die zwei Befehle face_recognition und face_detection

Mit der Installation kommen zwei Befehle auf das System. face_recognition erwartet einen Ordner mit bekannten Personen, in dem jede Datei nach der abgebildeten Person benannt ist und ein Bild je Person enthält, sowie einen zweiten Ordner oder ein einzelnes Bild mit Unbekannten. Die Ausgabe besteht aus einer Zeile je gefundenem Gesicht, durch Komma getrennt aus Dateiname und Name, oder aus unknown_person, wenn nichts passte.

face_detection ist das einfachere Werkzeug. Es nimmt einen Ordner oder ein Bild und gibt je erkanntem Gesicht eine Zeile mit vier Zahlen aus, den Koordinaten für oben, rechts, unten und links in Pixeln. Damit lässt sich ein Bestand ohne Namenszuordnung durchsuchen, etwa um zu zählen, wie viele Aufnahmen überhaupt Gesichter enthalten.

Die Namensgebung über Dateinamen ist bequem und gleichzeitig eine Fehlerquelle. Ein Tippfehler im Dateinamen erzeugt falsche Zuordnungen ohne jeden Hinweis. Das README verlangt ein Bild je Person, sagt aber nicht, wie sich der Befehl verhält, wenn in einer Vorlage mehrere Gesichter stehen.

--tolerance, --cpus und model="cnn" mit CUDA

Zwei Schalter steuern das Verhalten an der Befehlszeile. Mit --tolerance wird die Schwelle für einen Vergleich gesetzt. Das README empfiehlt einen niedrigeren Wert, wenn mehrere Personen einander ähnlich sehen und die Vergleiche strenger ausfallen sollen. Der Standardwert liegt laut Dokumentation bei 0,6. Mit --cpus lässt sich bei Python 3.4 oder neuer die Arbeit auf mehrere Kerne verteilen, was bei ganzen Bildordnern den Unterschied zwischen Minuten und Stunden macht.

In der Python-Schnittstelle entspricht dem die Wahl des Erkennungsmodells. Wer model="cnn" übergibt, nutzt ein faltendes Netz statt des Standardmodells, und das README weist ausdrücklich darauf hin, dass dieses Modell ohne CUDA-Unterstützung keine brauchbare Geschwindigkeit erreicht. Auf einem Rechner ohne passende Grafikkarte bleibt also das Standardmodell.

Für größere Bestände hält das Repository ein Beispiel für die Verarbeitung in Stapeln bereit. Wie sich die beiden Modelle in der Trefferquote unterscheiden, ist im README nicht beziffert. Die genannte Zahl von 99,38 Prozent bezieht sich auf das Maßstabsergebnis insgesamt, nicht auf einen Vergleich der Modelle.

Benannte Grenzen: Kinder, ethnische Gruppen, Jetson Nano

Die Grenzen sind im README aufgeführt, und sie sind nicht klein. Das Modell ist auf Erwachsene trainiert und arbeitet bei Kindern deutlich schlechter. Die Trefferquote schwankt außerdem zwischen ethnischen Gruppen. Für beides verweist das Projekt auf eine eigene Wikiseite, statt Zahlen zu nennen. Wer Gesichtserkennung in einem Bereich einsetzt, in dem einer dieser Punkte ins Gewicht fällt, bekommt hier keine Unterlage für eine Entscheidung.

Hinzu kommt ein hardwarenaher Fallstrick. Auf dem Nvidia Jetson Nano führt laut README ein Fehler in den CUDA-Bibliotheken zu einem stillen Fehlschlag, wenn nicht eine Zeile in dlib auskommentiert und die Bibliothek neu übersetzt wird. Ein stiller Fehlschlag ist die unangenehmste Fehlerart, weil das Programm ohne Hinweis einfach nichts findet.

Zur Verteilung auf Servern liegt ein Dockerfile im Repository, ein lokaler Container entsteht mit docker-compose up --build. Für eine eigenständige ausführbare Datei wird PyInstaller genannt, verbunden mit dem Hinweis, dass dafür eine eigene Konfiguration nötig ist.

Seit April 2018 keine Ausgabe mehr und der Weg über dlib

Die augenfälligste Tatsache steht nicht im README, sondern in den Repository-Metadaten. Die letzte Änderung datiert vom 2. April 2018, die letzte Ausgabe ist v1.2.2 vom selben Tag, und eine neuere Fassung ist in dieser Quelle nicht verzeichnet. Für ein Paket, das von dlib abhängt, wiegt das schwer, weil sich darunter liegende Bibliotheken, Python-Versionen und Compiler weiterentwickeln, während hier nichts nachzieht. Wer heute installiert, baut eine Kette gegen eine acht Jahre alte Momentaufnahme.

Als Alternative bleibt der Weg nach unten, also dlib selbst. Es bietet dieselben Modelle und mehr, verlangt aber, die Kette aus Erkennung, Ausrichtung, Kodierung und Vergleich selbst zu schreiben und zu pflegen. Wer face_recognition einsetzt, tauscht genau diese Arbeit gegen Bequemlichkeit und gegen ein Paket ohne weitere Ausgaben.

Lizenziert ist face_recognition unter MIT. Das erlaubt Nutzung, Veränderung und Weitergabe bei erhaltenem Hinweis und schließt jede Gewährleistung aus. Welche Lizenz dlib selbst trägt, sagt das README nicht, und genau das gehört vor einer Weitergabe eigener Programme geklärt.

Redaktionelles Fazit

face_recognition passt zu allen, die einen Bildbestand einmalig durchsuchen oder in einem Prototyp Gesichter finden, Gesichtspunkte auslesen und bekannte Personen zuordnen wollen, und die dafür drei Zeilen Python statt einer eigenen Verarbeitungskette schreiben möchten. Weniger geeignet ist es für Produktionssysteme, denn seit April 2018 ist keine Ausgabe mehr erschienen, das Modell arbeitet bei Kindern schlechter und schwankt zwischen ethnischen Gruppen, und Windows bleibt ohne Unterstützung. Wer es einsetzt, sollte zuerst prüfen, ob dlib auf der Zielplattform sauber übersetzt, und danach die Trefferquote an einem eigenen Bildbestand nachmessen.

Offizielle Quellen

1. Official README
2. Project repository
3. Release notes