InstantHMR zielt auf 3D-Körperrekonstruktion direkt auf dem Smartphone

Was das Modell aus einem Bild berechnet

Human Mesh Recovery bezeichnet allgemein Verfahren, die aus Bilddaten Körperpose und Körperform schätzen und daraus ein dreidimensionales Körpermodell ableiten. Ein solches Netz liefert damit eine umfangreichere Repräsentation als eine reine Liste zweidimensionaler Gelenkpunkte. [4]

InstantHMR verwendet das parametrisierte Momentum Human Rig (MHR). Die veröffentlichten Modellbeschreibungen nennen als Ausgaben unter anderem 204 MHR-Pose- und Skelettparameter, 45 Formparameter, eine Kameratranslation und 70 zweidimensionale Schlüsselpunkte. Ein zusätzliches MHR-Modell kann daraus 3D-Schlüsselpunkte und ein vollständiges Netz erzeugen. [2] [3]

Die dokumentierte Geometrie ist zunächst an das Kamerakoordinatensystem gebunden. Das Repository weist Positionen in Metern aus und bietet eine Option für die Brennweite an, wenn die Position im Raum genauer bestimmt werden soll. Die verfügbaren Angaben beschreiben daher keine eigenständige, über mehrere Kameras oder eine Szene hinweg verankerte Weltrekonstruktion. [2]

Bei der Mesh-Größe nennen die Quellen unterschiedliche Werte: Das Abstract auf der Paper-Seite spricht von 6.890 Eckpunkten, während Repository und Model Card für die MHR-Ausgabe 18.439 Eckpunkte dokumentieren. Die bereitgestellten Unterlagen erläutern nicht, ob diese Differenz auf verschiedene Modellstufen, Ausgabedarstellungen oder Konfigurationen zurückgeht. [1] [2] [3]

Zusätzliche Pose-Anpassung in Version 1.1

Die am 8. November im Repository dokumentierte Version 1.1 ergänzt die Netzvorhersage um einen kinematischen Fit. Das Modell schätzt sowohl eine 3D-Pose als auch 2D-Schlüsselpunkte; ein Optimierungsschritt verschiebt die Pose so, dass die Projektion des Körpers besser zu diesen Bildpunkten passt. Laut Projektbeschreibung nutzt der Fit dabei die Konfidenzwerte der Schlüsselpunkte und enthält keine zusätzlich trainierten Parameter. [2] [3]

Bei der Variante mit einem Bildausschnitt pro Person sinkt der ausgewiesene PA-MPJPE-Wert des mittleren Modells auf EMDB-1 von 48,8 auf 45,2 Millimeter und auf 3DPW von 40,0 auf 39,4 Millimeter. Mit zwei Ausschnitten nennt das Repository 44,4 beziehungsweise 39,3 Millimeter. Die Messwerte bleiben Resultate der vom Projektteam beschriebenen Auswertung. [2]

Der Genauigkeitsgewinn fällt je nach Datensatz unterschiedlich aus und kostet zusätzliche Rechenzeit. Für das mittlere Modell steigen die Angaben auf dem Galaxy S23 von 5,49 Millisekunden ohne Fit auf 6,40 Millisekunden mit einem Ausschnitt und 10,22 Millisekunden mit zwei Ausschnitten. Unternehmen müssen deshalb Genauigkeitsbedarf und Latenz im jeweiligen Einsatz gegeneinander abwägen. [2]

Für Video und Kameras dokumentiert das Repository außerdem zwei zeitliche Filter. Nach Angaben des Projektteams wurden sie auf 3DPW und EgoHumans abgestimmt; sie sollen das Zittern reduzieren, ohne dabei stärker als eine halbe Bildperiode nachzulaufen. Das sind Herstellerangaben, keine unabhängigen Messwerte aus den bereitgestellten Quellen. [2]

Benchmarks: gute Werte, aber begrenzte Vergleichbarkeit

Für das mittlere Basismodell nennt das Projektteam einen PA-MPJPE von 40,0 Millimetern auf 3DPW und 48,8 Millimetern auf EMDB-1; für RICH weist das Abstract 41,7 Millimeter aus. Die Modellübersicht des Repositorys ergänzt kleinere Varianten: Nano erreicht dort 46,6 Millimeter auf 3DPW, Tiny 44,0 und Small 41,7. Bei dieser Metrik gilt laut Dokumentation ein niedrigerer Wert als besser. [1] [2]

Im Abstract heißt es, die Autoren hätten elf Verfahren unter einem einheitlichen Protokoll erneut ausgewertet, unter anderem mit übereinstimmenden Bildausschnitten und einer offiziellen Konvertierung zwischen MHR und SMPL. Das Team begründet den gemeinsamen Vergleich damit, dass unterschiedliche Bewertungsprotokolle die Fehlerwerte merklich verändern können. Die verfügbaren Quellen enthalten jedoch keine unabhängige Reproduktion dieser Ergebnisse; zudem ist der Volltext auf der verlinkten Paper-Seite nicht verfügbar. [1]

Die Zahlen sind daher als Selbstauskunft des Entwicklungsteams einzuordnen. Sie erlauben einen ersten Vergleich der veröffentlichten Varianten, belegen aber für sich genommen weder die Robustheit in realen Betriebsumgebungen noch eine Überlegenheit unter beliebigen Kameras, Beleuchtungen oder Nutzergruppen. Diese Einschränkung folgt daraus, dass die bereitgestellten Nachweise Benchmarks und Projektmaterialien, aber keine externe Evaluation enthalten. [1] [2] [3]

Die Modellzeit ist nicht die Pipelinezeit

Die niedrige NPU-Latenz darf nicht mit der Laufzeit einer vollständigen Anwendung gleichgesetzt werden. In der Demo erkennt zunächst ein separates RF-DETR-Modell Personen; InstantHMR verarbeitet danach die jeweiligen Personenausschnitte. Das Repository nennt für RF-DETR in mittlerer Größe rund 27 Millisekunden und weist diesen Schritt als langsamste Stufe der Demo aus. [2]

Auch die gemessene Laufzeit des InstantHMR-Schritts hängt von der Ausführung ab. Für eine RTX 4070 nennt das Repository im Demoablauf mit TensorRT 2,8 Millisekunden pro Person bei einem Fit-Ausschnitt und 3,3 Millisekunden bei zwei Ausschnitten. Diese Werte umfassen mehr Verarbeitung als die reine Modellgraph-Messung und sind deshalb nicht direkt mit den 0,98 Millisekunden des Basismodells gleichzusetzen. [2]

Für einen Unternehmenseinsatz zählt damit nicht nur die Wahl des HMR-Modells. Auch Detektorgröße, Anzahl der Personen, Bildrate und Häufigkeit der erneuten Detektion beeinflussen den Aufwand. Das Repository bietet etwa eine Einstellung, mit der der Detektor nur in bestimmten Bildabständen läuft; zwischenzeitlich kann die Personenbox anhand der 2D-Schlüsselpunkte weitergeführt werden. [2]

Technisch eröffnet die Ausführung auf einem Smartphone-NPU die Möglichkeit, die Inferenz lokal auf dem Gerät zu betreiben. Die veröffentlichten Materialien belegen jedoch weder einen vollständigen Datenschutz- oder Sicherheitsnachweis noch Angaben zu Energieverbrauch, Wärmeentwicklung oder dauerhaft erreichbarer Bildrate. Für eine Beschaffungsentscheidung müssen Sie diese Größen deshalb separat unter Ihrer eigenen Hardware- und Lastkonfiguration prüfen. [2] [3]

Lizenzbedingungen unterscheiden sich nach Modellvariante

Die Lizenzfrage ist für kommerzielle Anwendungen besonders relevant. Das Code-Repository führt den Programmcode grundsätzlich unter Apache 2.0, nimmt davon aber bestimmte aus SAM 3D Body abgeleitete Trainingsbestandteile aus. Modellgewichte und das gemeinsame MHR-Modell werden laut Repository unter der SAM-Lizenz bereitgestellt. [2]

Zusätzlich zu den Bedingungen der SAM-Lizenz stuft das Team die Gewichte Nano, Tiny, Small und Medium als nicht-kommerziell ein. Als Grund nennt es Bildquellen in den Trainingsdaten, deren Nutzungsrechte nach Darstellung der Entwickler auf Forschung oder nicht-kommerzielle Verwendung beschränkt sind. Die Variante Medium-commercial wurde laut Model Card mit Bildern trainiert, die das Team als kommerziell nutzbar einordnet; für sie entfällt diese zusätzliche Einschränkung. [2] [3]

Medium-commercial ist damit nicht mit einer uneingeschränkten Apache-Lizenz gleichzusetzen: Für die Modellartefakte gilt weiterhin die SAM-Lizenz, deren Bedingungen laut Quellen unter anderem Handelskontrollen und einen Ausschluss militärischer Nutzung umfassen. Unternehmen sollten deshalb Modellgewichte, Code und abgeleitete Komponenten getrennt prüfen und die für ihren konkreten Anwendungsfall geltenden Lizenzbedingungen juristisch bewerten lassen. [2] [3]

Der Lizenzkompromiss zeigt sich auch in den ausgewiesenen Genauigkeitswerten. Für Medium-commercial nennt die Modellübersicht ohne Fit 72,2 Millimeter auf EMDB-1 und 50,7 Millimeter auf 3DPW; die Standardvariante Medium liegt dort bei 48,8 beziehungsweise 40,0 Millimetern. Die Zahlen stammen aus den Projektbenchmarks und machen die kommerziell nutzbare Datenbasis nicht zu einem leistungsgleichen Ersatz. [2] [3]

Verfügbarkeit und Grenzen der Einordnung

Code, Demo, ONNX-Modelle und Trainingsmaterialien sind über die vom Team verlinkten Projekt-Repositories beschrieben; für den ersten Einsatz lädt die Demo benötigte Gewichte aus dem Model-Repository. Die Model Card nennt Unterstützung über ONNX Runtime für CPU, CUDA und TensorRT sowie die Ausführung auf Smartphone-NPUs. Zugleich vermerkt sie, dass InstantHMR dort nicht über einen Inference Provider als gehosteter Dienst bereitgestellt wird. [2] [3]

Die Paper-Seite auf Hugging Face enthält ein Abstract und verweist auf den arXiv-Beitrag, meldet aber, dass der Paper-Inhalt nicht verfügbar ist. Das GitHub-Repository nennt als zitierbare Veröffentlichung einen HAL-Preprint. Die hier verfügbaren Leistungs- und Funktionsdetails stammen daher wesentlich aus den Projektunterlagen selbst. [1] [2]

Für Anwendungen in Robotik, Biomechanik oder AR/VR kann eine schnelle, lokale Schätzung von Pose und Körperform eine nützliche technische Komponente sein. Aus den Quellen lässt sich aber nicht ableiten, dass InstantHMR bereits die Anforderungen an Weltkoordinaten, mehrkamerabasierte Rekonstruktion, dauerhafte Videoanalyse oder branchenspezifische Validierung erfüllt. Für Unternehmen ist das Modell deshalb zunächst als spezialisierter Baustein zu bewerten: Entscheidend sind der vollständige Datenpfad, die Lizenz der konkret eingesetzten Variante und Tests mit den eigenen Kameras und Szenen. [1] [2] [3]

Quellen

1. [1] Paper page - InstantHMR : Real-Time Human Mesh Recovery on Your Phone — https://huggingface.co/papers/2611.09195 (abgerufen am 2026-11-10)
2. [2] GitHub - Naturalpad-studio/InstantHMR · GitHub — https://github.com/Naturalpad-studio/InstantHMR (abgerufen am 2026-11-10)
3. [3] momolesang/InstantHMR · Hugging Face — https://huggingface.co/momolesang/InstantHMR (abgerufen am 2026-11-10)
4. [4] Human Mesh Recovery — https://akanazawa.github.io/hmr (abgerufen am 2026-11-10)