Podsystem HAL

Żądania

Platforma aplikacji wysyła żądania dotyczące przechwyconych wyników do podsystemu aparatu. Jedno żądanie odpowiada jednemu zestawowi wyników. Żądanie zawiera wszystkie informacje o konfiguracji dotyczące przechwytywania i przetwarzania tych wyników. Obejmuje to takie elementy jak rozdzielczość i format pikseli, ręczne sterowanie czujnikiem, obiektywem, i lampą błyskową, tryby działania 3A, sterowanie przetwarzaniem RAW na YUV oraz generowanie statystyk. Umożliwia to znacznie większą kontrolę nad wynikami' i ich przetwarzaniem. Jednocześnie może być w toku kilka żądań, a ich przesyłanie nie blokuje innych działań. Żądania są zawsze przetwarzane w kolejności ich otrzymania.

Rysunek 1. Model aparatu

HAL i podsystem aparatu

Podsystem aparatu obejmuje implementacje komponentów w potoku aparatu takich jak algorytm 3A i elementy sterujące przetwarzaniem. HAL aparatu udostępnia interfejsy, które umożliwiają implementowanie własnych wersji tych komponentów. Aby zachować zgodność na wielu platformach między różnymi producentami urządzeń i dostawcami procesorów sygnału obrazu (ISP lub czujników aparatu), model potoku aparatu jest wirtualny i nie odpowiada bezpośrednio żadnemu rzeczywistemu procesorowi ISP. Jest on jednak wystarczająco podobny do rzeczywistych potoków przetwarzania, aby można go było efektywnie mapować na sprzęt. Ponadto jest on wystarczająco abstrakcyjny, aby umożliwić stosowanie różnych algorytmów i kolejności operacji bez pogorszenia jakości, wydajności ani zgodności na innym urządzeniu.

Potok aparatu obsługuje też wyzwalacze, które platforma aplikacji może inicjować aby włączyć takie funkcje jak autofokus. Wysyła też powiadomienia z powrotem do platformy aplikacji, informując aplikacje o zdarzeniach takich jak blokada autofokusu czy błędy.

Rysunek 2. Potok aparatu

Pamiętaj, że niektóre bloki przetwarzania obrazu pokazane na powyższym diagramie nie są dobrze zdefiniowane w początkowej wersji. Potok aparatu opiera się na tych założeniach:

• Dane wyjściowe RAW Bayer nie są przetwarzane w procesorze ISP.
• Statystyki są generowane na podstawie nieprzetworzonych danych z czujnika.
• Różne bloki przetwarzania, które przekształcają nieprzetworzone dane z czujnika na YUV, są w dowolnej kolejności.
• Chociaż pokazano wiele jednostek skalowania i przycinania, wszystkie jednostki skalowania mają wspólne elementy sterujące regionem wyjściowym (zoom cyfrowy). Każda jednostka może jednak mieć inną rozdzielczość wyjściową i format pikseli.

Podsumowanie korzystania z interfejsu API
Oto krótkie podsumowanie kroków korzystania z interfejsu API aparatu Androida. Szczegółowy opis tych kroków, w tym wywołań interfejsu API, znajdziesz w sekcji Sekwencja uruchamiania i oczekiwanych operacji.

1. Nasłuchuj i wyliczaj urządzenia z aparatem.
2. Otwórz urządzenie i połącz odbiorniki.
3. Skonfiguruj dane wyjściowe dla docelowego przypadku użycia (np. przechwytywanie zdjęć, nagrywanie, itp.).
4. Utwórz żądania dla docelowego przypadku użycia.
5. Przechwytuj lub powtarzaj żądania i serie.
6. Odbieraj metadane wyników i dane obrazu.
7. Gdy zmieniasz przypadki użycia, wróć do kroku 3.

Podsumowanie działania HAL

• Asynchroniczne żądania przechwytywania pochodzą z platformy.
• Urządzenie HAL musi przetwarzać żądania w kolejności. W przypadku każdego żądania musi generować metadane wyników wyjściowych oraz co najmniej 1 bufor obrazu wyjściowego.
• Kolejność FIFO w przypadku żądań i wyników oraz strumieni, do których odwołują się kolejne żądania.
• Znaczniki czasu muszą być identyczne dla wszystkich danych wyjściowych z danego żądania, aby platforma mogła je w razie potrzeby dopasować.
• Cała konfiguracja i stan przechwytywania (z wyjątkiem procedur 3A) są hermetyzowane w żądaniach i wynikach.

Rysunek 3. Omówienie HAL aparatu

Sekwencja uruchamiania i oczekiwanych operacji

Ta sekcja zawiera szczegółowe wyjaśnienie kroków, które należy wykonać podczas korzystania z interfejsu API aparatu. Definicje interfejsu HIDL znajdziesz w platform/hardware/interfaces/camera/.

Wyliczanie i otwieranie urządzeń z aparatem oraz tworzenie aktywnej sesji

1. Po zainicjowaniu platforma zaczyna nasłuchiwać obecnych dostawców aparatu, którzy implementują ICameraProvider interfejs. Jeśli taki dostawca lub dostawcy są obecni, platforma spróbuje nawiązać połączenie.
2. Platforma wylicza urządzenia z aparatem za pomocą ICameraProvider::getCameraIdList().
3. Platforma tworzy instancję nowego ICameraDevice, wywołując odpowiedni ICameraProvider::getCameraDeviceInterface_VX_X().
4. Platforma wywołuje ICameraDevice::open(), aby utworzyć nową aktywną sesję przechwytywania ICameraDeviceSession.

Korzystanie z aktywnej sesji aparatu

1. Platforma wywołuje ICameraDeviceSession::configureStreams() z listą strumieni wejściowych i wyjściowych do urządzenia HAL.
2. Platforma żąda ustawień domyślnych dla niektórych przypadków użycia za pomocą wywołań ICameraDeviceSession::constructDefaultRequestSettings(). Może to nastąpić w dowolnym momencie po utworzeniu ICameraDeviceSession przez ICameraDevice::open.
3. Platforma tworzy i wysyła pierwsze żądanie przechwytywania do HAL z ustawieniami opartymi na jednym z zestawów ustawień domyślnych oraz z co najmniej 1 strumieniem wyjściowym, który został wcześniej zarejestrowany przez platformę. Jest ono wysyłane do HAL za pomocą ICameraDeviceSession::processCaptureRequest(). HAL musi zablokować powrót tego wywołania, dopóki nie będzie gotowy na wysłanie następnego żądania.
4. Platforma nadal przesyła żądania i wywołuje ICameraDeviceSession::constructDefaultRequestSettings() w celu uzyskania buforów ustawień domyślnych dla innych przypadków użycia w razie potrzeby.
5. Gdy rozpocznie się przechwytywanie żądania (czujnik zacznie się eksponować na potrzeby przechwytywania), HAL wywoła ICameraDeviceCallback::notify() z komunikatem SHUTTER, w tym z numerem klatki i znacznikiem czasu rozpoczęcia ekspozycji. To wywołanie zwrotne powiadomienia nie musi nastąpić przed pierwszym processCaptureResult() wywołaniem dla żądania, ale żadne wyniki nie są dostarczane do aplikacji do momentu wywołania notify() dla tego przechwytywania.
6. Po pewnym opóźnieniu potoku HAL zaczyna zwracać ukończone przechwytywania do platformy za pomocą ICameraDeviceCallback::processCaptureResult(). Są one zwracane w tej samej kolejności, w jakiej zostały przesłane żądania. W zależności od głębokości potoku urządzenia HAL aparatu jednocześnie może być w toku kilka żądań.

Po pewnym czasie nastąpi jedna z tych sytuacji:

• Platforma może przestać przesyłać nowe żądania, poczekać na zakończenie istniejących przechwytywań (wypełnienie wszystkich buforów, zwrócenie wszystkich wyników), a następnie ponownie wywołać ICameraDeviceSession::configureStreams() ponownie. Spowoduje to zresetowanie sprzętu i potoku aparatu dla nowego zestawu strumieni wejściowych i wyjściowych. Niektóre strumienie mogą być ponownie używane z poprzedniej konfiguracji. Platforma będzie kontynuować od pierwszego żądania przechwytywania do HAL, jeśli pozostanie co najmniej 1 zarejestrowany strumień wyjściowy. (W przeciwnym razie, ICameraDeviceSession::configureStreams() jest wymagane najpierw.)
• Platforma może wywołać ICameraDeviceSession::close() , aby zakończyć sesję aparatu. Może to nastąpić w dowolnym momencie, gdy nie są aktywne żadne inne wywołania z platformy, chociaż wywołanie może zostać zablokowane do momentu zakończenia wszystkich przechwytywań w toku (zwrócenia wszystkich wyników, wypełnienia wszystkich buforów wypełnionych). Po powrocie wywołania close() HAL nie może już wywoływać ICameraDeviceCallback. Gdy wywołanie close() jest w toku, platforma nie może wywoływać żadnych innych funkcji urządzenia HAL.
• W przypadku błędu lub innego zdarzenia asynchronicznego HAL musi wywołać ICameraDeviceCallback::notify() z odpowiednim komunikatem o błędzie lub zdarzeniu. Po powrocie z powiadomienia o krytycznym błędzie w całym urządzeniu HAL powinien zachowywać się tak, jakby wywołano na nim close(). HAL musi jednak anulować lub zakończyć wszystkie oczekujące przechwytywania przed wywołaniem notify(), aby po wywołaniu notify() z krytycznym błędem platforma nie otrzymywała dalszych wywołań zwrotnych z urządzenia. Metody inne niż close() powinny zwracać -ENODEV lub NULL po powrocie metody notify() z komunikatu o krytycznym błędzie.

Rysunek 4. Przebieg działania aparatu

Poziomy sprzętu

Urządzenia z aparatem mogą implementować kilka poziomów sprzętu w zależności od swoich możliwości. Więcej informacji znajdziesz w artykule Obsługiwany poziom sprzętu.

Interakcja między żądaniem przechwytywania aplikacji, sterowaniem 3A i potokiem przetwarzania

W zależności od ustawień w bloku sterowania 3A potok aparatu ignoruje niektóre parametry w żądaniu przechwytywania aplikacji i używa wartości podanych przez procedury sterowania 3A. Na przykład, gdy aktywna jest automatyczna ekspozycja, czas ekspozycji, czas trwania klatki i czułość czujnika są kontrolowane przez algorytm 3A platformy, a wszystkie wartości określone przez aplikację są ignorowane. Wartości wybrane dla klatki przez procedury 3A muszą być zgłaszane w metadanych wyjściowych. W tabeli poniżej opisano różne tryby bloku sterowania 3A oraz właściwości, które są kontrolowane przez te tryby. Definicje tych właściwości znajdziesz w pliku platform/system/media/camera/docs/docs.html.

Parametr	Stan	Kontrolowane właściwości
android.control.aeMode	WYŁ.	Brak
	WŁ.	android.sensor.exposureTime android.sensor.frameDuration android.sensor.sensitivity android.lens.aperture (jeśli obsługiwane) android.lens.filterDensity (jeśli obsługiwane)
	ON_AUTO_FLASH	Wszystko jest WŁĄCZONE, a dodatkowo android.flash.firingPower, android.flash.firingTime i android.flash.mode
	ON_ALWAYS_FLASH	Tak samo jak ON_AUTO_FLASH
	ON_AUTO_FLASH_RED_EYE	Tak samo jak ON_AUTO_FLASH
android.control.awbMode	WYŁ.	Brak
	WHITE_BALANCE_*	android.colorCorrection.transform. Dostosowania specyficzne dla platformy, jeśli android.colorCorrection.mode to FAST lub HIGH_QUALITY.
android.control.afMode	WYŁ.	Brak
	FOCUS_MODE_*	android.lens.focusDistance
android.control.videoStabilization	WYŁ.	Brak
	WŁ.	Można dostosować android.scaler.cropRegion, aby zaimplementować stabilizację obrazu
android.control.mode	WYŁ.	AE, AWB i AF są wyłączone
	AUTOMATYCZNIE	Używane są indywidualne ustawienia AE, AWB i AF
	SCENE_MODE_*	Można zastąpić wszystkie parametry wymienione powyżej. Indywidualne elementy sterujące 3A są wyłączone.

Elementy sterujące w bloku przetwarzania obrazu na rysunku 2 działają na podobnej zasadzie. Każdy blok ma zwykle 3 tryby:

• WYŁ.: ten blok przetwarzania jest wyłączony. Bloków demosaic, korekcji kolorów i dostosowania krzywej tonalnej nie można wyłączyć.
• SZYBKO: w tym trybie blok przetwarzania nie powinien spowalniać liczby klatek wyjściowych w porównaniu z trybem WYŁ., ale powinien generować dane wyjściowe o najwyższej możliwej jakości przy tym ograniczeniu. Zwykle jest to używane w trybach podglądu lub nagrywania wideo albo w trybie przechwytywania seryjnego zdjęć. Na niektórych urządzeniach może to być równoznaczne z trybem WYŁ. (nie można przeprowadzić przetwarzania bez spowolnienia liczby klatek), a na niektórych urządzeniach może to być równoznaczne z trybem HIGH_QUALITY (najwyższa jakość nie spowalnia liczby klatek).
• HIGH_QUALITY: w tym trybie blok przetwarzania powinien generować wyniki o najwyższej jakości, w razie potrzeby spowalniając liczbę klatek wyjściowych. Zwykle jest to używane do przechwytywania zdjęć w wysokiej jakości. Niektóre bloki zawierają sterowanie ręczne, które można opcjonalnie wybrać zamiast trybu FAST lub HIGH_QUALITY. Na przykład blok korekcji kolorów obsługuje macierz transformacji kolorów , a blok dostosowania krzywej tonalnej obsługuje dowolną globalną krzywą mapowania tonalnego.

Maksymalna liczba klatek na sekundę, którą może obsługiwać podsystem aparatu, zależy od wielu czynników:

• Żądane rozdzielczości strumieni obrazu wyjściowego.
• Dostępność trybów binningu i pomijania w obrazie.
• Przepustowość interfejsu obrazu.
• Przepustowość różnych bloków przetwarzania ISP.

Ponieważ te czynniki mogą się znacznie różnić w zależności od procesora ISP i czujnika, interfejs HAL aparatu próbuje abstrakcyjnie przedstawić ograniczenia przepustowości w jak najprostszym modelu. Przedstawiony model ma te cechy:

• Czujnik obrazu jest zawsze skonfigurowany tak, aby generować dane wyjściowe w najmniejszej możliwej rozdzielczości biorąc pod uwagę rozmiary strumieni wyjściowych żądane przez aplikację. Najmniejsza rozdzielczość jest definiowana jako co najmniej tak duża jak największy żądany rozmiar strumienia wyjściowego.
• Ponieważ każde żądanie może używać dowolnych lub wszystkich aktualnie skonfigurowanych strumieni wyjściowych, czujnik i procesor ISP muszą być skonfigurowane tak, aby obsługiwać skalowanie pojedynczego przechwytywania do wszystkich strumieni jednocześnie.
• W przypadku żądań, w których nie są uwzględniane strumienie JPEG, działają one jak przetworzone strumienie YUV . W przypadku żądań, w których są bezpośrednio przywoływane, działają jak strumienie JPEG .
• Procesor JPEG może działać równolegle z resztą potoku aparatu, ale nie może przetwarzać więcej niż 1 przechwytywania naraz.