Aplicação a jogos de futebol - paginas.fe.up.ptee99035/relatorio/relatorio.pdf · figura 28 –...

Detecção de cortes de cena

Aplicação a jogos de futebol

Trabalho realizado no âmbito da disciplina

Projecto, Seminário ou Trabalho de Final de Curso

do 5º ano da Licenciatura em Engenharia Electrotécnica e de Computadores

por

Sérgio Filipe dos Reis Órfão

Orientadores

Eng. André Monteiro de Oliveira Restivo (FEUP)

Dr. José Bernardo dos Santos Cardoso (PT Inovação)

Julho de 2004

Detecção de cortes de cena – Aplicação a jogos de futebol

Sérgio Filipe dos Reis Órfão I

Índice Geral

1 INTRODUÇÃO 1

2 ENVOLVENTE 2

3 ESTADO DA ARTE 4

4 BASES TEÓRICAS 8

4.1. DVB 8

4.2. MPEG 9 4.2.1. Princípios da codificação de vídeo do MPEG-1 9 4.2.2. Os diferentes tipos de imagens MPEG 10 4.2.3. Ordem das imagens 11 4.2.4. Decomposição em camadas de uma sequência de vídeo MPEG 12 4.2.5. Controlo de débito binário de saída 13 4.2.6. Codificação de vídeo MPEG-2 14 4.2.7. Níveis e perfis MPEG-2 14 4.2.8. Especificação MPEG-2 para os modos de predição 16

4.3. YUV 18 4.3.1. Amostragem YUV 19

4.4. PGM (Portable Gray Map) 21

4.5. Cor 22 4.5.1. Espaço de cor e conversões de taxa de amostragem de cor 24

4.6. Conversão entre RGB e YUV 4:4:4 24 4.6.1. Conversão de RGB para YUV 4:4:4 26 4.6.2. Conversão de YUV de 8-bits para RGB 26

4.7. Métodos simples de detecção de cortes de cena 27 4.7.1. Variação da intensidade dos Pixels 27 4.7.2. Razão de probabilidades 28 4.7.3. Comparação de histogramas 28

4.8. Um método mais complexo - DCT (Discrete Cosine Transform) 29 4.8.1. Fast DCT – método dos três coeficientes 30 4.8.2. Fast DCT - método de Skal 30

5 IMPLEMENTAÇÃO 35

5.1. Linguagens e Plataformas 35

5.2. Desenvolvimento da Aplicação 35

5.3. Interface Gráfica 44

6 CONVERSÃO DE MPEG PARA PGM 47


Sérgio Filipe dos Reis Órfão II

7 TESTES PRELIMINARES 49

8 APRESENTAÇÃO E DISCUSSÃO DE RESULTADOS 60

8.1. Variação de intensidade de pixels (diferença total) 62

8.2. Variação de intensidade de pixels (em percentagem) 64

8.3. Razão de probabilidades 67

8.4. Comparação de histogramas 68

8.5. DCT (método com três coeficientes) 70

8.6. DCT (método de Skal) 71

8.7. Outras sequências analisadas 72

9 CONCLUSÕES E SUGESTÕES DE TRABALHO FUTURO 76

ANEXO 79 REFERÊNCIAS 93


Sérgio Filipe dos Reis Órfão III

Índice de Figuras figura 1 – módulos para a análise de vídeos de futebol 6 figura 2 – concatenação de três tipos de figuras mpeg 10 figura 3 – hierarquia das camadas de vídeo mpeg 12 figura 4 – composição de um macro bloco 4:2:0 (o = amostras y, * = amostras cb e cr) 13 figura 5 – diagrama esquemático do codificador mpeg 14 figura 6 – diagrama esquemático do descodificador mpeg 14 figura 7 – níveis e perfis mpeg2 15 figura 8 – posição das linhas dos sucessivos campos num sistema entrelaçado 17 figura 9 – corte de blocos a partir de macro blocos (modo frame) 17 figura 10 – corte de blocos a partir de macro blocos (modo field) 18 figura 11 – grelha de amostragem usando 4:4:4 20 figura 12 – grelha de amostragem usando 4:2:2 20 figura 13 – grelha de amostragem 4:2:0 no mpeg-1 21 figura 14 – grelha de amostragem 4:2:0 no mpeg-2 21 figura 15 – exemplo da barra de menu 36 figura 16 – fluxograma da função open 36 figura 17 – exemplo da caixa de selecção do método 37 figura 18 – fluxograma da função select 37 figura 19 – botões de início e de interrupção da análise 38 figura 20 – barra de progresso de análise 38 figura 21 – exemplo do espaço onde aparecem os cortes de cena detectados 38 figura 22 – exemplo do espaço onde aparecem os resultados da análise 39 figura 23 – fluxograma da função play 40 figura 24 – exemplo dos botões de resultados finais 41 figura 25 – exemplo das janelas de resultados finais 41 figura 26 – fluxograma da função statistic 42 figura 27 – fluxograma da função log 42 figura 28 – fluxogramas das funções visualizar o primeiro corte de cena e visualizar o corte de cena

anterior 43 figura 29 – exemplo da janela de pré-visualização do filme 44 figura 30 – fluxograma da função preview 44 figura 31 – constituição de um programa em wxwindows 45 figura 32 – ambiente gráfico desenvolvido 45 figura 33 – screenshot do programa de conversão de mpeg para pgm 47 figura 34 – directoria onde ficaram gravadas as imagens pgm e reprodução de uma delas 48 figura 35 – exemplo de corte de cena 49 figura 36 – criação das imagens (f1, f2) a partir de campos com a mesma sequência (c1, c2, c3, c4) 50 figura 37 – criação das imagens (f1, f2) a partir de campos com sequências diferentes (c1, c2, c3, d1) 50 figura 38 – exemplo de uma imagem com duas sequências sobrepostas 51 figura 39 – exemplo das cortinas utilizadas nas transmissões do euro 2004 51 figura 40 – corte de cena detectado incorrectamente associado às primeiras imagens da sequência 60 figura 41 – corte de cena detectado associado à transmissão televisiva por campos 61 figura 42 – corte de cena detectado associado à existência de cortinas 61 figura 43 – cortes de cena detectados incorrectamente em sequência 62 figura 44 – funcionamento da ferramenta de segmentação vídeo 77 figura 45 – interface da ferramenta de segmentação vídeo 77


Sérgio Filipe dos Reis Órfão IV

índice de tabelas tabela 1 – parâmetros característicos de análise de cortes de cena pelos vários métodos (fcp vs slb – 1/0) 53 tabela 2 – parâmetros característicos de análise de cortes de cena pelos vários métodos (fcp vs slb – 1/1) 53 tabela 3 – parâmetros característicos de análise de cortes de cena pelos vários métodos (fcp vs slb – 1/2) 53 tabela 4 – parâmetros estatísticos dos vários métodos (fcp vs slb – 1/0) 54 tabela 5 – parâmetros estatísticos dos vários métodos (fcp vs slb – 1/1) 54 tabela 6 – parâmetros estatísticos dos vários métodos (fcp vs slb – 1/2) 54 tabela 7 - factores multiplicativos para os vários métodos utilizando o algoritmo móvel (fcp vs slb – 1/0) 55 tabela 8 - factores multiplicativos para os vários métodos utilizando o algoritmo móvel (fcp vs slb – 1/1) 55 tabela 9 - factores multiplicativos para os vários métodos utilizando o algoritmo móvel (fcp vs slb – 1/2) 55 tabela 10 - parâmetros característicos de análise de cortes de cena pelos vários métodos (fcp vs mon – 1/0) 56 tabela 11 - factores multiplicativos para os vários métodos utilizando o algoritmo móvel (fcp vs mon – 1/0) 56 tabela 12 - parâmetros característicos de análise de cortes de cena pelos vários métodos (ita vs den) 57 tabela 13 - factores multiplicativos para os vários métodos utilizando o algoritmo móvel (ita vs den) 58 tabela 14 – valores limites seleccionados (algoritmo invariável) 59 tabela 15 – valores limites seleccionados (algoritmo móvel) 59 tabela 16 – cortes de cena detectados pelo método de variação de intensidade de pixels (diferença total) 63 tabela 17 – resumo dos resultados da análise pelo método de variação de intensidade de pixels (diferença total) 64 tabela 18 - resumo dos resultados da análise pelo método de variação de intensidade de pixels (diferença total)

utilizando o algoritmo móvel 64 tabela 19 - cortes de cena detectados pelo método de variação de intensidade de pixels (em precentagem) 65 tabela 20 – resumo dos resultados da análise pelo método de variação de intensidade de pixels (em percentagem)66 tabela 21- resumo dos resultados da análise pelo método de variação de intensidade de pixels (em percentagem)

utilizando o algoritmo móvel 66 tabela 22 - cortes de cena detectados pelo método de variação de intensidade de pixels (em precentagem) utilizando

o algoritmo móvel 67 tabela 23 - resumo dos resultados da análise pelo método da razão das probabilidades 67 tabela 24 - cortes de cena detectados pelo método da razão de probabilidades 68 tabela 25 - resumo dos resultados da análise pelo método da razão das probabilidades utilizando o algoritmo móvel68 tabela 26 - cortes de cena detectados pelo método da comparação de histogramas 69 tabela 27 - resumo dos resultados da análise pelo método da comparação de histogramas 69 tabela 28 - resumo dos resultados da análise pelo método da comparação de histogramas utilizando o algoritmo

móvel 69 tabela 29 - resumo dos resultados da análise pelo método dct de três coeficientes 70 tabela 30 - resumo dos resultados da análise pelo método dct de três coeficientes utilizando o algoritmo móvel 70 tabela 31 - cortes de cena detectados pelo método dct de skal 71 tabela 32 - resumo dos resultados da análise pelo método dct de skal 72 tabela 33 - resultados da análise pelo método da diferença de pixels (diferença total) 73 tabela 34 - resultados da análise pelo método da diferença de pixels (diferença total) utilizando o algoritmo móvel73 tabela 35 - resultados da análise pelo método da diferença de pixels (em percentagem) 73 tabela 36 - resultados da análise pelo método da diferença de pixels (em percentagem) utilizando o algoritmo móvel

73 tabela 37 - resultados da análise pelo método da razão de probabilidades 74 tabela 38 - resultados da análise pelo método da razão de probabilidades utilizando o algoritmo móvel 74 tabela 39 - resultados da análise pelo método da comparação de histogramas 74 tabela 40 - resultados da análise pelo método da comparação de histogramas utilizando o algoritmo móvel 74 tabela 41 - resultados da análise pelo método dct com três coeficientes 75 tabela 42 - resultados da análise pelo método dct com três coeficientes utilizando o algoritmo móvel 75 tabela 43 - resultados da análise pelo método dct de skal 75 tabela 44 - resultados da análise pelo método dct de skal utilizando o algoritmo móvel 75


Sérgio Filipe dos Reis Órfão 1

1 INTRODUÇÃO

Os eventos desportivos são aqueles que maiores audiências têm em todo o tipo de media, em particular nas televisões. Devido a este facto fazem-se muitos investimentos no campo da transmissão de eventos desportivos. O problema é que o valor do conteúdo deste tipo de eventos se reduz significativamente após um curto período de tempo. Por isso, o seu processamento deve ser realizado de um modo o mais automático possível.

O objectivo deste trabalho é estudar várias técnicas de detecção de cortes de cena, com aplicação em eventos desportivos, neste caso o futebol.

Este relatório começa por descrever a envolvente do projecto, onde se tenta justificar a sua elaboração e pertinência.

De seguida, faz-se referência ao estado da arte, apresentando-se vários trabalhos desenvolvidos nesta área.

Após esta fase introdutória, apresentam-se as bases teóricas que permitem resolver o problema colocado. Esta descrição teórica centra-se em dois assuntos fundamentais: uma primeira parte relativa às normas utilizadas para transmissões televisivas, nomeadamente à análise das normas MPEG, e uma segunda parte onde se explicam os métodos que vão ser testados na detecção dos cortes de cena.

Concluída a análise teórica, passa-se à fase de realização prática do trabalho. Nos capítulos 5 e 6 explica-se como foi idealizado o ambiente gráfico do trabalho, como cada uma das tarefas foi efectuada e como é que se converte um ficheiro MPEG em imagens do tipo PGM.

Terminado o desenvolvimento do ambiente gráfico, é necessário realizar testes preliminares para conhecer quais os valores limite a utilizar para cada um dos métodos de detecção de cortes de cena, o que está descrito no capítulo 7.

No capítulo 8 vão-se testar os referidos métodos, usando vários exemplos, de forma a descobrir qual o que detecta todos os cortes de cena existentes com o menor número de erros possível. Desta forma é possível determinar qual deles é o mais eficiente.

Por último, sumariam-se as principais conclusões retiradas do projecto realizado e apresentam-se algumas perspectivas de desenvolvimento deste trabalho.



2 ENVOLVENTE

Antes de começar a descrever especificamente este trabalho é necessário apresentar uma ideia geral do porquê deste projecto, bem como da importância da segmentação nos dias de hoje.

Os avanços nas tecnologias informáticas e de comunicação, principalmente o desenvolvimento da WEB, levaram a um esforço na procura de novos métodos e técnicas para a realização de aplicações multimédia. Desse esforço resultaram o aparecimento de aplicações como o video-on-demand e o tele-shopping, entre outros. Aplicações deste tipo estão ligadas à gestão e controlo de bases de dados multimédia que abrangem uma enorme variedade de áreas, tais como o processamento de imagem e de informação, a inteligência artificial e, obviamente as bases de dados.

Actualmente, a quantidade de informação multimédia existente é enorme e continua a aumentar rapidamente. Por isso, os requisitos para aceder a esta grande quantidade de dados multimédia estão a tornar-se cada vez mais importantes e é necessário encontrar modos de os armazenar eficientemente. É aqui que entra a segmentação.

A segmentação consiste na tentativa de separação de um conjunto de dados em partes mais pequenas. Isto faz com que seja possível o acesso a conteúdos relevantes de um modo mais rápido e simples. Os dados multimédia podem ser de um conjunto variado de tipos e, embora por exemplo as bibliotecas digitais também sejam muito importantes, o projecto presente centra-se exclusivamente nos dados de vídeo.

A segmentação de vídeo desempenha um papel importante em inúmeras aplicações e, apesar de estar a ser estudada há algumas décadas, continua a ser difícil conseguir com que seja feita automaticamente e com exactidão. Os jogos de futebol constituem um bom exemplo de aplicação da segmentação de vídeo. O tempo típico de um jogo de futebol é de uma hora e meia. Em torneios como o Campeonato do Mundo são jogados 52 jogos e é gerada uma biblioteca correspondente a centenas de horas. Mesmo para os inúmeros fãs deste desporto, a tarefa de rever longas horas de jogos com o intuito de encontrar as jogadas mais interessantes acaba por se tornar enfadonha. Interessa por isso que os jogos sejam segmentados e que a cada pedaço do jogo seja associado um “rótulo” que identifique bem o que se passou nessa parte e quem foram os intervenientes. Desta maneira irá ser possível fazer com que o utilizador escolha o que quer ver, tendo ainda a possibilidade de fazer resumos personalizados ou dirigidos dos jogos.



O trabalho proposto neste projecto prende-se com a detecção eficiente de cortes de cena, passo necessário para conseguir fazer a segmentação automática de um modo correcto.



3 ESTADO DA ARTE

Como já foi referido no capítulo anterior, a segmentação de vídeo é um tema importante. Assim, várias publicações se debruçam sobre vários aspectos desta problemática.

Em particular, na área da segmentação automática de jogos de futebol, alguns trabalhos recentes foram desenvolvidos, alguns deles com um nível de complexidade elevado. Por exemplo, já se desenvolveram algoritmos que pretendem tornar possível a execução de resumos automáticos de jogos e até mesmo um que selecciona apenas os golos dos jogos.

Cheong [1] referiu que um passo chave no tratamento de uma grande base de dados de vídeo é a partição das sequências de vídeo em shots (sequências de vídeo filmadas continuamente por uma câmara). A partição do vídeo torna os dados mais manuseáveis por imposição duma hierarquia. É também o primeiro passo para a compreensão do conteúdo do vídeo, dividindo-o em shots por conteúdos de análise (por exemplo, cenas, movimentos de câmara). Uma abordagem convencional consiste em tratar a partição de vídeo como um problema de processamento de imagem 2-D. A ideia intuitiva é que a intensidade de cada pixel 2-D deve mudar abruptamente numa mudança de shot. A contribuição deste método reside no uso dum contraste físico rigoroso associado com cenas 3-D e de movimento, isto é, a luminosidade total duma cena entre duas frames deve manter-se constante se a mudança é o resultado de suaves movimentos de câmara. Assim, o problema de detecção de mudança de shot resume-se a detectar contrastes violentos de cenas. Cheong [1] fez uma revisão bibliográfica dos algoritmos de detecção de mudanças de cena apresentados na literatura por vários investigadores e identificou os trabalhos que tinham em conta mudanças de imagem por suaves operações de câmara. Propôs um algoritmo a partir duma equação de contraste de luminosidade e fluxo óptico. O algoritmo permite lidar com várias situações tais como imagens texturadas em movimento e transições de shot não lineares. Contudo, ele tem limitações para movimentos longos e transições superiores a dois segundos.

Depois do vídeo ser segmentado em shots, a extracção de key-frames permite uma representação aceitável para browsing e retrievel. Muitos atributos das frames, tais como a cor e o movimento, têm sido usados para a detecção dos limites dum shot. O uso de técnicas de histogramas tem-se mostrado eficaz para o efeito. Os histogramas da cor de duas imagens consecutivas são analisados em computador e se a diferença entre os dois histogramas estiver acima de um certo threshold, assume-se que há um limite de shot. Contudo, neste método não é usada informação do movimento, pelo que a técnica tem inconvenientes em cenas com movimentos de câmara e de objectos.



Segundo Abdeljaoued et al. [2] existem diferentes tipos de limites entre shots:

• O corte é uma mudança abrupta que ocorre num único frame. • Um fade-in começa com uma frame negra aparecendo a imagem

gradualmente até ao brilho máximo. • O fade-out é o oposto do fade-in. • O dissolve consiste numa sobreposição do fade-out sobre o fade-in.

As técnicas usadas anteriormente limitavam-se à detecção de cortes. Por isso, estes autores apresentaram um novo algoritmo para a detecção de limites de shot, que explora a informação fotométrica (descritores de textura) assim como informações de movimento (tracking). Este algoritmo permite a detecção de uma variedade de limites de shot, incluindo cortes, dissolves e fades.

A avaliação do método provou que nas cenas caracterizadas por muito movimento de objectos e de câmara conseguiam-se detectar efeitos especiais de vídeo, tais como o dissolve. Contudo, o desempenho do algoritmo dependia da estabilidade da extracção dos pontos característicos e dos passos de tracking. Por isso esta técnica ainda precisa de melhoramentos.

Em 2001, Chen et al. [3] apresentaram um método de detecção de mudança de cenas usando um algoritmo de segmentação e a técnica do tracking dum objecto baseado nos resultados da segmentação. Este método permite não só a detecção eficaz de mudanças de cena, mas também tirar informações sobre as frames de vídeo, muito úteis para indexação e análise de conteúdos. Usando o algoritmo de segmentação, o mapa da máscara de segmentação de cada frame de vídeo pode ser automaticamente extraído. Assim, os pixels da cada frame são agrupados em diferentes classes. Depois, comparam-se as frames e verificam-se as diferenças dos mapas de segmentação. Para melhor lidar com rotação de cenas, usaram a técnica de tracking. Verificaram que os custos adicionais de introdução desta técnica eram irrisórios. O método mostrou-se promissor, pelo que os autores se propuseram a continuar a investigação de forma a desenvolvê-lo.

Sifakis et al. [4] apresentam um algoritmo constituído por três passos principais: classificação da sequência de imagem, detecção de mudança duma frame fixa, localização de objectos usando características de cores. A classificação da sequência de imagem é baseada em testes estatísticos das diferenças. A detecção de movimento usa um algoritmo two-label fast marching. Para a localização de objectos usa-se um algoritmo baseado na semelhança de cor. Este algoritmo baseia-se principalmente na detecção de mudanças e difere dos anteriores pois a localização de objectos baseada em fronteiras é substituída pela etiquetagem de objectos por região. O algoritmo fast marching mostrou-se muito eficiente, mas verificou-se que a localização dos objectos poderia ser melhorada.

Lu et al. [5] apresentaram um novo modelo para a segmentação de vídeo, explorando quer informação temporal do fundo quer informação espacial



do primeiro plano. Na técnica proposta, as regiões do fundo da cena são integradas inicialmente numa grande imagem virtual que inclui todas as partes visíveis do fundo durante toda a sequência. As regiões iniciais do primeiro plano são detectadas em cada frame, subtraindo o fundo na imagem virtual e dividindo em regiões de textura através do algoritmo watershed. O maior contributo deste modelo é permitir a organização da informação temporal da sequência. Além disso, o esquema proposto permite analisar sequências de vídeo com vários movimentos globais tais como deslocamentos, rotação e zoom. Comparada com outras abordagens de segmentação, esta técnica tem as seguintes vantagens: permite segmentar sequências de vídeo com vários movimentos de câmara ou pausas em alguns frames; pode detectar efectivamente o desaparecimento de objectos existentes e o aparecimento de novos; proporciona fronteiras de objectos com maior exactidão porque a imagem virtual contém a informação integral de fundo.

Ekin e Tekalp [6,7] apresentaram contribuições para o processamento de vídeo nos desportos, nomeadamente basquetebol e futebol. Apresentaram um fluxograma onde se mostram os módulos essenciais na estrutura da análise de vídeos de jogos de futebol, que a seguir se reproduz [6].

Figura 1 – Módulos para a análise de vídeos de futebol

Os shots de futebol são classificados em três classes: shots longos, shots médios e close-up shots. Depois, desenvolveram diferentes algoritmos para compreensão dos conteúdos semânticos dos shots médios ou longos. Foram detectados shots médios com árbitros e desenvolveu-se um algoritmo de tracking para a sua detecção. Manipularam o tracking de jogadores em shots longos com integração de movimento e cor. Os shots longos das trajectórias dos jogadores ficaram registados num modelo com



detecção das linhas de campo e cálculo dos parâmetros de transformação. Este trabalho tem tido continuidade noutras publicações. Por exemplo, em 2003, os mesmos autores propuseram uma nova estrutura de análises de vídeos de futebol usando características dos objectos e conceitos de cinemática [7]. Nesta publicação é proposto um novo algoritmo de detecção de fronteiras usando para o efeito a análise de variações da cor dominante (cor da relva). Além disso, propõem-se duas novas características para a classificação de shots em vídeos de futebol, capazes de proporcionar robustez a variações de características cinemáticas devidas a ligeiras diferenças de estilos usados por diferentes equipas. Introduziram ainda novos algoritmos para detecção automática de golos, árbitros e áreas de grande penalidade. Testaram os algoritmos propostos em mais de 13 horas de jogos de diferentes países para avaliar a sua fiabilidade, tendo-se obtido resultados bastante satisfatórios.

Kim et al. [8] fizeram a avaliação dos resultados da segmentação com base nas trajectórias estimadas dos jogadores nos jogos de futebol. Usaram algoritmos k-means para determinar com exactidão a localização das pernas dos jogadores mostrando que ela deve ser usada para aumentar o desempenho dos métodos.

São muito mais as publicações nesta área específica. Contudo as aqui mencionadas fazem parte do grupo das mais citadas e são suficientemente abrangentes para que da sua leitura se fique com uma visão relativamente profunda do estado da arte nesta matéria.

Fica-se com a ideia de que, embora haja um esforço recente para conseguir obter métodos automáticos de segmentação eficientes e robustos, há ainda muito trabalho de investigação a ser feito até atingir esse objectivo.



4 BASES TEÓRICAS

O objectivo específico deste trabalho é detectar cortes de cena em jogos de futebol. Essa análise terá que ser feita num computador e, por isso, precisamos de dispor dos jogos num formato digital. Interessa então saber qual é o formato digital existente em Portugal e quais são as suas características para podermos depois analisar os jogos convenientemente. Este tema vai ser objecto de estudo nas primeiras secções deste capítulo.

Posteriormente referem-se os tipos e as características fundamentais das imagens, tanto a cores como a preto e branco, bem como é que se podem realizar as conversões entre um tipo de imagens e o outro.

Finalmente vão ser descritos os diferentes métodos a utilizar na detecção dos cortes de cena neste trabalho.

4.1. DVB

Em Portugal, a ANACOM (Autoridade Nacional de Comunicações) aderiu ao Digital Video Broadcasting Project (projecto DVB) em Janeiro de 2003. O projecto DVB é um consórcio, criado em 1992, que engloba mais de trezentos radiodifusores, operadores de rede, fabricantes e reguladores, de cerca de trinta e cinco países, cujo objectivo se prende com a criação de normas para um mercado o mais abrangente possível de serviços de televisão digital e de dados. Assim sendo, as emissões digitais no nosso país seguem as normas ditadas por este projecto.

O projecto DVB está dividido em quatro módulos, cada um envolvendo uma área específica dos trabalhos a realizar. Os módulos comercial e técnico são os impulsionadores da maioria do projecto, complementados pelo módulo de direitos de propriedade intelectual e o módulo de promoção e comunicação.

O módulo técnico é o que se reveste de maior relevância para este projecto, pois é aqui que são desenvolvidas as especificações técnicas. As especificações técnicas da norma consideram as técnicas de compressão de áudio e vídeo de acordo com o standard MPEG (Moving Picture Experts Group). O sistema de codificação áudio utiliza o standard MPEG LayerII (MUSICAM) e o sistema de codificação vídeo usa uma combinação entre o Main Profile e o Main Level (MainProfile@MainLevel), com uma frequência de frames de 25 Hz para os formatos 4:3 ou 16:9.

Neste ponto do trabalho é interessante explicar mais detalhadamente o standard MPEG [9], principalmente no que respeita à codificação vídeo, que é a que tem um maior interesse para o presente trabalho.



4.2. MPEG

MPEG é um grupo que trabalha seguindo directivas da International Standars Organisation (ISO) e da International-Technical Commission (IEC). Este grupo concentra o seu trabalho em definir standards para a codificação de vídeo, áudio e outros tipos de dados. No fundo, o que este grupo faz, é definir regras de como os sistemas e os ficheiros media devem interagir uns com os outros.

O MPEG-1 define regras para a codificação de vídeo e áudio reduzindo a quantidade de dados armazenada ao mínimo possível para que as imagens continuem a ser observadas com elevada qualidade. Para além desta regra também são definidas na especificação do sistema, normas de como é que os streams de áudio e vídeo podem ser agrupados para produzir um stream de sistema.

O MPEG-2 foi construído baseado na especificação MPEG-1 com o objectivo de ser utilizado em aplicações de vídeo de alta qualidade, uma vez que a qualidade das imagens do MPEG-1 não servia para aplicações broadcast. Por isso o MPEG-2 é o standard para a transmissão de vídeo digital.

Tal como o MPEG-1, também o MPEG-2 é dividido em três partes distintas:

• MPEG-2 system – define os streams MPEG-2; • MPEG-2 vídeo – define a codificação de vídeo MPEG-2; • MPEG-2 áudio – define a codificação de áudio MPEG-2.

Para se poder compreender o que acontece na codificação de vídeo do MPEG-2, tem que se analisar primeiro os princípios de codificação de vídeo do MPEG-1.

4.2.1. Princípios da codificação de vídeo do MPEG-1

Como já foi referido, o principal objectivo do MPEG-1 foi chegar a uma qualidade de vídeo média, isto é, com uma taxa média de bits constante (1,5 Mb/s) para armazenar vídeo e áudio num CD-ROM. A parte de vídeo utiliza 1,15 Mb/s e o restante é utilizado pela parte de áudio e outros dados adicionais necessários. Contudo, a especificação MPEG-1 é muito flexível e permite que diferentes débitos sejam escolhidos consoante a complexidade de codificação e a qualidade que se deseja.

A codificação de vídeo do MPEG-1 explora a forte correlação que existe entre imagens sucessivas, com o objectivo de reduzir a quantidade de informação que é necessária transmitir e armazenar. Estas técnicas são conhecidas por “predição com compensação do movimento” e consistem em deduzir a maior parte das imagens de uma sequência a partir de imagens anteriores e de imagens seguintes, com um mínimo de



informação adicional correspondente à diferença entre imagens. Isto faz com que seja necessário num codificador MPEG um estimador de movimento, que é a função mais complexa e condiciona a performance do codificador.

A codificação pode ser feita em vários passos para aplicações em que o tempo real (isto quer dizer um tempo de atraso constante e aceitável) não é importante mas a qualidade tem imensa importância. No entanto, em transmissões de vídeo em directo a codificação em tempo real é necessária.

Portanto, a realização prática de um codificador tem que ter em conta factores como a velocidade, a taxa de compressão, a complexidade e a qualidade de imagem. É também necessário que o tempo de sincronização e o tempo de acesso aleatório a uma sequência estejam dentro de um limite aceitável (convém não exceder 0,5 s), o que restringe o número de imagens que podem ser dependentes da primeira imagem a um número entre 10 e 12 para um sistema que opere com 25 imagens/s.

4.2.2. Os diferentes tipos de imagens MPEG

A norma MPEG define três tipos de imagens que costumam estar posicionadas como se apresenta na Figura 2.

Figura 2 – Concatenação de três tipos de figuras MPEG • Imagens I (intra pictures) – Estas imagens são codificadas sem terem

qualquer referência a outras, de um modo semelhante a imagens JPEG. Isto quer dizer que elas contêm toda a informação necessária para a sua reconstrução pelo descodificador; por esta razão, estas imagens são o ponto de partida para o acesso a uma sequência de vídeo. A taxa de compressão das imagens I é muito baixa e é similar à taxa de compressão de uma imagem JPEG com a mesma resolução.

• Imagens P (predicted pictures) – Estas imagens são codificadas a partir de imagens I e P anteriores, usando as técnicas de predição com compensação de movimento. Imagens P podem ser usadas como base para imagens P seguintes, mas como a compensação de movimento não é perfeita não é possível estender muito o número de imagens P



entre duas imagens I. A taxa de compressão de imagens P é consideravelmente superior à taxa de compressão das imagens I.

• Imagens B (bidirectional predicted pictures) – Estas imagens são codificadas por interpolação bidireccional a partir de imagens I e P anteriores e, também, posteriores. Como as imagens B não são utilizadas para codificar imagens posteriores elas não propagam erros de codificação. As imagens B têm a taxa de compressão maior.

Consoante a complexidade do codificador usado, é possível codificar apenas imagens I, imagens I e P ou imagens I, P e B, com resultados muito diferentes em relação à taxa de compressão, ao tempo de codificação e à qualidade da imagem.

Para descrever a sucessão de imagens I, P e B existem dois parâmetros, o M e o N:

• M é a distância (em número de imagens) entre duas imagens P. • N (Group of Pictures , GOP) é a distância entre duas imagens I.

Para um débito binário de 1,15 Mb/s os parâmetros geralmente usados são M = 3 e N = 12. Com estes valores, uma sequência de vídeo tem: 1/12 (8,33%) de imagens I, 1/4 (25%) de imagens P e 2/3 (66,67%) de imagens B; esta taxa de compressão encontra-se maximizada uma vez que as imagens mais frequentes são aquelas que têm uma taxa de compressão maior.

4.2.3. Ordem das imagens

Obviamente que a sequência de imagens após a descodificação tem que ter a mesma ordem que a sequência original. Se os parâmetros M e N tiverem os valores anteriormente referidos (M = 3 e N = 12) a correspondência entre o número de cada imagem e o tipo de codificação seria o seguinte:

1(I) 2(B) 3(B) 4(P) 5(B) 6(B) 7(P) 8(B) 9(B) 10(P) 11(B) 12(B) 13(I)…

Para ser possível codificar ou descodificar imagens B (bidireccionais), tanto o codificador como o descodificador necessitam de ter as imagens I e P anteriores e, também, as seguintes. Para que isto seja possível é necessário que a sequência de imagens original seja reordenada. Este reordenamento dá origem à seguinte sequência:

1(I) 4(P) 2(B) 3(B) 7(P) 5(B) 6(B) 10(P) 8(B) 9(B) 13(I) 11(B) 12(B)…

O aumento da taxa de compressão que se consegue utilizando imagens B faz com que seja necessário um maior atraso de codificação e uma memória maior para a codificação e a descodificação.



4.2.4. Decomposição em camadas de uma sequência de vídeo MPEG

Para uma dada sequência de vídeo a norma MPEG define uma hierarquia de camadas que é apresentada na Figura 3. Cada uma destas camadas tem uma função específica.

Figura 3 – Hierarquia das camadas de vídeo MPEG Começando da camada superior, as camadas sucessivas são:

• Sequence – esta é a camada superior que define o contexto válido para toda a sequência (por exemplo os parâmetros básicos do vídeo).

• Group of Pictures (GOP) – esta é a camada que determina o acesso aleatório à sequência; tem que começar sempre por uma imagem I.

• Picture (Imagem) – este é o elemento que é mostrado; pode ser de três tipos (I, P ou B).

• Slice – esta é a camada de sincronização e permite a recuperação de erros; o conjunto de slices cobre toda a figura sem sobreposição entre eles; o tamanho de cada um pode variar entre um macro bloco e a imagem inteira, mas normalmente é uma linha completa de macro blocos.

• Macroblock – esta é a camada utilizada para a estimação e compensação de movimento; um macro bloco tem um tamanho de 16x16 pixel e é constituído por quatro blocos de luminância e dois de crominância (Figura 4).

• Block – como no JPEG, uma imagem é dividida em blocos de 8x8 pixel.



Figura 4 – Composição de um macro bloco 4:2:0 (o = amostras Y, * = amostras Cb e Cr)

4.2.5. Controlo de débito binário de saída

O bitstream gerado pelo codificador de vídeo designa-se por stream elementar (ES). Para preencher todos os requisitos do canal e a especificação do buffer de entrada do descodificador MPEG de referência, o débito binário do stream elementar é geralmente mantido constante. Isto não é garantido no processo de codificação, porque é preciso ter em conta que há diferentes quantidades de detalhe e de movimento nas imagens que é preciso codificar.

Para controlar o débito binário à saída do codificador existe um buffer do tipo FIFO (First In First Out). A quantidade de informação existente neste buffer é monitorizada e mantida dentro de limites predeterminados através de um feedback loop (ciclo de realimentação) que modifica os parâmetros de quantificação, o que tem grande influência no débito binário do bitstream de codificação. Desta maneira, é possível obter um débito binário constante, com uma resolução que depende do conteúdo da imagem e da quantidade de movimento que ela tem (quanto maior for o movimento, menor a sua resolução). Um diagrama de blocos esquemático de um codificador MPEG é apresentado na Figura 5.



Figura 5 – Diagrama esquemático do codificador MPEG

O descodificador esquematizado na Figura 6, não tem que realizar a estimativa de movimento e por isso é muito mais simples. Isto foi um dos objectivos do standard MPEG porque, antes da introdução da norma, existia um número maior de tipos de descodificadores do que de codificadores.

Figura 6 – Diagrama esquemático do descodificador MPEG

4.2.6. Codificação de vídeo MPEG-2

O MPEG-2 é um melhoramento do MPEG-1, uma vez que utiliza todas as ferramentas do MPEG-1 e adiciona mais algumas funcionalidades novas, de seguida referidas.

4.2.7. Níveis e perfis MPEG-2

O standard MPEG-2 tem quatro níveis que definem a resolução da imagem, que pode ser desde SIF até HDTV, e tem cinco perfis que



determinam o conjunto de ferramentas de compressão a usar. Desta maneira, há um compromisso entre a taxa de compressão e o custo do descodificador.

A Figura 7 ilustra as características principais dos diferentes níveis e perfis MPEG-2. Note-se contudo que existem combinações de níveis e de perfis que não são utilizadas dado o seu pouco interesse.

Figura 7 – Níveis e perfis MPEG2 Os quatro níveis podem ser descritos do seguinte modo:

• O low level corresponde à resolução SIF utilizada no MPEG-1 (no máximo de 360x288).

• O main level corresponde à resolução standard 4:2:0 (no máximo de 720x576).

• O high-1440 level é utilizado para HDTV (no máximo de 1440x1152). • O high level é optimizado para ecrãs de alta definição HDTV (no

máximo de 1920x1152). No caso dos perfis é um pouco mais complexo:

• O simple profile é definido para simplificar a codificação e a descodificação, em detrimento de um débito binário elevado, uma vez que não utiliza imagens B.

• O main profile constitui actualmente o melhor compromisso entre a taxa de compressão e o custo, uma vez que usa os três tipos de imagens (I, P, B) mas necessita de codificadores e descodificadores relativamente complexos.



• Os scalable profiles estão ainda em desenvolvimento; eles irão permitir a transmissão de imagens de boa qualidade, com resolução espacial ou com exactidão de quantização e com informação suplementar que permite o melhoramento das características das imagens; isto pode ser usado, por exemplo, para transmitir de um modo compatível o mesmo programa com diferentes resoluções ou qualidades.

• O high profile é utilizado para as aplicações broadcast da HDTV nos formatos 4:2:0 e 4:2:2.

Existe uma grande compatibilidade entre os perfis, ou seja, um descodificador de um dado perfil é igualmente capaz de descodificar todos os perfis mais baixos.

Actualmente a combinação mais importante, a utilizada em aplicações broadcast na Europa, designa-se por main profile at main level (MP@ML). Isto corresponde a uma codificação entrelaçada de imagens MPEG-2 no formato 4:2:0 e com resolução de 720x480 a 30 Hz ou 720x576 a 25 Hz. As imagens podem ser dos três tipos (I, P e B). Dependendo do compromisso entre o débito binário e a qualidade e a natureza das imagens a serem transmitidas, o débito binário está, geralmente, entre os 4 Mb/s (PAL ou SECAM) e os 9 Mb/s (perto da qualidade de estúdio).

Em relação à codificação de vídeo, quase todo o processo descrito anteriormente para o MPEG-1 continua a ser válido para o MPEG-2, em particular a hierarquia de camadas. Contudo, existe uma pequena diferença na definição de slices. De facto, não há a necessidade que um slice cubra a imagem inteira e eles são apenas constituídos por blocos contíguos da mesma linha horizontal.

Se se excluírem os níveis e os perfis introduzidos, a principal novidade do MPEG-2 em relação ao MPEG-1 é o processamento de imagens entrelaçadas, o que introduz alguma complexidade e alguma específicidade. Para obter melhores resultados, imagens entrelaçadas têm que ser processadas de uma maneira diferente atendendo à importância dos movimentos entre dois campos de uma imagem.

4.2.8. Especificação MPEG-2 para os modos de predição

A sequência temporal da posição vertical das linhas que pertencem a campos sucessivos de um sistema entrelaçado é apresentada na Figura 8.

Para a codificação interna de imagens entrelaçadas, o MPEG-2 permite escolher uma de entre duas estruturas de imagem, a estrutura do tipo frame e a estrutura do tipo field:

• A estrutura do tipo frame (também designada de progressiva) é mais útil em casos onde ocorre pouco movimento entre dois campos sucessivos. Os macro blocos e os blocos são então retirados da frame completa (Figura 9) sendo-lhes, então, aplicada uma DCT a pontos



verticais consecutivos separados uns dos outros por um período de 20ms, o que não constitui problema para partes da imagem com pouco movimento.

• A estrutura do tipo field (também designada de entrelaçada) é utilizada preferencialmente quando existem movimentos importantes entre dois campos sucessivos. Neste caso, para evitar um conteúdo vertical de alta-frequência, que faria com que a eficiência dos passos de compressão que seguem a DCT diminuíssem, os macros blocos são retirados de um campo (Figura 10) que passa a ser considerado como uma imagem independente.

Figura 8 – Posição das linhas dos sucessivos campos num sistema entrelaçado

Figura 9 – Corte de blocos a partir de macro blocos (modo frame)



Figura 10 – Corte de blocos a partir de macro blocos (modo field)

São também possíveis modos diferentes de estimação de movimento. A predição de um macro bloco pode ser feita num field, numa frame ou então utilizando conjuntamente os dois modos:

• No modo frame, um macro bloco retirado de um campo ímpar é utilizado para fazer a predição do macro bloco correspondente no próximo campo ímpar, acontecendo o mesmo para os campos pares. Os vectores de movimento correspondem à duração de dois campos (40 ms).

• No modo field, a predição de um macro bloco é feita utilizando o campo anterior e os vectores de movimento correspondem à duração de um campo (20 ms).

• No modo mixed, a predição é feita por macro blocos que pertencem a duas frames.

Os diagramas de codificação e descodificação MPEG-1 também se aplicam ao MPEG-2.

Para a realização deste trabalho há necessidade de converter vídeo (MPEG) em imagens. Nas secções seguintes descrevem-se os formatos de imagem considerados bem como os modos possíveis de conversão entre eles.

4.3. YUV

YUV (também conhecido por YCbCr) é um espaço de cor em que o Y representa a componente da luminância e as componentes U e V representam as crominâncias. Este formato é usado normalmente em aplicações de vídeo.

Imagens no formato YUV são criadas a partir de imagens originais no formato RGB. Para produzir a componente da luminância (Y) é necessário agrupar todas as componentes do sinal original (R, G e B). A componente U é gerada posteriormente subtraindo a componente Y da componente



azul (B) do sinal original e a componente V é gerada, subtraindo a luminância (Y) da componente vermelha (R) do sinal original.

A vantagem principal do formato YUV é que é um formato compatível com o preto e branco da televisão analógica. O sinal Y é, essencialmente, o mesmo sinal que é captado por uma câmara a preto e branco normal em que as componentes U e V podem ser simplesmente ignoradas.

Outra das vantagens é que o sinal YUV pode ser facilmente manipulado para, deliberadamente, desprezar alguma informação para ser possível reduzir a largura de banda. Estudos realizados compravam que o olho humano é muito pouco sensível à cor. Por isso, as imagens a cores de alta resolução que vemos actualmente são processadas pelo sistema visual combinando imagens de alta resolução a preto e branco com imagens de baixa resolução a cores. Por exemplo, standards como o NTSC (National Television System(s) Committee) reduz consideravelmente as componentes U e V. Este standard apenas guarda 11% da componente azul original e 30% da vermelha. Como o verde já se encontra codificado na componente Y, as componentes U e V são substancialmente mais pequenas do que seriam se os sinais originais RGB ou YUV fossem enviados. Esta filtragem das componentes azul e vermelho é fácil de conseguir se a imagem estiver no formato YUV. É óbvio que este processo reduz a qualidade da imagem. Nos anos 50, quando o NTSC foi criado, este facto não era um problema uma vez que os equipamentos utilizados na época não permitiam receber imagens de alta qualidade. Nos dias de hoje, os equipamentos televisivos podem transmitir muito mais informação. Isto fez com que se fizessem tentativas de utilizar as imagens com o formato YUV original, sistema que é no usado no VCR (Video Cassette Recorder). O YUV é também usado como formato standard para os algoritmos de compressão de vídeo como o MPEG-2, utilizado na televisão digital e nos DVD´s. O formato de vídeo digital não comprimido CCIR 601 também usa o espaço de cor YUV, para ser compatível com os formatos de vídeo analógico anteriores. Deste modo pode-se facilmente gerar qualquer formato de saída que seja necessário.

Em conclusão, o YUV é um formato versátil que pode ser convertido facilmente noutros formatos de vídeo.

4.3.1. Amostragem YUV

Uma das grandes vantagens do formato YUV é que as componentes de cor (U e V) podem ter uma taxa de amostragem inferior à componente Y sem que seja perceptível uma degradação da qualidade da imagem. Apresentam-se a seguir as taxas de amostragem existentes, em que a notação A:B:C representa, respectivamente, os componentes Y, U e V:

• 4:4:4 - não há sub amostragem das componentes da crominância. • 4:2:2 – existe uma razão de 2:1 de sub amostragem horizontal, sem ocorrer sub amostragem vertical; cada linha de varrimento contém o dobro de amostras Y relativamente às amostras U e V.



• 4:2:0 - existe uma razão de 2:1 tanto de sub amostragem horizontal, como vertical. • 4:1:1 - existe uma razão de 4:1 de sub amostragem horizontal, sem ocorrer sub amostragem vertical; cada linha de varrimento contém quatro amostras Y para cada amostra de U e de V; este é o tipo de amostragem menos comum.

A Figura 11 mostra uma grelha de amostragem usando uma taxa 4:4:4. A componente da luminância é representada por cruzes, enquanto que as componentes de crominância são representadas por círculos.

Figura 11 – Grelha de amostragem usando 4:4:4 A forma dominante da amostragem 4:2:2 é definida na recomendação BT.601 da norma ITU-R. A Figura 12 mostra uma grelha de amostragem associada a este standard.

Figura 12 – Grelha de amostragem usando 4:2:2

Existem duas variantes da amostragem 4:2:0. Uma delas é usada no MPEG-1 e nas recomendações H.261 e H.263 da norma ITU-T (Figura 13) e a outra no vídeo MPEG-2 (Figura 14).



Figura 13 – Grelha de amostragem 4:2:0 no MPEG-1 Figura 14 – Grelha de amostragem 4:2:0 no MPEG-2

É mais simples fazer a conversão nos formatos de amostragem 4:2:2 e 4:4:4 no MPEG-2 do que no MPEG-1. Portanto, o primeiro é preferido no Windows e deve ser utilizado como padrão para a interpretação de formatos 4:2:0. Agora que já foram mencionadas quais as características principais da norma MPEG e da cor, interessa saber como é que é possível transformar os vídeos dos jogos de futebol em imagens. Para isso é necessário utilizar o formato PGM, que vai ser referido de seguida.

4.4. PGM (Portable Gray Map)

O formato PGM é o formato de ficheiro do menor divisor comum da escala de cinzas. Este formato é de concepção muito simples, sendo muito fácil a elaboração de programas que o utilizem.

Uma imagem no formato PGM é apresentada numa escala de cinzas. Existem muitos pseudo-formatos PGM em utilização, onde é tudo especificado excepto o significado de cada valor individual de pixel. Uma imagem PGM pode ser imaginada como sendo um array de inteiros arbitrários.

Um ficheiro PGM consiste de uma sequência de uma ou mais imagens PGM. Não existem dados que delimitem as imagens.

Cada imagem PGM consiste no seguinte:

1. Um “número mágico” para identificar o tipo de ficheiro. O número mágico de uma imagem PGM tem dois caracteres, por exemplo “P5”.

2. Um espaço em branco. 3. Um comprimento formatado em caracteres ASCII decimais. 4. Um espaço em branco. 5. Uma altura, também em caracteres ASCII decimais. 6. Um espaço em branco.



7. O valor máximo de cinzas (Maxval), também em ASCII decimal. Tem que ser menor que 65536 e superior a 0.

8. Uma nova linha ou então um único espaço em branco. 9. Uma sequência de n linhas (em que n é a altura) com ordem de cima

para baixo. Cada linha tem m elementos (em que m é o comprimento) com ordem da esquerda para a direita. Cada valor de cinzas é um número entre 0 e Maxval, representado 0 o preto e Maxval o branco. Cada valor é representado com um binário puro com 1 (se o Maxval for menor que 256) ou 2 bytes. O byte mais significativo é o primeiro.

10. Caracteres que se seguem a um # até ao início da linha seguinte, antes da linha onde é dito o Maxval, representam comentários e são ignorados.

O formato descrito, que é o formato considerado usualmente, é conhecido por formato PGM de linha. Existe ainda uma outra versão menos usual (PGM de plano).

As diferenças do formato PGM de plano relativamente ao de linha são as seguintes:

• Há exactamente uma imagem por ficheiro. • O número mágico é P2 e não P5. • Cada pixel é representado por um número ASCII decimal. • Cada pixel tem, pelo menos, um espaço em branco antes e depois. • Nenhuma linha deve ter mais do que 70 caracteres.

De seguida é apresentado um exemplo de uma pequena imagem no formato PGM de plano:

P2 # feep.pgm

24 7 15

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 3 3 3 3 0 0 7 7 7 7 0 0 11 11 11 11 0 0 15 15 15 15 0 0 3 0 0 0 0 0 7 0 0 0 0 0 11 0 0 0 0 0 15 0 0 15 0 0 3 3 3 0 0 0 7 7 7 0 0 0 11 11 11 0 0 0 15 15 15 15 0 0 3 0 0 0 0 0 7 0 0 0 0 0 11 0 0 0 0 0 15 0 0 0 0 0 3 0 0 0 0 0 7 7 7 7 0 0 11 11 11 11 0 0 15 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

4.5. Cor

Para tentar entender a cor é necessário falar brevemente sobre a luz. A luz é constituída por ondas de energia. Existem radiações de energia (e de comprimento de onda) variada constituindo aquilo a que se chama o espectro electromagnético. Os comprimentos de onda que os nossos olhos podem detectar são apenas uma pequena porção desse espectro, a que se chama espectro visível. Numa das extremidades do espectro visível



encontram-se os comprimentos de onda mais baixos (azul). No outro extremo da parte visível do espectro encontram-se os comprimentos de onda mais altos (vermelho). Todas as outras cores que podem ser observadas encontram-se ao longo do espectro entre o azul e o vermelho.

Se a porção visível do espectro fosse dividida em três partes, as cores predominantes eram o vermelho, o verde e o azul. Estas três cores são consideradas as cores primárias.

Sobrepondo as cores primárias obtêm-se as cores secundárias (ciano, magenta e amarelo).

Apenas existem duas maneiras básicas de reproduzir cor, a aditiva e a subtractiva.

Sistema de cor Aditivo (RGB) O sistema de cor aditivo envolve luz emitida directamente pela fonte, antes de um objecto a reflectir. O processo de reprodução aditivo mistura várias quantidades de luz vermelha, verde e azul para produzir outras cores. Combinando uma cor primária com outra obtém-se uma das cores secundárias (ciano, magenta, amarelo). Combinando todas as cores primárias obtém-se o branco.

A televisão e os monitores dos computadores criam a cor utilizando as cores primárias da luz. Cada pixel num ecrã começa a preto. Quando o vermelho, o verde e o azul de um pixel são simultaneamente iluminados, ele fica branco. Este fenómeno designa-se por cor aditiva. Milhares de pontos fosforescentes vermelhos, verdes e azuis constroem as imagens nos monitores de vídeo. Os pontos fosforescentes emitem luz quando activados electronicamente e é a combinação de diferentes intensidades de vermelho, verde e azul que produz todas as cores num monitor de vídeo. Como os pontos são tão pequenos e estão tão próximos uns dos outros, não os conseguimos ver individualmente; aparecendo-nos uma



imagem a cores sem descontinuidades. As cores variam normalmente de um monitor para outro e ao longo do tempo. Actualmente, não existe nenhum standard para o fosforescente utilizado na produção de monitores para a indústria gráfica.

Todos os dispositivos de captura de imagens utilizam o sistema aditivo de cor para reunirem a informação necessária para reproduzir a imagem de cor.

4.5.1. Espaço de cor e conversões de taxa de amostragem de cor

Consideram-se dois esquemas de codificação RGB diferentes: 8-bit computer RGB, que é também conhecido por sRGB ou por “full-scale” RGB, e o studio video RGB, ou “RGB with head-room and toe-room”. Estes esquemas são definidos de seguida:

• O computer RGB utiliza 8 bits para cada amostra de vermelho, verde e azul. O preto é representado por R=G=B=0 e o branco é representado por R=G=B=255.

• O studio video RGB utiliza um número de bits N para cada amostra de vermelho, verde e azul, onde N é maior ou igual a 8. Este esquema utiliza um factor de escala diferente do computer RGB e tem um offset. O preto é representado por R=G=B=16*2N-8, e o branco é representado por R=G=B=235*2N-8. Contudo, poderão existir valores que se encontram fora destes limites.

O studio Video RGB é a definição RGB preferida para vídeo no Windows, enquanto que o computer RGB é a definição RGB preferida para aplicações não vídeo.

4.6. Conversão entre RGB e YUV 4:4:4

Para converter YUV 4:2:0 ou YUV 4:2:2 para RGB recomenda-se converter primeiro os dados YUV para o formato YUV 4:4:4 e, só depois, converter de YUV 4:4:4 para RGB. O formato AYUV, que é outra designação para o formato YUV 4:4:4, utiliza 8 bits para cada amostra de Y, U e V. Em algumas aplicações, YUV pode também ser definido utilizando mais de 8 bits.

Existem duas conversões que foram definidas para o vídeo digital entre YUV e RGB. Ambas são baseadas na recomendação BT.709 da norma ITU-R. Uma das conversões é considerada a preferida para o formato YUV para a definição standard da resolução da TV (720 x 576). É caracterizado por duas constantes Kr e Kb:

Kr = 0,299 Kb = 0,114



Outra conversão é considerada preferível para as resoluções de vídeo a partir da SDTV. É caracterizada por valores diferentes para as duas constantes:

Kr = 0,2126 Kb = 0,0722

A conversão de RGB para YUV é definida começando pela expressão:

L = Kr * R + Kb * B + (1 – Kr – Kb) * G

Os valores de YUV são obtidos da seguinte forma:

Y = floor (2^ (M-8) * (219 * (L–Z) / S + 16) + 0,5) U = clip3 (0, 2^ (M-1), floor (2^ (M-8) * (112 * (B-L) / ((1- Kb) * S) + 128) +

0,5)) V = clip3 (0, 2^ (M-1), floor (2^ (M-8) * (112 * (R-L) / ((1- Kr) * S) + 128) +

0,5))

Onde

• M é o número de bits por amostra de YUV (M >= 8). • Z é a variável que indica o nível de preto. Para o computer RGB, Z é

igual a 0. Para o studio video RGB, Z é igual a 16 * 2N-8, onde N é o número de bits por amostra de RGB (N> = 8).

• S é uma variável de escala. Para o computer RGB, S é igual a 255. Para o studio video RGB, S é igual a 219 * 2N-8.

A função floor(x) retorna o maior inteiro maior ou igual a x. A função clip3( x, y, z) é definida por:

clip3(x, y, z) = ((z < x) ? x : ((z > y) ? y : z))

A amostra Y representa a luminância, e as amostras de U e V representam os desvios de cor em relação ao azul e ao vermelho, respectivamente. A gama nominal de valores para o Y varia entre 16 * 2M-8 e 235 * 2M-8. O preto é representado por 16 * 2M-8 e o branco é representado por 235 * 2M-8. A gama nominal de valores para as componentes U e V varia entre 16 * 2M-8 e 240 * 2M-8, com o valor 128 * 2M-8 a representar a crominância neutra. Contudo, actualmente existem valores que podem encontrar-se fora destas gamas.

Para dados de entrada na forma de studio video RGB, a operação de clip é necessária para manter os valores das componentes U e V entre 0 e 2M-1. Se os dados de entrada forem computer RGB, a operação de clip não é necessária porque a fórmula de conversão não produz valores fora da gama de valores admitida.



4.6.1. Conversão de RGB para YUV 4:4:4

No caso de uma entrada em computer RGB e uma saída em YUV de 8-bit, é possível aproximar as fórmulas mencionadas na secção anterior pelas fórmulas seguintes:

Y = ((66 * R + 129 * G + 25 * B + 128) >> 8) + 16 U = ((-38 * R – 74 * G + 112 * B + 128) >> 8) + 128 V = ((112 * R – 94 * G – 18 * B + 128) >> 8) + 128

Estas fórmulas produzem resultados de 8 bits usando coeficientes que não requerem mais de 8 bits (sem sinal) de precisão. Resultados intermédios requerem 16 bits.

4.6.2. Conversão de YUV de 8-bits para RGB

Da expressão original de conversão de RGB para YUV podemos derivar as seguintes relações:

Y = round (0,256788 * R + 0,504129 * G + 0,097906 * B) + 16 U = round (-0,148223 * R – 0,290993 * G + 0,439216 * B) + 128 V = round (0,439216 * R – 0,367788 * G – 0,071427 * B) + 128

Considerando:

C = Y – 16 D = U – 128 E = V – 128

As fórmulas para converter de YUV para computer RGB são as seguintes:

R = clip (round( 1,164383 * C + 1,596027 * E)) G = clip (round( 1,164383 * C – ( 0,391762 * D) – ( 0,812968 * E)))

B = clip (round( 1,164383 * C + 2,017232 * D))

Onde a função clip() faz o clipping entre a gama de valores de 0 a 255. Estas fórmulas podem ser razoavelmente aproximadas por:

R = clip ((298 * C + 409 * E + 128) >> 8) G = clip ((298 * C – 100 * D – 208 * E + 128) >> 8)

B = clip (( 298 * C + 516 * D + 128) >> 8)



Estas fórmulas usam alguns coeficientes que requerem mais de 8 bits de precisão para produzir um resultado de 8 bits e os resultados intermédios requerem mais de 16 bits.

4.7. Métodos simples de detecção de cortes de cena

4.7.1. Variação da intensidade dos Pixels

As mudanças entre duas frames podem ser detectadas comparando as diferenças entre os valores de intensidade dos pixels correspondentes às duas frames. O algoritmo conta qual o número de pixels que foi alterado, sendo o corte de cena declarado se a percentagem do número total de pixels alterados exceder um certo limite. Matematicamente, o método é traduzido pelas equações (1) e (2). Na equação (1), Fi (x, y) é o valor da intensidade do pixel na frame i nas coordenadas (x, y). Se a diferença entre os pixels correspondentes nas duas frames for superior a um certo limite mínimo, a diferença na imagem DPi (x, y) é colocada a um. Na equação (2), a percentagem da diferença entre os pixels de duas frames é calculada somando a diferença na imagem e dividindo pelo número total de pixels existente numa frame. Se essa percentagem for superior a um determinado valor, é porque ocorreu um corte de cena.

( ) >−

= +

valoresoutrostyxFyxFse

yxDP iii 0

),(,1),( 1 (1)

TYX

yxDPYX

yxi

>∑

= 100**

),(,

1, (2)

Em alternativa pode-se usar um método semelhante que consiste em adicionar as diferenças de intensidades de todos os pixels nas duas frames e estabelecer a comparação do valor obtido com um valor limite previamente definido. Se esse valor for superior ao estabelecido, então ocorreu um corte de cena.

Movimentos de câmara, como o zoom, podem afectar um largo conjunto de pixels e, deste modo, um corte de cena errado ser detectado. Objectos que se movem rapidamente também provocam o mesmo efeito. Se forem comparadas as intensidades médias dos valores dos pixels os efeitos da câmara e os movimentos rápidos são reduzidos.



4.7.2. Razão de probabilidades

A detecção de alterações pixel a pixel não é um método muito robusto de resolver o problema. Um método melhor é baseado em critérios estatísticos uniformes de segunda ordem sobre uma região. Uma frame pode ser subdividida em blocos e os blocos podem ser comparados com base nas características estatísticas relacionadas com os seus níveis de intensidade. A equação (3) representa uma fórmula que calcula uma função de probabilidade, considerando iµ e 1+iµ como sendo os valores das intensidades médias de uma dada região de duas frames consecutivas e iσ e 1+iσ as variâncias correspondentes. Se o valor dessa função de probabilidade for superior a um certo limite pré-estabelecido atribui-se o valor 1 à variável de diferença, como se vê na equação (4). O processo é repetido para todos os blocos considerados. Se o somatório das variáveis de diferença é superior a um determinado limite é porque existe um corte de cena.

1

2211

*22

+

++

−

++

=ii

iiii

σσ

µµσσ

λ (3)

>

=valoresoutrostse

lkDPi 01

),(λ

(4)

Este método é melhor do que o anterior uma vez que aumenta a tolerância ao ruído associado com a câmara e a movimentação do objecto. É possível, mesmo assim, que dois blocos analisados de frames consecutivas sejam diferentes e tenham a mesma função de probabilidade. Nestes casos os cortes de cena poderão não ser detectados.

4.7.3. Comparação de histogramas

A sensibilidade da análise à câmara e ao movimento do objecto pode ser reduzida comparando os níveis de cinzento de duas frames consecutivas o que se consegue através de histogramas. O histograma é obtido a partir de um número de pixels pertencentes a cada nível de cinzento de uma frame. Na equação (5), G representa o número total de níveis de



cinzento, j é o nível de cinzento, i é o número da frame e )( jHi é o histograma para o nível de cinzento j e para a frame i .

∑=

+ >−G

jii tjHjH

11 )()( (5)

Se a soma for superior a um dado limite pré-estabelecido um corte de cena é detectado.

4.8. Um método mais complexo - DCT (Discrete Cosine Transform)

A DCT é uma transformação matemática, reversível e sem perdas, que converte uma representação de dados espaciais em amplitude numa representação de dados espaciais em frequência. Uma das vantagens da DCT é a sua propriedade de compactação da energia; a energia do sinal encontra-se concentrada em poucos componentes enquanto a maior parte dos componentes tem energia zero ou muito baixa. A DCT foi utilizada inicialmente em 1974 e, desde então, tem sido muito usada em aplicações como a filtragem, codificação de voz e de imagem, reconhecimento de padrões, entre outras. A DCT é largamente utilizada em aplicações de compressão de imagem e, por isso, é utilizada no JPEG e MPEG. A propriedade de compactação de energia é importante para a compressão de imagens uma vez que, na maior parte delas, a energia se encontra concentrada numa gama de frequências restrita. A DCT não é fácil de implementar porque depende dos dados mas permite uma taxa de compressão elevada.

A expressão matemática que representa a DCT é a seguinte:



4.8.1. Fast DCT – método dos três coeficientes

O coeficiente DC e os primeiros coeficientes AC horizontal e vertical são, na maior parte dos casos, suficientes para representar um bloco 8x8. Por isso, o método de três coeficientes pode ser uma boa solução prática como um método de DCT rápido [10]. Todos os blocos 8x8 formam um sinal com 64 dimensões espaciais, mas os blocos que podem ser representados por apenas três coeficientes diferentes de zero encontram-se num sub espaço linear do espaço de 64 dimensões. Em teoria, é possível calcular os três coeficientes a partir de apenas três coeficientes das 64 amostras que constituem o bloco 8x8 e fazendo uma multiplicação a uma matriz 3x3. Na prática, devem-se usar mais do que três coeficientes para o algoritmo ser mais imune ao ruído.

O algoritmo consiste em realizar a soma das amostras da primeira e da última linha do bloco 8x8 (h0 e h7) e a soma das amostras da primeira e da última coluna (v0 e v7). A partir dos valores anteriores podem-se calcular o coeficiente DC e os dois coeficientes AC:

C00 = kdc (h0 + h7 + v0 + v7)

C01 = kac (v0 - v7)

C10 = kac (h0 - h7)

Os factores de escala são escolhidos para que este algoritmo produza resultados semelhantes aos obtidos com o DCT completo para alguns padrões de blocos importantes. Considerando um bloco constante, obtém-se imediatamente que kdc = 1/4. O factor de escala AC é escolhido de modo a que os coeficientes c01 e c10 sejam idênticos aos do DCT completo tendo uma rampa horizontal e vertical como sinal de entrada. Isto faz com que kac = 21/64. Este método apenas necessita de trinta e três adições para um bloco 8x8, e por isso este método consegue ser oitenta vezes mais rápido que a DCT completa.

4.8.2. Fast DCT - método de Skal

Vai-se agora descrever o método de Skal de ordem O(N*N*ln(N)) [1W], mais rápido que a DCT completa que é de ordem O(N*N*N). Este método usa o esquema de dois passos, utiliza apenas uma transformada de uma dimensão, repetindo o processo oito vezes nas linhas e nas colunas.

Existem muitas redundâncias e simetrias escondidas nos valores dos termos )2/)12.(.cos( Nnk +π que aparecem na expressão matemática do



DCT. Na realidade, para N = 8, apenas existem sete valores distintos. Expandindo a matriz e identificando as constantes e subtermos comuns, obtém-se as seguintes equações com 22 multiplicações e 28 adições:

Fase 0 ( Butterflies originais): m0 = x0+x7 m7 = x0-x7

m1 = x1+x6 m6 = x1-x6 m2 = x2+x5 m5 = x2-x5 m3 = x3+x4 m4 = x3-x4

Fase 1 (parte par): tp03 = m0 + m3

tm03 = m0 - m3

tp12 = m1 + m2 tm12 = m1 – m2 z0 = c4 . (tp03 + tp12) z4 = c4 . (tp03 - tp12) { z2, z6 } = Rot_6( tm03, tm12)

Fase 2 (parte ímpar):

{ z1, z7 } = Rot_7( m4, m7) + Rot_3( m6, m5) { z2, z6 } = Rot_3( m7, m4) + Rot_1( m5, m6)

Notas: • Estão a ser omitidos factores de escala nos coeficientes de saída. • Rot_n(x, y) é a abreviação para uma rotação de ângulo de 16/.πn . Por

isso, escrever { x´, y´} = Rot_6(x, y) quer dizer:

x’ = c6.x + c2.y y’ = -c2.x + c6.y

• A transformação {x, y} => { x+y, x-y} é muito comum e designa-se por butterfly.

Um esquema do que ocorre nos passos 0 e 1 é apresentado de seguida:



Existem várias maneiras de explicar como é que as rotações são realizadas. O truque habitual para se realizar uma rotação com 3 multiplicações e 3 adições é:

tmp = (x+y) . cos(t) x’ = tmp + y . (sin(t) – cos(t)) y’ = tmp – x . (sin(t) + cos(t))

Isto é usado pela DCT na biblioteca JPEG. Outra maneira de calcular rotações é através de:

x´= [ x + y.tan(t)] . cos(t) y´= [ y - x.tan(t)] . cos(t)

Este método conta com 4 multiplicações e 2 adições porque é possível atrasar o factor de escala de cos(t). A grandeza tan(t) mantém-se normalmente numa gama de valores entre 0 e 1, o que é uma boa propriedade para expressões aritméticas de valor fixo.

Os três esquemas equivalentes para a rotação são apresentados a seguir:

As rotações consomem a maior parte do tempo, especialmente as da fase 2. Mesmo assim ainda há lugar para um melhoramento na fase 1. Considerando as relações trigonométricas apresentadas de seguida:

128

3tan +=π



128

tan

83tan

1−==

ππ

Pode-se escrever Rot_6 do seguinte modo:

( )[ ]166cos.2

166sin

166cos πππ yxyyx ++=+

( )[ ]166sin.2

166cos

166sin πππ yxyyx +−=+−

Deste maneira têm-se dois termos comuns: y2 e ( )yx + .

Dependendo do custo das operações de multiplicação em relação aos registos temporários que estão disponíveis, este método pode ser vantajoso ou não. De seguida, apresentam-se três maneiras equivalentes de efectuar a Rot_6. A entrada é [tm03, tm12] e a saída é [x, y].

Método 1 Método 2 Método 3 x <- tm03; x <- tm03; x <- tm03; tmp1 < )8/3tan( π ; y <- )8/tan(π ; tmp <- tm12; y <- tm12; y *= x; y <- x; tmp2 <- tmp1; x += tm12; x += tmp; tmp1 *= x; y -= tm12; y +=x; tmp2 *=y; x += x; x *= )8/tan(π ; y -= tmp1; x += y; y += x; x += tmp2; x += tmp;

Comparando os métodos chega-se às seguintes conclusões:

o O método 1 usa duas variáveis temporais e duas multiplicações mas demora mais tempo que os outros.

o O método 2 não utiliza nenhuma variável temporal e apenas utiliza uma multiplicação. É mais rápido, mas lê tm12 da memória duas vezes.

o O método 3 apenas lê a entrada uma vez, mas usa um registo temporário.

o Os métodos 2 e 3 são menos regulares que o método 1 porque necessitam de mais adições e multiplicações para a entrada ’x’ do que para a ‘y’. Por isso são precisos mais bits de precisão para ‘x’ do que para ‘y’.



Para a fase 2, podem-se escrever as seguintes expressões para as quatro rotações:

−−−−−−

=

07162534

*

1331311331131331

7531

VmVmVmVm

ssccscsccscsccss

zzzz

Um esquema para a FDCT da fase 2 é apresentado de seguida:



5 IMPLEMENTAÇÃO

Antes de fazer a análise dos métodos para a detecção de cortes de cena é necessário escolher a linguagem a utilizar para o desenvolvimento do programa. Por outro lado, é necessário arquitectar uma interface gráfica que permita a interacção entre o programa e o utilizador. É esse o principal tema deste capítulo.

5.1. Linguagens e Plataformas

As linguagens escolhidas para desenvolver este projecto foram o C e o C++, sendo uma das principais razões da escolha o conhecimento prévio destas linguagens por parte do autor deste relatório. Depois de escolher as linguagens foi necessário seleccionar a plataforma a utilizar para construir o ambiente visual. As duas plataformas analisadas foram o MFC e o wxWindows. Optou-se pelo wxWindows pela sua portabilidade, isto é, por poder funcionar em vários sistemas operativos.

O wxWindows é um conjunto de bibliotecas que permite que aplicações C++ compilem e corram em vários tipos diferentes de computadores, com um mínimo de alterações ao código. O wxWindows é um framework que possui muitas funcionalidades que o programador pode usar ou alterar para melhor servir os seus propósitos, poupando assim muito tempo. A plataforma suporta também estruturas de dados básicas como strings, arrays, listas ligadas e hash tables.

A API (Application Programming Interface) do wxWindows tem um enorme sucesso devido a ser intuitiva e simples. Esta ferramenta não é a única, mas é livre, bem documentada e de uso corrente entre os programadores.

5.2. Desenvolvimento da Aplicação

A primeira tarefa que tem que ser executada pelo programa é perguntar ao utilizador onde se encontra o vídeo que pretende analisar. Numa primeira fase este vídeo vai-se encontrar armazenado como um conjunto de imagens e, por isso, basta indicar qual é a primeira imagem da sequência que se pretende analisar. O número de imagens que vão ser analisadas deverá ser imediatamente visualizável. Para se escolher a primeira imagem a analisar, o programa terá de conter uma barra para menus em que um dos itens deverá ser, por exemplo, como o apresentado de seguida:



Figura 15 – Exemplo da barra de menu

A função open tem um certo grau de complexidade na medida em que são necessárias instruções de modo a que seja possível dirigir a escolha para a imagem pretendida. Na Figura 16 apresenta-se um fluxograma que descreve o que esta função terá que fazer.

Figura 16 – Fluxograma da função open



É ainda necessário escolher o método a utilizar para efectuar a detecção dos cortes de cena. Por isso, o programa também terá de conter uma pequena caixa onde aparecem todos os métodos considerados, podendo o utilizador seleccionar um deles (Figura 17).

Figura 17 – Exemplo da caixa de selecção do método

A função que vai ter esta caixa de escolha do método é explicada na Figura 18.

Figura 18 – Fluxograma da função select Depois de estarem realizadas as duas tarefas anteriores pode-se começar a fazer a análise. Para isso, é necessário dispor de um botão de play. É importante haver um outro botão de stop, para que seja possível cancelar a análise quando pretendido (Figura 19).



Figura 19 – Botões de início e de interrupção da análise

É interessante também colocar uma barra de progresso(Figura 20). Desta maneira, o utilizador tem uma percepção visual imediata do tempo que demora a análise que está a ser feita.

Figura 20 – Barra de progresso de análise

Enquanto a análise está a decorrer vão ser detectados cortes de cena pelo método escolhido. Mostrar os cortes de cena à medida que vão sendo detectados é um dos aspectos com mais relevância (Figura 21), uma vez que se pode desde logo verificar se o método escolhido para a análise tem alguma validade e interromper a execução no caso contrário.

Figura 21 – Exemplo do espaço onde aparecem os cortes de cena detectados



Para além de ser possível visualizar as imagens, é essencial que o programa nos apresente as estatísticas da última análise que foi realizada ou da análise que está a ser feita.

As grandezas mais relevantes que terão de ser apresentados são:

• O número de cortes de cena detectados. • O número de cortes de cena detectado com erro (observado pelo

utilizador). • O número de comparações que ficaram muito próximos de ser cortes

de cena. • O tempo total da análise.

Uma imagem tipo dos resultados da análise é apresentada na Figura 22.

Figura 22 – Exemplo do espaço onde aparecem os resultados da análise

Todas as tarefas imediatamente anteriores são partes integrantes da função play. Um fluxograma que descreve o funcionamento desta função está apresentado na Figura 23.



Figura 23 – Fluxograma da função play

É também útil poder visualizar todos os cortes de cena detectados após a análise (para ser possível uma posterior eliminação de algum corte de cena incorrecto), ter-se uma listagem de todos os cortes de cena detectados (com a indicação dos valores obtidos segundo o critério utilizado em comparação com os limites estipulados) e também um histórico que mostre a percentagem de erros na detecção dos cortes de cena, bem como o tempo que demora cada análise a ser efectuada por



imagem, para cada um dos métodos. Para que isso seja possível, é necessário ter na janela principal os seguintes botões (Figura 24):

Figura 24 – Exemplo dos botões de resultados finais

Cada um destes botões vai fazer com que seja aberta uma nova janela. Já foi explicado anteriormente o conteúdo de cada uma delas. Na Figura 25 mostra-se o aspecto de cada uma dessas janelas.

Figura 25 – Exemplo das janelas de resultados finais

Cada uma destas funções pode ser idealizada como se esquematiza nos fluxogramas seguintes (Figuras 26, 27 e 28):



Figura 26 – Fluxograma da função statistic

Figura 27 – Fluxograma da função log

Para conseguir a visualização dos cortes de cena posteriormente à análise é necessário implementar várias funções. A primeira função necessária tem a ver com a visualização do primeiro corte de cena. A janela onde é apresentado o corte de cena irá conter quatro botões, dois para avançar/recuar um corte de cena e outros dois para avançar/recuar cinco cortes de cena. Como estas funções realizam tarefas semelhantes, vai-se apenas apresentar um fluxograma tipo de uma delas. Assim, na Figura 28 encontram-se os fluxogramas das funções de visualização do primeiro corte de cena e de visualização do corte de cena anterior.

Para além destes botões ainda existe um outro que permite a eliminação de cortes de cena.



Figura 28 – Fluxogramas das funções visualizar o primeiro corte de cena e visualizar o corte de cena anterior

Uma função adicional que o programa pode ter é a possibilidade de correr o filme que está a ser analisado. Esta facilidade permite ao utilizador ter uma noção de quantos cortes de cena é que existem mesmo antes de proceder à realização da análise (Figura 29).



Figura 29 – Exemplo da janela de pré-visualização do filme

O fluxograma da função preview, necessária para o efeito, pode ser feito como se mostra na Figura 30.

Figura 30 – Fluxograma da função preview

5.3. Interface Gráfica

Embora não entenda ser necessário descrever em pormenor aspectos específicos de programação em wxWindows, penso que interessa referir qual é a estrutura utilizada por esta plataforma para que se possam desenvolver programas.

Um programa em wxWindows pode ser definido, de uma forma simples, como sendo constituído por duas partes (Figura 31):



• Uma aplicação – uma instância da classe wxApp • Uma frame – uma instância da classe wxFrame.

Uma frame pode conter uma barra de menu, uma barra de estado, ícones, etc. A frame pode ser um contentor que contém inúmeros objectos como botões, separadores, blocos de texto, etc.

Figura 31 – Constituição de um programa em wxWindows

No presente trabalho, como na maioria das situações, tem-se apenas uma frame onde todas as funções que o programa tem de desempenhar estão presentes. O resultado final da aplicação desenvolvida em termos do ambiente visual é apresentado na Figura 32.

Figura 32 – Ambiente gráfico desenvolvido



Apenas o item Analysis, presente na barra de menu, não foi ainda discutido. Este item permite ao utilizador escolher entre fazer a análise da correcção dos cortes de cena apenas no final da análise, utilizando o botão See all Cut Scenes, ou fazê-la à medida que o programa corre. Neste último caso, sempre que é detectado um corte de cena irão aparecer no ecrã dois botões para o utilizador confirmar ou não se se trata de um corte de cena. Se se tratar de um erro, o correspondente corte de cena é logo eliminado e o campo que contém o número de cortes de cena detectados com erro é actualizado.



6 CONVERSÃO DE MPEG PARA PGM

Como já foi referido anteriormente, para que seja possível fazer a análise dos cortes de cena é necessário converter o vídeo em imagens. Neste trabalho, como se trata de uma primeira abordagem ao problema, o estudo será limitado ao modo offline. Isto quer dizer, que o jogo não está a ser transmitido em directo; o que se tem é um filme do jogo e é com ele que se vai trabalhar. Refira-se que futuramente será necessário implementar outro procedimento, uma vez que este processo não é viável para fazer a segmentação. Imaginando que uma imagem ocupa 400 kbytes e que em cada segundo existem 25 imagens, se um jogo demora cerca de 100 minutos, podemos concluir que no total temos 25 * 100 * 60 imagens, o que dá 150000 imagens, a que correspondem cerca de 60 Gbytes de espaço em disco.

Para converter um ficheiro MPEG em imagens utilizou-se uma biblioteca que se designa por libmpeg2 [2W], e que se destina a descodificar streams de vídeo MPEG1 e MPEG2. A principal razão porque se preferiu esta biblioteca em relação a outras foi a existência, no próprio pacote que continha a biblioteca, de um pequeno programa de teste, mpeg2dec. O código deste programa também se encontra disponível. Deste modo, é relativamente simples escrever um programa de conversão de imagens, bastando para isso analisar com alguma atenção o código da aplicação mpeg2dec.

Foi assim possível escrever um programa simples de conversão de MPEG para imagens no formato PGM. Este programa pergunta ao utilizador onde é que se encontra o ficheiro que ele quer converter, o número de frames que ele pretende e qual é a frame inicial. Um screenshot do funcionamento do programa bem como o resultado final são apresentados de seguida (Figuras 33 e 34).

Figura 33 – Screenshot do programa de conversão de MPEG para PGM



Figura 34 – Directoria onde ficaram gravadas as imagens PGM e reprodução de uma delas



7 TESTES PRELIMINARES

Como já referido no capítulo 4, para fazer a análise dos cortes de cena são utilizados vários métodos. Em todos esses métodos estabelece-se uma comparação entre um determinado valor associado a cada um deles e um valor limite. Se o primeiro valor for superior a esse limite significa que existe corte de cena e que no caso contrário não existe.

O valor limite a utilizar em cada um dos métodos é definido pelo programador. Ele deve ser escolhido de modo a que seja possível detectar todos os cortes de cena verdadeiros presentes no conjunto de imagens analisadas. Então, para seleccionar o limite a usar em cada um dos métodos, é necessário levar a efeito uma série de testes relativos a vários jogos e a diferentes momentos de um mesmo jogo para testar os efeitos da variação da luminosidade.

Antes de apresentar os resultados que foram obtidos importa referir o que é que se entende por corte de cena e mencionar outras situações que podem ocorrer que interferem na análise dos cortes de cena.

A definição genérica e simples de corte de cena implica que ocorra uma mudança de câmara. Num desafio de futebol é uma situação como a apresentada na Figura 35, em que o conteúdo de duas imagens consecutivas é completamente diferente.

Figura 35 – Exemplo de corte de cena

A transmissão de televisão não é feita imagem a imagem, mas sim por campos, o campo par e o campo ímpar. Como os campos são transmitidos



dois a dois, podem ocorrer as duas diferentes situações apresentadas nas Figuras 36 e 37.

Figura 36 – Criação das imagens (F1, F2) a partir de campos com a mesma sequência (C1, C2, C3, C4) Imaginemos duas sequências de transmissão (C, D). Uma sequência é um conjunto de imagens que se refere a uma jogada filmada pela mesma câmara. Se a sequência ocupar um número par de campos (Figura 36), então quando existe uma mudança de sequência os campos par e ímpar seguintes transmitem apenas informação da próxima sequência. O mesmo não acontece se a sequência ocupar um número impar de campos (Figura 37), já que os campos par e ímpar seguintes ficam com informação de sequências diferentes e a imagem correspondente a esses campos fica com as duas sequências, como se apresenta na Figura 38.

Figura 37 – Criação das imagens (F1, F2) a partir de campos com sequências diferentes (C1, C2, C3,

D1)



Figura 38 – Exemplo de uma imagem com duas sequências sobrepostas

Outra situação que ocorre nos jogos de futebol tem a ver sobretudo com as repetições dos lances mais interessantes. Quando ocorrem as repetições, não há nenhuma mudança brusca entre a sequência de jogo que está a ser transmitida e a repetição de um lance anterior. Nestes casos são utilizados efeitos especiais, designados por cortinas. As cortinas diferem de realização para realização, mas normalmente demoram mais do que dez imagens consecutivas. No caso das transmissões televisivas do Euro 2004 as cortinas que foram utilizadas são apresentadas na Figura 39.

Figura 39 – Exemplo das cortinas utilizadas nas transmissões do Euro 2004

Como é óbvio, a detecção de cortinas e de sobreposição de campos é difícil porque não existem variações bruscas entre as imagens. Estes dois casos não vão ser considerados neste trabalho, uma vez que o que interessa é a detecção de cortes de cena que correspondem simplesmente



a mudanças de câmara. No entanto, refira-se que estes dois casos eram facilmente detectáveis (incorrectamente no caso das cortinas) como cortes de cena se a análise fosse feita de 25 em 25 imagens (de 1s em 1s) em vez de ser feita de uma em uma. Ocorre na mesma uma mudança de cena, só que em vez de ser entre uma imagem e a seguinte é, no primeiro caso, entre uma imagem e as duas seguintes e, no segundo caso, entre uma imagem e, aproximadamente, as dez imagens seguintes.

Sabendo que a análise que vai ser efectuada vai ser de imagem a imagem e não de 25 em 25 imagens, não se vão considerar estes casos como sendo cortes de cena mas, se forem detectados, não se vão considerar que ocorreram erros na detecção, isto é, estas situações vão ser ignoradas na análise.

Posto isto, pode-se avançar para a apresentação e discussão dos resultados preliminares.

Foram usados todos os métodos descritos no Capítulo 4. Para comodidade do leitor interessa referir como eles serão designados nas tabelas de resultados. Assim:

• Variação de intensidade de pixels (diferença total) – Total Pixel Dif.

• Variação de intensidade de pixels (em percentagem) - Pixel Dif.

• Razão de probabilidades - Block Dif.

• Comparação de histogramas - Histogram

• DCT (método com três coeficientes) – DCT 3 coef.

• DCT (método de Skal) – skal DCT

Os primeiros testes efectuados foram feitos a sequências do jogo da Final da Taça de Portugal de 2004 entre as equipas do Futebol Clube do Porto e do Sport Lisboa e Benfica. Estes testes tiveram como principal objectivo verificar se as condições de luminosidade ao longo do jogo provocavam alterações significativas nas diferenças detectadas entre imagens. Para isso escolheram-se as jogadas dos três golos que ocorreram nessa final; como foram todos obtidos em partes distintas do jogo, estas jogadas servem o objectivo.

Os resultados obtidos para cada um dos golos e para os diferentes métodos são apresentados nas Tabelas 1, 2 e 3. A Tabela 1 refere-se ao golo do Derlei (1ª parte), a Tabela 2 ao golo do Fyssas (2ª parte) e a Tabela 3 ao golo do Simão (prolongamento). A primeira coluna indica as imagens onde ocorrem cortes de cena correctos, enquanto que nas outras colunas são apresentados os valores obtidos através das expressões características para cada um dos métodos nesses cortes de cena.



Tabela 1 – Parâmetros característicos de análise de cortes de cena pelos vários métodos (FCP vs SLB – 1/0)

FCP vs SLB (1/0)

Tot. Pixel Dif. Pixel Dif. Block Dif. Histogram

DCT 3 coef. skal DCT

135-136 16796109 59,24 1517 602656 6316 3874 312-313 14119073 54,92 1422 546366 6076 3372 717-718 8489941 25,92 1339 374896 5435 1564

1254-1255 14199132 42,99 1173 354966 5868 2692 1514-1515 11206520 37,58 948 336342 5545 1860 1557-1558 12967276 43,73 1090 357708 5829 2402 1672-1673 12909910 48,61 1394 557366 5954 2606 2195-2196 12102428 41,96 1347 335532 5869 2629 3504-3505 17092015 50,78 1190 239792 6179 3440


FCP vs SLB (1/1)



1428-1429 16786983 50,55 1388 493758 6061 3120 1500-1501 13995288 42,75 1479 358752 5913 2669 1575-1576 10665071 44,55 1529 475528 5979 2451 1922-1923 11387444 45,27 1130 390588 5787 2337


FCP vs SLB (1/2)


DCT 3 coef.

skal DCT

1366-1367 15268865 54,6 1319 314870 6257 3541 3065-3065 13505506 55,7 1490 290796 6147 3595

Analisando os resultados podemos ver, desde já, que os valores mínimos obtidos nos diferentes lances são bastante diferente. O mesmo acontece dentro de cada lance para os vários cortes de cena.

Para uma análise mais cuidada da dispersão dos resultados têm que ser analisados os valores do desvio padrão relativos a cada um dos métodos. O desvio padrão será tanto maior quanto mais variabilidade houver entre os dados. Nas Tabelas 4, 5 e 6 encontram-se os valores da média, do desvio padrão e o valor mínimo para as jogadas referidas.



Tabela 4 – Parâmetros estatísticos dos vários métodos (FCP vs SLB – 1/0)

FCP vs SLB (1/0)



mínimo 8489941 25,92 948 239792 5435 1564 média 13320267 45,08 1269 411736 5897 2715 desvio padrão

2676148 9,88 181 124669 282 748


FCP vs SLB (1/1)




2781478 3,35 178 65235 116 346


FCP vs SLB (1/2)


DCT 3 coef.

skal DCT


1246883 0,78 121 17023 78 38

Tal como já tinha sido referido no que diz respeito a cada uma das jogadas, os valores do desvio padrão mostram que a variabilidade é elevada para a maior parte dos métodos. Por isso, a utilização de um limite invariável poderá não ser a solução mais correcta para abordar o problema. Uma alternativa possível é utilizar o algoritmo económico, também conhecido por algoritmo móvel. Este algoritmo, em cada passo, considera não só o valor obtido na iteração anterior mas também todos os valores que já foram analisados, segundo a expressão:

2limlim valorobtauxaux +

=

Para descobrir qual o valor limite a utilizar para a detecção dos cortes de cena basta multiplicar o valor obtido da expressão anterior por um factor multiplicativo. Na utilização do algoritmo móvel é necessário definir o valor máximo para o factor multiplicativo, de modo a que todos os cortes de cena sejam detectados. As Tabelas 7, 8 e 9 mostram os factores multiplicativos obtidos para cada um dos cortes de cena, bem como o factor multiplicativo mínimo em cada um dos lances.



Tabela 7 - Factores multiplicativos para os vários métodos utilizando o algoritmo móvel (FCP vs SLB – 1/0)

FCP vs SLB (1/0)


DCT 3 coef.

skal DCT

135-136 1,93 2,08 2,98 17,89 1,11 2,78 312-313 32,78 118,91 27,46 21,18 1,36 6160,09 717-718 6,52 8,52 315 37,51 1,08 576,03

1254-1255 9,34 16,5 107,25 21,81 1,14 37088,06 1514-1515 2,52 2,77 13,35 19,17 1,08 4,08 1557-1558 1,06 1,1 2,7 13,46 1,03 1,13 1672-1673 5,74 9,67 42,67 32,18 1,10 17,68 2195-2196 16,54 31,7 59,5 22,72 1,09 128,47 3504-3505 2,09 1,72 16,51 16,85 1,00 2,52

mínimo 1,06 1,1 2,7 13,46 1,00 1,13 média 8,72 21,44 65,27 22,53 1,11 4886,76 desvio padrão

10,25 37,85 99,35 7,64 0,10 12241,81


FCP vs SLB (1/1)


DCT 3 coef.

skal DCT

1428-1429 12,87 16,81 75,51 25,76 1,21 881,22 1500-1501 2,68 2,96 12,85 14,89 0,99 4,25 1575-1576 7,4 12,5 8,02 14,27 1,11 24,32 1922-1923 7,02 13,25 57,24 22,95 1,12 101


4,18 5,92 33,21 5,76 0,09 421,08


FCP vs SLB (1/2)


DCT 3 coef.

skal DCT

1366-1367 3,95 4,18 41,75 20,69 1,07 14,21 3065-3065 4,39 5,95 47,92 14,91 1,08 43,47


0,31 1,25 4,36 4,09 0,01 20,69

De seguida foram analisados lances de outros jogos para fazer comparações entre os resultados obtidos. Para isso, escolheram-se dois jogos com realizações diferentes e transmitidos por diferentes canais. Os jogos escolhidos foram a Final da Liga dos Campeões de 2004 e um jogo do Euro 2004 (Dinamarca vs Itália).



No jogo da Liga dos Campeões a análise foi feita na jogada do primeiro golo do Porto marcado por Carlos Alberto. Os resultados são apresentados nas Tabelas 10 e 11.

Tabela 10 - Parâmetros característicos de análise de cortes de cena pelos vários métodos (FCP vs MON – 1/0)

FCP vs MON - (1/0)


DCT 3 coef.

skal DCT

722-723 8436621 34,92 1442 400882 5786 1575 819-820 7477154 25,06 1200 335666 5355 1021

1167-1168 11229194 51,77 1457 538454 6246 3245 2848-2849 8836635 33,79 1253 252222 5839 1982

mínimo 7477154 25,06 1200 252222 5355 1021 média 8994901 36,39 1338 381806 5807 1955,75 desvio padrão

1595028 11,16 131 120863 364 945

Tabela 11 - Factores multiplicativos para os vários métodos utilizando o algoritmo móvel (FCP vs MON – 1/0)

FCP vs MON - (1/0)


DCT 3 coef.

skal DCT

722-723 4,28 6,57 147,24 38,02 1,13 41,49 819-820 2,51 3 16,67 11,64 1,07 6,25

1167-1168 4,51 8,42 8,24 18,58 1,08 11,96 2848-2849 2,21 3,43 10,05 11,2 1,05 4,42

mínimo 2,21 3 8,24 11,2 1,05 4,42 média 3,38 5,36 45,55 19,86 1,08 16,03 desvio padrão

1,19 2,59 67,89 12,57 0,03 17,27

No jogo do Euro 2004 a análise é feita a uma sequência de jogadas em que os guarda-redes das duas equipas “brilharam”. Os resultados são apresentados nas Tabelas 12 e 13.



Tabela 12 - Parâmetros característicos de análise de cortes de cena pelos vários métodos (ITA vs DEN)

ITA vs DEN - (0/0)


DCT 3 coef.

skal DCT

256-257 11011108 33,51 1106 163640 5362 2002 318-319 10023928 28,64 1405 336228 5517 1656 560-561 14772594 50,89 1500 558750 6011 2968 592-593 15379047 50,84 1467 527562 6117 3125 884-885 9484927 32,39 1251 383284 5564 1520 997-998 16136214 48,52 1392 318512 5966 2869

1023-1024 18463520 48,56 1397 304384 6094 3089 1055-1056 14375177 44,75 1318 255716 5682 2837 1117-1118 14682638 51,06 1398 220102 5910 3037 1169-1170 15050497 53,79 1462 381108 6089 3347 1205-1206 14435510 47,74 1496 303006 6091 3284 1301-1302 22306957 56,64 1549 446280 6187 3847 1375-1376 9593992 32,55 1228 276520 5355 1987 1543-1544 16836896 62,95 1479 465444 6318 4216 1594-1595 14810801 46,97 1141 362988 5964 3034 2270-2271 11941666 40,37 1425 337524 5819 2160 2298-2299 11729986 39,45 1434 483624 5956 2381 2499-2500 13381312 44,22 1453 410082 5831 2801 2689-2690 16356061 47,4 1312 355132 5958 3075 3393-3394 10123198 39,65 1517 549992 5817 2134 4163-4164 11683707 46,44 1495 496084 5918 2808


3215273 8,60 123 109074 260 682



Tabela 13 - Factores multiplicativos para os vários métodos utilizando o algoritmo móvel (ITA vs DEN) ITA vs DEN -

(0/0) Tot. Pixel

Dif. Pixel Dif. Block Dif. HistogramDCT 3 coef.

skal DCT

256-257 2,85 2,82 23,23 9,84 1,06 7,33 318-319 3,1 2,75 11,49 12,75 1,02 4,12 560-561 6,16 8,02 19,71 34,42 1,19 13,49 592-593 6,97 9,4 102,7 29,24 1,05 45,99 884-885 1,59 1,61 3,42 10,98 1,02 1,71 997-998 11,53 15,78 110,05 11,69 1,14 841,28

1023-1024 3,21 2,6 1,5 2,73 0,94 2,93 1055-1056 1,9 1,61 1,71 5,38 1,04 1,87 1117-1118 2,33 2,39 2,8 8,52 1,07 2,98 1169-1170 11,18 23,25 30,08 16,08 1,04 47,39 1205-1206 5,03 7,24 8,85 12,88 1,07 11,81 1301-1302 5,46 4,59 4,6 10,11 1,01 6,41 1375-1376 28,97 119,19 82,59 24,96 1,09 50662,92 1543-1544 21,92 45,3 52,76 27,79 1,29 608,14 1594-1595 6,22 6,89 131,2 29,87 1,00 25,74 2270-2271 9,33 18,35 116,98 19,06 1,10 998,48 2298-2299 4,88 7,56 9,56 20,48 1,11 9,83 2499-2500 2,28 2,6 2,81 12,17 0,99 2,74 2689-2690 1,47 1,52 1,5 4,45 0,96 1,55 3393-3394 5,54 12,42 5,92 19,52 1,10 17,27 4163-4164 25,02 62,05 163,75 41,32 1,23 1126,03


7,89 27,98 52,31 10,49 0,09 11020,32

Como se observa nas quatro tabelas anteriores os valores obtidos dos parâmetros correspondentes aos vários métodos são de um modo geral da mesma ordem de grandeza dos associados às situações consideradas do jogo da Taça de Portugal. Sendo assim, pode-se já escolher qual o valor limite a usar para a detecção dos cortes de cena em cada um dos métodos, através do valor mínimo obtido para cada um deles nos testes realizados.

Nas Tabelas 14 e 15 apresentam-se os mínimos obtidos nos testes realizados para cada um dos métodos e também os limites que vão ser utilizados para a análise de cortes de cena, quando se utiliza o algoritmo invariável ou móvel, respectivamente. Na selecção dos valores limite decidiu-se atribuir valores ligeiramente inferiores aos mínimos determinados como factor de segurança.



Tabela 14 – Valores limites seleccionados (algoritmo invariável)

Resultados gerais



Mínimo 7477154 25,06 948 163640 5355 1021 Limite a usar

7477150 25,00 945 163625 5350 1020

Tabela 15 – Valores limites seleccionados (algoritmo móvel)

Resultados gerais



Mínimo 1,06 1,10 1,50 2,73 0,90 1,13 Limite a usar

1,00 1,05 1,25 2,70 0,85 1,10



8 APRESENTAÇÃO E DISCUSSÃO DE RESULTADOS

Depois de se terem determinado os valores limite a utilizar para cada um dos métodos, aplicaram-se esses valores ao programa desenvolvido e correu-se o programa de modo a analisar as sequências referidas no capítulo anterior.

Inicialmente, considerou-se a análise do golo do Derlei no jogo da Final da Taça de Portugal de 2004. Utilizou-se este lance para fazer uma análise pormenorizada de cada um dos métodos. Para os outros, irão apenas ser apresentados os resultados e verificar-se-á se eles conduzem às mesmas conclusões.

Logo no início da análise do golo de Derlei notou-se que o primeiro corte de cena detectado era um erro. Este erro resulta do facto da primeira imagem não corresponder a uma imagem I. Por isso, em alguns pixels é impossível fazer a correlação com imagens anteriores, uma vez que aquela é a primeira imagem da jogada que estamos a analisar. Em resultado, não aparece nenhuma informação (pixels apresentados a verde na Figura 40).

Figura 40 – Corte de cena detectado incorrectamente associado às primeiras imagens da sequência

Assim, para além dos dois casos já mencionados no capítulo anterior, também esta situação ou equivalentes não vão ser consideradas como um erro. Se forem detectados os correspondentes cortes de cena, eles serão ignorados.

Como já era esperado, esta análise mostra também as duas situações focadas no capítulo anterior. A Figura 41 é um exemplo do efeito da transmissão de TV ser feita por campos. A Figura 42 demonstra que também as cortinas podem ser detectadas em algumas situações, mesmo



fazendo a comparação imagem a imagem. O tipo de cortinas depende da realização do jogo; neste caso a realização da TVI utiliza um tipo de cortina que, embora tenha características semelhantes, é diferente do utilizado pela realização do Euro 2004.

Figura 41 – Corte de cena detectado associado à transmissão televisiva por campos

Figura 42 – Corte de cena detectado associado à existência de cortinas

Vai-se agora descrever e analisar os resultados obtidos pelos vários métodos de detecção de cortes de cena, referidos anteriormente.



8.1. Variação de intensidade de pixels (diferença total)

Este foi o primeiro método a ser testado. Como já se referiu no Capítulo 4, trata-se do método de detecção de cortes de cena menos complexo.

Feita a análise, o resultado mais relevante é que foram detectados 953 (!) cortes de cena. Sabendo que a totalidade da jogada analisada corresponde a 4092 imagens, o resultado é estranho. No capítulo anterior, quando se falou deste lance, disse-se que existiam apenas nove cortes de cena correctos; se a estes se adicionarem os cortes de cena detectados para os casos já previamente mencionados (cortinas, campos e inexistência de imagem I anterior) teremos, no máximo, cerca de 30 a 40 cortes de cena. Logo, podemos concluir que este método origina bastantes erros de detecção.

Analisando os cortes de cena detectados, verifica-se que quando é detectado um corte de cena incorrectamente ocorre uma sucessão de cortes de cena errados. Na Figura 43 ilustra-se bem esse fenómeno.

Figura 43 – Cortes de cena detectados incorrectamente em sequência Como ocorrem sequências de erros, com um algoritmo mais robusto esta análise tornava-se mais correcta. Bastaria que o algoritmo tivesse uma condição do tipo: se nas imagens anteriores mais próximas existem cortes de cena, então é porque as duas últimas imagens não correspondem a um corte de cena.



Na Tabela 16 apresentam-se todos os cortes de cena detectados, bem como os respectivos motivos, se existirem. Na última coluna mostra-se o número de cortes de cena nos intervalos de imagem indicados. Como já foi indicado anteriormente, a quantidade de erros é enorme.

Tabela 16 – Cortes de cena detectados pelo método de variação de intensidade de pixels (diferença total)

Cortes de cena

detectados Motivo Erro Número

0-1 e 1-2 Inexistência de

imagem I 72-73 e 73-74 Campo par e ímpar

80-81 a 134-135 27 135-136 Corte de cena 312-313 Corte de cena

329-330 a 343-344 15 344-345 Corte de cena 717-718 Corte de cena 839-840 Campo par e ímpar

1254-1255 Corte de cena 1264-1265 a 1381-1382 108

1382-1383 Corte de cena 1514-1515 Corte de cena


1674-1675 a 1831-1832 157 1832-1833-1834 Cortina 2

2034-2035 a 2123-2124 90 2124-2125-2126 Cortina 2

2195-2196 Corte de cena 2321-2322 a 2429-2430 83 2430(31)(32)(33)(34)(35) Cortina 5 2921-2922 a 2992-2993 60

2994-2995 Cortina 3025-3026 a 3141-3142 26

3319-3320 Cortina 3348-3349 a 3503-3504 109

3504-3505 Corte de cena 3701-3702 a 3916-3917 208 Na Tabela 17 apresentam-se os valores do tempo de análise, do tempo por 25 imagens (corresponde ao tempo necessário para analisar um segundo de filme) e também as percentagens de erro obtidas considerando que cada corte mal detectado corresponde a um erro ou, em alternativa, considerando que uma sequência de erros pode ser considerada apenas um erro. Note-se que, mesmo agrupando as sequências de erros, a percentagem de erros é elevada (cerca de 30%).



Tabela 17 – Resumo dos resultados da análise pelo método de variação de intensidade de pixels (diferença total)

Tempo Total (s) 364

Tempo / 25 imagens 2,22 Cortes de cena detectados 953 Próximo de corte de cena 111

Percentagem de erro total (%) 97,2 Perc. erro com sequência (%) 28,9

Na Tabela 18 apresentam-se os resultados obtidos aplicando o algoritmo móvel ao mesmo lance.

Tabela 18 - Resumo dos resultados da análise pelo método de variação de intensidade de pixels (diferença total) utilizando o algoritmo móvel

Tempo Total (s) 370


Neste caso não se apresentaram os resultados das percentagens de erro uma vez que eram muito próximos dos 100%. Conclui-se que a aplicação do algoritmo móvel neste método não tem nenhuma vantagem em relação ao algoritmo invariável, uma vez que o número de cortes de cena detectados incorrectamente foi ainda maior. Além disso, os cortes de cena detectados com erro por este processo não estão, como no anterior, em sequência, mas são espaçados entre si. Por isso, a utilização do procedimento mais robusto, proposto para utilizar no algoritmo invariável, é aqui inútil.

Antes de passarmos ao próximo método, é importante referir que, com o algoritmo móvel, o primeiro corte de cena resultante da falta de informação em alguns pixels não é detectado, ao contrário do que acontecia no caso anterior.

8.2. Variação de intensidade de pixels (em percentagem)

Na Tabela 19 apresenta-se um quadro com os cortes de cena detectados por este método e o motivo pelo qual foram detectados.



Tabela 19 - Cortes de cena detectados pelo método de variação de intensidade de pixels (em precentagem)

Cortes de cena

detectados Motivo Erro Número




331-332 a 343-344 13 344-345 Corte de cena 717-718 Corte de cena 839-840 Campo par e ímpar

1254-1255 Corte de cena 1267-1268 a 1381-1382 105

1382-1383 Corte de cena 1514-1515 Corte de cena


1674-1675 a 1831-1832 158 1832-1833-1834-1835 Cortina 3

2034-2035 a 2123-2124 90 2124-2125-2126-2127 Cortina 3

2195-2196 Corte de cena 2320-2321 a 2429-2430 83

2430(31)(32)(33)(34) Cortina 4 2919-2920 a 2991-2992 65

2992(93)(94)(95)(96) Cortina 4 3069-3070 a 3141-3142 13 3348-3349 a 3503-3504 104

3504-3505 Corte de cena 3697-3698 a 3915-3916 219

3916(17)(18) Cortina 2 Este método não apresenta diferenças significativas em relação ao anterior, o que não é de estranhar uma vez que se baseiam em princípios semelhantes. Mesmo assim, pode-se verificar (Tabela 20) que o número de cortes de cena detectados é ligeiramente inferior, o que se traduz em percentagens de erro inferiores. Além disso, o tempo de análise é exactamente o mesmo.



Tabela 20 – Resumo dos resultados da análise pelo método de variação de intensidade de pixels (em percentagem)

Tempo Total (s) 384


Percentagem de erro total (%) 96,6 Perc. erro com sequência (%) 25,6

Na análise com o algoritmo móvel, como se pode ver na Tabela 21, o número de cortes de cena detectados foi ligeiramente inferior ao obtido com o algoritmo invariável, mas continua a ser demasiado elevado. Tal como no método anterior, o problema é que os cortes de cena que são detectados incorrectamente não estão em sequência. Por isso, embora a percentagem de erro total seja nesta situação inferior, a utilização do algoritmo invariável permite elaborar um processo mais robusto que faz com que a percentagem de erros seja reduzida, enquanto que com o algoritmo móvel a construção de um algoritmo mais robusto é mais complicada. Estas observações já foram feitas para o método anterior.

Tabela 21- Resumo dos resultados da análise pelo método de variação de intensidade de pixels (em percentagem) utilizando o algoritmo móvel

Tempo Total (s) 376


Para mostrar que os erros detectados no algoritmo móvel estão mais dispersos pode-se observar a Tabela 22. Por exemplo, no espaço entre a imagem 88 e a imagem 123 são detectados apenas seis cortes de cena, enquanto que utilizando o algoritmo invariável, praticamente para o mesmo conjunto de imagens, foram detectados vinte e um cortes de cena.



Tabela 22 - Cortes de cena detectados pelo método de variação de intensidade de pixels (em precentagem) utilizando o algoritmo móvel

Cortes de cena

detectados Motivo Erro Número 12-13, 13-14 e 14-15 3

72-73 e 73-74 Campo par e ímpar 88-89 a 122-123 6

135-136 Corte de cena 185-186 a 306-307 27

312-313 Corte de cena 319-320 a 339-340 13

344-345 Corte de cena 364-365 a 704-705 37

717-718 Corte de cena 725-726 a 838-839 42 839-840 e 840-841 Campo par e ímpar 850-851 a 960-961 28

971(72)(73)(74)(75)(76) Cortina 5

8.3. Razão de probabilidades

Os resultados obtidos pelos dois métodos anteriores são maus; o melhor que se conseguiu foi uma percentagem de erro de 25%. Ver-se-á que com o método da razão de probabilidades se podem obter resultados bastante satisfatórios. A Tabela 23 ilustra esta afirmação.

Tabela 23 - Resumo dos resultados da análise pelo método da razão das probabilidades

Tempo Total (s) 475 Tempo / 25 imagens 2,9

Cortes de cena detectados 13 Próximo de corte de cena 2

Perc. erro (%) 7,7 Com este método foi possível detectar os cortes de cena que deveriam ser detectados, com a excepção de um deles, como se mostra na Tabela 24.



Tabela 24 - Cortes de cena detectados pelo método da razão de probabilidades

Cortes de cena detectados Motivo Erro

72-73 e 73-74 Campo par e ímpar 135-136 Corte de cena 312-313 Corte de cena 337-338 344-345 Corte de cena 717-718 Corte de cena

1254-1255 Corte de cena 1382-1383 Corte de cena 1514-1515 Corte de cena 1558-1559 Corte de cena 1673-1674 Corte de cena 2195-2196 Corte de cena 3504-3505 Corte de cena

Tal como nos anteriores, também neste método a introdução do algoritmo móvel não faz com que ocorram muitas melhorias na detecção dos cortes de cena. Antes pelo contrário, neste caso até piora, uma vez que o número de cortes de cena detectados é largamente superior ao obtido pelo algoritmo invariável.

Tabela 25 - Resumo dos resultados da análise pelo método da razão das probabilidades utilizando o algoritmo móvel

Tempo Total (s) 461


8.4. Comparação de histogramas

O método de comparação de histogramas também apresenta resultados muito satisfatórios. Neste caso, como se pode observar na Tabela 26, não foi detectado incorrectamente nenhum corte de cena.



Tabela 26 - Cortes de cena detectados pelo método da comparação de histogramas

Cortes de cena detectados Motivo Erro



135-136 Corte de cena 312-313 Corte de cena 344-345 Corte de cena 717-718 Corte de cena

839-840 e 840-841 Campo par e ímpar 1254-1255 Corte de cena 1382-1383 Corte de cena 1514-1515 Corte de cena 1558-1559 Corte de cena 1673-1674 Corte de cena 2195-2196 Corte de cena 3504-3505 Corte de cena 3919-3920 Cortina

Os resultados mais relevantes deste método são apresentados na Tabela 27. Note-se que o tempo de análise é menor que nos casos anteriores.

Tabela 27 - Resumo dos resultados da análise pelo método da comparação de histogramas



Perc. erro (%) 0 Quando se utiliza o algoritmo móvel os resultados são, tal como nos outros métodos até agora considerados, piores do que quando se aplica o algoritmo invariável. No entanto, para este caso, o número total de erros detectado é menor em comparação com a utilização do algoritmo móvel nos outros métodos. Mesmo assim a correspondente percentagem é elevada.

Tabela 28 - Resumo dos resultados da análise pelo método da comparação de histogramas utilizando o algoritmo móvel

Tempo Total (s) 344


Perc. erro (%) 59,4



8.5. DCT (método com três coeficientes)

O método DCT com três coeficientes é o que origina os piores resultados entre os testados. Na publicação em que me baseei para o descrever [10] referia-se que ele era bastante satisfatório e constituía uma óptima alternativa à aplicação das fórmulas da DCT completa, uma vez que era muito mais rápido. No entanto, o que se pode observar é que nas 4092 imagens correspondentes ao lance em análise, este método detectou quase 2200 cortes de cena e cerca de 1400 comparações muito próximas de ser escolhidas como cortes de cena. Pode-se concluir que utilizar apenas três coeficientes para descrever uma matriz que contém sessenta e quatro não constitui uma boa solução, porque os resultados práticos não são satisfatórios apesar dos tempos de análise serem muito menores do que na DCT completa.

Os resultados obtidos por este método são apresentados de seguida. Como é evidente, a percentagem de erro não se encontra apresentada na Tabela 29 uma vez que o seu valor é muito próximo dos 100%.

Tabela 29 - Resumo dos resultados da análise pelo método DCT de três coeficientes



Usando o algoritmo invariável chegaram-se portanto a resultados muito maus. Da experiência adquirida na análise dos métodos anteriores, sabemos que o algoritmo móvel se comporta ainda pior, como tem sido referido ao longo deste capítulo. Por isso, o mesmo deve acontecer para este método (Tabela 30). Efectivamente, verifica-se que praticamente todas as comparações feitas conduziram à detecção de cortes de cena.

Tabela 30 - Resumo dos resultados da análise pelo método DCT de três coeficientes utilizando o algoritmo móvel





8.6. DCT (método de Skal)

O método de Skal é um método de aplicação rápida DCT mais robusto que o anterior. Contudo, os resultados obtidos foram do mesmo tipo dos correspondentes aos primeiros dois métodos experimentados. Isto quer dizer que, além de terem sido detectados os cortes de cena correctos, também foram detectados muitos outros, eventualmente agrupados em conjuntos de cortes de cena detectados incorrectamente. Na Tabela 31 apresentam-se os resultados obtidos para esta situação.

Tabela 31 - Cortes de cena detectados pelo método DCT de Skal

Cortes de cena detectados Motivo Erro Número





839-840 e 841-842 Campo par e ímpar 1254-1255 Corte de cena


1515-1516 a 1557-1558 43 1558-1559 Corte de cena 1673-1674 Corte de cena 1839-1840 1

2037-2038 a 2381-2382 140 2430(31)(32)(33)(34)(35) Cortina 5 2929-2930 a 2992-2993 56

2994-2995-2996 Cortina 2 3015-3016 a 3142-3143 50

3318(19)(20)(21)(22) Cortina 4 3347-3348 a 3503-3504 117

3504-3505 Corte de cena A síntese dos resultados mais importantes é apresentada na Tabela 32.



Tabela 32 - Resumo dos resultados da análise pelo método DCT de Skal



Percentagem de erro total (%) 95,5 Perc. erro com sequência (%) 25

Os resultados são ligeiramente melhores que nos métodos das diferenças de pixels, mas obtidos ao fim de um tempo superior.

8.7. Outras sequências analisadas

Depois desta primeira análise, que já permitiu tirar algumas conclusões, é necessário testar os mesmos métodos noutros lances e analisar os respectivos resultados para validação das conclusões anteriores. Para isso, analisaram-se também as outras jogadas mencionadas no capítulo anterior. Não se vão descrever aqui todos os resultados das análises, como foi feito nas secções anteriores, mas apenas apresentar, para cada método, comparações entre os resultados obtidos nas várias jogadas.

Nos casos em que é aplicado o algoritmo móvel, não vai ser referida a percentagem de erro uma vez que é sempre muito próxima dos 100% devido à detecção de inúmeros cortes de cena, como já foi referido nas secções anteriores.

De seguida são apresentados os resultados obtidos. Em cada uma das tabelas são apresentados os valores obtidos por cada um dos métodos nas várias sequências de imagens, identificadas da mesma forma que anteriormente neste relatório. Para cada um dos métodos existem duas tabelas, uma referente à utilização do algoritmo invariável e outra ao algoritmo móvel.

Note-se que os números totais de imagens para os lances analisados são:

• FCP vs SLB (1/1) – 3940

• FCP vs SLB (1/2) – 4249

• FCP vs MON (1/0) – 3427

• ITA vs DEN (0/0) – 4474



Tabela 33 - Resultados da análise pelo método da diferença de pixels (diferença total)

Total Pixel Diference FCP vs SLB

(1/1) FCP vs SLB

(1/2) FCP vs MON

(1/0) ITA vs DEN

(0/0) Tempo Total 348 432 333 363

Tempo / 25 Imagens 2,21 2,54 2,43 2,03 Detectados 418 285 48 211

Próximos de cortes 158 105 78 145 Percentagem de Erro(%) 97,1 94,7 62,7 89,6

Perc. erro com seq. 47,8 28,6 13,6 31,3

Tabela 34 - Resultados da análise pelo método da diferença de pixels (diferença total) utilizando o algoritmo móvel

Total Pixel Diference FCP vs SLB

(1/1) FCP vs SLB

(1/2) FCP vs MON

(1/0) ITA vs DEN

(0/0) Tempo Total 355 420 314 517


Próximos de cortes 1919 2060 1353 1978

Tabela 35 - Resultados da análise pelo método da diferença de pixels (em percentagem)

Pixel Diference FCP vs SLB

(1/1) FCP vs SLB

(1/2) FCP vs MON

(1/0) ITA vs DEN

(0/0) Tempo Total 451 420 306 415



Perc. erro com seq. 46,1 34,8 11,1 26,5

Tabela 36 - Resultados da análise pelo método da diferença de pixels (em percentagem) utilizando o algoritmo móvel

Pixel Diference FCP vs SLB

(1/1) FCP vs SLB

(1/2) FCP vs MON

(1/0) ITA vs DEN

(0/0) Tempo Total 432 418 359 506





Tabela 37 - Resultados da análise pelo método da razão de probabilidades

Block Diference FCP vs SLB

(1/1) FCP vs SLB

(1/2) FCP vs MON

(1/0) ITA vs DEN

(0/0) Tempo Total 405 449 376 478


Próximos de cortes 4 4 6 39 Percentagem de Erro(%) 0 0 0 30,5

Perc. erro com seq. - - - 10,7

Tabela 38 - Resultados da análise pelo método da razão de probabilidades utilizando o algoritmo móvel

Block Diference FCP vs SLB

(1/1) FCP vs SLB

(1/2) FCP vs MON

(1/0) ITA vs DEN

(0/0) Tempo Total 383 454 389 410



Tabela 39 - Resultados da análise pelo método da comparação de histogramas

Histogram FCP vs SLB

(1/1) FCP vs SLB

(1/2) FCP vs MON

(1/0) ITA vs DEN

(0/0) Tempo Total 263 315 248 337


Próximos de cortes 2 3 1 4 Percentagem de Erro(%) 0 0 0 2,3

Perc. erro com seq. - - - -

Tabela 40 - Resultados da análise pelo método da comparação de histogramas utilizando o algoritmo móvel

Histogram FCP vs SLB

(1/1) FCP vs SLB

(1/2) FCP vs MON

(1/0) ITA vs DEN

(0/0) Tempo Total 283 318 253 333





Tabela 41 - Resultados da análise pelo método DCT com três coeficientes

DCT 3 coefs. FCP vs SLB

(1/1) FCP vs SLB

(1/2) FCP vs MON

(1/0) ITA vs DEN

(0/0) Tempo Total 323 447 293 372


Próximos de cortes 1784 1564 1949 2202 Percentagem de Erro(%) - - - -

Perc. erro com seq. - - - -

Tabela 42 - Resultados da análise pelo método DCT com três coeficientes utilizando o algoritmo móvel

DCT 3 coefs. FCP vs SLB

(1/1) FCP vs SLB

(1/2) FCP vs MON

(1/0) ITA vs DEN

(0/0) Tempo Total 388 367 300 455



Tabela 43 - Resultados da análise pelo método DCT de Skal

skal DCT FCP vs SLB

(1/1) FCP vs SLB

(1/2) FCP vs MON

(1/0) ITA vs DEN

(0/0) Tempo Total 749 722 663 744



Perc. erro com seq. 39,1 31,8 6,5 27,7

Tabela 44 - Resultados da análise pelo método DCT de Skal utilizando o algoritmo móvel

skal DCT FCP vs SLB

(1/1) FCP vs SLB

(1/2) FCP vs MON

(1/0) ITA vs DEN

(0/0) Tempo Total 698 804 584 845


Próximos de cortes 669 657 425 734 As conclusões retiradas da análise do primeiro lance analisado (golo de Derlei) repetem-se para as restantes jogadas, isto é, o método dos histogramas e o da razão de probabilidades com o algoritmo invariável são os mais eficientes. Os valores obtidos para os cortes de cena detectados por estes dois métodos são ligeiramente diferentes, mas no entanto na maioria das situações a percentagem de erro é de 0%, desde que não se considerem as cortinas, a transmissão por campos e a ausência de imagem I anterior como erros, como já foi referido antes.



9 CONCLUSÕES E SUGESTÕES DE TRABALHO FUTURO

O principal objectivo deste trabalho foi fazer a avaliação de diferentes métodos de detecção de cortes de cena em jogos de futebol. Pretendia-se um método rápido e eficaz, isto é, que detectasse o mais rapidamente possível todos os cortes de cena existentes com um mínimo de erros. Após o desenvolvimento de uma aplicação para esse fim e da análise dos vários métodos considerados, é possível concluir que existem dois métodos que conduzem a resultados muito satisfatórios: razão de probabilidades e comparação de histogramas, ambos utilizando o algoritmo de detecção invariável.

A utilização do algoritmo móvel de detecção não é uma boa solução em nenhum dos métodos, uma vez que os resultados obtidos conduzem a percentagens de erro próximas dos 100%. Além disso, também se verificou que a utilização de um modo mais sofisticado, que agrupasse uma sequência de erros num só erro, não era possível uma vez que as detecções feitas incorrectamente se encontravam dispersas. No entanto, a utilização deste modo mais complexo para a detecção de cortes de cena com o algoritmo invariável, permite que haja uma redução significativa na percentagem de erros detectados nos dois métodos das diferenças de pixels e no método de Skal. Mesmo assim, a percentagem de erros detectados continua a ser bastante elevada.

Os resultados obtidos pelo método de DCT com apenas três coeficientes são péssimos, o que faz com que se questione a veracidade da conclusão da publicação onde se encontra referido o método, onde se afirma que é uma boa aproximação ao DCT completo. O método de Skal apresenta resultados um pouco melhores que os dois métodos baseados na diferença de pixels, mas não são igualmente satisfatórios e trata-se de um método mais lento. Apesar de muito semelhantes, o método Pixel Dif. apresenta ligeiras melhorias em relação ao método Total Pixel Dif., visto que além de ser ligeiramente mais rápido também origina percentagens de erros ligeiramente inferiores.

Em relação aos métodos de comparação de histogramas e de razão de probabilidades podemos concluir que não ocorrem quase erros nenhuns. Por isso, é de concluir que estes dois métodos são os mais indicados para a detecção de cortes de cena em jogos de futebol. Comparando um método com o outro verifica-se que o da comparação de histogramas apresenta um menor número de valores próximos de corte de cena, o que é uma indicação de que com este método há uma maior diferenciação entre imagens sucessivas que são cortes de cena e as que não são. Também se pode observar que o referido método demora menos tempo a efectuar a análise. Por isso, para uma aplicação em que seja necessário fazer a detecção de cortes de cena em jogos de futebol pode-se dizer que a utilização do método da comparação de histogramas é o melhor.



A detecção de cortes de cena em jogos de futebol poderá servir para a criação de resumos de jogos de futebol como um processo semi-automático. Este processo consistirá de duas partes: em primeiro lugar o vídeo é analisado na sua totalidade e todos os cortes de cena são detectados, de forma automática; seguidamente essas cenas são agrupadas manualmente para criar segmentos de vídeo correspondentes a jogadas.

O funcionamento tipo da ferramenta de segmentação é representado esquematicamente na Figura 44.

Figura 44 – Funcionamento da ferramenta de segmentação vídeo

De modo a perceber melhor o que foi atrás referido apresenta-se de seguida (Figura 45) uma interface homem/máquina possível para este tipo de ferramenta.

Figura 45 – Interface da ferramenta de segmentação vídeo



Tal como se pode observar, na parte superior do ecrã ficariam disponíveis as cenas detectadas automaticamente no vídeo. O segmento correspondente a uma jogada será criado arrastando cenas para a área imediatamente abaixo como é possível ver na Figura 45. Em qualquer instante será possível fazer um Preview do segmento realizado e quando o operador estiver satisfeito com o agrupamento das cenas pode criar uma jogada/segmento, que irá ficar disponível na área vertical do lado direito.

Após esta breve descrição geral de uma possível utilização dos cortes de cena, pode-se também falar mais detalhadamente de alguns melhoramentos que podem vir a ser efectuados de modo a tornar o seu algoritmo de detecção mais robusto e eficaz.

A primeira alteração que se pode fazer centra-se no modo como se tentam detectar os cortes. Neste trabalho a detecção foi feita por análise imagem a imagem. Verificou-se que isto tinha alguns problemas, já que havia situações em que eram detectadas e noutras que não. Isto pode ser tudo resolvido, como já se disse anteriormente, se se realizar a análise de um em um segundo, isto quer dizer de 25 em 25 imagens. Deste modo, para além do processo se tornar mais rápido, uma vez que não se analisam todas as imagens, também é possível detectar todas as situações focadas anteriormente sem nenhum problema.

Outro dos melhoramentos possíveis prende-se com a utilização das cortinas. Em quase todas as situações as cortinas são utilizadas para separar repetições de lances interessantes dos lances do jogo que continua a decorrer. Como o objectivo da segmentação de vídeo é a construção de jogadas, teria interesse que as repetições fossem detectadas e eliminadas automaticamente no processo de detecção de cortes de cena. Para este efeito podem ser utilizadas duas soluções. Uma delas tem a ver com distâncias; por exemplo, se ocorrerem dois cortes de cena muito próximos um do outro é porque a duração da sequência em causa é pequena e, por isso, muito provavelmente representa uma repetição. Outra maneira também possível de eliminar cortinas tem relação com o próprio processo de detecção de cortes de cena. Como estaríamos a fazer a análise de 25 em 25 imagens, quando um corte de cena fosse detectado passava-se a fazer a análise imagem a imagem dentro do intervalo das 25 imagens, e se fossem detectados dois ou mais cortes de cena dentro desse intervalo era porque havia uma cortina. Se a detecção da cortina correspondesse a um número ímpar o corte detectado teria que representar o início de uma repetição, se correspondesse a um número par representava o fim da repetição.

Para ambas as soluções apresentadas será necessário fazer um estudo mais pormenorizado de modo a tirar conclusões relativamente à sua aplicabilidade em termos práticos.



Anexo

No Capítulo 5 fez-se referência ao modo como o programa poderia ser desenvolvido e implementado.

Neste anexo vão-se apresentar as funções principais que o programa realiza, correspondentes aos fluxogramas anteriormente apresentados (Capítulo 5).

De seguida, é apresentado o código da função open com os respectivos comentários, seguindo à risca a informação apresentada no fluxograma relativo a esta função.

void MyFrame::OnOpen(wxCommandEvent & evt) { //Mensagem que aparece na janela onde se escolhe o ficheiro

wxFileDialog firstfile( this, _T("Choose the starting file for the analysis"), _T("C:\\temp"), _T(""), _T("pgm files (*.pgm)|*.pgm"));

//O programa não se encontra a proceder a nenhuma análise if(playPRESSED == FALSE){

//Escolheu uma imagem do tipo pgm if (firstfile.ShowModal() == wxID_OK) { bool auxiliar = FALSE; struct _stat buf; int pathlenght, dirlenght, indice = 0, numimg; wxString aux, file; imagens = 0; aux = ""; aux << imagens;

//Inicializar a label das imagens a 0 ImageText.SetLabel(aux); //Gravar o caminho do ficheiro escolhido

file = firstfile.GetPath().c_str(); //Se o debug estiver activado imprime valor guardado em file if(debug != 0){ wxString MSG = "You choose the file: \n"; MSG << file.GetData();

wxMessageDialog openDialog( this, MSG, "Cut Scene Detector Project", wxOK | wxICON_INFORMATION);

openDialog.ShowModal(); }

int estado = _stat( file.GetData(), &buf); //Verificar se a imagem existe mesmo //Se não existir imprime informação if(estado != 0){

wxMessageDialog error(this, _T("There isn´t such image!!!"), "Error Message Box", wxOK | wxICON_ERROR | wxSTAY_ON_TOP);

error.ShowModal(); return;



} //Gravar o caminho do directório escolhido dir = firstfile.GetDirectory().c_str(); //Se o debug estiver activado imprime valor guardado em dir if(debug != 0){ wxString MSG = "Dir: "; MSG << dir;


openDialog.ShowModal(); } //Calcular os tamanhos das variáveis dir e file dirlenght = dir.Length(); pathlenght = file.Length();

//Se o debug estiver activado imprime valor guardado em dirlenght e //path lenght

if(debug != 0){ wxString MSG = "Dir lenght: "; MSG << dirlenght; MSG << "\nPath lenght: "; MSG << pathlenght;


openDialog.ShowModal(); } //Verificar quantos algarismos tem o ficheiro escolhido, ex. 235.pgm for(int i = dirlenght; i < pathlenght; i++){ if(file.GetChar(i) >= '0' && file.GetChar(i) <= '9') indice++; } //Se o debug estiver activado imprime valor guardado no índice if(debug != 0){ wxString MSG = "indice: "; MSG << indice;


openDialog.ShowModal(); }

//Remover a extensão pgm e transformar o ficheiro escolhido na //primeira imagem que vai ser analisada

aux = file.Right(indice + SIZEEXT); aux = aux.Remove(indice); numimg = atoi(aux.GetData()); firstimage = numimg; //Se o debug estiver activado imprime valor guardado em firstimage if(debug != 0){ wxString MSG = "aux: "; MSG << aux; MSG << "\nfirst image: "; MSG << numimg;

wxMessageDialog openDialog( this, MSG, "CutScene Detector Project", wxOK | wxICON_INFORMATION);

openDialog.ShowModal(); } //Enquanto existirem imagens para analisar



while(!auxiliar){ estado = _stat( file.GetData(), &buf); //Ver imagem seguinte if(estado == 0){ imagens++; numimg++; aux = "\\"; aux << numimg; aux.Append(".pgm"); file = dir; file += aux; } else{ auxiliar = TRUE; } } //Imprime valor de imagens que vão ser analisadas aux = ""; aux << imagens; ImageText.SetLabel(aux); } //Possibilidade de observar as imagens que vão ser analisadas if(imagens) prevpic.Enable(TRUE);

//Possibilidade de analisar as imagens escolhidas if(!method.IsEmpty() && imagens){ playpic.Enable(TRUE); } }

//O programa encontra-se a proceder a uma análise else{

wxMessageDialog Choice1Dialog( this, _T("You have to let the search finish first"), "Combo Info", wxOK | wxICON_INFORMATION);

Choice1Dialog.ShowModal(); } } A par da realização da função open foi necessário desenvolver também, tal como já referido no Capítulo 5, a função de escolha de um método. De seguida é apresentado o código da respectiva função (choice), com os respectivos comentários. void MyFrame::OnChoiceSelected( wxCommandEvent& evt ) {

//O programa não se encontra a proceder a nenhuma análise

if(playPRESSED == FALSE){ //Método escolhido fica na variável method

method = evt.GetString(); //Se o debug estiver activado imprime valor guardado em method if(debug){ wxString MSG = _T("You've selected item: " + method);

wxMessageDialog ChoiceDialog( this, MSG, "Combo Info", wxOK | wxICON_INFORMATION);

ChoiceDialog.ShowModal();



} //Possibilidade de analisar as imagens escolhidas if(!method.IsEmpty() && imagens){ playpic.Enable(TRUE); } } //O programa encontra-se a realizar uma análise else{

wxMessageDialog Choice1Dialog( this, _T("You have to let the search finish first"), "Combo Info", wxOK | wxICON_INFORMATION);

Choice1Dialog.ShowModal(); } } A seguir vai-se apresentar o código da função play. Como já foi mencionado no corpo do relatório esta é a função mais complexa do programa. O código apresentado de seguida seria muito extenso se fossem apresentados todos os métodos. Contudo, como todos os métodos têm que realizar tarefas semelhantes, apresenta-se só o código aplicado a um deles, sendo possível estendê-lo facilmente às tarefas aos outros. void MyFrame::OnPlayClick( wxCommandEvent& evt) { //Variáveis necessárias para a realização da análise

PGMfile *aux, *ficheiro; RGBdata *fstbmpimg, *sndbmpimg; int i, x, y; bool errorlog; wxString caminho, logstring; wxFile logfile; int resptime = 0, auxerr; double prog; //Inicializar novamente as labels dos cortes de cena detectados, etc…a 0 textcut.SetLabel(""); textnear.SetLabel(""); texterror.SetLabel(""); texttime.SetLabel(""); //Colocar os valores dos cortes de cena detectados, etc… a 0 nearcut = 0, cut = 0, errorcut = 0; totalpausetime = 0; //Colocar variáveis boolenas com os valores respectivos cancelPRESSED = FALSE; playPRESSED = TRUE; eliminatePRESSED = FALSE; waitanswer = FALSE; errorlog = FALSE; //Colocar vazia a variável que fica com todos os cortes de cena descobertos histcuts = " "; //Poucas imagens para realizar a análise if(imagens <= 1){

wxMessageDialog methodDialog( this, _T("You have less than 2 images. Impossible make the analysis!"), "Play Info", wxOK | wxICON_ERROR);

methodDialog.ShowModal(); //Colocar os botões com as permissões respectivas playpic.Disable(); cancelpic.Disable();



playPRESSED = FALSE; return; } if((aux = (PGMfile *) malloc(sizeof(PGMfile))) == NULL){

wxMessageDialog error(this, _T("Not enough memory!"), "Error Message Box", wxOK | wxICON_ERROR | wxSTAY_ON_TOP);

error.ShowModal(); } if((ficheiro = (PGMfile *) malloc(sizeof(PGMfile))) == NULL){

wxMessageDialog error(this, _T("Not enough memory!"), "Error Message Box", wxOK | wxICON_ERROR | wxSTAY_ON_TOP);

error.ShowModal(); } //Colocar botões com permissões respectivas cancelpic.Enable(TRUE); playpic.Disable(); prevpic.Disable(); statpic.Disable(); logpic.Disable(); allcutpic.Disable(); //Inicializar variável que vai ajudar a criar o ficheiro log logstring = ""; logstring << "logs"; //Inicializar a contagem de tempo time( &totaltime_init); //Inicializar a análise começando na primeira imagem int numimgaux = firstimage; caminho = ""; caminho << dir.c_str(); caminho << "\\"; caminho << numimgaux++; caminho << ".pgm";

//Função getframe permite ir buscar a imagem apresentada em caminho e descarrega-//a para a variável aux

getframe((char *) caminho.c_str(), aux); //Se for este o método escolhido para a análise if(method == "Total Pixel Diference"){ if(debug){

wxMessageDialog methodDialog( this, method.GetData(), "Play Info", wxOK | wxICON_INFORMATION);

methodDialog.ShowModal(); } //Variável auxiliar que vai ser comparada com o limite existente int difimg; //Para este método o ficheiro de log é o met1.txt logstring << "\\met1.txt"; logfile.Create(logstring, TRUE); if(!logfile.Access(logstring, wxFile::write)){

wxMessageDialog methodDialog( this, _T("You don´t have permission to write in the file"), "Play Info", wxOK | wxICON_INFORMATION);

methodDialog.ShowModal(); } //Imprime limite para o ficheiro logstring = "CUT SCENE LIMIT "; logstring << THRESHOLD;



logstring << "\n\n"; logfile.Write(logstring); for(i = 1; i < imagens; i++){

//Faz com que a informação presente na janela de programa seja //constantemente actualizada.

wxSafeYield(this); //Tem um pedido para cancelar, sai do programa if(cancelPRESSED == TRUE || closePRESSED == TRUE) break;

//Se a análise é feita directamente qd o programa está a correr e foi //detectado um erro incorrectamente, elimina logo o corte de cena //e escreve esta informação no ficheiro de log

if(errorlog == TRUE){ if(auxerr != errorcut){ logstring = "Cut Scene detected incorrectly!!!\n"; logfile.Write(logstring); } } //Se a análise é feita directamente e está à espera de uma resposta if(waitanswer == TRUE){ if(resptime++ > WAITVALUE){ resptime = 0;

wxMessageDialog resptimeDialog( this, _("Please, choose an answer!"), "Play Info", wxOK | wxICON_EXCLAMATION);

resptimeDialog.ShowModal(); } i--; continue; } errorlog = FALSE; //Actualiza barra de progresso prog = (double) i/imagens; prog *= RANGE; progress->SetValue(prog); difimg = 0; caminho = ""; caminho << dir.c_str(); caminho << "\\"; caminho << numimgaux++; caminho << ".pgm"; //Imagem para ser comparada com a anterior getframe((char *) caminho.c_str(), ficheiro); //Aplicação do método de detecção do corte de cena

if(ficheiro->height == aux->height && ficheiro->width == aux->width && ficheiro->tammax == aux->tammax && !(strcmp(ficheiro->tipo, aux->tipo))){

for(x = 0; x < aux->height; x++){ for(y = 0; y < aux->width; y++){

difimg += abs(ficheiro->arrayfile[x*aux->width + y] - aux->arrayfile[x*aux->width + y]);

} }

//É um corte de cena



if(difimg > THRESHOLD){ if((fstbmpimg = (RGBdata *) malloc(aux->width*aux->height*2/3*sizeof(RGBdata))) == NULL){

wxMessageDialog error(this, _T("Not enough memory!!!"), "Error Message Box", wxOK | wxICON_ERROR | wxSTAY_ON_TOP);

error.ShowModal(); }

if((sndbmpimg = (RGBdata *) malloc(aux->width*aux->height*2/3*sizeof(RGBdata))) == NULL){

wxMessageDialog error(this, _T("Not enough memory!!!"), "Error Message Box", wxOK | wxICON_ERROR | wxSTAY_ON_TOP);

error.ShowModal(); } converttobmp(aux, fstbmpimg);

wxImage pic1(544, 576, (unsigned char *) fstbmpimg); pic1.Rescale(272, 288); wxBitmap fstimgpic(pic1, 24); if(debug){ if (fstimgpic.Ok()) {

wxMessageDialog error(this, _T("Ok"), "Message Box", wxOK | wxICON_INFORMATION | wxSTAY_ON_TOP);

error.ShowModal(); } else {

wxMessageDialog error(this, _T("Nicles"), "Message Box", wxOK | wxICON_INFORMATION | wxSTAY_ON_TOP);

error.ShowModal(); } } fstimg.SetBitmap(fstimgpic); converttobmp(ficheiro, sndbmpimg);

wxImage pic2(544, 576, (unsigned char *) sndbmpimg); pic2.Rescale(272, 288); wxBitmap sndimgpic(pic2, 24); if(debug){ if (sndimgpic.Ok()) {

wxMessageDialog error(this, _T("Ok"), "Message Box", wxOK | wxICON_INFORMATION | wxSTAY_ON_TOP);

error.ShowModal(); } else {

wxMessageDialog error(this, _T("Nicles"), "Message Box", wxOK | wxICON_INFORMATION | wxSTAY_ON_TOP);

error.ShowModal(); } } sndimg.SetBitmap(sndimgpic); cut++; sprintf(auxcut, "%5d", cut); cutlabel = ""; cutlabel << cut;



cutscenenum.SetLabel(cutlabel); textcut.SetLabel(cutlabel); histcuts << numimgaux - 2; histcuts << "/"; histcuts << numimgaux - 1; histcuts << " "; logstring = "\nCut Scene!!!\n"; logstring << "Frames "; logstring << numimgaux - 2; logstring << " - "; logstring << numimgaux - 1; logstring << " with difference of "; logstring << difimg; logstring << "\n"; logfile.Write(logstring); //A análise é feita qd o programa está a correr if(!dinamic){ question.Show(TRUE); butno.Show(TRUE); butyes.Show(TRUE); time( &pausetime_init); waitanswer = TRUE; errorlog = TRUE; auxerr = errorcut; resptime = 0; if(debug){ if( butyes.IsEnabled()){

wxMessageDialog YesDialog( this, "Perfeito", "Yes Info", wxOK | wxICON_INFORMATION);

YesDialog.ShowModal(); } else{

wxMessageDialog YesDialog( this, "Existe um erro aqui", "Yes Info", wxOK | wxICON_INFORMATION);

YesDialog.ShowModal(); } } } }

//Copia imagem mais recente para a mais o espaço ocupado //pela mais antiga memcpy(aux->arrayfile, ficheiro->arrayfile, aux->height * aux->width);

free(ficheiro->arrayfile);

//Próximo de corte de cena if(difimg >= (THRESHOLD - THRESHOLD*QCC) && difimg < THRESHOLD){

nearcut++; sprintf(auxnear, "%5d", nearcut); nearlabel = ""; nearlabel << nearcut;

nearcutnum.SetLabel(nearlabel);



textnear.SetLabel(nearlabel); logstring = "\nNear from cut scene limit!!!\n"; logstring << "Frames "; logstring << numimgaux - 2; logstring << " - "; logstring << numimgaux - 1; logstring << " with difference of "; logstring << difimg; logstring << "\n"; logfile.Write(logstring); } //Imprimir também os outros valores para o ficheiro de log

if(difimg < (THRESHOLD - THRESHOLD*QCC)){ logstring = ""; logstring << "Frames "; logstring << numimgaux - 2; logstring << " - "; logstring << numimgaux - 1; logstring << " with difference of "; logstring << difimg; logstring << "\n"; logfile.Write(logstring); } } } } else if …

…

//Verificar se o programa n foi interrompido enquanto estava à espera de uma //resposta if(question.IsShown() || butyes.IsShown() || butno.IsShown()){

int answer = wxMessageBox( _T("You have to answer if this is a Cut Scene?"), "Question Box", wxYES_NO | wxYES_DEFAULT | wxICON_QUESTION, this);

if(answer == wxNO){ errorcut++; sprintf(auxerror, "%5d", errorcut); errorlabel = auxerror; errorcutnum.SetLabel(errorlabel); texterror.SetLabel(errorlabel); logstring = "Cut scene detected incorrectly!!!\n"; logfile.Write(logstring); histcuts.RemoveLast(); while(histcuts.Last() != ' '){ histcuts.RemoveLast(); } } question.Hide(); butno.Hide(); butyes.Hide(); time( &pausetime_end); totalpausetime += difftime( pausetime_end, pausetime_init ); } //Terminar com a contagem de tempo e verificar qual foi esse valor time( &totaltime_end); timepassed = difftime( totaltime_end, totaltime_init ); timepassed -= totalpausetime;

//Actualizar as variáveis de tempo e de percentagem de erros para cada um dos //métodos

if(method == "Total Pixel Diference"){



met1t = (timepassed * FRAME) / ((float) (numimgaux - 1)); if(cut) met1e = (float) errorcut/cut; }

else if… …

else{ wxMessageDialog plDialog( this, _("Method not implemented"), "Play Info", wxOK | wxICON_INFORMATION);

plDialog.ShowModal(); } //Período de debug if(debug){ wxString exp; exp = ""; exp << "diferença total-> "; exp << difftime( totaltime_end, totaltime_init ); exp << " Tempo real -> "; exp << timepassed;

wxMessageDialog timeplayDialog( this, exp, "Play Info", wxOK | wxICON_INFORMATION);

timeplayDialog.ShowModal(); } //Parte final, actualiza campos necessários, coloca botões com permissões respectivas sprintf(auxtime, "%5.0f", timepassed); timelabel = auxtime; timenum.SetLabel(timelabel); texttime.SetLabel(timelabel); prevpic.Enable(TRUE); statpic.Enable(TRUE); logpic.Enable(TRUE); allcutpic.Enable(TRUE); progress->SetValue(0); wxBitmap fstimgpic(_T("images/bolapt1.bmp"), wxBITMAP_TYPE_BMP); wxImage img1aux = fstimgpic.ConvertToImage(); img1aux.Rescale(272, 288); fstimg.SetBitmap(img1aux.ConvertToBitmap()); wxBitmap sndimgpic(_T("images/bolafeup.bmp"), wxBITMAP_TYPE_BMP); wxImage img2aux = sndimgpic.ConvertToImage(); img2aux.Rescale(272, 288); sndimg.SetBitmap(img2aux.ConvertToBitmap()); playpic.Enable(TRUE); cancelpic.Disable(); playPRESSED = FALSE; free(aux->arrayfile); free(aux); free(ficheiro); }

O grau de complexidade das outras funções para as quais são apresentados os fluxogramas é relativamente baixo. Deste modo decidi não os apresentar. No entanto, funções como a getframe, a converttobmp e a Skl_Dct16_C têm mais interesse de ser abordadas nesta parte. No corpo do relatório já se explicaram os correspondentes fundamentos



teóricos. Aqui apresentam-se apenas as listagens dos respectivos programas. void getframe(char *a, PGMfile *aux){ bool existeespaco; int j; FILE *pgmfile; aux->height = 0; aux->width = 0; aux->tipo[0] = '\0'; aux->tammax = 0; pgmfile = fopen( a, "rb"); if(!pgmfile){ wxLogMessage(_T("Couldn´t open file!")); exit(1); } do{ j = 0; existeespaco = FALSE; fgets(a, SIZE, pgmfile); if(a[0] != '#'){ if(a[0]!= 'P'){ while(a[j] != '\0'){ if(a[j] == ' ') { existeespaco = TRUE; break; } j++; } if(existeespaco == TRUE) sscanf( a, "%d %d", &aux->width, &aux->height); else if(!feof(pgmfile)) sscanf( a, "%d", &aux->tammax); } else sprintf(aux->tipo, "%s", a); }

}while((!aux->tammax || !aux->width || !aux->height || (aux->tipo == '\0')) && !feof(pgmfile));

aux->arrayfile = (unsigned char *) malloc( aux->width * aux->height); if(fread((void *)aux->arrayfile, aux->width * aux->height, 1, pgmfile) != 1){ wxLogMessage(_T("Couldn´t read the file!")); } fclose(pgmfile); return; }

void converttobmp(PGMfile *a, RGBdata *b){ unsigned char *Y, *U, *V; int uinit, vinit; RGBdata bitmap; long C, D, E; bool endline = FALSE; Y = &a->arrayfile[0]; uinit = a->height*a->width*2/3;



U = &a->arrayfile[uinit]; vinit = uinit + a->width*1/2; V = &a->arrayfile[vinit]; for(int i = 0; i < 576; i++){ for(int j = 0; j < 544; j++){ if( endline == TRUE){ if( i % 2 != 0){ U = U - 272; V = V - 272; } else{ U = U + 272; V = V + 272; } endline = FALSE; } if(j == 543) endline = TRUE; C = *Y - 16; D = *U - 128; E = *V - 128; Y++; if( j % 2 != 0){ U++; V++; } bitmap.rgbRed = clip((298*C + 409*E + 128) >> 8); bitmap.rgbGreen = clip((298*C - 100*D - 208*E + 128) >> 8); bitmap.rgbBlue = clip((298*C + 516*D + 128) >> 8); b[544*i + j] = bitmap; } } } long clip(long a){ if( a > 255) a = 255; if( a < 0) a = 0; return a; }

void Skl_Dct16_C(TYPE *In) { TYPE *pIn; int i; pIn = In; for(i=8; i>0; --i) { int mm0, mm1, mm2, mm3, mm4, mm5, mm6, mm7, Spill; // odd LOAD_BUTF(mm1,mm6, 1, 6, mm0, pIn); LOAD_BUTF(mm2,mm5, 2, 5, mm0, pIn); LOAD_BUTF(mm3,mm4, 3, 4, mm0, pIn); LOAD_BUTF(mm0,mm7, 0, 7, Spill, pIn);



BUTF(mm1, mm2, Spill); BUTF(mm0, mm3, Spill); ROTATE(mm3, mm2, ROT6_C, ROT6_SmC, -ROT6_SpC, Spill, FIX-FPASS, HALF(FIX-FPASS)); pIn[2] = mm3; pIn[6] = mm2; BUTF(mm0, mm1, Spill); pIn[0] = SHIFTL(mm0, FPASS); pIn[4] = SHIFTL(mm1, FPASS); // even mm3 = mm5 + mm7; mm2 = mm4 + mm6; ROTATE(mm2, mm3, ROT17_C, -ROT17_SpC, -ROT17_SmC, mm0, FIX-FPASS, HALF(FIX-FPASS)); ROTATE(mm4, mm7, -ROT37_C, ROT37_SpC, ROT37_SmC, mm0, FIX-FPASS, HALF(FIX-FPASS)); mm7 += mm3; mm4 += mm2; pIn[1] = mm7; pIn[7] = mm4; ROTATE(mm5, mm6, -ROT13_C, ROT13_SmC, ROT13_SpC, mm0, FIX-FPASS, HALF(FIX-FPASS)); mm5 += mm3; mm6 += mm2; pIn[3] = mm6; pIn[5] = mm5; pIn += 8; } pIn = In; for(i=8; i>0; --i) { int mm0, mm1, mm2, mm3, mm4, mm5, mm6, mm7, Spill; // odd LOAD_BUTF(mm1,mm6, 1*8, 6*8, mm0, pIn); LOAD_BUTF(mm2,mm5, 2*8, 5*8, mm0, pIn); BUTF(mm1, mm2, mm0); LOAD_BUTF(mm3,mm4, 3*8, 4*8, mm0, pIn); LOAD_BUTF(mm0,mm7, 0*8, 7*8, Spill, pIn); BUTF(mm0, mm3, Spill); ROTATE(mm3, mm2, ROT6_C, ROT6_SmC, -ROT6_SpC, Spill, 0, HALF(FIX+FPASS+3)); pIn[2*8] = (TYPE)SHIFTR(mm3,FIX+FPASS+3); pIn[6*8] = (TYPE)SHIFTR(mm2,FIX+FPASS+3); mm0 += HALF(FPASS+3) - 1; BUTF(mm0, mm1, Spill); pIn[0*8] = (TYPE)SHIFTR(mm0, FPASS+3); pIn[4*8] = (TYPE)SHIFTR(mm1, FPASS+3); // even mm3 = mm5 + mm7; mm2 = mm4 + mm6; ROTATE(mm2, mm3, ROT17_C, -ROT17_SpC, -ROT17_SmC, mm0, 0, HALF(FIX+FPASS+3));



ROTATE2(mm4, mm7, -ROT37_C, ROT37_SpC, ROT37_SmC, mm0); mm7 += mm3; mm4 += mm2; pIn[7*8] = (TYPE)SHIFTR(mm4,FIX+FPASS+3); pIn[1*8] = (TYPE)SHIFTR(mm7,FIX+FPASS+3); ROTATE2(mm5, mm6, -ROT13_C, ROT13_SmC, ROT13_SpC, mm0); mm5 += mm3; mm6 += mm2; pIn[5*8] = (TYPE)SHIFTR(mm5,FIX+FPASS+3); pIn[3*8] = (TYPE)SHIFTR(mm6,FIX+FPASS+3); pIn++; } }



Referências

[1] L.F. Cheong, Scene-Based Shot Change Detection and Comparative Evaluation, Computer Vision and Image Understanding 79, 224-235, 2000.

[2] Y. Abdeljaoued, T. Ebrahimi, C. Christopoulos, I.M. Ivars, A New Algorithm for Shot Boundary Detection, 10th European Signal Processing Conference, Tampere, Finland, 2000.

[3] S.C. Chen, M.L. Shyu, C.C. Zhang, R.L. Kashyap, Video Scene Change Detection Method Using Unsupervised Segmentation and Object Tracking, IEEE International Conference on Multimedia and Expo, 57-59, 2001.

[4] E. Sifakis, I. Grinias, G. Tziritas, Vídeo Segmentation Using Marching and Region Growing Algorithms, EURASIP Journal on Applied Signal Processing, 4, 379-388, 2002

[5] Y. Lu, W. Gao, F. Wu, Automatic Video Segmentation Using a Novel Background Model, IEEE International Symposium on Circuits and Systems, Volume 3, 26-29, 2002.

[6] A. Ekin, A.M. Tekalp, A Framework for Analysis and Tracking of Soccer Video, Visual Com. and Image Proc. (VCIP), San Jose, USA, 2002.

[7] A. Ekin, A.M. Tekalp, Automatic Soccer Video Analysis and Summarization, Symp. Electronic Imaging: Science and Technology: Storage and Retrieval for Image and Video Databases IV, IS&T/SPI03, USA, 2003.

[8] H. Kim, S. Nam e J. Kim, Player Segmentation Evaluation for Trajectory Estimation in Soccer Games, Image and Vision Computing, Palmerston North, NZ, 2003.

[9] H. Benoit, Digital Television- MPEG-1, MPEG-2 and Principles of the DVB System, 2ª edição, Focal Press, Great Britain, 2002.

[10] B.Girod, K.W. Stuhlmuller, A Content – Dependent Fast DCT for Low Bit – Rate Video Coding, em Proc. IEEE International Conference on Image Processing, Chicago, USA, 1998.

Referências WEB

[1W] http://skal.planet-d.net/coding/dct.html [2W] http://libmpeg2.sourceforge.net/

Aplicação a jogos de futebol - paginas.fe.up.ptee99035/relatorio/relatorio.pdf · figura 28 –...

Documents

Transcript of Aplicação a jogos de futebol - paginas.fe.up.ptee99035/relatorio/relatorio.pdf · figura 28 –...