HAL 하위 시스템

요청

앱 프레임워크는 캡처된 결과에 관한 요청을 카메라 하위 시스템으로 보냅니다. 하나의 요청은 하나의 결과 집합에 해당합니다. 요청은 이러한 결과의 캡처 및 처리에 관한 모든 구성 정보를 캡슐화합니다. 여기에는 해상도 및 픽셀 형식, 수동 센서/렌즈/플래시 제어, 3A 작동 모드, RAW를 YUV로 변환하는 처리 제어, 통계 생성 등이 포함됩니다. 따라서 결과의 출력과 처리에 관한 제어 기능이 향상됩니다. 다수의 요청을 한 번에 진행할 수 있으며 요청 제출은 차단되지 않습니다. 요청은 항상 수신된 순서대로 처리됩니다.

그림 1. 카메라 모델

HAL 및 카메라 하위 시스템

카메라 하위 시스템에는 3A 알고리즘 및 처리 제어와 같은 카메라 파이프라인 구성요소의 구현이 포함됩니다. 카메라 HAL에서는 이러한 구성요소의 버전을 구현할 수 있는 인터페이스를 제공합니다. 여러 기기 제조업체와 ISP(이미지 신호 프로세서 또는 카메라 센서) 공급업체 간의 크로스 플랫폼 호환성을 유지하기 위해 카메라 파이프라인 모델은 가상이며 실제 ISP에 직접 대응하지 않습니다. 그러나 이는 실제 처리 파이프라인과 유사하기 때문에 하드웨어에 효율적으로 매핑될 수 있습니다. 또한 품질, 효율성 또는 교차 기기 호환성을 손상하지 않으면서 알고리즘과 작업 순서를 다양하게 적용할 수 있을 정도로 추상적입니다.

카메라 파이프라인은 앱 프레임워크가 자동 초점과 같은 기능을 켤 수 있도록 하는 트리거도 지원합니다. 또한 앱 프레임워크로 알림을 다시 보내 자동 초점 잠금 또는 오류와 같은 이벤트를 앱에 알립니다.

그림 2. 카메라 파이프라인

위의 다이어그램에 표시된 일부 이미지 처리 블록은 초기 버전에 잘 정의되어 있지 않습니다. 카메라 파이프라인에서는 다음과 같이 가정합니다.

RAW Bayer 출력은 ISP 내부 처리가 없습니다.
통계는 원시 센서 데이터를 기반으로 생성됩니다.
원시 센서 데이터를 YUV로 변환하는 다양한 처리 블록에는 임의의 순서가 적용됩니다.
여러 비율 및 자르기 단위가 표시되는 동안 모든 스케일러 단위는 출력 영역 제어(디지털 줌)를 공유합니다. 그러나 각 단위는 출력 해상도와 픽셀 형식이 다를 수도 있습니다.

API 사용 요약
Android 카메라 API를 사용하는 단계에 관한 간략한 요약입니다. 단계(API 호출 등)에 관한 자세한 내용은 시작 및 예상 작업 순서 섹션을 참고하세요.

카메라 기기를 수신 대기하고 열거합니다.
기기를 열고 리스너를 연결합니다.
대상 사용 사례의 출력을 구성합니다(스틸 캡처, 녹화 등).
대상 사용 사례에 관한 요청을 생성합니다.
요청 및 버스트를 캡처하고 반복합니다.
결과 메타데이터와 이미지 데이터를 수신합니다.
사용 사례를 전환할 때 3단계로 돌아갑니다.

HAL 작업 요약

캡처에 관한 비동기식 요청은 프레임워크에서 발생합니다.
HAL 기기는 요청을 순서대로 처리해야 합니다. 또한 요청마다 출력 결과 메타데이터와 하나 이상의 출력 이미지 버퍼를 생성합니다.
요청 및 결과를 비롯해 후속 요청에서 참조한 스트림의 경우 선입 선출이 적용됩니다.
특정 요청의 모든 출력에 관한 타임스탬프가 동일해야 프레임워크가 필요에 따라 타임스탬프를 일치시킬 수 있습니다.
모든 캡처 구성 및 상태(3A 루틴 제외)는 요청 및 결과에 캡슐화됩니다.

그림 3. 카메라 HAL 개요

시작 및 예상 작업 순서

이 섹션에는 카메라 API 사용 시 예상되는 단계에 관한 자세한 설명이 포함되어 있습니다. HIDL 인터페이스 정의는 platform/hardware/interfaces/camera/를 참고하세요.

카메라 기기 열거 및 열기, 활성 세션 생성하기

초기화 후에 프레임워크는 ICameraProvider 인터페이스를 구현하는 현재 카메라 제공자를 수신 대기합니다. 이러한 제공자가 있는 경우 프레임워크는 연결을 설정하려고 시도합니다.
프레임워크는 ICameraProvider::getCameraIdList()를 통해 카메라 기기를 열거합니다.
프레임워크는 ICameraProvider::getCameraDeviceInterface_VX_X() 각각을 호출하여 새로운 ICameraDevice를 인스턴스화합니다.
프레임워크는 ICameraDevice::open()을 호출하여 새로운 활성 캡처 세션 ICameraDeviceSession을 만듭니다.

활성 카메라 세션 사용

프레임워크는 입력/출력 스트림 목록이 있는 ICameraDeviceSession::configureStreams()를 HAL 기기로 호출합니다.
프레임워크는 ICameraDeviceSession::constructDefaultRequestSettings() 호출을 통해 일부 사용 사례의 기본 설정을 요청합니다. 이는 ICameraDevice::open에서 ICameraDeviceSession을 생성한 이후 어느 때나 발생할 수 있습니다.
프레임워크는 기본 설정 집합 중 하나를 기반으로 하는 설정과 프레임워크에서 이전에 등록한 1개 이상의 출력 스트림을 통해 첫 번째 캡처 요청을 구성하고 HAL에 전송합니다. 요청은 ICameraDeviceSession::processCaptureRequest()와 함께 HAL로 전송됩니다. HAL은 다음 요청을 전송할 준비가 될 때까지 이 호출의 반환을 차단해야 합니다.
프레임워크는 필요 시 다른 사용 사례의 기본 설정 버퍼를 가져오기 위해 ICameraDeviceSession::constructDefaultRequestSettings() 요청 및 호출을 계속 제출합니다.
요청의 캡처가 시작되면(센서에서 캡처를 위해 노출을 시작함) HAL은 프레임 숫자와 노출 시작의 타임스탬프를 포함하는 SHUTTER 메시지로 ICameraDeviceCallback::notify()를 호출합니다. 이를 통해 요청을 위한 첫 번째 processCaptureResult() 호출 전에 콜백이 발생하지 않아도 됨을 알리지만, 결과는 캡처에 관한 notify()가 호출되고 나서야 애플리케이션에 전달됩니다.
파이프라인 지연 후 HAL은 ICameraDeviceCallback::processCaptureResult()와 함께 완료된 캡처를 프레임워크로 반환하기 시작합니다. 캡처는 요청이 제출된 순서대로 반환됩니다. 카메라 HAL 기기의 파이프라인 깊이에 따라 여러 요청을 한 번에 진행할 수 있습니다.

시간이 지나면 다음 중 하나가 발생합니다.

프레임워크는 새 요청 제출을 중단하고 기존 캡처가 완료되어 모든 버퍼가 채워지고 모든 결과가 반환될 때까지 대기한 다음 ICameraDeviceSession::configureStreams()를 다시 호출할 수 있습니다. 이렇게 하면 새로운 집합의 입력/출력 스트림을 위한 카메라 하드웨어 및 파이프라인이 재설정됩니다. 일부 스트림은 이전 구성에서 재사용될 수 있습니다. 등록된 출력 스트림이 하나 이상 남아 있는 경우 프레임워크는 HAL에 관한 첫 번째 캡처 요청부터 계속 진행합니다. 이외의 경우에는 먼저 ICameraDeviceSession::configureStreams()가 필요합니다.
프레임워크는 카메라 세션을 종료하기 위해 ICameraDeviceSession::close()를 호출할 수 있습니다. 이는 프레임워크로부터의 다른 호출이 전부 활성 상태가 아닌 경우 어느 때나 호출될 수 있지만, 모든 진행 중인 캡처가 완료되어 모든 결과가 반환되고 모든 버퍼가 채워질 때까지 호출이 차단할 수 있습니다. close() 호출이 반환되면 HAL에서 ICameraDeviceCallback 호출을 발생시킬 수 없습니다. close() 호출이 진행되면 프레임워크는 다른 HAL 기기 기능을 호출할 수 없습니다.
오류 또는 기타 비동기식 이벤트의 경우 HAL은 적절한 오류/이벤트 메시지를 통해 ICameraDeviceCallback::notify()를 호출해야 합니다. HAL은 치명적인 기기 전체 오류 알림에서 반환된 후 close()가 HAL에 호출된 것처럼 작동해야 합니다. 그러나 HAL은 notify()를 호출하기 전에 미처리된 캡처 전체를 취소하거나 완료해야 합니다. 이렇게 해야 notify()가 치명적인 오류로 호출되었을 때 프레임워크에서 기기로부터 추가 콜백을 수신하지 않게 됩니다. close() 이외의 메서드는 notify() 메서드가 치명적인 오류 메시지로부터 반환된 후 ENODEV 또는 NULL을 반환해야 합니다.

그림 4. 카메라 작업 흐름

하드웨어 수준

카메라 기기는 기능에 따라 여러 하드웨어 수준을 구현할 수 있습니다. 자세한 내용은 지원되는 하드웨어 수준을 참고하세요.

애플리케이션 캡처 요청, 3A 제어, 처리 파이프라인 간의 상호작용

3A 제어 블록의 설정에 따라 카메라 파이프라인은 애플리케이션 캡처 요청의 일부 매개변수를 무시하는 대신 3A 제어 루틴에서 제공하는 값을 사용합니다. 예를 들어 자동 노출이 활성화된 경우 센서의 노출 시간, 프레임 지속 기간, 민감도 매개변수가 플랫폼 3A 알고리즘에 의해 제어되며, 앱에서 지정한 값은 무시됩니다. 프레임을 위해 3A 루틴에서 선택한 값은 출력 메타데이터에 보고되어야 합니다. 다음 표는 3A 제어 블록의 다양한 모드와 이러한 모드로 제어되는 속성을 설명합니다. 이러한 속성의 정의는 platform/system/media/camera/docs/docs.html 파일을 참고하세요.

매개변수	상태	제어되는 속성
android.control.aeMode	OFF	없음
	ON	android.sensor.exposureTime android.sensor.frameDuration android.sensor.sensitivity android.lens.aperture(지원되는 경우) android.lens.filterDensity(지원되는 경우)
	ON_AUTO_FLASH	모든 항목이 ON, android.flash.firingPower, android.flash.firingTime, android.flash.mode입니다.
	ON_ALWAYS_FLASH	ON_AUTO_FLASH와 동일합니다.
	ON_AUTO_FLASH_RED_EYE	ON_AUTO_FLASH와 동일합니다.
android.control.awbMode	OFF	없음
	WHITE_BALANCE_*	android.colorCorrection.transform. android.colorCorrection.mode가 FAST 또는 HIGH_QUALITY인 경우 플랫폼별 조정입니다.
android.control.afMode	OFF	없음
	FOCUS_MODE_*	android.lens.focusDistance
android.control.videoStabilization	OFF	없음
	ON	동영상 안정화를 구현하도록 android.scaler.cropRegion을 조정할 수 있습니다.
android.control.mode	OFF	AE, AWB, AF가 사용 중지되었습니다.
	AUTO	개별 AE, AWB, AF 설정이 사용됩니다.
	SCENE_MODE_*	위에 나열된 모든 매개변수를 재정의할 수 있습니다. 개별 3A 제어가 사용 중지되었습니다.

그림 2의 이미지 처리 블록의 제어는 모두 유사한 원리로 작동하며, 각 블록에는 일반적으로 다음 세 가지 모드가 있습니다.

OFF: 이 처리 블록이 사용 중지됩니다. 디모자이크, 색상 보정, 톤 커브 조정 블록은 사용 중지할 수 없습니다.
FAST: 이 모드에서 처리 블록은 OFF 모드에 비해 출력 프레임 속도를 낮추지는 않지만, 이러한 제한을 감안하여 다른 방식으로 최고 품질의 출력을 제공합니다. 일반적으로 미리보기나 동영상 녹화 모드 또는 스틸 이미지의 버스트 캡처에 사용됩니다. 일부 기기에서는 프레임 속도를 낮추지 않고는 처리를 완료할 수 없다는 점에서 OFF 모드와 동일할 수 있으며, 일부 기기에서는 최상의 품질이어도 프레임 속도가 낮아지지 않는다는 점에서 HIGH_QUALITY 모드와 동일할 수도 있습니다.
HIGH_QUALITY: 이 모드에서 처리 블록은 최대한 최고 품질의 결과를 제공하며 필요에 따라 출력 프레임 속도를 낮춥니다. 이 모드는 일반적으로 고품질 스틸 캡처에 사용됩니다. 일부 블록에는 FAST 또는 HIGH_QUALITY 대신 선택사항으로 선택할 수 있는 수동 제어가 포함됩니다. 예를 들어 색상 보정 블록은 색상 변환 매트릭스를 지원하고 톤 커브 조정은 임의의 전체 톤 매핑 커브를 지원합니다.

카메라 하위 시스템에서 지원할 수 있는 최대 프레임 속도는 다음과 같은 요인에 의해 결정됩니다.

출력 이미지 스트림의 요청 해상도
이미지 센서에서 비닝/스키핑 모드의 가용성
이미지 센서 인터페이스의 대역폭
다양한 ISP 처리 블록의 대역폭

이러한 요인은 다양한 ISP와 센서마다 매우 다를 수 있으므로, 카메라 HAL 인터페이스는 대역폭 제한을 최대한 단순한 모델로 추상화하려고 합니다. 제시된 모델에는 다음과 같은 특징이 있습니다.

이미지 센서는 항상 애플리케이션의 요청된 출력 스트림 크기를 고려하여 최대한 가장 낮은 해상도를 출력하도록 구성됩니다. 가장 낮은 해상도는 최소한 요청된 최대 출력 스트림 크기와 같은 것으로 정의됩니다.
모든 요청은 현재 구성된 출력 스트림 일부 또는 전부를 사용할 수 있으므로, 센서와 ISP는 모든 스트림에 관한 단일 캡처 크기 조정을 동시에 지원하도록 구성되어야 합니다.
JPEG 스트림은 JPEG 스트림이 포함되지 않은 요청에 대해 처리된 YUV 스트림처럼 작동하며 직접 참조되는 요청에서는 JPEG 스트림처럼 작동합니다.
JPEG 프로세서는 나머지 카메라 파이프라인과 동시에 실행될 수 있지만, 한 번에 두 개 이상의 캡처를 처리할 수는 없습니다.