6.1. Por que arrays#

A classe Image é a ferramenta certa para trabalho com pixels porque cada método dela opera diretamente sobre o buffer de pixels nativo da câmera em uma única chamada rápida. A maior parte do que a aplicação faz com um quadro – limiarização, busca de blobs, detecção de AprilTag, filtros de borda – já reside ali.

O que a biblioteca de imagem não expõe é o restante do trabalho numérico com que uma aplicação OpenMV se depara:

  • buffers de sensor que não são pixels – amostras de ADC, eixos de uma IMU (unidade de medição inercial), áudio de microfone,

  • números derivados da imagem que nenhum método interno retorna – uma coluna de histograma, uma mistura personalizada de dois quadros, uma transformação por pixel que o catálogo não cobre,

  • álgebra linear pequena – a matriz de calibração que retifica a lente, a rotação que funde a IMU,

  • matemática de processamento de sinais – o conteúdo de frequência de um buffer de vibração, suavização aplicada à saída de um sensor, um vetor de características que um classificador quer como entrada.

Todos esses querem a mesma forma: um buffer de números com uma operação aplicada a cada elemento. Um laço for em Python é a forma óbvia de escrevê-lo:

for i in range(len(samples)):
    samples[i] = samples[i] * cal

O laço funciona. Ele também é lento. Python é uma linguagem interpretada, e cada iteração de um laço Python carrega o custo de executar o interpretador uma vez: procurar samples, ler o elemento i, multiplicar, escrever de volta, avançar o contador do laço, verificar a condição do laço. Em um buffer de mil amostras de sensor esses custos do interpretador somam dezenas de milissegundos para o que é fundamentalmente uma operação rápida.

Esse overhead morde toda vez que um script alcança um buffer. Um quadro QVGA em escala de cinza tem 76.800 pixels; um acelerômetro a 100 Hz entrega cem amostras de três eixos por segundo; um microfone preenche um buffer de 1024 amostras a cada 64 ms. Um laço for em Python puro sobre qualquer um deles transforma uma tarefa que deveria levar alguns microssegundos em uma que leva dezenas de milissegundos – e cerca de dez vezes mais ainda em um buffer do tamanho de uma imagem.

6.1.1. Funções de biblioteca são mais rápidas que laços#

A solução é expressar a operação como uma única chamada de função contra o buffer inteiro, em vez de um laço Python sobre seus elementos. O numpy é exatamente isso: uma biblioteca de matemática de arrays onde cada operação é uma função já otimizada que percorre o buffer uma vez do início ao fim. np.multiply(samples, cal) multiplica cada elemento de samples por cal dentro de uma única chamada – a mesma aritmética que o laço fazia, sem o custo do interpretador por iteração. A mesma multiplicação de 1000 elementos que levava dezenas de milissegundos como um laço Python leva dezenas de microssegundos como uma chamada numpy.

Este é o acordo que o numpy oferece em toda a linha: sum, mean, sin, exp, multiplicação de matrizes, primitivas de processamento de sinais – cada uma é uma única função de biblioteca que opera sobre um buffer inteiro de uma vez. A troca é que os dados têm que viver no tipo de array do numpy e a operação tem que ser expressa contra esse array, não contra seus elementos um de cada vez.

6.1.2. Por que uma list não serve#

Uma list Python não pode substituir. Uma lista pode conter qualquer mistura de objetos – inteiros, floats, strings, outras listas – e uma função de biblioteca que a lê ainda tem que olhar cada slot para descobrir o que há nele e extrair o valor antes que qualquer aritmética aconteça. Esse overhead por slot é exatamente o custo que o laço Python paga. Listas são a escolha errada para matemática de arrays rápida.

6.1.3. Por que bytearray também não basta#

Um bytearray é a forma certa – um buffer tipado, um byte por elemento, tudo em um único bloco contíguo. É o que a maioria das APIs de periféricos orientadas a bytes devolve. O que lhe falta é a matemática. bytearray * 2 repete o buffer em vez de dobrar cada valor, e não há significado sensato para bytearray + bytearray elemento a elemento.

A estrutura de dados que combina um buffer tipado com matemática elemento a elemento é o ndarray. O que está dentro da caixa e como cada campo molda o comportamento de caminho rápido são as fundações sobre as quais o resto deste capítulo se apoia.