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.
| 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.
| Cena enquadrada | Densidade | Maior objetivo alcançado |
|---|---|---|
| 4 m | 480 px/m | Identificar |
| 8 m | 240 px/m | Reconhecer |
| 15 m | 128 px/m | Reconhecer |
| 20 m | 96 px/m | Observar |
| 30 m | 64 px/m | Observar |
| 40 m | 48 px/m | Detectar |
| 77 m | 25 px/m | Detectar (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.
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.
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.
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:
- 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.
- 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.
- 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.
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
- 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.
- 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.
- 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.
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.