Podsystem HAL

Na tej stronie opisujemy podsystem HAL, w tym żądania, podsystem aparatu, sekwencję uruchamiania i działania, poziomy sprzętowe oraz interakcje.

Żądania

Platforma aplikacji wysyła do podsystemu aparatu żądania dotyczące przechwyconych wyników. 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. Można jednocześnie wysyłać wiele żą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łączać 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 obszarem 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 działań.

1. Nasłuchiwanie i wyliczanie urządzeń z aparatem.
2. Otwieranie urządzenia i łączenie odbiorników.
3. Konfigurowanie danych wyjściowych na potrzeby docelowego przypadku użycia (np. robienia zdjęć lub nagrywania).
4. Tworzenie żądań na potrzeby docelowego przypadku użycia.
5. Przechwytywanie/powtarzanie żądań i serii zdjęć.
6. Odbieranie metadanych wyników i danych obrazu.
7. Podczas przełączania przypadków użycia wróć do kroku 3.

Podsumowanie działania HAL

• Żądania asynchroniczne dotyczące 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 we 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 działań

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

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

1. Po zainicjowaniu platforma zaczyna nasłuchiwać wszystkich obecnych dostawców aparatu, którzy implementują ICameraProvider interfejs. Jeśli taki dostawca lub dostawcy są obecni, platforma pró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 w niektórych przypadkach użycia, wywołując ICameraDeviceSession::constructDefaultRequestSettings. Może to nastąpić w dowolnym momencie po utworzeniu ICameraDeviceSession przez ICameraDevice::open.
3. Platforma tworzy i wysyła do HAL pierwsze żądanie przechwytywania z ustawieniami opartymi na jednym z zestawów ustawień domyślnych oraz 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, aby w razie potrzeby uzyskać bufory ustawień domyślnych w innych przypadkach użycia.
5. Gdy rozpocznie się przechwytywanie żądania (czujnik zacznie naświetlać na potrzeby przechwytywania), HAL wywoła ICameraDeviceCallback::notify z komunikatem SHUTTER, w tym numerem klatki i znacznikiem czasu rozpoczęcia naświetlania. To wywołanie zwrotne powiadomienia nie musi nastąpić przed pierwszym processCaptureResult wywołaniem w przypadku żądania, ale żadne wyniki nie są dostarczane do aplikacji w przypadku przechwytywania, dopóki nie zostanie wywołane notify w przypadku tego przechwytywania.
6. Po pewnym opóźnieniu potoku HAL zaczyna zwracać ukończone przechwytywanie 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 można jednocześnie wysyłać wiele żądań.

Po pewnym czasie nastąpi jedna z tych sytuacji:

• Platforma przestaje przesyłać nowe żądania, czeka na zakończenie istniejących przechwytywań (wypełnienie wszystkich buforów, zwrócenie wszystkich wyników ), a następnie ponownie wywołuje ICameraDeviceSession::configureStreams. Spowoduje to zresetowanie sprzętu i potoku aparatu na potrzeby nowego zestawu strumieni wejściowych i wyjściowych. Niektóre strumienie można ponownie wykorzystać z poprzedniej konfiguracji. Platforma kontynuuje działanie od pierwszego żądania przechwytywania do HAL, jeśli pozostanie co najmniej 1 zarejestrowany strumień wyjściowy. (W przeciwnym razie najpierw wymagane jest ICameraDeviceSession::configureStreams.)
• Platforma może wywołać ICameraDeviceSession::close , aby zakończyć sesję aparatu. Można to wywołać w dowolnym momencie, gdy nie są aktywne żadne inne wywołania z platformy, chociaż wywołanie może zostać zablokowane, dopóki nie zostaną ukończone wszystkie przechwytywania w toku (zwrócone wszystkie wyniki, wypełnione wszystkie bufory ). 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 błędem krytycznym 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 komunikatem o błędzie krytycznym.

Rysunek 4. Przebieg działania aparatu.

Poziomy sprzętowe

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

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. Gdy na przykład aktywna jest automatyczna ekspozycja, czas naświetlania, 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	OFF	Brak.
	ON	android.sensor.exposureTime, android.sensor.frameDuration, android.sensor.sensitivity, android.lens.aperture (jeśli obsługiwane) i android.lens.filterDensity (jeśli obsługiwane).
	ON_AUTO_FLASH	Wszystko jest ON, 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	OFF	Brak.
	WHITE_BALANCE_*	android.colorCorrection.transform. Dostosowania specyficzne dla platformy, jeśli android.colorCorrection.mode ma wartość FAST lub HIGH_QUALITY.
android.control.afMode	OFF	Brak
	FOCUS_MODE_*	android.lens.focusDistance
android.control.videoStabilization	OFF	Brak.
	ON	Może dostosować android.scaler.cropRegion, aby zaimplementować stabilizację obrazu.
android.control.mode	OFF	AE, AWB i AF są wyłączone.
	AUTO	Używane są indywidualne ustawienia AE, AWB i AF.
	SCENE_MODE_*	Może 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, a każdy blok ma 3 tryby:

• OFF: ten blok przetwarzania jest wyłączony. Bloków demosaic, korekcji kolorów i dostosowania krzywej tonalnej nie można wyłączyć.
• FAST: w tym trybie blok przetwarzania może nie spowalniać liczby klatek wyjściowych w porównaniu z trybem OFF, ale powinien w przeciwnym razie generować dane wyjściowe o najlepszej jakości, jaką można uzyskać przy tym ograniczeniu. Zwykle jest to używane w trybach podglądu lub nagrywania filmów albo w przypadku robienia zdjęć seryjnych. Na niektórych urządzeniach może to być równoznaczne z trybem OFF (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 (najlepsza jakość nie spowalnia liczby klatek).
• HIGH_QUALITY: w tym trybie blok przetwarzania powinien generować wyniki o najlepszej jakości, w razie potrzeby spowalniając liczbę klatek wyjściowych. Zwykle jest to używane w przypadku robienia zdjęć w wysokiej jakości. Niektóre bloki zawierają sterowanie ręczne, które można opcjonalnie wybrać zamiast 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.

Czynniki te mogą się znacznie różnić w zależności od procesora ISP i czujnika, dlatego 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.
• Każde żądanie może używać dowolnego lub wszystkich aktualnie skonfigurowanych strumieni wyjściowych, dlatego 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ędnione 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.