OpenRadarBLOG

Densidade de pixel: a conta que decide se sua câmera pode detectar algo

Resposta curta

Densidade de pixel é quantos pixels da imagem cobrem um metro real da cena. A norma IEC 62676-4:2014 associa quatro objetivos operacionais a quatro patamares de densidade: 25 px/m para detectar, 63 px/m para observar, 125 px/m para reconhecer e 250 px/m para identificar uma pessoa.

A conta é uma divisão: pixels na horizontal divididos pela largura, em metros, do trecho de cena que a câmera enquadra. Uma câmera de 1920 px de largura enquadrando 20 m de rua entrega 96 px/m — dá para detectar e observar, não dá para reconhecer. Resolução alta em enquadramento largo não compra detalhe.

Densidade de pixel não é resolução: é resolução dividida por cena

Especificação de câmera é vendida em megapixels, e projeto de monitoramento é resolvido em pixels por metro. São coisas diferentes, e a confusão entre as duas é a causa mais comum de câmera nova que não resolve o problema antigo.

A resolução é uma propriedade do sensor. A densidade de pixel é uma propriedade da instalação: depende da resolução, da lente, da distância e do enquadramento. A mesma câmera de 4 MP entrega detalhe sobrando num portão de 3 m de largura e entrega quase nada num pátio de 60 m. O sensor não mudou; a cena mudou.

Densidade de pixel é o número de pixels disponíveis para representar um trecho da cena, normalmente expresso em pixels por metro ou por pé.

Axis Communications, Pixel density based on IEC 62676-4:2014 — paráfrase

De onde vêm os 25, 63, 125 e 250 px/m?

O modelo parte do rosto humano. A pergunta original da norma é quantos pixels são necessários atravessando a largura de um rosto para cumprir cada objetivo: 4 pixels para detectar que há alguém, 10 para observar características, 20 para reconhecer uma pessoa já vista antes, 40 para identificar. Como a largura média de um rosto humano é assumida em 16 cm, os valores por rosto convertem diretamente em valores por metro.

Patamares de densidade de pixel por objetivo operacional (DORI). Valores conforme a Axis Communications a partir da IEC 62676-4:2014.
Objetivo Px por rosto Px por metro O que fica possível
Detectar 4 px 25 px/m Determinar se há ou não alguém presente.
Observar 10 px 63 px/m Contar quantas pessoas há e ver características, como roupa distintiva.
Reconhecer 20 px 125 px/m Decidir se a pessoa mostrada é a mesma que o observador já viu antes.
Identificar 40 px 250 px/m Identificar um indivíduo.

Repare no salto: identificar exige dez vezes a densidade de detectar. É por isso que "a câmera viu o carro passar" e "a câmera identificou quem estava dirigindo" são requisitos de projetos diferentes, com lentes diferentes e, muitas vezes, com câmeras diferentes na mesma posição.

Quantos metros de cena a minha câmera cobre?

Essa é a única medida que falta para fechar a conta, e ela não está no datasheet — está na parede. O caminho de campo é direto: enquadre a cena como ela vai ficar em operação, coloque no ponto de interesse um objeto de largura conhecida (uma trena aberta em 1 m resolve), e veja que fração da largura da imagem esse metro ocupa. Se 1 m real ocupa um décimo da largura da imagem, a densidade é um décimo da resolução horizontal.

A tabela abaixo é aritmética pura, para uma câmera de 1920 px de largura — o cálculo é a resolução horizontal dividida pela largura da cena.

Densidade resultante para uma imagem de 1920 px de largura, por largura de cena enquadrada. Cálculo direto, sem correção de distorção de lente.
Cena enquadrada Densidade Maior objetivo alcançado
4 m480 px/mIdentificar
8 m240 px/mReconhecer
15 m128 px/mReconhecer
20 m96 px/mObservar
30 m64 px/mObservar
40 m48 px/mDetectar
77 m25 px/mDetectar (no limite)

Duas leituras práticas saem daí. A primeira: passar de 1080p para 4K dobra a densidade no mesmo enquadramento — mas alargar o enquadramento em duas vezes devolve a perda inteira. A segunda: se o projeto exige reconhecer, o enquadramento útil de uma câmera de 1920 px de largura fica em torno de 15 m. Cobrir 40 m de rua com uma câmera só é uma decisão de detecção, não de reconhecimento — e vale escrever isso no projeto antes de alguém cobrar reconhecimento da gravação.

Nota

A densidade não é uniforme no quadro. Ela é maior no centro e cai para as bordas, por causa da distorção da lente e do ângulo com que a cena é vista. Os cálculos de distância DORI publicados em datasheet usam o centro da imagem como referência. Portanto: se o ponto de interesse do seu projeto fica no canto do quadro, a densidade real ali é menor do que a do datasheet.

O DORI vale para IA ou só para olho humano?

Esta é a parte que quase todo material comercial omite, e a norma é explícita: os requisitos operacionais especificados valem para situações em que as imagens são interpretadas por operadores humanos. Para aplicações de análise de vídeo, ou outros sistemas em que a análise da imagem é feita por software, valem outras definições. Câmera térmica também usa um conjunto próprio de requisitos.

Na prática isso significa duas coisas. Primeiro: o DORI continua sendo a melhor régua pública disponível para dimensionar um projeto, e usá-lo é muito melhor do que não usar régua nenhuma. Segundo: ele não é certificado de funcionamento de um detector. Um modelo de visão computacional pode falhar com densidade folgada — se o contraste for ruim, se o alvo estiver parcialmente oculto, se o movimento for muito rápido para a cadência — e pode acertar com densidade apertada, se a cena for limpa. Densidade de pixel é condição necessária, não suficiente.

A consequência de engenharia é que o critério de aceitação de um sistema com IA tem de ser medido na cena real, não deduzido da planilha. A planilha diz se vale a pena tentar; o teste em campo diz se funciona.

Placa de veículo acrescenta uma restrição de ângulo

Leitura de placa é o caso em que a geometria pesa tanto quanto a densidade. A nota de aplicação AN033 da Eagle Eye Networks sobre instalação de câmeras para LPR/ANPR é direta em dois pontos: o ângulo de pan deve ficar limitado a 30 graus, porque a vista em perspectiva além disso prejudica a leitura da placa; e a câmera deve estar sempre inclinada para baixo, tanto para evitar que a luz do sol e o farol do carro incidam direto na lente quanto para que a chuva escorra do vidro.

O motivo é geométrico. Uma placa vista de lado projeta na imagem uma largura menor do que a largura física dela: os mesmos pixels passam a cobrir mais milímetros de placa, e a densidade efetiva cai sem que ninguém tenha mudado a lente. Ângulo é perda de densidade disfarçada.

Onde entramos nisso

No OpenRadar, essa conta é a primeira coisa que fazemos antes de dizer que uma câmera serve para alguma coisa: enquadramento, densidade no ponto de interesse e ângulo, câmera por câmera. Quando a geometria não fecha, o diagnóstico é que não fecha — é mais barato descobrir isso num relatório do que numa assembleia.

Ver o diagnóstico de viabilidade por câmera

A compressão do vídeo apaga a densidade de pixel que o sensor tinha?

Não apaga a densidade — apaga o detalhe dentro dela, que é o que interessa. A própria Axis registra que fatores como direção da luz, qualidade da óptica e compressão da imagem afetam o resultado, e que o modelo de densidade de pixel é uma simplificação de uma realidade complexa.

Existe medida experimental sobre isso. Um estudo de 2022 de pesquisadores da Kinesense e do Trinity College Dublin avaliou o efeito da compressão H.264 sobre o desempenho de um detector de objetos (YOLOv5) em 50 vídeos de vigilância, codificados em cinco níveis de qualidade (CRF 22, 32, 37, 42 e 47). O resultado tem duas metades. A primeira: o desempenho de detecção é razoavelmente robusto a compressão moderada — usar CRF 37 em vez de CRF 22 reduziu bastante a taxa de bits e o tamanho do arquivo sem prejudicar o desempenho de forma relevante. A segunda: em compressão mais alta o desempenho degrada de forma apreciável, sobretudo em cenas complexas, com iluminação ruim e alvos em movimento rápido.

Isso tem uma implicação direta em instalação existente. É comum o software de análise consumir o stream secundário da câmera, que costuma ser configurado com resolução e taxa de bits menores para economizar rede. Nesse caminho, a densidade de pixel que o projeto calculou no sensor nunca chega ao analisador. Vale conferir qual perfil de vídeo o sistema realmente recebe antes de discutir por que ele está errando.

Como transformar isso em critério de aceitação

Densidade de pixel é útil justamente porque é verificável. Três disciplinas de teste que cabem em qualquer projeto, independentes de fabricante:

  1. Declare o objetivo por câmera, não por sistema. "Detectar presença de veículo na faixa da guarita" e "reconhecer o veículo" são requisitos com uma ordem de magnitude de diferença. Escrever qual é o objetivo de cada câmera evita cobrança impossível depois.
  2. Meça com objeto de referência no ponto de interesse. Não no centro do quadro, não na frente da câmera: no lugar exato onde o evento acontece. Um alvo de largura conhecida, um print da imagem e uma divisão resolvem, e o registro serve como prova de conformidade do projeto.
  3. Repita no pior caso, não no melhor. Contraluz do fim da tarde, chuva, farol aceso à noite. A densidade geométrica não muda com o clima, mas o detalhe utilizável muda muito — e é o pior caso que define se o sistema é confiável.
O que este texto não afirma

Não afirma que alcançar 25, 63, 125 ou 250 px/m garante o resultado. A própria fonte registra que o modelo é uma simplificação e que não há garantia de que cumprir a regra prática satisfaça o requisito operacional — nem que descumpri-la necessariamente o inviabilize.

Não afirma que os patamares do DORI se apliquem a detectores automáticos. A norma os define para interpretação por operador humano; para análise por software valem outras definições, que este texto não estabelece.

Não afirma qual é o ângulo vertical máximo para leitura de placa. A fonte citada prescreve inclinação para baixo sem fixar um valor, e não encontramos número verificável para citar.

Não descreve nenhum parâmetro, limiar ou procedimento de calibração do OpenRadar. Tudo aqui é norma pública, geometria e aritmética.

Fontes

  1. Axis Communications. Pixel density based on IEC 62676-4:2014 (white paper). whitepapers.axis.com/en-us/pixel-density-based-on-iec-62676-4-2014 — versão em PDF: axis.com/dam/public/53/47/fd/pixel-density-en-US-364241.pdf Origem dos patamares 4/10/20/40 px por rosto e 25/63/125/250 px/m, da largura média de rosto de 16 cm, da ressalva de que os requisitos valem para operador humano e da observação de que o modelo é uma simplificação. Consultado em 4 de setembro de 2026.
  2. Eagle Eye Networks. Camera Installation Considerations for LPR/ANPR, Application Note AN033. een.com/docs/app-notes/an033/ Origem do limite de 30 graus para o ângulo de pan e da recomendação de inclinar a câmera para baixo. Consultado em 4 de setembro de 2026.
  3. O'Byrne, M.; Sugrue, M.; Vibhoothi; Kokaram, A. Impact of Video Compression on the Performance of Object Detection Systems for Surveillance Applications, 2022. arXiv:2211.05805. arxiv.org/pdf/2211.05805 Origem do efeito da compressão H.264 sobre detecção com YOLOv5, incluindo a comparação entre CRF 37 e CRF 22 e a degradação em cenas complexas com pouca luz e alvos rápidos. Consultado em 4 de setembro de 2026.
Sobre o OpenRadar

Trabalhamos sobre a câmera IP que já está instalada: leitura do stream, análise na borda e evidência assinada em SHA-256 que qualquer pessoa pode conferir sozinha. O primeiro passo é sempre o diagnóstico de viabilidade câmera por câmera — inclusive quando a resposta é que aquela câmera não serve.

Falar sobre viabilidade das suas câmeras