Apples Vision Framework: Was bereits eingebaut ist und wofür die meisten Entwickler Cloud-APIs nutzen
Apples Vision Framework, das ohne den Suffix „OS”, umfasst mehr als zwei Dutzend On-Device-Computer-Vision-Operationen. Die meisten iOS-Entwickler greifen standardmäßig auf OpenAI Vision API, Google Cloud Vision oder AWS Rekognition zurück – für Aufgaben, die das Framework in Mikrosekunden auf der Neural Engine des Geräts ausführt. Diese Standardwahl spiegelt eher eine Voreinstellung wider als eine bewusste Bewertung: Cloud-APIs wirken nach „moderner KI”, Vision dagegen nach „Plattform-Infrastruktur” – also wird die Plattform übergangen. Diese Voreinstellung verkennt jedoch, was die Plattform inzwischen enthält.
Vision ist das Local-First-CV-Framework. Es läuft auf der Neural Engine, sofern verfügbar, andernfalls auf der GPU und im äußersten Fall auf der CPU. Die Inferenz erfolgt für die meisten Operationen in wenigen Millisekunden. Das Framework verursacht keine Kosten pro Aufruf. Die Daten verlassen das Gerät nicht. Einen API-Schlüssel gibt es nicht, da kein API existiert. Für die meisten Computer-Vision-Aufgaben einer iOS-App ist dies das richtige Werkzeug.
TL;DR
- Apple Vision bietet mehr als zwei Dutzend On-Device-CV-Operationen: Texterkennung, Gesichtserkennung und Landmarken, Körper- und Handposenerkennung, Barcode-Lesen, Dokumentensegmentierung, Bild-Embeddings, Saliency, Tiererkennung, Konturen, Trajektorien, optischen Fluss sowie einen Runner für jedes beliebige Core ML-Modell.
- Jede Operation läuft in Millisekunden auf der Neural Engine, kostet nichts pro Aufruf, benötigt keine Netzwerkverbindung und erzeugt keine Drittanbieter-Telemetrie.
- Cloud-APIs gewinnen in einem spezifischen Fall: komplexes semantisches Schließen über ein Bild (ein multimodales LLM versteht ein Diagramm, ein Meme oder die Absicht eines Dokuments). Bei Operationen auf Pixelebene (Gesichter finden, Text lesen, eine Hand erkennen) gewinnt Vision in puncto Kosten, Latenz und Datenschutz.
- Die Verbindung zum Agenten-Workflow: Vision-Ergebnisse fließen in App Intents und Foundation Models On-Device-LLM-Aufrufe ein, ohne einen Netzwerk-Roundtrip. Die gesamte Pipeline läuft lokal.
Was Vision tatsächlich enthält
Vision gruppiert seine Operationen als VNRequest-Typen. Eine Anfrage wird erstellt, mit Parametern konfiguriert, mit einem Bild gespeist (oder CVPixelBuffer, oder CIImage, oder CGImage, oder URL) und ausgeführt. Die Ergebnisse kommen als Beobachtungen zurück, die der Anfrage angehängt sind. Die nachstehenden Kategorien decken den Funktionsumfang des Frameworks zum Stand iOS 26 ab.
Texterkennung
VNRecognizeTextRequest führt OCR durch. Die Anfrage unterstützt recognitionLevel (.fast für Live-Kamerastreams, .accurate für Dokumentenscans), Sprachhinweise, benutzerdefinierte Wortlisten und Bounding-Box-Konfidenz. Der genaue Pfad unter iOS 18+ steht kommerziellen OCR-APIs bei Quittungen, Schildern und gedruckten Dokumenten in nichts nach; Handschrifterkennung wird in vielen Sprachen unterstützt.
let request = VNRecognizeTextRequest { request, error in
guard let observations = request.results as? [VNRecognizedTextObservation] else { return }
let lines = observations.compactMap { $0.topCandidates(1).first?.string }
print(lines.joined(separator: "\n"))
}
request.recognitionLevel = .accurate
request.usesLanguageCorrection = true
request.recognitionLanguages = ["en-US"]
let handler = VNImageRequestHandler(cgImage: image, options: [:])
try handler.perform([request])
Dieselbe Operation über die OpenAI Vision API kostet etwa einen Bruchteil eines Cents pro Aufruf im Low-Detail-Modus und deutlich mehr im High-Detail-Modus, dauert 1–3 Sekunden Roundtrip und sendet das Bild an die Server von OpenAI. Vision liefert die Ergebnisse lokal in 100–300 ms, kostenlos und ohne Datenabfluss.
Gesichtserkennung und Landmarken
Drei Ebenen der Gesichtsanalyse sind in Vision enthalten:
VNDetectFaceRectanglesRequestliefert Bounding Boxes für jedes Gesicht im Frame.VNDetectFaceLandmarksRequestliefert pro Gesicht strukturierte Landmarkenregionen (Kieferlinie, Mund, Augen, Augenbrauen, Nase, Pupillen), jeweils mit mehreren Schlüsselpunkten.VNDetectFaceCaptureQualityRequestliefert einen Qualitätswert, den die Kamera-App für das Timing der Selfie-Aufnahme verwendet.
Für die meisten Apps, die Gesichter finden, auf Gesichter zuschneiden, Gesichter weichzeichnen oder Gesichter zählen müssen, ist die Rectangles-Anfrage das richtige Werkzeug. Für Apps, die etwas am Gesicht eines Benutzers animieren (Filter, Masken, Tracking), sind Landmarken plus Pupillenverfolgung das richtige Werkzeug. Nichts davon erfordert eine Modelldatei oder einen Netzwerkaufruf.
Körper- und Handpose
VNDetectHumanBodyPoseRequest liefert die 19 benannten Gelenke in VNHumanBodyPoseObservation.JointName4 (Nase, Hals, Schultern, Ellbogen, Handgelenke, Hüften, Knie, Fußgelenke, Ohren, Augen, Wurzel) mit 2D-Koordinaten und Konfidenz pro Gelenk. VNDetectHumanBodyPose3DRequest erweitert die Topologie auf Geräten mit LiDAR-Scanner in den 3D-Raum. VNDetectHumanHandPoseRequest liefert 21 Hand-Landmarken in Auflösung der Fingergelenke.
Körperpose ist das, was Fitness-Apps verwenden, um Wiederholungen ohne Wearable zu zählen, was AR-Apps verwenden, um virtuelle Inhalte an die Hände eines Benutzers zu heften, und was Haltungs-Apps verwenden, um die Form zu bewerten. Handpose treibt die Gestenerkennung an (der Benutzer zeigt zwei Finger, die App sieht zwei Finger). Beide laufen mit 60 fps auf einer aktuellen iPhone Neural Engine. Die Cloud-Äquivalente sind Google MediaPipe oder proprietäre Fitness-Tech-APIs, die das Framework ersetzt.
Barcode und QR
VNDetectBarcodesRequest liest die Symbologien, die die meisten Einzelhandels- und Inventar-Workflows benötigen (QR, PDF417, Aztec, Code 128, Code 39, EAN-13, ITF14, Data Matrix, GS1 DataBar und mehr) und liefert die Rohdaten zusammen mit dem Bounding-Rechteck. Die Erkennung läuft in Millisekunden und funktioniert auch unter den Lichtverhältnissen, die Apples eigene Kamera-App bereits validiert hat.
Dokumentensegmentierung
VNDetectDocumentSegmentationRequest findet rechteckige Dokumente in einem Frame und liefert deren Eckpunkte unter Berücksichtigung der Perspektive. Diese Anfrage verwenden Dokumentenscanner-Apps, um das Dokument zu beschneiden und in ein flaches Bild zu rektifizieren. Apples eigenes VisionKit-Framework verpackt die Anfrage zusammen mit einer UI, doch die zugrunde liegende Operation ist direkt aufrufbar, wenn eine App eine eigene UI benötigt.
Saliency und Ästhetik
VNGenerateAttentionBasedSaliencyImageRequest liefert eine Heatmap, wo sich die Aufmerksamkeit eines Betrachters in einem Bild voraussichtlich konzentriert. VNGenerateObjectnessBasedSaliencyImageRequest liefert eine Heatmap, wo sich Objekte befinden. VNCalculateImageAestheticsScoresRequest, in iOS 18 als öffentliche API hinzugefügt1, liefert ästhetische Qualitätswerte einschließlich einer Nutzwertklassifizierung (Memos, Screenshots) und eines ästhetischen Wertes. Diese Werte verwendet Photos, um Kandidaten für „Erinnerungen” hervorzubringen, und sie fließen in Auto-Crop-Entscheidungen ein.
Bildklassifikation und Embeddings
VNClassifyImageRequest liefert mit einem eingebauten Klassifizierer (über 1.000 Kategorien aus einem Modell, das auf Web-Scale-Daten trainiert wurde) die Top-N-Kategorienlabels für ein Bild. VNGenerateImageFeaturePrintRequest liefert einen Merkmalsvektor (das Embedding des Modells), der sich für die Bildähnlichkeitssuche eignet.
Embeddings sind die Grundlage dafür, wie eine Photos-App, die „Ähnliche Gerichte finden”-Funktion einer Rezept-App oder die Deduplizierung-nach-Ähnlichkeit einer Moodboard-App tatsächlich funktioniert. Das Cloud-Äquivalent sind OpenAI CLIP-Embeddings oder Googles Vertex AI; Vision liefert sie lokal und kostenlos.
Objektverfolgung und Trajektorien
VNDetectTrajectoriesRequest verfolgt sich bewegende Objekte über Frames hinweg und liefert parabolische Trajektorienanpassungen (ein geworfener Ball, ein abgeschossener Pfeil). VNTrackObjectRequest folgt einem manuell begrenzten Objekt durch eine Videosequenz.
Trajektorien sind das zugrunde liegende Primitiv für Sport-Apps (Tracking eines Baseballs, Basketballs, Tennisballs). Die Erkennung funktioniert auf einem Live-AVFoundation-Stream und liefert Ergebnisse in Echtzeit.
Eigene Modelle via VNCoreMLRequest
VNCoreMLRequest führt jedes beliebige Core ML-Modell durch die Vision-Pipeline aus. Die Anfrage übernimmt automatisch das Preprocessing (Bildgrößenanpassung, Farbraumkonvertierung, Normalisierung) basierend auf der Eingabebeschreibung des Modells. Eine App trainiert in Create ML einen eigenen Klassifizierer (eine Handvoll Kategorien, hundert Beispielbilder pro Kategorie, zehn Minuten Training) oder lädt ein veröffentlichtes Modell herunter, legt das .mlpackage ins App-Bundle und führt es mit drei Zeilen Code durch Vision aus.
let model = try VNCoreMLModel(for: MyClassifier(configuration: .init()).model)
let request = VNCoreMLRequest(model: model) { request, error in
let results = request.results as? [VNClassificationObservation]
print(results?.first?.identifier, results?.first?.confidence)
}
let handler = VNImageRequestHandler(cgImage: image, options: [:])
try handler.perform([request])
Das Cloud-Äquivalent für einen eigenen Klassifizierer besteht darin, das Modell auf einem Server zu hosten, für Inferenz-Compute zu zahlen, die API zu verwalten und die Netzwerklatenz hinzunehmen. Vision macht daraus ein .mlpackage im App-Bundle und einen Request-Handler.
Wo Cloud-APIs tatsächlich gewinnen
Visions Territorium sind Operationen auf Pixelebene: dieses Ding finden, dieses Bild klassifizieren, diesen Text erkennen. Das Framework liefert kein komplexes semantisches Schließen über die Bedeutung eines Bildes. Drei Fälle, in denen Cloud-APIs die richtige Wahl sind:
Multimodales LLM-Verstehen. „Was tut diese Person auf diesem Bild?” „Ist dieses Diagramm irreführend?” „Übersetzen Sie diese Speisekarte und sagen Sie mir, welche Gerichte vegetarisch sind.” Keine dieser Fragen ist eine Frage auf Pixelebene. Sie erfordern ein großes multimodales Modell, das visuelle Wahrnehmung mit Weltwissen und Sprache verbindet. Apples Foundation Models (das On-Device-LLM, behandelt in Foundation Models On-Device LLM) beginnt, einen Teil davon On-Device zu erledigen, doch für komplexes Schließen gewinnen weiterhin GPT-4o, Claude Sonnet oder Gemini.
Einmalige, individuelle Aufgaben ohne Trainingsdaten. Visions Klassifikationsmodell ist fest; eigene Core ML-Modelle erfordern Trainingsdaten. Ein multimodales LLM kann „Ist das ein Foto einer Katze mit Fliege?” beantworten, ohne ein einziges gelabeltes Trainingsbeispiel gesehen zu haben. Für Prototyping oder einmalige Aufgaben, bei denen das Sammeln von Trainingsdaten zu teuer wäre, sind Cloud-LLMs das richtige Werkzeug.
Document Intelligence jenseits von OCR. Visions OCR liefert Text. Eine Document-Intelligence-API (AWS Textract, Google Document AI, Azure Form Recognizer) liefert strukturierte Felder: Rechnungsnummer, Datum, Posten, Summen. Der Mehrwert liegt in der Strukturierung, nicht in der OCR. Für hochwertige Dokumenten-Workflows sind die Cloud-APIs in der Regel richtig; für „Lies diese Quittung und gib den Text aus” ist Vision richtig.
Das Muster: Cloud gewinnt beim Schließen und bei stark spezialisierten vertikalen APIs; Vision gewinnt bei Wahrnehmungsprimitiven.
Ehrlicher Vergleich von Latenz und Kosten
Eine repräsentative Inferenz-Pipeline, ausgeführt auf einem iPhone 16 Pro (A18 Pro Chip):
| Operation | Vision (on-device) | OpenAI Vision API | AWS Rekognition |
|---|---|---|---|
| OCR (1 Seite Quittung) | 150–300 ms | 1–3 s Roundtrip + Kosten pro Bild | 200–500 ms + Kosten pro Bild |
| Gesichtserkennung (1 Frame) | 5–15 ms | 1–2 s + Kosten | 100–300 ms + Kosten |
| Körperpose (live, 60 fps) | <16 ms | nicht echtzeitfähig | nicht echtzeitfähig |
| Bild-Embedding | 20–40 ms | 200–500 ms + Kosten | nicht direkt verfügbar |
| Eigener Klassifizierer | abhängig von der Modellgröße | erfordert gehostetes Modell | erfordert gehostetes Modell |
Die obigen Zahlen leiten sich aus öffentlichen Apple-Benchmarks und entwicklerseitig berichteten Messungen ab; die Aussage betrifft die Größenordnung, nicht den exakten Wert. Visions Vorteile liegen in den Kosten (null pro Aufruf), in der Tail-Latenz (kein Netzwerk-Jitter) und im Datenschutz (Daten verlassen das Gerät nicht).
Die Kosten summieren sich, wenn eine App häufig Vision-Operationen aufruft. Eine Foto-Bearbeitungs-App, die 100 Bilder pro Sitzung verarbeitet, kostet über Cloud-APIs in der Größenordnung mehrerer Dollar pro Sitzung – und über Vision null.
Die Verbindung zum Agenten-Workflow
Vision passt sauber zu zwei bereits ausgelieferten Cluster-Ideen:
App Intents-Tools für Apple Intelligence. Wenn die App eine Funktion wie „Gesichter in meinen Fotos finden” oder „Text aus Screenshot lesen” über ein AppIntent bereitstellt, führt die perform-Methode des Intents Vision lokal aus und liefert ein strukturiertes Ergebnis zurück. Der Orchestrator von Apple Intelligence kann den Intent aufrufen, ohne das Foto des Benutzers an einen Server zu senden. Der Beitrag zu App Intents erläutert den Surface-Vertrag.
Foundation Models On-Device LLM. Eine Pipeline, die sowohl Wahrnehmung als auch Schließen benötigt, führt zuerst Vision aus (Text extrahieren, Gesichter finden, Objekte lokalisieren) und anschließend Foundation Models (über das Gefundene schließen, eine Zusammenfassung erzeugen). Beide Stufen laufen On-Device. Netzwerkaufrufe insgesamt: null. Der Beitrag zu Foundation Models erklärt, wie das LLM aufgerufen wird; dieser Beitrag argumentiert, dass Vision das ist, was es ohne Cloud-Roundtrip speist.
let textRequest = VNRecognizeTextRequest()
textRequest.recognitionLevel = .accurate
let handler = VNImageRequestHandler(cgImage: receiptImage, options: [:])
try handler.perform([textRequest])
let extractedText = (textRequest.results ?? [])
.compactMap { ($0 as? VNRecognizedTextObservation)?.topCandidates(1).first?.string }
.joined(separator: "\n")
let llmResponse = await foundationModel.generate(
"Summarize this receipt as JSON with merchant, total, and date fields:\n\(extractedText)"
)
Die gesamte Pipeline läuft auf dem Gerät. Kein API-Schlüssel. Kein Netzwerkaufruf. Keine Drittanbieter-Datenexposition.
Was sich in den letzten beiden Releases weiterentwickelt hat
Drei nennenswerte Ergänzungen, konservativ datiert anhand von Apples Release Notes2:
Aesthetics Scoring als öffentliche API (iOS 18). VNCalculateImageAestheticsScoresRequest liefert Werte einschließlich Nutzwertklassifizierung und ästhetischem Wert und ersetzt das, was Foto-Kuratierungs-Apps zuvor mit eigenen Core ML-Modellen näherungsweise abbilden mussten.
Verbesserte mehrsprachige OCR. VNRecognizeTextRequest hat in den jüngsten Releases die Unterstützung für nicht-lateinische Schriften ausgebaut und damit den Abstand zu Cloud-OCR-Diensten verringert, die historisch eine stärkere mehrsprachige Abdeckung hatten. Apples Dokumentation zur Texterkennung listet die aktuell unterstützten Sprachen auf3.
Dokumentensegmentierung mit VisionKit-Integration. VNDetectDocumentSegmentationRequest findet rechteckige Dokumente und liefert Eckpunkte; VisionKits DataScannerViewController verpackt die Anfrage mit einer gestalteten UI für das Live-Dokumentenscannen.
Die Kernfähigkeiten des Frameworks (Gesicht, Text, Pose, Barcode, Embeddings) sind seit mehreren iOS-Releases ausgereift. Das Muster: erweitern statt neu erfinden.
Warum die meisten Entwickler Vision übergehen
Drei Gründe, warum das Framework trotz klarer Argumente übergangen wird:
Cloud-First-Gewohnheit. Der Großteil moderner KI-Entwicklung erfolgt zuerst gegen Cloud-APIs. Entwickler wissen, wie man OpenAI aufruft; die Oberfläche aus VNRecognizeTextRequest plus VNImageRequestHandler plus VNRecognizedTextObservation wirkt nach mehr API zum Lernen für etwas, das in der Praxis weniger Codezeilen ergibt.
Falsche Einschätzung der Fähigkeiten. Entwickler, die das Framework länger nicht geprüft haben, gehen davon aus, dass es nur OCR und Barcodes abdeckt. Die obige Kategorienliste umfasst über ein Dutzend Fähigkeiten, von denen mehrere kein cloud-natives Pendant haben und mehrere kommerziellen APIs ohne deren Kosten ebenbürtig sind.
Divergenz zwischen Prototyp und Produktion. Cloud-APIs gewinnen im frühen Prototyping (ein curl-Befehl bringt das Ergebnis), und der Prototyp wird ohne erneute Bewertung in die Produktionspipeline überführt. Der richtige Schritt ist, mit dem schnellsten Werkzeug zu prototypisieren und die Wahrnehmungsschicht neu zu bewerten, sobald der Workflow real ist.
Die Lösung besteht nicht darin, Cloud-APIs abzulehnen; die Lösung besteht darin, zu wissen, was die Plattform enthält, damit die Wahl eine echte Wahl ist.
Was dieses Muster für iOS 26+ Apps bedeutet
Drei Erkenntnisse.
-
Standardmäßig Vision für Wahrnehmungsprimitive. Gesichter finden, Text lesen, Barcodes erkennen, Posenerkennung durchführen, Bild-Embeddings erzeugen. Das Framework läuft in Mikrosekunden auf der Neural Engine, kostet nichts und hinterlässt keine Drittanbieter-Datenspur. Für CV-Operationen auf Pixelebene ist das Framework der richtige Ausgangspunkt.
-
Cloud-APIs für das Schließen verwenden, nicht für die Wahrnehmung. Ein multimodales LLM, das die Bedeutung eines Bildes versteht; eine vertikale Document-Intelligence-API, die strukturierte Felder extrahiert; eine einmalige, individuelle Aufgabe ohne Trainingsdaten. Das ist Cloud-Territorium; sie der Cloud zu überlassen, ist korrekt.
-
Vision mit Foundation Models für vollständig On-Device-Pipelines koppeln. Wahrnehmung (Vision) speist das Schließen (On-Device-LLM). Die Pipeline läuft Ende-zu-Ende lokal, ohne API-Schlüssel, ohne Netzwerk-Jitter und ohne Telemetrie, die das Gerät verlässt. Der Foundation-Models-Beitrag des Clusters behandelt die LLM-Hälfte; Vision ist die Eingabehälfte.
Der vollständige Apple-Ecosystem-Cluster: typisierte App Intents; MCP-Server; die Routing-Frage; Foundation Models; die Unterscheidung zwischen Runtime und Tooling-LLM; drei Oberflächen; das Single-Source-of-Truth-Muster; Zwei MCP-Server; Hooks für die Apple-Entwicklung; Live Activities; die watchOS-Runtime; SwiftUI-Internals; RealityKits räumliches mentales Modell; SwiftData-Schema-Disziplin; Liquid-Glass-Muster; Multi-Plattform-Auslieferung; die Plattform-Matrix; worüber ich nicht schreibe. Die Hub-Seite ist die Apple Ecosystem Series. Den breiteren Kontext für iOS mit KI-Agenten finden Sie im iOS Agent Development Guide.
FAQ
Was ist der Unterschied zwischen Apple Vision und visionOS?
Das Vision Framework ist die On-Device-Computer-Vision-API für iOS, macOS und visionOS. visionOS ist das Betriebssystem für Apple Vision Pro. Die Namensüberschneidung ist unglücklich. Vision (das Framework) läuft auf jedem modernen Apple-Gerät; visionOS (das OS) läuft ausschließlich auf der Vision-Pro-Hardware.
Wann sollte ich Vision anstelle der OpenAI Vision API oder Google Cloud Vision verwenden?
Für Wahrnehmungsaufgaben auf Pixelebene (Gesichter finden, Text lesen, Objekte erkennen, Elemente zählen, Pose schätzen, Bild-Embeddings erzeugen) ist Vision fast immer die richtige Wahl. Es läuft in Millisekunden, kostet pro Inferenz nichts und behält die Benutzerdaten auf dem Gerät. Cloud-APIs sind richtig, wenn die Aufgabe komplexes semantisches Schließen über die Bedeutung eines Bildes erfordert oder wenn eine vertikale Document-Intelligence-API strukturierte Felder über die reine Textextraktion hinaus liefert.
Kann ich mein eigenes Core ML-Modell durch Vision ausführen?
Ja. VNCoreMLRequest umschließt jedes beliebige Core ML-Modell und übernimmt das Preprocessing automatisch. Legen Sie die .mlpackage-Datei ins App-Bundle, instanziieren Sie das Modell, kapseln Sie es in einem VNCoreMLModel und führen Sie es über einen Request-Handler aus. Derselbe Handler kann mehrere Anfragen parallel ausführen, einschließlich der eingebauten Vision-Anfragen und des eigenen Core ML-Modells.
Wie funktioniert das Dispatching von Vision auf Apple Silicon?
Vision (und die Core ML-Modelle, die es ausführt) wird automatisch auf die Neural Engine verteilt, sofern verfügbar, fällt andernfalls auf die GPU und im äußersten Fall auf die CPU zurück. Das Framework wählt den schnellsten Pfad für das Gerät und die Operation. Bei den meisten modernen iPhones (A12 Bionic und neuer) übernimmt die Neural Engine den Großteil der Inferenz; der Entwickler konfiguriert das Dispatching nicht manuell.
Was wurde kürzlich hinzugefügt?
Die konservative Zusammenfassung, datiert anhand von Apples Release Notes: VNCalculateImageAestheticsScoresRequest wurde in iOS 18 als öffentliche API hinzugefügt; VNRecognizeTextRequest hat die mehrsprachige Unterstützung in jüngsten Releases ausgebaut; VisionKits DataScannerViewController verpackt das Dokumentenscannen in einer gestalteten UI. Die Kernfähigkeiten (Text, Gesicht, Pose, Barcodes, Embeddings) sind seit mehreren iOS-Releases ausgereift.
Quellen
-
Apple Developer Documentation:
VNCalculateImageAestheticsScoresRequest, eingeführt in iOS 18.0+. ↩ -
Apple Developer Documentation: Vision framework, Referenz für verfügbare Anfragen und Plattformverfügbarkeit. ↩
-
Apple Developer Documentation: Recognizing Text in Images, unterstützte Erkennungssprachen pro API-Aufruf. ↩
-
Apple Developer Documentation:
VNHumanBodyPoseObservation.JointName, aufgezählte Gelenknamen, die von 2D-Körperposenanfragen zurückgegeben werden. ↩