Vídeo de profundidade com garantia por pixel — e a refutação honesta do inter

Sequências reais de Kinect (TUM RGB-D) comprimidas com o TUBE2D a ε = ±5 mm — uma tolerância de agarre de garra declarada, não um knob de qualidade. Todo pixel válido reconstrói a ≤ 5 mm do original por construção; pixel inválido (0, buraco do sensor) reconstrói 0 exato. Este demo mostra o que o codec entrega (bytes contra SZ3-3D/ZFP/gzip, consulta certificada sem descomprimir) e o que ele não entrega — o modo temporal que a intuição pedia e o sensor refutou.

O quadro dentro do tubo — original × reconstruído × erro/ε

freiburg1_xyz (câmera de mão) · quadro 45 · profundidade · cinza = pixel inválido do Kinect (25,1% do quadro) · subamostrado 4× para exibição
original — depth Kinect real
reconstruído a ε=±5 mm (N=32, K=10)
|orig−rec|/ε — máx (≤1 em todo pixel)
freiburg3_walking_static (câmera parada, pessoas andando) · quadro 55 · profundidade · inválidos 30,2%
original
reconstruído a ε=±5 mm
|orig−rec|/ε — máx (≤1 em todo pixel)

A prova visual do contrato: o mapa de erro nunca passa de 1×ε — não porque deu sorte, mas porque o residual é quantizado contra a predição: o bound vale por construção, e o verify confere 100% dos pixels de todos os quadros. Zeros do sensor saem exatos (contrato declarado: rec < 8 cm ⇒ 0; todo valor válido do Kinect está acima de 40 cm).

Bytes: o comparativo — SZ3 recebeu o eixo do tempo e perdeu

TUBE2D N=32 (intra)SZ3-3Dgzip -9ZFP-3D

Mesmo ε, mesmos float64. O SZ3 rodou em modo 3D — os quadros empilhados, o eixo temporal dado a ele de graça — e ficou 1,24× (fr1) e 1,33× (fr3) atrás do TUBE2D; na câmera parada perde até do gzip. ZFP fica 4–7× atrás (maxerr/ε 0,22: conservador, paga em bytes). H.26x fica fora por regra, não por medo: nenhum codec de vídeo dá |orig−rec| ≤ ε por pixel — o rate-control decide o erro, não o contrato. E nenhum dos três dá zeros exatos, verify ou consulta certificada.

vs H.265 — a régua do pior caso

x265 (libx265) monocromático 12-bit · empacotamento ÷16 declarado (uint16 não cabe em 12 bits; só o empacotamento custa ≤0,32×ε) · GOP default = o inter completo dele · erro medido pixel a pixel contra o uint16 original · régua dele é perceptual/média — a nossa é o pior caso, porque é o que agarre e forense compram
TUBE2D |erro|/ε · quadro 45 fr1 · mesma escala 0–10×ε — máx 1,0×ε (contrato)
x265 |erro|/ε · mesmo quadro, escala 0–10×ε — pior do quadro ; vermelho = acima de ε
original (referência) — as regiões vermelhas do x265 são as silhuetas: ringing de DCT na descontinuidade de profundidade

\n

A refutação honesta do inter — o sensor pisca mais que o tubo

|zt − zt−1|/ε · par de quadros consecutivos (54→55) da fr3 — câmera PARADA · escala 0→10×ε · vermelho = pisca acima de ε · cinza = inválido

Esperávamos ≥ 1,5×. Medimos 1,001×. O modo temporal (predizer cada pixel pelo mesmo pixel do quadro anterior reconstruído) foi construído, concorre por custo em cada tile — e o encoder o escolhe em só 2% dos tiles.

A imagem ao lado explica: com a câmera parada, o pixel médio do Kinect se move entre quadros — e dos pixels pisca acima de ε. A profundidade Kinect é quantizada por disparidade: o passo cresce com o quadrado da distância (~2,5 mm a 1 m, 2–10 cm a 3–6 m). O flicker de quantização engole os ±5 mm do contrato.

A lição, medida duas vezes: no DAS (degrau-0) o eixo do tempo valia 1,5–1,8× e o tile 2D perdeu; aqui o 2D vale e o tempo não paga. O eixo que paga é o que o sensor correlaciona — não o que a intuição espera. Aberto declarado: depth sub-mm (ToF industrial) pode reverter o veredito.

A consulta da garra — respondida sem descomprimir o vídeo

"a região ficou toda na banda de profundidade durante os quadros t1..t2?" · veredito certificado pelo envelope [rec−ε, rec+ε] tocando o índice de tiles (16 B/tile) e decodificando só cadeias de tile indecidíveis · retângulos sobre o quadro 45 da fr1

Decodes >100% = o preço da cadeia desde o keyframe (K=10), medido e mostrado — não escondido. Num sensor que pisca 6–9×ε com 25–30% de buracos, o índice poupa pouco e quase tudo vira FORA: é a resposta certa deste dado (o aparelho é proibido de mentir por teste — DENTRO ⇒ todo válido na banda e zero buracos; buraco = "o sensor não mediu" ⇒ no máximo INDECIDÍVEL). No DAS do degrau-0, janelas quietas custam zero decode; a consulta paga onde o dado tem regiões realmente estáveis.

Surpresa temporal — o movimento acende (onde há movimento de verdade)

fr1 (câmera de mão) · barras = bytes/quadro (N=32, K=10; picos regulares = keyframes intra) · linha = movimento médio |Δz| por quadro · Pearson 0,696 nos quadros inter

Quadro de movimento rápido custa até 2,2× o de movimento lento — os bytes são um sismógrafo do movimento, de graça. O miss, declarado: na fr3 (câmera parada) a correlação cai para 0,117 — o flicker de quantização domina o orçamento e as pessoas andando somem nele. O mapa de surpresa por tile existe, mas a agregação por quadro não separa movimento local de ruído de sensor neste dado.

Tudo medido, nada encenado. verify: 100% dos pixels × quadros × 8 configs, pior caso 1,0000×ε, zeros exatos · dados: TUM RGB-D freiburg1_xyz e freiburg3_walking_static (CC-BY 4.0, Kinect 640×480 @ 30 Hz, fator 5000) · codec e benches: repo tube2d, commits 1be3a6d (degrau-0: tiles 2D, vence SZ3 em DAS e depth) e 0a43a75 (degrau-1: vídeo, inter refutado com causa) · concorrentes: SZ3 v3.3.2 (-M ABS, 3D), ZFP 1.0.1 (-a, 3D), gzip -9, mesmos float64 e mesmo ε.