Podsystem HAL

Upraszanie

Struktura aplikacji wysyła żądania dotyczące przechwyconych wyników do podsystemu kamery. Jedno żądanie odpowiada jednemu zestawowi wyników. Żądanie zawiera wszystkie informacje konfiguracyjne dotyczące przechwytywania i przetwarzania tych wyników. Obejmuje to takie rzeczy, jak rozdzielczość i format pikseli; ręczne sterowanie czujnikiem, obiektywem i lampą błyskową; Tryby pracy 3A; Kontrola przetwarzania RAW do YUV; i generowanie statystyk. Pozwala to na znacznie większą kontrolę nad wynikami i przetwarzaniem. Jednocześnie może być przesyłanych wiele żądań, a przesyłanie żądań nie powoduje blokowania. Żądania są zawsze przetwarzane w kolejności ich otrzymania.

Rysunek 1. Model aparatu

Podsystem HAL i kamera

Podsystem kamery obejmuje implementacje komponentów potoku kamery, takich jak algorytm 3A i elementy sterujące przetwarzaniem. Kamera HAL zapewnia interfejsy umożliwiające implementację własnych wersji tych komponentów. Aby zachować kompatybilność międzyplatformową pomiędzy wieloma producentami urządzeń i dostawcami procesorów sygnału obrazu (ISP lub czujnika kamery), model potoku kamery jest wirtualny i nie odpowiada bezpośrednio żadnemu prawdziwemu dostawcy usług internetowych. Jest jednak na tyle podobny do rzeczywistych potoków przetwarzania, że ​​można go efektywnie zmapować na swoim sprzęcie. Ponadto jest na tyle abstrakcyjny, że pozwala na zastosowanie wielu różnych algorytmów i kolejności operacji bez uszczerbku dla jakości, wydajności lub zgodności między urządzeniami.

Potok kamery obsługuje także wyzwalacze, które platforma aplikacji może inicjować w celu włączenia takich funkcji, jak automatyczne ustawianie ostrości. Wysyła także powiadomienia z powrotem do struktury aplikacji, powiadamiając aplikacje o zdarzeniach, takich jak blokada automatycznego ustawiania ostrości lub błędy.

Rysunek 2. Rurociąg kamery

Należy pamiętać, że niektóre bloki przetwarzania obrazu pokazane na powyższym schemacie nie są dobrze zdefiniowane w początkowej wersji. Potok kamery przyjmuje następujące założenia:

• Dane wyjściowe RAW firmy Bayer nie są przetwarzane przez dostawcę usług internetowych.
• Statystyki są generowane na podstawie surowych danych z czujników.
• Różne bloki przetwarzania, które konwertują surowe dane z czujnika na YUV, są ułożone w dowolnej kolejności.
• Chociaż wyświetlanych jest wiele jednostek skali i przycinania, wszystkie jednostki skalowania mają wspólne elementy sterujące obszarem wyjściowym (zoom cyfrowy). Jednakże każda jednostka może mieć inną rozdzielczość wyjściową i format pikseli.

Podsumowanie użycia API
Oto krótkie podsumowanie kroków korzystania z interfejsu API aparatu w systemie Android. Aby zapoznać się ze szczegółowym zestawieniem tych kroków, w tym wywołań API, zobacz sekcję Uruchamianie i oczekiwana sekwencja operacji.

1. Słuchaj i wyliczaj urządzenia z kamerą.
2. Otwórz urządzenie i połącz słuchaczy.
3. Skonfiguruj wyjścia dla docelowego przypadku użycia (takiego jak przechwytywanie, nagrywanie itp.).
4. Utwórz żądania dla docelowego przypadku użycia.
5. Przechwytuj/powtarzaj żądania i serie.
6. Otrzymuj metadane wyników i dane obrazu.
7. Podczas przełączania przypadków użycia wróć do kroku 3.

Podsumowanie operacji HAL

• Asynchroniczne żądania przechwytywania pochodzą z platformy.
• Urządzenie HAL musi przetwarzać żądania w określonej kolejności. Dla każdego żądania utwórz metadane wyników wyjściowych i co najmniej jeden bufor obrazu wyjściowego.
• Pierwsze wejście, pierwsze wyjście w przypadku żądań i wyników oraz w przypadku strumieni, do których odwołują się kolejne żądania.
• Sygnatury czasowe muszą być identyczne dla wszystkich wyników danego żądania, aby w razie potrzeby platforma mogła je ze sobą dopasować.
• Cała konfiguracja i stan przechwytywania (z wyjątkiem procedur 3A) jest hermetyzowana w żądaniach i wynikach.

Rysunek 3. Przegląd HAL kamery

Uruchomienie i oczekiwana kolejność działania

Ta sekcja zawiera szczegółowe wyjaśnienie kroków oczekiwanych podczas korzystania z interfejsu API kamery. Aby zapoznać się z definicjami interfejsu HIDL, zobacz platformę/sprzęt/interfejsy/kamerę/ .

Wyliczanie, otwieranie urządzeń kamerowych i tworzenie aktywnej sesji

1. Po inicjalizacji platforma zaczyna nasłuchiwać wszystkich obecnych dostawców kamer, którzy implementują interfejs ICameraProvider . Jeśli taki dostawca lub dostawcy są obecni, framework spróbuje nawiązać połączenie.
2. Struktura wylicza urządzenia kamer za pomocą ICameraProvider::getCameraIdList() .
3. Struktura tworzy instancję nowego ICameraDevice , wywołując odpowiednią funkcję ICameraProvider::getCameraDeviceInterface_VX_X() .
4. Struktura wywołuje ICameraDevice::open() w celu utworzenia nowej aktywnej sesji przechwytywania ICameraDeviceSession.

Korzystanie z aktywnej sesji aparatu

1. Struktura wywołuje ICameraDeviceSession::configureStreams() z listą strumieni wejścia/wyjścia do urządzenia HAL.
2. Struktura żąda ustawień domyślnych dla niektórych przypadków użycia z wywołaniami ICameraDeviceSession::constructDefaultRequestSettings() . Może to nastąpić w dowolnym momencie po utworzeniu ICameraDeviceSession przez ICameraDevice::open .
3. Struktura konstruuje i wysyła pierwsze żądanie przechwytywania do warstwy HAL z ustawieniami opartymi na jednym z zestawów ustawień domyślnych i z co najmniej jednym strumieniem wyjściowym, który został wcześniej zarejestrowany przez platformę. Jest to wysyłane do warstwy HAL za pomocą ICameraDeviceSession::processCaptureRequest() . HAL musi zablokować zwrot tego połączenia, dopóki nie będzie gotowy na wysłanie kolejnego żądania.
4. Struktura nadal przesyła żądania i wywołuje ICameraDeviceSession::constructDefaultRequestSettings() , aby uzyskać bufory ustawień domyślnych dla innych przypadków użycia, jeśli to konieczne.
5. Gdy rozpoczyna się przechwytywanie żądania (czujnik zaczyna udostępniać do przechwytywania), warstwa HAL wywołuje funkcję ICameraDeviceCallback::notify() z komunikatem SHUTTER, zawierającym numer klatki i znacznik czasu rozpoczęcia naświetlania. To wywołanie zwrotne powiadamiania nie musi nastąpić przed pierwszym wywołaniem processCaptureResult() w przypadku żądania, ale żadne wyniki nie są dostarczane do aplikacji w celu przechwycenia, dopóki nie zostanie wywołane notify() dla tego przechwytywania.
6. Po pewnym opóźnieniu potoku warstwa HAL zaczyna zwracać ukończone przechwytywania do platformy za pomocą ICameraDeviceCallback::processCaptureResult() . Są one zwracane w tej samej kolejności, w jakiej zostały złożone wnioski. Jednocześnie może być przesyłanych wiele żądań, w zależności od głębokości rurociągu urządzenia HAL z kamerą.

Po pewnym czasie nastąpi jedna z poniższych sytuacji:

• Struktura może przestać przesyłać nowe żądania, poczekać na zakończenie istniejących przechwytywania (wypełnienie wszystkich buforów i zwrócenie wszystkich wyników), a następnie ponownie wywołać funkcję ICameraDeviceSession::configureStreams() . Spowoduje to zresetowanie sprzętu i potoku kamery dla nowego zestawu strumieni wejścia/wyjścia. Niektóre strumienie mogą zostać ponownie wykorzystane z poprzedniej konfiguracji. Struktura jest następnie kontynuowana od pierwszego żądania przechwytywania do warstwy HAL, jeśli pozostaje co najmniej jeden zarejestrowany strumień wyjściowy. (W przeciwnym razie najpierw wymagana jest ICameraDeviceSession::configureStreams() .)
• Struktura może wywołać funkcję ICameraDeviceSession::close() w celu zakończenia sesji kamery. Można to wywołać w dowolnym momencie, gdy żadne inne wywołania ze struktury nie są aktywne, chociaż wywołanie może zostać zablokowane do czasu zakończenia wszystkich przechwytywania w locie (zwrócone wszystkie wyniki, zapełnione wszystkie bufory). Po powrocie wywołania close() z warstwy HAL nie są już dozwolone żadne wywołania ICameraDeviceCallback . Po rozpoczęciu wywołania funkcji close() framework nie może wywoływać żadnych innych funkcji urządzenia HAL.
• W przypadku błędu lub innego zdarzenia asynchronicznego warstwa HAL musi wywołać funkcję ICameraDeviceCallback::notify() z odpowiednim komunikatem o błędzie/zdarzeniu. Po powrocie z powiadomienia o błędzie krytycznym obejmującym całe urządzenie warstwa HAL powinna działać tak, jakby została na niej wywołana funkcja close() . Jednak warstwa HAL musi albo anulować, albo zakończyć wszystkie zaległe przechwytywania przed wywołaniem notify() , tak aby po wywołaniu notify() z błędem krytycznym struktura nie otrzymywała dalszych wywołań zwrotnych z urządzenia. Metody inne niż close() powinny zwracać wartość -ENODEV lub NULL, gdy metoda notify() zwróci komunikat o błędzie krytycznym.

Rysunek 4. Schemat działania kamery

Poziomy sprzętu

Urządzenia z kamerą mogą implementować kilka poziomów sprzętowych w zależności od swoich możliwości. Aby uzyskać więcej informacji, zobacz obsługiwany poziom sprzętu .

Interakcja między żądaniem przechwycenia aplikacji, kontrolą 3A i potokiem przetwarzania

W zależności od ustawień w bloku kontrolnym 3A, potok kamery ignoruje niektóre parametry w żądaniu przechwytywania aplikacji i zamiast tego wykorzystuje wartości dostarczone przez procedury sterujące 3A. Na przykład, gdy aktywna jest automatyczna ekspozycja, czas ekspozycji, czas trwania klatki i parametry czułości czujnika są kontrolowane przez algorytm platformy 3A, a wszelkie wartości określone przez aplikację są ignorowane. Wartości wybrane dla ramki przez procedury 3A muszą być zgłaszane w metadanych wyjściowych. Poniższa tabela opisuje różne tryby bloku sterującego 3A i właściwości kontrolowane przez te tryby. Definicje tych właściwości można znaleźć w pliku platform/system/media/camera/docs/docs.html .

Wszystkie elementy sterujące w bloku przetwarzania obrazu na rysunku 2 działają na podobnej zasadzie i ogólnie każdy blok ma trzy tryby:

• WYŁ.: Ten blok przetwarzania jest wyłączony. Bloków demozaiki, korekcji kolorów i regulacji krzywej tonalnej nie można wyłączyć.
• SZYBKO: W tym trybie blok przetwarzający nie może zmniejszać wyjściowej szybkości klatek w porównaniu z trybem WYŁ., ale poza tym powinien generować wydruk o najwyższej jakości, jaki jest w stanie uzyskać przy tych ograniczeniach. Zwykle jest to używane w trybach podglądu lub nagrywania wideo albo w trybie zdjęć seryjnych. Na niektórych urządzeniach może to być równoznaczne z trybem WYŁ. (nie można wykonać żadnego przetwarzania bez zmniejszenia szybkości klatek), a na niektórych urządzeniach może to być równoznaczne z trybem WYSOKIEJ JAKOŚCI (najlepsza jakość nadal nie spowalnia szybkości klatek).
• WYSOKA_JAKOŚĆ: W tym trybie blok przetwarzania powinien generować wynik o możliwie najlepszej jakości, zmniejszając w razie potrzeby wyjściową częstotliwość klatek. Zwykle jest to wykorzystywane do robienia zdjęć o wysokiej jakości. Niektóre bloki obejmują sterowanie ręczne, które można opcjonalnie wybrać zamiast SZYBKO lub WYSOKA JAKOŚĆ. Na przykład blok korekcji kolorów obsługuje matrycę transformacji kolorów, podczas gdy regulacja krzywej tonalnej obsługuje dowolną krzywą globalnego mapowania tonów.

Maksymalna liczba klatek na sekundę obsługiwana przez podsystem kamery jest funkcją wielu czynników:

• Żądane rozdzielczości wyjściowych strumieni obrazów
• Dostępność trybów kategoryzacji/pomijania w wywoływarce
• Przepustowość interfejsu kamery
• Przepustowość różnych bloków przetwarzania ISP

Ponieważ czynniki te mogą się znacznie różnić w zależności od dostawcy usług internetowych i czujników, interfejs HAL kamery próbuje ująć ograniczenia przepustowości w możliwie najprostszy model. Prezentowany model charakteryzuje się następującymi cechami:

• Przetwornik obrazu jest zawsze skonfigurowany tak, aby generować możliwie najmniejszą rozdzielczość, biorąc pod uwagę żądane przez aplikację rozmiary strumienia wyjściowego. Najmniejszą rozdzielczość definiuje się jako co najmniej tak dużą, jak największy żądany rozmiar strumienia wyjściowego.
• Ponieważ każde żądanie może wykorzystywać dowolny lub wszystkie aktualnie skonfigurowane strumienie wyjściowe, czujnik i dostawca usług internetowych muszą być skonfigurowani tak, aby obsługiwały skalowanie pojedynczego przechwytywania do wszystkich strumieni jednocześnie.
• Strumienie JPEG działają jak przetworzone strumienie YUV w przypadku żądań, dla których nie są uwzględnione; w żądaniach, w których następuje bezpośrednie odniesienie, działają jak strumienie JPEG.
• Procesor JPEG może działać jednocześnie z resztą potoku kamery, ale nie może przetwarzać więcej niż jednego przechwycenia na raz.