Ta strona została przetłumaczona przez Cloud Translation API.

Podsystem HAL

Prośby

Platforma aplikacji wysyła do podsystemu aparatu żądania zarejestrowania 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. Umożliwia to 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, czyli czujników aparatu), model ścieżki przetwarzania obrazu 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 też na tyle abstrakcyjna, że umożliwia stosowanie różnych algorytmów i różnych kolejności działania 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 w celu włączenia takich funkcji jak autofokus. Wysyła też powiadomienia do frameworku aplikacji, informując je o zdarzeniach takich jak blokada autofokusu lub 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. Proces przetwarzania obrazu z kamery zakłada:

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.

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

Podsumowanie operacji 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) dotyczy żą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ę działania

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

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.
Platforma wylicza urządzenia z kamerą za pomocą funkcjiICameraProvider::getCameraIdList().
Framework tworzy instancję nowej klasy ICameraDevice, wywołując odpowiednią metodę ICameraProvider::getCameraDeviceInterface_VX_X().
Framework wywołuje funkcję ICameraDevice::open(), aby utworzyć nową sesję aktywnego przechwytywania ICameraDeviceSession.

Korzystanie z aktywnej sesji kamery

Framework wywołuje funkcję ICameraDeviceSession::configureStreams() z listą strumieni wejścia/wyjścia do urządzenia HAL.
W przypadku niektórych zastosowań framework prosi o ustawienia domyślne w wywołaniach do funkcji ICameraDeviceSession::constructDefaultRequestSettings(). Może się to zdarzyć w dowolnym momencie po utworzeniu ICameraDeviceSession przez ICameraDevice::open.
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 wartością ICameraDeviceSession::processCaptureRequest(). HAL musi zablokować powrót tego wywołania, dopóki nie będzie gotowy do wysłania następnego żądania.
Platforma nadal przesyła żądania i wywołania do ICameraDeviceSession::constructDefaultRequestSettings(), aby uzyskać domyślne bufory ustawień na potrzeby innych zastosowań.
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 na potrzeby przechwytywania, dopóki nie zostanie wywołana funkcja notify() dla tego przechwytywania.
Po pewnym opóźnieniu w pipeline HAL zaczyna zwracać wykonane 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 urządzenia 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 potem 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 wymagana jest najpierw opcja 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ć funkcję ICameraDeviceCallback::notify() z odpowiednim komunikatem o błędzie lub zdarzeniu. Po powrocie z powiadomienia o błędzie krytycznym na całym urządzeniu interfejs HAL powinien zachowywać się tak, jakby wywołano funkcję close(). Jednak przed wywołaniem funkcji notify() interfejs HAL musi anulować lub zakończyć wszystkie niewykonane jeszcze przechwycenia, aby po wywołaniu funkcji notify() z błędem krytycznym interfejs nie 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

Urządzenia z kamerą mogą mieć różne poziomy sprzętu w zależności od ich 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 w kamerze 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 wartości określone przez aplikację są ignorowane. Wartości wybrane dla ramki przez procedury 3A muszą być podane 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	Region	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ługiwane) android.lens.filterDensity (jeśli jest obsługiwane)
	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.
	AUTOMATYCZNIE	Używane są indywidualne ustawienia AE, AWB i AF.
	SCENE_MODE_*	Może zastąpić wszystkie parametry wymienione powyżej. Poszczególne elementy 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: ten blok przetwarzania jest wyłączony. Bloki demozaikacji, korekcji kolorów i regulacji krzywej tonów nie mogą być wyłączone.
FAST: w tym trybie blok przetwarzania może nie spowolnić szybkości generowania klatek w porównaniu z trybem OFF, ale powinien zapewnić jak 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ą opcjonalną opcję sterowania ręcznego, która może być wybrana 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ę obsługiwana przez podsystem aparatu zależy od wielu czynników:

Wymagane rozdzielczości strumieni danych wyjściowych
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 przechwytywania 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 ujęcia naraz.