Subsistema de HAL

En esta página, se describe el subsistema de HAL, incluidas las solicitudes, el subsistema de cámara, la secuencia de inicio y operación, los niveles de hardware y las interacciones.

Solicitudes

El framework de la app emite solicitudes de resultados capturados al subsistema de 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; el control manual del sensor, la lente y el flash; los modos de operación 3A; el control de procesamiento de RAW a YUV; y la generación de estadísticas. Esto permite un control mucho mayor sobre la salida y el procesamiento de los resultados. Se pueden realizar varias solicitudes a la vez, y el envío de solicitudes no es bloqueador. Además, las solicitudes siempre se procesan en el orden en que se reciben.

Figura 1: Modelo de cámara

Subsistema de HAL y cámara

El subsistema de cámara incluye implementaciones para componentes de la canalización de la cámara como el algoritmo 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ñales 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, notificando a las apps sobre 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:

• La salida de Bayer RAW 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 varias unidades de escala y recorte, todas las unidades de escalador 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 la API

Este es un breve resumen de los pasos para usar la API de la cámara de Android. Consulta la sección Secuencia de inicio y operación esperada 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 objetivo (como la captura o la grabación de imágenes fijas).
4. Crea solicitudes para el caso de uso objetivo.
5. Captura o repite solicitudes y ráfagas.
6. Recibe metadatos de resultados y datos de imágenes.
7. Cuando cambies los casos 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. Además, para cada solicitud, debe producir 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 las solicitudes posteriores.
• Las marcas de tiempo deben ser idénticas para todas las salidas de una solicitud determinada, de modo que el framework pueda hacer coincidir si es necesario.
• Toda la configuración y el estado de captura (excepto las rutinas 3A) están encapsulados en las solicitudes y los resultados.

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

Secuencia de inicio y operación esperada

En esta sección, se incluye una explicación detallada de los pasos esperados cuando se usa la API de la cámara. Para obtener definiciones de interfaz HIDL, consulta platform/hardware/interfaces/camera/.

Enumera y abre dispositivos de cámara, y crea una sesión activa

1. Después de la inicialización, el framework comienza a escuchar cualquier proveedor de cámara presente que implemente la ICameraProvider interfaz. Si hay uno o más proveedores de este tipo, el framework intenta establecer una conexión.
2. El framework enumera los dispositivos de cámara a través de ICameraProvider::getCameraIdList.
3. El framework crea una instancia de un nuevo ICameraDevice llamando al ICameraProvider::getCameraDeviceInterface_VX_X respectivo.
4. El framework llama a ICameraDevice::open para crear una nueva sesión de captura activa ICameraDeviceSession.

Usa una sesión de cámara activa

1. El framework llama a ICameraDeviceSession::configureStreams con una lista de transmisiones de entrada/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 el ICameraDeviceSession sea creado por ICameraDevice::open.
3. El framework construye y envía la primera solicitud de captura a la HAL con configuración basada en uno de los conjuntos de configuración predeterminada y con al menos una transmisión de salida que el framework registró anteriormente. 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 que se envíe la siguiente solicitud.
4. El framework continúa enviando solicitudes y llama a ICameraDeviceSession::constructDefaultRequestSettings para obtener búferes de configuración predeterminada 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), la 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 processCaptureResult llamada para una solicitud, pero no se entregan resultados a una app para una captura hasta que se llama a notify para esa captura.
6. Después de un retraso en la canalización, la HAL comienza a devolver las capturas completadas al framework con ICameraDeviceCallback::processCaptureResult. Estos se devuelven en el mismo orden en que se enviaron las solicitudes. Se pueden realizar 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, ocurre una de las siguientes situaciones:

• El framework deja de enviar solicitudes nuevas, espera a que se completen las capturas existentes (se llenan todos los búferes y se devuelven todos los resultados) y, luego, vuelve a llamar a ICameraDeviceSession::configureStreams de nuevo. Esto restablece el hardware y la canalización de la cámara para un nuevo conjunto de transmisiones de entrada/salida. Se pueden reutilizar algunas transmisiones de la configuración anterior. Luego, el framework continúa desde la primera solicitud de captura a la HAL, si queda al menos una transmisión de salida registrada. (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 en cualquier momento cuando no haya otras llamadas activas del framework, aunque la llamada podría bloquearse hasta que se completen todas las capturas en curso (se devuelvan todos los resultados y se llenen todos los búferes ). Después de que se devuelva la llamada close, la HAL no permitirá más llamadas a ICameraDeviceCallback. Una vez que la close llamada esté en curso, el framework no podrá llamar a ninguna otra función del dispositivo HAL.
• En caso de un error o cualquier otro evento asíncrono, la 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, la HAL debe actuar como si close se hubiera llamado en ella. Sin embargo, la HAL debe cancelar o completar todas las capturas pendientes antes de llamar a notify, de modo que, después de que se llame a notify con un error fatal, el framework no reciba más devoluciones de llamada del dispositivo. Los métodos además de close deben mostrar -ENODEV o NULL después de que el método notify muestre 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, consulta el nivel de hardware compatible.

Interacción entre la solicitud de captura de la app, 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 app y usa los valores proporcionados por las rutinas de control 3A. Por ejemplo, cuando la exposición automática está activa, los parámetros de tiempo de exposición, duración del fotograma y sensibilidad del sensor se controlan con el algoritmo 3A de la plataforma, y se ignoran todos los valores especificados por la app. Los valores elegidos para el fotograma por las rutinas 3A 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.

Parámetro	Estado	Propiedades controladas
android.control.aeMode	OFF	Ninguno
	ON	android.sensor.exposureTime, android.sensor.frameDuration, android.sensor.sensitivity, android.lens.aperture (si es compatible) y android.lens.filterDensity (si es compatible).
	ON_AUTO_FLASH	Todo está ON, además de android.flash.firingPower, android.flash.firingTime y android.flash.mode.
	ON_ALWAYS_FLASH	Es igual que ON_AUTO_FLASH.
	ON_AUTO_FLASH_RED_EYE	Es igual que ON_AUTO_FLASH.
android.control.awbMode	OFF	Ninguno
	WHITE_BALANCE_*	android.colorCorrection.transform. Ajustes específicos de la plataforma si android.colorCorrection.mode es FAST o HIGH_QUALITY.
android.control.afMode	OFF	Ninguno
	FOCUS_MODE_*	android.lens.focusDistance
android.control.videoStabilization	OFF	Ninguno
	ON	Puede ajustar android.scaler.cropRegion para implementar la estabilización de video.
android.control.mode	OFF	AE, AWB y AF están inhabilitados.
	AUTO	Se usan las configuraciones individuales de AE, AWB y AF.
	SCENE_MODE_*	Puede anular todos los parámetros enumerados anteriormente. Los controles 3A individuales están inhabilitados.

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

• OFF: Este bloque de procesamiento está inhabilitado. No se pueden inhabilitar los bloques de ajuste de la curva de tonos, la corrección de color y la demosaización.
• FAST: En este modo, es posible que el bloque de procesamiento no ralentice la velocidad de fotogramas de salida en comparación con el modo OFF pero, de lo contrario, debería producir la salida de mejor calidad posible dada esa restricción. Por lo general, se usaría para vista previa o grabación de video, o la captura en ráfaga para imágenes fijas. En algunos dispositivos, esto podría ser equivalente al modo OFF (no se puede realizar ningún procesamiento sin ralentizar la velocidad de fotogramas) y, en algunos dispositivos, esto podría ser equivalente al 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 usaría para la captura de 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 color admite una matriz de transformación de color, mientras que el ajuste de la curva de tonos admite una curva de asignación de tonos 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 modos de agrupamiento o omisión en el generador 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 de ISP

Estos factores pueden variar mucho entre diferentes ISP y sensores, por lo que 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 transmisión de salida solicitados por la app. La resolución más pequeña se define como al menos tan grande como el tamaño de transmisión de salida solicitado más grande.
• Cualquier solicitud puede usar cualquiera o todas las transmisiones de salida configuradas actualmente, por lo que el sensor y el ISP deben configurarse para admitir el escalamiento de una sola captura a todas las transmisiones al mismo tiempo.
• Las transmisiones JPEG actúan como transmisiones YUV procesadas para las solicitudes para las que no se incluyen ; en las solicitudes en las que se hace referencia directa a ellas, 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.