Camera2 заменяет один логический поток двумя физическими потоками в Android API 29 - PullRequest
Новая
       32

Camera2 заменяет один логический поток двумя физическими потоками в Android API 29

2 голосов
/ 30 апреля 2019

Когда был выпущен Android 9 (API 28), я был очень рад обнаружить, что физические камеры телефонов с несколькими камерами будут выставлены, я был очень разочарован тем, что не смог получить к ним доступ. Сегодня наткнулся на андроид Q документация которая гласит:

Начиная с уровня API 29, некоторые или все физические камеры могут не подвергаться независимому воздействию приложения, и в этом случае идентификаторы физических камер не будут доступны в CameraManager.getCameraIdList (). Но приложение все еще может запрашивать характеристики физических камер, вызывая CameraManager.getCameraCharacteristics (String).

Это утверждение смущает меня, означает ли это, что Android возвращается? Какова цель изменения?

Меня интересует управление камерами на очень хорошем уровне, помешает ли это изменение сделать то, что я могу сделать сегодня с Android 9?

В нем говорится, что идентификаторы могут отсутствовать в списке, но характеристики все еще могут быть запрошены. Как мы можем получить характеристики камер, не имея их идентификаторов? Я предполагаю, что мы должны получить физические идентификаторы камер через getPhysicalCameraIds() на логических камерах, но означает ли это, что если мы хотим использовать «скрытую» камеру, нам придется протестировать несколько случайных строк идентификаторов?

enter image description here

И сможем ли мы по-прежнему создавать сеансы захвата с SessionConfiguration на физических камерах, которые не экспонируются?

Может кто-нибудь пролить свет на это?

1 Ответ

1 голос
/ 30 апреля 2019

Это не возврат. На самом деле, это обобщение является важным шагом для предоставления вам лучшего контроля над сложными настройками камеры.

До API 29, если производитель не мог предоставить отдельное cameraDevice для каждого из объективов, составляющих композитную камеру, он не мог представить параметры объектива разработчику. Их единственным выбором было выставить композитную камеру целиком.

Вопрос не

И сможем ли мы по-прежнему создавать сеансы захвата с помощью SessionConfiguration на физических камерах, которые не отображаются?

а точнее,

И теперь мы можем прочитать характеристики физических камер, которые не могли быть выставлены раньше‼

С новым изменением производитель может предоставить вам всю доступную информацию о «Back camera1», «Back camera2» и т. Д., Даже если нет возможности начать отдельные сеансы захвата для них.

getPhysicalCameraIds () ссылка объясняет:

До уровня API 29 все возвращенные идентификаторы гарантированно возвращаются с помощью CameraManager.getCameraIdList () и могут быть открыты непосредственно с помощью CameraManager.openCamera () . Начиная с уровня API 29, для каждого возвращенного идентификатора, если он также возвращается CameraManager.getCameraIdList () , он может использоваться в качестве автономной камеры с помощью CameraManager.openCamera (), В противном случае идентификатор камеры может использоваться только как часть текущей логической камеры.

Это означает, что вы можете использовать любой идентификатор, возвращаемый getPhysicalCameraIds () in CameraManager.getCameraCharacteristics (id) :

На уровне API 29 эта функция также может использоваться для запроса возможностей физических камер, которые могут использоваться только как часть логической многокамерной камеры. Эти камеры нельзя не открывать напрямую через openCamera (String, CameraDevice.StateCallback, Handler) .

...