Treiberunterstützung für kameraausrichtung

Artikel
02/07/2024

Wichtig

Die weiter unten in diesem Thema beschriebene Methode zur automatischen Korrektur ist die empfohlene Lösung für die Ausrichtungsmontage von Kamerasensoren, die keine Referenz ist. Dies soll die App-Kompatibilität sicherstellen, da die Meisten der Anwendungen, die bereits für die Verwendung von Kamerafeeds geschrieben wurden, weder wissen, ob sie nach Drehungsinformationen suchen oder korrigieren. Bitte überprüfen Sie die Informationen im Abschnitt zur automatischen Korrektur unten sorgfältig.

Da unterschiedliche Formfaktoren eingeführt werden, führen einige der physischen Einschränkungen dazu, dass Kamerasensoren in einer nicht herkömmlichen Ausrichtung montiert werden. Aus diesem Grund ist es notwendig, dem Betriebssystem und der Anwendung ordnungsgemäß zu beschreiben, wie die Sensoren montiert werden, damit das resultierende Video ordnungsgemäß gerendert/aufgezeichnet werden kann.

Ab Windows 10, Version 1607, müssen alle Kameratreiber die Kameraausrichtung explizit angeben, unabhängig davon, ob die Kamera gemäß den Mindesthardwareanforderungen montiert ist. Insbesondere muss ein Kameratreiber ein neu eingeführtes Feld , Rotation, in der ACPI-_PLD-Struktur festlegen, die einer Erfassungsgeräteschnittstelle zugeordnet ist:

typedef struct _ACPI_PLD_V2_BUFFER {

    UINT32 Revision:7;
    UINT32 IgnoreColor:1;
    UINT32 Color:24;
    // …
    UINT32 Panel:3;         // Already supported by camera.
    // …
    UINT32 CardCageNumber:8;
    UINT32 Reference:1;
    UINT32 Rotation:4;      // 0 – Rotate by 0° clockwise
                            // 1 – Rotate by 45° clockwise (N/A to camera)
                            // 2 – Rotate by 90° clockwise
                            // 3 – Rotate by 135° clockwise (N/A to camera)
                            // 4 – Rotate by 180° clockwise
                            // 5 – Rotate by 225° clockwise (N/A to camera)
                            // 6 – Rotate by 270° clockwise
    UINT32 Order:5;
    UINT32 Reserved:4;

    //
    // _PLD v2 definition fields.
    //

    USHORT VerticalOffset;
    USHORT HorizontalOffset;
} ACPI_PLD_V2_BUFFER, *PACPI_PLD_V2_BUFFER;

Für Die Kamera gibt das Rotationsfeld in einer ACPI-_PLD-Struktur die Anzahl der Grad an ('0' für 0°, '2' für 90°, '4' für 180°, '6' für 270°), ein erfasster Frame wird relativ zum Bildschirm gedreht, während sich die Anzeige in seiner nativen Ausrichtung befindet.

Basierend auf dem Wert im Feld Drehung kann eine Anwendung bei Bedarf zusätzliche Drehungen durchführen, um erfasste Frames ordnungsgemäß zu rendern.

Drehungswerte

Für Geräte, deren Kameras und Displays das gleiche Gehäuse (oder Gehäusegehäuse/) teilen, ist es möglich, diese Peripheriegeräte auf verschiedenen Oberflächen zu installieren, wobei jedes von ihnen durch einen festen, aber beliebigen Grad auf seiner jeweiligen Ebene gedreht wird. Folglich benötigt eine Anwendung einen Mechanismus, um die räumliche Beziehung zwischen den beiden Peripheriegeräten so zu beschreiben, dass ein erfasster Frame in der richtigen Ausrichtung auf die Renderingoberfläche übertragen werden kann.

Eine Möglichkeit, das Problem zu lösen, besteht darin, die ACPI-_PLD Struktur zu verwenden, in der bereits die Konzepte der Oberfläche und des Drehungsgrads definiert sind. Beispielsweise verfügt die _PLD-Struktur bereits über ein Panelfeld , das die Oberfläche angibt, auf der sich ein Peripheriegerät befindet:

ACPI PLD-Bereichsfeld.

Definition des Felds ACPI _PLD Panel (Rev. 5.0a)

Die nächsten beiden Diagramme veranschaulichen die Definition der einzelnen Panels visuell:

Paneldefinitionen für Desktop-PCs und die meisten Geräte

Bereichsdefinitionen – Desktop.

Paneldefinitionen für faltbare Geräte

Bereichsdefinitionen : faltbare Geräte.

Tatsächlich wird das Konzept eines ACPI-"Panels" bereits von Windows übernommen, wenn:

Eine Kamerageräteschnittstelle ist einer _PLD-Struktur zugeordnet, wobei das Feld Panel entsprechend festgelegt wird, wenn ein Aufnahmegerät statisch an einem festen Ort montiert wird.
Eine Anwendung kann den Bereich abrufen, in dem sich ein Aufzeichnungsgerät befindet, indem die Windows.Devices.Enumeration.DeviceInformation.EnclosureLocation.Panel-Eigenschaft aufgerufen wird .

Die ACPI-_PLD-Struktur verfügt auch über ein Rotationsfeld, das wie folgt definiert ist:

Definition des ACPI-_PLD Rotationsfelds (Rev 5.0a)

ACPI-_PLD-Rotationsfelddefinitionen.

Anstatt die obige Definition unverändert zu verwenden, wird sie weiter verfeinert, um Mehrdeutigkeiten zu vermeiden:

Für Kamera gibt das Feld Drehung in einer ACPI-_PLD-Struktur die Anzahl der Grad an ('0' für 0°, '2' für 90°, '4' für 180° und '6' für 270°), ein erfasster Frame wird relativ zum Bildschirm gedreht, während sich die Anzeige in seiner nativen Ausrichtung befindet.

Primärer Querformat- und Hochformatprimit

In Windows kann die native Anzeigeausrichtung durch Aufrufen der Eigenschaft Windows.Graphics.Display.DisplayInformation.NativeOrientation abgerufen werden, die entweder Querformat oder Hochformat zurückgibt:

Natives Ausrichtungsscanmuster anzeigen.

Unabhängig davon, welchen Wert NativeOrientation zurückgibt, beginnt das scan-Muster der logischen Anzeige von der oberen linken Ecke der Anzeige und bewegt sich von links nach rechts nach unten (siehe Abbildung 5). Bei Geräten, deren physische Standardausrichtung unerklärlich ist, impliziert diese Eigenschaft nicht nur die Position eines ACPI Top-Bereichs , sondern stellt auch die räumliche Beziehung zwischen einem Kameraausgabepuffer und der Renderingoberfläche bereit.

Beachten Sie, dass die NativeOrientation-Eigenschaft im Gegensatz zur Kamera nicht auf ACPI basiert und daher keine _PLD-Struktur aufweist. Dies gilt auch dann, wenn ein Display statisch auf einem Gerät eingebunden wird.

Beim Einbinden auf einem primären Hochformatgerät müssen Kameratreiber beachten, dass die meisten Anwendungen das Gerät unabhängig von der tatsächlichen Ausrichtung des Kameraausgangspuffers als Ausgabepuffer im Querformat behandeln. Aus diesem Grund empfehlen wir, dass Kameratreiber einen Kamerapuffer ausgeben, der einen Ausrichtungsoffset von 90 Grad vom NativeOrientation-Hochformat aufweist, wenn sie sich auf einem Portrait Primary-Gerät befinden. Dadurch können Anwendungen, die diese zusätzliche Drehung auf Hochformatgeräten durchführen, die Drehung auf die erwartete Ausrichtung korrigieren. Dies kann mithilfe des Beispiels Kameraanwendung mit Drehung überprüft werden.

Offsetmontage

IHV/OEMs werden dringend empfohlen, die Montage des Sensors in einem Offset von nicht 0 Grad zu vermeiden, um die App-Kompatibilität zu gewährleisten. Viele vorhandene und ältere Apps wissen nicht, nach der PLD-Tabelle des ACPI zu suchen, und versuchen auch nicht, den Offset ungleich 0 Grad zu korrigieren. Folglich wird das resultierende Video für solche Apps falsch gerendert.

In Fällen, in denen IHV/OEMs den Sensor nicht in der oben beschriebenen 0 Grad-Ausrichtung einbinden können, werden die folgenden Schritte zur Entschärfung in der Reihenfolge der Präferenz empfohlen:

Korrigieren Sie die Ausrichtung ohne 0 Grad im Kameratreiber (entweder im Kernelmodus mit dem AV-Stream-Miniporttreiber oder im Benutzermodus mithilfe eines Plug-Ins wie Device MFT oder MFT0), sodass sich die resultierenden Ausgabeframes in der Ausrichtung von 0 Grad befinden.
Deklarieren Sie die Ausrichtung nicht 0 Grad über das FSSensorOrientation-Tag, damit die Kamerapipeline das aufgenommene Bild korrigieren kann.
Deklarieren Sie die Ausrichtung ungleich 0 Grad in der PLD-Tabelle des ACPI, wie oben beschrieben.

Komprimierte/codierte Medientypen

Für komprimierte und/oder codierte Medientypen (z. B. MJPG, JPEG, H264, HEVC) kann pipeline correct nicht verwendet werden. Aus diesem Grund werden komprimierte/codierte Medientypen herausgefiltert, wenn fsSensorOrientation auf einen Wert ungleich 0 festgelegt ist.

Bei MJPG-Medientypen (z. B. von einer UVC-Kamera) stellt die Frame Server-Pipeline einen automatisch decodierten Medientyp (NV12 oder YUY2 für DShow-basierte Anwendungen) bereit. Der automatisch decodierte und korrigierte Medientyp wird angezeigt, das ursprüngliche MJPG-Format jedoch nicht.

[! HINWEIS!] Wenn komprimierte/codierte Medientypen für Anwendungen verfügbar gemacht werden müssen, dürfen IHV/ODMs die FSSensorOrientation-Korrektur nicht verwenden. Stattdessen muss die Korrektur vom Kameratreiber durchgeführt werden (entweder im Kernelmodus über den AV Stream Treiber oder im Benutzermodus über DMFT/MFT0).

Automatische Korrektur über AV Stream Miniport/Gerät MFT/MFT0

Wenn die Sensoren nicht mit einem Offset von 0 Grad montiert werden können, empfiehlt sich, dass der AV Stream Miniporttreiber (oder die Benutzermodus-Plug-Ins in Form von DMFT oder MFT0) den resultierenden erfassten Rahmen korrigieren, damit er der Pipeline in einem Offset von 0 Grad verfügbar gemacht wird.

Beim Korrigieren des Videoframes aus dem AV-Stream Miniport und/oder dem MFT/MFT0-Stecker des Geräts muss die resultierende Medientypdeklaration auf dem korrigierten Frame basieren. Wenn der Sensor mit einem Offset von 90 Grad montiert ist, sodass das resultierende Video ein Seitenverhältnis von 9:16 vom Sensor aufweist, das korrigierte Video jedoch 16:9 beträgt, muss der Medientyp das Seitenverhältnis von 16:9 deklarieren.

Dies schließt die resultierenden Schrittinformationen ein. Dies ist erforderlich, da die für die Korrektur verantwortliche Komponente vom IHV/OEM gesteuert wird und die Kamerapipeline keinen Einblick in den Videoframe hat, es sei denn, sie wurde korrigiert.

Es wird dringend empfohlen, die Korrektur im Benutzermodus vorzunehmen und der API-Vertrag zwischen der Pipeline und dem Benutzermodus-Plug-In zu befolgen. Insbesondere bei Verwendung von DMFT oder MFT0, wenn die IMFDeviceTransform::P rocessMessage oder IMFTransform::P rocessMessage mit einer MFT_MESSAGE_SET_D3D_MANAGER Nachricht aufgerufen wird, muss das Benutzermodus-Plug-In die folgende Richtlinie einhalten:

Wenn kein D3D-Manager bereitgestellt wird (ulParam der Nachricht ist 0), darf das Benutzermodus-Plug-In KEINE GPU-Vorgänge aufrufen, um die Rotationskorrektur zu verarbeiten. Und der resultierende Frame muss im Systemspeicher bereitgestellt werden.
Wenn D3D-Manager bereitgestellt wird (ulParam der Nachricht ist die IUnknown eines DXGI-Managers), muss dieser DXGI-Manager für die Rotationskorrektur verwendet werden, und der resultierende Frame muss GPU-Speicher sein.
Das Benutzermodus-Plug-In muss auch die D3D-Manager-Nachricht während der Laufzeit verarbeiten. Wenn die MFT_MESSAGE_SET_D3D_MANAGER Meldung ausgegeben wird, muss der nächste vom Plug-In erzeugte Frame dem angeforderten Speichertyp entsprechen (d. h. GPU, wenn DXGI-Manager bereitgestellt wurde, andernfalls CPU).
Wenn der AV Stream-Treiber (oder das Benutzermodus-Plug-In) die Rotationskorrektur verarbeitet, muss das Feld Rotation der PLD-Struktur des ACPI auf 0 festgelegt werden.

Hinweis

Wenn auto Correct verwendet wird, dürfen OEMs und IHVs die tatsächliche Ausrichtung des Sensors NICHT über das Feld _PLD Drehung ankündigen. In diesem Fall muss das Feld Drehung die Ausrichtung nach der Korrektur angeben: 0 Grad.

Deklarieren über FSSensorOrientation

; Defines the sensor mounting orientation offset angle in
; degrees clockwise.
FSSensorOrientation: REG_DWORD: 90, 180, 270

Durch Deklarieren der Nicht-0-Grad-Ausrichtung des Sensors über das Registrierungstag FSSensorOrientation kann die Kamerapipeline den erfassten Frame korrigieren, bevor er der Anwendung präsentiert wird.

Die Pipeline optimiert die Rotationslogik, indem sie GPU- oder CPU-Ressourcen basierend auf dem Anwendungsfall und der App-Anforderung/Szenario nutzt.

ACPI PLD-Rotation

Das Rotationsfeld der ACPI PLD-Struktur muss 0 sein. Dies soll verwirrende Anwendungen vermeiden, die die PLD-Informationen verwenden können, um den Frame zu korrigieren.

Medientypinformationen

Der vom Treiber bereitgestellte Medientyp muss der nicht korrigierte Medientyp sein. Wenn die Kamerapipeline mithilfe des FSSensorOrientation-Eintrags über den Offset ungleich 0 Grad informiert wird, müssen die vom Sensor bereitgestellten Medientypinformationen der nicht korrigierte Medientyp sein. Wenn der Sensor beispielsweise um 90 Grad im Uhrzeigersinn montiert ist, sodass anstelle des Seitenverhältnisses von 16:9 das resultierende Video 9:16 beträgt, muss der Medientyp des Seitenverhältnisses 9:16 der Kamerapipeline angezeigt werden.

Dies ist erforderlich, um sicherzustellen, dass die Pipeline den Zählerrotationsprozess ordnungsgemäß konfigurieren kann: Die Pipeline benötigt den Eingabemedientyp und den gewünschten Ausgabemedientyp der Anwendung.

Dies schließt die Schrittinformationen ein. Die Schrittinformationen müssen für den nicht korrigierten Medientyp der Kamerapipeline angezeigt werden.

Registrierungsunterschlüssel

Der Registrierungseintrag FSSensorOrientation muss auf dem Knoten Geräteschnittstelle veröffentlicht werden. Der empfohlene Ansatz besteht darin, dies während der AddInterface-Direktivendeklaration im INF des Kameratreibers als AddReg-Direktive zu deklarieren.

Die in der FSSensorOrientation angezeigten Daten müssen eine REG_DWORD sein, und die einzigen gültigen Werte sind 90, 180 und 270. Jeder andere Wert wird als 0 Grad Offset behandelt (d. h. ignoriert).

Jeder Wert stellt die Sensorausrichtung im Uhrzeigersinn in Grad dar. Die Kamerapipeline korrigiert den resultierenden Videorahmen, indem das Video um denselben Betrag gegen den Uhrzeigersinn gedreht wird: d. h. eine 90-Grad-Deklaration im Uhrzeigersinn führt zu einer Drehung um 90 Grad gegen den Uhrzeigersinn, um den resultierenden Videoframe wieder auf 0 Grad Offset zu bringen.

MS-Betriebssystemdeskriptor 1.0

Für USB-basierte Kameras kann FSSensorOrientation auch über MSOS-Deskriptoren veröffentlicht werden.

MS OS Descriptor 1.0 verfügt über zwei Komponenten:

Ein Headerabschnitt mit fester Länge
Benutzerdefinierte Eigenschaftenabschnitte mit variabler Länge, die dem Headerabschnitt folgen

Abschnitt "MS OS DESCRIPTOR 1.0 Header"

Der Headerabschnitt beschreibt eine einzelne benutzerdefinierte Eigenschaft (Face Auth Profile).

Offset	Feld	Größe (Byte)	Wert	BESCHREIBUNG
0	dwLength	4	<>
4	bcdVersion	2	0x0100	Version 1.0
6	Windex	2	0x0005	Betriebssystemdeskriptor für erweiterte Eigenschaften
8	wCount	2	0x0001	Eine benutzerdefinierte Eigenschaft

Abschnitt "Benutzerdefinierte MS OS DESCRIPTOR 1.0-Eigenschaft"

Offset	Feld	Größe (Byte)	Wert	BESCHREIBUNG
0	dwSize	4	0x00000036 (54)	Gesamtgröße (in Bytes) für diese Eigenschaft.
4	dwPropertyDataType	4	0x00000004	REG_DWORD_LITTLE_ENDIAN
8	wPropertyNameLength	2	0x00000024 (36)	Größe (in Bytes) des Eigenschaftsnamens.
10	bPropertyName	50	UVC-FSSensorOrientation	Zeichenfolge "UVC-FSSensorOrientation" in Unicode.
60	dwPropertyDataLength	4	0x00000004	4 Bytes für Eigenschaftsdaten (sizeof(DWORD)).
64	bPropertyData	4	Offsetwinkel in Grad im Uhrzeigersinn.	Gültige Werte sind 90, 180 und 270.

MS OS Descriptor 2.0

MsOS Extended Descriptor 2.0 kann verwendet werden, um die Registrierungswerte zu definieren, um FSSensorOrientation-Unterstützung hinzuzufügen. Dies geschieht mithilfe des Microsoft OS 2.0-Registrierungseigenschaftsdeskriptors.

Für den UVC-FSSensorOrientation Registrierungseintrags wird im Folgenden ein MSOS 2.0-Beispieldeskriptorsatz gezeigt:

UCHAR Example2_MSOS20DescriptorSet_UVCFSSensorOrientationForFutureWindows[0x3C] =
{
    //
    // Microsoft OS 2.0 Descriptor Set Header
    //
    0x0A, 0x00,                 // wLength - 10 bytes
    0x00, 0x00,                 // MSOS20_SET_HEADER_DESCRIPTOR
    0x00, 0x00, 0x0?, 0x06,     // dwWindowsVersion – 0x060?0000 for future Windows version
    0x4A, 0x00,                 // wTotalLength – 74 bytes

    //
    // Microsoft OS 2.0 Registry Value Feature Descriptor
    //
    0x40, 0x00,                 // wLength - 64 bytes
    0x04, 0x00,                 // wDescriptorType – 4 for Registry Property
    0x04, 0x00,                 // wPropertyDataType - 4 for REG_DWORD_LITTLE_ENDIAN
    0x32, 0x00,                 // wPropertyNameLength – 50 bytes
    0x55, 0x00, 0x56, 0x00,     // Property Name - "UVC-FSSensorOrientation"
    0x43, 0x00, 0x2D, 0x00,
    0x46, 0x00, 0x53, 0x00,
    0x53, 0x00, 0x65, 0x00,
    0x6E, 0x00, 0x73, 0x00,
    0x6F, 0x00, 0x72, 0x00,
    0x4F, 0x00, 0x72, 0x00,
    0x69, 0x00, 0x65, 0x00,
    0x6E, 0x00, 0x74, 0x00,
    0x61, 0x00, 0x74, 0x00,
    0x69, 0x00, 0x6F, 0x00,
    0x6E, 0x00, 0x00, 0x00,
    0x00, 0x00,
    0x04, 0x00,                 // wPropertyDataLength – 4 bytes
    0x5A, 0x00, 0x00, 0x00      // PropertyData – 0x0000005A (90 degrees offset)
}

Deklarieren über ACPI PLD-Informationen

Als letzte Option können PLD-Informationen wie oben beschrieben genutzt werden, um der Anwendung mitzuteilen, dass der Videoframe vor dem Rendern/Codieren korrigiert werden muss. Wie bereits erwähnt, verwenden viele vorhandene Anwendungen jedoch weder die PLD-Informationen noch behandeln die Framerotation, sodass es Szenarien geben wird, in denen Apps das resultierende Video möglicherweise nicht ordnungsgemäß rendern können.

Die folgenden Abbildungen veranschaulichen die Werte des Felds _PLD Rotation für jede Hardwarekonfiguration:

Drehung: 0 Grad im Uhrzeigersinn

0 Grad Drehzahl.

In der obigen Abbildung:

Das Bild auf der linken Seite veranschaulicht die zu erfassende Szene.
Das Bild in der Mitte zeigt, wie eine Szene von einem CMOS-Sensor angezeigt wird, dessen physische Auslesereihenfolge von der unteren linken Ecke beginnt, die sich von links nach rechts nach oben bewegt.
Das Bild auf der rechten Seite stellt die Ausgabe des Kameratreibers dar. In diesem Beispiel kann der Inhalt des Medienpuffers direkt gerendert werden, während die Anzeige ihre native Ausrichtung ohne zusätzliche Drehung aufweist. Folglich weist das FELD ACPI _PLD Rotation den Wert 0 auf.

Drehung: 90 Grad im Uhrzeigersinn

90 Grad Drehzahl.

In diesem Fall wird der Inhalt des Medienpuffers im Uhrzeigersinn im Vergleich zur ursprünglichen Szene um 90 Grad gedreht. Daher weist das FELD ACPI _PLD Rotation den Wert 2 auf.

Drehung: 180 Grad im Uhrzeigersinn

180 Grad Drehzahl.

In diesem Fall wird der Inhalt des Medienpuffers im Uhrzeigersinn im Vergleich zur ursprünglichen Szene um 180 Grad gedreht. Daher weist das FELD ACPI _PLD Rotation den Wert 4 auf.

Drehung: 270 Grad im Uhrzeigersinn

Drehzahl um 270 Grad.

In diesem Fall wird der Inhalt des Medienpuffers im Uhrzeigersinn im Vergleich zur ursprünglichen Szene um 270 Grad gedreht. Daher weist das FELD ACPI _PLD Rotation den Wert 6 auf.

Freigeben über