introducción
Si el marco de la aplicación desea obtener fotografías o videos tomando fotografías y obteniendo una vista previa de la cámara, debe enviar una solicitud al subsistema de la cámara.
Una solicitud corresponde a un conjunto de resultados.
Se pueden iniciar varias solicitudes a la vez, y las solicitudes enviadas no son bloqueantes y siempre se procesan secuencialmente en forma de cola en el orden recibido.
Una solicitud contiene toda la información sobre el disparo y la configuración de la cámara, así como los resultados de su procesamiento.
(Generalmente incluye: resolución, formato de píxeles, sensor manual, lente, control de flash, modo de operación 3A, control de procesamiento de RAW a YUV, generación de información estadística , etc., lo que significa que puede tener mucho control sobre los resultados de salida y procesamiento Este es el cambio más importante de Camera2 en comparación con Camera1)
Modelo de solicitud de cámara:
tubería de cámara
En el subsistema de cámara, incluye la implementación de componentes en la tubería . Tales como: algoritmo 3A y controles de procesamiento.
La cámara HAL proporciona interfaces y los usuarios pueden implementar sus propias versiones de estas interfaces de componentes. Por ejemplo, Qualcomm o MTK implementan sus propias interfaces de componentes según la interfaz estándar HAL. Una interfaz estándar de este tipo no sólo garantiza la compatibilidad multiplataforma entre múltiples fabricantes de equipos e ISP, sino que también garantiza la singularidad de cada implementación.
La canalización de la cámara es virtual y el flujo de procesamiento de todos los datos de la cámara es el mismo que el de la canalización. El concepto de tubería se puede utilizar para mapear hardware. Este tipo de componente abstracto de la canalización admite una variedad de algoritmos y secuencias de operación diferentes sin afectar la calidad, la eficiencia y la compatibilidad entre dispositivos.
La canalización de la cámara también admite notificaciones o activación de eventos: el marco de la aplicación puede iniciar algunas funciones, como el enfoque automático, y también enviará notificaciones al marco de la aplicación para notificar a la aplicación de eventos como el bloqueo o el error del enfoque automático.
La imagen del canal de cámaras mencionado anteriormente incluye no solo el procesamiento del dispositivo de hardware real, sino también el procesamiento de software:
CameraSensor, ISP, información estadística, algoritmo 3A, procesamiento Bayer, procesamiento Jpeg, procesamiento YUV
ISP también incluye: calibración térmica de píxeles, demosaico, reducción de ruido, calibración de sombras, calibración de geometría, calibración de diferencia de color, mejora de bordes, ajuste de curva de tono,
Vale la pena señalar que algunos bloques de procesamiento de imágenes, como se muestra en la figura, no están bien definidos y el proceso de la cámara hace las siguientes suposiciones. :
1) La salida RAW de Bayer no se procesa dentro del ISP
2) Las estadísticas se generan a partir de datos sin procesar del sensor.
3) Se pueden organizar varios bloques de procesamiento que convierten datos sin procesar en YUV en cualquier orden
4) Cuando se muestran varias unidades de escala y recorte, todas las unidades de zoom comparten controles de área (zoom digital). Sin embargo, cada unidad puede tener una resolución de salida y un formato de píxeles diferentes.
Resumen de las operaciones de HAL
Solicitudes asincrónicas de FW para tomar fotografías o grabar videos
El dispositivo HAL debe procesar las solicitudes en orden . Cada solicitud genera metadatos de salida y uno o más buffers de imágenes de salida.
Las solicitudes, los resultados y las solicitudes de transmisión posteriores obedecen a la regla de primero en entrar, primero en salir (reglas de colas).
Todas las salidas de una solicitud específica deben tener exactamente la misma marca de tiempo para que el marco pueda unirlas si es necesario.
La configuración y el estado de todas las grabaciones de fotos o videos (excluyendo las rutinas 3A) están incluidos en la solicitud y el resultado.
Descripción general de la cámara HAL :
Inicio de la cámara y secuencia esperada de operaciones
El proceso de uso de la API de AndroidCamera
- Escuche y enumere los dispositivos de cámara.
- Abra el dispositivo y conecte el oyente.
- Configure la salida para el caso de uso objetivo (como tomar fotografías, grabar, etc.).
- Cree una solicitud para el caso de uso de destino.
- Captura/repetición de solicitudes y ráfagas.
- Reciba los metadatos del resultado y los datos de la imagen .
- Al cambiar de caso de uso , regrese al paso 3
Proceso de operación de la cámara
hardware/interfaces/cámara
1) Enumerar, abrir el dispositivo de cámara y crear una sesión válida:
- a. Después de la inicialización, el marco comienza a escuchar cualquier CameraProvider existente (implementación de la interfaz ICameraProvider). Si hay uno o más CameraProviders, FW intentará establecer una conexión.
b. FW enumera los dispositivos de cámara a través de: ICameraProvider::getCameraIdList()
c. El FW crea una instancia de un nuevo ICameraDevice y llama en consecuencia:
ICameraProvider::getCameraDeviceInterface_VX_X()
d. FW crea una nueva sesión de captura activa (ICameraDeviceSession) llamando a ICameraDevice::open()
2) Utilice una sesión de cámara válida:
a. El FW llama a la lista de flujos de entrada/salida del dispositivo HAL para llamar: ICameraDeviceSession::configureStreams()
b. Siempre que ICameraDeviceSession sea creado por ICameraDevice::open(), en cualquier momento, FW puede llamar a la solicitud de configuración predeterminada en algunos casos de uso: ICameraDeviceSession::constructDefaultRequestSettings();
c. El marco construye la primera solicitud de captura llamando a la configuración basada en un cierto conjunto de configuraciones predeterminadas y al menos un flujo de salida previamente registrado por el marco, y lo envía al HAL. Esta solicitud se envía a HAL a través de ICameraDeviceSession::processCaptureRequest(). El HAL debe bloquear la devolución de esta llamada hasta que esté listo para enviar la siguiente solicitud.
d. El marco continúa enviando solicitudes, llamando a ICameraDeviceSession::constructDefaultRequestSettings() según sea necesario para obtener búferes de configuración predeterminados para otros casos de uso.
e. Cuando se solicita un inicio de captura (el sensor comienza a exponer para la captura), HAL llama a ICameraDeviceCallback::notify() con un mensaje SHUTTER que incluye: el número de fotograma y la marca de tiempo cuando se inició la exposición. Esta devolución de llamada de notificación no tiene que ocurrir antes de que se llame a ProcessCaptureResult() para la primera solicitud. Sin embargo, los resultados de esa captura no se proporcionan a la aplicación hasta que se llama a notify() en la captura correspondiente.
F. Después de un retraso en la canalización, HAL comienza a devolver la captura completa al marco usando ICameraDeviceCallback::processCaptureResult(). Estas capturas se devuelven en el mismo orden en que se enviaron las solicitudes. Se pueden realizar varias solicitudes a la vez, dependiendo de la profundidad de la tubería del dispositivo HAL de la cámara.
3) Después de encender la cámara, ocurrirá una de las siguientes situaciones:
a. Después de tomar fotografías o videos, restablezca la configuración y vuelva a enviar la solicitud, y los datos serán reasignados y adquiridos nuevamente.
La redistribución es llamar: ICameraDeviceSession::configureStreams()
B. Apague la cámara.
Al cerrar la cámara se llamará: ICameraDeviceSession::close()
C. Hay un error o anomalía en la cámara.
Devuelve un mensaje de error o evento: ICameraDeviceCallback::notify()