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 todo 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. sensor manual, lente, y control de flash; Modos de operación 3A; Control de procesamiento de RAW a YUV y la generación de estadísticas. Esto te da más control sobre los resultados salida y procesamiento. Múltiples solicitudes pueden estar en tránsito a la vez enviar solicitudes no implica un bloqueo. Y las solicitudes siempre se procesan el orden en que se reciben.

Figura 1: Modelo de cámara

HAL y subsistema de la cámara

El subsistema de la cámara incluye implementaciones para los componentes de la cámara. como el algoritmo 3A y los controles de procesamiento. La HAL de la cámara proporciona interfaces para que implementes las versiones de estos componentes. Para mantener la compatibilidad multiplataforma entre varios fabricantes de dispositivos y Proveedores del procesador de señales de imagen (ISP o sensor de la cámara), la canalización 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 puedas asignarla a tu el hardware con eficiencia. Además, es lo suficientemente abstracto como para permitir varias diferentes algoritmos y órdenes de operación sin comprometer calidad, eficiencia o compatibilidad multidispositivo.

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 de la app, que notifica a las apps sobre eventos, como errores o bloqueos de enfoque automático.

Figura 2: Canalización de cámara

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

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

Resumen del uso de la API
Este es un breve resumen de los pasos para usar la API de cámara de Android. Consulta la Sección de secuencia de operación de inicio y esperada para 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. Configurar las salidas para el caso de uso objetivo (como captura estática, grabación, etcétera).
4. Crea solicitudes para el caso de uso objetivo.
5. Captura/repite solicitudes y aumentos de actividad.
6. Recibir metadatos y datos de imágenes de los resultados
7. Cuando cambies de caso de uso, regresa 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 imagen de salida.
• Primero en entrar, primero en salir para las solicitudes y los resultados, y para las transmisiones a las que hace referencia solicitudes posteriores.
• Las marcas de tiempo deben ser idénticas para todos los resultados de una solicitud determinada, de modo que puedes unirlas si es necesario.
• Toda la configuración y el estado de la captura (excepto las rutinas 3A) son 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

Esta sección contiene una explicación detallada de los pasos que se esperan para usar la API de la cámara. Consulta platform/hardware/interfaces/camera/ para la interfaz HIDL definiciones

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 presente proveedores de cámaras que implementan el ICameraProvider. Si dicho proveedor o proveedores de servicios están presentes, el marco intentará establecer una conexión.
2. En el framework, se enumeran los dispositivos de cámara mediante ICameraProvider::getCameraIdList()
3. El framework crea una instancia de un nuevo ICameraDevice llamando al respectivo ICameraProvider::getCameraDeviceInterface_VX_X()
4. El framework llama a ICameraDevice::open() para crear un nuevo elemento. 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 transmisiones 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 se realice el cambio de ICameraDeviceSession creado por ICameraDevice::open.
3. El framework construye y envía la primera solicitud de captura a la HAL con de Terraform en función de uno de los conjuntos de parámetros de configuración predeterminados y con, al menos, uno de salida que el framework registró anteriormente. Esto se envió al HAL con ICameraDeviceSession::processCaptureRequest(). La HAL debe bloquear la devolución de esta llamada hasta que esté lista para la siguiente que se envíe la solicitud.
4. El framework continúa enviando solicitudes y llamadas. 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 el captura), la HAL llama al objeto ICameraDeviceCallback::notify() con el mensaje SHUTTER, incluido el número de fotograma y la marca de tiempo de inicio de la exposición. No es necesario que esta devolución de llamada de notificación ocurra antes de la primera processCaptureResult() para una solicitud, pero no hay resultados entregados a una aplicación para su captura hasta después de 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 a el framework con ICameraDeviceCallback::processCaptureResult(). Estas se muestran en el mismo orden en que se enviaron las solicitudes. Múltiples las solicitudes pueden estar en tránsito a la vez, según la profundidad de la canalización del dispositivo HAL de la cámara.

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

• Es posible que el framework deje de enviar solicitudes nuevas, espere se completen las capturas existentes (todos los búferes se completaron, todos los resultados que se muestra) y, luego, llama a ICameraDeviceSession::configureStreams() de nuevo. Esto restablece el hardware de la cámara y la canalización para un nuevo conjunto transmisiones de entrada y salida. Es posible que se reutilicen algunas transmisiones configuración. Luego, el framework continúa desde la primera solicitud de captura al HAL, si al menos una de la 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 a este método en cualquier momento cuando no haya otras llamadas del framework estén activas, aunque la llamada podría bloquearse hasta que las capturas en tránsito (todos los resultados devueltos, todos los búferes completado). Una vez que se devuelva la llamada a close(), no habrá más llamadas a La HAL permite ICameraDeviceCallback. Una vez que close() está en curso; el framework no puede llamar a ninguna otra Funciones del dispositivo HAL.
• En caso de que se produzca un error o algún otro evento asíncrono, la HAL debe llamar ICameraDeviceCallback::notify() por la configuración mensaje de error/evento. Después de regresar de una notificación de error irrecuperable en todo el dispositivo, la HAL debe actuar como si se hubiera llamado a close() en ella. Sin embargo, la HAL debe cancelar o completa todas las capturas pendientes antes de llamar a notify(). para que una vez Se llama a notify() con un error grave, el framework no recibir más devoluciones de llamada del dispositivo. Además de los métodos Se debería mostrar close() -ENODEV o NULL después de que el método notify() muestre una respuesta irrecuperable. mensaje de error.

Figura 4: Flujo operativo de la cámara

Niveles de hardware

Los dispositivos de cámara pueden implementar varios niveles de hardware según su capacidades de integración. Para obtener más información, consulta 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 usa los valores proporcionadas por las rutinas de control de 3A. Por ejemplo, cuando la exposición automática es activo, el tiempo de exposición, la duración de los fotogramas y los parámetros de sensibilidad del son controlados por el algoritmo 3A de la plataforma y cualquier valor se ignoran. Se deben informar los valores elegidos para el fotograma por las rutinas 3A en los metadatos de salida. En la siguiente tabla, se describen los diferentes modos del un bloque de control y las propiedades que controlan estos modos. Consulta el Platform/system/media/camera/docs/docs.html para ver las definiciones de estas propiedades.

Todos los controles del bloque de procesamiento de imágenes de la Figura 2 operan en un un principio similar y, por lo general, cada bloque tiene tres modos:

• DESACTIVADO: Este bloque de procesamiento está inhabilitado. La eliminación de mosaico, la corrección de colores y Los bloques de ajuste de curva de tono no se pueden inhabilitar.
• RÁPIDA: En este modo, es posible que el bloque de procesamiento no ralentice el fotograma de salida. en comparación con el modo Apagado, pero debería producir la mejor de salida, se puede aplicar esa restricción. Por lo general, se usa para 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 disminuye la velocidad de fotogramas) y, en algunos dispositivos, esto puede ser equivalente a Modo HIGH_QUALITY (la mejor calidad no disminuye la velocidad de fotogramas).
• HIGH_QUALITY: en este modo, el bloque de procesamiento debería producir la mejor y de calidad, lo que ralentiza la velocidad de fotogramas de salida según sea necesario. Por lo general, se usa para capturas estáticas de alta calidad. Algunos bloques incluyen un control manual que puede seleccionarse opcionalmente en lugar de FAST o HIGH_QUALITY. Por ejemplo, el bloque de corrección de colores admite un color de transformación de datos, mientras que el ajuste de la curva de tono admite una cadena de la curva de asignación de tonos.

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

• Resoluciones solicitadas de transmisiones de imágenes de salida
• Disponibilidad de los modos de discretización/omisión en la imagen
• El ancho de banda de la interfaz del generador de imágenes
• El ancho de banda de los distintos bloques de procesamiento del ISP

Dado que estos factores pueden variar mucho entre los distintos ISP y sensores, el la interfaz de la HAL de la cámara intenta abstraer las restricciones de ancho de banda de manera con el modelo más eficaz 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 según los tamaños de flujo de salida solicitados por la app. La más pequeña resolución se define como al menos tan grande como la mayor el tamaño del flujo de salida.
• Debido a que cualquier solicitud puede usar cualquiera o todas las transmisiones de salida configuradas actualmente, 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 incluido; en las solicitudes en las que se hace referencia directamente, actúan como transmisiones JPEG.
• El procesador JPEG puede ejecutarse simultáneamente al resto de la canalización de la cámara no se puede procesar más de una captura a la vez.