Ontem, parte do Brasil comemorou o 4 de julho por conta do primeiro título da Libertadores conquistado pelo Corinthians. Há 100 anos, parte do território brasileiro era contestado, e um fragmento comemorava o 4 de Julho pela sua conexão com os Estados Unidos.




"A Lumber é uma das maiores serrarias instaladas no Brasil, naquele momento. Talvez uma das maiores do mundo. Ela vai construir, em território catarinense e paranaense o território contestado a época uma pequena cidade, um pequeno país. Um fragmento dos Estados Unidos que comemora o 4 de Julho." — Nilson Cesar Fraga aos 00:04:24 do Olhar Contestado.

Sim, o filme ficou pronto. Finalmente. E foi um processo bem mais difícil do que o esperado. Tanto que ninguém se sentiu muito estimulado a blogar mais por aqui. Demorou demais, causou espectativa demais. Pra mim ele ficou bom, bem resolvido, mas é isso, ficou bom. Não é o "bicho" que talvez muitos esperem pelo tempo que levou para ser feito, mas está cumprindo seu papel. Vejam e tenham sua própria opinião. A primeira exibição privada ocorreu durante a encontrADA. E a primeira exibição pública será na bicicletaria cultural, dia 28 de junho de 2012. Apareçam! :-)

Ocorreram várias mudanças desde que o último post falando sobre a infraestrutura do projeto foi publicado. Mudamos fisicamente de local, adquirimos hardware novo e tivemos alguns problemas no meio do caminho.

A mudança mais significativa diz respeito a aquisição do hardware novo. Antigamente possuíamos uma máquina que trabalhava como servidor local, provendo o serviço de NFS para máquinas e responsável pelo sistema de backup. A nova máquina adquirida possui dois discos grandes e de mesmo tamanho, então pudemos configurar o sistema utilizando RAID1 e abrimos mão do antigo servidor local. Outra característica interessante dessa nova aquisição é que agora possuímos 2 monitores LCD de 20", que foram configurados utilizando o Xinerama, mas para acertarmos essa configuração nós passamos por maus lençóis...

Esses monitores novos da Samsung não conseguem transmitir as informações do display (EDID) pela interface HDMI, por causa disso o monitor acaba ficando com resolução 640x480 no Linux. No Windows esse problema é ainda pior, o monitor nem sequer sincroniza (aka "liga") e você não consegue utiliza-lo para nada. Nessa altura nós tínhamos 2 monitores de 20" funcionando em resolução 640x480, ao menos o Xinerama funcionava. Foram 2 dias buscando solução para o problema da resolução, até encontrarmos aqui uma forma de fazer com que o Xorg.conf ignore as informações do EDID e utilize apenas as informações configuradas no próprio arquivo. A solução que nós acabamos utilizando é um pouco diferente da existente no link anterior, mas o conceito (forçar configurações, ignorar EDID) é o mesmo. Adicional a versão final (na íntegra) do nosso arquivo Xorg.conf que estamos utilizando atualmente na máquina, esse arquivo possui ainda outras configurações referentes ao Xinerama, a placa de vídeo nVidia, etc.

Esse foi realmente um dos problemas que mais nos deu dor de cabeça na parte da infraesturura. O resto da configuração da máquina foi bastante usual, existem outras pequenas configurações mas que são normais de qualquer instalação, além, é claro, das configurações específicas dos softwares instalados, mas que também não são nada fora do comum. Falaremos disso ainda em outras oportunidades, acho que por hoje é só... :)

Desde o último post publicado por aqui aconteceram muitas coisas que ainda não foram devidamente documentadas. Porém, este fato eu quis relatar antes de tudo porque realmente é um marco.

O Flávio Soares, meu querido amigo lechuga, veio para Curitiba financiado pelo Projeto Contestado. O objetivo de sua estadia por aqui foi, dentre várias coisas que detalharei em outro post, nos ensinar a autorar matrizes DVD no Linux. Haviam ainda algumas ressalvas em relação à esta tarefa, principalmente na legendagem. Porém, as pesquisas dos últimos 3 dias permitiram que elas fossem devidamente sanadas (!). O tom do email dele hoje pra mim resume a história:

em 2010/4/15 flavio escreveu:
> E a GROUNDBREAKING DISCOVERIES INC® consegue a descoberta do século!
>
> Fabs, dê um close no screenshot e você verá que o nosso amigo aqui acaba de
> fazer funcionar o que ele tentava há anos, há séculos, há milênios! Aproxime
> o screenshot, aproxime! Olhe bem o painel de controle do Xine e... lá está!
> Áudio em "pt" e.... Legendas em "pt"!!!!! É incrível senhores! Esta gabiarra
> é mesmo marota!
>
> Agora DVDs autorados em Linux de forma "quase 100%" são coisa do passado!
>
> Só rock n roll!
>


Yeah!

pesquisa focada rocks! =D

detalhamentos da gambiarra em breve, aguardem! :-)

Oi pessoal. Sou o Fernando Severo, roteirista e co-diretor do Projeto Contestado e este é o meu primeiro post sobre a documentação do mesmo.

A vontade de fazer um filme sobre o tema do Contestado remonta aos anos 80 quando tentei realizar um documentário em parceria com Rui Vezzaro. Desanimado pelas dificuldades em conseguir verba para o filme abandonei esta ideia durante muito tempo. Mas o desejo de abordar o tema continuou presente em meu espírito.

Quando conheci Fabianne Balvedi fiquei entusiasmado com a qualidade de seu trabalho em animação e vislumbrei a possibilidade de retomar o tema Contestado dentro dessa técnica. Fabianne aderiu imediatamente à ideia, agregou um grupo de jovens realizadores e fomos à luta, conseguindo o aval da Lei de Incentivo à Cultura de Curitiba e seus investidores. Outro fator que se revelou fundamental neste processo foi descobrir quase que acidentalmente o riquíssimo acervo fotográfico de Claro Jansson, que naturalmente se impôs como o atual fio condutor de nosso trabalho de realização deste filme.

Em um próximo post irei comentar sobre minha metodologia na evolução do roteiro do projeto.

Como não há forma melhor de começar em um blog do que enviando um Hello World!, esse é o título do meu primeiro post. Meu nome é Arthur Furlan, estou começando agora no projeto e sou o sysadmin responsável por toda a infraestrutura utilizada no projeto... ou como diz a Fabs, por toda parte "techie". :)

Os primeiros passos dentro do projeto foram no sentido de "arrumar a casa", então passamos a semana passada organizando a rede interna. Definimos o intervalo de endereços dinâmicos (DHCP), o intervalo de endereços estáticos, criamos o mapa da rede e fizemos todas as configurações necessárias em cada uma das máquinas do ambiente.

Feito isso foi a vez de trabalhar em cima do servidor, que foi reinstalado como Debian Lenny e que por enquanto trabalha apenas como servidor local de arquivos (NFS). Ainda temos bastante trabalho para fazer, principalmente no que diz respeito ao servidor... Temos que criar um subdomínio no no-ip.org para a máquina, liberar acesso remoto, configurar repositórios SVN/GIT, configurar rotinas de backup e muito mais... Assim que formos ativando novos recursos, vamos comentando no blog para que tudo seja o mais transparente possível.

E acho que é isso... em breve teremos mais novidades, diretamente da ala "nerds" do projeto. :)

No post anterior relatei que havia conseguido certo sucesso na geração do arquivo VRML com o PhotoPopup?.

Essa área de pesquisas --geração de um modelo 3D a partir de uma foto (ou de um conjunto estereoscópico de fotos)-- está em franco desenvolvimento em várias universidades e centros de pesquisa pelo mundo afora. Vários foram os artigos que encontrei sobre esse assunto, e parece não haver ainda um consenso sobre a melhor maneira de fazer isso, infelizmente.

O resultado, via de regra, é bastante simplificado, visto que os algoritmos apresentados pelos vários pesquisadores não é capaz de identificar precisamente todos os detalhes da foto. Assim, o resultado seria sempre parecido com a imagem do post passado: a geometria básica está presente, mas os detalhes são ignorados. O casal da foto e o cachorro, por exemplo, ficam achatados e planificados no chão e na parede da casa.



Essa tecnologia ainda não está disponível fora do âmbito das universidades e centros de pesquisas, então teremos que encontrar alguma maneira para tornar o processo possível na munheca mesmo.

A primeira idéia que surgiu foi a utilizaçao óbvia dos displacement maps (DM) no Blender. A teoria é a seguinte: o Blender aplica um deslocamento (displacement) aos vértices do objeto baseado em um mapa (o displacement map). Esse mapa é uma imagem em tons de cinza, que o Blender usa saber se um vértice deve ser deslocado para dentro ou para fora do objeto original. Se o mapa é claro, o vértice é deslocado em uma direção; se é escuro, o vértice é deslocado na direção oposta.

Ou seja: no displacement map ficam as informações de profundidade que se quer aplicar à foto. Esse é um exemplo de um displacement map onde foi utilizada a convenção escuro=frente e claro=atrás.



O problema dessa metodologia é que o Blender só aplica o DM ao renderizar a imagem. Assim, fica complicado compor ângulos de câmera, animações e outros efeitos sobre essa imagem, já que na vista de trabalho do Blender ela vai aparecer sempre plana.

O ideal seria que pudéssemos utilizar o mapa para efetivamente alterar o objeto fisicamente, alterando a posição real de seus vértices.

É aqui que entra o nosso amigo Gus. Gus, é com você.

Pois é, hoje nos apavoramos. Nosso último post no blog foi em primeiro de abril, e não é mentira! Quem dera fosse e estivéssemos com tudo em dia, porém isso não é verdade. Muita coisa aconteceu, mas não conseguimos documentar quase nada nestes últimos três meses. Espero que intervalos como esse não se repitam mais. Porém, como o próprio título deste post diz, não é uma tarefa nada fácil produzir e documentar ao mesmo tempo. Mas não vamos desistir de jeito nenhum de nossos relatos, pois este é um dos principais objetivos deste projeto. Hay que produzir, pero sin perder la documentación jamás! (ugh)

Crédito da Imagem: Wellcome Library, London

Revisando o texto do último post antes da publicação, não pude deixar de sentir-me um tanto frustrado, como vocês podem imaginar.

Porém, um detalhe incomodou-me muito durante o processo de teste do photoPopup: um aviso na página do tutorial sobre os visualizadores VRML para Linux.

Sempre desconfiei de duas coisas que poderiam ser responsáveis pelo fracasso das tentativas:

Uma era o fato do Gimp não salvar no formato .pbm, apesar de saber que o formato salvo por ele poderia simplesmente ser renomeado sem problemas.

A outra era que talvez o visualizador de VRML não estava conseguindo ler os arquivos corretamente.

Munido dessa segunda dúvida, fiz uma nova busca por "VRML viewer linux" e descobri um tal de Octaga Player, indicado num blog como o único visualizador VRML para linux que funcionava realmente.

Ok, ele não é software livre, eu sei. Mas e se o problema fosse realmente apenas a visualização dos arquivos, e se o photoPopup estivesse realmente popando, mas nós é que não conseguíssemos ver?

Baixei e instalei. Tentei abrir o arquivo gerado na minha última tentativa. Ao invés de uma tela preta e uma mensagem de erro, eis que o rio de Florença aparece na tela, com prédios ao lado, e o céu acima. Achei que o programa havia carregado a foto original, achei que pudesse ter clicado no arquivo errado por engano. Cliquei e arrastei o mouse, e a imagem moveu-se em um espaço 3D.

O photoPopup funciona desde o início! O problema era o visualizador! Estávamos cegos criticando o quadro na parede.

Fiz outro teste rápido com uma das fotos do Claro:
http://estudiolivre.org/el-gallery_view.php?arquivoId=6818&

CTRL+S, pessoas. Daniel aqui, e esse post é sobre nossa tentativa frustada de usar uma ferramenta que nos pareceu sensacional, o photoPopup.

Resumidamente, o photoPopup gera um arquivo VRML a partir de uma foto, tornando possível a visualização em 3D dessa foto, de forma automática e indolor. Como grande parte das nossas fontes iconográficas são as fotos de Claro Jansson, pensamos que poderíamos aproveitar a ferramenta com elas. Imaginem um passeio 3D por uma cena do Contestado!

Armados com o mais puro entusiasmo, jogamo-nos a testar o photoPopup. A seguir, os vários passos dados por mim nesses testes:

Primeiro de tudo, baixamos o software em si, e mais as dependências necessárias, linkadas diretamente da página do projeto.

As instruções são dadas por outra pessoa, em outra página. Passos 1 e 2 ok, sem problemas, apenas algumas alterações em variáveis de ambiente do Linux e a instalação propriamente dita. Mas cuidado! Essas alterações podem fazer alguns de seus aplicativos deixarem de funcionar corretamente!

No passo 3 enfrentamos nosso primeiro problema. O software precisa que a foto a ser processada esteja em formato PBM (Portable BitMap). Abri o GIMP, escolhi uma foto do Largo da Ordem aqui em Curitiba, encontrada na internet, e procurei a extensão .pbm para salvar. Negativo. O GIMP não salva em .pbm. O arquivo tem que ser salvo em .pnm e depois renomeado para .pbn (que, de acordo com alguns sites e fóruns, é a mesma coisa).

Passo 4: compilar e instalar outro software (segment) para geração de um arquivo usado no processo. Para isso fez-se necessária a instalação do pacote g++.

O passo 5 é o uso do software instalado no passo 4 (segment) para a geração do arquivo. Por algum motivo, o segment só completava a tarefa quando rodado como root (prática altamente desaconselhável, crianças)! O arquivo gerado, então, devia ter suas permissões alteradas para poder ser utilizado pelo photoPopup: $chmod 666 arquivo_gerado.pnm

Passo 6: photoPopup fazendo sua mágica (em teoria). Ao contrário do segment, o photoPopup não pode ser rodado como root. Após algumas tentativas, descobri também que endereços absolutos não funcionam com ele. Os argumentos da linha de comando devem ser dados como endereços relativos (../teste).

Passo 7: Como descrito na página de instruções: "Veja"! Bom, não é tão fácil assim. Tínhamos os arquivos VRML gerados pelo photoPopup, mas não conseguimos visualizá-los em nenhum dos navegadores VRML encontrados na web. Sempre a mensagem "warning: The axis component of a rotation must be a normalized vector", e uma tela preta aparentemente vazia, sem objeto algum. Fui atrás de alguma maneira de ver o resultado e o blender foi a próxima parada. O arquivo VRML pôde ser aberto com ele, mas o resultado é ininteligível. Existe uma geometria, mas as texturas não são aplicadas automaticamente e a própria geometria é indecifrável para humanos normais.

Assim, sem conseguir fazer o programinha gerar resultados satisfatórios, tentei entrar em contato tanto com o desenvolvedor (que não respondeu, infelizmente) quanto com a pessoa que escreveu a página de tutorial utilizado. Ela respondeu, mas a única vez em que havia usado o programa foi no dia em que escreveu a página, e depois disso nunca mais precisou dele. Portanto, não podia oferecer muita ajuda a não ser "tente entrar em contato com o desenvolvedor".

Abandonamos, pois, o photoPopup. Assim que chegar no Olho Vivo posto os arquivos que utilizamos para esses testes, com o resultado final. Se alguém tiver alguma idéia ou sugestão, acho que ainda dá tempo de pensarmos em utilizá-lo.