Obsługa wielu kamer

Zadbaj o dobrą organizację dzięki kolekcji Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.

W systemie Android 9 wprowadzono obsługę interfejsu API dla urządzeń z wieloma kamerami za pośrednictwem nowego logicznego urządzenia kamery złożonego z co najmniej dwóch fizycznych urządzeń kamer skierowanych w tym samym kierunku. Urządzenie z kamerą logiczną jest wystawiane jako pojedyncza kamera CameraDevice/CaptureSession w aplikacji umożliwiającej interakcję z funkcjami wielu kamer zintegrowanymi z HAL. Aplikacje mogą opcjonalnie uzyskiwać dostęp i kontrolować podstawowe strumienie, metadane i elementy sterujące z kamer fizycznych.

Obsługa wielu kamer

Rysunek 1 . Obsługa wielu kamer

Na tym schemacie różne identyfikatory kamer są oznaczone kolorami. Aplikacja może przesyłać strumieniowo surowe bufory z każdej fizycznej kamery w tym samym czasie. Możliwe jest również ustawienie oddzielnych kontroli i odbieranie oddzielnych metadanych z różnych kamer fizycznych.

Przykłady i źródła

Urządzenia z wieloma kamerami muszą być reklamowane z logiczną obsługą 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 getPhysicalCameraIds() . Identyfikatory zwrócone jako część wyniku są następnie używane do indywidualnego sterowania urządzeniami fizycznymi za pomocą setPhysicalCameraId() . Wyniki takich indywidualnych żądań można odpytywać z pełnego wyniku, wywołując getPhysicalCameraResults() .

Żądania dotyczące indywidualnych kamer fizycznych 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 dla czujników monochromatycznych i 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 fotograficzne muszą obsługiwać zastąpienie jednego logicznego strumienia YUV/RAW fizycznymi strumieniami o tym samym rozmiarze (nie dotyczy strumieni RAW) i tym samym formacie z dwóch fizycznych aparatów. Nie dotyczy to urządzeń z Androidem 10.

W przypadku urządzeń z systemem Android 10, w których wersja urządzenia HAL kamery to 3.5 lub nowsza, urządzenie z kamerą musi obsługiwać isStreamCombinationSupported aby aplikacje mogły sprawdzać, czy dana kombinacja strumieni zawierająca strumienie fizyczne jest obsługiwana.

Mapa konfiguracji strumienia

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

W przypadku logicznego urządzenia z kamerą obsługującego funkcję RAW z fizycznymi kamerami podrzędnymi o różnych rozmiarach, jeśli aplikacja skonfiguruje logiczny strumień RAW, logiczne urządzenie z kamerą nie może przełączać się na fizyczne podkamery o różnych rozmiarach czujnika. Gwarantuje to, że istniejące aplikacje do przechwytywania plików RAW nie psują się.

Aby skorzystać z zoomu optycznego zaimplementowanego w technologii HAL poprzez przełączanie fizycznych kamer podrzędnych podczas przechwytywania RAW, aplikacje muszą skonfigurować fizyczne strumienie podkamer zamiast logicznego strumienia RAW.

Gwarantowana kombinacja strumienia

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

Logiczne urządzenie z kamerą powinno działać w taki sam sposób, jak fizyczne urządzenie z kamerą, w zależności od poziomu sprzętu i możliwości. Zaleca się, aby jego zestaw funkcji był nadzbiorem zestawu indywidualnych kamer fizycznych.

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

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

  • Dodanie dwóch strumieni nieprzetworzonych, po jednym z każdej fizycznej kamery, jeśli kamera logiczna nie reklamuje możliwości RAW, ale podstawowe kamery fizyczne tak. Zwykle dzieje się tak, gdy fizyczne kamery mają różne rozmiary czujników.

  • 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 strumienia fizycznego i logicznego jest taki sam.

Rozważania dotyczące 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 fizycznych ustawień kamery może spowolnić szybkość przechwytywania, jeśli podstawowe kamery zostaną ustawione w różnych częstotliwościach 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 warstwy HAL i spowodować większe zużycie energii.

Dostosowywanie

Implementację urządzenia można dostosować w następujący sposób.

  • Łączone wyjście kamery logicznej zależy całkowicie od implementacji warstwy HAL. Decyzja dotycząca sposobu uzyskiwania połączonych strumieni logicznych z kamer fizycznych jest niewidoczna dla aplikacji i struktury kamery systemu Android.
  • Indywidualne żądania fizyczne i wyniki mogą być opcjonalnie obsługiwane. Zestaw dostępnych parametrów w takich żądaniach jest również całkowicie zależny od konkretnej implementacji HAL.
  • W systemie Android 10 warstwa HAL może zmniejszyć liczbę kamer, które mogą być bezpośrednio otwierane przez aplikację, wybierając opcję nierozgłaszania niektórych lub wszystkich identyfikatorów PHYSICAL_ID w getCameraIdList . Wywołanie getPhysicalCameraCharacteristics musi następnie zwrócić charakterystykę fizycznej kamery.

Walidacja

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

Te trzy testy ITS dotyczą systemów wielokamerowych w celu ułatwienia prawidłowego łączenia obrazów:

Testy sceny 1 i sceny 4 są przeprowadzane za pomocą urządzenia testowego ITS-in-a-box . Test test_multi_camera_match zapewnia, że ​​jasność środka obrazów jest taka sama, gdy obie kamery są włączone. Test test_multi_camera_alignment potwierdza, że ​​odstępy między kamerami, orientacje i parametry zniekształceń są prawidłowo ładowane. Jeśli system wielokamerowy zawiera kamerę Wide FoV (>90o), wymagana jest wersja rev2 skrzynki ITS.

Sensor_fusion to drugie stanowisko testowe, które umożliwia powtarzalne, określone ruchy telefonu i zapewnia, że ​​znaczniki czasowe żyroskopu i czujnika obrazu są zgodne, a klatki z wielu kamer są zsynchronizowane.

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

Najlepsze praktyki

Aby w pełni korzystać z funkcji obsługiwanych przez wiele kamer przy zachowaniu zgodności aplikacji, postępuj zgodnie z poniższymi najlepszymi praktykami podczas wdrażania logicznego urządzenia z wieloma kamerami:

  • (Android 10 lub nowszy) Ukryj fizyczne podkamery z getCameraIdList . Zmniejsza to liczbę kamer, które mogą być bezpośrednio otwierane przez aplikacje, eliminując potrzebę stosowania przez aplikacje złożonej logiki wyboru kamery.
  • (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żywaj ANDROID_SCALER_CROP_REGION tylko do przycinania proporcji. ANDROID_CONTROL_ZOOM_RATIO umożliwia urządzeniu pomniejszanie i zachowanie lepszej 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 uzyskać więcej informacji o tym, jak ANDROID_SCALER_CROP_REGION współpracuje z ANDROID_CONTROL_ZOOM_RATIO , zobacz camera3_crop_reprocess#cropping .
  • W przypadku urządzeń z wieloma kamerami z fizycznymi kamerami, które mają różne możliwości, upewnij się, że urządzenie reklamuje obsługę określonej wartości lub zakresu dla kontrolki tylko wtedy, gdy cały zakres powiększenia obsługuje tę wartość lub zakres. Na przykład, jeśli aparat logiczny składa się z ultrawide, 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ę logiczną kamer dla ANDROID_SCALER_CROP_REGION , ANDROID_CONTROL_AE_REGIONS , ANDROID_CONTROL_AWB_REGIONS , ANDROID_CONTROL_AF_REGIONS , ANDROID_SCALER_CROP_REGION , ANDROID_CONTROL_AE_REGIONS , ANDROID_CONTROL_AWB_REGIONS , ANDROID_STATISTICS_FACE_LANDMARKS , ANDROID_STATISTICS_FACE_RECTANGLES i z perspektywy, układ współrzędnych jest aktywnym rozmiarem tablicy kamery logicznej.
    • Jeśli aparaty szerokokątne i teleobiektywy 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 ultrawide, aby po zbliżeniu aplikacji do obiektywu ultrawide fakt, że podstawowy aparat fizyczny ma stałą ostrość, był przezroczysty dla aplikacji, a maszyny stanu autofokusa dla obsługiwanych trybów AF działać zgodnie z oczekiwaniami.
    • Jeśli kamery szerokokątne i teleobiektywy obsługują 4K @ 60 fps, a ultrawide obsługuje tylko 4K @ 30 fps lub 1080p @ 60 fps, ale nie 4K @ 60 fps, upewnij się, że kamera logiczna nie reklamuje 4k @ 60 fps w obsługiwane konfiguracje strumienia. Gwarantuje to integralność funkcji kamery logicznej, zapewniając, że aplikacja nie napotka problemu nieosiągnięcia 4k @ 60 fps przy wartości ANDROID_CONTROL_ZOOM_RATIO mniejszej niż 1.
  • Począwszy od systemu Android 10, logiczna wielokamera nie jest wymagana do obsługi kombinacji strumieni, które obejmują strumienie fizyczne. Jeśli warstwa HAL obsługuje kombinację ze strumieniami fizycznymi:
    • (Android 11 lub nowszy) Aby lepiej radzić sobie z przypadkami użycia, takimi jak głębia ze stereo i śledzenie ruchu, zwiększ pole widzenia wyjść strumienia fizycznego tak duże, jak może być osiągnięte 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 strumienia logicznego.
    • Aby rozwiązać problem presji pamięci spowodowanej przez wiele strumieni fizycznych, upewnij się, że aplikacje używają discardFreeBuffers do cofnięcia alokacji wolnych buforów (buforów, które są zwalniane przez konsumenta, ale nie zostały jeszcze usunięte z kolejki przez producenta), jeśli strumień fizyczny ma być bezczynny przez pewien czas czasu.
    • Jeśli strumienie fizyczne z różnych kamer fizycznych nie są zwykle dołączone do tego samego żądania, upewnij się, że aplikacje używają surface group aby jedna kolejka buforu była używana do tworzenia kopii zapasowych dwóch powierzchni skierowanych do aplikacji, co zmniejsza zużycie pamięci.