Camera2在Android API中用两个物理流替换了一个逻辑流29 [英] Camera2 replacing one logical stream with two physical streams in Android API 29

查看:204
本文介绍了Camera2在Android API中用两个物理流替换了一个逻辑流29的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

当发布Android 9(API 28)时,我很高兴发现带有多个摄像头的手机的物理摄像头会暴露出来,我为无法访问它们而感到非常沮丧.今天,我偶然发现了Android Q

并且我们仍然能够使用解决方案

这不是回溯.实际上,这种概括是向您更好地控制复杂相机设置的重要步骤.

在API 29之前,如果制造商无法为构成复合相机的每个镜头提供单独的 cameraDevice ,则他们将无法向开发人员公开镜头参数.他们唯一的选择是将复合相机整体曝光.

问题不是

我们还能在未曝光的物理摄像机上使用SessionConfiguration创建捕获会话吗?

但是,

现在我们可以读取以前无法曝光的物理相机的特征!

有了新的更改,制造商可以为您提供后置摄像头1",后置摄像头2"等所有可用信息,即使没有办法在它们上开始单独的捕获会话.

getPhysicalCameraIds()参考说明:

在API级别29之前,保证所有返回的ID均由 CameraManager.getCameraIdList(),可以直接通过 CameraManager.getCameraIdList(),它可以被 documentation which says:

Starting from API level 29, some or all physical cameras may not be independently exposed to the application, in which case the physical camera IDs will not be available in CameraManager.getCameraIdList(). But the application can still query the physical cameras' characteristics by calling CameraManager.getCameraCharacteristics(String).

This statement confuses me, does it mean that Android is backtracking? what's the purpose of the change?

I'm interested in managing cameras at a very fine level, will this change prevent me from doing what I'm able to do today with Android 9?

It says that the IDs may not be listed any more but that the characteristics can still be queried, how are we supposed to get the characteristics of cameras without having their IDs? I guess we are supposed to get the physical cameras' IDs via getPhysicalCameraIds() on logical cameras, but does it means that if we wanted to use a "hidden" camera, we'd have to test a bunch of random ID strings?

And will we still be able to create capture sessions with SessionConfiguration on physical cameras that are not exposed?

Can someone shed some light on this?

解决方案

This is not backtracking. Actually, this generalization is an important step to provide you with better control of complex camera setups.

Before API 29, if the manufacturer could not provide separate cameraDevice for each of the lenses that constitute a composite camera, they had no way to expose the lens parameters to the developer. Their only choice was to expose the composite camera as whole.

The question is not

And will we still be able to create capture sessions with SessionConfiguration on physical cameras that are not exposed?

but rather,

And now we can read the characteristics of physical cameras that could not be exposed before‼

With the new change, the manufacturer can give you all available info on "Back camera1", "Back camera2", etc. even if there is no way to start separate capture sessions on them.

getPhysicalCameraIds() reference explains:

Prior to API level 29, all returned IDs are guaranteed to be returned by CameraManager.getCameraIdList(), and can be opened directly by CameraManager.openCamera(). Starting from API level 29, for each of the returned ID, if it's also returned by CameraManager.getCameraIdList(), it can be used as a standalone camera by CameraManager.openCamera(). Otherwise, the camera ID can only be used as part of the current logical camera.

This means that you can use any id returned by getPhysicalCameraIds() in CameraManager.getCameraCharacteristics(id):

From API level 29, this function can also be used to query the capabilities of physical cameras that can only be used as part of logical multi-camera. These cameras cannot not be opened directly via openCamera(String, CameraDevice.StateCallback, Handler).

这篇关于Camera2在Android API中用两个物理流替换了一个逻辑流29的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆