Podsystem HAL

Prośby

Platforma aplikacji wysyła do podsystemu aparatu żądania zarejestrowanych wyników. Jedno żądanie odpowiada jednemu zbiorowi 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ęczna kontrola czujnika, obiektywu i lampy błyskowej, tryby działania 3A, przetwarzanie RAW na YUV oraz generowanie statystyk. Dzięki temu masz znacznie większą kontrolę nad przetwarzaniem i wyświetlaniem wyników. Wiele żądań może być wysyłanych jednocześnie, a przesyłanie próśb nie blokuje przetwarzania. Zgłoszenia są zawsze przetwarzane w kolejności ich otrzymania.

Rysunek 1. Model aparatu

Interfejs HAL i podsystem aparatu

Podsystem kamery obejmuje implementacje komponentów w przepływie danych kamery, takie jak algorytm 3A i sterowanie przetwarzaniem. Biblioteka HAL aparatu udostępnia interfejsy, które umożliwiają implementację wersji tych komponentów. Aby zapewnić zgodność między platformami dla wielu producentów urządzeń i dostawców procesorów sygnału obrazu (ISP lub czujników aparatu), model przepływu danych w aparacie jest wirtualny i nie odpowiada bezpośrednio żadnemu rzeczywistemu procesorowi ISP. Jest on jednak wystarczająco podobny do prawdziwych strumieni przetwarzania, aby można było go efektywnie mapować na sprzęt. Jest ona na tyle abstrakcyjna, że umożliwia stosowanie różnych algorytmów i różnych kolejności operacji bez uszczerbku na jakości, wydajności czy kompatybilności z różnymi urządzeniami.

System przetwarzania obrazu obsługuje też wyzwalacze, które mogą być inicjowane przez platformę aplikacji, aby włączyć takie funkcje jak autofokus. Wysyła też powiadomienia do frameworku aplikacji, powiadamiąc je o zdarzeniach takich jak blokada autofokusu czy błędy.

Rysunek 2. Proces przetwarzania obrazu

Pamiętaj, że niektóre bloki przetwarzania obrazu widoczne na diagramie powyżej nie są dobrze zdefiniowane w pierwszej wersji. System przetwarzania obrazu z kamery zakłada, że:

• Dane wyjściowe RAW Bayer nie są przetwarzane w ISP.
• Statystyki są generowane na podstawie nieprzetworzonych danych z czujników.
• Różne bloki przetwarzania, które konwertują nieprzetworzone dane z czujnika na YUV, są w dowolnej kolejności.
• Podczas wyświetlania wielu jednostek skalowania i przycinania wszystkie jednostki skalowania mają te same elementy sterujące regionem wyjściowym (cyfrowy zoom). 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, które należy wykonać, aby korzystać z interfejsu API aparatu w Androidzie. Szczegółowe omówienie tych kroków, w tym wywołań interfejsu API, znajdziesz w sekcji dotyczącej sekwencji uruchamiania i oczekiwanego działania.

1. Wysłuchiwanie i wyliczanie urządzeń kamery.
2. Otwórz urządzenie i połącz słuchaczy.
3. Skonfiguruj wyjścia na potrzeby docelowego zastosowania (np. na potrzeby przechwytywania obrazu, nagrywania itp.).
4. Utwórz żądania dla docelowego przypadku użycia.
5. Przechwytywanie/powtarzanie żądań i przerwy.
6. Odbieranie metadanych wyników i danych obrazu.
7. Aby zmienić przypadki użycia, wróć do kroku 3.

Podsumowanie działania HAL

• Asynchroniczne żądania dotyczące przechwytywania pochodzą z ramy.
• Urządzenie HAL musi przetwarzać żądania w kolejności. Dla każdej prośby wygeneruj metadane wyjściowe i co najmniej 1 bufor wyjściowy obrazu.
• Zasada „first-in, first-out” (pierwszy na wejściu, pierwszy na wyjściu) w przypadku żądań i wyników oraz strumieni, do których odwołują się kolejne żądania.
• Czasy stempla muszą być identyczne we wszystkich danych wyjściowych danego żądania, aby platforma mogła je w razie potrzeby dopasować.
• Cała konfiguracja i stan rejestrowania (z wyjątkiem rutyn 3A) są zaszyfrowane w żądaniach i wynikach.

Rysunek 3. Omówienie interfejsu HAL aparatu

Uruchomienie i oczekiwaną sekwencję operacji

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  platform/hardware/interfaces/camera/.

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

1. Po uruchomieniu framework zaczyna nasłuchiwać obecnych dostawców kamer, którzy implementują interfejs ICameraProvider. Jeśli taki dostawca jest dostępny, platforma spróbuje nawiązać połączenie.
2. Platforma wylicza urządzenia z kamerą za pomocą funkcjiICameraProvider::getCameraIdList().
3. Platforma tworzy instancję nowej klasy ICameraDevice, wywołując odpowiednią metodę ICameraProvider::getCameraDeviceInterface_VX_X().
4. Framework wywołuje funkcję ICameraDevice::open(), aby utworzyć nową sesję aktywnego przechwytywania ICameraDeviceSession.

Korzystanie z aktywnej sesji kamery

1. Framework wywołuje funkcję ICameraDeviceSession::configureStreams() z listą strumieni wejścia/wyjścia do urządzenia HAL.
2. Framework prosi o ustawienia domyślne w przypadku niektórych zastosowań z wywołaniami do ICameraDeviceSession::constructDefaultRequestSettings(). Może się to zdarzyć w dowolnym momencie po utworzeniu ICameraDeviceSession przez ICameraDevice::open.
3. Framework tworzy i wysyła pierwsze żądanie przechwycenia do HAL z ustawieniami opartymi na jednym z zestawów ustawień domyślnych oraz co najmniej 1 strumieniem wyjściowym zarejestrowanym wcześniej przez framework. Jest on wysyłany do HAL z ICameraDeviceSession::processCaptureRequest(). HAL musi zablokować powrót tego wywołania, dopóki nie będzie gotowy do wysłania następnego żądania.
4. Platforma nadal przesyła żądania i wywołania do ICameraDeviceSession::constructDefaultRequestSettings(), aby pobierać domyślne bufory ustawień na potrzeby innych zastosowań.
5. Gdy rozpoczyna się przechwytywanie żądania (czujnik zaczyna naświetlać obraz), HAL wywołuje funkcję ICameraDeviceCallback::notify() z wiadomością SHUTTER, która zawiera numer klatki i znak czasu rozpoczęcia naświetlania. Ten wywołanie zwrotne notify nie musi nastąpić przed pierwszym wywołaniem funkcji processCaptureResult() dla żądania, ale żadne wyniki nie są dostarczane do aplikacji dotyczącej rejestrowania, dopóki nie zostanie wywołana funkcja notify() dla danego rejestrowania.
6. Po pewnym opóźnieniu w pipeline HAL zaczyna zwracać zakończone przechwycenia do frameworku za pomocą ICameraDeviceCallback::processCaptureResult(). Są one zwracane w tej samej kolejności, w jakiej zostały przesłane. W zależności od głębokości potoku danych w urządzeniu HAL aparatu może być wysyłanych jednocześnie wiele żądań.

Po pewnym czasie nastąpi jedno z tych działań:

• Framework może przestać przesyłać nowe żądania, zaczekać, aż obecne przechwycenia zostaną zakończone (wszystkie bufory wypełnione, wszystkie wyniki zwrócone), a następnie ponownie wywołać funkcję ICameraDeviceSession::configureStreams(). Spowoduje to zresetowanie sprzętu i potoku przetwarzania kamery pod kątem nowego zestawu strumieni wejścia/wyjścia. Niektóre strumienie mogą zostać użyte ponownie z poprzedniej konfiguracji. Jeśli pozostaje co najmniej 1 zarejestrowany strumień wyjściowy, framework kontynuuje działanie od pierwszego żądania przechwycenia do HAL. (w przeciwnym razie wymagane jest najpierw wypełnienie pola ICameraDeviceSession::configureStreams()).
• Framework może wywołać funkcję ICameraDeviceSession::close(), aby zakończyć sesję kamery. Możesz je wywołać w dowolnym momencie, gdy nie ma aktywnych innych wywołań z ramy, ale wywołanie może być zablokowane, dopóki nie zostaną zakończone wszystkie przechwytywania w trakcie (zwrócone wszystkie wyniki, wypełnione wszystkie bufory). Po zakończeniu wywołania close() HAL nie może już wywoływać metody ICameraDeviceCallback. Gdy wywołanie close() jest w toku, framework może nie 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/zdarzeniu. Po powrocie z powiadomienia o błędzie krytycznym na całym urządzeniu interfejs HAL powinien działać tak, jakby wywołano metodę close(). Jednak przed wywołaniem notify() interfejs HAL musi anulować lub zakończyć wszystkie niewykonane jeszcze przechwyty. Gdy wywołanie notify() zakończy się fatalnym błędem, framework nie będzie otrzymywać dalszych wywołań zwrotnych od urządzenia. Metody inne niż close() powinny zwracać -ENODEV lub NULL po zwróceniu przez metodę notify() krytycznego komunikatu o błędzie.

Rysunek 4. Procedura obsługi kamery

Poziomy sprzętowe

Aparaty mogą mieć różne poziomy sprzętu w zależności od możliwości. Więcej informacji znajdziesz w  artykule na temat obsługiwanego sprzętu.

Interakcja między żądaniem przechwycenia aplikacji, elementem sterującym 3A a przetwarzaniem

W zależności od ustawień w bloku sterowania 3A, przepływ danych z kamery ignoruje niektóre parametry w żądaniu rejestrowania 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 ramki przez procedury 3A muszą zostać zgłoszone 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	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 (jeśli jest obsługiwana) android.lens.filterDensity (jeśli jest obsługiwana)
	ON_AUTO_FLASH	Wszystko jest włączone, a dodatkowo android.flash.firingPower, android.flash.firingTime i android.flash.mode.
	ON_ALWAYS_FLASH	To samo co ON_AUTO_FLASH
	ON_AUTO_FLASH_RED_EYE	To samo co ON_AUTO_FLASH
android.control.awbMode	WYŁ.	Brak
	WHITE_BALANCE_*	android.colorCorrection.transform. korekty dla poszczególnych platform, 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Ł.	Umożliwia dostosowanie android.scaler.cropRegion w celu zaimplementowania 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ąpić wszystkie parametry wymienione powyżej. Elementy sterujące 3A są wyłączone.

Elementy sterujące w bloku przetwarzania obrazu na rysunku 2 działają według podobnej zasady. Ogólnie każdy blok ma 3 tryby:

• WYŁĄCZONO: ta blokada przetwarzania jest wyłączona. Bloki demozaikacji, korekcji kolorów i regulacji krzywej tonów nie mogą być wyłączone.
• FAST: w tym trybie blokowanie przetwarzania może nie spowolnić szybkości generowania klatek w porównaniu z trybem OFF, ale powinno zapewnić najlepszą jakość wyjściową, jaką można uzyskać przy danej blokadzie. Zwykle jest to używane w trybach podglądu lub nagrywania filmów albo w trybie seryjnego robienia zdjęć. Na niektórych urządzeniach może to być równoznaczne z trybem OFF (nie można przeprowadzić żadnego przetwarzania bez spowolnienia szybkości klatek), a na innych może to być równoznaczne z trybem HIGH_QUALITY (najwyższa jakość nie powoduje spowolnienia szybkości klatek).
• HIGH_QUALITY: w tym trybie blok przetwarzania powinien zapewnić najlepszą jakość, w razie potrzeby spowalniając liczbę klatek na wyjściu. Zwykle jest to używane do robienia zdjęć o wysokiej jakości. Niektóre bloki zawierają ręczne sterowanie, które można opcjonalnie wybrać zamiast FAST lub HIGH_QUALITY. Na przykład blok korekcji kolorów obsługuje matrycę transformacji kolorów, a dostosowanie krzywej tonów obsługuje dowolną globalną krzywą mapowania tonów.

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

• Wymagane rozdzielczości strumieni danych wyjściowych z obrazami
• Dostępność trybów binningu/pomijania w skanerze
• Przepustowość interfejsu imagera
• Przepustowość różnych bloków przetwarzania dostawcy usług internetowych

Ponieważ te czynniki mogą się znacznie różnić w zależności od dostawcy usług internetowych i czujników, interfejs HAL aparatu próbuje zastąpić ograniczenia przepustowości jak najprostszym modelem. Prezentowany model ma te cechy:

• Czujnik obrazu jest zawsze konfigurowany tak, aby generować dane wyjściowe o najmniejszej możliwej rozdzielczości, biorąc pod uwagę żądane rozmiary strumienia wyjściowego aplikacji. Najmniejsza rozdzielczość jest zdefiniowana jako co najmniej tak duża jak największy żądany rozmiar strumienia wyjściowego.
• Ponieważ każde żądanie może używać dowolnego lub wszystkich skonfigurowanych strumieni wyjściowych, czujnik i dostawca usług internetowych muszą być skonfigurowane tak, aby obsługiwać skalowanie pojedynczego przechwycenia do wszystkich strumieni jednocześnie.
• W przypadku żądań, w których nie są one uwzględnione, strumienie JPEG działają jak przetworzone strumienie YUV. W żądaniach, w których są one bezpośrednio wywoływane, działają jak strumienie JPEG.
• Procesor JPEG może działać równolegle z resztą łańcucha przetwarzania w aparacie, ale nie może przetwarzać więcej niż 1 obrazu naraz.