Visualização de Panoramas Virtuais PDF

Visualizaca~o de Panoramas Virtuais
Andre Machado de Matos

18 de agosto de 1998
A Alice
Agradecimentos
ii
Ao Luiz Velho, meu orientador, por todas as ideias que motivaram esse trabalho e por
estar sempre disposto a discutir todos os problemas
Ao Jonas por todo apoio durante os dois anos em que estive no Visgraf
Ao Marcelo Gattass por todo apoio e pelos conselhos valiosos
Ao Paulo Cezar que me introduziu a Computac~ao Graca
Ao Andre Parente e Heloisa que me deram uma vis~ao nova das aplicac~oes do nosso projeto
A galera do Visgraf, pelo otimo ambiente de trabalho
Aos Meus pais pelo carinho, pela orientac~ao e por terem criado todas as condic~oes
A s Minhas irm~as pelas muitas alegrias que me deram
A Heloisa, Manoel e Juliana que têm sido minha segunda famlia
E por ultimo, e mais importante, a Alice por todo amor e por estar sempre do meu lado
me dando todas as forcas que preciso
iii
Resumo
Recentemente um grande numero de sistemas foram desenvolvidos que permitem a visualizacao de ambientes virtuais baseados em panoramas, como o Quicktime VR. Esses
sistemas, no entanto, possuem diversas limitacoes quanto a qualidade da imagem gerada
e a interatividade. Neste trabalho, sao apresentadas algumas tecnicas de visualizacao que
resolvem essas limitacoes. Essas tecnicas estao sendo utilizadas no Sistema Visorama,
que utiliza componentes de hardware e de software para permitir uma interacao natural
e imersiva com as panoramas. O sistema desenvolvido permite a visualizacao de panoramas muito grandes a taxas interativas. Entre os assuntos abordados podemos citar
visualizacao em tempo real, deformacao de imagens, gerenciamento de cache e imagens
em multiresolucao
Abstract
Recently, a large number of systems were developed that allow the visualization of panoramabased virtual environments, like the Quicktime VR system for instance. However, these
systems have several limitations in terms of the quality of the image generated and interativity. In this work, we present a few visualization techniques that solve these limitations.
These techniques are currently being used as part of the Visorama System, which uses
hardware and software components to provide a natural and immersive interaction with
panoramas. The system we developed allows the visualization of very large panoramas
at interactive frame rates. Among the topics covered are real time visualization, image
deformation, cache management and multiresolution images.
Sumario
1 Introduc~ao
2 Visualizac~ao de Ambientes Virtuais
2.1
2.2
2.3
2.4
Motivac~ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Paradigma dos Quatro Universos de Abstraca~o . . . . . . . . . .
Func~ao de Luminosidade . . . . . . . . . . . . . . . . . . . . . .
Descric~ao da Funca~o de Luminosidade . . . . . . . . . . . . . .
2.4.1 Descric~ao Algortmica x Amostragem . . . . . . . . . . .
2.5 Criac~ao, Armazenamento e Visualizaca~o de Ambientes Virtuais .
2.5.1 Metodos de Renderizaca~o Baseada em Geometria . . . .
2.5.2 Metodos de Renderizaca~o Baseada em Imagens . . . . .
2.5.3 Convers~ao entre Descric~oes e Metodos Hbridos . . . . .
2.6 Considerac~oes Finais . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2
5
5
6
7
9
9
10
11
12
14
14
3 Renderizac~ao Baseada em Imagens
15
4 Sistemas de Panoramas Virtuais
28
3.1 Origens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.1 Computac~ao Graca . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.2 Vis~ao Computacional . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Renderizac~ao Baseada em Imagens . . . . . . . . . . . . . . . . . . . . . .
3.2.1 Visualizaca~o de Ponto de Vista Fixo . . . . . . . . . . . . . . . . .
3.2.2 Visualizaca~o por Amostragem Densa . . . . . . . . . . . . . . . . .
3.2.3 Visualizaca~o por Amostragem da Funca~o de Luminosidade Estendida
3.2.4 Visualizaca~o por Analise de Amostras da Funca~o de Luminosidade .
3.3 Modelagem Baseada em Imagens. . . . . . . . . . . . . . . . . . . . . . . .
3.4 Considerac~oes nais. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1 Panoramas Virtuais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Autoria de Panoramas . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.1 Ambientes Modelados . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.2 Fotograas do Mundo Real . . . . . . . . . . . . . . . . . . . . . . .
4.2.3 Fotograas do Mundo Real com Auxlio de Processamento Digital
de Imagens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3 Visualizac~ao de Panoramas . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4 Analise dos Sistemas Existentes . . . . . . . . . . . . . . . . . . . . . . . .
4.5 Um Novo Sistema de Panoramas Virtuais . . . . . . . . . . . . . . . . . . .
4.6 Considerac~oes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
iv
15
15
16
16
17
18
20
22
25
26
28
29
30
30
32
34
34
36
37

SUMARIO
5 Visualizac~ao de Panoramas
5.1
5.2
5.3
5.4
Modelo de Câmera . . . . . . . . . . . . . . . . . .
Imagem Panorâmica . . . . . . . . . . . . . . . . .
Visualizac~ao e Reamostragem . . . . . . . . . . . .
Transformaca~o de Dois Passos . . . . . . . . . . . .
5.4.1 Algoritmo de dois passos . . . . . . . . . . .
5.4.2 Algoritmo de Reamostragem de Fant . . . .
5.5 Visualizac~ao de Panoramas Cilndricas . . . . . . .
5.5.1 Derivac~ao da Transformaca~o de Dois Passos
5.5.2 Implementac~ao . . . . . . . . . . . . . . . .
5.6 Aproximac~ao Poligonal . . . . . . . . . . . . . . . .
5.6.1 Aproximac~ao por Transformac~oes Projetivas
5.6.2 Implementac~ao . . . . . . . . . . . . . . . .
5.7 Consideracoes Finais . . . . . . . . . . . . . . . . .
6 Gerenciamento de Cache
6.1
6.2
6.3
6.4
6.5
6.6
6.7
Otimizac~ao do Acesso aos Dados . . . .

O Problema Geral . . . . . . . . . . . . .
Algoritmo . . . . . . . . . . . . . . . . .
Visualizac~ao de Dados no Plano . . . .
Aplicaca~o na Visualizac~ao de Panoramas
Resultados . . . . . . . . . . . . . . . . .
Considerac~oes Finais . . . . . . . . . . .
7 Panoramas em Multiresoluc~ao
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7.1 Pirâmide de Imagens . . . . . . . . . . . . . . .

7.2 Pirâmide de Tiles . . . . . . . . . . . . . . . . .
7.2.1 Criac~ao da Estrutura . . . . . . . . . . .
7.2.2 Visualizaca~o da Pirâmide . . . . . . . . .
7.3 Gerenciamento de Cache e Pirâmide de Imagens
7.4 Implementac~ao . . . . . . . . . . . . . . . . . .
7.5 Resultados . . . . . . . . . . . . . . . . . . . . .
8 Conclus~oes e Trabalhos Futuros

Referências Bibliogracas
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
38
39
40
41
43
43
44
45
45
47
48
49
50
53
54
54
56
59
60
63
65
66
68
68
70
72
74
76
79
79
82
87
Lista de Figuras
2.1 Os quatro universos de abstraca~o. . . . . . . . . . . . . . . . . . . . . . . .
2.2 Os processos de modelagem, armazenamento e visualizaca~o utilizando representac~oes baseadas em geometria. . . . . . . . . . . . . . . . . . . . . .
2.3 Os processos de modelagem, armazenamento e visualizaca~o utilizando representac~oes baseadas em imagens. . . . . . . . . . . . . . . . . . . . . . .
3.1 Parametrizacao baseada em panoramas. . . . . . . . . . . . . . . . . . . .
3.2 Parametrizacao do conjunto de retas do espaco. . . . . . . . . . . . . . . .
3.3 Amostragem da func~ao de luminosidade. . . . . . . . . . . . . . . . . . . .
3.4 Visualizac~ao utilizando representaca~o por slabs. . . . . . . . . . . . . . . .
3.5 Mapa de disparidades de uma imagem em relaca~o a outra (Imagem obtida
do trabalho de Chen e Williams). . . . . . . . . . . . . . . . . . . . . . . .
3.6 Triangulac~ao a partir de uma imagem com profundidade (Imagem obtida
do trabalho de Darsa et al.). . . . . . . . . . . . . . . . . . . . . . . . . . .
3.7 View morphing permite que a imagem Is seja gerada a partir de I0 e I1 . . .
3.8 Pre-deformaca~o (a) Interpolac~ao (b) e Pos-deformac~ao (c). . . . . . . . . .
3.9 Resultado da aplicaca~o do view-morphig a duas imagens (Imagem obtida
do trabalho de Seitz e Dyer). . . . . . . . . . . . . . . . . . . . . . . . . . .
3.10 Calculo da posica~o relativa dos cilindros minimiza a distância d entre os
raios denidos pelos pixels correspondentes p e p'. . . . . . . . . . . . . . .
3.11 Modelo reconstrudo e uma das fotograas originais. As arestas do modelo
realcadas na fotograa s~ao utilizadas no metodo de otimizaca~o (Imagem
obtida do trabalho de Debevec et al.). . . . . . . . . . . . . . . . . . . . . .
4.1 Imagem panorâmica e seu mapeamento na superfcie panorâmica cilndrica.
4.2 Câmera virtual visualizando panorama cilndrica. . . . . . . . . . . . . . .
4.3 Câmera panorâmica modelo Roundshot produzido pela SEITZ Phototechnik.
4.4 Fotograa panorâmica cilndrica de 360 tirada da estaca~o de trem da Amtrak em Oakland, CA, EUA. Design: VBN Associates, Oakland Foto: Anc 1996. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
drew Van Dis
4.5 Lente sheye de 6mm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.6 Fotograa tirada com uma lente sheye. . . . . . . . . . . . . . . . . . . .
4.7 As fotograas s~ao tiradas a intervalos de a^ngulos regulares com sobreposica~o.
4.8 Composic~ao de duas imagens consecutivas. . . . . . . . . . . . . . . . . . .
4.9 Imagem panorâmica da cidade do Rio de Janeiro vista do morro do Corcovado. Foto: Andre Parente (a) A mesma imagem editada para simular o
Rio de Janeiro antes do descobrimento do Brasil. Edica~o: Heloisa Siert (b)
vi
7
11
13
17
18
19
20
21
21
22
23
24
24
26
29
29
31
31
31
32
32
33
34
LISTA DE FIGURAS
4.10 A visualizac~ao da superfcie cilndrica com a imagem mapeada pela câmera
virtual (a) e implementada por uma deformac~ao 2D dessa imagem (b). . .
4.11 O esquipamento de hardware do Sistema Visorama. . . . . . . . . . . . . .
5.1 Durante o processo de autoria o ambiente e projetado na superfcie panorâmica. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 Uma câmera de modelo pinhole visualizando a supefcie produz a mesma
imagem que seria gerada se visualizasse o ambiente. . . . . . . . . . . . . .
5.3 Parâmetros da Câmera Virtual. . . . . . . . . . . . . . . . . . . . . . . . .
5.4 Mapeamento entre o espaco de parâmetros da superfcie e o plano de imagem da câmera virtual. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.5 Superposic~ao do grid da imagem nal transformado (T (xi; yi)) com o grid
da imagem inicial ((ui; vi). (a) Expans~ao (b) Contrac~ao. . . . . . . . . . .
5.6 Câmera virtual geral (a) simplicada(b) . . . . . . . . . . . . . . . . . . .
5.7 Imagem panorâmica de 360 graus utilizada para testar o algoritmo . . . . .
5.8 Vistas do ambiente obtidas por deformaco~es da imagem panorâmica da
gura anterior. Resultado do primeiro passo (a) e (c). Resultado dos dois
passos (b) e (d). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.9 A malha poligonal e uma grade regular . . . . . . . . . . . . . . . . . . . .
5.10 A transformac~ao pode ser aproximada por uma transformac~ao projetiva
por partes poligonizando a superfcie S . . . . . . . . . . . . . . . . . . . .
5.11 Vistas do ambiente obtidas por aproximaca~o poligonal. . . . . . . . . . . .
5.12 Os gracos ilustram o tempo de geracao de cada quadro para tamanho de
imagens diferentes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1 Nveis de armazenamento utilizados em um sistema de visualizac~ao. . . . .
6.2 Elementos de um esquema de cache. . . . . . . . . . . . . . . . . . . . . . .
6.3 Graco de objetos carregados por quadro. . . . . . . . . . . . . . . . . . .
6.4 Graco de tiles carregados no cache por quadro quando pre carregamento
e utilizado. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5 Algoritmo de gerenciamento de cache com pre carregamento . . . . . . . .
6.6 Os tiles escuros est~ao sendo visualizados no quadro corrente. . . . . . . . .
6.7 Tiles classicados segundo o criterio temporal. . . . . . . . . . . . . . . . .
6.8 Tiles classicados segundo o criterio espacial para um unico nvel da multiresoluc~ao. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.9 Uma imagem panorâmica subdividida em tiles. . . . . . . . . . . . . . . . .
6.10 A janela de visualizaca~o em uma imagem panorâmica cilndrica. . . . . . .
6.11 Graco do numero de pixels carregados por quadro, com pre carregamento
e utilizando o oraculo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.12 Um pedaco da sequência de visualizac~ao gravada. A janela de visualizac~ao
corrente esta desenhada em branco, as janelas anteriores em cinza claro e
as futuras em cinza escuro. . . . . . . . . . . . . . . . . . . . . . . . . . .
7.1 Pirâmide de Imagens. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2 Cada nvel da pirâmide e uma matriz de tiles, com tamanhos crescentes. .
7.3 Cada tile na estrutura pode ter quatro lhos que representam a mesma
regi~ao com o dobro de resoluc~ao. . . . . . . . . . . . . . . . . . . . . . . .
vii
35
36
39
40
40
41
42
46
47
48
49
50
50
51
55
56
58
58
61
62
62
63
64
64
66
66
69
71
71
LISTA DE FIGURAS
7.4 A pirâmide de tiles e representada por uma arvore tipo quadtree. Os quadrados em cinza correspondem a tiles existentes. . . . . . . . . . . . . . . .
7.5 As imagens dos nveis inferiores s~ao criadas aplicando o ltro box de tamanho dois e fazendo amostragem pontual. . . . . . . . . . . . . . . . . . . .
7.6 Uma pirâmide de 4 nveis simplicada usando fator de qualidade q=0.5. . .
7.7 A mesma pirâmide da gura anterior simplicada usando fator de qualidade
q=0.3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.8 Vistas obtidas de uma imagem panorâmica. Os numeros embaixo de cada
vista indicam o numero de tiles desenhados para gerar essa vista. (a) Vistas
geradas com a imagem panorâmica original (b) Vistas geradas com uma
pirâmide de tiles criada da imagem panorâmica com qualidade 1. . . . . .
7.9 Durante uma mudanca rapida de parâmetros, o nvel corrente desce na
pirâmide ate que a mudanca de parâmetros diminua e os tiles do nvel
otimo possam ser carregados a tempo. (a) Parâmetros de visualizaca~o constantes. (b) Movimento rapido para a direita. (c) Parâmetros constantes
novamente. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.10 Tempos de geraca~o de quadros para quatro sequências de visualizaca~o em
uma imagem de 155 MB. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.1 Tela do Stitcher. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
72
73
74
75
77
78
80
85
Captulo 1
Introduc~ao
Recentemente, um grande numero de trabalhos que permitem a visualizac~ao de ambientes virtuais a partir de imagens foram propostos. Nesses trabalhos, o ambiente e
representado por um conjunto de imagens, que s~ao combinadas durante a visualizac~ao,
para criar vistas arbitrarias. Essa abordagem possui diversas vantagens em relac~ao aos
metodos tradicionais de renderizac~ao baseada em geometria e, dentre elas, podemos citar:
o tempo de renderizaca~o independe da complexidade do ambiente virtual, o que e

bom para aplicac~oes interativas;

as imagens podem ser obtidas do mundo real, o que possibilita a criaca~o de ambientes
foto-realistas;
as imagens podem ser geradas por metodos tradicionais de renderizaca~o como um
pre-processamento;
o ambiente pode ser alterado por um artista pintando sobre as imagens;
n~ao ha necessidade de modelar geometricamente o ambiente, o que em geral e um
processo demorado.
Devido a essas vantagens, esses trabalhos têm ganhado grande importância na area de
Computac~ao Graca, o que resultou no surgimento de uma nova sub-area, a renderizac~ao
baseada em imagens.
Os metodos de renderizac~ao baseada em imagens diferem no modo como amostram e
reconstroem o ambiente virtual, o que determina o tipo de navegaca~o permitida. Apesar de muitos desses metodos terem sido propostos, boa parte deles têm problemas que
impossibilitam sua utilizac~ao em um sistema para navegaca~o de ambientes virtuais em
tempo real. O problema mais comum e que n~ao criam vistas corretas em todos os pontos
da navegac~ao. Alguns que resolvem esse problema n~ao s~ao sucientemente interativos,
outros exigem uma capacidade de armazenamento t~ao grande que tornam impossvel a
representac~ao de um ambiente completo. Uma excec~ao e o metodo de visualizaca~o por panoramas virtuais, que e capaz de gerar vistas corretas a taxas interativas sem necessidades
de armazenamento muito grandes.
Em uma panorama virtual, o usuario permanece em um ponto xo do ambiente,
podendo olhar em qualquer direc~ao. A direc~ao de visualizac~ao pode ser alterada continuamente e o metodo reconstroi todas as vistas em tempo real. Alem disso, pode-se
~
CAPITULO 1. INTRODUCAO
aproximar de objetos atraves de um fator de zoom, como na interac~ao com um binoculo.

Finalmente, e possvel a movimentaca~o pelo ambiente "pulando"entre diferentes pontos,
ou seja, o metodo n~ao permite que o usuario ande continuamente entre dois pontos. Diversos sistemas, comerciais ou n~ao, ja foram desenvolvidos que utilizam panoramas para
a visualizac~ao de ambientes virtuais.
Os sistemas de panoramas virtuais s~ao na verdade compostos de dois subsistemas,
autoria e visualizaca~o. O subsistema de autoria permite a criaca~o da panorama que
representa o ambiente virtual, sendo executado somente pelos autores do ambiente. Ja
o subsistema de visualizac~ao, e executado durante a navegaca~o do usuario, gerando as
vistas do ambiente.
Os sistemas de visualizac~ao existentes, no entanto, n~ao permitem uma interaca~o imersiva com as panoramas. Para isso e necessario que a qualidade da imagem gerada seja
muito boa e que seja mostrada a taxas interativas, o que n~ao ocorre nesses sistemas.
Resumimos abaixo as suas principais limitaco~es:
n~ao geram imagens a taxas constantes e interativas;

introduzem uma pequena latência na interaca~o;
n~ao suportam a utilizac~ao de imagens muito grandes, o que reduz a quantidade de
detalhes do ambiente que pode ser representada.
Nessa dissertac~ao, apresentamos algumas tecnicas de visualizaca~o de panoramas virtuais que resolvem os problemas dos sistemas existentes mencionados acima. Dentre essas,
podemos citar, a visualizaca~o de panoramas utilizando hardware de mapeamento de textura, o gerenciamento de cache e a representaca~o de imagens em multiresoluca~o. Essas
tecnicas est~ao sendo utilizadas no Sistema Visorama (Matos et al. , 1997b), um novo
equipamento de realidade virtual que utiliza um dispositivo binocular para visualizar ambientes representados por panoramas. Os resultados obtidos com a suas utilizac~oes no
Visorama têm sido bastante satisfatorios.
Antes de falarmos do sistema de visualizaca~o de panoramas, no entanto, falaremos
um pouco sobre visualizaca~o de ambientes virtuais e, em particular, sobre os metodos de
renderizac~ao baseada em imagens.
No Captulo 2 apresentamos uma conceituaca~o do problema de visualizac~ao de ambientes virtuais. Utilizando essa conceituac~ao, mostramos como os metodos de renderizac~ao
baseada em imagens s~ao fundamentalmente diferentes dos metodos de renderizac~ao baseada em geometria. Essa comparac~ao so foi feita na literatura para metodos especcos
enquanto a nossa discuss~ao pretende ser mais geral e se aplicar a toda a area de renderizac~ao baseada em imagens. Apresentamos tambem as principais etapas da visualizac~ao
utilizando essas duas abordagens.
No captulo 3, apresentamos uma vis~ao geral da area de renderizaca~o baseada em
imagens. Discutimos suas origens, mostrando como se desenvolveu a partir da Computac~ao Graca e da Vis~ao Computacional. Em seguida, apresentamos alguns trabalhos
importantes que demonstram as principais linhas de pesquisa.
No captulo 4, apresentamos uma vis~ao geral dos sistemas de panoramas virtuais.
Discutimos seus principais componentes, mostramos, em linhas gerais, como o ambiente
virtual e criado e como e feita a visualizac~ao. Ao nal do captulo, falamos sobre alguns
sistemas existentes, mostrando as vantagens e deciências de cada um.
~
CAPITULO 1. INTRODUCAO
No captulo 5 apresentamos detalhes da visualizaca~o de panoramas. Mostramos que

essa visualizac~ao pode ser efetuada pela deformaca~o de uma imagem e apresentamos
duas alternativas de implementaca~o desta deformaca~o. Discutimos as duas abordagens,
apresentando resultados da sua implementaca~o, e mostramos porque decidimos utilizar a
segunda.
Uma das grandes diculdades na implementac~ao da visualizac~ao de panoramas a taxas
interativas e a latência introduzida pelo tempo de acesso as imagens. Esse problema se
torna ainda maior na medida em que o tamanho das imagens cresce. Para resolver esse
problema, e necessario o desenvolvimento de um algoritmo de gerenciamento de cache,
que otimize esse tempo de acesso. Apresentamos um algoritmo deste tipo no captulo
6. Embora os resultados que mostramos sejam da implementac~ao deste algoritmo para a
visualizac~ao de panoramas, ele pode ser aplicado em qualquer problema de visualizac~ao
e, sendo assim, e apresentado neste captulo da forma mais generica possvel.
Finalmente, no captulo 7 mostramos como os algoritmos apresentados nos captulos
anteriores podem ser utilizados para visualizar ambientes representados por imagens arbitrariamente grandes, mantendo a taxa de geraca~o de quadros sempre constante. Para que
o tamanho da imagem n~ao afete a taxa de geraca~o de quadros, a imagem e armazenada
em uma estrutura de multiresoluca~o. Mostramos como essa estrutura pode ser criada e
como e utilizada para visualizac~ao. Ao nal do captulo, mostramos resultados numericos
que evidenciam o funcionamento correto dos algoritmos.
Pode-se notar que a dissertac~ao esta organizada de forma que os captulos v~ao cando
cada vez mais especcos. No Captulo 2 discutimos visualizaca~o de ambientes em geral, no
proximo falamos da visualizac~ao baseada em imagens, em seguida abordamos os sitemas
de panoramas virtuais. A partir da discutimos o desenvolvimento de um sistema especco
de visualizac~ao de panoramas, apresentando as diversas tecnicas utilizadas, comecando
pelo esquema de visualizac~ao basico e depois apresentando algumas otimizac~oes. Ao longo
dessa discuss~ao, optamos por uma descric~ao mais ampla de cada tecnica, muitas vezes
evitando entrar em muitos detalhes, principalmente os detalhes de implementaca~o. Isso
foi necessario para que todas as tecnicas pudessem ser abordadas sem que a dissertac~ao
casse grande demais. Apesar disso, as principais caractersticas de cada tecnica s~ao
apresentadas com clareza, de modo que, a partir dessa discuss~ao, o leitor deve ser capaz
de repetir os resultados encontrados.
Captulo 2
Visualizac~ao de Ambientes Virtuais
Apesar de muitos trabalhos terem surgido nos ultimos anos apresentando metodos
diferentes de renderizac~ao baseada em imagens, poucos têm se preocupado em conceituar
o que esses metodos têm em comum e o que os diferencia dos metodos tradicionais de
renderizac~ao baseada em geometria. Neste captulo, faremos uma conceituaca~o das duas
abordagens que nos permitira caracterizar os trabalhos de renderizac~ao baseada em imagens e compara-los com os metodos baseados em geometria. Uma comparaca~o entre as
duas abordagens foi feita por McMillan (McMillan, 1997) para o caso especco do metodo
proposto no seu trabalho. A conceituaca~o aqui apresentada, por outro lado, pretende ser
a mais geral possvel sem entrar em detalhes de trabalhos especcos. Acreditamos que
atraves dessa conceituac~ao pode-se compreender melhor os trabalhos na area.
Comecaremos falando das motivac~oes que levaram ao densenvolvimento da tecnologia
baseada em imagens. Em seguida apresentamos o paradigma dos quatro universos, que
fornecera um suporte para conceituac~ao da area. Utilizando esse paradigma, mostramos
as diferencas fundamentais entre as abordagens baseadas em imagens e baseadas em
geometria. Finalmente, ilustramos os processos de autoria, armazenamento e visualizac~ao
de ambientes virtuais para os dois casos.
2.1 Motivac~ao
Tradicionalmente, ambientes virtuais têm sido representados e visualizados utilizandose tecnicas de computac~ao graca 3D. Nesse caso, os objetos do ambiente virtual s~ao
representados por modelos geometricos 3D e s~ao visualizados em tempo real utilizando-se
modelos de simulaca~o de iluminaca~o. Porem, esses processos de modelagem e visualizac~ao
apresentam diversas limitac~oes para a criac~ao de ambientes virtuais foto-realsticos.
Embora um grande numero de representaco~es de objetos tri-dimensionais tenha sido
proposto (CSG, B-Rep, Decomposica~o celular, etc ), em todas essas representac~oes, o
processo de modelagem manual dos objetos e intrinsicamente problematico para a criac~ao
de ambientes foto-realsticos. Isso porque a geometria de muitos objetos do mundo real
e extremamente complexa e, portanto, e quase impossvel de ser completamente especicada manualmente. Alem disso, em muitos casos onde a modelagem pode ser feita, o
processo e extremamente trabalhoso. Alem da diculdade de modelagem, as representac~oes geometricas possuem outra limitac~ao devido aos metodos de visualizaca~o que s~ao
empregados. Esses metodos trabalham com primitivas simples, geralmente polgonos, e
~ DE AMBIENTES VIRTUAIS
CAPITULO 2. VISUALIZACAO
possuem um limite no numero de polgonos que podem ser mostrados por segundo a taxas
interativas. Com isso a complexidade do ambiente virtual a ser navegado e limitada.
Uma terceira limitac~ao dessa abordagem se deve a diculdade de empregar modelos de
iluminac~ao foto-realsticos em tempo-real, como o ray-tracing (Watt, 1993). Tipicamente
esses modelos s~ao globais, e consideram as interac~oes entre os diferentes objetos da cena,
o que faz com que sejam lentos e n~ao possam ser empregados a taxas interativas em
equipamentos comuns.
Para aplicac~oes de realidade virtual, no entanto, n~ao e importante que a geometria do
ambiente seja conhecida com grande precis~ao, ou que a iluminac~ao da cena seja simulada
corretamente, mas apenas que o ambiente seja visualmente realista para que haja imersibilidade. Essa observaca~o motivou o desenvolvimento de tecnicas de mapeamento de
textura para resolver algumas dessas limitaco~es (Heckbert, 1986). Utilizando mapeamento de textura, a micro-geometria de alguns objetos do ambiente podem ser representadas
por imagens, por exemplo, as janelas de uma casa vista a distância, ou a rugosidade de
alguns materiais (Blinn, 1978). Atraves dessas tecnicas, um grande numero de polgonos
de um objeto pode ser visualmente representado por um unico polgono com uma imagem
mapeada. Alem disso, diversos efeitos de iluminaca~o podem ser simulados de modo mais
eciente com texturas (Blinn, 1976). O mapeamento de textura possibilitou pela primeira
vez a utilizac~ao de fotograas do mundo real na sntese de ambientes virtuais.
Nas tecnicas de mapeamento de textura, porem, ainda e necessario que os objetos do
ambiente sejam modelados, pois as imagens s~ao mapeadas em superfcies desses objetos.
Dessa forma, as limitac~oes descritas acima n~ao s~ao totalmente resolvidas. Mas com a
evoluc~ao dos equipamentos gracos, que passaram a ser capazes de mostrar um grande
numero de polgonos com textura a taxas interativas, surgiu recentemente um novo conjunto de tecnicas que prometem resolver grande parte desses problemas, as tecnicas de
renderizac~ao baseada em imagens.
As tecnicas de renderizac~ao baseada em imagens s~ao, de certa forma, uma extens~ao do
mapeamento de textura onde as proprias imagens s~ao utilizadas para representar o ambiente, n~ao sendo necessario nenhum modelo dos objetos da cena. Para o desenvolvimento
dessas tecnicas foram utilizados diversos resultados de uma area adjacente a Computac~ao
Graca, a area de Vis~ao Computacional.
Apesar das tecnicas de renderizac~ao baseada em imagens terem surgido da computac~ao
graca 3D baseada em geometria, existem diferencas conceituais importantes entre as
duas abordagens. Nas proximas sec~oes apresentaremos algumas dessas diferencas. A
compreens~ao dessas sec~oes e essencial para que se entenda porque uma nova area da
Computac~ao Graca esta surgindo em torno dessas tecnicas.
Vale ressaltar que essas tecnicas devem ser utilizadas apenas em aplicaco~es onde o
objetivo e a visualizac~ao do ambiente. Em aplicaco~es de simulac~ao onde propriedades
fsicas dos objetos devem ser consideradas, como muitos programas de engenharia, a
representac~ao geometrica e impressindvel.
2.2 Paradigma dos Quatro Universos de Abstrac~ao

Para discutirmos as principais diferencas conceituais entre as abordagens baseadas em
imagens e em geometria para representac~ao e visualizaca~o de ambientes, apresentamos
o paradigma dos quatro universos de abstrac~ao. Atraves desse paradigma, denimos
mais precisamente o problema a ser resolvido e discutimos como essas duas soluco~es s~ao
utilizadas.
O paradigma dos quatro universos de abstraca~o foi introduzido por Jonas Gomes e
Luiz Velho (Gomes & Velho, 1995) como um guia para abordar problemas de matematica
computacional, baseado no trabalho de Requicha (Requicha, 1980) na area de modelagem
geometrica.
De acordo com o paradigma dos quatro universos, os problemas de matematica computacional s~ao resolvidos em diferentes nveis de abstraca~o, ou universos, ilustrados na
Figura 2.1. Os objetos do mundo real est~ao associados ao nvel de abstrac~ao chamado de
universo fsico. Os modelos matematicos, que descrevem objetos e leis do mundo fsico,
pertencem a um nvel de abstraca~o conhecido como universo matematico. Para serem
manipulados no computador, esses modelos devem ser convertidos em uma descrica~o por
um numero nito de smbolos que pertencem a um universo de representaca~o. Finalmente, essas representac~oes nitas s~ao efetivamente implementadas no computador atraves de
estruturas de dados apropriadas, que pertencem ao universo de implementac~ao.
Universo
Fisico
Universo
Matematico
Universo de
Representacao
Universo de
Codificacao
Figura 2.1: Os quatro universos de abstraca~o.

A correspondência entre objetos do universo matematico e de representaca~o e denida
por uma relac~ao matematica conhecida como esquema de representac~ao. Geralmente, um
grande numero de esquemas de representaca~o pode ser denido para o mesmo universo
matematico. Cada esquema pode ser mais vantajoso para certas aplicaco~es e, assim, e
importante que se conheca metodos de convers~ao entre os diferentes esquemas de representac~ao.
No caso do problema de visualizac~ao de ambientes virtuais, o fenômeno fsico de interesse e a interac~ao da energia eletromagnetica na faixa do visvel que e emitida por cada
objeto do ambiente (dizemos que a energia e emitida pelo objeto mas n~ao exigimos que
este seja fonte de luz, ou seja, a energia pode, na realidade, ser re etida ou refratada
pelo objeto). Precisamos denir um modelo matematico para descrever esse fenômeno e,
a partir deste modelo, criar esquemas de representaca~o que permitir~ao a simulac~ao deste
fenômeno no computador. Na proxima seca~o descrevemos um modelo matematico que
julgamos apropriado para este problema.
2.3 Func~ao de Luminosidade

O modelo matematico que utilizaremos para representar as interaco~es de energia luminosa no ambiente e o que chamamos de func~ao de luminosidade.
A func~ao de luminosidade de um ambiente estatico e denida do seguinte modo: seja
V = (Vx; Vy ; Vz ) um ponto do espaco, seja d = (; ) uma direca~o, e seja P o primeiro ponto
do ambiente interceptado por um raio R iniciado em V e com direc~ao d. Ent~ao, a func~ao
de luminosidade determina a cor emitida em P quando visualizado de V . Essencialmente,
essa funca~o determina a cor do ambiente quando visto de um determinado ponto e direc~ao
de visualizac~ao. Para estender essa denica~o a ambientes dinâmicos, basta que a func~ao
tambem dependa do tempo. Com isso, a func~ao de luminosidade e do tipo:
l = L(; ; Vx; Vy ; Vz ; t)
(2.1)
A func~ao de luminosidade foi denida por diversos autores, em areas diferentes, e

por vezes utilizando parâmetros um pouco diferentes. O primeiro a denir uma func~ao
semelhante foi A. Gershun (Gershun, 1939) em um artigo sobre as propriedades da luz,
embora sua func~ao determine o vetor de irradiância ao inves da cor. Mais recentemente,
P. Moon (Moon, 1981) deniu uma funca~o semelhante a de luminosidade que chamou
de photic eld. Ja no contexto de vis~ao computacional, Adelson e Bergen (Adelson &
Bergen, 1991) introduziram o que chamaram de plenoptic function, que e semelhante a
func~ao de luminosidade que acabamos de denir, mas retorna a radiância emitida no
ponto ao inves da cor. Com isso, a plenoptic function possui um parâmetros a mais que
indica o comprimento de onda cuja radiância deve ser retornada. Decidimos utilizar a
cor na func~ao de luminosidade, ao inves da radiância, para torna-la mais simples. Os
primeiros que propuseram um modelo matematico para renderizac~ao baseada em imagens
foram MacMillan e Bishop (McMillan & Bishop, 1995a), que utilizaram plenoptic function.
Por esse motivo, e geralmente a funca~o utilizada nos trabalhos de renderizac~ao baseada
em imagens. A func~ao de luminosidade tambem foi denida de forma independente por
Gomes e Velho no contexto de computaca~o graca (Gomes & Velho, 1989).
A func~ao de luminosidade pode ainda ser estendida para utilizar outros parâmetros.
Em particular, um parâmetro util para os metodos de vis~ao computacional e a profundidade z ao longo do raio R onde a radiância foi amostrada. Utilizando esse parâmetro
e possvel representar amostras da func~ao de luminosidade por camadas, o que permite
calcular a visibilidade corretamente para pontos de vista proximos. Podemos pensar em
uma imagem com z-buer como sendo um numero de amostras dessa func~ao onde o valor
do z-buer indica o parâmetro z que foi utilizado na amostragem. Chamaremos essa nova
func~ao de func~ao de luminosidade estendida, que e do tipo:
l = L(; ; z; Vx; Vy ; Vz ; t)
(2.2)
Utilizando a func~ao de luminosidade (ou luminosidade estendida), podemos denir o

objetivo dos metodos de renderizac~ao de ambientes virtuais: O objetivo dos metodos de
renderizac~ao de ambientes virtuais e criar uma descric~ao nita da func~ao de luminosidade
do ambiente e, a partir desta, reconstru-la para gerar amostras em tempo real com os
parâmetros dados pela navegaca~o do usuario.
Essa denic~ao utiliza a palavra renderizaca~o de uma forma um pouco diferente de
como ela e geralmente utilizada. Em geral, esse termo denota somente as tecnicas de
visualizac~ao de ambientes virtuais, mas segundo a nossa denic~ao tambem consideramos
parte dos metodos de renderizaca~o a criac~ao da descrica~o da funca~o de luminosidade do
ambiente, essencialmente a criaca~o do ambiente virtual. Fazemos isso porque os trabalhos
que tem sido considerados na literatura parte da area de renderizaca~o baseada em imagens
fazem muito mais do que somente visualizar o ambiente, criando tambem a sua descric~ao
(melhor seria se essa area tivesse sido chamada de representac~ao baseada em imagem).
Para o leitor acostumado com os termos da Computac~ao Graca, ca a ressalva de que
nessa dissertaca~o consideramos como parte dos metodos de renderizaca~o tanto a criac~ao
quanto a visualizac~ao do ambiente.
Diferentes descrico~es podem ser utilizadas cada uma utilizando esquemas de representac~ao diferentes. Nas proximas sec~oes discutiremos algumas dessas descric~oes, em particular, discutiremos aquelas utilizadas na visualizaca~o baseada em imagens e na visualizac~ao
baseada em geometria.
2.4 Descric~ao da Func~ao de Luminosidade

Os esquemas de representac~ao devem criar uma descric~ao nita da func~ao de luminosidade. Essa descrica~o e tipicamente n~ao inversvel e dicilmente e unica, ou seja, dada
uma mesma func~ao de luminosidade, mais de uma descrica~o pode geralmente ser criada
utilizando o mesmo esquema.
Com essa descric~ao, e possvel reconstruir a funca~o de luminosidade, gerando amostras
para uma determinada congurac~ao do observador (0 ; 0; z0 ; Vx0; Vy0 ; Vz0; t0 ).
Cabe aqui um comentario relativo a representaca~o de amostras da func~ao de luminosidade nos metodos que vamos tratar. Essas amostras s~ao representadas por uma imagem
digital, resultante de uma fotograa do ambiente, que determina os valores dessa func~ao
no ponto onde a foto foi tirada a nas direco~es dadas pelo raio que liga cada pixel ao
centro de projec~ao da câmera. A rigor, cada imagem representa diversas amostras, uma
por pixel. Mas para facilitar a discuss~ao, sempre que falarmos de uma amostra da func~ao
de luminosidade nesta dissertac~ao estamos nos referindo a uma imagem digital inteira,
independente do seu tamanho.
Argumentamos anteriormente que os metodos baseados em imagens s~ao fundamentalmente diferentes dos metodos baseados em geometria. Mostraremos a seguir que essa
diferenca resulta do fato de utilizarem descric~oes diferentes para a func~ao de luminosidade.
2.4.1 Descric~ao Algortmica x Amostragem
A computaca~o graca baseada em geometria utiliza um esquema de representac~ao

que gera um tipo de descrica~o que chamamos de descric~ao algortmica. Esses esquemas
n~ao geram uma descric~ao direta da func~ao, e sim uma descrica~o do processo que deve
ser executado para reconstru-la. No caso da func~ao de luminosidade, o processo a ser
simulado e a interac~ao da energia luminosa no ambiente virtual (Foley et al. , 1987).
Dessa forma, a descric~ao deve conter os modelos de iluminac~ao, a geometria dos objetos
na cena, as propriedades luminosas de seus materiais, as propriedades das fontes de luz,
entre outras informac~oes. A partir dessa descrica~o o processo pode ser simulado em tempo
real gerando uma amostra da func~ao de luminosidade no ponto dado pela congurac~ao
do observador.
Ja os metodos de renderizac~ao baseada em imagens utilizam um esquema que gera
um tipo de descric~ao que chamamos de descric~ao direta. Esses esquemas descrevem a
func~ao diretamente atraves de amostras, e a reconstruc~ao e feita utilizando algum ltro
de interpolac~ao, que e empregado sobre as amostras mais proximas do ponto onde se
deseja recontru-la.
A compreens~ao da diferenca entre as descric~oes algortmica e direta e provavelmente
o principal objetivo deste captulo, pois e essa a diferenca fundamental entre os metodos
10
de renderizac~ao baseada em imagens e baseada em geometria. Voltando as tecnicas de

mapeamento de textura, ca claro agora como as tecnicas de renderizaca~o baseada em
imagens diferem dessas. No caso de mapeamento de textura, a imagem representa propriedades da superfcie do objeto a ser utilizado durante a simulac~ao, enquanto que no caso
da renderizac~ao baseada em imagens representa uma amostra da funca~o de luminosidade.
Para ilustrar mais claramente a diferenca entre as duas abordagens, faremos uma
analogia com o caso mais simples da descric~ao do lancamento de um projetil. O esquema
por descric~ao algortmica descreveria o movimento pelas equac~oes que o regem, enquanto
o esquema por descric~ao direta o descreveria por algumas posic~oes ao longo da trajetoria,
que poderiam ser medidas experimentalmente ou obtidas atraves de uma simulac~ao previa.
Ambos apresentam vantagens e desvantagens.
Na descric~ao algortmica, o tempo de avaliar as equaco~es pode ser proibitivo para ser
executado em tempo real. Alem disso, a simulac~ao das equac~oes pode resultar em uma
aproximac~ao ruim do movimento e muitas vezes o processo de especicaca~o da simulac~ao
pode ser extremamente complicado. Na descric~ao direta, porem, os dados podem ser
medidos experimentalmente e a reconstruc~ao pode ser feita mais ecientemente. De fato,
um grande numero de ltros de reconstruca~o podem ser utilizados, alguns mais ecientes,
outros que permitem uma reconstruc~ao melhor com menos amostras. Alem disso, o movimento reconstrudo pode ser feito t~ao proximo do real quanto se deseja aumentando-se
o numero de amostras.
Por outro lado, um grande numero de amostras pode exigir uma quantidade de armazenamento muito grande, enquanto que a descrica~o por equac~oes e geralmente mais
concisa. Finalmente, se o lancamento for modicado, o esquema algortmico permite uma
modicac~ao mais simples da descrica~o.
Essas mesmas quest~oes s~ao relevantes quando comparamos as duas abordagens para
representac~ao de ambientes virtuais, e ser~ao discutidas na proxima seca~o, onde apresentamos detalhadamente o processo de criac~ao, armazenamento e visualizac~ao de ambientes
virtuais utilizando cada abordagem.
2.5 Criac~ao, Armazenamento e Visualizac~ao de Ambientes Virtuais

Na utilizac~ao dos esquemas de representac~ao apresentados, três processos principais
s~ao executados: autoria, armazenamento e visualizac~ao. Cada um desses processos incluem um conjunto de operac~oes que s~ao aplicadas aos dados.
O processo de autoria consiste das operac~oes utilizadas para a criaca~o do ambiente
virtual, ou melhor, criac~ao da descric~ao da funca~o de luminosidade do ambiente. Geralmente, o processo ideal de autoria e aquele que oferece grande liberdade de criac~ao para o
autor do ambiente ao mesmo tempo que utiliza operaco~es simples e intuitivas. Em muitos
casos, esses dois objetivos s~ao con itantes, e um compromisso entre os dois e atingido da
melhor forma para a aplicaca~o especca.
O processo de armazenamento inclui as operaco~es necessarias para armazenar e acessar a descric~ao da func~ao de luminosidade. O processo ideal de armazenamento deve
minimizar o espaco ocupado e, ao mesmo tempo, permitir um acesso rapido durante a
visualizac~ao.
11
Finalmente, o processo de visualizaca~o e formado pelas operac~oes executadas durante

a visualizac~ao do ambiente, reconstruindo sua func~ao de luminosidade. O processo ideal
deve gerar amostras foto-realsticas com a menor latência possvel, ou seja, minimizando
o tempo entre as ac~oes do usuario e a resposta do ambiente virtual.
Esses processos s~ao executados de modos distintos para metodos de renderizac~ao baseada em geometria e baseada em imagens, de acordo com as diferencas no esquema de
representac~ao utilizado.
2.5.1 Metodos de Renderizac~ao Baseada em Geometria
A Figura 2.2 ilustra os processos de autoria, armazenamento e visualizac~ao de ambientes nos metodos de renderizac~ao baseada em geometria. No diagrama, as caixas
retangulares indicam os dados e objetos, as areas elpticas indicam as operaco~es aplicadas
a esses dados, e os losangulos indicam os parâmetros fornecidos para as operac~oes.
Leis Fisicas
Objetos e
interacoes do
mundo Real
Modelagem
Dados Armazenados
Modelos geometricos
Modelos de
iluminacao
Sintese
Imagem do ambiente
Amostra da funcao
de luminosidade
Transformacoes
Geometricas
Parametros de
Visualizacao
Autoria
Visualizacao
Figura 2.2: Os processos de modelagem, armazenamento e visualizac~ao utilizando representac~oes baseadas em geometria.
Os tipos de dados centrais nesses metodos s~ao os modelos geometricos e os modelos de
iluminac~ao. Esses modelos aparecem no centro do diagrama e todas as operac~oes, sejam
elas de autoria, de armazanamento ou de visualizac~ao, s~ao aplicadas a esses dados.
As operac~oes de modelagem s~ao responsaveis pela criaca~o dos modelos dos objetos
no ambiente e dos modelos de iluminac~ao obtidos a partir de leis fsicas. Atraves da
modelagem, o autor do ambiente virtual cria toda a descrica~o algortmica da func~ao de
luminosidade deste ambiente que sera utilizada no processo de visualizac~ao para reconstruir essa func~ao.
Essas operac~oes s~ao tipicamente manuais, ou seja, um usuario utiliza programas de
modelagem para especicar cada detalhe do ambiente virtual. Os programas geralmente
oferecem um conjunto de primitivas basicas que o autor pode combinar de diversas formas para criar o ambiente virtual, embora esse processo manual dicilmente permite a
criac~ao de uma boa descric~ao da geometria complexa do mundo real. Alternativamente,
12
a modelagem pode ser feita automaticamente atraves de um scanner 3D, onde feixes de
laser s~ao utilizados para medir a posic~ao de objetos em diversos pontos.
As operac~oes de visualizac~ao, indicadas por sntese no diagrama, utilizam a descric~ao
algortmica criada durante o processo de modelagem para executar a simulaca~o fsica de
iluminac~ao e reconstruir a funca~o de luminosidade do ambiente. A amostra gerada depende dos parâmetros fornecidos pela navegaca~o do usuario. Uma parte dessas operac~oes
s~ao executadas repetidamente para cada passo do usuario e dessa forma precisam ser
empregadas a taxas interativas, o que limita a complexidade da simulac~ao que pode ser
utilizada e impede a utilizac~ao de alguns metodos de simulac~ao mais precisos.
Em grande parte dos sistemas gracos com visualizac~ao em tempo-real, os dados
passados para visualizaca~o s~ao um conjunto de malhas poligonais representando a fronteira
de cada objeto em seu proprio sistema de coordenadas, as propriedades dos materiais
que formam cada superfcie e as transformaco~es que posicionam cada objeto no mundo.
Dentre as operac~oes de visualizac~ao, que s~ao implementadas pelos sistema gracos, est~ao
as transformac~oes de visualizac~ao, a operaca~o de clipping, os calculos de iluminaca~o, entre
outros.
As operac~oes que classicamos como operac~oes de armazenamento, s~ao as operac~oes
que transformam os modelos utilizados durante a modelagem para modelos apropriados
para armazenamento e transformam esses para modelos apropriados para visualizac~ao.
Essas operac~oes s~ao importantes pois diversas representac~oes geometricas diferentes
podem ser utilizadas para o mesmo objeto matematico (Foley et al. , 1987). Frequentemente, a melhor representaca~o para a modelagem n~ao e a melhor para a visualizac~ao, e
provavelmente n~ao sera a mais apropriada para armazenamento. Por exemplo, mencionamos anteriormente que as operaco~es de visualizaca~o recebem tipicamente como entrada
um conjunto de malhas poligonais. Essa representaca~o, no entanto, e inapropriada para
modelagem, pois exigiria que todos os vertices de cada polgono fossem especicados pelo
usuario. Uma representac~ao CSG torna o processo de modelagem muito mais simples e
intuitivo.
Agora que discutimos o processo de autoria, armazenamento e visualizac~ao nos metodos
de renderizac~ao baseada em geometria, vamos discutir os mesmos processos para os
metodos de renderizaca~o baseada em imagens.
2.5.2 Metodos de Renderizac~ao Baseada em Imagens
A Figura 2.3 ilustra o diagrama dos processos de autoria, armazenamento e visualizac~ao de ambientes nos metodos de renderizaca~o baseada em imagens.
Todos os metodos baseados em imagens s~ao variaco~es de tecnicas de amostragem e reconstruc~ao da func~ao de luminosidade (ou func~ao de luminosidade estendida) do ambiente
virtual. Eles diferem quanto a densidade de amostragem em cada parâmetro, quanto aos
ltros de reconstruc~ao que utilizam, se usam a funca~o de luminosidade estendida ou n~ao,
entre outros. No proximo captulo veremos em maiores detalhes como alguns trabalhos
efetuam amostragem e reconstruc~ao. Em ambas etapas, os dados centrais s~ao amostras
da func~ao de luminosidade (ou funca~o de luminosidade estendida). Isso indica um fato
importante sobre os metodos de renderizaca~o baseada em imagens, as operac~oes s~ao sempre aplicadas no referencial das imagens utilizadas, ao inves de um referencial global do
ambiente.
As operac~oes de sensoriamento, executadas durante a autoria, s~ao as reponsaveis por
13
Analise
Objetos e
interacoes do
mundo Real
Sensoriamento
Imagens do Ambiente
Amostras da Funcao
de Luminosidade
Deformacao
Imagem do ambiente
Amostra da funcao
de luminosidade
Dados Armazenados
Parametros de
Visualizacao
Autoria
Visualizacao
Figura 2.3: Os processos de modelagem, armazenamento e visualizac~ao utilizando representac~oes baseadas em imagens.
amostrar a func~ao de luminosidade. Para ambientes reais, essas operaco~es s~ao executadas
por câmeras fotogracas ou de vdeo. Para ambientes modelados, essas operac~oes s~ao
executadas por câmeras virtuais (falaremos mais adiante da possibilidade de se utilizar
tecnicas de renderizac~ao baseadas em imagens para representar ambientes modelados). O
numero de amostras que devem ser obtidas depende do metodo de reconstruc~ao utilizado,
ou seja, das operac~oes de visualizac~ao.
Em geral, quanto mais densa for a amostragem, melhor sera a qualidade da func~ao
reconstruda. No entanto, o aumento da densidade pode tornar inviavel a quantidade
de dados que deve ser armazenado, pois cada amostra e representada por uma imagem
digital. Para tentar reduzir a quantidade de armazenamento, sem piorar a qualidade,
alguns metodos aplicam operaco~es durante o processo de armazenamento das amostras
que chamamos de operac~oes de analise. Essas operaco~es s~ao geralmente tecnicas de vis~ao
computacional aplicadas para determinar relac~oes entre as amostras, que s~ao essenciais
para o processo de visualizaca~o. Tipicamente essas relac~oes incluem informac~oes como
as partes de duas amostras que representam os mesmos pontos do ambiente, o posicionamento relativo entre as câmeras que geraram cada amostra, entre outras. E possivel
tambem que essas informac~oes sejam fornecidas durante a fase de sensoriamento.
Finalmente, a fase de visualizac~ao recontroi a funca~o de luminosidade interpolando
entre amostras armazenadas para criar uma nova amostra da funca~o de luminosidade,
dependente da posic~ao do observador. Esse processo de interpolac~ao deforma as amostras
originais e combina os resultados, como veremos com mais detalhes adiante.
Ao longo da discuss~ao de ambas as abordagens, apresentamos algumas de suas vantagens e desvantagens. Os metodos baseados em geometria s~ao limitados pela complexidade
da simulac~ao, pois essa deve ser executada a taxas interativas. Isso e uma desvantagem
quando se deseja resultados foto-realsticos. Os metodos baseados em imagens podem produzir resultados mais foto-realsticos para pequenas regi~oes do ambiente. Esses metodos,
porem, s~ao limitados pela quantidade de dados que deve ser armazenado, ja que esta
14
aumento muito com o numero de vistas reconstrudas. Nos metodos baseados em geometria isso n~ao ocorre. Uma vantagem adicional desses metodos e a facilidade com que
o ambiente virtual pode ser modicado, o que e feito modicando-se algum modelo da
descric~ao algortmica. Nos metodos baseados em imagens isso geralmente exige que se
reamostre grande parte do ambiente.
Dadas essas vantagens e desvatagens, e importante discutirmos como essas abordagens podem ser integradas, convertendo entre os diferentes tipos de descrica~o, para criar
metodos hbridos.
2.5.3 Convers~ao entre Descric~oes e Metodos Hbridos
A possibilidade de converter dados entre esses dois conjuntos de metodos, permite que
se utilize metodos hbridos, que possam se aproveitar das vantagens de cada abordagem.
O melhor exemplo de um metodo deste tipo e a utilizaca~o da renderizaca~o baseada em
imagens para visualizar ambientes modelados geometricamente. Nesse caso a convers~ao
e simples. Analizando a Figura 2.2 vemos que o resultado dos metodos baseados em
geometria e uma amostra da func~ao de luminosidade, que pode ser armazenada e posteriormente visualizada utilizando os processos baseados em imagens. Como veremos no
proximo captulo um numero de trabalhos tomam essa abordagem (Darsa et al. , 1996)
(Mark et al. , 1997).
Outra possibilidade seria fazer a convers~ao na direc~ao oposta. A partir de amostras
da func~ao de luminosidade criar modelos geometricos do ambiente gerando uma descric~ao
algortmica da sua func~ao de luminosidade. As amostras podem inclusive ser utilizadas
como textura dos modelos. Esse tipo de convers~ao e bastante complicada de ser efetuada automaticamente. No proximo captulo veremos alguns trabalhos que utilizam uma
abordagem deste tipo que chamamos de modelagem baseada em imagens.
2.6 Considerac~oes Finais

Nesse captulo, zemos uma conceituaca~o dos metodos de renderizaca~o baseada em
imagens e baseada em geometria. Esperamos que atraves dessa conceituac~ao tenha cado
claro para o leitor as diferencas fundamentais entre essas abordagens. Esperamos tambem
que o leitor tenha uma ideia de como funciona os processos de autoria, armazenamento
e visualizac~ao de ambientes virtuais utilizando a renderizac~ao baseada em imagens. No
proximo captulo falaremos especicamente de alguns dos principais trabalhos que têm
contribudo para essa area, mostrando como executam cada um desses processos.
Captulo 3
Renderizac~ao Baseada em Imagens
No captulo anterior, apresentamos uma conceituaca~o da area de renderizac~ao baseada em imagens e mostramos, em linhas gerais, os processos de autoria, armazenamento
e visualizaca~o de ambientes, comparando as abordagens baseadas em imagens e em geometria. Mostramos que todos os metodos baseados em imagens resolvem o problema de
amostragem e reconstruca~o da funca~o de luminosidade. Neste captulo vamos abordar em
maiores detalhes alguns trabalhos importantes dessa area, que demonstram as principais
linhas de pesquisa.
3.1 Origens
Conforme ja mencionamos, os metodos de renderizac~ao baseada em imagens surgiram
principalmente a partir da combinac~ao de tecnicas de Computaca~o Graca e Vis~ao Computacional. Embora grande parte dessas tecnicas ja seja conhecida ha muito tempo, sua
utilizac~ao conjunta para visualizac~ao de ambientes virtuais so foi possvel recentemente,
gracas ao avanco dos equipamentos gracos, em particular do hardware de mapeamento
de textura.
3.1.1 Computac~ao Graca
As principais contribuico~es da Computaca~o Graca nos metodos de renderizac~ao baseada em imagens s~ao as tecnicas de mapeamento de textura e deformaca~o de imagens,
utilizadas para reconstruc~ao da func~ao de luminosidade (ver Figura 2.3 ).
Greene (Greene, 1986) foi o primeiro a propor a utilizaca~o de tecnicas de mapeamento
de textura para a representac~ao e visualizaca~o de ambientes virtuais. Neste trabalho
ele mostra que um conjunto de fotograas tiradas de um ponto do ambiente pode ser
mapeada em uma superfcie em torno deste ponto de tal forma que vistas arbitrarias
podem ser reconstrudas visualizando essa superfcie. Esse metodo e bastante semelhante
as panoramas virtuais, que veremos adiante, mas provavelmente n~ao teve tanto impacto
pela diculdade de executar a visualizaca~o em tempo real com equipamentos da epoca.
Outro trabalho que menciona a utilizac~ao da deformac~ao de imagens para a visualizac~ao de ambientes virtuais e a tese de mestrado de Heckbert (Heckbert, 1989). Esta
tese contem uma boa apresentac~ao das tecnicas de deformaca~o de imagens para mapeamento de textura e grande parte dos algoritmos de deformaca~o utilizados nos metodos de
~ BASEADA EM IMAGENS
CAPITULO 3. RENDERIZACAO
16
renderizac~ao baseada em imagens s~ao apresentados neste trabalho.
3.1.2 Vis~ao Computacional
As tecnicas de vis~ao computacional s~ao bastante utilizadas para analise de imagens

em alguns metodos de renderizac~ao baseada em imagens (ver Figura 2.3). Essas tecnicas
s~ao empregadas antes da visualizaca~o para estabelecer relac~oes entre as imagens que
determinam como essas devem ser deformadas para reconstruc~ao. Por esse motivo, o
modelo de câmera geralmente utilizado nesses metodos e o modelo empregado em grande
parte dos trabalhos de Vis~ao Computacional, e difere um pouco do modelo utilizado na
Computac~ao Graca (Faugeras, 1993). Dentre as ferramentas da Vis~ao Computacional
mais utilizadas, podemos citar a teoria da geometria epipolar (Faugeras & Robert, 1995).
Alguns trabalhos desenvolvidos na area de Vis~ao Computacional podem inclusive ser
considerados trabalhos de renderizac~ao baseada em imagens, pois criam vistas de um
ambiente virtual, em pontos arbitrarios, a partir de um numero de amostras iniciais. Em
(Laveau & Faugeras, 1994) os autores utilizam a geometria epipolar de duas amostras para
deformar os pixels correspondentes e criar uma terceira vista em um ponto arbitrario. O
metodo proposto, no entanto, e um pouco ineciente, o que diculta sua utilizac~ao para
visualizac~ao em tempo real de ambientes virtuais.
3.2 Renderizac~ao Baseada em Imagens

Como vimos no captulo anterior, os metodos de renderizaca~o baseada em imagens
efetuam amostragem e reconstruca~o da funca~o de luminosidade de um ambiente virtual.
Essas duas etapas s~ao, naturalmente, interdependentes, ou seja, a densidade e extens~ao
de amostragem em cada parâmetro determina o tipo de reconstruc~ao que pode ser feita, e
vice-versa. Esses fatores determinam as vistas do ambiente que podem ser reconstrudas e,
consequentemente, o tipo de navegaca~o que o usuario podera fazer no ambiente. Devido ao
grande numero de parâmetros dessa func~ao, diversas combinac~oes de densidade e extens~ao
de amostragem podem ser utilizadas, muitas das quais ainda n~ao foram utilizadas em
nenhum trabalho. Os metodos que vamos apresentar podem ser classicados segundo o
tipo de amostragem e funca~o de interpolac~ao que utilizam.
Os metodos mais simples de amostragem e reconstruc~ao s~ao os metodos de ponto de
observac~ao xo. Esses metodos permitem ao usuario visualizar o ambiente em qualquer
direc~ao a partir de um unico ponto, ou seja, tem apenas dois graus de liberdade para
rotac~ao. Geralmente o usuario tambem pode "pular"entre pontos de observaca~o, o que
corresponde a uma amostragem densa nos parâmetros (; ) e esparsa nos parâmetros
(Vx; Vy ; Vz ).
A extens~ao desses metodos para reconstruir vistas de qualquer ponto (oferecendo ao
usuario mais graus de liberdade para translac~ao) e bem mais complexa. A reconstruc~ao
correta da func~ao pela interpolac~ao de amostras de pontos de vista diferentes depende da
forma dos objetos no ambiente. Essa reconstruca~o geralmente e feita deformando-se duas
ou mais imagens e combinando-as, mas, para pontos de vista distintos, essas deformac~oes
dependem da distância entre o ponto de observac~ao e os pontos visualizados do ambiente.
Considerando esse fato, diferentes abordagens foram propostas para permitir a translac~ao do usuario. Uma soluca~o trivial, mas inviavel, e amostrar o ambiente em todos os
17
pontos de vista. Alguns trabalhos aproximam essa soluca~o realizando uma amostragem
bastante densa do ambiente. Dessa forma, a distância entre as amostras e t~ao pequena que
ao ignorar-se a geometria do ambiente, erros mnimos s~ao introduzidos. Isso e importante
ja que muitas vezes essa geometria n~ao esta disponvel.
Quando a amostragem e feita em ambientes virtuais sinteticos, cada amostra pode ser
armazenada juntamente com seu z-buer (Foley et al. , 1987). Essa informac~ao adicional
permite uma boa reconstruca~o para amostragens pouco densas. Um numero de trabalhos
que iremos apresentar utilizam essa abordagem.
Por outro lado, quando as amostras s~ao obtidas de um ambiente real, o z-buer n~ao
esta disponvel. Nesse caso, a soluc~ao e estimar a profundidade para cada pixel das
amostras, ou seja, estimar o z-buer. Isso pode ser feito desde que se conheca pixels em
mais de uma amostra que correspondem ao mesmo ponto do ambiente. Na realidade, os
metodos que utilizam essa abordagem n~ao estimam o z-buer diretamente, mas utilizam
as proprias correspondências para efetuar a reconstruc~ao em amostragens pouco densas.
Veremos agora alguns trabalhos que utilizam cada uma dessas abordagens.
3.2.1 Visualizac~ao de Ponto de Vista Fixo
Os metodos de visualizac~ao de ponto de vista xo fazem uma amostragem e reconstruc~ao da func~ao de luminosidade em um unico ponto do ambiente. Com isso, essa func~ao
passa a ter dois parâmetros apenas, que denem a direca~o de visualizac~ao: l = L(; ).
Cada direc~ao dene uma unica reta passando pelo ponto de vista, ou seja, essa funca~o de
luminosidade leva o feixe R de retas passando por esse ponto em valores de radiância:
L:R!R
l = L(R)
Diversas parametrizac~oes podem ser utilizadas para a conjunto R. Uma dessas parametrizac~oes, que chamamos de panorama virtual, utiliza uma superfcie parametrica
S ao redor do ponto de observaca~o. Cada reta R intercepta essa superfcie em um
unico ponto P = S (u; v). Dessa forma, a func~ao de luminosidade pode ser da forma
l = L(S (u; v)) = L0 (u; v). A funca~o L0 associa a cada ponto (u; v) do espaco de parâmetros
de S a cor do ambiente na direca~o de P = S (u; v) (ver Figura 3.1).
R
P = S(u,v)
Figura 3.1: Parametrizacao baseada em panoramas.

A vantagem dessa parametrizaca~o e que a associaca~o de um ponto da supefcie com
uma cor (radiância) pode ser feita mapeando-se uma imagem na superfcie. Assim, pa-
18
ra reconstruir a func~ao de luminosidade, a superfcie mapeada e visualizada utilizando

tecnicas de mapeamento de textura. Chamamos a superfcie S de superfcie panorâmica.
Os sistemas de panoramas virtuais s~ao o principal assunto desta dissertac~ao. Dessa
forma n~ao entraremos em maiores detalhes aqui sobre o seu funcionamento, mas dedicamos
o proximo captulo para esses sistemas.
3.2.2 Visualizac~ao por Amostragem Densa
Os metodos de visualizac~ao por amostragem densa (Gortler et al. , 1996) (Levoy

& Hanrahan, 1996) generalizam as panoramas virtuais permitindo que o ambiente seja
visualizado de qualquer ponto de vista, ou seja, utilizam todos os parâmetros da func~ao
de luminosidade. A grande densidade de amostragem faz com que qualquer ponto do
ambiente esteja bem proximo de alguma amostra, o que facilita a reconstruc~ao. Essa
abordagem aproxima uma soluca~o em que todos os pontos do ambiente seriam amostrados.
Nos trabalhos que vamos discutir, a funca~o de luminosadade possui quatro parâmetros
apenas, pois quando o usuario se move na direca~o de visualizaca~o, o valor da func~ao n~ao
muda. Enquanto Levoy e Hanrahan. (Levoy & Hanrahan, 1996) chamam essa func~ao de
Light Field, Gortler et al. (Gortler et al. , 1996) chamam de Lumigraph.
O Lumigraph (ou Light Field) leva uma reta generica do espaco em um valor de radiância. Assim como no caso das panoramas virtuais, diversas parametrizaco~es podem ser
utilizadas para representar esse conjunto de retas. Os trabalhos mencionados parametrizam o conjunto de retas atraves de um par de planos paralelos, pois cada reta do espaco
intercepta cada plano em um unico ponto (a menos das retas paralelas aos planos). Seja
(s; t) e (u; v) a parametrizac~ao de cada plano, ent~ao um reta l0 pode ser representada pela
tupla (u0; v0; s0; t0) (ver Figura 3.2).
Naturalmente, um unico par de planos n~ao e capaz de representar todas as retas do
espaco (as retas paralelas aos planos n~ao os intercepta em um unico ponto) e, alem disso,
geralmente se trabalha com um pequeno intervalo do espaco de parâmetros dos planos
(e.g. [0; 1] [0; 1]). Por esse motivo, frequentemente se utiliza mais de um par de planos.
Gortler et al. apresenta diversas conguraco~es possveis, apresentando situaco~es onde
cada uma deve ser utilizada.
l
(s,t)
t
(u,v)
v
u
Figura 3.2: Parametrizacao do conjunto de retas do espaco.

A associac~ao entre as amostras da func~ao de luminosidade e esses parâmetros e feita
19
de modo que, a cada par (s; t) corresponde uma posica~o de câmera e a cada par (u; v),
uma direc~ao de visualizac~ao. Com isso, a amostragem da func~ao de luminosidade e feita
tirando-se varias fotograas nos pontos do grid (s; t) de tal forma que cada pixel de cada
fotograa esta associado a um valor de (u; v), como podemos ver na Figura 3.3, que ilustra
os planos (s; t) e (u; v) vistos de cima.
Objeto
(u,v)
1 pixel
(s,t)
Figura 3.3: Amostragem da funca~o de luminosidade.

Essa amostragem pode ser feita sem diculdades para ambientes modelados. No caso
de ambientes reais, o processo e mais complexo, pois e necessario que se conheca a congurac~ao da câmera para um grande numero de imagens. Gortler at al. descrevem um
esquema baseado em uma plataforma com padr~oes de cores para determinar a posic~ao
de câmera durante a captura de amostras em torno de um objeto. Ja Levoy e Hanrahan
utilizam um aparato mecânico controlado por computador que posiciona a câmera em
posic~oes conhecidas.
Diversos ltros de reconstruca~o podem ser utilizados para gerar uma nova amostra da
func~ao durante a visualizac~ao, alguns dos quais s~ao discutidos em ambos os trabalhos.
Como essa reconstruc~ao e feita a taxas interativas, e importante que a reconstruca~o utilize
o hardware de mapeamento de textura quando disponivel. No caso da reconstruc~ao com
o ltro box, isso pode ser feito como ilustrado na Figura 3.4. Dada a posica~o da câmera
virtual, determina-se quais os pontos do grid (s; t) sendo visualizados, pois esses pontos
indicam as amostras que contribuem para a vista corrente. A regi~ao desse plano associada
a cada ponto e projetada na tela da câmera virtual utilizando como textura a imagem no
plano (u; v) associada a essa amostra (ver Figura 3.4).
Para que o esquema de reconstruc~ao obtenha resultados visualmente corretos e necessario que a amostragem seja densa n~ao so no plano (u; v) mas tambem no plano (s; t).
Desta necessidade resulta o maior problema desses metodos, que e a grande quantidade de
dados armazenados. Levoy e Hanrahan prop~oem um algoritmo de compress~ao e armam
que pode-se atingir um fator de compress~ao de ate 200:1 sem defeitos notaveis nos resultados. Apesar disso, a quantidade de dados armazenados continua sendo muito grande
e, como nem toda a descompress~ao pode ser executada em tempo real, a capacidade de
armazenamento em tempo de execuc~ao e ainda maior.
20
(u,v) s ,t
o
o
(s,t)
so
Figura 3.4: Visualizac~ao utilizando representaca~o por slabs.
3.2.3 Visualizac~ao por Amostragem da Func~ao de Luminosidade

Estendida
Para diminuir a quantidade de dados armazenados pelos metodos anteriores, diversos

metodos foram propostos que efetuam uma amostragem menos densa. Em linhas gerais,
esses metodos partem de duas ou mais imagens de referência, obtidas de conguraco~es de
câmera distintas, as câmeras de referência, e geram uma imagem correspondente a uma
nova congurac~ao de câmera, a câmera destino. Para isso, aplicam uma deformac~ao a
cada uma das imagens de referência gerando uma nova imagem que aproxima o que seria
visto atraves da câmera destino. As imagens deformadas s~ao ent~ao combinadas por uma
operac~ao de composic~ao.
A deformac~ao que deve ser aplicada as imagens de referência depende da forma dos objetos da cena, pois o vetor de deslocamento de cada pixel da imagem durante a deformac~ao
depende n~ao so do movimento da câmera, mas tambem da sua profundidade ao longo do
raio de vis~ao. Para ambientes sinteticos, onde a profundidade em cada pixel e conhecida
(z-buer), essas deformac~oes podem ser calculadas automaticamente. Os metodos que
utilizam essa informac~ao de profundidade, amostram a funca~o de luminosidade estendida.
Chen e Williams (Chen & Williams, 1993) utilizam essa abordagem para gerar uma
nova vista de um ambiente, intermediaria entre duas vistas de referência. Em uma etapa
de pre-processamento a profundidade e utilizada para determinar os pixels correspondentes nas duas imagens, ou seja, pixels que ilustram o mesmo ponto do ambiente. Essa
informac~ao e utilizada para gerar um mapa de disparidades, como se pode ver na Figura
3.5.
Seja v um vetor do mapa de disparidades correspondente ao pixel p. Para gerar uma
nova imagem Is resultado da interpolaca~o linear das imagens originais: Is = I0 s +
(1 , s) I1 , cada pixel p e deslocado de s v e seu correspondente de ,(s , 1) v.
As duas imagens resultantes s~ao ent~ao compostas gerando a imagem nal. Note que
a transformac~ao correta que deve ser aplicada a cada pixel para gerar a nova imagem e
uma transformac~ao projetiva, que esta sendo aproximada nesse caso por uma interpolaca~o
linear. Os autores mostram que, no caso de câmeras paralelas, essa aproximaca~o e exata
e, mesmo no caso em que as câmeras n~ao s~ao paralelas e a rotaca~o relativa entre elas n~ao
e muito grande, a interpolac~ao linear apresenta resultados visualmente satisfatorios.
21
Figura 3.5: Mapa de disparidades de uma imagem em relac~ao a outra (Imagem obtida do
trabalho de Chen e Williams).
Para otimizar a visualizaca~o, uma outra aproximaca~o e feita. Pixels proximos com
vetores de disparidades proximos s~ao agrupados em blocos que passam a ter um unico
vetor de disparidades. Dessa forma, um numero menor de deformac~oes tem que ser
efetuado.
Darsa et al. (Darsa et al. , 1997) tambem reconstroem vistas arbitrarias de ambientes
virtuais modelados utilizando imagens com profundidades. Utilizam, no entanto, uma
abordagem um pouco diferente de Chen e Williams, pois trabalham com a informac~ao 3D
diretamente e utilizam panoramas virtuais cubicas.
O metodo recebe como entrada um conjunto de imagens correpondentes a diferentes
faces da panorama cubica e a profundidade em cada pixel. A imagem com profundidade
pode ser considerada como amostras de uma superfcie e um algoritmo de triangulac~ao e
empregado para aproxima-la por uma superfcie linear por partes. Esse algoritmo e uma
adaptac~ao do algoritmo de Delaunay que considera a profundidade para gerar uma boa
aproximac~ao (ver Figura 3.6). As malhas de triangulos geradas s~ao ent~ao projetadas para
3D e representadas como se fossem objetos poligonais do ambiente.
Figura 3.6: Triangulaca~o a partir de uma imagem com profundidade (Imagem obtida do
trabalho de Darsa et al.).
No caso em que existe apenas uma malha, a criaca~o de uma vista arbitraria e feita
22
utilizando-se os metodos tradicionais de computaca~o graca 3D para visualizar essa malha com a imagem mapeada como textura. Quando existem mais de uma malha, essas
devem ser compostas de modo a gerar uma vista correta em termos de visibilidade. Os
autores apresentam quatro metodos de composic~ao de malhas com textura e comparam
os resultados obtidos com cada um.
3.2.4 Visualizac~ao por Analise de Amostras da Func~ao de Luminosidade
Os metodos anteriores reconstroem a funca~o de luminosidade a partir de uma amostragem esparsa da func~ao estendida. Em muitos casos, porem, so est~ao disponveis amostras
da func~ao de luminosidade, ou seja, sem informaca~o de profundidade. Isso ocorre por
exemplo, quando as amostras s~ao obtidas do mundo real. No entanto, vimos que no
metodo de Chen e Williams a profundidade e utilizada para calcular a correspondência
entre os pixels e, a partir dessas, estimar o vetor do deslocamento que cada pixel sofre
durante a deformac~ao para reconstruca~o. Quando a profundidade n~ao esta disponvel,
esse metodo pode ainda ser utilizado desde que as correspondências possam ser estimadas
diretamente. Alguns metodos utilizam essa abordagem aplicando alguma forma de analise
sobre as amostras para estima-las. Esses metodos s~ao tipicamente semi-automaticos, pois
exigem que o usuario especique um numero de correspondências iniciais manualmente.
Veremos agora alguns desses trabalhos.
Seitz and Dyer (Seitz, 1996) desenvolveram um trabalho para resolver o seguinte problema: dadas duas imagens I0 e I1 de um objeto, obtidas por congurac~oes de câmera
C0 e C1, gerar uma nova imagem Is que corresponde a uma congurac~ao de câmera Cs
que seja intermediaria entre C0 e C1 (ver Figura 3.7). O metodo por eles proposto e
chamado de view-morping, e assume que as conguraco~es de câmera s~ao todas conhecidas
(posteriormente exibilizam o metodo para o caso em que apenas a geometria epipolar
entre as imagens e conhecida).
I
I
1
Is
C
1
Figura 3.7: View morphing permite que a imagem Is seja gerada a partir de I0 e I1.
No caso especco em que as câmeras C0 e C1 s~ao paralelas, eles mostram que a
nova imagem e o resultado de uma interpolac~ao linear entre as imagens originais. Ou
seja, o vetor de deslocamento da deformac~ao que deve ser aplicada a cada pixel das
23
imagens originais e obtido por escalamento do vetor que liga os pixels correspondentes.
Sendo assim, prop~oem um metodo para gerar a nova imagem no caso paralelo, onde o
usuario especica um numero de pixels correpondentes nas duas imagens, que geralmente
equivalem a pontos notaveis do objeto. A partir da um algoritmo de morphing tradicional
e empregado que interpola linearmente as correspondências especicadas aproximando o
vetor de deslocamento para os demais pixels. Por exemplo, uma triangulaca~o da imagem
pode ser feita onde os vertices dos triângulos s~ao os pixels correspondentes e a deformac~ao
aplicada e o resultado de uma interpolac~ao linear desses vertices. Apos essa deformac~ao,
as duas imagens s~ao compostas atraves de um blending.
O caso mais geral, onde as câmeras n~ao s~ao paralelas, e reduzido a este caso especial
atraves de uma pre-deformac~ao de reticaca~o (Faugeras, 1993). Assim, o algoritmo e
executado em três etapas. A primeira e a pre-deformaca~o de reticac~ao, que leva as
imagens I0 e I1 em Î0 e Î1 (Figura 3.8(a) ). A segunda e a intepolac~ao entre as imagens
paralelas Î0 e Î1, gerando Îs (Figura 3.8(b) ). A terceira e uma pos-deformac~ao que
modica a imagem para ter a orientac~ao da câmera Cs. (Figura 3.8(c) ).
I
I
0
I
1
I
0
(a)
I
I
I
1
C
1
0
s
C
s
(b)
I
s
(c)
Figura 3.8: Pre-deformaca~o (a) Interpolac~ao (b) e Pos-deformaca~o (c).

O metodo proposto apresenta problemas relativos a visibilidade de pontos do objeto. Os autores introduzem uma restrica~o, que chamam de restric~ao de monotonicidade,
que, quando satisfeita, garante o funcionamento correto do metodo. Basicamente, essa
24
restric~ao garante que nenhuma face do objeto visvel de uma das imagens originais esteja
escondida na outra. E o que Faugeras chama de restric~ao de ordenac~ao (Faugeras, 1993).
A Figura 3.9 ilustra um dos resultado da aplicac~ao do metodo.
Figura 3.9: Resultado da aplicac~ao do view-morphig a duas imagens (Imagem obtida do

trabalho de Seitz e Dyer).
McMillan e Bishop (McMillan & Bishop, 1995b) utilizam uma abordagem parecida
para o caso da panoramas virtuais cilndricas. Nesse caso, s~ao dadas duas panoramas
virtuais, de pontos distintos do ambiente, e uma nova panorama e calculada de um novo ponto. Novamente, o usuario deve especicar manualmente um pequeno numero de
correspondências nas duas imagens panorâmicas. A partir dessas correspondências, um
metodo de otimizac~ao e empregado para determinar a posic~ao relativa entre os centros de
ambos os cilindros minimizando a distância d entre os raios gerados pelos pixels correspondentes p e p0. A distância resultante entre os centros de ambos os cilindros e chamada
de disparidade. (ver Figura 3.10).
d
Figura 3.10: Calculo da posic~ao relativa dos cilindros minimiza a distância d entre os
raios denidos pelos pixels correspondentes p e p'.
Ao contrario do trabalho de Seitz e Dyer, onde a correspondência e estimada para
os demais pixels da imagem por um algoritmo de morphing, aqui a correspondência e
calculada para cada pixel, gerando um mapa de disparidades. Esse calculo e feito atraves
de uma generalizac~ao da restric~ao epipolar utilizada em imagens stereo (Faugeras, 1993)
para o caso de imagens panorâmicas cilndricas. Dado um pixel em uma panorama, essa
restric~ao garante que o seu correspondente na outra pertence a uma curva conhecida, a
25
curva epipolar. Uma vez calculadas essas correspondências, essa mesma restrica~o e utilizada para interpolar os pixels correspondentes ao longo da curva epipolar, mais ou menos
como fazem Chen e Williams para o vetor deslocamento, gerando a imagem panorâmica
na nova posic~ao do cilindro.
Durante a deformac~ao, mais de um pixel pode ser levado a uma mesma posic~ao e
e preciso determinar qual deles deve ser desenhado. Os autores prop~oem um metodo
que sempre gera a visibilidade correta. Dada uma imagem de referência que deve ser
deformada para gerar uma imagem em um novo ponto de vista, se a geometria epipolar
entre as câmeras alvo e de referência for conhecida, os autores denem uma ordem de
pintura dos pixels de modo que os pixels pintados por ultimo s~ao garatidos de estarem
mais proximos do novo ponto de vista. Essa restric~ao de ordem de pintura e muito
utilizada em outros trabalhos em renderizac~ao baseada em imagens.
3.3 Modelagem Baseada em Imagens.

Enquanto os trabalhos apresentados na sec~ao anterior obtem imagens e as deformam
para criar novas vistas, Debevec et al. (Debevec et al. , 1996) prop~oem um metodo
que, de certa forma, faz a operaca~o inversa. A partir de um conjunto de fotograas de
um ambiente real, cria um modelo que aproxima os seus objetos e aplica tecnicas de
Computac~ao Graca 3D para visualizar esses modelos., utilizando as fotograas iniciais
como texturas. Esse metodo n~ao e propriamente um metodo de renderizac~ao baseada em
imagens como os demais apresentados nesse captulo, e sim um metodo de modelagem
baseada em imagens.
O sistema de Debevec et al. e especco para visualizaca~o de objetos arquiteturais,
como predios, igrejas, pontes, etc. O metodo se aproveita do fato de que modelos arquiteturais possuem uma geometria simples, geralmente composta de blocos, tetraedros
e outros solidos simples. O sistema modela o ambiente em dois passos. O primeiro passo
consiste na modelagem da geometria principal da cena, e o segundo rena esse modelo
para incluir os detalhes no primeiro modelo.
Na primeira etapa, o usuario cria um modelo basico da arquitetura utilizando primitivas simples, como blocos e tetraedros. Durante esse processo s~ao estabelecidas correspondências entre as arestas das primitivas e as arestas dos objetos nas diversas fotograas.
As primitivas podem ter restric~oes quanto as suas posic~oes e tamanhos relativos. Ao nal
deste processo, os parâmetros das primitivas (altura, largura, etc. ) n~ao est~ao necessariamente corretos. Esses parâmetros s~ao ajustados projetando o modelo nas fotograas
iniciais e aplicando um metodo de otimizac~ao ate que as correspondências especicadas
estejam proximas. Durante essa otimizac~ao, a posic~ao da câmera para cada fotograa
tambem e renada, usando como estimativa inicial uma posic~ao calculada por restric~oes
de linhas horizontais e verticais na imagem. A Figura 3.11 ilustra uma fotograa inicial e o modelo gerado. As arestas marcadas na imagem mostram as correspondências
especicadas entre a fotograa e o modelo.
Na segunda etapa da modelagem, os detalhes s~ao estimados utilizando metodos de
vis~ao estereo para calcular um mapa de profundidade de cada imagem original. Esses
metodos s~ao geralmente sujeitos a erros grosseiros pois utilizam apenas a correlaca~o entre
pixels nas duas imagens e n~ao têm como tratar problemas de oclus~ao. No caso deste
trabalho, o modelo criado pode ser utilizado, o que diminui a ocorrência desses problemas.
26
Figura 3.11: Modelo reconstrudo e uma das fotograas originais. As arestas do modelo realcadas na fotograa s~ao utilizadas no metodo de otimizac~ao (Imagem obtida do
trabalho de Debevec et al.).
Para determinar o mapa de disparidades de uma imagem, uma segunda imagem e mapeada
no modelo e visualizada do ponto de vista da primeira. A profundidade pode ent~ao ser
estimada pela disparidade entre os pixels das duas imagens. Note que neste metodo, a
estimativa do mapa de profundidades e apenas um renamento, o que o torna menos
sujeito a erros do que os metodos que dependem inteiramente dessa estimativa, como o
metodo de MacMillan e Bishop (McMillan & Bishop, 1995b).
Apos a criac~ao do modelo, este pode ser visualizado utilizando as fotograas iniciais
como textura. Isso pode ser feito facilmente pois a correspondência entre as faces do modelo e as fotograas foi especicada durante a modelagem. Um problema adicional e que
diversas fotograas est~ao disponveis para cada face do modelo, e nesse caso as fotograas
cujas direc~oes de visualizac~ao e posico~es est~ao mais proximas da vista sendo renderizada
devem ser utilizadas. A visualizac~ao e feita utilizando um metodo de mapeamento de
textura onde diversas imagens s~ao compostas de acordo com o ponto de vista . Cada
pixel da textura e uma media ponderada de pixels das diferentes fotograas onde o peso
depende do ângulo entre o ponto de vista, o ponto no modelo e a posica~o da câmera.
O mapa de profundidade de cada imagem tambem e utilizado na ponderac~ao embora os
autores n~ao expliquem como isso e feito.
3.4 Considerac~oes nais.

Apresentamos neste captulo alguns dos principais trabalhos que tem surgido na area
de renderizac~ao baseada em imagens. O objetivo deste captulo e dar uma vis~ao geral da
area, apresentando suas principais linhas de pesquisa. foi ilustrar as principais abordagens
que tem sido utilizada na area. N~ao entramos em muitos detalhes sobre cada trabalho,
mas apresentamos o que julgamos importante para mostrar suas principais contribuic~oes.
27
Um fato que podemos perceber ao estudar todos esses trabalhos e que grande parte dos
metodos propostos ainda possuem muitos problemas, que dicultam sua utilizac~ao em um
sistema de visualizac~ao de ambientes virtuais em tempo real. Uma excec~ao e o metodo de
visualizac~ao com ponto de vista xo, a panorama virtual, que ja e utilizado em um grande
numero de sistemas, alguns inclusive comerciais. Falaremos desses sistemas no proximo
captulo.
Captulo 4
Sistemas de Panoramas Virtuais
Nos dois captulos anteriores falamos da area de renderizaca~o baseada em imagens e
apresentamos as diferencas fundamentais entre essa area e a computaca~o graca baseada
em modelos. Mostramos tambem alguns dos principais trabalhos na area, ou pelo menos
aqueles que denem as principais linhas de pesquisa. A partir deste captulo, passamos a
tratar do assunto principal desta dissertac~ao, os sistemas de panoramas virtuais.
4.1 Panoramas Virtuais

Conforme ja mencionamos no captulo anterior, a panorama virtual e um metodo de
renderizac~ao baseada em imagens que permite a visualizaca~o de um ambiente a partir
de um ponto de observaca~o xo. Para esse tipo de visualizac~ao, deve ser conhecida a
cor do ambiente associada a cada direc~ao de visualizaca~o a partir de um ponto xo.
Nos sistemas de panoramas virtuais, essa associac~ao e representada por uma superfcie
parametrica ao redor deste ponto (e.g. um cilindro ). Como cada ponto na superfcie
corresponde a uma unica direca~o de visualizac~ao, pode-se associar a cor desta direc~ao a
esse ponto (ver Figura 3.1). A grande vantagem desta abordagem e que essa associac~ao
pode ser implementada mapeando-se uma imagem digital nessa superfcie, o que pode ser
feito utilizando alguma tecnica de mapeamento de textura (Heckbert, 1986). No restante
desta dissertac~ao chamamos essa superfcie de superfcie panorâmica e a imagem mapeada
de imagem panorâmica.
A amostragem do ambiente virtual consiste ent~ao em criar uma imagem panorâmica
que, quando mapeada na superfcie, representa corretamente a associac~ao entre cores e
direc~oes de visualizac~ao. Em outras palavras, essa imagem deve representar a projec~ao
do ambiente na superfcie, onde o centro de projec~ao e o ponto de observac~ao. A Figura
4.1 ilustra uma imagem panorâmica que representa a projec~ao de um ambiente em uma
superfcie panorâmica cilndrica.
A reconstruc~ao de vistas arbitrarias do ambiente a partir do ponto de observaca~o e feita
visualizando-se a superfcie panorâmica e a imagem mapeada com uma câmera virtual.
Diversos algoritmos podem ser utilizados para visualizar superfcies com mapeamento de
textura e o melhor algoritmo depende n~ao so do tipo de superfcie como dos requisitos
da aplicac~ao. Mais adiante neste captulo falaremos um pouco dos algoritmos utilizados
pelos sistemas existentes de panoramas virtuais e no Captulo 5 entramos em maiores
detalhes sobre esses algoritmos. A Figura 4.2 ilustra uma câmera virtual visualizando
CAPITULO 4. SISTEMAS DE PANORAMAS VIRTUAIS
29
Figura 4.1: Imagem panorâmica e seu mapeamento na superfcie panorâmica cilndrica.

uma imagem panorâmica em uma superfcie cilndrica.
Figura 4.2: Câmera virtual visualizando panorama cilndrica.

Segundo a discuss~ao anterior, os sistemas de panoramas virtuais possuem duas partes bem distintas. A primeira, que chamamos de ambiente de autoria, possui todas as
ferramentas necessarias para amostrar o ambiente virtual e a segunda, que chamamos de
modulo de visualizac~ao, possui os componentes para a sua visualizaca~o.
4.2 Autoria de Panoramas

A principal nalidade das ferramentas de autoria e a criac~ao das imagens panorâmicas
como projec~ao do ambiente virtual na superfcie panorâmica. O processo de criac~ao
dessas imagens depende do tipo de ambiente virtual e dos equipamentos e ferramentas
disponveis. Discutiremos aqui três casos: a criac~ao a partir de ambientes modelados
30
geometricamente, a partir de fotograas do mundo real, e a partir dessas fotograas com

auxlio de processamento digital de imagens. Em cada caso, falamos da criac~ao para
superfcies panorâmicas cubicas, esfericas e cilndricas, que s~ao as mais utilizadas.
4.2.1 Ambientes Modelados
A criac~ao de imagens panorâmicas a partir de ambientes modelados pode ser simples

ou bastante complexa, dependendo do tipo de superfcie utilizada. Quando a superfcie e
um cubo, por exemplo, essa operaca~o e bastante simples. Dene-se uma câmera virtual
cujo plano de imagem corresponde a uma das faces do cubo e renderiza-se o ambiente
com essa congurac~ao de câmera. As operaco~es de renderizaca~o s~ao as mesmas utilizadas
em geral na computaca~o graca, pois o modelo de câmera virtual utilizado e o mesmo (o
modelo "pinhole"(Faugeras, 1993)). O processo se repete para cada face do cubo, gerando
seis imagens panorâmicas correspondentes as faces do cubo.
No caso da superfcie cilndrica, o mesmo processo pode ser utilizado, aproximando-a
por faces retangulares. Alternativamente, pode-se utilizar um modelo de câmera virtual
onde o plano de imagem n~ao e plano, mas corresponde a superfcie de um cilindro (simulando uma câmera panorâmica, que discutiremos na proxima sec~ao). No caso da superfcie
esferica, a aproximac~ao por polgonos retangulares se torna mais complexa e a utilizac~ao
de um modelo de câmera esferico e mais apropriado.
Alguns programas comerciais de modelagem e animaca~o ja oferecem a opca~o de gerar
imagens panorâmicas cilndricas diretamente, dentre os quais podemos citar o KPT Brice
(KPTBryce, 1997) e o Strata Pro (StrataPro, 1997).
4.2.2 Fotograas do Mundo Real
A criac~ao de imagens panorâmicas a partir do mundo real, sem a utilizaca~o de processamento de imagens so e possvel com câmeras e lentes que projetem o ambiente nas superfcies utilizadas, que est~ao disponveis para as superfcies cubicas, esfericas e cilndricas.
No caso das superfcies cubicas, as imagens podem ser obtidas com lentes e câmeras
comuns. A câmera e posicionada com seu ponto nodal no centro de observaca~o, e seis
fotograas s~ao tiradas, cada uma com o plano de imagem paralelo a uma face distinta do
cubo. A grande diculdade neste processo e garantir que a abertura da lente seja tal que
n~ao hajam regi~oes em comum entre duas fotos e n~ao hajam buracos.
Para as superfcies cilndricas, utiliza-se uma câmera panorâmica (Malde, 1983), como
a ilustrada na Figura 4.3. Essa câmera possui uma pequena abertura vertical que permite
que uma faixa de luz inscida no lme e que gira 360 graus ao redor do ponto de observac~ao
registrando o ambiente ao longo do lme. O resultado e uma imagem panorâmica como a
ilustrada na Figura 4.4, que representa a projec~ao de um ambiente em um cilindro. Repare
que esse tipo de fotograa n~ao amostra todo o ambiente visto do ponto de observac~ao.
Vale aqui um comentario em relac~ao a nomenclatura. As câmeras panorâmicas, de 360
graus ou menos, tem sido utilizadas por fotografos desde o incio do seculo XIX. O tipo
de fotograa tirada por esse tipo de câmera, que projeta o ambiente em uma superfcie
cilndrica, e o que tem sido chamado de imagem panorâmica. Neste trabalho, no entanto,
generalizamos este termo para denotar imagens projetadas em qualquer tipo de superfcie,
e n~ao apenas a cilndrica. Esse nome nos pareceu o mais logico para esse tipo de imagem,
31
Figura 4.3: Câmera panorâmica modelo Roundshot produzido pela SEITZ Phototechnik.
Figura 4.4: Fotograa panorâmica cilndrica de 360 tirada da estac~ao de trem da Amtrak
c 1996.
em Oakland, CA, EUA. Design: VBN Associates, Oakland Foto: Andrew Van Dis
e esperamos que essa generalizaca~o n~ao confunda o leitor que esteja acostumado com a
nomenclatura utilizada em fotograa.
No caso das superfcies panorâmicas esfericas, deve-se utilizar uma lente "sheye",
como a que esta ilustrada na Figura 4.5. Essa lente possui um sistema otico que projeta
um semi-espaco do ambiente em um hemisferio (a Figura 4.6 ilustra uma fotograa obtida
com essa lente), de modo que duas imagens panorâmicas podem ser utilizadas amostrar
totalmente o ambiente a partir de um ponto. Como no caso do cubo, existe uma pequena
diculdade em casar as duas imagens corretamente.
Figura 4.5: Lente sheye de 6mm.

Os processos que acabamos de descrever possuem algumas desvantagens. O equipamento necessario para as superfcies esfericas e cilndricas e caro e pouco disponvel. Alem
disso, a captura das imagens deve ser bastante controlada, pois pequenos erros podem
gerar imagens panorâmicas visivelmente incorretas. Foram desenvolvidos ent~ao alguns
programas que utilizam processamento de imagens para facilitar esses processos.
32
Figura 4.6: Fotograa tirada com uma lente sheye.
4.2.3 Fotograas do Mundo Real com Auxlio de Processamento

Digital de Imagens
Alguns sistemas de panoramas virtuais existentes oferecem programas que utilizam

processamento de imagens para facilitar a criac~ao da imagem panorâmica, permitindo
que se utilize câmeras fotogracas com lentes comuns para tirar um numero de fotos ao
redor do ponto de observac~ao. Essas fotograas s~ao deformadas e compostas para criar a
imagem panorâmica, motivo pelo qual esses programas s~ao chamados de stitchers.
Nos sistemas comerciais atualmente disponveis, so existem stitchers para superfcies
panorâmicas cilndricas. Esses programas restringem no processo de obtenca~o das fotograas. A câmera fotograca deve ser colocada em um tripe nivelado horizontalmente e
de modo que possa girar em torno do seu ponto nodal. As fotograas s~ao ent~ao tiradas
em intervalos de ângulos regulares com alguma sobreposic~ao entre fotos adjacentes, como
esta ilustrado na Figura 4.7.
Figura 4.7: As fotograas s~ao tiradas a intervalos de a^ngulos regulares com sobreposic~ao.
33
As fotos tiradas desta forma s~ao passadas para o stitcher juntamente com informac~oes
adicionais, como o ângulo de abertura da lente e o intervalo angular entre fotos adjacentes.
Utilizando essas informaco~es, o stitcher aplica uma deformac~ao sobre as imagens que
equivale a projeta-las em um cilindro centrado no ponto nodal da câmera. Com isso,
as imagens passam a estar representadas no espaco de parâmetros do cilindro onde as
imagens deformadas podem ser transladadas para que as regi~oes de sobreposica~o casem
perfeitamente. Finalmente, as imagens s~ao compostas em uma unica imagem nal, que se
assemelha a fotograa obtida com uma câmera panorâmica. Esse algoritmo de composic~ao
foi primeiro apresentado na literatura por Szeliski (Szeliski, 1996) e e ilustrado na Figura
4.8 para duas fotos.
Figura 4.8: Composic~ao de duas imagens consecutivas.

Embora a criac~ao das imagens panorâmicas seja bastante facilitada pela utilizac~ao
desses programas, muitos problemas ainda existem. Primeiro, o processo de obtenc~ao
das fotograas ainda tem que ser bastante controlado, por causa das restrico~es impostas.
Na pratica, e difcil garantir essas restrico~es sem a utilizac~ao de um tripe especializado.
Outra limitac~ao e a necessidade de se conhecer os parâmetros da câmera, como a distância
focal e o ângulo de abertura, o que impossibilita a utilizaca~o de fotograas ja existentes.
Finalmente, o fato da câmera ter que car nivelada na horizontal limita a faixa angular
vertical onde o ambiente e amostrado.
Para resolver alguns desses problemas, Szeliski (Szeliski & Shum, 1997) propôs um
metodo que n~ao exige nenhum tipo de informac~ao sobre a câmera, e cuja unica exigência
e que esta gire em torno do seu ponto nodal. O seu metodo, no entanto, ainda apresenta
problemas quando as imagens n~ao est~ao muito proximas, sendo ideal para imagens obtidas
com uma câmera de video.
Finalizando nossa discuss~ao sobre autoria de panoramas, vale ressaltar uma das grandes vantagens dos metodos de renderizac~ao baseada em imagens, que e a possibilidade
de alterar o ambiente virtual desenhando sobre as imagens que amostram o ambiente,
nesse caso a imagem panorâmica. A rigor, a imagem panorâmica poderia ser totalmente
desenhada por um artista, desde que esse fosse capaz de incorporar ao desenho a deformac~ao apropriada para o tipo de superfcie panorâmica utilizada. Alternativamente, uma
imagem pode ser criada por algum metodo que apresentamos e o artista pode adicionar
ou retirar certos objetos. Por exemplo, a Figura 4.9(a) ilustra uma imagem panorâmica
recente do Rio de Janeiro visto do Morro do Corcovado. Na Figura 4.9(b) podemos ver
uma alterac~ao dessa imagem onde a artista retirou todos os sinais da cidade, criando um
ambiente virtual que representa o Rio de Janeiro antes do descobrimento do Brasil.
34
Figura 4.9: Imagem panorâmica da cidade do Rio de Janeiro vista do morro do Corcovado.
Foto: Andre Parente (a) A mesma imagem editada para simular o Rio de Janeiro antes
do descobrimento do Brasil. Edic~ao: Heloisa Siert (b)
4.3 Visualizac~ao de Panoramas

A reconstruca~o de vistas do ambiente e feita por uma câmera virtual, cujo centro
de projec~ao e posicionado no ponto de observac~ao para que a cena 3D projetada na
superfcie seja visualizada. Pela forma como a imagem panorâmica foi criada (projec~ao
do ambiente na superfcie utilizando o ponto de observac~ao como centro de projeca~o), a
imagem produzida pela câmera e uma vista do ambiente virtual.
A implementac~ao dessa visualizac~ao pode ser feita por dois metodos. No primeiro, a
superfcie e poligonizada e em cada polgono e mapeada uma parte da imagem panorâmica.
Esse e o metodo geralmente empregado na computac~ao graca 3D para visualizac~ao de
superfcies com mapeamento de textura.
O segundo metodo utiliza o fato de que a imagem panorâmica e uma imagem digital
2D que, ao ser projetada na superfcie e visualizada pela câmera virtual, gera uma nova
imagem 2D na tela. Assim, uma deformaca~o 2D e aplicada na imagem original que
tem o mesmo resultado nal na tela, como ilustrado na Figura 4.10. Alvy Ray Smith
(Smith, 1987) mostra que tal deformaca~o existe para todas as superfcies quadricas e
super-quadricas e que esta pode ser decomposta em duas deformac~oes unidimensionais,
que por sua vez podem ser implementadas mais ecientemente utilizando ao algoritmo de
reamostragem de Fant (Fant, 1986).
Os sistemas existentes de panoramas virtuais utilizam o segundo metodo, por causa
da sua eciência. Dessa forma, esses sistemas so podem utilizar superfcies quadricas,
super-quadricas, ou outras onde essas equaco~es de deformaca~o podem ser derivadas e
executadas em dois passos. No captulo 5 mostraremos como essa deformac~ao de dois
passos pode ser derivada para a superfcie cilindrica e faremos uma comparaca~o entre os
dois metodos.
4.4 Analise dos Sistemas Existentes

Ate agora, falamos das principais caractersticas dos sistemas de panoramas virtuais,
sem entrar em detalhes sobre sistemas especcos. Nesta sec~ao falaremos de alguns sistemas existentes, mostrando algumas de suas vantagens e desvantagens, e discutindo
35
Figura 4.10: A visualizaca~o da superfcie cilndrica com a imagem mapeada pela câmera
virtual (a) e implementada por uma deformac~ao 2D dessa imagem (b).
algumas funcionalidades adicionais que esses sistemas oferecem.
O primeiro sistema de panoramas virtuais disponvel foi o Quicktime VR (Chen, 1995).
O Quicktime VR suporta apenas superfcies panorâmicas cilndricas e oferece um stitcher semelhante ao descrito acima. Embora a utilizaca~o das superfcies cilndricas tenha
vantagens quanto a facilidade de criaca~o da imagem panorâmica, apresenta uma grande
desvantagen que e n~ao permitir ao usuario visualizar o ambiente em todas as direc~oes,
pois, como ja mencionamos, o processo de criac~ao limita a abertura angular vertical em
que o ambiente pode ser amostrado.
Nesse sentido, o PhotoBubbles (PhotoBubbles, 1997) apresenta uma vantagem, pois
utiliza somente superfcies esfericas. No entanto, a imagem panorâmica so pode ser criada
com lentes "sheye". Alem dessa lente ser cara, a impossibilidade de utilizaca~o de uma
lente com distância focal maior limita a quantidade de detalhes que podem ser registrados
na pelcula do lme.
Outro sistema disponvel, o RealVR (RealVR, 1997), permite a utilizaca~o de superfcies
esfericas, cilndricas e cubicas. Apesar dessa exibilidade a mais, este sistema tem os mesmos problemas que os outros nas superfcies esfericas e cilndricas. No caso da superfcie
cubica, o sistema n~ao oferece nenhum apoio para autoria das imagens panorâmicas e,
assim, as diculdades que apontamos anteriormente na autoria para superfcies cubicas
existem no RealVR.
Todos esses sistemas oferecem um tipo de interface semelhante, em que o usuario modica a direc~ao de visualizac~ao da panorama atraves do mouse e do teclado. Esse tipo de
manipulac~ao n~ao e natural, e reduz signicamente a imersibilidade do usuario no ambiente
virtual. Outro fator de reduca~o da imersibilidade e a baixa performance do visualizador
desses sistemas. Eles foram desenvolvidos para ser executados em qualquer tipo de plataforma, inclusive pela internet e, com isso, n~ao podem se aproveitar de vantagens de
determinadas plataformas. O resultado e a baixa interatividade desses visualizadores,
com baixas taxas de quadros por segundo e alto grau de \ ickering".
Finalmente, tanto o Quicktime VR quanto o RealVR permite que o usuario navegue
36
no ambiente virtual, trocando as panoramas sendo visualizadas. Ambos permitem apenas

um tipo de transic~ao por corte seco, que e causado pelo usuario ao clicar com o mouse
em algum ponto sensvel da panorama. O RealVR permite tambem a utilizaca~o de audio
nas panoramas.
4.5 Um Novo Sistema de Panoramas Virtuais

Nessa dissertac~ao apresentamos o desenvolvimento de um novo sistema para visualizac~ao de panorama. Esse sistema tem como objetivo ser utilizado no Visorama (Matos
et al. , 1997a), que esta sendo desenvolvido para resolver algumas limitac~oes dos sistemas
existentes apontadas na sec~ao anterior.
Um dos principais objetivos do Visorama e aumentar a imersibilidade do usuario no
ambiente virtual representado pela panorama. Para isso, o sistema utiliza um equipamento de hardware com um display binocular que simula um binoculo real, mas possui
dois pequenos monitores ligados a sada de vdeo do computador que mostram a imagem
produzida pelo visualizador de panoramas. O usuario pode modicar a direca~o de visualizac~ao na panorama naturalmente girando o display binocular como ilustra a Figura
4.11.
Figura 4.11: O esquipamento de hardware do Sistema Visorama.

O sistema de panoramas virtuais que deve ser utilizado em um equipamento como o
Visorama possui requisitos que n~ao s~ao satisfeitos pelos sistemas existentes. A manipulac~ao atraves do display binocular exige que o tempo de resposta na mudanca de direc~ao
de visualizac~ao seja instantâneo e suave, sem que o usuario perceba a tela sendo pintada,
caso contrario perde-se a imersibilidade que o equipamento pretende garantir. Com a
utilizac~ao de equipamentos imersivos, esse tipo de defeito torna-se muito mais perceptvel
e tende a incomodar muito mais o usuario. Dessa forma, enquanto os sistemas existentes
tem como objetivo um tempo de resposta razoavel na media, o sistema utilizado pelo
Visorama deve ser instantâneo em todos os casos.
Um segundo requisito e relativo a qualidade e estabilidade da imagem resultante.
Alguns dos sistemas existentes n~ao aplicam nenhuma ltragem sobre a imagem resultante
para evitar aliasing e esta se torna instavel, tremendo entre dois quadros consecutivos.
Esse tipo de defeito tambem n~ao pode existir em um sistema imersivo.
37
Finalmente, o sistema n~ao deve permitir que a imagem tenha uma grande degradac~ao
quando o usuario magnica o que esta sendo visualizado. Nos sistemas existentes essa
degradac~ao e grande, pois maiores detalhes exigem maiores imagens e esses sistemas foram
feitos para funcionar com imagens pequenas pela internet.
Esses novos requisitos nos levam a desenvolver o nosso proprio sistema de panoramas
virtuais, assunto que e abordado no restante dessa dissertaca~o.

Mostramos nesse captulo como funcionam os sistemas de panoramas virtuais de modo geral e apresentamos alguns sistemas existentes apontando suas deciências. Falamos
ent~ao do Sistema Visorama e de como resolve uma dessas limitac~oes, a falta de imersibilidade. Essas soluc~oes imp~oem novos requisitos na visualizaca~o de panoramas, requisitos
estes que nos levaram ao desenvolvimento de um novo sistema de visualizaca~o de panoramas. As etapas deste desenvolvimento, bem como os problema encontrados e as soluc~oes
utilizadas, ser~ao discutidas nos proximos captulos.
Captulo 5
Visualizac~ao de Panoramas
No captulo anterior, mencionamos que a visualizac~ao
de panoramas virtuais e conceitualmente simples, se reduzindo
a visualizaca~o da supefcie
panorâmica com a imagem correspondente mapeada como
textura. Apesar dessa simplicidade conceitual, diversos
cuidados devem ser tomados na pratica para que
a imagem resultante seja de boa qualidade e possa
ser gerada a taxas interativas. Os algoritmos gerais de
mapeamento de textura em superfcies curvas
n~ao podem ser utilizados, pois n~ao permitem a visualizaca~o
a taxas interativas com os equipamentos de hardware
disponveis atualmente. Ao inves disso, um algoritmo que
utiliza os recursos da maquina de forma mais eciente
deve ser utilizado, mesmo que gere apenas uma
aproximac~ao do mapeamento correto. Outra quest~ao que
deve ser considerada e a resoluca~o
da imagem panorâmica. Idealmente, cada
pixel da imagem deveria ser mapeado em
um pixel da tela, e e interessante que se possa determinar
durante a visualizac~ao a resoluca~o que resulta nesta
raz~ao de pixels.
Nesse captulo apresentamos de forma mais detalhada o
processo de visualizaca~o de panoramas. Em seguida
apresentaremos dois algoritmos ecientes para
visualizac~ao da supefcie panorâmica. O primeiro implementa
essa visualizac~ao por uma transformac~ao de imagens
no plano. Ja o segundo, aproxima a superfcie por
polgonos e visualiza os polgonos individualmente. Ao nal
do captulo comparamos os dois algoritmos e mostramos
porque decidimos utilizar o segundo no nosso sistema.
~ DE PANORAMAS
39
5.1 Modelo de Câmera

Conforme ja mencionamos anteriormente, a visualizaca~o de
panoramas e feita atraves de uma câmera virtual,
que e utilizada para visualizar a superfcie panorâmica
com a imagem mapeada. O modelo de câmera virtual
utilizado deve ser tal que a imagem resultante do processo de visualizaca~o seja semelhante aquela que seria gerada pela visualizaca~o do ambiente representado pela panorama.
Sendo assim, esse modelo depende de como a funca~o de luminosidade do ambiente e amostrada durante o processo de autoria.
Vimos no captulo 3 que a superfcie panorâmica representa uma parametrizac~ao das
retas passando pela origem. Se zermos uma projec~ao do ambiente, onde a origem e
o centro de projec~ao, ent~ao a cada ponto da superfcie corresponde um unico raio de
projec~ao, e podemos "pintar"neste ponto a cor do ambiente interceptado pelo raio. Com
isso, a superfcie representa uma amostra da funca~o de luminosidade do ambiente visto
do centro de projec~ao (ver Figura 5.1).
Figura 5.1: Durante o processo de autoria o ambiente e projetado na superfcie panorâmica.

Para gerar vistas do ambiente podemos utilizar um modelo pinhole de câmera virtual,
onde o centro de projec~ao e posicionado na origem. Quando isso e feito, os mesmos raios
de projec~ao utilizados para pintar a superfcie s~ao utilizados para projeta-la na tela da
câmera virtual. Como resultado a imagem gerada e a mesma que seria gerada se essa
mesma câmera fosse utilizada para visualizar o ambiente( ver Figura 5.2).
Note que no processo descrito acima, existem duas projeco~es envolvidas. Primeiro,
o ambiente e projetado na superfcie panorâmica durante a autoria. Posteriormente,
durante a visualizac~ao, a superfcie e projetada na tela da câmera virtual. Por esse
motivo, a projeca~o da câmera virtual e muitas vezes chamada na literatura de reprojec~ao,
embora seja uma projec~ao normal. A superfcie panorâmica e frequentemente chamada
de environment map, devido a primeira projec~ao (Greene, 1986).
Como o centro de projeca~o da câmera virtual esta sempre na origem e esta so pode
variar a sua direc~ao de visualizaca~o e a^ngulo de abertura, iremos representa-la por quatro
~ DE PANORAMAS
40
Figura 5.2: Uma câmera de modelo pinhole visualizando a supefcie produz a mesma
imagem que seria gerada se visualizasse o ambiente.
parâmetros: a inclinac~ao vertical (), o ângulo de rotac~ao horizontal (), o ângulo de
abertura horizontal (hFOV ) e o ângulo de abertura vertical (vFOV ) (ver Figura 5.3).
Figura 5.3: Parâmetros da Câmera Virtual.

Na discuss~ao acima, mencionamos que o ambiente e projetado e "pintado"na superfcie
para posterior visualizac~ao. Isso e implementado armazenando na imagem panorâmica
as cores correspondentes a cada ponto do ambiente. Essa e ent~ao mapeada na superfcie
durante a visualizac~ao.
5.2 Imagem Panorâmica

Seja S a superfcie panorâmica, que pode ser representada parametricamente. A imagem panorâmica deve associar a cada ponto P = S (u; v) a cor do ambiente projetada em
P . Essa imagem e uma func~ao do tipo I : U R 2 ! C R 3 , onde U e o espaco de
parâmetros da superfcie e C e o espaco de cores. Assim, para cada ponto (u; v) de U , a
~ DE PANORAMAS
41
imagem panorâmica determina a cor do ponto P = S (u; v) apos a projec~ao do ambiente

em S .
Do mesmo modo, o resultado do processo de visualizaca~o deve ser uma imagem que
associa a cada ponto (x; y) da tela a cor do ambiente sendo visualizado, ou seja uma
func~ao I 0 : W R 2 ! C R 3 , onde W e a janela sendo visualizada no plano de
imagem. Essa func~ao e dada pela projec~ao da supefcie na tela, onde a cor de cada ponto
da supefcie depende da func~ao I . Sendo assim, o processo de visualizac~ao dene uma
transformac~ao T (u; v) = (x; y) que associa a cada ponto (x; y) da tela o ponto (u; v) no
espaco de parâmetros da superfcie tal que P = S (u; v) e projetado em (x; y). Com isso,
podemos dizer que I 0(x; y) = I (T ,1(x; y)), desde que T seja inversvel. A Figura 5.4
ilustra esse processo.
Figura 5.4: Mapeamento entre o espaco de parâmetros da superfcie e o plano de imagem

da câmera virtual.
Na gura acima, a func~ao H e a projeca~o da câmera virtual. Fica claro pela gura
que a transformac~ao T e dada por: T (u; v) = H (S (u; v)) = (x; y). Essa transformac~ao
espacial T dene uma mudanca de coordenadas que pode ser aplicada a imagem I para
gerar a imagem I 0. O processo de visualizaca~o pode ent~ao ser implementado por uma
transformac~ao no plano, sem que as operac~oes de visualizac~ao 3D precisem ser utilizadas.
Embora ate agora temos assumido que as imagens I e I 0 s~ao contnuas, na pratica elas
s~ao discretas. As suas discretizac~oes correspondem a amostragens dos raios de projec~ao
na superfcie panorâmica e na tela, respectivamente. Esse fato introduz uma diculdade
na implementac~ao da transformac~ao espacial pois, em geral, esta n~ao alinha as duas
discretizac~oes. Por esse motivo, essa transformaca~o deve ser implementada por uma
processo de reamostragem (Gomes & Velho, 1997) (Wolberg, 1988).
5.3 Visualizac~ao e Reamostragem

A transformac~ao T pode ser implementada de modo mais efetivo utilizando mapeamento inverso (Gomes & Velho, 1997). Essa abordagem exige que a transformaca~o inversa T ,1 exista e seja conhecida. Note que T e composta de uma projeca~o H do tipo
H : R 3 ! R 2 , que geralmente n~ao e inversvel. No entanto, como sabemos que o ponto
projetado pertence a superfcie S , e geralmente possvel se determinar a transformac~ao
inversa T ,1.
Assumindo que a transformaca~o T ,1 seja conhecida, ela pode ser aplicada a grade de
amostragem da imagem nal, I 0. A grade transformada resultante e sobreposto a grade da
~ DE PANORAMAS
42
imagem inicial, I , para determinar a correspondência entre pixeis nais e iniciais. Baseado
nessas correspondências, a imagem nal e criada. Como mencionamos anteriormente, as
duas grades em geral n~ao se alinham, e a cor de cada pixel da imagem nal deve ser
determinada considerando-se dois tipos de reamostragem que podem ser induzidos pela
transformac~ao espacial: expans~ao e contrac~ao. Chamaremos os pixels da imagem inicial
de pixels de entrada e os pixels da imagem nal de pixels de sada.
Expans~ao ocorre quando varios pixels da imagem nal s~ao mapeados por T ,1 em um
unico pixel da imagem inicial (Figura 5.5a). Nesse caso, se as cores dos pixels de sada
forem determinadas por amostragem pontual nos pixels de entrada, a imagem resultante
apresentara um padr~ao de blocagem. Ao inves disso, a cor em cada pixel interno ao
pixel de entrada pode ser determinada por interpolac~ao linear entre os pixels adjancentes.
Nesse processo estamos na realidade reconstruindo a imagem de entrada utilizando um
ltro de reconstruc~ao linear , e aplicando amostragem pontual nessa imagem reconstruda
(Gomes & Velho, 1997).
Quando existe contrac~ao (Figura 5.5b, um pixel da imagem de sada e mapeado em
varios pixels de entrada. Se amostragem pontual fosse utilizada, a imagem resultante
teria problemas de aliasing. Ao inves disso, a cor do pixel de sada pode ser determinada
como a media de todos os pixels de entrada que est~ao no seu interior, onde essa media
poderia ser ponderada pela area de cada um no interior do pixel de sada. Esse tipo de
amostragem e conhecido como area sampling.
Figura 5.5: Superposic~ao do grid da imagem nal transformado (T (xi; yi)) com o grid da
imagem inicial ((ui; vi). (a) Expans~ao (b) Contraca~o.
Em ambos os casos, as operac~oes necessarias, se aplicadas diretamente, s~ao inecientes
e difceis serem executadas a taxas interativas para imagens com um certo tamanho. Sendo
assim, testaremos dois metodos mais ecientes para implementaca~o da reamostragem. No
primeiro, decompomos a transformac~ao bidimensional em dois passos unidimensionais. As
operac~oes descritas acima, s~ao executadas primeiro nas linhas da imagem e depois nas suas
colunas, o que pode ser feito muito mais ecientemente do que aplicando as operaco~es no
plano. E claro que nem toda transformac~ao pode ser decomposta em dois passos, veremos
adiante alguns casos onde isso pode ser feito.
No segundo metodo, fazemos uma aproximac~ao poligonal da transformac~ao. Dividimos
a imagem em retângulos e aplicamos a transformaca~o aos seus vertices, gerando um
quadrilatero arbitrario. A correspondência entre os vertices do retângulo original e do
quadrilatero resultante dene uma unica transformaca~o projetiva (Faugeras, 1993) que
e aplicada aos pixels interiores. A vantagem dessa abordagem e que podemos utilizar
as func~oes de mapeamento de textura de bibliotecas gracas, que em muitos sistemas
~ DE PANORAMAS
43
s~ao implementadas em hardware. Com isso, essas operac~oes podem ser implementadas
ecientemente.
No restante deste captulo mostraremos como a transformaca~o pode ser implementada
usando cada um dos metodos descritos acima, e apresentaremos resultados da implementac~ao de cada um deles.
Antes de apresentarmos esse metodos, vale alguns comentarios sobre as operaco~es de
expans~ao e contrac~ao na visualizaca~o de panoramas. A regi~ao da tela onde a imagem e
mostrada e xa ao longo de toda a visualizac~ao, e como a discretizac~ao da tela tambem
e xa, o numero de amostras na imagem nal e constante. Por outro lado, a regi~ao da
imagem panorâmica sendo visualizada varia ao longo da execuc~ao e o seu tamanho varia
com o ângulo de zoom da câmera virtual (hFOV e vFOV). Se a discretizac~ao da imagem
panorâmica for xa, o numero de pixels mapeado na tela varia com o ângulo de zoom.
Sendo assim, podera ocorrer tanto contrac~ao quanto expans~ao ao longo da visualizac~ao.
Examinando novamente a Figura 5.5 vemos que tanto a expans~ao quanto a contrac~ao
s~ao ruins quando muito grandes. Uma expans~ao grande signica que um pixel da imagem
panorâmica e mapeado em muitos pixels da tela, ou seja, o usuario esta tentando ver
mais detalhes do que esta representado na imagem panorâmica. Por outro lado, uma
contrac~ao grande signica que muitos pixels da imagem panorâmica s~ao mapeados em
um unico pixel da tela, o que signica que a transformac~ao esta sendo aplicada a mais
pixels do que seria necessario, prejudicando o tempo de visualizac~ao. Uma soluc~ao para
resolver esses problemas seria introduzir limites maximo e mnimo para o ângulo de zoom,
limitando assim a contrac~ao e expans~ao maxima. Essa soluc~ao, porem, limita a navegac~ao
do usuario no ambiente. Uma outra possibilidade e permitir que discretizaca~o da imagem
panorâmica varie de acordo com o ângulo de zoom. Isso pode ser feito utilizando-se uma
estrutura de multiresoluc~ao, ou pirâmide de imagens, como veremos no Captulo 7.
5.4 Transformac~ao de Dois Passos

A transformac~ao T leva cada ponto (u; v) da imagem panorâmica em um ponto (x; y)
da tela segundo duas func~oes de mapeamento X e Y :
(x; y) = T (u; v) = (X (u; v); Y (u; v))
(5.1)
Quando T pode ser expressado como T (u; v) = F (u) G(v) diz-se que T e uma
transformac~ao separavel. Smith (Smith, 1987) chama as transformac~oes expressadas desta
forma de mapeamento serial e aquelas expressas como na equac~ao 5.1 de mapeamento
paralelo. Sendo assim, uma transformac~ao separavel e uma que pode ser expressa como
um mapeamento serial. Transformaco~es separaveis s~ao interessantes porque podem ser
executadas por um algoritmo de dois passos, onde no primeiro passo apenas as linhas da
imagem s~ao transformadas e no segundo passo, apenas as colunas. Como a cada passo
apenas a reamostragem unidimensional e empregada, esse algoritmo e mais eciente.
5.4.1 Algoritmo de dois passos
Catmull e Smith (Catmull & Smith, 1980) foram os primeiros a mostrar como o algoritmo de dois passos pode ser empregado dada uma transformac~ao T (u; v) = (X (u; v); Y (u; v)).
~ DE PANORAMAS
44
No primeiro passo as linhas da imagem s~ao transformadas segundo uma funca~o Fv (u), que
pode variar de linha para linha. O primeiro passo pode ser expresso como:
(x; v) = (Fv (u); v)
(5.2)
Mas como x = X (u; v), temos que Fv (u) = X (u; v). Logo esse primeiro passo pode
ser executado trivialmente a partir de T .
No segundo passo, cada coluna da imagem resultante do primeiro passo e transformada
por uma func~ao Gx(v), que pode ser diferente para cada coluna. Este segundo passo pode
ser expresso como:
(x; y) = (x; Gx(v))
(5.3)
Para determinar G, gostaramos de utilizar o fato de que y = Y (u; v). Mas como as
linhas ja foram transformadas, precisamos para isso inverter a func~ao F e achar o valor
de u correspondente a cada x. Seja H essa funca~o inversa, ou seja: u = Hx(v) quando
x = Fv (u). Tendo achado essa funca~o podemos denir G como: Gx(v) = Y (Hx(v); v).
Com isso o sengudo passo do algoritmo e dado por:
(x; y) = (x; Y (Hx(v); v))
(5.4)
A funca~o H existe desde que F seja bijetiva, mas acha-la nem sempre e uma tarefa
simples, o que diculta a utilizac~ao deste algoritmo em muitos casos. Smith (Smith,
1987) mostra que esse algoritmo sempre pode ser empregado quando a transformac~ao
planar e resultado da visualizac~ao de quadricas e superquadricas. Sendo assim, podemos
utilizar este algoritmo para visualizac~ao de superfcies panorâmicas desde que a superfcie
pertenca a esta classe, o que e o caso das superfcies cilndricas, esfericas e cubicas (que
pode ser tratada como seis superfcies planas).
Cada passo do algoritmo acima envolve a reamostragem de linhas ou colunas da matriz.
Essa reamostragem pode ser implementada utilizando o algoritmo de Fant (Fant, 1986).
5.4.2 Algoritmo de Reamostragem de Fant
O algoritmo de Fant e um dos mais ecientes para reamostragem unidimensional de

imagens. A grande vantagem desse algoritmo e que faz antialiasing e area sampling para
o caso unidimensional em poucas operac~oes.
O algoritmo trata os pixels de entrada como uma sequência a ser consumida, e os
pixels de sada como uma sequência a ser produzida. Essas duas sequências v~ao sendo
percorridas iterativamente, com ponteiros mantendo controle do pixel corrente em cada
uma. A cada passo, duas situaco~es podem ocorrer:
1. O pixel de entrada transformado completa um pixel de sada sem ser totalmente
consumido. Nesse caso, a sua intensidade e adicionada ao pixel de sada juntamente
com a intensidade do pixel seguinte, onde a ponderaca~o depende da area ocupada
por cada um no pixel de sada apos a transformaca~o. Com isso, o algoritmo interpola
linearmente entre pixels de entrada no caso de expans~ao. Apos esse passo, passa-se
para o proximo pixel de sada.
~ DE PANORAMAS
45
2. O pixel de entrada e totalmente consumido sem completar um pixel de sada. Nesse

caso, a intesidade do pixel de entrada e adicionada ao pixel de sada multiplicada
pela frac~ao da area deste que o pixel de entrada ocupa. Com isso o algoritmo efetua
area sampling no caso de contrac~ao. Apos esse passo, passa-se ao proximo pixel de
entrada.
O caso onde o pixel de entrada e consumido preenchendo totalmente um pixel de
sada pode ser encaixado em qualquer um dos casos acima. A cada passo do algoritmo
três adic~oes, três multiplicaco~es e uma acumulaca~o s~ao efetuadas, motivo pelo qual esse
algoritmo e eciente.
A implementac~ao de transformaco~es espaciais atraves do algoritmo de dois passos
apresenta alguns problemas que devem ser tratados. Se a transformac~ao for tal que no
primeiro passo uma contraca~o muito grande ocorra, muita informac~ao da imagem sera
perdida durante a reamostragem. Por exemplo, na implementac~ao da rotac~ao de imagens
por um ângulo de 90 graus, o primeiro passo levaria toda uma linha da imagem em um
unico pixel. Wolberg (Wolberg & Boult, 1989) prop~oe uma extens~ao do algoritmo de Fant
que resolve esse problema e outros que podem surgir, como o problema de foldover. Como
na visualizac~ao de supefcies panorâmicas tipicamente usadas esses problemas podem ser
evitados, o algoritmo de Fant e suciente.
Em seguida veremos como esse algoritmo de dois passos pode ser implementado para
a visualizac~ao de superfcies panorâmicas cilndricas.
5.5 Visualizac~ao de Panoramas Cilndricas

Queremos derivar as func~oes Fv (u) e Gx(v) que ser~ao utilizadas nos dois passos de
reamostragem. Essa func~oes s~ao dadas pela projeca~o da superfcie cilndrica na tela, que
determina para cada ponto (u; v) do espaco de parâmetros do cilindro, a sua posic~ao
(x; y) na tela. Dada essa transformaca~o, aplicamos o algoritmo de Fant para realizar a
reamostragem.
5.5.1 Derivac~ao da Transformac~ao de Dois Passos
Seja S (u; v) a superfcie do cilindro e seja H a matriz de projeca~o da câmera virtual.

Ent~ao, a transformaca~o espacial e dada por:
(x; y) = H S (u; v)
(5.5)
Vimos que a câmera virtual deve ser posicionada no centro de projec~ao utilizado para
criar a imagem panorâmica. Geralmente esse ponto e o centro do cilindro, o ponto no seu
eixo que esteja na media entre a altura maxima e mnima. A equac~ao geral de projeca~o do
cilindro em uma câmera virtual posicionada no seu centro e ligeiramente complexa o que
diculta a determinac~ao da funca~o Hx(u). Com isso faremos algumas simplicac~oes no
modelo que ir~ao gerar equaco~es mais simples (ecientes) e ainda resultar~ao em imagens do
boa qualidade. Essas simplicac~oes s~ao semelhantes as utilizadas no algoritmo de Chen
(Chen & Miller, 1995), que s~ao empregadas no sistema comercial Quicktime VR (Chen,
1995).
~ DE PANORAMAS
46
A câmera virtual esta xa na origem com o eixo na direc~ao z. Dessa forma um ponto
da tela e dado por Pt = (x; y). Dizemos ainda que a câmera virtual tem distância focal
d. Com isso, a matriz de projec~ao H e dada por:
0d 0 0
B0 d 0
H=B
@0 0 d
0
0C
C
(5.6)
0A
0 0 1 0
O cilindro esta posicionado na origem com eixo na direca~o y, sendo dado em coordenadas homogêneas pela equac~ao:
S (u; v) = [r sen(u); h v; r cos(u); 1]

(5.7)
Onde r e o raio do cilindro, h e sua altura, 0 u 2 e ,h v h.
Como a câmera esta xa com eixo na direca~o z, uma modicac~ao de a^ngulo de rotac~ao
da câmera e implementado por uma translaca~o u0 = u , u0 da coordenada u de todos
os pontos da imagem, onde u0 e o ângulo de rotaca~o desejado. Alem disso, o ângulo
de vis~ao vertical da câmera e tal que todo o cilindro seja visivel. Assim, mudancas no
ângulo de elevaca~o s~ao implementadas eliminado-se os os pontos cuja coordenada v esta
fora do campo de vis~ao vertical da câmera. As simplicac~oes que propomos equivalem a
substituir a câmera da Figura 5.6a pela da Figura 5.6b.
Figura 5.6: Câmera virtual geral (a) simplicada(b)

Como veremos nos resultados, essa simplicaca~o ainda permite que se gere uma imagem com deformac~oes aparentemente corretas.
Substituindo 5.6 e 5.7 em 5.5, temos:
x = d tan(u0 )
(5.8)
dv
y = r h cos
(u0)
(5.9)
~ DE PANORAMAS
47
Da podemos obter os dois passos do algoritmo. Nesse caso e mais conveniente fazer
com que o primeiro passo transforme as colunas da imagem e o segundo as linhas. Com
isso o primeiro passo e dado por:
dv )
(u0; y) = (u0; r h cos
(u0)
(5.10)
Na equac~ao 5.8, x n~ao depende de v e logo n~ao precisamos achar a func~ao inversa H .
Essa e a grande vantagem de aplicar o primeiro passo sobre as colunas. Com isso, a o
segundo passo e dado por:
(x; y) = (d tan(u0 ); y)
(5.11)
5.5.2 Implementac~ao
Implementamos os dois passos acima utilizando o algoritmo de reamostragem de Fant.

Executamos o programa com a imagem panorâmica da Figura 5.7. Determinamos os
parâmetros relativos ao tamanho do cilindro e distância focal da câmera virtual a partir
de uma estimativa do ângulo de abertura da câmera fotograca utilizada para gerar a
imagem.
Figura 5.7: Imagem panorâmica de 360 graus utilizada para testar o algoritmo
A Figura 5.8 ilustra duas vistas do ambiente representado pela imagem panorâmica e
criadas por essa implementac~ao. Como se pode vericar, a imagem gerada e perceptualmente igual a que seria vista se uma fotograa fosse tirada com os mesmos parâmetros
de câmera. Podemos ver tambem o resultado do primeiro passo, sobre as colunas da
imagem (Figura 5.8 (a) e (c)) e o resultado aplicando os dois passos. Podemos notar que
o segundo passo n~ao causa grandes diferencas na imagem resultante. Isso se deve ao fato
de que na superfcie cilndrica, a deformaca~o e maior nas colunas do que nas linhas, como
podemos vericar pelas equac~oes acima. Em outras superfcies, como a esferica, n~ao se
pode esperar que isso ocorra.
O tempo de execuc~ao dessa implementac~ao esta indicado na tabela abaixo. Nela s~ao
apresentados o tempo de gerac~ao de um quadro como funca~o da resoluc~ao da imagem
panorâmica. Esses resultados foram obtidos em uma maquina com processador Pentium
300 Mhz, com 128 MB de Memoria. O programa n~ao utiliza nenhuma acelerac~ao graca
da maquina.
~ DE PANORAMAS
48
Figura 5.8: Vistas do ambiente obtidas por deformac~oes da imagem panorâmica da gura
anterior. Resultado do primeiro passo (a) e (c). Resultado dos dois passos (b) e (d).
da Imagem
Tempo Medio de Gerac~ao de Quadros (ms) LarguraTamanho
Altura Tamanho (MB)
1780
4096
1024
12
1168
2048
512
3
919
1024
256
0.768
805
512
128
0.192
742
256
64
0.048
716
128
32
0.012
Vemos que, utilizando o algoritmo de transformac~ao de dois passos, o tempo de gerac~ao de
cada quadro ainda esta muito acima do que gostaramos. Para imagens n~ao muito grandes, como 4096x1024, o tempo ja e proibitivo e mesmo quando o tamanho da imagem e
reduzido, esse tempo n~ao diminui muito. E bem verdade que essa implementac~ao poderia ainda ser otimizada atraves de uma inspec~ao minunciosa dos principais gargalos no
codigo, mas acreditamos que mesmo assim o tempo ainda seria acima do que gostaramos
para as maiores imagens que testamos. Com isso, decidimos tentar um outro esquema
de implementac~ao da deformaca~o, onde fazemos uma aproximac~ao poligonal desta, o que
e implementado com a ajuda de aceleradores gracos que fazem mapeamento de textura
em hardware.
5.6 Aproximac~ao Poligonal

Ao inves de aplicar a transformaca~o T a cada pixel da imagem, podemos implementar
uma aproximac~ao poligonal desta. Para isso, criamos uma malha poligonal sobre a imagem
e aplicamos a cada vertice da malha Vi = (ui; vi) a transformaca~o T . A cada polgono
Pj dessa malha e associada uma transformac~ao Tj que e aplicada a todos os seus pontos
interiores. Essa transformaca~o e denida de modo que alguma relaca~o entre os pontos
interiores dos polgonos e os seus vertices seja mantida.
Por exemplo, podemos fazer uma triangulac~ao da imagem utilizando os pontos Vi como
vertices. Assim, qualquer ponto V na imagem estara certamente no interior de um unico
triângulo. Seja V0i , V1i e V2i os vertices deste triângulo, e seja (1; 2; 3) as coordenadas
~ DE PANORAMAS
49
baricênctricas de V em relaca~o a esses vertices. Existe uma unica transformaca~o linear Ti

que leva os pontos V0i, V1i e V2i nos pontos T (V0i), T (V1i) e T (V2i). Essa transformac~a e tal
que as coordenadas baricêntricas de Ti(V ) em relac~ao a T (V0i), T (V1i) e T (V2i) tambem
e dada por (1; 2; 3). Denindo Ti dessa forma, estamos aproximando a transformac~ao
T por um conjunto de transformaco~es lineares onde cada uma se aplica a uma regi~ao do
plano, ou seja, por uma transformac~ao linear por partes.
Pela equac~ao 5.5 vemos que T tem um componente projetivo, dada pela projeca~o da
câmera virtual. Sendo assim, uma aproximaca~o por transformac~oes lineares n~ao traz bons
resultados, sendo mais apropriado a aproximaca~o por transformaco~es projetivas.
5.6.1 Aproximac~ao por Transformac~oes Projetivas
Do mesmo modo que aproximamos T por uma transformac~ao linear por partes, podemos aproxima-la por uma transformac~ao projetiva por partes, onde cada Ti sera uma
transformac~ao projetiva. Para isso, a malha poligonal e uma grade regular na imagem,
como ilustrado na Figura 5.9.
Figura 5.9: A malha poligonal e uma grade regular

Para cada polgono Pk desta malha, existe uma unica transformaca~o projetiva Tk que
leva os seus vertices V0, V1 , V2 e V3 em T (V0), T (V1), T (V2) e T (V3) respectivamente.
Essa transformac~ao, quando aplicada aos pontos interiores do polgono, preserva a raz~ao
cruzada entre esses pontos e quaisquer três vertices transformados (Faugeras, 1993).
Na equac~ao 5.5 vemos que T e obtida a partir de uma mapeamento na superfcie e
da projec~ao desta na câmera virtual. Uma boa aproximaca~o dessa transformac~ao para
um dado polgono Pk pode ser obtida mapeando-se cada ponto V , interior ao polgono,
no quadrilatero do espaco com vertices S (V0), S (V1), S (V2), S (V3) e efetuando a projec~ao
deste quadrilatero na câmera virtual. Esse mapeamento, que chamamos de S, pode ser
denido de modo que a transformac~ao Tk resultante seja uma transformaca~o projetiva no
plano (ver Figura 5.10).
A aproximac~ao acima e, na realidade, bastante intuitiva, pois consiste em poligonizar
a superfcie a partir de uma discretizac~ao do seu espaco de parâmetros por uma grade
regular, e visualizar essa superfcie poligonizada, mapeando em cada polgono a regi~ao da
grade correspondente na imagem. Da a grande vantagem desta aproximaca~o, podemos
utilizar o pipeline de visualizac~ao 3D dos sistemas gracos para visualizar a superfcie. Toda a reamostragem da imagem panorâmica passa a ser feita pelas func~oes de mapeamento
de textura desses sistemas.
No incio do captulo, quando derivamos a transformaca~o espacial no plano, mencionamos que isso permitia que fugssemos do pipeline de visualizaca~o 3D pois este e muito
ineciente. De fato, quando essas operaco~es s~ao executadas em software, n~ao e possvel
gerar a sada a taxas interativas com os equipamentos disponveis atualmente. Mas em
~ DE PANORAMAS
50
Figura 5.10: A transformaca~o pode ser aproximada por uma transformac~ao projetiva por
partes poligonizando a superfcie S
grande parte dos sistemas, essas operac~oes s~ao implementadas em harware e, sendo assim, podem ser executadas com grande eciência. A seguir, apresentamos resultados
dessa implementac~ao para visualizaca~o de panoramas cilndricas e a comparamos com a
implementac~ao utilizando o algoritmo de dois passos.
Uma quest~ao que ainda n~ao mencionamos e relativa ao erro introduzido pela aproximac~ao poligonal. Para alguns tipos de superfcies panorâmicas, como a superfcie cubica,
n~ao ha nenhum erro introduzido, pois a propria superfcie e poligonizada. Nas demais
superfcies, o erro depende da distância no espaco entre os poligonos e a superfcie propriamente dita. E sempre possvel diminuir o erro de uma dada aproximac~ao utilizando
uma grade mais densa. Na nossa experiência, n~ao e necessario uma grade muito densa
para que o resultado seja satisfatorio.
5.6.2 Implementac~ao
Implementamos a visualizaca~o de panoramas cilndricas por aproximaca~o poligonal

utilizando a biblioteca OpenGL. A grade de poligonizaca~o utilizada tem tamanho 32 na
direc~ao u e 1 na direca~o v. A Figura 5.11 ilustra duas vistas geradas com essa implementac~ao. Vemos que a qualidade da imagem gerada e a mesma do algoritmo de dois
passos. Note que n~ao ha problemas de aliasing nas imagens resultantes, pois as func~oes
de mapeamento de textura do OpenGL tambem ltram a imagem para evitar artefatos
(Woo, 1998), como zemos no algoritmo de dois passos.
Figura 5.11: Vistas do ambiente obtidas por aproximaca~o poligonal.

O tempo de execuc~ao do algoritmo esta ilustrado nos gracos da Figura 5.12. O
~ DE PANORAMAS
51
programa foi executado em uma maquina com processador Intel Pentium 300 MHz, com
128 MB de memoria e uma placa graca Diammond FireGL 4000, que implementa o
OpenGL em hardware e possui 16 MB de memoria de textura.
A primeira conclus~ao que podemos tomar pelos gracos e que o tempo de gerac~ao
de quadros utilizando aproximac~ao poligonal e muito menor do que o tempo utilizando
o algoritmo de dois passos. Tanto os tempos medios quanto os tempos maximos, para
qualquer tamanho de imagem, e melhor do que o tempo medio obtido utilizando o algoritmo de dois passos. Como ja mencionamos, isso vem do fato de que todas as operac~oes
de visualizac~ao com mapeamento de textura s~ao implementadas em hardware na placa
graca.
Figura 5.12: Os gracos ilustram o tempo de geracao de cada quadro para tamanho de
imagens diferentes.
Podemos ver que para imagens menores do que 3MB, o tempo de gerac~ao de quadros
se mantem praticamente constante com o tamanho. Na realidade, os dados obtidos para
esses tamanhos indicam um tempo de gerac~ao de 10 ms para alguns quadros e 0 ms para
~ DE PANORAMAS
52
outros. Isso acontece porque a func~ao de medica~o de tempo tem uma precis~ao de 10 ms, de
modo que os tempos reais devem ser algo entre 0 ms e 10 ms nesses casos, provavelmente
um pouco menos as para imagens menores.
Podemos ver ainda que, para imagens com tamanho de 12 MB ou mais, aparecem
alguns picos de tempo nos gracos. Esses picos introduzem uma pequena "engasgada"na
visualizac~ao. Apos uma analise dos dados e um estudo do funcionamento do OpenGL,
conclumos que esses picos correspondem ao tempo de carregamento das texturas na placa
graca.
Para aplicar uma textura em um polgono, o OpenGL deve primeiro carregar essa textura na placa graca, que possui 16 MB para armazenamento. O tempo de transferência
para a placa depende do tamanho da textura, podendo aumentar bastante o tempo de gerac~ao do quadro. As texturas s~ao carregadas na primeira vez que s~ao utilizadas e a partir
da permanecem na memoria da placa. Quando essa memoria ca cheia, um algoritmo de
LRU (Least Recently Used ) (Silberschatz & Galvin, 1997) e utilizado para retirar texturas
sempre que uma nova deve ser carregada.
Os picos nos gracos acima correspondem a mudancas no ângulo da câmera virtual
onde polgonos cuja textura n~ao estava carregada s~ao visualizados. O processamento e
interrompido para efetuar o carregamento, o que resulta nos picos. Na medida que a imagem aumenta, esses picos tambem aumentam, pois as texturas cam maiores. Podemos
ver isso claramente no graco correspondente a imagem com 32 MB de tamanho. Nesse
graco, vemos picos com tamanhos de 240 ms, 160 ms e 80 ms aproximadamente ( ha
uma variac~ao de 20 ms nesses valores devido a imprecis~ao da funca~o de temporizac~ao).
Os maiores picos ocorrem durante movimentos mais rapidos. Isso nos leva a crer que o
tempo de carregamento de uma textura e mais ou menos de 80 ms para essa imagem.
O pico de 240 ms corresponde a um movimento onde três novos polgonos s~ao visualizados por quadro, o pico de 160 ms corresponde a um movimento onde dois polgonos
s~ao visualizados e o de 80 ms a um movimento onde um novo polgono e visualizado por
quadro.
Para imagens menores do que 3 MB, o tempo de carregamento e menor do que os 10
ms de precis~ao da func~ao de temporizaca~o, de modo que n~ao percebemos os pontos onde
as texturas est~ao sendo carregadas.
Outra evidência de que o carregamento da textura introduz um tempo adicional a
visualizac~ao vem do fato de que em todos os casos, o quadro com maior tempo de gerac~ao
e o primeiro, justamente aquele que tem que carregar a textura para todos os polgonos
desenhados. Esse fato n~ao pode ser visto na gura porque os dados do primeiro quadro se
confundem com a linha do eixo, mas foi vericado numericamente em todas as sequências
de visualizac~ao.
Esses picos s~ao altamente indesejaveis pois, em um sistema de visualizaca~o em temporeal, e desejavel que a taxa de gerac~ao de quadros se mantenha constante, o que permite
uma interatividade maior. Alem disso, e de se esperar que, para imagens maiores, esses
picos aumentem muito o tempo de geraca~o de alguns quadros, que assim deixariam de ser
gerados a taxas interativas.
~ DE PANORAMAS
53
5.7 Consideracoes Finais

Vimos neste captulo duas abordagens para visualizaca~o de panoramas, a primeira
baseada no algoritmo de dois passos e a segunda em uma aproximaca~o poligonal. Mostramos que, com o algoritmo de dois passos, n~ao e possvel atingir taxas interativas de
desenho com os equipamentos que temos disponveis. Por outro lado, vimos que utilizando
o metodo de aproximac~ao poligonal com auxlio de uma placa que implemente mapeamento de textura em hardware, o tempo de geraca~o de quadros e bastante pequeno na
media, mesmo para imagens com 32 MB de tamanho. Sendo assim, decidimos utilizar em
nosso sistema de visualizac~ao de panoramas o metodo por aproximaca~o poligonal, com
auxlio do mapeamento de textura implementado em harware. Vale mencionar que placas
gracas com esse tipo de funcionalidade est~ao cando cada vez mais comuns no mercado
a precos acessveis.
Uma quest~ao importante que descobrimos analisando nossa implementac~ao e que, na
placa graca que utilizamos, o tempo gasto com carregamento de textura pode tornarse muito grande com o aumento da imagem. Esperamos poder trabalhar com imagens
muito maiores do que as testadas nesta seca~o, para criar um ambientes virtuais com muitos
detalhes. Nesses casos as texturas ser~ao muito maiores e e de se esperar que os tempos de
carregamento crescer~ao muito, impedindo que a taxa de geraca~o de quadros se mantenha
constante e acima de um mnimo esperado, em torno de 15 quadros pro segundo.
Para resolver, ou pelo menos diminuir, esse problema, podemos quebrar a textura em
pedacos menores que podem ser carregados sem introduzir picos, como vimos para as
imagens pequenas, e implementar a visualizac~ao de modo que apenas um pedaco destes
seja carregado por quadro. Dessa forma e necessario a implementac~ao de um algoritmo que
gerencie essas operaco~es de carregamento e descarregamento de texturas. Na verdade, esse
problema faz parte de um problema mais geral de gerenciamento de cache e, na medida que
as imagens v~ao cando muito grandes, e de se esperar que tambem ocorra em outros tipos
de armazenamento. So para citar um exemplo, se a imagem for t~ao grande que n~ao caiba
na memoria do computador, uma parte tem que ser aramazenada em disco. Quando esta
parte for visualizada, tera que ser carregada do disco para memoria antes que possa ser
passada para o pipeline de visualizac~ao. Isso certamente introduzira um aumento muito
grande no tempo de gerac~ao do quadro. O mesmo algoritmo que mencionamos acima pode
ser utilizado para tratar esse caso. No proximo captulo apresentaremos um algoritmo de
gerenciamento de cache para visualizac~ao de panoramas. Esse algoritmo pode ser aplicado
para gerenciar o carregamento de dados nesses dois tipos de armazenamento, memoria e
placa graca, e outros que possam ser necessarios.
Um problema interessante que n~ao abordamos neste captulo e a comparac~ao numerica
da diferenca entre as imagens obtidas com a transformac~ao de dois passos e a aproximac~ao
poligonal. Seria interessante que pudessemos estimar o erro maximo em pixels introduzido pela aproximac~ao poligonal como funca~o do numero de polgonos. Dessa forma,
teramos um indicativo do menor numero de polgonos que devem ser utilizados para que
o resultado tenha uma qualidade desejada. Repare que a aproximaca~o poligonal pode ser
exata se a imagem panorâmica for gerada como uma projeca~o do ambiente na superfcie
poligonizada, ao inves da superfcie aproximada (e.g. cilindro). Isso pode ser feito quando
essa imagem e criada a partir de ambientes modelados ou a partir do ambiente real com
auxlio de processamento de imagens.
Captulo 6
Gerenciamento de Cache
Vimos no captulo 5 que a implementac~ao do algoritmo de visualizac~ao utizando o
OpenGL introduz atrasos na visualizac~ao sempre que uma textura grande tem que ser
carregada na placa de vdeo. Esse atraso introduz picos no tempo de geraca~o de quadros,
impedindo que estes sejam gerados a uma taxa constante. Alem disso, frequentemente
esses atrasos s~ao t~ao grandes que prejudicam toda a interatividade do programa.
Embora esses tempos de carregamentos n~ao possam ser evitados, e possvel tornar a
taxa de gerac~ao de quadros mais proxima de constante controlando quando os carregamentos s~ao feitos. Esse problema e um caso especial do problema de gerenciamento de
caches para aplicac~oes de visualizaca~o. Do mesmo modo que o tempo de carregamento de
texturas na placa introduz um atraso, o carregamento de texturas armazenadas em disco
para a memoria tambem introduz atrasos. Sendo assim, o problema de gerenciamento
de cache e um problema que tem que ser tratado para que grandes imagens panorâmicas
possam ser visualizadas.
Embora tenhamos implementado esse algoritmo apenas para a visualizac~ao de panoramas, muito do que discutimos aqui se aplica a qualquer aplicac~ao de visualizac~ao,
principalmente aquelas onde o dado sendo visualizado e 2D. Em particular, todas as aplicac~oes de renderizac~ao baseada em imagens podem tomar proveito deste esquema, ja que
certamente tambem precisam carregar algumas imagens para visualizac~ao. Para facilitar a aplicac~ao deste algoritmo em todos os casos, tentaremos tornar a discuss~ao neste
captulo a mais geral possvel.
6.1 Otimizac~ao do Acesso aos Dados

Grande parte das aplicaco~es de visualizaca~o tentam otimizar o tempo de desenho dos
quadros, frequentemente desconsiderando o fato de que o tempo de gerac~ao de quadros
n~ao e somente o tempo para desenhar, mas tambem o tempo de obter os dados dos
dispositivos de armazenamento. Se cuidados especiais n~ao forem tomados, o processo de
renderizac~ao pode ter que ser interrompido para esperar o carregamento dos dados, o que
n~ao pode ser tolerado em um sistema de tempo real.
Isso e especialmente importante em aplicaco~es onde os dados s~ao obtidos de bancos de
dados muito grandes, como em grande parte das aplicac~oes de realidade virtual. Nesses
casos, o conjunto completo de dados e armazenado em um dispositivo de armazenamento
com uma capacidade muito grande e acesso muito lento. Porc~oes menores dos dados po-
CAPITULO 6. GERENCIAMENTO DE CACHE
55
dem ser armazenadas em dispositivos com capacidades menores e de acessos mais rapidos.
A Figura 6.1 ilustra os nveis de armazenamento tpicos para uma aplicaca~o de visualizac~ao. Cada nvel L armazena um subconjunto dos dados no nvel L + 1 e permite um
acesso mais rapido aos seus dados. Assim, dizemos que o nvel L funciona como um cache
para o nvel L + 1. Em geral, os dados so podem ser processados no nvel 0.
Figura 6.1: Nveis de armazenamento utilizados em um sistema de visualizaca~o.

O granho de performance obtido com a utilizac~ao de um cache depende muito do
seu algoritmo de gerenciamento, que determina qual dado deve ser armazenado. Grande
parte dos dispositivos tem algoritmos de gerenciamento de cache gerais, que normalmente
pertencem ao sistema operacional. Tipicamente, esses algoritmos determinam apenas
quais dados devem ser retirados do cache quando algum dado novo deve ser carregado.
Um metodo muito utilizado e o algoritmo Least Recently Used (LRU) que retira do cache
os dados que n~ao s~ao acessados a mais tempo (Silberschatz & Galvin, 1997). Mas no caso
de aplicac~oes de computaca~o graca, pode-se criar um algoritmo melhor considerando-se
a coerência espacial da aplicac~ao.
Muitos algoritmos em computaca~o graca podem ser otimizados considerando a coerência
espacial (Sutherland et al. , 1974). Normalmente os dados sendo visualizados representam
um objeto de dimens~ao m em um espaco Rn. Como os parâmetros de visualizaca~o geralmente variam suavemente com o tempo, os dados visualizados em quadros subsequentes
est~ao geralmente em uma mesma vizinhanca.
A coerência espacial pode ser utilizada para estimar os dados que ser~ao visualizados
em quadros futuros, uma informac~ao valiosa para se determinar quais dados devem permanecer no cache. Mais ainda, pode ser utilizada para pre-carregar dados no cache, antes
de serem utilizados. Neste caso, uma frac~ao do tempo de geraca~o de cada quadro pode
ser reservada para carregamentos no cache. Quando esse tempo n~ao e utilizado para carregar dados do quadro corrente, os dados estimados para quadros futuros podem ser pre
carregados. Se a estimativa for boa, esse algoritmo reduz o numero de quadros onde o
tempo de carregamento ultrapasse um valor desejado.
Funkhouser et al. (Funkhouser et al. , 1992) prop~oem um algoritmo de gerenciamento
de cache para visualizac~ao por "walkthrough"de ambientes 3D. Nesse trabalho, os autores
apresentam a arquitetura de um sistema para a visualizaca~o de ambientes interiores mo-
56
delados. O modelo e armazenado em um banco de dados e algumas partes s~ao copiadas

para um cache em memoria. Os objetos s~ao pre carregados na memoria quando se determina que eles podem ser necessarios para gerac~ao dos proximos quadros. A heurstica
que utilizam para essa determinaca~o, no entanto, e especca para aquela aplicac~ao. Uma
abordagem diferente, mas que tambem utiliza pre carregamento, foi proposta para visualizac~ao de terrenos (Leclerc & Jr., 1994). Porem, este trabalho tambem utiliza heursticas
especcas para esse tipo de aplicaca~o.
O algoritmo de gerenciamento de cache que apresentaremos neste captulo e geral
para visualizac~ao de dados no plano. Embora so tenhamos implementado e testado para
a nossa aplicac~ao de visualizaca~o de panoramas, toda a discuss~ao e feita assumindo esse
tipo de dados mais geral.
Antes de apresentarmos o algoritmo e mostrarmos os resultados, vamos denir o problema de gerenciamento de cache um pouco mais formalmente.
6.2 O Problema Geral

Nessa sec~ao, veremos como um algoritmo de gerenciamento de cache com pre carregamento pode otimizar a visualizaca~o de dados e Mostraremos quais caractersticas da
aplicac~ao e do equipamento podem afetar o gerenciamento de cache.
Como ja vimos, diversos nveis de armazenamento podem ser utilizados em sistemas
gracos e cada um pode ser utilizado como cache para o nvel acima. Na Figura 6.1
vimos exemplos de ta magnetica, servidor de disco na rede, disco local, memoria RAM
e memoria na placa de vdeo. Para que a discuss~ao se aplique a todos os nveis, chamaremos o nvel inferior de cache, o nvel superior de armazenamento principal e o meio de
transmiss~ao de barramento. A Figura 6.2 ilustra essa terminologia.
Figura 6.2: Elementos de um esquema de cache.

Um algoritmo de gerenciamento de cache deve ser adaptado ao nvel de armazenamento, ou seja, deve ser parametrizado pelas caractersticas dos dispositivos. Dois parâmetros
s~ao de grande importância para o gerenciamento de cache:
largura de banda do barramento (bw), que e o numero de bytes que pode ser carregado no barramento por unidade de tempo;
tamanho do cache (cs), que e o numero de bytes que pode ser armazenado no cache.
Geralmente, e mais conveniente representar esses valores em unidades especcas da

aplicac~ao, como polgonos, vertices, imagens, entre outros. Nessa discuss~ao usaremos o
numero de objetos, em geral, para nos referirmos a qualquer um destes elementos.
Como ja mencionamos, o tempo de geraca~o de quadros e formado pelo tempo de
renderizac~ao e o tempo de carregamento dos dados. Para atingirmos uma taxa de gerac~ao
57
de quadros constante, ambos devem ser controlados. Dado um tempo de carregamento

por quadro desejado, lt , e a largura de banda do barramento, bw, o numero de objetos
que podem ser carregados por quadro e dado por bw lt. Chamamos essa quantidade
de throughput (th). O objetivo do algoritmo de gerenciamento de cache e permitir que a
visualizac~ao seja feita com o menor valor de lt possvel.
Se conhecermos os objetos que ser~ao visualizados em todos os quadros, e possvel
determinarmos o tempo de carregamento (lt) mnimo para que uma taxa de quadros
constante seja gerada (assumindo uma largura de banda xa) usando uma determinada
estrategia de gerenciamento de cache. Vamos dizer que no quadro i o algoritmo de gerenciamento carrega lsi tiles. Ent~ao, o tempo mnimo de carregamento por quadro e tal que
o throughput resultante satisfaca:
max
(lsi ) < th;
i
for i = 1; :::; n
(6.1)
onde n e o numero total de quadros na sequência de visualizaca~o.

Os valores de lsi dependem dos objetos renderizados em cada quadro. Digamos que
em cada quadro i, nvsi objetos s~ao visualizados que n~ao foram visualizados em quadros
anteriores. Podemos assumir que nenhum dos nvsi objetos ja esta no cache, ja que
estamos fazendo nossa analise para o pior caso. O algoritmo de gerenciamento de cache
deve garantir que todos esses objetos sejam carregados nos quadros 1; :::; i. Quando pre
carregamento n~ao e utilizado, os objetos s~ao carregados quando s~ao visualizados pela
primeira vez, de modo que lsi = nvsi , e temos ent~ao:
max
(nvsi) < th;
i
for i = 1; :::; n
(6.2)
Analizando essa equaca~o, podemos ver como pre carregamento de objetos pode melhorar a taxa de geraca~o de quadros. A sequência nvsi tem geralmente uma grande variac~ao
entre os termos, possuindo um numero de picos que correspondem aos quadros onde um
grande numero de novos objetos s~ao visualizados. Quando nenhum pre carregamento e
utilizado, esses quadros exigem um tempo de carregamento muito grande, como vimos
nos gracos do Captulo 5. Como lt e o tempo de carregamento mnimo, seu valor e
aumentado para permitir o carregamento durante esses poucos quadros. A Figura 6.3
ilustra os valores de nvsi para uma determinada sequência de visualizaca~o da panorama.
Neste graco, a unidade basica de medida e o pixel.
Por outro lado, quando pre carregamento e utilizado, o carregamento de objetos para
quadros com grandes valores de nvsi pode ser distribudo pelos quadros anteriores que
possuem valores baixos de nvsi. Como resultado, o valor maximo de ls diminui, permitindo que um lt menor seja utilizado. A Figura 6.4 ilustra esse fato. Nela podemos ver
que a distribuic~ao fez com que todos os lsi tenham o mesmo valor.
Para determinarmos o valor mnimo de lt quando pre carregamento e utilizado, notamos pela equac~ao 6.1 que este sera dado pela sequência de lsi com o menor maximo.
Para quaisquer dois quadros i e j , com i > j , se lsi > lsj , ent~ao o seu maximo pode
ser diminudo fazendo lsi = lsj = ls +2 lsj . Isso sempre pode ser feito, ja que os objetos
carregados no quadro i podem tambem ser carregados em j .
Dessa forma, podemos ver facilmente que o throughput mnimo sera dado por:
i
58
Figura 6.3: Graco de objetos carregados por quadro.
Figura 6.4: Graco de tiles carregados no cache por quadro quando pre carregamento e
utilizado.
Pk nvs
i
i=1
max
(
k
k ) < th;
for k = 1; :::; n
(6.3)
Essa equac~ao esta correta apenas se assumirmos th objetos podem ser carregados em
cada quadro, o que pode n~ao ser o caso se o tamanho do cache e muito pequeno. Mais
especicamente, o tamanho do cache seria um problema se este casse completamente
ocupado com objetos que ainda est~ao para ser visualizados. No caso da nossa aplicaca~o,
assumimos que o cache e grande o bastante de modo que isso n~ao aconteca. De qualquer
forma, seria um problema interessante analisar como o tamanho do cache modica a
equac~ao acima.
Ao longo dessa sec~ao, temos assumido que a sequência de objetos visualizados em cada quadro, nvsi , e conhecida, ja que toda a analise depende dos valores desta sequência.
No entanto, podemos usar essa mesma analise para determinarmos diversos parâmetros
59
da aplicac~ao considerando o pior caso. Por exemplo, podemos usar essas equac~oes para
determinar a velocidade maxima com que parâmetros de visualizaca~o podem ser alterados com um throughput (th) desejado. Do mesmo modo, podemos querer determinar o
throughput necessario para que os parâmetros possam ser alterados com uma certa velocidade maxima. Assumindo que os parâmetros se modicam com essa velocidade maxima
constante, pode-se determinar a sequência nvsi resutante, que pode ent~ao ser substituda
nas equac~oes acima.
As equac~oes se aplicam tambem para os casos em que a sequência de nvsi e obtida
de um oraculo, o que e feito na pratica. Nesse caso, o numero de objetos carregados
corretamente depende de qu~ao bom e o oraculo. Um problema interessante seria utilizar
um modelo probabilstico para derivar as equac~oes acima usando propriedades estatsticas
do oraculo. Como veremos na ultima sec~ao, os valores que obtemos com o oraculo que
implementamos s~ao muito proximos dos valores calculados pelas equaco~es.
6.3 Algoritmo
Na sec~ao anterior, discutimos em termos gerais o problema de gerenciamento de cache
com pre carregamento de dados. Mostramos como o throughput mnimo pode ser determinado dada uma sequência de visualizac~ao. Nesta sec~ao, apresentaremos um algoritmo
que resolve o seguinte problema de gerenciamento de cache: dado um throughput desejado, th, e o tamanho do cache, cs, e assumindo que a sequência nvsi seja conhecida, ache
a sequência lsi que minimize err dado por:
err =
ei =
0
n
X
i=1
ei
se lsi th
lsi , th se lsi > th
(6.4)
(6.5)
onde err mede o quanto o throughput mnimo foi ultrapassado.

Se th satiszer a equaca~o 6.3, e a sequência de visualizac~ao for conhecida, o algoritmo
garante que err = 0. Quando a sequência n~ao e conhecida e um oraculo e utilizado, os
resultados do algoritmo dependem de qu~ao bom e o oraculo.
Pela discuss~ao da sec~ao anterior, percebemos que a soluca~o otima e aquela que carrega
todos os objetos necessarios no quadro i antes dos objetos necessarios em j , sempre que
i < j . Ent~ao, um algoritmo otimo deve comecar carregando os objetos do primeiro
quadro. A partir da, os proximos th objetos v~ao sendo carregados a cada quadro, e os
que ja foram renderizados s~ao retirados do cache. Alem disso, chegada a hora de renderizar
um quadro, todos os objetos deste que ainda n~ao foram caregados devem ser, mesmo que
isso ultrapasse o limite th. Objetos carregados incorretamente no cache pelo oraculo s~ao
descarregados assim que o quadro que deveria desenha-los passar.
E facil de se ver que esse algoritmo produz o valor mnimo de err quando a sequência
de visualizac~ao e conhecida. Vamos dizer que, em um determinado quadro i, ei objetos
s~ao carregados acima do limite th. A unica forma que esse quadro poderia ter carregado
menos do que th objetos seria se os ei objetos fossem carregados em quadros anteriores.
60
Mas como nos quadros anteriores, pelo menos th objetos foram carregados por quadro,
essa distribuica~o faria com que o mesmo numero de objetos casse acima do limite th
nesses quadros anteriores.
Desenvolvemos um algoritmo que mantem um controle de todos os objetos a serem
visualizados. Estes podem ser estar em dois estados:
carregados no cache, que s~ao armazenados em uma lista L;

n~ao carregados no cache, que s~ao armazenados em uma lista M .
A cada passo do algoritmo, todos os objetos s~ao classicados com o numero de quadros
estimados ate que eles sejam visualizados. Na pratica, estimamos os objetos visualizados
nos proximos f quadros e classicamos os demais com algum valor maior do que f . A lista
M e percorrida e todos os objetos classicados com 0 (quadro corrente) s~ao marcados para
serem carregados. Se houver menos do th destes elementos, aqueles com menores valores
v~ao sendo marcados para carregamento, ate que th objetos s~ao marcados. Digamos que
ao nal, n objetos s~ao marcados para carregamento. Se ha k posico~es livres no cache,
ent~ao os n , k objetos com maior valor devem ser removidos, assumindo e claro que
esse valores s~ao maiores do que aqueles dos objetos marcados para carregamento. Ent~ao
percorremos a lista L e marcamos esses n , k elementos para descarregamento. Ao nal,
trocamos os objetos com menor valor marcados para carregamento com os objetos de
maior valor marcados para descarregamento, e continuamos com essa operac~ao ate que
todos os objetos marcados sejam processados, ou ate que o proximo objeto marcado para
caregamento tenha um valor maior do que o proximo marcado para descarregamento. Na
Figura 6.5 mostramos o pseudo-codigo do algoritmo.
Para analizarmos a complexidade deste algoritmo, chamamos de t o numero total de
objetos. Vemos logo que a complexidade deste algoritmo depende da complexidade do
oraculo para classicar todos os objetos. No caso da nossa implementaca~o, esta classicac~ao tem complexidade O(t). Notamos que o algoritmo possui alguns percorrimentos
das listas M e L, o que tem coplexidade O(t). Notamos tambem que ha operac~oes para
obter os maiores n elementos de uma das listas, os n , k maiores elementos da outra
e duas ordenac~oes em listas de tamanho n. Como n pode ser da ordem de t, quando
todos os objetos s~ao visualizados, a complexidade de pior caso do algoritmo e O(t log t).
Na pratica, dicilmente esse pior caso se verica, especialmente quando a imagem possui
muitos objetos, pois dicilmente todos s~ao visualizados.
Comparando este algoritmo com o LRU, muito utilizado em esquemas de gerenciamento de cache, vemos que o LRU e semelhante a menos da parte de classicac~ao dos
objetos. Esse algoritmo seria o equivalente a ter todos os objetos descarregados classicados com 1, menos os do quadro corrente, que seriam classicados com 0. Na lista de
objetos carregados, eles seriam classicados com o numero de quadros desde que foram
visualizados pela ultima vez. Dessa forma, n~ao e feito nenhum pre carregamento, e os
objetos usados menos recentemente s~ao retirados do cache a cada passo.
6.4 Visualizac~ao de Dados no Plano

Na sec~ao anterior, apresentamos um algoritmo de gerenciamento de cache assumindo
que tnhamos um oraculo que estimava os objetos que seriam visualizados em quadros
61
Figura 6.5: Algoritmo de gerenciamento de cache com pre carregamento
for each frame do
label all objects using oracle

empty list P
empty list Q
for each element x of list M do
if label(x) = 0 then
insert x into P
end if
end for
m
size(P )
if m < th then
insert the smallest th , m elements of M into P
m size(P )
end if
k number of free positions in the cache

insert the largest m , k elements of L into Q
sort P in ascending order
sort Q in descending order
for each element x of P and y of Q do
if x < y then
switch x and y
load x
unload y
end if
end for
end for
futuros. O oraculo foi visto como uma caixa preta porque seu funcionamento depende
de caractersticas especcas de cada aplicaca~o. Nessa seca~o, apresentamos detalhes deste
oraculo para visualizac~ao de conjuntos de dados bidimensionais.
Para simplicar a discuss~ao, assumimos que o plano pode ser subdividido em pequenas
regi~oes retangulares, que chamamos de tiles, e que o tamanho dos objetos no interior de
cada tile e o mesmo. Essa condic~ao e realista para muitas aplicaco~es, como a propria
visualizac~ao de panoramas, e e estatisticamente realista em outras. De qualquer forma,
este fato n~ao ira afetar nossa analise.
Assumimos ainda que a regi~ao do plano sendo visualizada e retangular, o que e razoavel para muitas aplicac~oes. Caso n~ao seja podemos assumir que o algortimo utiliza o
fecho retangular da regi~ao visualizada. Sendo assim, os parâmetros de visualizac~ao s~ao
representados por uma janela no plano, a janela de visualizac~ao, parametrizada pelos seus
quatro vertices. Para cada quadro, os tiles dentro desta janela s~ao os tiles visualizados, o
que esta ilustrado na Figura 6.6.
Para predizer os tiles que ser~ao desenhados em quadros futuros, o oraculo deve estimar
a janela de visualizaca~o para esses quadros. Isso e feito aproximando-se a velocidade e
acelerac~ao dos vertices da janela de visualizaca~o baseado em suas posic~oes anteriores.
62
Figura 6.6: Os tiles escuros est~ao sendo visualizados no quadro corrente.

Assim, dado o numero de quadros adiante cuja janela de visualizaca~o se deseja calcular,
faz-se uma aproximaca~o quadratica para achar essa janela.
Utilizando essas estimativas e a janela corrente, o oraculo marca cada tile usando dois
criterios distintos.
1. temporal;
2. espacial.
O criterio temporal classica os objetos de acordo com as posico~es estimadas da janela
de visualizac~ao em quadros futuros. Tiles que ser~ao visualizados nos proximos quadros
recebem valores menores do que tiles que so ser~ao visualizados mais tarde. A Figura 6.7
mostra como os tiles s~ao marcados com esse criterio para uma janela se movendo para o
lado.
Figura 6.7: Tiles classicados segundo o criterio temporal.

Esse criterio sozinho no entanto gera resultados ruins em alguns casos. Quando a
velocidade da janela de visualizac~ao sofre uma mudanca repentina, nenhum dos tiles que
passam a ser visualizados ter~ao sido pre carregados, pois n~ao pertenciam a nenhuma
estimativa futura. Alem disso e possvel que n~ao haja tempo suciente para carrega-los
antes que tenham que ser renderizados. Para resolver esse problema, seria interessante
que alguns tiles ao redor da janela de visualizac~ao corrente tambem recebessem valores
baixos, independente da movimentac~ao. Dessa forma, esses tiles podem ser pre carregados
tambem, cuidando do caso que mencionamos de uma mudanca brusca de direca~o de
visualizac~ao. Isso e feito pelo criterio espacial.
63
Utilizando o criterio espacial, cada tile recebe um valor determinado pela sua proximidade com a janela de visualizaca~o corrente. Tiles perto desta janela recebem valores
menores do que tiles mais distantes. Esse criterio tambem funciona bem nos casos em
que a janela corrente esta parada e todas as velocidades e acelerac~oes s~ao nulas. Quando
isso ocorre, todas as janelas futuras coincidem com a janela corrente. O criterio espacial
carrega os tiles ao redor desta janela sem dar preferência a nenhuma direca~o, o que e o
correto ja que, neste caso, n~ao se pode estimar como sera a proxima janela de visualizac~ao.
A Figura 6.8 mostra como os tiles s~ao marcados somente baseado no criterio espacial.
Figura 6.8: Tiles classicados segundo o criterio espacial para um unico nvel da multiresoluc~ao.
Uma quest~ao que ainda n~ao mencionamos e como combinar os dois criterios. Essa
decis~ao depende do tipo de visualizaca~o que provavelmente sera feita. Se o usuario tender
a mudar a direc~ao de visualizaca~o bruscamente e frequentemente, o criterio espacial deve
ter mais peso. Se por outro lado as mudancas forem suaves, o criterio temporal deve
ter mais peso. Na visualizaca~o de panoramas, permitimos que esse peso seja variado
atraves de um parâmetro, F , na equac~ao do valor nal. Seja Lt o valor devido ao criterio
temporal, e Ls o correspodente ao criterio espacial. Ent~ao o valor nal, Ls sera dado por:
80
<
Lf = : F + Ls
Lt + Ls
se tile 2 quadro corrente

se tile 2= quadros futuros
se tile 2 quadros futuros
Podemos pensar no parâmetro F como colocando uma penalidade nos tiles que n~ao
est~ao nos quadros futuros. Quanto maior essa penalidade mais valor se da ao criterio
temporal. Em nossa aplicaca~o um valor de 20 pareceu dar um resultado desejavel.
6.5 Aplicac~ao na Visualizac~ao de Panoramas

O algoritmo descrito acima para visualizaca~o de dados no plano pode ser facilmente
aplicado para a visualizac~ao de panoramas. Para isso, a imagem panorâmica deve ser subdividida em tiles de tamanhos iguais, que ser~ao as unidades de manipulaca~o do algoritmo
de gerenciamento de cache. A Figura 6.9 ilustra essa divis~ao.
No Captulo 5 a imagem panorâmica tambem era dividida em uma grade retangular
para aproximac~ao poligonal da transformac~ao. Esses duas grades, de aproximaca~o poligonal e de tiles, n~ao precisam necessariamente coincidir. A primeira e determinada para
que seja uma boa aproximac~ao da transformac~ao, enquanto que a segunda e determinada
64
Figura 6.9: Uma imagem panorâmica subdividida em tiles.

como func~ao do throughput desejado. Para a placa de vdeo em que implementamos o
algoritmo, zemos alguns testes e vericamos que um bom tamanho para os tiles e de
64 64 pixels. Esse tamanho e tal que o carregamento de um tile por quadro n~ao parece
afetar o tempo de desenho da aplicaca~o.
Nessa implementac~ao, assumimos que a imagem panorâmica cabe totalmente na memoria
RAM. Dessa forma o unico cache que temos que gerenciar e o primeiro nvel, na placa de
vdeo. No proximo captulo veremos exemplos de visualizac~ao de imagens muito maiores.
O carregamento e descarregamento na placa e feito pelo OpenGL. Para que isso seja
feito individualmente, cada tile esta associado a um objeto de textura diferente do OpenGL(Woo, 1998). O carregamento e feito desenhando-se o tile no backbuer uma vez, o
que causa o seu carregamento para a placa mas n~ao faz com que apareca para o usuario.
Para controlar quais tiles permanecem no cache, utilizamos o esquema de prioridades de
textura do OpenGL. Esse mecanismo permite que o usuario especique, para cada textura, uma certa prioridade e a implementac~ao tenta manter em memoria aqueles objetos de
textura com maior prioridade. Assim, para manter um tile no cache este e desenhado com
prioridade 1. Para descarrega-lo basta fazer com que sua prioridade volte para 0, de modo
que, quando o cache for totalmente preenchido, esse tile sera certamente descarregado.
A janela de visualizac~ao e calculada pelos parâmetros da câmera virtual, sendo determinada a partir da intersec~ao desta com a superfcie panorâmica. Como em geral essa
regi~ao e complexa, toma-se o seu fecho retangular. A Figura 6.10 ilustra essa regi~ao para
uma panorama cilndrica.
Figura 6.10: A janela de visualizac~ao em uma imagem panorâmica cilndrica.

Na proxima sec~ao apresentamos os resultados da aplicaca~o destes algoritmo de gerenciamento de cache para a visualizac~ao de algumas panoramas.
65
6.6 Resultados
Testamos a implementac~ao destes algoritmos em uma maquina com processador Pentium II 300 MHz, com 128 MB de memoria RAM e uma placa de vdeo Diammond
FireGL4000, que possui 16 MB de memoria de textura.
Utilizamos a mesma panorama dos testes no Captulo 5. Dessa vez, no entanto, pedimos para um numero de usuarios interagir com a panorama e gravamos suas sequências
de visualizac~ao.
Para cada sequência gravada, podemos determinar quais tiles s~ao visualizados em cada
quadro, e consequentemente o valor de nvs para cada um. O graco da Figura 6.3 ilustra
esses valores para a primeira sequência de visualizac~ao gravada.
Implementamos o algoritmo usando três estrategias de gerenciamento de cache diferentes, e armazenamos os valores de lsi em cada caso. As três estrategias s~ao:
1. sem pre carregamento de dados;
2. pre carregamento de dados utilizando a sequência gravada para determinar os parâmetros
de visualizac~ao em quadros futuros (exato);
3. pre carregamento de dados utilizando o oraculo para estimar os parâmetros de visualizaca~o em quadros futuros.
A implementac~ao do algoritmo sem pre carregamento, que e semelhante ao LRU,
resulta em uma sequência de lsi igual a sequência de nvsi, como esperavamos. Com essa
estrategia, o valor mnimo de th que poderia ser utilizado e dado pelo maior valor de nvs.
Para a primeira sequência gravada, ilustrada na Figura 6.3, esse valor e de 98394 pixels.
A segunda estrategia usa a sequência gravada para pre carregar os tiles. Pode ser
utilizada para testar nossa armac~ao de que o algoritmo da uma soluca~o otima quando
os nvsi s~ao conhecidos, o que ja provamos na teoria. Usando os valores da sequência
gravada, calculamos o valor de th atraves da equaca~o 6.3. Para a primeira sequência,
determinamos que th e 6155 pixels. Modicamos ent~ao o algoritmo para que carregue
três tiles por quadro, 6144 pixels, e repetimos a sequência gravada. A Figura 6.4 ilustra
o numero de pixels carregado em cada quadro, que esta sempre abaixo do valor calculado
de th como tnhamos previsto.
Finalmente, testamos o algoritmo utilizando o oraculo. O graco da Figura 6.11 ilustra
os valores de lsi para a primeira sequência. Comparando esse graco com o obtido para
o segundo teste, podemos ver os efeitos do oraculo sobre o algoritmo.
Em grande parte dos quadros, os valores est~ao abaixo do th calculado. Para alguns
quadros, no entanto, est~ao muito acima. Com isso, para que o taxa de gerac~ao de quadros
seja constante, o valor de th para esse caso teria que ser aumentadopara 22508, o que e
feito aumentando-se o tempo de carregamento por quadro. Esse valor e aproximadamente
quatro vezes o otimo, mas ainda muito melhor do que o algoritmo sem pre carregamento.
Notamos ainda que esses valores acima de th ocorrem apenas para 7 quadros, de um total
de 904. Assim, para grande parte das aplicac~oes n~ao seria um grande problema manter o
valor de th como o mnimo calculado e permitir que a taxa deixe de ser constante nesses
7 quadros.
Esses testes mostram que o oraculo que propomos pode funcionar muito bem, o que se
conrmou em outros testes semelhantes. Na Figura 6.12 podemos ver a classicac~ao cada
66
Figura 6.11: Graco do numero de pixels carregados por quadro, com pre carregamento
e utilizando o oraculo.
tile usando o esquema apresentado (tiles claros possuem numerac~ao menor). A gura
tambem mostra as janelas de visualizac~ao passadas, corrente e estimadas.
Figura 6.12: Um pedaco da sequência de visualizac~ao gravada. A janela de visualizac~ao

corrente esta desenhada em branco, as janelas anteriores em cinza claro e as futuras em
cinza escuro.

Neste captulo apresentamos um algoritmo de gerenciamento de cache que pode ser utilizado para tornar o tempo de gerac~ao de quadros mais proximo de constante, controlando
o tempo de carregamento de dados no cache. Mostramos resultados dessa implementac~ao
na visualizac~ao de panoramas que evidenciam o funcionamento correto do algoritmo.
A utilizac~ao de um algoritmo como este esta cando cada vez mais importante em
aplicac~oes de visualizac~ao em tempo real. Os dados utilizados por muitas dessas aplicac~oes
est~ao cando cada vez mais complexos e exigindo mais espaco, o que faz com que a
utilizac~ao de dispositivos de armazenamento com acesso lento sejam utilizados. Alem
disso, muitas operac~oes de visualizac~ao s~ao implementadas em hardware, sendo assim
bastante ecientes, o que faz com que o tempo de acesso aos dados se torne o principal
gargalo dessas aplicac~oes.
Apesar de termos desenvolvido esse algoritmo para a visualizac~ao de panoramas, ele
pode ser utilizado em um grande numero de aplicac~oes que mostram dados em 2D. Uma
classe dessas aplicac~oes s~ao os Sistemas Geogracos de Informaca~o (GIS), onde tipicamente uma grande quantidade de dados relativa a alguma regi~ao geograca e mostrada
na tela. Esses dados est~ao muitas vezes armazenados em um grande banco de dados,
67
que pode estar em algum servidor central, de modo que varios nveis de cache podem ser
necessarios.
Finalmente, notamos que o modelo cache, barramento e armazenamento principal e
mais util do que pode parecer. O cache e o armazenamento principal n~ao precisam ser
necessariamente dois dispositivos fsicos diferentes, mas podem representar duas formas
de armazenamento diferentes em um mesmo dispositivo. O barramento, por sua vez, n~ao
prescisa ser uma linha fsica de transmiss~ao de dados, mas pode representar um processo
de modicac~ao do estado dos dados. Por exemplo, os dados podem ser comprimidos e
armazenados em um disco. Esse mesmo disco pode ter uma pequena regi~ao reservada
para armazenamento de parte dos dados descomprimida. Podemos considerar ent~ao que
os dados comprimidos est~ao no armazenamento principal, os dados descomprimidos est~ao
no cache e o barramento e o processo de descompress~ao, com a largura de banda (bw)
dada pela quantidade de dados que pode ser descomprimida por unidade de tempo. Toda
a analise que zemos neste captulo se aplica a essa situac~ao. Diversos problemas podem
ser modelados como um problema de cache, e logo s~ao aplicaco~es para o algoritmo que
propomos.
Uma quest~ao que n~ao consideramos neste captulo e o que fazer quando o tempo
de carregamento mnimo por quadro, calculado pela equac~ao 6.3 for acima do desejado.
Conforme mencionamos, o algoritmo garante que, quando a sequência for conhecida,
nenhum carregamento e feito acima do mnimo calculado. Mas se esse mnimo for acima
de algum valor desejado, algo diferente deve ser feito.
A unica forma de resolvermos esse problema e limitando-se a quantidade de dados
visualizada em cada quadro, o que reduz os valores de nvsi e consequentemente o th
mnimo calculado. Veremos no proximo captulo como isso pode ser feito para visualizac~ao
de panoramas.
Captulo 7
Panoramas em Multiresoluc~ao
No captulo anterior, apresentamos um esquema de gerenciamento de cache que controla o tempo de acesso aos dados para visualizac~ao. O algoritmo permite que se especique
a quantidade de dados que pode ser carregado por quadro no cache, sem afetar a visualizac~ao, o que chamamos de throughput (th). Essa quantidade e determinada de modo
que o tempo de seu carregamento somado ao tempo de renderizac~ao dos dados permita uma taxa interativa de geraca~o de quadros, e normalmente precisa ser determinada
experimentalmente. Com isso, o algoritmo distribui o carregamento dos dados de modo
que a cada quadro apenas o throughput especicado seja carregado. Mostramos que se
esse thoughput for maior do que um throughput mnimo calculado para a sequência de
visualizac~ao, o algoritmo faz com que o tempo de acesso aos dados em cada quadro seja
aproximadamente constante e raramente ultrapasse o valor especicado. A proximidade
de um comportamento constante depende de um oraculo utilizado pelo algoritmo.
Mas quando o throughput desejado for menor do que o mnimo calculado para uma
determinada sequência de visualizac~ao, o algoritmo de gerenciamento de cache n~ao pode
garantir a taxa constante de gerac~ao de quadros nesta sequência. Nessa caso, a unica
soluc~ao e diminuir o mnimo calculado, o que pode ser feito reduzindo a quantidade de
dados visualizada em cada quadro.
No caso da visualizac~ao de panoramas isso pode ser feito sem perda de qualidade
representando a imagem panorâmica por uma estrutura de multiresoluca~o, ou pirâmide
de imagens.
7.1 Pirâmide de Imagens

No Captulo 5 mencionamos que durante o processo de reamostragem poderia ocorrer
uma contrac~ao ou uma expans~ao da imagem panorâmica, dependendo no a^ngulo de zoom.
Na realidade, algumas superfcies panorâmicas podem expandir a imagem em uma regi~ao
e contrair em outra. Porem, para ângulos de zoom pequenos (ou grandes) as deformac~oes
tendem a contrair (expandir) apenas.
Quando ocorre uma expans~ao muito grande, a qualidade da imagem resultante sera
ruim, pois a amostragem na tela sera muito mais densa do que a da imagem panorâmica.
Em outras palavras, uma imagem do ambiente capturada com a taxa de amostragem da
tela, seria muito mais detalhada do que a imagem mostrada pelo sistema de panoramas
virtuais. Para evitar que isso aconteca, deve-se utilizar uma imagem panorâmica de maior
~
CAPITULO 7. PANORAMAS EM MULTIRESOLUCAO
69
resoluc~ao, ou ent~ao limitar os menores valores possveis de hFOV e vFOV .

Por outro lado, quando ocorre contrac~ao, muitos pixels da imagem panorâmica s~ao
mapeados em apenas um pixel da tela. Quando isso acontece, a qualidade da imagem
resultante e boa, pois pode-se fazer uma media de todos os pixels que mapeiam em cada
pixel da tela. Porem, a quantidade de pixels que se processa e muito maior do que seria
necessario, pois muitos pixels tem pouca contribuic~ao para a imagem nal.
Idealmente cada pixel da imagem deveria ser mapeado em um pixel da tela, independente da janela de zoom. Isso seria possvel se a imagem panorâmica mudasse sua
resoluc~ao sempre que o tamanho da janela de visualizac~ao mudasse, de modo que o numero
de pixels dentro dessa janela na imagem panorâmica fosse constante. Com isso, a quantidade de dados processada pelo algoritmo de visualizaca~o seria sempre a mesma. Alem
disso, a qualidade da imagem resultante seria inalterada.
Com isso, se resolveria tambem os problemas do gerenciamento de cache apresentados
acima. Como a quantidade de dados visualizados e sempre a mesma, a quantidade de
dados que precisa ser carregada por quadro tambem n~ao muda. Assim, o algoritmo
funciona da mesma forma em qualqer tamanho de imagem.
Embora n~ao exista tal imagem com resoluc~ao variavel, podemos aproxima-la por uma
estrutura de mutiresoluc~ao, ou pirâmide de imagens. Em uma priâmide, uma imagem e
armazenada em sua resoluc~ao original e em resoluco~es reduzidas pela metade, formando
uma escala diadica que tamanhos. A Figura 7.1 ilustra uma pirâmide desse tipo.
Figura 7.1: Pirâmide de Imagens.

Podemos pensar nessa pirâmide como uma amostragem de todas as resoluco~es possveis
que a imagem poderia assumir se tivesse resoluca~o variavel. Dada uma regi~ao da panorama
sendo visualizada, podemos escolher qualquer nvel da pirâmide para efetuar a reamostragem. E sempre possvel escolher um nvel onde o mapeamento entre pixels da imagem
e da tela seja aproximadamente 1:1. Mais especicamente, seja r a raz~ao entre o numero
de pixels na regi~ao visualizada e o numero de pixels na tela. Se assumirmos que esta
regi~ao e retangular e tem a mesma raz~ao de aspecto que a tela, ent~ao podemos sempre
escolher um nvel da pirâmide onde 0:5 r 2. E facil ver isso, pois se r fosse maior do
que 2, escolhendo o nvel abaixo na pirâmide teramos um quarto do numero de pixels,
de modo que o novo r iria satisfazer 0:5 < r. Do mesmo modo, se r for menor do que
0.5, poderamos escolher o nvel acima da pirâmide, que teria quatro vezes mais pixels,
~
70
fazendo com que o novo r satisfaca r < 2. Dessa forma, e sempre possvel manter o valor
de r entre 0.5 e 2, ou seja proximo de 1. Ao longo dessa discuss~ao, chamaremos o nvel
escolhido dessa maneira para uma determinada janela de visualizaca~o de nvel otimo.
Embora em grande parte das superfcies a regi~ao visualizada n~ao sera exatamente
retangular, ela poder geralmente ser bem aproximada pelo seu fecho retngular.
Uma outra quest~ao que n~ao estamos considerando e que geralmente a pirâmide e
limitada, possuindo uma resoluc~ao maxima. Sendo assim, e possvel que a janela de
visualizac~ao que t~ao pequena que o nvel otimo n~ao exista. No caso da nossa aplicac~ao,
vamos assumir que os ângulos de zoom podem sempre ser limitados, de modo que o nvel
otimo para a menor janela seja o ultimo.
O primeiro autor a propor a representaca~o de imagens por uma pirâmide foi Lance
Williams (Williams, 1980). Neste trabalho, ele apresenta uma representac~ao para mapeamento de textura, o mip map, que e essencialmente a pirâmide de imagens apresentada.
Em um mip map, a textura e acessada por parâmetros u, v e d. Os dois primeiros
determinam o mapeamento da imagem na superfcie, enquanto d determina qual nvel
da pirâmide deve ser utilizado neste mapeamento. Esse parâmetro pode assumir valores
reais indicando que dois nveis devem ser interpolados. O autor sugere que o parâmetro d
seja determinado para cada pixel da tela segundo o tamanho da area da textura que sera
mapeada neste pixel, o que pode ser feito durante a rasterizac~ao.
O mip map e utilizado para representar texturas em um grande numero de sistemas de
visualizac~ao e de bibliotecas de computac~ao graca 3D, como o OpenGL (Woo, 1998) por
exemplo. Apesar disso, essa representaca~o possui algumas limitac~oes para a visualizac~ao
de panoramas.
Em primeiro lugar, a representac~ao por mip map e composta de uma unica pirâmide
em que toda a imagem e armazenada em todos os nveis. Mas para a visualizac~ao de panoramas, gostaramos de poder representar apenas algumas partes da imagem em resoluc~oes
mais altas, que corresponderam a regi~oes da imagem com maiores detalhes. Para vermos
a importância disto, imagine uma panorama de uma paisagem urbana. N~ao e necessario
que se tenha regi~oes correspondentes ao ceu em resoluc~oes muito altas. Por outro lado,
regi~oes onde muitos detalhes est~ao sendo mostrados de alguma parte da cidade devem ser
representadas em resoluc~oes altas. Assim, conseguimos comprimir a imagem sem muita
perda de qualidade.
Outra limitaca~o do mip map se refere a sua implementac~ao no OpenGL em especco.
Vimos no captulo anterior como fazemos o carregamento de tiles na memoria da placa
de vdeo, representando cada tile como um objeto de textura. Se tivessemos utilizado o
esquema de mip map do OpenGL n~ao poderamos determinar o carregamento de cada
nvel separadamente.
Por esses motivos, vamos utilizar uma estrutura um pouco mais exvel do que o mip
map.
7.2 Pirâmide de Tiles

Assim como no algoritmo de gerenciamento de cache, na estrutura de pirâmide de
imagens, a unidade basica sera os tiles. Cada nvel da pirâmide e formado por uma
matriz de tiles, como mostra a Figura 7.2. Seja l h o tamanho dessa matriz no nvel 0
da pirâmide, que e o nvel com a imagem de menor resoluc~ao. Ent~ao o k-esimo nvel tem
~
71
tamanho 2k l 2k h. Seja n o numero de nveis da estrutura, o ultimo nvel tera tamanho

2nl 2nh. Podemos dizer que essa estrutura e na realidade uma pirâmide de tiles, ao
inves de uma pirâmide de imagens.
Figura 7.2: Cada nvel da pirâmide e uma matriz de tiles, com tamanhos crescentes.
Cada tile nesta estrutura pode ser unicamente identicado pelo nvel a que pertence
e pela posic~ao neste nvel. Sendo assim, chamaremos de ti;j;k o tile no nvel k, linha i
e coluna j . A regi~ao da imagem representada por um tile ti;j;k, e representada no nvel
k + 1 pelos tiles t2i;2j;k+1, t2i+1;2j;k+1,t2i+1;2j+1;k+1 e t2i;2j+1;k+1 (Figura 7.3). Sendo assim,
podemos dizer que esses quatro s~ao lhos do tile ti;j;k .
Figura 7.3: Cada tile na estrutura pode ter quatro lhos que representam a mesma regi~ao
com o dobro de resoluc~ao.
Para permitir que nem toda a imagem seja representada em todos os nveis de resoluc~ao, n~ao exigimos que todos os nveis estejam completos. Mas faremos a restric~ao de
que um tile so pode existir, se todos os seus ancestrais existirem. Essa retric~ao e bastante
razoavel ja que a existência de um tile signica que a area representada por ele possui
detalhes no nvel da pirâmide a que pertence. Se isso e verdade, ent~ao essa mesma regi~ao
tem que possuir detalhes tambem nos nveis de menor resoluca~o. Com essa restric~ao, a
pirâmide pode ser representada por uma arvore, onde cada no esta associado a um tile e
pode ter quatro lhos. Faremos uma segunda restrica~o a essa estrutura de que quando
um no tem algum lho, tera todos os quatro. Essa estrutura e semelhante a uma quadtree
~
72
incompleta, e esta ilustrada na Figura 7.4, onde os quadrados em cinza representam os

tiles existentes.
Figura 7.4: A pirâmide de tiles e representada por uma arvore tipo quadtree. Os quadrados em cinza correspondem a tiles existentes.
Da mesma forma que a pirâmide de imagens garante que o numero de pixels visualizados n~ao varie muito, a pirâmide de tiles garante que o numero de tiles visualizados
permaneca proximo de constante. Na realidade, a arvore de tiles e ainda melhor, pois
nem todos os tiles existem nos nveis mais altos e o numero de tiles pode ate ser reduzido
quando esses nveis s~ao otimos. Uma vez que o algoritmo de gerenciamento de cache e as
rotinas de desenho operam sobre tiles, essa estrutura permite a visualizac~ao de imagens
muito grandes sem que a taxa de geraca~o de quadros seja muito modicada.
Veremos agora como essa estrutura pode ser criada a partir de uma imagem.
7.2.1 Criac~ao da Estrutura
Para visualizar panoramas com imagens representadas pela estrutura apresentada acima, devemos criar essa estrutura a partir de uma unica imagem panorâmica, que chamaremos de imagem original.
A imagem original deve corresponder a imagem armazenada no ultimo nvel da arvore,
ja que n~ao faz sentido criarmos algum nvel com mais resoluca~o do que a imagem original.
Vamos dizer que queremos criar uma arvore com n nveis. Seja t t as dimens~oes dos
tiles. Assumimos que a imagem original tem tamanho 2nwt 2nht para algum h e w.
Isso signica que a imagem tem o tamanho de uma matriz de tiles cujas dimens~oes s~ao
multiplas de 2n. Se esse n~ao for o caso, ela pode ser escalada para o menor tamanho que
satisfaca essa equac~ao e seja maior do que o tamanho original.
No nvel mais alto e criada uma nova imagem igual a original, mas onde os pixels s~ao
armazenados por ordem de tiles, ou seja, primeiro os pixels do primeiro tile, depois os
pixels do segundo tile, etc. Isso e importante ja que o acesso aos dados da imagem sera
feito um tile por vez. Depois disso a imagem original e escalada para criar o nvel anterior
na pirâmide. Como a imagem neste nvel tem a metade das dimens~oes da imagem original,
a regi~ao representada por um pixel nessa nova imagem e representada por quatro pixels
na imagem original. Sendo assim, esse processo de escalamento faz com que cada pixel
na nova imagem seja a media dos quatro pixels correspondentes na imagem original. Isso
e feito aplicando um ltro passa baixa do tipo box com kernel de tamanho 2 na imagem
~
73
original (anti-aliasing) e depois fazendo amostragem pontual no resultado. A Figura 7.5

ilustra esse processo.
Figura 7.5: As imagens dos nveis inferiores s~ao criadas aplicando o ltro box de tamanho
dois e fazendo amostragem pontual.
Apos esse escalamento, uma nova imagem e criada que e igual a esta escalada, mas
com os pixels organizados por ordem de tiles. O processo e ent~ao repetido diversas vezes
ate que se chegue ao primeiro nvel da estrutura.
A soma dos tamanhos de todas as imagens da estrutura piramidal sera naturalmente
maior do que a imagem original, pois os dados desta s~ao repetidos nos diferentes nveis.
Se a imagem original tiver tamanho 2nwt 2nht pixels, ent~ao a soma dos dados de todas
as imagens da pirâmide tera tamanho 2n+1wt 2n+1 ht pixels, ou seja, sera quatro vezes a
original. Com isso, imagens grandes se tornam ainda maiores, o que pode ser um problema
para o visualizador.
Para diminuir esse problema, permitimos que uma simplicac~ao seja feita na estrutura durante a sua criaca~o. Essa simplicaca~o consiste em n~ao adicionar todos os tiles a
estrutura, mas apenas aqueles que introduzem um certo nvel de detalhes em relaca~o aos
seus ancestrais. Durante o processo de criaca~o, os dados para um tile so s~ao adicionados
ao nvel da pirâmide se uma condic~ao de comparac~ao com o nvel anterior for satisfeita.
Atualmente, essa comparac~ao e feita da seguinte forma. Passamos o ltro box no tile inicial, do mesmo modo que fazemos para o escalamento. Nesse processo alguma informac~ao
e perdida, que corresponde as altas frequências retiradas pelo ltro. Calculamos ent~ao
um novo tile, que chamamos de t, como sendo a diferenca do tile inicial e do tile ltrado.
Os pixels de t nos da uma indicaca~o de quanto de detalhe esta presente no tile inicial.
Utilizamos ent~ao a seguinte heurstica. Seja tmax a luminância maxima em t, e seja tmean
a luminância media. Ent~ao, o tile inicial e adicionado a estrutura se:
tmax > (1 , q) 255
(7.1)
tmean > (1 , q) 200
(7.2)
ou
onde q e um numero entre 0 e 1 que indica a qualidade desejada.

Os valores de 255 e 200 foram obtidos apos alguns testes com panoramas. Quando q
for proximo de 0, dicilmente essas equaco~es ser~ao satisfeitas, de modo que poucos tiles
ser~ao adicionados a estrutura. Quando q e proximo de 1, praticamente todos os tiles
ser~ao adicionados. Para outros valores de q apenas os tiles com maiores detalhes ser~ao
~
74
adicionados. As Figuras 7.6 e 7.7 ilustram duas pirâmides geradas a partir da mesma
imagem panorâmica com valores de q diferentes. Note que as regi~oes que realmente
parecem ter mais detalhes s~ao mantidas nos nveis de maior resoluc~ao. Nesse caso, a
imagem panorâmica original tinha 6 MB, a pirâmide simplicada com q = 0:5 cou com
4.23 MB e a pirâmide simplifcada com q = 0:3 cou com 2.69 MB. A diferenca de qualidade
entre as três, principalmente entre a imagem original e a simplicada com q = 0:5, e muito
pequena. Assim, vemos que essa simplicac~ao e uma boa forma de compress~ao, embora
com perda.
Figura 7.6: Uma pirâmide de 4 nveis simplicada usando fator de qualidade q=0.5.
Outros esquemas mais poderosos poderiam ter sido utilizados na simplicaca~o. Poderamos por exemplo aplicar a transformada de Fourier no tile e determinar se este deve
ser includo baseado nas frequências mais altas presentes. Outra possibilidade seria representar o tile em uma base de wavelets. Nesse caso os coecientes de detalhe horizontal,
vertical e diagonal poderiam determinar o nvel de detalhe presente. Decidimos pelo esquema que apresentamos pois parece funcionar bem e n~ao exige praticamente nenhum
processamento a mais no processo de criaca~o da estrutura.
7.2.2 Visualizac~ao da Pirâmide
O processo basico de visualizac~ao da imagem panorâmica representada pela pirâmide

de imagens e apenas um pouco mais complexo do que para visualizaca~o de uma unica
imagem. A principal diferenca e que precisamos determinar quais nveis da pirâmide
ser~ao utilizado para desenhar, o que deve ser feito de acordo com o tamanho da janela de
visualizac~ao.
Dados os parâmetros de visualizaca~o, calculamos a interseca~o do cone de vis~ao com
a superfcie panorâmica e achamos a area equivalente na imagem panorâmica. Tomamos o fecho convexo dessa area como sendo uma aproximaca~o da janela de visualizac~ao.
Procuramos ent~ao o nvel da pirâmide onde o numero de pixels no interior da janela de
~
75
Figura 7.7: A mesma pirâmide da gura anterior simplicada usando fator de qualidade
q=0.3.
visualizac~ao seja o mais proximo, porem ainda maior, do numero de pixels na tela. Esse
nvel e tomado como nvel otimo. Todos os tiles no interior da janela de visualizac~ao no
nvel otimo e no nvel anterior ser~ao desenhados.
Na realidade e feito um "blending"entre os dois nveis, cujo fator e determinado pela
raz~ao r dos dois nveis. Assim, durante uma operaca~o de zoom, os nveis v~ao sendo
interpolados suavemente, sem que o usuario perceba. Esse blending e feito da sequinte
forma. Calculamos o bounding box da regi~ao sendo visualizada na panorama e assumimos
que essa regi~ao sera mapeada na tela inteira. Para cada uma das dimens~oes da janela,
altura e largura, calculamos a raz~ao entre o tamanho da regi~ao e o tamanho da panorama
inteira. Baseado nisso, determinamos o numero de pixels que deveria ter a panorama para
que o mapeamento de pixels da panorama para pixels da tela seja 1:1. Achamos ent~ao o
menor nvel da pirâmide com um numero maior de pixels do que o calculado, que e o nvel
otimo. Como o calculo e feito independentemente para a altura e a largura da janela, o
maior entre os dois nveis e utilizado. O fator de "blending"entre este nvel e o anterior e
dado por:
, no)
b = 1 , 2 (nc
nc
(7.3)
Onde nc e o numero de pixels no nvel utilizado e no e o numero de pixels que a

imagem panorâmica deveria ter. Note que na medida em que no varia entre nc e nc=2,
numero de pixels do nvel abaixo, o valor de b varia entre 0 e 1. Os valores de nc e no
utilizados s~ao os obtidos com a dimens~ao (altura ou largura) com maior no. Com isso,
o nvel otimo e desenhado com canal alpha valendo b e o nvel abaixo e desenhado com
alpha valendo 1 , b.
A Figura 7.8 ilustra algumas vistas da visualizaca~o de duas panoramas. A Figura 7.8a
e resultado da visualizac~ao da imagem original, enquanto que a Figura 7.8b e resultado
~
76
da visualizac~ao da pirâmide de tiles obtida desta mesma imagem. Note o numero de tiles
desenhado em cada quadro, e repare como na pirâmide um numero signicativamente
menor de tiles e desenhado. Note tambem que esse numero se mantem aproximadamente
constante para qualquer nvel de zoom, tendo uma diferenca de no maximo a metade. A
qualidade da imagem resultante e praticamente a mesma nos dois processos de visualizac~ao, como tnhamos previsto. Vale mencionar que a pirâmide foi criada com fator de
qualidade 1.
Com esse novo esquema de visualizac~ao, as operac~oes de zoom podem fazer com que
novos tiles sejam visualizados que est~ao em outros nveis, o que n~ao ocorria na visualizac~ao
com um unico nvel. Como consequência, o mecanismo de gerenicamento de cache tem
que ser modicado para tratar dessas mudancas de nvel. Veremos na proxima seca~o com
isso e feito.
Esse esquema permite a visualizac~ao de imagens muito grandes, que podem n~ao caber
na memoria principal. Sendo assim, e importante a implementac~ao do mecanismo de cache
tambem para o proximo nvel, onde a memoria e o cache e o disco e o armazenamento
principal. Mais adiante falaremos um pouco dessa implementac~ao.
7.3 Gerenciamento de Cache e Pirâmide de Imagens

A visualizaca~o da imagem panorâmica representada pela pirâmide de tiles afeta diretamente o algoritmo de gerenciamento de cache, ou melhor, o oraculo utilizado.
No gerenciamento de cache para pirâmides de imagens, vamos adicionar uma exigência
razoavel. Sempre que um tile for carregado no cache, e necessario que todos os seus antepassados tambem estejam carregados. Do mesmo modo, antes que um tile possa ser
descarregado, e necessario que todos os seus descendentes tambem o sejam. Essa exigência
e razoavel porque o principal objetivo da estrutura piramidal e permitir que uma vers~ao
menor da imagem possa ser usada para visualizaca~o reduzindo o processamento necessario.
Mas se essa imagem menor tiver que ser carregada, pode ser que o processamento acabe sendo maior do que se a imagem inicial fosse usada. Exigindo o carregamento dos
ancestrais impede que isso aconteca.
A consequência deste fato para o oraculo e que quando este marca os tiles pertencentes
a janelas de visualizac~ao de quadros futuros, todos os tiles dentro dessa janela devem ser
marcados, desde o nvel 0 ate o nvel otimo. E mais, quando a lista de tiles a carregar
e percorrida, os tiles que pertencem aos menores nveis devem ser carregados primeiro.
Note que o nvel otimo para um quadro futuro pode ser diferente do nvel otimo do quadro
corrente.
O criterio espacial tambem deve ser modicado da mesma forma. Todos os nveis
entre o nvel 0 e o nvel otimo devem ser considerados, e a classicac~ao deve ser tal que
para dois tiles a uma mesma distância da janela, aquele com menor nvel tera o menor
valor (mais chance de ser carregado).
Com essas mudancas, o oraculo funciona para pirâmide de imagens. Fazemos ainda
uma modicac~ao no algoritmo de que os primeiros dois nveis da estrutura est~ao sempre
carregados. Dessa forma qualquer que seja a sequência de visualizac~ao, todas as regi~oes
da imagem ter~ao pelo menos dois tiles ja carregados.
Com esse esquema de gerenciamento de cache para pirâmides de imagens, podemos
realmente garantir que o tempo gasto com carregamento dos dados no cache sera abaixo
~
77
Figura 7.8: Vistas obtidas de uma imagem panorâmica. Os numeros embaixo de cada
vista indicam o numero de tiles desenhados para gerar essa vista. (a) Vistas geradas com
a imagem panorâmica original (b) Vistas geradas com uma pirâmide de tiles criada da
imagem panorâmica com qualidade 1.
de um determinado valor em todos os quadros. Quando apenas um nvel era utilizado,
tentavamos carregar o maximo de dados possveis abaixo desse limite. Mas se mesmo
assim algum tile casse sem ser carregado, este teria que ser carregado de qualquer forma,
mesmo que fosse preciso ultrapassar o limite mnimo desejado. Por outro lado, tendo a
pirâmide de imagens, se um tile n~ao estiver carregado na hora de ser desenhado, algum
ancestral seu estara. Esse ancestral pode ent~ao ser utilizado para desenhar enquanto o
~
78
tile correto n~ao e carregado.

Um problema desse esquema e que como, os tiles v~ao sendo desenhados na medida em
que s~ao carregados, o usuario vê claramente o carregamento ocorrer, pois a imagem vai
melhorando aos poucos.
Uma soluc~ao para isso seria desenhar um nvel somente depois que todos os seus tiles
s~ao carregados. O problema e que quando se faz uma pequena movimentaca~o em alguma
direc~ao que possua algum tile n~ao carregado, todos os tiles s~ao mostrados no nvel inferior,
ate que esse novo tile seja carregado. Como resultado, a visualizac~ao ca variando nveis
frequentemente, o que incomoda o usuario.
Implementamos ent~ao uma terceira soluca~o que consiste em levar em considerac~ao
tambem os quadros futuros, que de certa forma indicam como os parâmetros de visualizac~ao est~ao mudando. Se o usuario faz um movimento muito rapido e o sistema percebe
que sera difcil carregar todos os novos tiles a tempo, o nvel desenhado e reduzido ate
um nvel em que o carregamento possa ser feito para todo o movimento. O interessante e
que, os casos em que se tera que subir muitos nveis correspondem a movimentos rapidos,
onde a qualidade de imagem n~ao e muito importante. A Figura 7.9 ilustra esse esquema.
Na Figura 7.9a os parâmetros de visualizaca~o est~ao constantes. Na Figura 7.9b o usuario
esta fazendo um movimento rapido para a direita, e como os tiles neste lado ainda n~ao
estavam carregados, o nvel na pirâmide desceu para que a taxa de geraca~o de quadros se
mantivesse constante. Assim que o usuario para, Figura 7.9c, os tiles do nvel otimo s~ao
carregados novamente para o quadro corrente. Esse ultimo carregamento e geralmente
feito em cerca de 1 segundo, de modo que o usuario n~ao visualiza a imagem com qualidade
ruim por muito tempo.
Figura 7.9: Durante uma mudanca rapida de parâmetros, o nvel corrente desce na
pirâmide ate que a mudanca de parâmetros diminua e os tiles do nvel otimo possam ser
carregados a tempo. (a) Parâmetros de visualizaca~o constantes. (b) Movimento rapido
para a direita. (c) Parâmetros constantes novamente.
Para implementar esse esquema, notamos que que para cada quadro futuro k, variandose o nvel onde este quadro sera desenhado, pode-se variar o valor de nvsk na equaca~o 6.3
do captulo anterior. Sendo assim, podemos utilizar essa equaca~o para estimar um nvel
lk tal que, se todos os quadros antes de k forem desenhados no nvel lk , os tiles desenhados
poder~ao ser carregados com o throughput desejado. Atualmente, esse calculo e feito para
20 quadros futuros e, ao inves de pegarmos o menor valor de lk , tomamos a media, que
e menos sujeita a variac~oes locais que podem ser causadas por algum quadro estimado
erradamente.
Dadas essas mudancas no gerenciamento de tiles, veremos agora como e implementado
o esquema nal de visualizac~ao de panoramas em tempo real.
~
79
7.4 Implementac~ao
Dadas essas mudancas causadas pela representaca~o da imagem panorâmica pela pirâmide,
e suas consequências no esquema de gerenciamento de tiles, implementamos um novo esquema de visualizaca~o capaz de visualizar imagens muito grandes em tempo real.
A primeira modicac~ao que zemos foi implementar o mecanismo de gerenciamento de
cache para o segundo nvel, onde a memoria RAM e o cache e o disco e o armazenamento
principal. Isso e necessario porque queremos executar o programa com imagens que n~ao
cabem em memoria RAM.
Para controlar quais dados s~ao carregados em memoria RAM, utilizamos uma facilidade do Windows NT chamada de memory mapped les (Ritchter, 1996). Os memory
mapped les s~ao arquivos que podem ter partes suas mapeadas para regi~oes do espaco de
enderecamento do processo. Quando essas regi~oes s~ao acessadas, os dados s~ao transferidos
do arquivo para memoria fsica (RAM) onde o acesso pode ser feito. Se a quantidade de
memoria car pequena, ou o arquivo for desmapeado, os dados s~ao copiados de volta para
o arquivo e a memoria fsica e reutilizada.
Quando o arquivo com os dados dos tiles e aberto, este n~ao e totalmente lido, apenas
o seu cabecalho. Os dados de tiles permanecem inacessados. Ao vericarmos que um
tile pode ser necessario no futuro, mapeamos a regi~ao do arquivo onde seus dados est~ao
armazenados em um endereco de memoria. Assim que percebemos que um tile n~ao sera
mais utilizado, retiramos seu mapeamento em memoria, de modo que este volta para o
disco.
O gerenciamento de cache nesse nvel introduz um novo problema, no entanto. O
carregamento ou descarregamento envolve um acesso a disco, o que pode forcar uma
espera do programa ate que o disco responda. Uma soluca~o para isso e utilizarmos dois
threads no programa, um para desenhar e outro para carregar e descarregar dados nos
caches. Assim, quando a execuc~ao desse thread for interrompida para esperar da resposta
do disco, o outro e automaticamente posto para executar. Com isso podemos melhorar
um pouco o tempo de execuca~o.
Implementamos os dois threads de modo que o thread de desenho tenha prioridade
maior. Assim, toda vez que termina de desenhar, ele mesmo se coloca para dormir por
um tempo certo durante o qual o gerenciamento de cache sera feito. Como o thread
de desenho tem prioridade maior, o outro n~ao consegue ser executado fora desse tempo.
Esse esquema permite que controlemos o tempo lt gasto com carregamento nos caches.
As melhoras seriam ainda maiores se o programa fosse executado em um computador
com mais de um processador, pois nesse caso cada thread poderia ser executado em uma
maquina diferente.
7.5 Resultados
Ao longo deste captulo mostramos diversas imagens geradas pelo algoritmo de visualizac~ao apresentado. Nesta seca~o mostraremos alguns resultados numericos que demostram
a eciência do esquema de visualizaca~o que implementamos.
Montamos uma panorama com uma imagem original de dimens~oes 2048 20480 e 125
MB de tamanho. Apos sua convers~ao para uma pirâmide de tiles e a simplicaca~o desta
com fator de qualidade q = 0:5, o tamanho dos dados passou a ser de 155 MB.
~
80
Pedimos que quatro usuarios visualizassem essa panorama e marcamos o tempo de

gerac~ao de cada quadro durante a visualizac~ao de cada um. Os resultados s~ao mostrados
nos gracos da Figura 7.10.
Figura 7.10: Tempos de geraca~o de quadros para quatro sequências de visualizac~ao em

uma imagem de 155 MB.
Como podemos ver claramente nos gracos, o tempo de gerac~ao de quadros em todas
as sequências e constante. Na realidade existe uma pequena variac~ao de ate 20 ms entre
um quadro e outro, mas considerando que a func~ao de temporizac~ao que usamos tem
precis~ao de 10 ms, essa diferenca n~ao e consideravel. Algumas sequências tem um ou dois
quadros com tempo de gerac~ao muito maior do que os demais. Como isso so ocorre no
maximo em três quadros por sequência, de um total de 3000 mais ou menos, consideramos
que esses valores correspondem a alguma interferência do computador.
No captulo 5 mostramos gracos semelhantes para a visualizaca~o de panoramas muito
menores. Naqueles gracos, o tempo n~ao era constante para imagens acima de um determinado tamanho. Utilizando esse esquema de visualizaca~o conseguimos manter o tempo
praticamente constante com imagens muito maiores do que as testadas naquele captulo.
Alem disso, os tempos medios de geraca~o de quadros pareciam estar entre 10 e 20 ms.
Nos gracos acima, vemos que esses tempos parecem se manter constantes entre 30 e 40
ms. Esse fato e de extrema importância, pois mostra que conseguimos adicionar todo o
processamento necessario para que a taxa de gerac~ao de quadros seja constante independente do tamanho da imagem (gerenciamento de cache e visualizac~ao em multiresoluc~ao)
e mesmo assim o tempo medio de geraca~o de quadros n~ao subiu muito. Com um tempo
de 40 ms por quadro, e considerando que o thread de carregamento de tiles executa por
aproximadamente 10 ms entre a gerac~ao de quadros, temos um tempo total de 50 ms, que
~
81
permite uma taxa media de 20 quadros por segundo. Essa taxa e e geralmente considerada boa para aplicac~oes interativas, e e acima do mnimo que pretendamos atingir, de
15 quadros por segundo.
Captulo 8
Conclus~oes e Trabalhos Futuros
Nesta dissertac~ao apresentamos um novo sistema para visualizac~ao de panoramas virtuais. Esse sistema resolve diversas limitac~oes dos ja existentes. Por exemplo, esses
sistemas n~ao geram quadros a uma taxa constante e interativa, mas introduzem em geral
uma pequena latência na interaca~o do usuario com a câmera virtual. Esse fato impossibilita a sua utilizac~ao em equipamentos imersivos, pois qualquer latência e muito mais
notavel nestes equipamentos.
Alem disso, a sua performance piora muito, na medida em que a imagem panorâmica
e aumentada, a ponto de n~ao suportar imagens maiores do que um determinado tamanho.
Como o tamanho da imagem esta diretamente relacionado com a densidade de amostragem
da func~ao de luminosidade do ambiente, esses sistemas limitam o nvel de detalhe em que
o ambiente pode ser representado, o que certamente reduz a imersibilidade. Alem disso,
n~ao ha possibilidade de se ter apenas uma pequena regi~ao do ambiente representada com
maiores detalhes.
O sistema que desenvolvemos n~ao tem nenhum desses problemas. Primeiro permite a
visualizac~ao da panorama a taxas interativas. Segundo, essa taxa n~ao e alterada quando o
tamanho da imagem panorâmica e modicada. Qualquer que seja o tamanho da imagem, a
taxa de geraca~o de quadros permanece aproximadamente a mesma, permitindo a utilizac~ao
de imagens com resoluc~oes muito altas que podem mostrar ambientes bem detalhados.
Fizemos diversos testes de visualizaca~o com imagens panorâmicas de diversos tamanhos. Em todas as imagens testadas, o tempo para gerar quadros permaneceu entre 10
ms e 40 ms, independente do seu tamanho. A maior imagem testada tem 300 MB. N~ao
conseguimos criar uma imagem maior, devido a limitac~oes de espaco em disco. No entanto, n~ao temos nenhum motivo para acreditar que o sistema n~ao funcione para imagens
maiores do que isso.
O sistema de panoramas esta sendo usado atualmente como parte do Visorama (Matos et al. , 1997b), cujos requisitos motivaram o seu desenvolvimento. O Visorama e um
dispositivo imersivo para interac~ao com panoramas virtuais. Por ser imersivo, qualquer
latência ou defeito introduzido da visualizac~ao se torna perceptvel. Os resultados positivos obtidos com a utilizaca~o do sistema de panoramas no Visorama demonstram que
atingimos os objetivos desejados com o seu desenvolvimento.
A seguir, resumimos algumas das principais conclus~oes tomadas durante o desenvolvimento do sistema, que est~ao apresentadas e fundamentadas ao longo da tese.
a visualizaca~o de panoramas pode ser bem aproximada por um conjunto de transformac~oes projetivas por partes;
~ E TRABALHOS FUTUROS
CAPITULO 8. CONCLUSOES
83
a aproximac~ao por transformac~oes projetivas pode ser implementada usando hard

ware de mapeamento de textura, que e mais eciente do que as implementaco~es por

software atualmente;
nas placas que testamos, o tempo de desenho utilizando hardware de mapeamento
de textura n~ao muda muito com o tamanho da imagem mostrada desde que esta
esteja toda carregada na placa;
quando o tamanho da imagem panorâmica ca maior do que pode ser armazenado
na placa, o grande gargalo da visualizaca~o e o tempo de carregamento das texturas
para a placa de vdeo;
esse gargalo pode ser reduzido implementando um algoritmo de gerenciamento de
cache que carrega uma pequena parte da imagem por quadro, determinando atraves
de um oraculo a melhor parte a ser carregada;
se o tamanho da imagem n~ao for muito grande e os parâmetros de visualizac~ao n~ao
mudarem muito rapido, o algoritmo de gerenciamento de cache possibilita uma taxa
de gerac~ao de quadros constante;
imagens grandes podem ser representadas por uma pirâmide de imagens onde cada
nvel corresponde a uma resoluca~o diferente e, escolhendo-se o nvel correto para
desenhar em cada quadro, o mesmo numero de pixels aproximadamente s~ao processados;
a pirâmide pode ser simplicada de acordo com a quantidade de detalhes presentes
em cada regi~ao da imagem, o que causa compress~ao sem muita perda de qualidade;
com a pirâmide e o algoritmo de gerenciamento de cache, a imagem pode ser sempre
desenhada no maior nvel de resoluc~ao que pode ser carregado no cache a tempo, o
que mantem o tempo de gerac~ao de quadros constante;
na pratica, se os parâmetros de visualizac~ao n~ao mudarem muito rapido, o nvel
desenhado e quase sempre o nvel otimo.
Embora essas conclus~oes estejam relacionadas com o desenvolvimento do visualizador

de panoramas virtuais, grande parte delas tem aplicabilidade muito mais geral, podendo
ser util em um grande numero de problemas semelhantes. O mesmo pode ser dito em
relac~ao a alguns algoritmos que apresentamos na dissertac~ao.
O esquema de gerenciamento de cache, por exemplo, pode ser utilizado em qualquer
aplicac~ao de visualizac~ao em tempo real onde o tempo de acesso aos dados seja comparavel
com o tempo de desenhar. Para que o oraculo apresentado seja utilizavel, e necessario que
os dados estejam no plano, mas um novo oraculo pode ser criado para dados no espaco.
Exemplos de aplicac~oes onde acreditamos que esse algoritmo possa ser bem aplicado s~ao os
sistemas de informac~oes geogracas (GIS), sistemas para visualizac~ao de imagens medicas,
outros sistemas para renderizaca~o de imagens medicas.
Os algoritmos para visualizac~ao em tempo real, por sua vez, podem ser usados em qualquer metodo de renderizac~ao baseada em imagens. Esses metodos devem invariavelmente
fazer alguma forma de reamostragem de uma ou mais imagens para a tela. Utilizando
a estrutura de pirâmide de tiles que apresentamos, podemos garantir que a quantidade
84
certa de pixels e sempre processada, o que permite uma qualidade boa da imagem resultante sem processamentos desnecessarios. Grande parte das conclus~oes apresentadas
acima tambem se aplicam aos metodos de renderizac~ao baseada em imagens.
As tecnicas de visualizaca~o que apresentamos est~ao sendo utilizadas para visualizac~ao
de panoramas no Sistema Visorama, tendo sido motivadas pelas necessidades deste. Sendo
assim, devemos separar os trabalhos futuros em dois grupos distintos. No primeiro grupo,
est~ao as melhorias que ainda podem ser feitas na visualizaca~o de panoramas virtuais,
consequências diretas do trabalho apresentado nessa dissertaca~o. No segundo grupo,
est~ao os outros componentes do Sistema Visorama que ainda faltam ser implementados.
Apesar de n~ao termos discutido o Visorama ao longo da dissertac~ao, vale falar aqui de
alguns dos seus problemas que podem resultar em trabalhos interessantes, como ocorreu
com o problema de visualizac~ao de panoramas.
No contexto da visualizac~ao de panoramas, vamos em implementar o esquema de
visualizac~ao por aproximaca~o poligonal para outras superfcies, como o cubo e a esfera.
Uma vez que essa visualizac~ao e feita por aproximac~ao, qualquer uma dessas superfcies
pode ser utilizada, ou ate outras mais complicadas.
Estamos tambem desenvolvendo nosso proprio stitcher de panoramas. Atualmente
utilizamos os stitchers dos sistemas comerciais. Esses sistemas têm a limitac~ao de que
toda a imagem panorâmica tem que ser criada em uma mesma resoluc~ao. Assim, quando
queremos que apenas uma determinada regi~ao da imagem seja representada em resoluc~ao
maior, devemos primeiro criar toda imagem nessa resoluca~o grande, e depois passa-la para
a estrutura de pirâmide, que pode ser simplicada usando o esquema aqui apresentado.
Mas isso nem sempre e possvel. Primeiro porque os stitchers comerciais permitem a
criac~ao de imagens panorâmicas apenas ate um determinado tamanho. Segundo, porque
muitas vezes n~ao queremos ter que amostrar toda a imagem panorâmica em uma resoluc~ao
alta. Por exemplo, vamos supor que criamos uma panorama tirando fotograas com
uma lente de 28 mm, e que essas fotograas s~ao escaneadas com resoluc~ao 1024 x 512.
Vamos supor que tiramos tambem algumas fotograas de uma regi~ao interessante com
uma lente de 200 mm, e escaneamos com a mesma resoluc~ao. Essa lente capta muito mais
detalhes, e as fotos resultantes mostram regi~oes menores do ambiente. Seria interessante
se pudessemos ent~ao compor todas essas fotos em uma unica parorama, criando uma
estrutura de multiresoluca~o. Na regi~ao da panorama onde as fotos de maior resoluc~ao
foram tiradas, haveria muito mais nveis na pirâmide, porque a amostragem e muito
maior.
Os stitchers comerciais n~ao permitem que isso seja feito. Primeiro, porque so permitem
a criac~ao de panoramas cilndricas, onde o processo de geraca~o de fotos seja controlado.
Segundo porque todas as fotos tem que ter a mesma resoluca~o.
Para que isso seja possvel, estamos implementando o esquema proposto por Szeliski
(Szeliski & Shum, 1997) com algumas modicaco~es, que permitem ao usuario especicar
o casamento entre as fotograas atraves de pontos de corresponndência. Assim, nenhuma
restric~ao e colocada no processo de tirar as fotograas. A Figura 8.1 mostra a tela desse
stitcher.
O nosso stitcher permite ao usuario modicar manualmente o casamento entre as
imagens, o que permite uma grande exibilidade. Para que essa manipulaca~o tambem seja
interativa, independente do tamanho da imagem, estamos incorporando nossa estrutura
de multiresoluca~o para representaca~o das imagens sendo casadas.
Outra quest~ao interessante de se estudar, que mencionamos na dissertac~ao, e a im-
85
Figura 8.1: Tela do Stitcher.

plementac~ao da multiresoluc~ao de imagens utilizando wavelets. As wavelets permitem
uma representaca~o mais concisa dessa estrutura, alem de proporcionarem um ferramental matematico poderoso. Seria necessario um estudo para determinar quais as wavelets
mais apropriadas para serem utilizadas nesse caso. Essa decis~ao deve levar em conta: o
tempo de codicac~ao e decodicac~ao, o espaco de armazenamento, as possibilidades de
compress~ao e a qualidade da imagem resultante gerada.
Seria interessante tambem que o sistema suportasse saltos e transico~es suaves entre
duas panoramas. Nesse caso, o esquema de gerenciamento de tiles, mais especicamente o
oraculo, deve ser modicado para lconsiderar que os tiles a serem visualizados em quadros
futuros podem estar em outra panorama. Uma analise deve ser feita para determinar se os
tiles de outras panoramas devem ser carregados antes que o usuario especique a transic~ao
ou depois.
Do mesmo modo, seria interessante suportar panoramas com animac~ao, onde algumas
sprites poderiam ser compostas com a panorama. Esse fato tambem modica o oraculo
do algoritmo de gerenciamento de cache, pois a cada quadro todos os tiles da sprite est~ao
sendo visualizados pela primeira vez, independente dos parâmetros de visualizaca~o serem
modicados ou n~ao.
No âmbito do Visorama, diversos problema interssantes ainda devem ser resolvidos.
Um desses problemas e a inclus~ao de audio no sistema. Essa possibilidade e interessante
porque o audio pode aumentar em muito a imersibilidade do usuario no ambiente. Alem
disso, em diversas aplicac~oes e interessante que se possa incluir uma narraca~o que proporcione mais informac~oes sobre o ambiente sendo visualizado. A exibic~ao de audio possui
diversos requisitos de tempo real, semelhantes aqueles da visualizaca~o de panoramas, e
um estudo de como esses requisitos podem ser atingidos deve ser feito.
Outro problema que permanece em aberto no Visorama e o desenvolvimento de um
ambiente de autoria especco para panoramas. Esse ambiente permitiria ao autor de um
ambiente virtual especicar como este deve interagir com o usuario. No Visorama, as
ac~oes do usuario incluem modicaco~es nos parâmetros de visualizaca~o e ativac~ao de um
bot~ao. A autor poderia especicar atraves desse ambiente eventos que devem ocorrer como
86
resposta a essas ac~oes em diversos casos. Por exemplo, poderia especicar que quando o
usuario visualiza uma determinada regi~ao e pressiona o bot~ao, um audio deve ser exibido.
Outros eventos que poderia ser gerados s~ao a exibica~o de animac~oes e a transica~o entre
panoramas.
Referências Bibliogracas

Adelson, E. & Bergen, J. 1991. The Plenoptic Function and Elements of Early Vision.
Computation Models of Visual Processing.
Blinn, J. F. 1976. Texture and Re ection in Computer Generated Images. Communication
of the ACM, 19(10), 542{547.
Blinn, J. F. 1978. Simulation of Wrinkled Surfaces. Proceedings of SIGGRAPH '78,
286{292.
Catmull, E. & Smith, A. R. 1980. 3-D Transformation of images in scanline order. Computer Graphics, 14(3), 279{285.
Chen, S. E. 1995. Quicktime VR - An Image-Based Approach to Virtual Environment
Navigation. Computer Graphics, Annual Conference Series, 29{38.
Chen, S. E. & Miller, G. S. 1995. Cylindrical to Planar Image Mapping Using Scanline
Order. United States Patent Number 5396583.
Chen, Shenchang Eric & Williams, Lance. 1993. View Interpolation for Image Synthesis.
Pages 279{288 of: Computer Graphics Proceedings, Annual Conference Series (Proc.
SIGGRAPH '93).
Darsa, L.; Costa, B. & Varshsney, A. 1996. Navigating Static Environments Using ImageSpace Simplication and Morphing. Proceedings of 1996 Symposium on 3D Graphics.
Darsa, L.; Silva, B. C. & Varshney, A. 1997 (April). Navigating Static Environments Using
Image-Space Simplication and Morphing. Pages 25{34 of: Proc. 1997 Symposium
on Interactive 3D Graphics.
Debevec, P. E.; Taylor, C. J. & Malik, J. 1996. Modeling and Rendering Architecture
From Photographs: A Hybrid Geometry- and Image-Based Approach. Pages 11{20
of: Computer Graphics Proceedings, Annual Conference Series (Proc. SIGGRAPH '
96).
Fant, K. M. 1986. A Nonaliasing Real-Time Spatial Transform Technique. IEEE Computer Graphics and Applications, 6(1), 71{80.
Faugeras, O. 1993. Three-dimensional computer vision - A geometric viewpoint. MIT
Press.
87

REFERE^NCIAS BIBLIOGRAFICAS
88
Faugeras, Q. T. Luong & Robert, Luc. 1995. The Fundamental Matrix: theory, algorithms, and stability analysis. Tech. rept. Technical Report RR-2205. INRIA - The
French Institute for Research in Computer Science and Control. Available fromhttp:// www.inria.fr.
Foley, J. D.; Dam, A. V.; Feiner, S. K. & Hughes, J. F. 1987. Computer Graphics
Principles and Practice. Addison-Wesley.
Funkhouser, Thomas A.; Sequin, Carlo H. & Teller, Seth J. 1992 (Mar.). Management of
large amounts of data in interactive building walkthroughs. Pages 11{20 of: Zeltzer,
David (ed), Computer Graphics (1992 Symposium on Interactive 3D Graphics), vol.
25.
Gershun, A. 1939. The Light Field. Journal of Mathematics and Physics, 18, 51{151.
Gomes, J. & Velho, L. 1989. Introduc~ao a Computac~ao Graca. Escola de Ver~ao de
Instituto de Matematica Pura e Aplicada.
Gomes, J. & Velho, L. 1995. Abstraction Paradigms for Computer Graphics. The Visual
Computer, 11(5), 227{239.
Gomes, J. & Velho, L. 1997. Image Processing For Computer Graphics. Springer.
Gortler, Steven J.; Grzeszczuk, Radek; Szeliski, Richard & Cohen, Michael F. 1996. The
Lumigraph. Pages 43{54 of: Computer Graphics Proceedings, Annual Conference
Series (Proc. SIGGRAPH '96).
Greene, N. 1986. Environment Mapping and Other Applications of World Projections.
IEEE Computer Graphics and Applications, 6(11), 21{29.
Heckbert, P. S. 1986. Survey of Texture Mapping. IEEE Computer Graphics and Applications, Nov., 56{67.
Heckbert, Paul S. 1989 (June). Fundamentals of Texture Mapping and Image Warping.
M.Phil. thesis, University of California at Berkeley, Berkeley, CA.
KPTBryce. 1997. MetaTools Inc., http://www.metatools.com.
Laveau, Stephane & Faugeras, Olivier. 1994 (February). 3-D Scene Representation
as a Collection of Images. Tech. rept. Technical Report RR-2205. INRIA - The
French Institute for Research in Computer Science and Control. Available from
http:www.inria.fr.
Leclerc, Y. G. & Jr., S. Q. Lau. 1994. TerraVision: A Terrain Visualization System.
Tech. rept. SRI International.
Levoy, Marc & Hanrahan, Pat. 1996. Light Field Rendering. Pages 31{42 of: Computer
Graphics Proceedings, Annual Conference Series (Proc. SIGGRAPH '96).
Malde, H. E. 1983. Panoramic Photographs. American Scientist, 12, 132{140.

89
Mark, W. R.; McMillan, L. & Bishop, G. 1997. Post-Rendering 3D Warping. Proceedings

of 1997 Symposium on 3D Graphics, 7{16.
Matos, A.; Gomes, J.; Parente, A.; Siert, H. & Velho, L. 1997a. O Sistema Visorama:
Um Novo Sistema de Multimidia e Realidade Virtual. III Workshop on Multimedia
and Hypermedia Systems.
Matos, A.; Gomes, J.; Parente, A.; Siert, H. & Velho, L. 1997b. The Visorama System:
A Functional Overview of a New Virtual Reality Environment. Computer Graphics
International '97 Proceedings.
McMillan, L. 1997. An Image-Based Approach to Three-Dimensional Computer Graphics.
Ph.D. thesis, University of North Calorina at Chapel Hill.
McMillan, L. & Bishop, G. 1995a. Plenoptic Modeling: An Image-Based Rendering
System. SIGGRAPH '95 Proceedings, 39{46.
McMillan, Leonard & Bishop, Gary. 1995b. Plenoptic Modeling: An Image-Based Rendering System. Pages 39{46 of: Computer Graphics Proceedings, Annual Conference
Series (Proc. SIGGRAPH '95).
Moon, P. 1981. The Photic Field. MIT-Press.
PhotoBubbles. 1997. Omniview Inc., http://www.omniview.com.
RealVR. 1997. Real Space Inc., http://www.rlspace.com.
Requicha, A. 1980. Representation for Rigid Solids: Theory, Methods and Systems. ACM
Computing Surveys, 12, 437{464.
Ritchter, J. 1996. Advanced Windows. Microsoft Press.
Seitz, Steven M. 1996. Toward Image-Based Scene Representation Using View Morphing.
Tech. rept. Computer Sciences Department, University of Wisconsin-Madison.
Silberschatz, Abraham & Galvin, Peter Baer. 1997. Operating System Concepts. AddisonWesley.
Smith, Alvy Ray. 1987. Planar 2-Pass Texture Mapping and Warping. Computer Graphics,
21(4), 263{272.
StrataPro. 1997. Strata Inc., http://www.strata.com.
Sutherland, I. E.; Sproull, R. F. & Schumacker, R. A. 1974. A Characterization of Ten
Hidden-Surface Algorithms. Journal of the ACM, Mar.
Szeliski, R. 1996. Video Mosaics for Virtual Environments. IEEE Computer Graphics
and Applications.
Szeliski, R. & Shum, H. 1997. Creating Full View Panoramic Image Mosaics and Environments. SIGGRAPH '97 Proceedings.
Watt, A. 1993. 3D Coputer Graphics. Addison-Wesley.

90
Williams, L. 1980. Piramid Parametrics. Computer Graphics.

Wolberg, G. 1988. Digital Image Warping. IEEE Computer Society Press.
Wolberg, G. & Boult, T. 1989. Separable image warping with spatial lookup tables.
Computer Graphics, 23(3), 369{378.
Woo, J. 1998. The OpenGL Programming Guide. Addison-Wesley.

Visualização de Panoramas Virtuais PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Visualização de Panoramas Virtuais PDF

Uploaded by

Copyright:

Available Formats

Visualizaca~o de Panoramas Virtuais

Andre Machado de Matos

3 Renderizac~ao Baseada em Imagens

4 Sistemas de Panoramas Virtuais

Otimizac~ao do Acesso aos Dados . . . .

7.1 Pir^amide de Imagens . . . . . . . . . . . . . . .

8 Conclus~oes e Trabalhos Futuros

 o tempo de renderizaca~o independe da complexidade do ambiente virtual, o que e

bom para aplicac~oes interativas;

aproximar de objetos atraves de um fator de zoom, como na interac~ao com um binoculo.

 n~ao geram imagens a taxas constantes e interativas;

No captulo 5 apresentamos detalhes da visualizaca~o de panoramas. Mostramos que

2.2 Paradigma dos Quatro Universos de Abstrac~ao

Figura 2.1: Os quatro universos de abstraca~o.

2.3 Func~ao de Luminosidade

A func~ao de luminosidade foi de nida por diversos autores, em areas diferentes, e

Utilizando a func~ao de luminosidade (ou luminosidade estendida), podemos de nir o

2.4 Descric~ao da Func~ao de Luminosidade

2.4.1 Descric~ao Algortmica x Amostragem

A computaca~o gra ca baseada em geometria utiliza um esquema de representac~ao

de renderizac~ao baseada em imagens e baseada em geometria. Voltando as tecnicas de

2.5 Criac~ao, Armazenamento e Visualizac~ao de Ambientes Virtuais

Finalmente, o processo de visualizaca~o e formado pelas operac~oes executadas durante

2.5.1 Metodos de Renderizac~ao Baseada em Geometria

2.5.2 Metodos de Renderizac~ao Baseada em Imagens

2.5.3 Convers~ao entre Descric~oes e Metodos Hbridos

2.6 Considerac~oes Finais

3.1.1 Computac~ao Gra ca

renderizac~ao baseada em imagens s~ao apresentados neste trabalho.

3.1.2 Vis~ao Computacional

As tecnicas de vis~ao computacional s~ao bastante utilizadas para analise de imagens

3.2 Renderizac~ao Baseada em Imagens

3.2.1 Visualizac~ao de Ponto de Vista Fixo

Figura 3.1: Parametrizacao baseada em panoramas.

ra reconstruir a func~ao de luminosidade, a superfcie mapeada e visualizada utilizando

3.2.2 Visualizac~ao por Amostragem Densa

Os metodos de visualizac~ao por amostragem densa (Gortler et al. , 1996) (Levoy

Figura 3.2: Parametrizacao do conjunto de retas do espaco.

Figura 3.3: Amostragem da funca~o de luminosidade.

Figura 3.4: Visualizac~ao utilizando representaca~o por slabs.

3.2.3 Visualizac~ao por Amostragem da Func~ao de Luminosidade

Para diminuir a quantidade de dados armazenados pelos metodos anteriores, diversos

3.2.4 Visualizac~ao por Analise de Amostras da Func~ao de Luminosidade

Figura 3.8: Pre-deformaca~o (a) Interpolac~ao (b) e Pos-deformaca~o (c).

Figura 3.9: Resultado da aplicac~ao do view-morphig a duas imagens (Imagem obtida do

3.3 Modelagem Baseada em Imagens.

3.4 Considerac~oes nais.

4.1 Panoramas Virtuais

CAPITULO 4. SISTEMAS DE PANORAMAS VIRTUAIS

Figura 4.1: Imagem panor^amica e seu mapeamento na superfcie panor^amica cilndrica.

Figura 4.2: C^amera virtual visualizando panorama cilndrica.

4.2 Autoria de Panoramas

CAPITULO 4. SISTEMAS DE PANORAMAS VIRTUAIS

geometricamente, a partir de fotogra as do mundo real, e a partir dessas fotogra as com

4.2.1 Ambientes Modelados

A criac~ao de imagens panor^amicas a partir de ambientes modelados pode ser simples

4.2.2 Fotogra as do Mundo Real

CAPITULO 4. SISTEMAS DE PANORAMAS VIRTUAIS

Figura 4.5: Lente sheye de 6mm.

CAPITULO 4. SISTEMAS DE PANORAMAS VIRTUAIS

Figura 4.6: Fotogra a tirada com uma lente sheye.

4.2.3 Fotogra as do Mundo Real com Auxlio de Processamento

Alguns sistemas de panoramas virtuais existentes oferecem programas que utilizam

Visualizaca~o de Panoramas Virtuais

Andre Machado de Matos

3 Renderizac~ao Baseada em Imagens

Otimizac~ao do Acesso aos Dados . . . .

o tempo de renderizaca~o independe da complexidade do ambiente virtual, o que e

bom para aplicac~oes interativas;

aproximar de objetos atraves de um fator de zoom, como na interac~ao com um binoculo.

n~ao geram imagens a taxas constantes e interativas;

No captulo 5 apresentamos detalhes da visualizaca~o de panoramas. Mostramos que

2.2 Paradigma dos Quatro Universos de Abstrac~ao

Figura 2.1: Os quatro universos de abstraca~o.

2.3 Func~ao de Luminosidade

A func~ao de luminosidade foi denida por diversos autores, em areas diferentes, e

Utilizando a func~ao de luminosidade (ou luminosidade estendida), podemos denir o

2.4 Descric~ao da Func~ao de Luminosidade

2.4.1 Descric~ao Algortmica x Amostragem

A computaca~o graca baseada em geometria utiliza um esquema de representac~ao

de renderizac~ao baseada em imagens e baseada em geometria. Voltando as tecnicas de

2.5 Criac~ao, Armazenamento e Visualizac~ao de Ambientes Virtuais

Finalmente, o processo de visualizaca~o e formado pelas operac~oes executadas durante

2.5.1 Metodos de Renderizac~ao Baseada em Geometria

2.5.2 Metodos de Renderizac~ao Baseada em Imagens

2.5.3 Convers~ao entre Descric~oes e Metodos Hbridos

2.6 Considerac~oes Finais

3.1.1 Computac~ao Graca

renderizac~ao baseada em imagens s~ao apresentados neste trabalho.

As tecnicas de vis~ao computacional s~ao bastante utilizadas para analise de imagens

3.2 Renderizac~ao Baseada em Imagens

3.2.1 Visualizac~ao de Ponto de Vista Fixo

ra reconstruir a func~ao de luminosidade, a superfcie mapeada e visualizada utilizando

3.2.2 Visualizac~ao por Amostragem Densa

Os metodos de visualizac~ao por amostragem densa (Gortler et al. , 1996) (Levoy

Figura 3.2: Parametrizacao do conjunto de retas do espaco.

Figura 3.3: Amostragem da funca~o de luminosidade.

Figura 3.4: Visualizac~ao utilizando representaca~o por slabs.

3.2.3 Visualizac~ao por Amostragem da Func~ao de Luminosidade

Para diminuir a quantidade de dados armazenados pelos metodos anteriores, diversos

3.2.4 Visualizac~ao por Analise de Amostras da Func~ao de Luminosidade

Figura 3.8: Pre-deformaca~o (a) Interpolac~ao (b) e Pos-deformaca~o (c).

Figura 3.9: Resultado da aplicac~ao do view-morphig a duas imagens (Imagem obtida do

3.4 Considerac~oes nais.

CAPITULO 4. SISTEMAS DE PANORAMAS VIRTUAIS

Figura 4.1: Imagem panor^amica e seu mapeamento na superfcie panor^amica cilndrica.

Figura 4.2: C^amera virtual visualizando panorama cilndrica.

CAPITULO 4. SISTEMAS DE PANORAMAS VIRTUAIS

geometricamente, a partir de fotograas do mundo real, e a partir dessas fotograas com

A criac~ao de imagens panor^amicas a partir de ambientes modelados pode ser simples

4.2.2 Fotograas do Mundo Real

CAPITULO 4. SISTEMAS DE PANORAMAS VIRTUAIS

CAPITULO 4. SISTEMAS DE PANORAMAS VIRTUAIS

Figura 4.6: Fotograa tirada com uma lente sheye.

4.2.3 Fotograas do Mundo Real com Auxlio de Processamento

CAPITULO 4. SISTEMAS DE PANORAMAS VIRTUAIS

Figura 4.8: Composic~ao de duas imagens consecutivas.

CAPITULO 4. SISTEMAS DE PANORAMAS VIRTUAIS

4.3 Visualizac~ao de Panoramas

4.4 Analise dos Sistemas Existentes

CAPITULO 4. SISTEMAS DE PANORAMAS VIRTUAIS

CAPITULO 4. SISTEMAS DE PANORAMAS VIRTUAIS

CAPITULO 4. SISTEMAS DE PANORAMAS VIRTUAIS

4.6 Considerac~oes Finais

Figura 5.1: Durante o processo de autoria o ambiente e projetado na superfcie panor^amica.

imagem panor^amica determina a cor do ponto P = S (u; v) apos a projec~ao do ambiente

Figura 5.4: Mapeamento entre o espaco de par^ametros da superfcie e o plano de imagem

5.3 Visualizac~ao e Reamostragem

5.4 Transformac~ao de Dois Passos

O algoritmo de Fant e um dos mais ecientes para reamostragem unidimensional de

2. O pixel de entrada e totalmente consumido sem completar um pixel de sada. Nesse

5.5 Visualizac~ao de Panoramas Cilndricas

5.5.1 Derivac~ao da Transformac~ao de Dois Passos

Seja S (u; v) a superfcie do cilindro e seja H a matriz de projeca~o da c^amera virtual.

Figura 5.6: C^amera virtual geral (a) simplicada(b)

5.6 Aproximac~ao Poligonal

baric^enctricas de V em relaca~o a esses vertices. Existe uma unica transformaca~o linear Ti

5.6.1 Aproximac~ao por Transformac~oes Projetivas

Figura 5.9: A malha poligonal e uma grade regular

Implementamos a visualizaca~o de panoramas cilndricas por aproximaca~o poligonal

Figura 5.11: Vistas do ambiente obtidas por aproximaca~o poligonal.

5.7 Consideracoes Finais

6.1 Otimizac~ao do Acesso aos Dados