Obsługa wielu kamer

W systemie Android 9 wprowadzono obsługę interfejsu API dla urządzeń z wieloma kamerami poprzez nową kamerę logiczną złożoną z dwóch lub więcej kamer fizycznych skierowanych w tym samym kierunku. Logiczne urządzenie kamery jest udostępniane jako pojedyncze urządzenie CameraDevice/CaptureSession w aplikacji, co pozwala na interakcję z funkcjami wielu kamer zintegrowanymi z HAL. Aplikacje mogą opcjonalnie uzyskiwać dostęp do strumieni, metadanych i elementów sterujących z kamer fizycznych oraz je kontrolować.

Obsługa wielu kamer

Rysunek 1 . Obsługa wielu kamer

Na tym schemacie różne identyfikatory kamer są oznaczone kolorami. Aplikacja może jednocześnie przesyłać strumieniowo surowe bufory z każdej fizycznej kamery. Możliwe jest także ustawienie oddzielnych elementów sterujących i otrzymywanie oddzielnych metadanych z różnych kamer fizycznych.

Przykłady i źródła

Urządzenia z wieloma kamerami muszą być reklamowane z logiczną możliwością obsługi wielu kamer .

Klienci kamer mogą wysyłać zapytania o identyfikatory urządzeń fizycznych, z których składa się konkretna kamera logiczna, wywołując metodę getPhysicalCameraIds() . Identyfikatory zwrócone jako część wyniku są następnie wykorzystywane do indywidualnego sterowania urządzeniami fizycznymi za pomocą setPhysicalCameraId() . Wyniki takich indywidualnych żądań można sprawdzić na podstawie pełnego wyniku, wywołując metodę getPhysicalCameraResults() .

Indywidualne żądania kamery fizycznej mogą obsługiwać tylko ograniczony podzbiór parametrów. Aby otrzymać listę obsługiwanych parametrów, programiści mogą wywołać getAvailablePhysicalCameraRequestKeys() .

Strumienie z kamer fizycznych są obsługiwane tylko w przypadku żądań bez ponownego przetwarzania i tylko w przypadku czujników monochromatycznych i czujników Bayer.

Realizacja

Lista kontrolna wsparcia

Aby dodać logiczne urządzenia z wieloma kamerami po stronie HAL:

W przypadku urządzeń z systemem Android 9 aparaty muszą obsługiwać wymianę jednego logicznego strumienia YUV/RAW na strumienie fizyczne o tym samym rozmiarze (nie dotyczy strumieni RAW) i tym samym formacie z dwóch kamer fizycznych. Nie dotyczy to urządzeń z systemem Android 10.

W przypadku urządzeń z systemem Android 10, w których kamera HAL jest w wersji 3.5 lub nowszej, kamera musi obsługiwać isStreamCombinationSupported , aby aplikacje mogły wysyłać zapytania, czy obsługiwana jest konkretna kombinacja strumieni zawierająca strumienie fizyczne.

Mapa konfiguracji strumienia

W przypadku kamery logicznej obowiązkowe kombinacje strumieni dla kamery na określonym poziomie sprzętowym są takie same, jak wymagane w CameraDevice.createCaptureSession . Wszystkie strumienie na mapie konfiguracji strumieni muszą być strumieniami logicznymi.

W przypadku logicznej kamery obsługującej format RAW z fizycznymi kamerami pomocniczymi o różnych rozmiarach, jeśli aplikacja skonfiguruje logiczny strumień RAW, logiczna kamera nie może przełączać się na fizyczne kamery dodatkowe z matrycami o różnych rozmiarach. Dzięki temu istniejące aplikacje do przechwytywania plików RAW nie psują się.

Aby skorzystać z zoomu optycznego zaimplementowanego w HAL poprzez przełączanie między fizycznymi kamerami dodatkowymi podczas przechwytywania plików RAW, aplikacje muszą konfigurować strumienie fizycznych kamer pomocniczych zamiast logicznego strumienia RAW.

Gwarantowana kombinacja strumieni

Zarówno kamera logiczna, jak i leżące u jej podstaw kamery fizyczne muszą gwarantować obowiązkowe kombinacje strumieni wymagane dla poziomów ich urządzeń.

Logiczna kamera powinna działać w taki sam sposób, jak fizyczna kamera, biorąc pod uwagę poziom sprzętu i możliwości. Zaleca się, aby jego zestaw funkcji stanowił nadzbiór zestawu poszczególnych kamer fizycznych.

Na urządzeniach z systemem Android 9 dla każdej gwarantowanej kombinacji strumieni kamera logiczna musi obsługiwać:

  • Zastąpienie jednego logicznego YUV_420_888 lub strumienia surowego dwoma strumieniami fizycznymi o tym samym rozmiarze i formacie, każdy z oddzielnej kamery fizycznej, pod warunkiem, że rozmiar i format są obsługiwane przez kamery fizyczne.

  • Dodanie dwóch nieprzetworzonych strumieni, po jednym z każdej kamery fizycznej, jeśli kamera logiczna nie reklamuje możliwości formatu RAW, ale podstawowe kamery fizyczne tak. Zwykle ma to miejsce, gdy kamery fizyczne mają różne rozmiary matrycy.

  • Używanie strumieni fizycznych zamiast strumienia logicznego o tym samym rozmiarze i formacie. Nie może to spowalniać szybkości klatek przechwytywania, gdy minimalny czas trwania klatek strumieni fizycznych i logicznych jest taki sam.

Względy wydajności i mocy

  • Wydajność:

    • Konfigurowanie i przesyłanie strumieniowe strumieni fizycznych może spowolnić szybkość przechwytywania kamery logicznej ze względu na ograniczenia zasobów.
    • Zastosowanie ustawień kamery fizycznej może spowolnić szybkość przechwytywania, jeśli podstawowe kamery mają różną częstotliwość klatek.
  • Moc:

    • Optymalizacja mocy HAL nadal działa w przypadku domyślnym.
    • Konfigurowanie lub żądanie strumieni fizycznych może zastąpić wewnętrzną optymalizację zasilania HAL i spowodować większe zużycie energii.

Dostosowywanie

Implementację urządzenia można dostosować na następujące sposoby.

  • Bezpieczne wyjście logicznej kamery zależy całkowicie od implementacji HAL. Decyzja dotycząca sposobu wyprowadzania połączonych strumieni logicznych z kamer fizycznych jest przejrzysta dla aplikacji i struktury kamer w systemie Android.
  • Indywidualne fizyczne żądania i wyniki mogą być opcjonalnie obsługiwane. Zestaw parametrów dostępnych w takich żądaniach jest również całkowicie zależny od konkretnej implementacji HAL.
  • Począwszy od Androida 10, warstwa HAL może zmniejszyć liczbę kamer, które można bezpośrednio otworzyć za pomocą aplikacji, decydując się na nie reklamowanie niektórych lub wszystkich identyfikatorów PHYSICAL_ID w getCameraIdList . Wywołanie metody getPhysicalCameraCharacteristics musi następnie zwrócić charakterystykę kamery fizycznej.

Walidacja

Logiczne urządzenia z wieloma kamerami muszą przejść CTS kamery jak każda inna zwykła kamera. Przypadki testowe przeznaczone dla tego typu urządzeń można znaleźć w module LogicalCameraDeviceTest .

Te trzy testy ITS dotyczą systemów wielokamerowych, aby ułatwić prawidłowe łączenie obrazów:

Testy sceny 1 i 4 przeprowadzane są na platformie testowej ITS-in-a-box . Test test_multi_camera_match potwierdza, że ​​jasność środka obrazu jest zgodna, gdy obie kamery są włączone. Test test_multi_camera_alignment sprawdza, czy odstępy kamer, orientacje i parametry zniekształceń są prawidłowo załadowane. Jeżeli system wielokamerowy zawiera kamerę Wide FoV (>90o), wymagana jest wersja 2 modułu ITS.

Sensor_fusion to drugie stanowisko testowe, które umożliwia powtarzalne, określone ruchy telefonu i sprawdza, czy znaczniki czasu żyroskopu i czujnika obrazu są zgodne oraz czy klatki z wielu kamer są zsynchronizowane.

Wszystkie pudełka są dostępne za pośrednictwem firm AcuSpec, Inc. ( www.acuspecinc.com , fred@acuspecinc.com) i MYWAY Manufacturing ( www.myway.tw , sales@myway.tw). Dodatkowo moduł ITS wersji 1 można kupić w firmie West-Mark ( www.west-mark.com , dgoodman@west-mark.com).

Najlepsze praktyki

Aby w pełni wykorzystać funkcje obsługiwane przez wiele kamer, zachowując jednocześnie kompatybilność aplikacji, postępuj zgodnie z poniższymi najlepszymi praktykami podczas wdrażania logicznego urządzenia z wieloma kamerami:

  • (Android 10 lub nowszy) Ukryj fizyczne kamery podrzędne przed getCameraIdList . Zmniejsza to liczbę kamer, które aplikacje mogą bezpośrednio otwierać, eliminując potrzebę stosowania przez aplikacje złożonej logiki wyboru kamer.
  • (Android 11 lub nowszy) W przypadku logicznego urządzenia z wieloma kamerami obsługującego zoom optyczny zaimplementuj interfejs API ANDROID_CONTROL_ZOOM_RATIO i użyj ANDROID_SCALER_CROP_REGION tylko do przycinania proporcji. ANDROID_CONTROL_ZOOM_RATIO umożliwia urządzeniu oddalanie i zachowanie większej precyzji. W takim przypadku warstwa HAL musi dostosować układ współrzędnych ANDROID_SCALER_CROP_REGION , ANDROID_CONTROL_AE_REGIONS , ANDROID_CONTROL_AWB_REGIONS , ANDROID_CONTROL_AF_REGIONS , ANDROID_STATISTICS_FACE_RECTANGLES i ANDROID_STATISTICS_FACE_LANDMARKS , aby traktować pole widzenia po przybliżeniu jako czujnik aktywny tablica. Aby uzyskać więcej informacji na temat współpracy ANDROID_SCALER_CROP_REGION z ANDROID_CONTROL_ZOOM_RATIO , zobacz camera3_crop_reprocess#cropping .
  • W przypadku urządzeń z wieloma kamerami i kamerami fizycznymi o różnych możliwościach upewnij się, że urządzenie ogłasza obsługę określonej wartości lub zakresu kontrolki tylko wtedy, gdy cały zakres zoomu obsługuje tę wartość lub zakres. Na przykład, jeśli aparat logiczny składa się z aparatu ultraszerokokątnego, szerokokątnego i teleobiektywu, wykonaj następujące czynności:
    • Jeśli rozmiary aktywnej tablicy kamer fizycznych są różne, warstwa HAL kamery musi wykonać mapowanie z aktywnych tablic kamer fizycznych na aktywną tablicę kamery logicznej dla ANDROID_SCALER_CROP_REGION , ANDROID_CONTROL_AE_REGIONS , ANDROID_CONTROL_AWB_REGIONS , ANDROID_CONTROL_AF_REGIONS , ANDROID_STATISTICS_FACE_RECTANGLES i ANDROID_STATISTICS_FACE_LANDMARKS , aby z aplikacji perspektywy układ współrzędnych to rozmiar aktywnej tablicy logicznej kamery.
    • Jeśli aparat szerokokątny i teleobiektyw obsługują autofokus, ale aparat ultraszerokokątny ma stałą ostrość, upewnij się, że aparat logiczny reklamuje obsługę autofokusa. HAL musi symulować maszynę stanu autofokusa dla aparatu ultraszerokokątnego, tak aby gdy aplikacja pomniejszy obraz do obiektywu ultraszerokokątnego, fakt, że podstawowa kamera fizyczna ma stałą ostrość, był niewidoczny dla aplikacji, a maszyny stanu autofokusa dla obsługiwanych trybów AF działać zgodnie z oczekiwaniami.
    • Jeśli aparat szerokokątny i teleobiektyw obsługują 4K przy 60 kl./s, a aparat ultraszerokokątny obsługuje tylko 4K przy 30 kl./s lub 1080p przy 60 kl./s, ale nie 4K przy 60 kl./s, upewnij się, że kamera logiczna nie reklamuje 4K przy 60 kl./s w obsługiwane konfiguracje strumieni. Gwarantuje to integralność logicznych możliwości kamery i gwarantuje, że aplikacja nie napotka problemu nieosiągnięcia 4k przy 60 fps przy wartości ANDROID_CONTROL_ZOOM_RATIO mniejszej niż 1.
  • Począwszy od systemu Android 10, logiczna kamera z wieloma kamerami nie jest wymagana do obsługi kombinacji strumieni obejmujących strumienie fizyczne. Jeśli warstwa HAL obsługuje kombinację ze strumieniami fizycznymi:
    • (Android 11 lub nowszy) Aby lepiej obsługiwać przypadki użycia, takie jak głębia stereo i śledzenie ruchu, ustaw pole widzenia strumieni fizycznych na tak duże, jak to tylko możliwe przez sprzęt. Jeśli jednak strumień fizyczny i strumień logiczny pochodzą z tej samej kamery fizycznej, ograniczenia sprzętowe mogą wymusić, aby pole widzenia strumienia fizycznego było takie samo jak strumień logiczny.
    • Aby rozwiązać problem zużycia pamięci spowodowanego przez wiele strumieni fizycznych, upewnij się, że aplikacje korzystają z discardFreeBuffers w celu zwolnienia przydziału wolnych buforów (buforów udostępnionych przez konsumenta, ale jeszcze nie usuniętych z kolejki przez producenta), jeśli oczekuje się, że strumień fizyczny będzie bezczynny przez pewien czas czasu.
    • Jeśli strumienie fizyczne z różnych kamer fizycznych zwykle nie są dołączone do tego samego żądania, upewnij się, że aplikacje korzystają z surface group , tak aby jedna kolejka buforów była używana do tworzenia kopii zapasowych dwóch powierzchni skierowanych do aplikacji, co zmniejsza zużycie pamięci.