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 cosas como la resolución y el formato de píxeles; sensor manual, lente y control de flash; Modos de funcionamiento 3A; Control de procesamiento RAW a YUV; y generación de estadísticas. Esto permite mucho más control sobre la salida y el procesamiento de los resultados. Múltiples solicitudes pueden estar en curso a la vez, y el envío de solicitudes no es un bloqueo. Y las solicitudes siempre se procesan en el orden en que se reciben.

Figura 1. Modelo de cámara

El HAL y el subsistema de cámara

El subsistema de la cámara incluye las implementaciones de los componentes de la canalización de la cámara, como el algoritmo 3A y los controles de procesamiento. La cámara HAL proporciona interfaces para que implemente sus 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 tubería de la cámara es virtual y no se corresponde directamente con ningún ISP real. Sin embargo, es lo suficientemente similar a las canalizaciones de procesamiento reales para que pueda asignarlo 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 disparadores que el marco de la aplicación puede iniciar para activar cosas como el enfoque automático. También envía notificaciones de regreso al marco de la aplicación, notificando aplicaciones de eventos como un bloqueo de enfoque automático o errores.

Figura 2. Canalización de la 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 del sensor sin procesar.
• Los diversos bloques de procesamiento que convierten los datos del sensor sin procesar a YUV están en un orden arbitrario.
• Si bien se muestran múltiples unidades de escala y recorte, todas las unidades de escalado 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íxel 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. Consulte la sección Inicio y secuencia de operación esperada para obtener un desglose detallado de estos pasos, incluidas las llamadas a la API.

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

Resumen de operaciones HAL

• Las solicitudes asíncronas de capturas provienen del marco.
• El dispositivo HAL debe procesar las solicitudes en orden. Y para cada solicitud, produzca 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 flujos a los que se hace referencia en solicitudes posteriores.
• Las marcas de tiempo deben ser idénticas para todos los resultados de una solicitud determinada, de modo que el marco pueda unirlos si es necesario.
• Toda la configuración y el estado de captura (excepto las rutinas 3A) se encapsulan en las solicitudes y los resultados.

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

Arranque y secuencia esperada de operación

Esta sección contiene una explicación detallada de los pasos esperados al usar la API de la cámara. Consulte plataforma/hardware/interfaces/cámara/ para obtener 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 cualquier proveedor de cámara presente que implemente 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 cámara a través ICameraProvider::getCameraIdList() .
3. El marco crea una instancia de un nuevo ICameraDevice llamando al respectivo ICameraProvider::getCameraDeviceInterface_VX_X() .
4. El marco llama a ICameraDevice::open() para crear una nueva sesión de captura activa ICameraDeviceSession.

Uso de 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 ICameraDevice::open haya creado ICameraDeviceSession.
3. El marco construye y envía la primera solicitud de captura a la HAL con configuraciones basadas en uno de los conjuntos de configuraciones predeterminadas y con al menos un flujo de salida que ha sido registrado anteriormente por el marco. Esto se envía a la HAL con ICameraDeviceSession::processCaptureRequest() . La HAL debe bloquear la devolución de esta llamada hasta que esté lista 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 cuadro 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 de processCaptureResult() para una solicitud, pero no se entregan resultados a una aplicación para una captura hasta después de que se llame a la notify() para esa captura.
6. Después de un retraso en la canalización, HAL comienza a devolver las capturas completadas al marco con ICameraDeviceCallback::processCaptureResult() . Estos se devuelven en el mismo orden en que se enviaron las solicitudes. Varias solicitudes pueden estar en curso a la vez, según la profundidad de canalización del dispositivo HAL de la cámara.

Después de un tiempo, ocurrirá uno de los siguientes:

• El marco puede dejar de enviar nuevas solicitudes, esperar a que se completen las capturas existentes (todos los búfer llenos, todos los resultados devueltos) y luego llamar a ICameraDeviceSession::configureStreams() nuevamente. Esto restablece el hardware y la canalización de la cámara para un nuevo conjunto de flujos de entrada/salida. Es posible que se reutilicen algunos flujos de la configuración anterior. Luego, el marco continúa desde la primera solicitud de captura hasta la 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 hay otras llamadas del marco activas, aunque la llamada puede bloquearse hasta que se hayan completado todas las capturas en curso (se devuelvan todos los resultados, se llenen todos los búferes). 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, es posible que el marco no llame a ninguna otra función del dispositivo HAL.
• En caso de error u otro evento asíncrono, HAL debe llamar a 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 a close() . Sin embargo, HAL debe cancelar o completar todas las capturas pendientes antes de llamar notify() , de modo que una vez que se llame a notify() con un error fatal, el marco no recibirá más devoluciones de llamada del dispositivo. Los métodos además de close() deben devolver -ENODEV o NULL después de que el método de 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 la canalización de procesamiento

Según la configuración del bloque de control 3A, la canalización de la cámara ignora algunos de los parámetros de 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 cuadro y los parámetros de sensibilidad del sensor son controlados por el algoritmo de la plataforma 3A y se ignora cualquier valor especificado por la aplicación. Los valores elegidos para el cuadro 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 son controladas por estos modos. Consulte el archivo platform/system/media/camera/docs/docs.html para ver las definiciones de estas propiedades.

Todos los controles en el bloque Procesamiento de imágenes en la Figura 2 funcionan con un principio similar y, en general, cada bloque tiene tres modos:

• APAGADO: Este bloque de procesamiento está deshabilitado. Los bloques de ajuste de demostración, corrección de color y curva de tono no se pueden desactivar.
• RÁPIDO: en este modo, es posible que el bloque de procesamiento no disminuya la velocidad de fotogramas de salida en comparación con el modo APAGADO, pero de lo contrario debería producir la salida de mejor calidad que pueda dada esa restricción. Por lo general, 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 ralentizar la velocidad de fotogramas), y en algunos dispositivos, esto 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, ralentizando la velocidad de fotogramas de salida según sea necesario. Por lo general, esto se usaría para la captura de imágenes fijas de alta calidad. Algunos bloques incluyen un control manual que se puede seleccionar opcionalmente en lugar de RÁPIDO o ALTA_CALIDAD. 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 asignación de tono global arbitraria.

La velocidad de fotogramas máxima que puede admitir un subsistema de cámara depende de muchos factores:

• Resoluciones solicitadas de flujos de imágenes de salida
• Disponibilidad de modos binning/skipping en la cámara
• El ancho de banda de la interfaz del generador de imágenes
• El ancho de banda de los diversos bloques de procesamiento de 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 solicitado más grande.
• Dado que cualquier solicitud puede usar cualquiera o todos los flujos de salida configurados actualmente, el sensor y el ISP deben configurarse para admitir el escalado de una sola captura a todos los flujos al mismo tiempo.
• Los flujos JPEG actúan como flujos YUV procesados ​​para solicitudes para las que no están incluidos; en las solicitudes en las que se les hace referencia directa, actúan como secuencias JPEG.
• El procesador JPEG puede ejecutarse simultáneamente con el resto de la canalización de la cámara, pero no puede procesar más de una captura a la vez.