Podsystem HAL

Prośby

Platforma aplikacji wysyła do podsystemu aparatu żądania dotyczące zarejestrowanych wyników. Jedno żądanie odpowiada jednemu zestawowi wyników. Żądanie zawiera wszystkie informacje o konfiguracji dotyczące rejestrowania 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. Dzięki temu masz większą kontrolę nad wynikami i ich przetwarzaniem. Można wysyłać wiele żądań jednocześnie, 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. Warstwa HAL aparatu udostępnia interfejsy, które umożliwiają implementację własnych wersji tych komponentów. Aby zachować zgodność międzyplatformową między wieloma 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. Jest on też wystarczająco abstrakcyjny, aby umożliwić stosowanie wielu różnych algorytmów i kolejności operacji bez pogarszania jakości, wydajności ani zgodności z różnymi urządzeniami.

Potok kamery obsługuje też wyzwalacze, które mogą być inicjowane przez platformę aplikacji, aby włączać takie funkcje jak automatyczne ustawianie ostrości. Wysyła też powiadomienia z powrotem do platformy aplikacji, informując aplikacje o zdarzeniach takich jak blokada automatycznego ustawiania ostrości czy błędy.

Rysunek 2. Potok kamery

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

• Dane wyjściowe RAW Bayer nie są przetwarzane w ISP.
• Statystyki są generowane na podstawie surowych danych z czujników.
• Poszczególne bloki przetwarzania, które przekształcają nieprzetworzone dane z czujnika na format YUV, są ułożone w dowolnej kolejności.
• Chociaż wyświetlanych jest 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
Krótkie podsumowanie kroków korzystania z interfejsu API aparatu na Androidzie. Szczegółowy opis tych kroków, w tym wywołań interfejsu API, znajdziesz w sekcji Uruchamianie i oczekiwana sekwencja operacji.

1. Nasłuchiwanie i wyliczanie urządzeń z kamerą.
2. Otwórz urządzenie i połącz słuchawki.
3. Skonfiguruj dane wyjściowe dla docelowego przypadku użycia (np. przechwytywanie obrazu, nagrywanie itp.).
4. Utwórz prośby dotyczące docelowego przypadku użycia.
5. Rejestrowanie i powtarzanie żądań oraz serii.
6. Otrzymywanie metadanych wyników i danych obrazu.
7. Gdy zmienisz przypadek użycia, wróć do kroku 3.

Podsumowanie operacji HAL

• Żądania asynchroniczne dotyczące przechwytywania pochodzą z platformy.
• Urządzenie HAL musi przetwarzać żądania w kolejności. W przypadku każdego żądania generuj metadane wyniku wyjściowego i co najmniej 1 bufor obrazu wyjściowego.
• Kolejność obsługi żądań i wyników oraz strumieni, do których odwołują się kolejne żądania, jest zgodna z zasadą „pierwsze przyszło, pierwsze wyszło”.
• Sygnatury czasowe muszą być identyczne we wszystkich wynikach danego żądania, aby w razie potrzeby można było je dopasować.
• Wszystkie konfiguracje i stany przechwytywania (z wyjątkiem procedur 3A) są zawarte w żądaniach i wynikach.

Rysunek 3. Omówienie HAL aparatu

Sekwencja uruchamiania i oczekiwane działanie

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

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

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

Korzystanie z aktywnej sesji kamery

1. Framework wywołuje funkcję ICameraDeviceSession::configureStreams() z listą strumieni wejściowych/wyjściowych do urządzenia HAL.
2. W przypadku niektórych zastosowań platforma wysyła żądania ustawień domyślnych za pomocą wywołań funkcji ICameraDeviceSession::constructDefaultRequestSettings(). Może się to zdarzyć w dowolnym momencie po utworzeniu ICameraDeviceSession przez ICameraDevice::open.
3. Framework tworzy i wysyła pierwsze żądanie przechwytywania do HAL z ustawieniami opartymi na jednym z zestawów ustawień domyślnych oraz z co najmniej jednym strumieniem wyjściowym, który został wcześniej zarejestrowany przez framework. Jest on wysyłany do HAL z wartością ICameraDeviceSession::processCaptureRequest(). HAL musi blokować powrót tego połączenia, dopóki nie będzie gotowy na wysłanie kolejnej prośby.
4. Platforma nadal przesyła żądania i wywołania ICameraDeviceSession::constructDefaultRequestSettings(), aby w razie potrzeby pobierać bufory ustawień domyślnych w innych przypadkach użycia.
5. Gdy rozpoczyna się rejestrowanie żądania (czujnik zaczyna naświetlać obraz), HAL wywołuje funkcję ICameraDeviceCallback::notify() z komunikatem SHUTTER, który zawiera numer klatki i sygnaturę czasową rozpoczęcia ekspozycji. To wywołanie zwrotne powiadomienia nie musi nastąpić przed pierwszym wywołaniem processCaptureResult() w przypadku żądania, ale do aplikacji nie są dostarczane żadne wyniki przechwytywania, dopóki nie zostanie wywołana funkcja notify() dla tego przechwytywania.
6. Po pewnym opóźnieniu potoku HAL zaczyna zwracać do platformy ukończone przechwytywanie z 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że być jednocześnie w toku kilka żądań.

Po pewnym czasie nastąpi jedna z tych sytuacji:

• Framework może przestać przesyłać nowe żądania, poczekać na zakończenie istniejących przechwytywań (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 w celu uzyskania nowego zestawu strumieni wejściowych/wyjściowych. Niektóre strumienie mogą być ponownie używane z poprzedniej konfiguracji. Następnie framework kontynuuje od pierwszego żądania przechwytywania do HAL, jeśli pozostanie co najmniej 1 zarejestrowany strumień wyjściowy. (W przeciwnym razie najpierw wymagany jest ICameraDeviceSession::configureStreams()).
• Platforma może wywołać metodę ICameraDeviceSession::close(), aby zakończyć sesję kamery. Można ją wywołać w dowolnym momencie, gdy nie są aktywne żadne inne wywołania z ram. Wywołanie może jednak zostać zablokowane do czasu zakończenia wszystkich przechwytywań w toku (zwrócenia wszystkich wyników i wypełnienia wszystkich buforów). Po powrocie wywołania close() z HAL nie można już wywoływać funkcji ICameraDeviceCallback. Gdy close()połączenie jest w toku, platforma może nie wywoływać żadnych innych funkcji urządzenia HAL.
• W przypadku błędu lub innego zdarzenia asynchronicznego HAL musi wywołać funkcję ICameraDeviceCallback::notify() z odpowiednim komunikatem o błędzie lub zdarzeniu. Po powrocie z powiadomienia o błędzie krytycznym na poziomie urządzenia HAL powinien zachowywać się tak, jakby wywołano na nim funkcję close(). Jednak HAL musi anulować lub zakończyć wszystkie oczekujące przechwytywania przed wywołaniem funkcji notify(), aby po wywołaniu funkcji 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 tym, jak metoda notify() zwróci komunikat o błędzie krytycznym.

Rysunek 4. Procedura działania kamery

Poziomy sprzętu

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 sekcji 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 zamiast nich używa wartości podanych przez procedury sterowania 3A. Na przykład gdy automatyczna ekspozycja jest aktywna, czas ekspozycji, czas trwania klatki i parametry czułości 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ć podane w metadanych wyjściowych. W poniższej tabeli opisano różne tryby bloku sterowania 3A i właściwości, które są przez nie kontrolowane. Definicje tych właściwości znajdziesz w pliku platform/system/media/camera/docs/docs.html.

Parametr	Województwo	Właściwości kontrolowane
android.control.aeMode	WYŁ.	Brak
	WŁ.	android.sensor.exposureTime android.sensor.frameDuration android.sensor.sensitivity android.lens.aperture (if supported) android.lens.filterDensity (if supported)
	ON_AUTO_FLASH	Wszystko jest WŁĄCZONE, a także 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 ma wartość FAST lub HIGH_QUALITY.
android.control.afMode	WYŁ.	Brak
	FOCUS_MODE_*	android.lens.focusDistance
android.control.videoStabilization	WYŁ.	Brak
	WŁ.	Możliwość dostosowania parametru android.scaler.cropRegion w celu wdrożenia stabilizacji wideo
android.control.mode	WYŁ.	AE, AWB i AF są wyłączone
	AUTO	Używane są indywidualne ustawienia AE, AWB i AF.
	SCENE_MODE_*	Może zastępować wszystkie wymienione wyżej parametry. Poszczególne elementy sterujące 3A są wyłączone.

Elementy sterujące w bloku Przetwarzanie 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 dostosowywania krzywej tonalnej nie można wyłączyć.
• SZYBKI: w tym trybie blok przetwarzania nie może spowalniać liczby klatek wyjściowych w porównaniu z trybem WYŁ., ale powinien generować wyjście o najwyższej możliwej jakości przy tym ograniczeniu. Zwykle jest on używany w trybach podglądu lub nagrywania filmów albo w trybie zdjęć seryjnych. Na niektórych urządzeniach może to być odpowiednik trybu WYŁĄCZONY (bez przetwarzania, które mogłoby spowolnić liczbę klatek na sekundę), a na innych – trybu WYSOKA JAKOŚĆ (najwyższa jakość nie spowalnia liczby klatek na sekundę).
• HIGH_QUALITY: w tym trybie blok przetwarzania powinien generować wynik o najwyższej możliwej jakości, w razie potrzeby zmniejszając liczbę klatek wyjściowych na sekundę. Zwykle jest to używane do robienia zdjęć wysokiej jakości. Niektóre bloki zawierają opcję sterowania ręcznego, którą można opcjonalnie wybrać zamiast opcji FAST lub HIGH_QUALITY. Na przykład blok korekcji kolorów obsługuje macierz transformacji kolorów, a korekta krzywej tonalnej obsługuje dowolną globalną krzywą mapowania tonalnego.

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

• Żądane rozdzielczości strumieni obrazu wyjściowego
• Dostępność trybów łączenia pikseli i pomijania na matrycy
• przepustowość interfejsu kamery,
• przepustowość poszczególnych bloków przetwarzania ISP,

Ponieważ te czynniki mogą się znacznie różnić w zależności od dostawców internetu i sensorów, interfejs HAL aparatu próbuje uprościć ograniczenia przepustowości do jak najprostszego modelu. Prezentowany model ma te cechy:

• Sensor obrazu jest zawsze skonfigurowany tak, aby generować najmniejszą możliwą rozdzielczość w odniesieniu do rozmiarów strumieni wyjściowych żądanych przez aplikację. Najmniejsza rozdzielczość jest co najmniej tak duża jak największy żądany rozmiar strumienia wyjściowego.
• Ponieważ każde żądanie może korzystać z dowolnego lub wszystkich skonfigurowanych obecnie strumieni wyjściowych, czujnik i procesor sygnałowy obrazu 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ą 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 pozostałą częścią potoku aparatu, ale nie może przetwarzać więcej niż 1 zdjęcia naraz.