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

Podsystem HAL

Prośby

Platforma aplikacji wysyła żądania dotyczące zarejestrowanych wyników do podsystemu kamery. Jedno żądanie odpowiada jednemu zestawowi wyników. Żądanie zawiera wszystkie elementy oraz rejestrowaniu i przetwarzaniu tych wyników. Obejmuje to m.in. rozdzielczość i format pikseli. czujnik ręczny, obiektyw i sterowanie lampą błyskową; tryby działania 3A; kontrola przetwarzania RAW na YUV; oraz generowania statystyk. Pozwala to znacznie lepiej kontrolować wyniki wyszukiwania dane wyjściowe i przetwarzanie. Wysyłane może być wiele żądań jednocześnie. nie ogranicza przesyłania próśb. Żądania są zawsze przetwarzane w kolejności ich otrzymania.

Rysunek 1. Model aparatu

HAL i podsystem aparatu

Podsystem kamery obejmuje implementacje jego komponentów w tym algorytm 3A i elementy sterujące przetwarzaniem. HAL aparatu udostępnia interfejsy umożliwiające implementację poszczególnych wersji tych komponentów. Do między różnymi producentami i umożliwiają zachowanie zgodności na wielu platformach. dostawcy usług przetwarzających sygnał obrazu (dostawcy usług internetowych lub czujników w aparacie), system kamery ma charakter wirtualny i nie odpowiada bezpośrednio żadnemu dostawcy usług internetowych. Jednak jest na tyle podobny do rzeczywistych potoków przetwarzania, że można zmapować je na i wydajności sprzętu. Co więcej, jest to wystarczająco abstrakcyjne, by umożliwić algorytmy i kolejności działania bez szkody dla obu jakość, wydajność czy zgodność z różnymi urządzeniami.

Potok kamery obsługuje również aktywatory, które może inicjować platforma aplikacji aby włączyć takie funkcje jak autofokus. Funkcja ta wysyła też powiadomienia z powrotem do działania aplikacji oraz powiadamianie aplikacji o zdarzeniach, takich jak blokada autofokusa czy błędy.

Rysunek 2. Potok kamery

Pamiętaj, że niektóre bloki przetwarzania obrazu pokazane na powyższym diagramie nie są są dobrze zdefiniowane w pierwszej wersji. System kamery generuje te dane: założenia:

Dane wyjściowe plików RAW Bayer nie są przetwarzane w systemie dostawcy usług internetowych.
Statystyki są generowane na podstawie nieprzetworzonych danych z czujnika.
Różne bloki przetwarzania, które konwertują nieprzetworzone dane z czujników na format YUV, znajdują się w w dowolnej kolejności.
Chociaż widocznych jest wiele jednostek skalowania i przycinania, wszystkie jednostki skalowania mają ten sam elementy sterujące regionem wyjścia (zoom cyfrowy). Każda jednostka może mieć jednak inny rozdzielczości wyjściowej i formatu piksela.

Podsumowanie użycia interfejsu API
To jest krótkie podsumowanie czynności, które należy wykonać, aby korzystać z interfejsu Android Camera API. Zobacz Sekcja sekwencji operacji uruchamiania i oczekiwanej operacji ze szczegółowym zestawieniem tych czynności, w tym również wywołań interfejsu API.

Nasłuchiwanie i wyliczanie kamer.
Otwórz urządzenie i połącz detektory.
Skonfiguruj dane wyjściowe w docelowym przypadku użycia (np. przechwytywanie, nagrywanie, itp.).
Utwórz żądania dla docelowego przypadku użycia.
Przechwytywanie/powtarzanie żądań i serii.
Odbieranie metadanych wyników i danych obrazów.
Podczas zmiany przypadków 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 utwórz metadanych wyniku wyjściowego i co najmniej jednego bufora obrazu wyjściowego.
Pierwszeństwo, pierwsze w przypadku żądań i wyników oraz strumieni, do których odwołuje się osoba kolejnych żądań.
Sygnatury czasowe muszą być identyczne w przypadku wszystkich danych wyjściowych danego żądania, tak aby aby w razie potrzeby je ze sobą dopasować.
Cała konfiguracja i stan przechwytywania (z wyjątkiem procedur 3A) to zawarte w żądaniach i wynikach.

Rysunek 3. Omówienie HAL aparatu

Uruchamianie i oczekiwana sekwencja operacji

Ta sekcja zawiera szczegółowe omówienie czynności, których należy się spodziewać przy korzystaniu z funkcji API kamery. Zobacz platforma/sprzęt/interfejsy/kamera/ do interfejsu HIDL definicji.

Wyliczaj, otwieraj urządzenia z kamerami i utwórz aktywną sesję

Po zainicjowaniu platforma zaczyna nasłuchiwać wszystkich obecnych dostawców aparatów, którzy stosują Interfejs ICameraProvider. Jeśli taki usługodawca lub dostawców, platforma spróbuje nawiązać połączenie.
Platforma wylicza aparaty za pomocą ICameraProvider::getCameraIdList()
Platforma tworzy nową instancję ICameraDevice, wywołując odpowiednie ICameraProvider::getCameraDeviceInterface_VX_X()
Platforma wywołuje metodę ICameraDevice::open(), aby utworzyć nowy aktywna sesja przechwytywania ICameraDeviceSession.

Używaj aktywnej sesji kamery

Platforma wywołuje ICameraDeviceSession::configureStreams() z listą strumieni wejściowych/wyjściowych do urządzenia HAL.
Platforma żąda domyślnych ustawień w niektórych przypadkach użycia z atrybutem połączenia z numerem ICameraDeviceSession::constructDefaultRequestSettings(). Może to nastąpić w dowolnym momencie po upływie parametru ICameraDeviceSession autor: ICameraDevice::open.
Platforma tworzy i wysyła pierwsze żądanie przechwytywania do HAL z użyciem parametru ustawień opartych na jednym z zestawów ustawień domyślnych i zawierających co najmniej jedną strumienia wyjściowego, który został wcześniej zarejestrowany przez platformę. Zostanie ono wysłane do HAL z ICameraDeviceSession::processCaptureRequest(). HAL musi zablokować zwrot tego wywołania, dopóki nie będzie gotowy dla następnego wywołania żądania wysłania.
Platforma nadal przesyła żądania ICameraDeviceSession::constructDefaultRequestSettings(), aby otrzymać w razie potrzeby ustawienia domyślne – bufory na potrzeby innych przypadków użycia.
Po rozpoczęciu przechwytywania żądania (czujnik zaczyna rejestrować przechwytywanie), HAL wywołuje ICameraDeviceCallback::notify() z komunikat SHUTTER, w tym numer klatki i sygnatura czasowa rozpoczęcia. narażenia na kontakt. To wywołanie zwrotne powiadomienia nie musi nastąpić przed pierwszym processCaptureResult() wysyła żądanie, ale nie ma wyników jest dostarczana do aplikacji w celu przechwytywania do Nazwa notify() dla tego zapisu jest wywoływana.
Po pewnym czasie opóźnienia potoku HAL zaczyna zwracać ukończone zrzuty do z platformy ICameraDeviceCallback::processCaptureResult(). Są one zwracane w takiej kolejności, w jakiej zostały przesłane. Wiele może być realizowana równocześnie, w zależności od głębokości potoku urządzenia HAL aparatu.

Po pewnym czasie wystąpi jedna z tych sytuacji:

Zasady mogą przestać przesyłać nowe prośby. Poczekaj do dotychczasowych zapisów do zakończenia (wszystkie bufory zostały wypełnione, wszystkie wyniki zwrócony), a następnie wywołaj ICameraDeviceSession::configureStreams() ponownie. Spowoduje to zresetowanie sprzętu i potoku kamery dla nowego zestawu strumienie wejściowe/wyjściowe. Niektóre strumienie można wykorzystać ponownie konfiguracji. Platforma będzie kontynuowana od pierwszego żądania przechwytywania. do HAL, jeśli co najmniej jeden zarejestrowanego strumienia wyjściowego. (W przeciwnym razie ICameraDeviceSession::configureStreams() jest najpierw wymagany).
Platforma może wywoływać metodę ICameraDeviceSession::close() aby zakończyć sesję kamery. Ta funkcja może zostać wywołana w każdej chwili, gdy nie ma innych połączeń z platformy są aktywne, chociaż wywołanie może zostać zablokowane do momentu, zakończone zapisy w trakcie transmisji (wszystkie wyniki zostały zwrócone, wszystkie bufory); ). Po odwróceniu połączenia close() nie będzie już można dzwonić do ICameraDeviceCallback są dozwolone z HAL. Gdy funkcja Trwa wywołanie close(), platforma nie może wywoływać innych funkcji urządzeń HAL.
W przypadku błędu lub innego zdarzenia asynchronicznego kod HAL musi wywołać ICameraDeviceCallback::notify() z odpowiednimi komunikat o błędzie/zdarzeniu. Po powrocie z powiadomienia o krytycznym błędzie dotyczącym całego urządzenia interfejs HAL powinien zachowuj się tak, jakby ktoś go otrzymał od: close(). HAL musi jednak anuluj lub wykonanie wszystkich zaległych sesji przed nawiązaniem połączenia z firmą notify(). Dzięki temu Interfejs notify() jest wywoływany z błędem krytycznym, a platforma nie będzie oddzwanianie z urządzenia. Metody inne niż Aplikacja close() powinna zwrócić -ENODEV lub NULL, gdy metoda notify() zwróci błąd krytyczny .

Rysunek 4. Przebieg działań związanych z kamerą

Poziomy sprzętu

Do aparatów można stosować kilka poziomów sprzętowych w zależności od funkcje zabezpieczeń. Więcej informacji: na poziomie obsługiwanego sprzętu.

Interakcja między żądaniem przechwytywania aplikacji, elementem sterującym 3A i potokiem przetwarzania

W zależności od ustawień w bloku sterującym 3A sieć kamery ignoruje niektóre parametry w żądaniu przechwytywania aplikacji oraz używają wartości dostępne w procedurach sterujących 3A. Jeśli na przykład automatyczna ekspozycja czas ekspozycji, czas trwania klatki i parametry czułości czujniki są kontrolowane przez algorytm platformy 3A, a wszelkie wartości określone przez aplikację są ignorowane. Wartości wybrane dla klatki przez procedury 3A muszą być raportowane w metadanych wyjściowych. W tabeli poniżej opisujemy różne tryby działania funkcji Blok sterujący 3A i właściwości kontrolowane przez te tryby. Zobacz platform/system/media/camera/docs/docs.html, gdzie znajdziesz definicje tych właściwości.

Parametr	Region	Właściwości kontrolowane
Tryb 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ługiwany)
	ON_AUTO_FLASH	Wszystko jest WŁĄCZONE. Dodatkowo android.flash.firingPower, android.flash.firingTime i android.flash.mode
	ON_ALWAYS_FLASH	Taka sama jak ON_AUTO_FLASH
	ON_AUTO_FLASH_RED_EYE	Taka sama jak ON_AUTO_FLASH
Tryb android.control.awbMode	WYŁ.	Brak
	SALDO_WHITE_*	android.colorCorrection.transform. Korekty związane z platformą, jeśli parametr android.colorCorrection.mode ma wartość FAST lub HIGH_QUALITY.
android.control.afMode,	WYŁ.	Brak
	TRYB_FOCUS_*	android.lens.focusOdległość
android.control.videoStabilization,	WYŁ.	Brak
	WŁ.	Może dostosować wartość android.scaler.cropRegion, aby wdrożyć stabilizację wideo
Tryb android.control.mode	WYŁ.	Wyłączono AE, AWB i AF
	AUTOMATYCZNIE	Użyteczne są indywidualne ustawienia AE, AWB i AF
	TRYB_SCENE_*	Może zastąpić wszystkie wymienione powyżej parametry. Poszczególne ustawienia 3A są wyłączone.

Elementy sterujące w bloku przetwarzania obrazu na rys. 2 są tę samą zasadę i każdy blok ma trzy tryby:

WYŁĄCZONE: ta blokada przetwarzania jest wyłączona. Funkcje demonstracyjne, korekcja kolorów bloków dostosowania krzywej tonu nie można wyłączyć.
SZYBKA: w tym trybie blok przetwarzania nie może spowalniać klatki wyjściowej. w porównaniu do trybu WYŁĄCZONEGO, ale poza tym powinna dać na wyjściu, jaki może mieć to ograniczenie. Jest to zwykle używane do podglądów i nagrywania filmów, jak i seria zdjęć. Niektóre urządzeń, może to być równoważne trybowi WYŁĄCZONE (nie można przetwarzać bez spowolnienie liczby klatek). Na niektórych urządzeniach może to być równoważne tryb HIGH_QUALITY (najlepsza jakość nadal nie spowalnia liczby klatek).
HIGH_QUALITY: w tym trybie blok przetwarzania powinien generować najlepsze w celu uzyskania najlepszej jakości, zmniejszając w razie potrzeby wyjściowe liczby klatek na sekundę. Ta metoda jest zwykle używana do zdjęć o wysokiej jakości. Niektóre bloki zawiera element sterujący, który można wybrać opcjonalnie zamiast metody FAST lub HIGH_QUALITY. Na przykład blok korekcji kolorów obsługuje kolor, matryca przekształcania, a dostosowanie krzywej tona obsługuje dowolny krzywą mapowania tonalnego.

Maksymalna liczba klatek, jaką może obsługiwać podsystem kamery, to funkcja wiele czynników:

Żądane rozdzielczości wyjściowego strumienia obrazów
Dostępność trybów tworzenia/pomijania w narzędziu do tworzenia obrazów
Przepustowość interfejsu narzędzia do tworzenia obrazów
Przepustowość różnych bloków przetwarzania danych dostawców usług internetowych

Te czynniki mogą się znacznie różnić w zależności od dostawcy usług internetowych i czujników, interfejs HAL kamery stara się przedstawić ograniczenia przepustowości w z jak największym modelem atrybucji. Prezentowany model ma następujące cechy:

Czujnik obrazu jest zawsze skonfigurowany tak, aby wysyłał obraz w najmniejszej rozdzielczości to możliwe przy wybranych przez aplikację rozmiarach strumienia wyjściowego. Najmniejszy rozdzielczość jest definiowana jako co najmniej tak duża, jak największa żądana rozmiaru strumienia wyjściowego.
Każde żądanie może korzystać z dowolnych lub wszystkich obecnie skonfigurowanych strumieni wyjściowych, Należy skonfigurować czujnik i dostawcę usług internetowych pod kątem obsługi skalowania we wszystkich transmisjach jednocześnie.
Strumienie JPEG działają jak przetworzone strumienie YUV w przypadku żądań, w przypadku których są nie uwzględniono; w żądaniach, w których są wskazywane bezpośrednio, działają jako strumienie JPEG,
Procesor JPEG może działać równolegle z pozostałą częścią kamery, ale nie może przetworzyć więcej niż jednego zapisu naraz.