Obsługa wielu kamer

W Androidzie 9 wprowadziliśmy obsługę interfejsu API dla urządzeń z wieloma aparatami za pomocą nowego logicznego urządzenia z aparatem, które składa się z co najmniej 2 fizycznych urządzeń z aparatem skierowanych w tym samym kierunku. Urządzenie kamery logicznej jest udostępniane aplikacji jako pojedyncze urządzenie CameraDevice lub sesja CaptureSession, co umożliwia interakcję z funkcjami wielu kamer zintegrowanymi z HAL. Aplikacje mogą opcjonalnie uzyskiwać dostęp do strumieni, metadanych i elementów sterujących fizycznego aparatu oraz nimi zarządzać.

Obsługa wielu kamer

Rysunek 1. Obsługa wielu kamer

Na tym diagramie różne identyfikatory kamer są oznaczone kolorami. Aplikacja może jednocześnie przesyłać strumieniowo surowe bufory z każdej kamery fizycznej. Można też ustawić osobne elementy sterujące i otrzymywać osobne metadane z różnych fizycznych aparatów.

Przykłady i źródła

Urządzenia z wieloma kamerami muszą być reklamowane z logicznie powiązaną funkcją wielu kamer.

Klienty aparatu mogą wysyłać zapytania o identyfikator aparatu urządzeń fizycznych, z których składa się dany aparat logiczny, wywołując funkcję getPhysicalCameraIds(). Identyfikatory zwrócone w ramach wyniku są następnie używane do sterowania poszczególnymi urządzeniami fizycznymi za pomocą setPhysicalCameraId(). Wyniki takich pojedynczych żądań można uzyskać z pełnego wyniku, wywołując getPhysicalCameraResults().

Poszczególne żądania dotyczące fizycznego aparatu mogą obsługiwać tylko ograniczony podzbiór parametrów. Aby otrzymać listę obsługiwanych parametrów, programiści mogą wywołać funkcję getAvailablePhysicalCameraRequestKeys().

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

Implementacja

Lista kontrolna pomocy

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

W przypadku urządzeń z Androidem 9 aparaty muszą obsługiwać zastępowanie jednego logicznego strumienia YUV/RAW strumieniami fizycznymi o tym samym rozmiarze (nie dotyczy strumieni RAW) i tym samym formacie z 2 aparatów fizycznych. Nie dotyczy to urządzeń z Androidem 10.

W przypadku urządzeń z Androidem 10, na których wersja urządzenia HAL aparatu to 3.5 lub nowsza, urządzenie musi obsługiwać isStreamCombinationSupported, aby aplikacje mogły sprawdzać, czy obsługiwana jest określona kombinacja strumieni zawierająca strumienie fizyczne.

Mapa konfiguracji strumienia

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

W przypadku urządzenia z kamerą logiczną obsługującego funkcję RAW z fizycznymi podkamerami o różnych rozmiarach, jeśli aplikacja skonfiguruje logiczny strumień RAW, urządzenie z kamerą logiczną nie może przełączać się na fizyczne podkamery o różnych rozmiarach matrycy. Dzięki temu istniejące aplikacje do rejestrowania obrazów RAW nie przestaną działać.

Aby korzystać z optycznego zoomu zaimplementowanego w HAL przez przełączanie się między fizycznymi podkamerami podczas rejestrowania obrazu w formacie RAW, aplikacje muszą konfigurować strumienie fizycznych podkamer zamiast logicznego strumienia RAW.

Gwarantowana kombinacja strumieni

Zarówno kamera logiczna, jak i jej fizyczne kamery muszą gwarantować obowiązkowe kombinacje strumieni wymagane na ich poziomach urządzenia.

Urządzenie kamery logicznej powinno działać w taki sam sposób jak urządzenie kamery fizycznej, w zależności od poziomu sprzętu i możliwości. Zalecamy, aby zestaw funkcji był nadzbiorem funkcji poszczególnych kamer fizycznych.

W przypadku urządzeń z Androidem 9 każda gwarantowana kombinacja strumieni musi być obsługiwana przez kamerę logiczną:

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

  • Dodawanie 2 strumieni RAW, po jednym z każdej kamery fizycznej, jeśli kamera logiczna nie obsługuje formatu RAW, ale obsługują go kamery fizyczne. Zwykle ma to miejsce, gdy kamery fizyczne mają różne rozmiary matryc.

  • Używanie strumieni fizycznych zamiast strumienia logicznego o tym samym rozmiarze i formacie. Nie może to spowalniać liczby klatek na sekundę podczas rejestrowania, gdy minimalny czas trwania klatki w przypadku strumieni fizycznych i logicznych jest taki sam.

Wydajność i zasilanie

  • Skuteczność:

    • Konfigurowanie i przesyłanie strumieni fizycznych może spowolnić szybkość rejestrowania obrazu przez kamerę logiczną z powodu ograniczeń zasobów.
    • Zastosowanie ustawień aparatu fizycznego może spowolnić szybkość rejestrowania, jeśli aparaty bazowe zostaną ustawione na różne liczby klatek na sekundę.

  • Zasilanie:

    • Optymalizacja zasilania w HAL-u nadal działa w przypadku domyślnym.
    • Konfigurowanie lub żądanie strumieni fizycznych może zastąpić wewnętrzną optymalizację zużycia energii w HAL-u i zwiększyć zużycie energii.

Dostosowywanie

Implementację urządzenia możesz dostosować na te sposoby:

  • Połączone dane wyjściowe logicznego urządzenia kamery zależą całkowicie od implementacji HAL. Decyzja o tym, jak połączone strumienie logiczne są uzyskiwane z kamer fizycznych, jest niewidoczna dla aplikacji i platformy aparatu Android.
  • Opcjonalnie można obsługiwać indywidualne prośby i wyniki dotyczące aktywności fizycznej. Zestaw dostępnych parametrów w takich żądaniach zależy też całkowicie od konkretnej implementacji HAL.
  • Od Androida 10 HAL może zmniejszyć liczbę kamer, które aplikacja może bezpośrednio otworzyć, poprzez nieudostępnianie niektórych lub wszystkich identyfikatorów PHYSICAL_ID w getCameraIdList. Wywołanie metody getPhysicalCameraCharacteristics musi zwrócić charakterystykę kamery fizycznej.

Weryfikacja

Urządzenia z wieloma kamerami logicznymi muszą przejść testy CTS kamery tak samo jak inne zwykłe kamery. Przypadki testowe, które są przeznaczone dla tego typu urządzenia, znajdziesz w module LogicalCameraDeviceTest.

Te 3 testy ITS są przeznaczone dla systemów z wieloma aparatami, aby ułatwić prawidłowe łączenie obrazów:

Testy sceny 1 i sceny 4 są przeprowadzane za pomocą ITS-in-a-box. Test test_multi_camera_match sprawdza, czy jasność środka obrazów jest taka sama, gdy obie kamery są włączone. Testtest_multi_camera_alignment sprawdza, czy odstępy między kamerami, ich orientacja i parametry zniekształceń są prawidłowo wczytywane. Jeśli system wielu kamer zawiera kamerę o szerokim polu widzenia (ponad 90°), wymagana jest wersja 2 skrzynki ITS.

Sensor_fusion to drugie stanowisko testowe, które umożliwia powtarzanie określonych ruchów telefonu i sprawdzanie, czy sygnatury czasowe żyroskopu i matrycy obrazu są zgodne oraz czy klatki z wielu aparatów są zsynchronizowane.

Wszystkie pudełka są dostępne w firmach AcuSpec, Inc. (www.acuspecinc.com, fred@acuspecinc.com) i MYWAY Manufacturing (www.myway.tw, sales@myway.tw). Dodatkowo urządzenie ITS w wersji rev1 można kupić w firmie West-Mark (www.west-mark.com, dgoodman@west-mark.com).

Sprawdzone metody

Aby w pełni korzystać z funkcji włączonych przez wiele aparatów, zachowując przy tym zgodność aplikacji, podczas wdrażania logicznego urządzenia z wieloma aparatami stosuj te sprawdzone metody:

  • (Android 10 lub nowszy) Ukrywanie fizycznych aparatów dodatkowych przed getCameraIdList. Zmniejsza to liczbę kamer, które mogą być bezpośrednio otwierane przez aplikacje, eliminując potrzebę stosowania przez nie złożonej logiki wyboru kamery.
  • (Android 11 lub nowszy) W przypadku urządzenia z wieloma kamerami logicznymi obsługującego zoom optyczny zaimplementuj interfejs API ANDROID_CONTROL_ZOOM_RATIO i używaj ANDROID_SCALER_CROP_REGION tylko do przycinania współczynnika proporcji. ANDROID_CONTROL_ZOOM_RATIO umożliwia oddalenie obrazu i zachowanie większej precyzji. W takim przypadku 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 powiększeniu jako aktywną tablicę czujnika. Więcej informacji o tym, jak ANDROID_SCALER_CROP_REGION współpracuje z ANDROID_CONTROL_ZOOM_RATIO, znajdziesz w artykule camera3_crop_reprocess#cropping.
  • W przypadku urządzeń z wieloma kamerami fizycznymi o różnych możliwościach upewnij się, że urządzenie reklamuje obsługę określonej wartości lub zakresu dla elementu sterującego tylko wtedy, gdy cały zakres powiększenia obsługuje tę wartość lub ten zakres. Jeśli np. aparat logiczny składa się z aparatu ultraszerokokątnego, szerokokątnego i teleobiektywu, wykonaj te czynności:
    • Jeśli aktywne rozmiary matryc fizycznych kamer są różne, interfejs HAL kamery musi mapować aktywne matryce kamer fizycznych na aktywne matryce kamery logicznej w przypadku 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, tak aby z perspektywy aplikacji układ współrzędnych był aktywnym rozmiarem matrycy kamery logicznej.
    • 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ę autofokusu. Warstwa HAL musi symulować automat stanu autofokusa dla aparatu ultraszerokokątnego, aby w momencie, gdy aplikacja powiększa obraz do obiektywu ultraszerokokątnego, fakt, że bazowy aparat fizyczny ma stałą ostrość, był dla niej niewidoczny, a automaty stanu autofokusa dla obsługiwanych trybów AF działały zgodnie z oczekiwaniami.
    • Jeśli aparat szerokokątny i teleobiektyw obsługują rozdzielczość 4K przy 60 klatkach na sekundę, a aparat ultraszerokokątny obsługuje tylko rozdzielczość 4K przy 30 klatkach na sekundę lub 1080p przy 60 klatkach na sekundę, ale nie 4K przy 60 klatkach na sekundę, upewnij się, że aparat logiczny nie reklamuje rozdzielczości 4K przy 60 klatkach na sekundę w obsługiwanych konfiguracjach strumieniowania. Gwarantuje to integralność możliwości kamery logicznej, dzięki czemu aplikacja nie napotka problemu z osiągnięciem 4K przy 60 kl./s przy wartości ANDROID_CONTROL_ZOOM_RATIO mniejszej niż 1.
  • Od Androida 10 nie jest wymagany logiczny aparat z wieloma obiektywami, aby obsługiwać kombinacje strumieni, które obejmują strumienie fizyczne. Jeśli HAL obsługuje kombinację ze strumieniami fizycznymi:
    • (Android 11 lub nowszy) Aby lepiej obsługiwać przypadki użycia, takie jak głębia z obrazu stereoskopowego i śledzenie ruchu, ustaw pole widzenia fizycznych strumieni wyjściowych tak szerokie, jak to możliwe w przypadku danego sprzętu. 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 strumienia logicznego.
    • Aby zmniejszyć obciążenie pamięci spowodowane przez wiele strumieni fizycznych, upewnij się, że aplikacje używają funkcji discardFreeBuffers do zwalniania wolnych buforów (buforów zwolnionych przez odbiorcę, ale jeszcze nie usuniętych z kolejki przez producenta), jeśli oczekuje się, że strumień fizyczny będzie nieaktywny przez pewien czas.
    • Jeśli strumienie fizyczne z różnych kamer fizycznych nie są zwykle dołączane do tego samego żądania, zadbaj o to, aby aplikacje używały surface group, dzięki czemu jedna kolejka buforów będzie używana do obsługi 2 interfejsów aplikacji, co zmniejszy zużycie pamięci.