다중 카메라 지원

Android 9에서는 동일한 방향을 가리키는 물리적 카메라 기기 2개 이상으로 구성된 새로운 논리 카메라 기기를 통해 다중 카메라 기기의 API 지원이 도입되었습니다. 논리 카메라 기기는 단일 CameraDevice/CaptureSession으로 앱에 노출되어 HAL 통합 다중 카메라 기능과 상호작용할 수 있습니다. 앱은 기본 물리적 카메라 스트림, 메타데이터, 컨트롤에 선택적으로 액세스하여 이를 제어할 수 있습니다.

다중 카메라 지원

그림 1. 다중 카메라 지원

이 다이어그램에서 카메라 ID는 색상별로 구분되어 있습니다. 앱은 각 물리적 카메라의 RAW 버퍼를 동시에 스트리밍할 수 있습니다. 또한 별도의 컨트롤을 설정하고 다른 물리적 카메라에서 별도의 메타데이터를 수신할 수 있습니다.

예시 및 소스

다중 카메라 기기는 논리 다중 카메라 기능을 통해 알려야 합니다.

카메라 클라이언트는 getPhysicalCameraIds()를 호출하여 특정 논리 카메라를 구성하는 실제 기기의 카메라 ID를 쿼리할 수 있습니다. 결과의 일부로 반환되는 ID는 setPhysicalCameraId()를 통해 실제 기기를 개별적으로 제어하는 데 사용됩니다. 이러한 개별 요청의 결과는 getPhysicalCameraResults()를 호출하여 전체 결과에서 쿼리될 수 있습니다.

개별 물리적 카메라 요청은 매개변수의 제한된 하위 집합만 지원할 수도 있습니다. 개발자는 지원되는 매개변수 목록을 수신하기 위해 getAvailablePhysicalCameraRequestKeys()를 호출할 수 있습니다.

물리적 카메라 스트림은 재처리되지 않는 요청과 흑백 및 베이어(bayer) 센서에만 지원됩니다.

구현

지원 체크리스트

HAL 측에 논리적 다중 카메라 기기를 추가하려면 다음 단계를 따르세요.

Android 9를 실행하는 기기의 경우 카메라 기기는 하나의 논리적 YUV/RAW 스트림을 두 물리적 카메라에서 크기(RAW 스트림에는 적용되지 않음) 및 형식이 동일한 물리적 스트림으로 교체할 수 있도록 지원해야 합니다. Android 10을 실행하는 기기에는 적용되지 않습니다.

카메라 HAL 기기 버전이 3.5 이상인 Android 10을 실행하는 기기의 경우 카메라 기기에서는 앱이 물리적 스트림을 포함하는 특정 스트림 조합이 지원되는지를 쿼리할 수 있도록 isStreamCombinationSupported를 지원해야 합니다.

스트림 구성 맵

논리 카메라의 경우 특정 하드웨어 수준의 카메라 기기에 적용되는 필수 스트림 조합은 CameraDevice.createCaptureSession에서 요구되는 것과 동일합니다. 스트림 구성 맵의 모든 스트림은 논리적 스트림이어야 합니다.

다양한 크기의 물리적 하위 카메라로 RAW 기능을 지원하는 논리 카메라 기기의 경우 애플리케이션이 논리 RAW 스트림을 구성하면 논리 카메라 기기는 센서 크기가 다른 물리적 하위 카메라로 전환하면 안 됩니다. 이렇게 하면 기존 RAW 캡처 앱이 중단되지 않습니다.

RAW 캡처 중에 물리적 하위 카메라를 전환하여 HAL 구현 광학 줌을 활용하려면 앱에서 논리 RAW 스트림 대신 물리적 하위 카메라 스트림을 구성해야 합니다.

보장된 스트림 조합

논리 카메라와 기본 물리적 카메라 모두 기기 수준별로 필요한 필수 스트림 조합이 보장되어야 합니다.

논리 카메라 기기는 하드웨어 수준 및 기능에 따라 물리적 카메라 기기와 동일한 방식으로 작동해야 합니다. 논리 카메라 기능 세트는 개별 물리적 카메라 기능 세트의 상위 집합인 것이 좋습니다.

Android 9를 실행하는 기기에서는 보장된 스트림 조합 각각의 경우 논리 카메라가 다음을 지원해야 합니다.

  • 논리 YUV_420_888 또는 RAW 스트림을 크기와 형식이 동일한 물리적 스트림 두 개와 교체하되, 물리적 카메라에서 지원되는 크기와 형식을 고려하여 개별 물리적 카메라 각각의 스트림과 교체합니다.

  • 논리 카메라는 RAW 기능을 전달하지 않지만 기본 물리적 카메라가 전달하는 경우 각 물리적 카메라에서 하나씩 두 개의 RAW 스트림을 추가합니다. 이는 일반적으로 물리적 카메라의 센서 크기가 다를 때 발생합니다.

  • 동일한 크기 및 형식의 논리 스트림 대신 물리적 스트림을 사용합니다. 물리적 스트림과 논리 스트림의 최소 프레임 지속 기간이 동일할 때 이로 인해 캡처의 프레임 속도가 느려지면 안 됩니다.

성능 및 전원 고려사항

  • 성능:

    • 물리적 스트림을 구성하고 스트리밍하면 리소스 제약으로 인해 물리적 카메라의 캡처 속도가 느려질 수 있습니다.
    • 물리적 카메라 설정을 적용하면 기본 카메라에 다른 프레임 속도가 적용되어 캡처 속도가 느려질 수 있습니다.

  • 전원:

    • HAL의 전원 최적화는 기본 설정에서도 계속 작동합니다.
    • 물리적 스트림을 구성하거나 요청하면 HAL의 내부 전원 최적화가 재정의되어 전원 사용량이 늘어날 수 있습니다.

맞춤설정

다음과 같은 방법으로 기기 구현을 맞춤설정할 수 있습니다.

  • 논리 카메라 기기의 통합 출력은 HAL 구현에 따라 전적으로 달라집니다. 통합 논리 스트림이 물리적 카메라에서 파생되는 방식에 관한 결정은 앱 및 Android 카메라 프레임워크에 투명합니다.
  • 개별 물리적 요청 및 결과는 선택적으로 지원될 수 있습니다. 이러한 요청의 사용 가능한 매개변수 세트는 특정 HAL 구현에 따라 완전히 달라집니다.
  • Android 10부터 HAL은 getCameraIdList의 PHYSICAL_ID 일부 또는 전체를 전달하지 않도록 선택하여 앱에서 직접 열 수 있는 카메라 수를 줄일 수 있습니다. 이후 getPhysicalCameraCharacteristics 호출은 물리적 카메라의 특성을 반환해야 합니다.

유효성 검사

논리 다중 카메라 기기는 다른 일반 카메라와 마찬가지로 카메라 CTS를 통과해야 합니다. 이 유형의 기기를 대상으로 하는 테스트 사례는 LogicalCameraDeviceTest 모듈에서 확인할 수 있습니다.

다음 ITS 테스트 세 가지는 다중 카메라 시스템을 대상으로 하여 이미지의 적절한 통합을 용이하게 합니다.

scene1 및 scene4 테스트는 ITS-in-a-box 테스트 장치로 실행됩니다. test_multi_camera_match 테스트는 두 카메라가 모두 사용 설정된 경우 이미지 중앙의 밝기가 일치함을 확인합니다. test_multi_camera_alignment 테스트는 카메라 간격, 방향, 왜곡 매개변수가 제대로 로드되었음을 확인합니다. 다중 카메라 시스템에 Wide FoV 카메라(90o 초과)가 포함되는 경우 ITS box의 rev2 버전이 필요합니다.

Sensor_fusion은 반복적인 지정 휴대전화 모션을 사용 설정하는 두 번째 테스트 장치로, 자이로스코프와 이미지 센서 타임스탬프가 일치하며 다중 카메라 프레임이 동기화되어 있음을 확인합니다.

모든 box는 AcuSpec, Inc.(www.acuspecinc.com, fred@acuspecinc.com) 및 MYWAY Manufacturing(www.myway.tw, sales@myway.tw)을 통해 사용할 수 있습니다. 또한 rev1 ITS box는 West-Mark(www.west-mark.com, dgoodman@west-mark.com)를 통해 구입할 수 있습니다.

권장사항

앱 호환성을 유지하면서 다중 카메라에 의해 사용 설정된 기능을 최대한 활용하려면 논리 다중 카메라 기기를 구현할 때 다음 권장사항을 따르세요.

  • (Android 10 이상) getCameraIdList에서 물리적 하위 카메라를 숨깁니다. 이렇게 하면 앱에서 직접 열 수 있는 카메라 수가 줄어들어 앱에 복잡한 카메라 선택 논리가 필요하지 않습니다.
  • (Android 11 이상) 광학 줌을 지원하는 논리 다중 카메라 기기의 경우 ANDROID_CONTROL_ZOOM_RATIO API를 구현하고 가로세로 비율 자르기에만 ANDROID_SCALER_CROP_REGION을 사용합니다. ANDROID_CONTROL_ZOOM_RATIO를 사용하면 기기가 축소되고 더 나은 정밀도를 유지할 수 있습니다. 이 경우 HAL은 ANDROID_SCALER_CROP_REGION, ANDROID_CONTROL_AE_REGIONS, ANDROID_CONTROL_AWB_REGIONS, ANDROID_CONTROL_AF_REGIONS, ANDROID_STATISTICS_FACE_RECTANGLES, ANDROID_STATISTICS_FACE_LANDMARKS의 좌표계를 조정하여 사후 확대/축소 시야를 센서 활성 배열로 취급해야 합니다. ANDROID_SCALER_CROP_REGION이 ANDROID_CONTROL_ZOOM_RATIO와 함께 작동하는 방식에 관한 자세한 내용은 camera3_crop_reprocess#cropping을 참고하세요.
  • 기능이 다양한 물리적 카메라가 있는 다중 카메라 기기의 경우 전체 확대/축소 범위에서 특정 값이나 범위를 지원하는 경우에만 제어의 특정 값 또는 범위 지원을 전달해야 합니다. 예를 들어 논리 카메라가 울트라와이드, 와이드, 망원 카메라로 구성된 경우 다음을 실행하세요.
    • 물리적 카메라의 활성 배열 크기가 다르면 카메라 HAL은 물리적 카메라의 활성 배열에서 ANDROID_SCALER_CROP_REGION, ANDROID_CONTROL_AE_REGIONS, ANDROID_CONTROL_AWB_REGIONS, ANDROID_CONTROL_AF_REGIONS, ANDROID_STATISTICS_FACE_RECTANGLES, ANDROID_STATISTICS_FACE_LANDMARKS의 논리 카메라 활성 배열로 매핑을 실행해야 합니다. 따라서 앱의 관점에서 좌표계는 논리 카메라의 활성 배열 크기입니다.
    • 와이드 및 망원 카메라는 자동 초점을 지원하지만 울트라와이드 카메라는 고정 초점이라면 논리 카메라가 자동 초점 지원을 전달해야 합니다. HAL은 앱이 울트라와이드 렌즈로 축소될 때 기본 물리적 카메라가 고정 초점이라는 사실이 앱에 투명하고, 지원되는 AF 모드의 자동 초점 상태 시스템이 예상대로 작동하도록 울트라와이드 카메라의 자동 초점 상태 시스템을 시뮬레이션해야 합니다.
    • 와이드 및 망원 카메라가 4K @60fps를 지원하고 울트라와이드 카메라는 4K @30fps 또는 1080p @60fps만 지원하고 4K @60fps를 지원하지 않는다면 논리 카메라가 지원되는 스트림 구성에서 4K @60fps를 전달하지 않아야 합니다. 이렇게 하면 논리 카메라 기능의 무결성을 보장하므로 1보다 작은 ANDROID_CONTROL_ZOOM_RATIO 값에서 4K @60fps를 달성하지 못하는 문제가 앱에 발생하지 않습니다.
  • Android 10부터 논리 다중 카메라는 물리적 스트림을 포함하는 스트림 조합을 지원하지 않아도 됩니다. HAL이 물리적 스트림과의 조합을 지원하는 경우:
    • (Android 11 이상) 스테레오 및 모션 추적의 심도와 같은 사용 사례를 더 잘 처리하려면 물리적 스트림 출력의 시야를 하드웨어에서 달성할 수 있는 최대 크기로 만듭니다. 그러나 물리적 스트림과 논리 스트림이 동일한 물리적 카메라에서 시작되면 하드웨어 제한으로 인해 물리적 스트림의 시야가 강제로 논리 스트림과 동일하게 될 수 있습니다.
    • 여러 물리적 스트림으로 발생한 메모리 압력을 해결하려면 물리적 스트림이 일정 기간 유휴 상태일 것으로 예상되는 경우 앱에서 discardFreeBuffers를 사용하여 여유 버퍼(소비자가 해제했지만 아직 생산자가 대기열에서 제외하지 않은 버퍼)를 할당 해제해야 합니다.
    • 다양한 물리적 카메라의 물리적 스트림이 일반적으로 동일한 요청에 연결되지 않은 경우 버퍼 큐 하나가 두 앱 지향 표면을 지원하는 데 사용되도록 앱에서 surface group을 사용하여 메모리 소비를 줄여야 합니다.