Pular para o conteúdo principal

Processamento de imagem

Processamento de imagem transforma frames de câmera em sinais úteis: movimento, detecções, tracking, recortes, snapshots, notificações ou eventos de pipeline.

No produto padrão, visão começa em CPU com ONNX Runtime. Aceleração por GPU é um caminho de upgrade, não um requisito para a primeira instalação.

Comece simples​

Valide o acesso da câmera antes de adicionar processamento de imagem:

  1. Adicione a câmera.
  2. Confirme que snapshot ou fonte de vídeo funciona.
  3. Publique a fonte para live viewing, se necessário.
  4. Crie ou gere um pipeline simples.
  5. Adicione etapas de visão mais pesadas só depois que o stream estiver estável.

Isso evita depurar acesso da câmera, streaming e visão ao mesmo tempo.

Streaming, mapeamento e detecção são testes separados​

Não trate um stream de imagem estática como prova de que a detecção de pessoas funciona. Uma imagem estática é útil para Docker, alcance RTSP, snapshots, transmissão ao vivo, mapeamento de câmera e projeção na Visão 360. Mesmo assim, ela pode não gerar nenhuma detecção.

Detecção real de pessoa precisa de todos estes pontos:

  • um artefato de modelo de detecção pronto no servidor de processamento selecionado;
  • uma fonte alcançável a partir desse servidor de processamento;
  • frames que realmente devem entrar no pipeline;
  • movimento suficiente ou um caminho explícito sem gate de movimento quando o pipeline usa camera.motion_gate;
  • operadores de tracking, notificação e mapeamento configurados para o resultado que você quer validar.

Para teste comum de câmera, use vídeo em loop, webcam ou câmera real. Para um smoke determinístico de produto que valida mapping -> tracking -> notify -> pin sem depender da acurácia do RF-DETR, use o caminho oficial de fonte de detecção sintética.

Processamento local em CPU​

Processamento em CPU é o padrão porque é mais fácil de instalar e funciona em mais ambientes.

Ele é adequado para:

  • testes iniciais;
  • poucas câmeras;
  • snapshots ocasionais;
  • pipelines simples;
  • máquinas com folga de CPU.

Ele pode se tornar limitado quando várias câmeras decodificam vídeo e executam modelos de visão ao mesmo tempo, especialmente em dispositivos ARM pequenos.

Processing servers​

Use um processing server quando a máquina origin ou o add-on Home Assistant OS não deve lidar com trabalho pesado de câmera.

Motivos comuns:

  • Home Assistant roda em Raspberry Pi ou mini PC pequeno;
  • outra máquina tem CPU melhor ou GPU NVIDIA;
  • a decodificação de câmera deve acontecer mais perto das câmeras;
  • você quer isolar experimentos do origin principal.

Veja Processing server em Linux e macOS, Processing server como serviço Windows e Processing server em Docker.

Upgrades de GPU​

Instale o Toposync primeiro, depois adicione aceleração se os diagnósticos mostrarem que ela é útil.

  • GPU no Windows: toposync-vision-directml.
  • NVIDIA nativo ou Docker CUDA: toposync-vision-cuda.
  • CPU padrão: nenhum pacote extra de GPU.

Veja Compatibilidade antes de escolher um caminho de GPU.

Limites práticos​

Para testes em early access:

  • comece com uma câmera;
  • prefira streams de menor resolução para análise contínua;
  • mantenha fontes de maior resolução para tela cheia ou inspeção direcionada;
  • evite rodar vários pipelines pesados de visão em hardware do porte de Raspberry Pi;
  • delegue decodificação repetida e cargas ONNX quando possível.

Solução de problemas​

Detecção está lenta​

Reduza resolução, diminua frame rate, teste uma câmera por vez ou mova o pipeline para um processing server.

A câmera funciona, mas o pipeline não​

Confirme que o pipeline lê a fonte de câmera pretendida e que processing_server_id aponta para o servidor onde a fonte é alcançável.

Pacote de GPU instalado, mas CPU ainda é usada​

Confira diagnósticos de runtime e ordem de providers. O pacote de GPU só ajuda quando driver, runtime, plataforma e provider do ONNX Runtime estão disponíveis.