Subsistema de HAL

Solicitudes

El framework de la app envía solicitudes de resultados capturados al subsistema de la cámara. Una solicitud corresponde a un conjunto de resultados. Una solicitud encapsula toda la información de configuración sobre la captura y el procesamiento de esos resultados. Esto incluye elementos como la resolución y el formato de píxeles, el control manual del sensor, el lente y el flash, los modos de funcionamiento de 3A, el control de procesamiento de RAW a YUV y la generación de estadísticas. Esto permite un mayor control sobre la salida y el procesamiento de los resultados. Se pueden enviar varias solicitudes a la vez, y el envío de solicitudes no es de bloqueo. Además, las solicitudes siempre se procesan en el orden en que se reciben.

Figura 1: Modelo de cámara

HAL y subsistema de la cámara

El subsistema de cámara incluye implementaciones para componentes de la canalización de la cámara, como el algoritmo de 3A y los controles de procesamiento. La HAL de la cámara proporciona interfaces para que implementes tus versiones de estos componentes. Para mantener la compatibilidad multiplataforma entre varios fabricantes de dispositivos y proveedores de procesadores de señal de imagen (ISP o sensor de cámara), el modelo de canalización de la cámara es virtual y no corresponde directamente a ningún ISP real. Sin embargo, es lo suficientemente similar a las canalizaciones de procesamiento reales para que puedas asignarlo a tu hardware de manera eficiente. Además, es lo suficientemente abstracto como para permitir varios algoritmos y órdenes de operación diferentes sin comprometer la calidad, la eficiencia ni la compatibilidad multidispositivo.

La canalización de la cámara también admite activadores que el framework de la app puede iniciar para activar elementos como el enfoque automático. También envía notificaciones al framework de la app para notificarles a las apps eventos como un bloqueo de enfoque automático o errores.

Figura 2: Canalización de la cámara

Ten en cuenta que algunos bloques de procesamiento de imágenes que se muestran en el diagrama anterior no están bien definidos en la versión inicial. La canalización de la cámara hace las siguientes suposiciones:

• El resultado en formato RAW Bayer no se procesa dentro del ISP.
• Las estadísticas se generan en función de los datos sin procesar del sensor.
• Los diversos bloques de procesamiento que convierten los datos sin procesar del sensor a YUV están en un orden arbitrario.
• Si bien se muestran varias unidades de escala y recorte, todas las unidades de escala comparten los controles de región de salida (zoom digital). Sin embargo, cada unidad puede tener una resolución de salida y un formato de píxeles diferentes.

Resumen del uso de la API
Este es un breve resumen de los pasos para usar la API de la cámara de Android. Consulta la sección Inicio y secuencia de operaciones esperadas para obtener un desglose detallado de estos pasos, incluidas las llamadas a la API.

1. Escucha y enumera los dispositivos de cámara.
2. Abre el dispositivo y conecta los objetos de escucha.
3. Configura las salidas para el caso de uso de destino (como captura de imágenes fijas, grabación, etc.).
4. Crea solicitudes para el caso de uso objetivo.
5. Captura o repite solicitudes y ráfagas.
6. Recibir metadatos de resultados y datos de imágenes
7. Cuando cambies de caso de uso, vuelve al paso 3.

Resumen de la operación de HAL

• Las solicitudes asíncronas de capturas provienen del framework.
• El dispositivo HAL debe procesar las solicitudes en orden. Y para cada solicitud, produce metadatos de resultados de salida y uno o más búferes de imágenes de salida.
• El primero en entrar, el primero en salir para las solicitudes y los resultados, y para las transmisiones a las que hacen referencia las solicitudes posteriores.
• Las marcas de tiempo deben ser idénticas para todos los resultados de una solicitud determinada, de modo que el framework pueda hacer coincidir las marcas de tiempo si es necesario.
• Toda la configuración y el estado de la captura (excepto las rutinas de 3A) se encapsulan en las solicitudes y los resultados.

Figura 3: Descripción general de la HAL de la cámara

Inicio y secuencia de operación esperada

En esta sección, se incluye una explicación detallada de los pasos que se esperan cuando se usa la API de la cámara. Consulta platform/hardware/interfaces/camera/ para obtener definiciones de las interfaces HIDL.

Enumerar, abrir dispositivos de cámara y crear una sesión activa

1. Después de la inicialización, el framework comienza a detectar cualquier proveedor de cámaras presente que implemente la interfaz ICameraProvider. Si ese proveedor o esos proveedores están presentes, el framework intentará establecer una conexión.
2. El framework enumera los dispositivos de la cámara a través de ICameraProvider::getCameraIdList().
3. El framework crea una instancia de un ICameraDevice nuevo llamando al ICameraProvider::getCameraDeviceInterface_VX_X() correspondiente.
4. El framework llama a ICameraDevice::open() para crear una nueva ICameraDeviceSession de sesión de captura activa.

Cómo usar una sesión de cámara activa

1. El framework llama a ICameraDeviceSession::configureStreams() con una lista de flujos de entrada y salida al dispositivo HAL.
2. El framework solicita la configuración predeterminada para algunos casos de uso con llamadas a ICameraDeviceSession::constructDefaultRequestSettings(). Esto puede ocurrir en cualquier momento después de que ICameraDevice::open cree ICameraDeviceSession.
3. El framework construye y envía la primera solicitud de captura al HAL con una configuración basada en uno de los conjuntos de parámetros de configuración predeterminados y con, al menos, un flujo de salida que el framework haya registrado antes. Esto se envía al sistema HAL con ICameraDeviceSession::processCaptureRequest(). El HAL debe bloquear la devolución de esta llamada hasta que esté listo para que se envíe la siguiente solicitud.
4. El framework sigue enviando solicitudes y llamadas a ICameraDeviceSession::constructDefaultRequestSettings() para obtener búferes de configuración predeterminados para otros casos de uso según sea necesario.
5. Cuando comienza la captura de una solicitud (el sensor comienza a exponerse para la captura), HAL llama a ICameraDeviceCallback::notify() con el mensaje SHUTTER, incluido el número de fotogramas y la marca de tiempo para el inicio de la exposición. Esta devolución de llamada de notificación no tiene que ocurrir antes de la primera llamada a processCaptureResult() para una solicitud, pero no se entregan resultados a una app para una captura hasta después de que se llame a notify() para esa captura.
6. Después de un retraso en la canalización, el sistema HAL comienza a mostrar capturas completas al framework con ICameraDeviceCallback::processCaptureResult(). Se muestran en el mismo orden en que se enviaron las solicitudes. Se pueden enviar varias solicitudes a la vez, según la profundidad de la canalización del dispositivo HAL de la cámara.

Después de un tiempo, ocurrirá una de las siguientes situaciones:

• Es posible que el framework deje de enviar solicitudes nuevas, espere a que se completen las capturas existentes (todos los búferes llenos, todos los resultados mostrados) y, luego, vuelva a llamar a ICameraDeviceSession::configureStreams(). Esta acción restablece el hardware y la canalización de la cámara para un nuevo conjunto de flujos de entrada y salida. Es posible que se vuelvan a usar algunas transmisiones de la configuración anterior. Luego, el framework continúa desde la primera solicitud de captura al HAL, si queda al menos un flujo de salida registrado. (De lo contrario, primero se requiere ICameraDeviceSession::configureStreams()).
• El framework puede llamar a ICameraDeviceSession::close() para finalizar la sesión de la cámara. Se puede llamar a esta función en cualquier momento cuando no haya otras llamadas del framework activas, aunque la llamada puede bloquearse hasta que se completen todas las capturas en curso (se muestren todos los resultados y se llenen todos los búferes). Después de que se devuelve la llamada a close(), no se permiten más llamadas a ICameraDeviceCallback desde el HAL. Una vez que se inicia la llamada a close(), es posible que el framework no llame a ninguna otra función del dispositivo HAL.
• En caso de un error o algún otro evento asíncrono, el HAL debe llamar a ICameraDeviceCallback::notify() con el mensaje de error o evento adecuado. Después de regresar de una notificación de error fatal en todo el dispositivo, el sistema HAL debería actuar como si se hubiera llamado a close(). Sin embargo, el sistema HAL debe cancelar o completar todas las capturas pendientes antes de llamar a notify(), de modo que, una vez que se llame a notify() con un error fatal, el framework no reciba más devoluciones de llamada del dispositivo. Los métodos que no sean close() deben mostrar -ENODEV o NULL después de que el método notify() muestre un mensaje de error irrecuperable.

Figura 4: Flujo operativo de la cámara

Niveles de hardware

Los dispositivos de cámara pueden implementar varios niveles de hardware según sus capacidades. Para obtener más información, consulta el nivel de hardware compatible.

Interacción entre la solicitud de captura de la app, el control de 3A y la canalización de procesamiento

Según la configuración del bloque de control de 3A, la canalización de la cámara ignora algunos de los parámetros de la solicitud de captura de la app y, en su lugar, usa los valores que proporcionan las rutinas de control de 3A. Por ejemplo, cuando la función de exposición automática está activa, el algoritmo 3A de la plataforma controla el tiempo de exposición, la duración de la trama y los parámetros de sensibilidad del sensor, y se ignoran los valores especificados por la app. Los valores que las rutinas de 3A eligen para el fotograma deben informarse en los metadatos de salida. En la siguiente tabla, se describen los diferentes modos del bloque de control 3A y las propiedades que controlan estos modos. Consulta el archivo platform/system/media/camera/docs/docs.html para obtener definiciones de estas propiedades.

Los controles del bloque de procesamiento de imágenes de la Figura 2 funcionan según un principio similar y, por lo general, cada bloque tiene tres modos:

• DESACTIVADO: Este bloque de procesamiento está inhabilitado. No se pueden inhabilitar los bloques de demosaico, corrección de colores ni ajuste de la curva de tono.
• RÁPIDO: En este modo, es posible que el bloque de procesamiento no ralentice la velocidad de fotogramas de salida en comparación con el modo DESACTIVADO, pero, de lo contrario, debería producir el resultado de la mejor calidad posible, dada esa restricción. Por lo general, se usa para los modos de vista previa o grabación de video, o la captura en ráfaga para imágenes fijas. En algunos dispositivos, esto puede ser equivalente al modo OFF (no se puede realizar ningún procesamiento sin ralentizar la velocidad de fotogramas) y, en otros, puede ser equivalente al modo HIGH_QUALITY (la mejor calidad aún no ralentiza la velocidad de fotogramas).
• HIGH_QUALITY: En este modo, el bloque de procesamiento debe producir el mejor resultado de calidad posible, lo que ralentiza la velocidad de fotogramas de salida según sea necesario. Por lo general, se usa para capturar imágenes fijas de alta calidad. Algunos bloques incluyen un control manual que se puede seleccionar de forma opcional en lugar de FAST o HIGH_QUALITY. Por ejemplo, el bloque de corrección de colores admite una matriz de transformación de color, mientras que el ajuste de la curva de tono admite una curva de asignación de tono global arbitraria.

La velocidad de fotogramas máxima que puede admitir un subsistema de cámara es una función de muchos factores:

• Resoluciones solicitadas de las transmisiones de imágenes de salida
• Disponibilidad de los modos de agrupación o omisión en el sistema de imágenes
• El ancho de banda de la interfaz del generador de imágenes
• El ancho de banda de los diversos bloques de procesamiento del ISP

Dado que estos factores pueden variar mucho entre los diferentes ISP y sensores, la interfaz de HAL de la cámara intenta abstraer las restricciones de ancho de banda en el modelo más simple posible. El modelo presentado tiene las siguientes características:

• El sensor de imagen siempre se configura para generar la resolución más pequeña posible según los tamaños de flujo de salida solicitados de la app. La resolución más pequeña se define como al menos tan grande como el tamaño de flujo de salida solicitado más grande.
• Dado que cualquier solicitud puede usar cualquiera de las transmisiones de salida configuradas actualmente o todas ellas, el sensor y el ISP deben configurarse para admitir la escalamiento de una sola captura a todas las transmisiones al mismo tiempo.
• Las transmisiones JPEG actúan como transmisiones YUV procesadas para las solicitudes en las que no se incluyen. En las solicitudes en las que se hace referencia a ellas directamente, actúan como transmisiones JPEG.
• El procesador JPEG puede ejecutarse de forma simultánea con el resto de la canalización de la cámara, pero no puede procesar más de una captura a la vez.