Subsistema de HAL

Solicitudes

El framework de la app emite 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, el control manual del sensor, el objetivo y el flash, los modos de funcionamiento de 3A, el control del procesamiento de RAW a YUV y la generación de estadísticas. Esto permite un mayor control sobre el procesamiento y la salida de los resultados. Se pueden realizar varias solicitudes a la vez, y el envío de solicitudes no bloquea el proceso. 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 las implementaciones para los 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 entre plataformas de varios fabricantes de dispositivos y proveedores de procesadores de señales de imagen (ISP o sensores 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 asignarla 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 entre dispositivos.

La canalización de la cámara también admite activadores que el framework de la app puede iniciar para activar funciones como el enfoque automático. También envía notificaciones al framework de la app para informar 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 Bayer RAW no se procesa dentro del ISP.
• Las estadísticas se generan a partir de los datos sin procesar del sensor.
• Los distintos bloques de procesamiento que convierten los datos sin procesar del sensor en YUV se encuentran en un orden arbitrario.
• Si bien se muestran varias unidades de ajuste, todas las unidades de ajuste 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. 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. Enumerar y escuchar 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 captura de imágenes, grabación, etc.).
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 de caso de uso, vuelve al paso 3.

Resumen de la operación de HAL

• El framework envía solicitudes asíncronas para capturas.
• 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.
• Primero en entrar, primero en salir para las solicitudes y los resultados, y para los flujos a los 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 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 la HAL de la cámara

Secuencia de inicio y funcionamiento esperados

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

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 los proveedores de cámaras presentes que implementan la interfaz ICameraProvider. Si hay uno o más proveedores de ese tipo, el framework intentará 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() correspondiente.
4. El framework llama a ICameraDevice::open() para crear una nueva sesión de captura activa ICameraDeviceSession.

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 el objeto ICameraDeviceSession.
3. El framework crea y envía la primera solicitud de captura al HAL con parámetros de configuración basados en uno de los conjuntos de parámetros de configuración predeterminados y con al menos un flujo de salida que el framework registró anteriormente. Esto se envía al HAL con ICameraDeviceSession::processCaptureRequest(). El HAL debe bloquear el regreso de esta llamada hasta que esté listo para que se envíe la siguiente solicitud.
4. El framework sigue enviando solicitudes y llamando 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), el HAL llama a ICameraDeviceCallback::notify() con el mensaje SHUTTER, que incluye el número de fotograma y la marca de tiempo del 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 que se llama a notify() para esa captura.
6. Después de un cierto retraso de la canalización, el HAL comienza a devolver capturas completadas al framework con ICameraDeviceCallback::processCaptureResult(). Se muestran 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, ocurrirá una de las siguientes situaciones:

• El framework puede dejar de enviar solicitudes nuevas, esperar a que se completen las capturas existentes (se llenen todos los búferes y se muestren todos los resultados) y, luego, volver a llamar a ICameraDeviceSession::configureStreams(). Esto restablece el hardware y el canal de la cámara para un nuevo conjunto de flujos de entrada y salida. Es posible que se reutilicen algunos flujos 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 este método en cualquier momento en que no haya otras llamadas activas del framework, aunque la llamada puede 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 muestre la llamada a close(), el HAL no podrá realizar más llamadas a ICameraDeviceCallback. Una vez que la llamada a close() está en curso, es posible que el framework no llame a ninguna otra función del dispositivo HAL.
• En caso de error o de otro evento asíncrono, el HAL debe llamar a ICameraDeviceCallback::notify() con el mensaje de error o evento apropiado. Después de volver de una notificación de error grave en todo el dispositivo, el HAL debe actuar como si se hubiera llamado a close() en él. Sin embargo, el 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 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 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 de 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, en su lugar, 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 de la plataforma 3A, y se ignoran todos los valores especificados por la app. Los valores elegidos para el fotograma por las rutinas de 3A se deben informar 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 las definiciones de estas propiedades.

Parámetro	Estado	Propiedades controladas
android.control.aeMode	APAGADO	Ninguno
	ACTIVADA	android.sensor.exposureTime android.sensor.frameDuration android.sensor.sensitivity android.lens.aperture (si es compatible) android.lens.filterDensity (si es compatible)
	ON_AUTO_FLASH	Todo está ACTIVADO, además de android.flash.firingPower, android.flash.firingTime y android.flash.mode
	ON_ALWAYS_FLASH	Igual que ON_AUTO_FLASH
	ON_AUTO_FLASH_RED_EYE	Igual que ON_AUTO_FLASH
android.control.awbMode	APAGADO	Ninguno
	WHITE_BALANCE_*	android.colorCorrection.transform. Son ajustes específicos de la plataforma si android.colorCorrection.mode es FAST o HIGH_QUALITY.
android.control.afMode	APAGADO	Ninguno
	FOCUS_MODE_*	android.lens.focusDistance
android.control.videoStabilization	APAGADO	Ninguno
	ACTIVADA	Se puede ajustar android.scaler.cropRegion para implementar la estabilización de video
android.control.mode	APAGADO	AE, AWB y AF están inhabilitados
	AUTOMÁTICO	Se usan los parámetros de configuración individuales de AE, AWB y AF
	SCENE_MODE_*	Puede anular todos los parámetros mencionados anteriormente. Los controles individuales de 3A están inhabilitados.

Los controles del bloque Image Processing de la figura 2 funcionan según un principio similar y, en general, cada bloque tiene tres modos:

• OFF: Este bloque de procesamiento está inhabilitado. Los bloques de ajuste de la curva de tonos, corrección de color y demosaico no se pueden inhabilitar.
• RÁPIDO: En este modo, es posible que el bloque de procesamiento no ralentice la frecuencia de fotogramas de salida en comparación con el modo APAGADO, pero, de lo contrario, debería producir la salida de mejor calidad posible dada esa restricción. Por lo general, se usa para los modos de vista previa o grabación de video, o para la captura en ráfaga de imágenes fijas. En algunos dispositivos, esto puede ser equivalente al modo OFF (no se puede realizar ningún procesamiento sin reducir la velocidad de fotogramas), y en otros, puede ser equivalente al modo HIGH_QUALITY (la mejor calidad no reduce la velocidad de fotogramas).
• HIGH_QUALITY: En este modo, el bloque de procesamiento debe producir el resultado de mejor calidad posible y reducir la velocidad de fotogramas de salida según sea necesario. Por lo general, se usa 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 los flujos de imágenes de salida
• Disponibilidad de los modos de discretización y omisión en el sensor de imágenes
• 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 los diferentes ISP y sensores, la interfaz de la 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, según 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 más grande solicitado.
• 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 ajuste de una sola captura a todos los flujos al mismo tiempo.
• Los flujos JPEG actúan como flujos YUV procesados para las solicitudes en las que no se incluyen. En las solicitudes en las que se hace referencia directa a ellos, actúan como flujos 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.