Subsistema HAL

Peticiones

El marco de la aplicación 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 aspectos como la resolución y el formato de píxeles; control manual de sensores, lentes y flash; modos de funcionamiento 3A; Control de procesamiento de RAW a YUV; y generación de estadísticas. Esto permite un control mucho mayor sobre la producción y el procesamiento de los resultados. Pueden haber varias solicitudes en curso a la vez y el envío de solicitudes no bloquea. Y las solicitudes siempre se procesan en el orden en que se reciben.

Figura 1. Modelo de cámara

El subsistema HAL y la cámara.

El subsistema de cámara incluye las implementaciones de componentes en la canalización de la cámara, como el algoritmo 3A y los controles de procesamiento. La cámara HAL proporciona interfaces para que usted implemente sus versiones de estos componentes. Para mantener la compatibilidad multiplataforma entre múltiples fabricantes de dispositivos y proveedores de procesadores de señal de imagen (ISP o sensor de cámara), el modelo de canal de cámara es virtual y no se corresponde directamente con ningún ISP real. Sin embargo, es lo suficientemente similar a los canales de procesamiento reales como para que pueda asignarlos a su hardware de manera eficiente. Además, es lo suficientemente abstracto como para permitir múltiples algoritmos y órdenes de operación diferentes sin comprometer la calidad, la eficiencia o la compatibilidad entre dispositivos.

La canalización de la cámara también admite activadores que el marco de la aplicación puede iniciar para activar cosas como el enfoque automático. También envía notificaciones al marco de la aplicación, notificando a las aplicaciones sobre eventos como un bloqueo de enfoque automático o errores.

Figura 2. Tubería de cámara

Tenga 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:

• La salida RAW de Bayer no se procesa dentro del ISP.
• Las estadísticas se generan a partir 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 la 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 API
Este es un breve resumen de los pasos para usar la API de la cámara de Android. Consulte la sección Inicio y secuencia de operación esperada para obtener un desglose detallado de estos pasos, incluidas las llamadas API.

1. Escuche y enumere los dispositivos de cámara.
2. Abra el dispositivo y conecte los oyentes.
3. Configure las salidas para el caso de uso objetivo (como captura, grabación, etc.).
4. Cree solicitudes para el caso de uso objetivo.
5. Captura/repetición de solicitudes y ráfagas.
6. Reciba metadatos de resultados y datos de imágenes.
7. Al cambiar de caso de uso, regrese al paso 3.

Resumen de operación HAL

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

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

Secuencia de inicio y operación esperada

Esta sección contiene una explicación detallada de los pasos esperados al utilizar la API de la cámara. Consulte plataforma/hardware/interfaces/cámara/ para ver las definiciones de interfaz HIDL.

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

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

Usando una sesión de cámara activa

1. El marco llama a ICameraDeviceSession::configureStreams() con una lista de flujos de entrada/salida al dispositivo HAL.
2. El marco solicita configuraciones predeterminadas para algunos casos de uso con llamadas a ICameraDeviceSession::constructDefaultRequestSettings() . Esto puede ocurrir en cualquier momento después de que ICameraDeviceSession haya sido creada por ICameraDevice::open .
3. El marco construye y envía la primera solicitud de captura a HAL con configuraciones basadas en uno de los conjuntos de configuraciones predeterminadas y con al menos un flujo de salida que el marco ha registrado anteriormente. Esto se envía al HAL con ICameraDeviceSession::processCaptureRequest() . El HAL debe bloquear la devolución de esta llamada hasta que esté listo para enviar la siguiente solicitud.
4. El marco continúa enviando solicitudes y llama 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 exponer para la captura), HAL llama a ICameraDeviceCallback::notify() con el mensaje SHUTTER, incluido el número de fotograma 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 processCaptureResult() para una solicitud, pero no se entregan resultados a una aplicación para una captura hasta después de que se llama notify() para esa captura.
6. Después de un retraso en la canalización, HAL comienza a devolver capturas completadas al marco con ICameraDeviceCallback::processCaptureResult() . Estos se devuelven en el mismo orden en que se enviaron las solicitudes. Pueden haber varias solicitudes en curso a la vez, dependiendo de la profundidad de la tubería del dispositivo HAL de la cámara.

Después de algún tiempo, ocurrirá una de las siguientes cosas:

• El marco puede dejar de enviar nuevas solicitudes, esperar a que se completen las capturas existentes (todos los buffers llenos, todos los resultados devueltos) y luego llamar a ICameraDeviceSession::configureStreams() nuevamente. Esto restablece el hardware de la cámara y la canalización para un nuevo conjunto de flujos de entrada/salida. Es posible que algunas transmisiones se reutilicen desde la configuración anterior. Luego, el marco continúa desde la primera solicitud de captura hasta el HAL, si queda al menos un flujo de salida registrado. (De lo contrario, primero se requiere ICameraDeviceSession::configureStreams() .)
• El marco puede llamar a ICameraDeviceSession::close() para finalizar la sesión de la cámara. Esto se puede llamar en cualquier momento cuando no haya otras llamadas activas desde el marco, aunque la llamada puede bloquearse hasta que se hayan completado todas las capturas en curso (todos los resultados devueltos, todos los buffers llenos). Después de que regresa la llamada close() , no se permiten más llamadas a ICameraDeviceCallback desde HAL. Una vez que la llamada close() está en marcha, el marco no puede llamar a ninguna otra función del dispositivo HAL.
• En caso de un error u otro evento asincrónico, HAL debe llamar ICameraDeviceCallback::notify() con el mensaje de error/evento apropiado. Después de regresar de una notificación de error fatal en todo el dispositivo, HAL debería actuar como si se hubiera llamado close() . Sin embargo, HAL debe cancelar o completar todas las capturas pendientes antes de llamar notify() , de modo que una vez que se llama notify() con un error fatal, el marco no recibirá más devoluciones de llamada del dispositivo. Los métodos además de close() deberían devolver -ENODEV o NULL después de que el método notify() regrese de un mensaje de error fatal.

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, consulte el nivel de hardware admitido .

Interacción entre la solicitud de captura de la aplicación, el control 3A y el proceso de procesamiento

Dependiendo de la configuración en el bloque de control 3A, la canalización de la cámara ignora algunos de los parámetros en la solicitud de captura de la aplicación y en su lugar utiliza los valores proporcionados por las rutinas de control 3A. Por ejemplo, cuando la exposición automática está activa, el tiempo de exposición, la duración del fotograma y los parámetros de sensibilidad del sensor se controlan mediante el algoritmo de la plataforma 3A y se ignoran los valores especificados por la aplicación. Los valores elegidos para el marco por las rutinas 3A deben informarse en los metadatos de salida. La siguiente tabla describe los diferentes modos del bloque de control 3A y las propiedades que controlan estos modos. Consulte el archivo platform/system/media/camera/docs/docs.html para obtener definiciones de estas propiedades.

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

• OFF: Este bloque de procesamiento está deshabilitado. Los bloques de mosaico, corrección de color y ajuste de curva de tono no se pueden desactivar.
• RÁPIDO: En este modo, es posible que el bloque de procesamiento no reduzca la velocidad de fotogramas de salida en comparación con el modo APAGADO, pero debería producir la mejor calidad posible dada esa restricción. Normalmente, esto se usaría para los modos de vista previa o grabación de video, o captura en ráfaga para imágenes fijas. En algunos dispositivos, esto puede ser equivalente al modo APAGADO (no se puede realizar ningún procesamiento sin reducir la velocidad de fotogramas) y en algunos dispositivos, esto puede ser equivalente al modo HIGH_QUALITY (la mejor calidad aún no reduce la velocidad de fotogramas).
• ALTA CALIDAD: en este modo, el bloque de procesamiento debe producir el resultado de la mejor calidad posible, reduciendo la velocidad de fotogramas de salida según sea necesario. Normalmente, esto se utilizaría para capturas fijas de alta calidad. Algunos bloques incluyen un control manual que se puede seleccionar opcionalmente en lugar de FAST o HIGH_QUALITY. Por ejemplo, el bloque de corrección de color admite una matriz de transformación de color, mientras que el ajuste de la curva de tono admite una curva de mapeo de tono global arbitraria.

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

• Resoluciones solicitadas de flujos de imágenes de salida
• Disponibilidad de modos de agrupamiento/salto en la cámara
• El ancho de banda de la interfaz de la cámara.
• El ancho de banda de los distintos bloques de procesamiento del ISP.

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

• El sensor de imagen siempre está configurado para generar la resolución más pequeña posible dados los tamaños de flujo de salida solicitados por la aplicación. La resolución más pequeña se define como al menos tan grande como el tamaño de flujo de salida más grande solicitado.
• Dado que cualquier solicitud puede utilizar cualquiera o todos los flujos de salida configurados actualmente, el sensor y el ISP deben configurarse para admitir el escalado de una única captura a todos los flujos al mismo tiempo.
• Las transmisiones JPEG actúan como transmisiones YUV procesadas para solicitudes para las cuales no están incluidas; en solicitudes en las que se hace referencia directa a ellos, actúan como secuencias JPEG.
• El procesador JPEG puede ejecutarse simultáneamente con el resto de la cámara, pero no puede procesar más de una captura a la vez.