Recuperando Informação Visual

Há algum tempo aqui no Blog, um post do Kenji chamou atenção para a categorização e recuperação de imagens. Com o aumento da oferta de câmeras digitais (cada dia melhores e mais baratas) e a farta disponibilidade de imagens na WEB (Picasa, Flickr e afins), a capacidade de humana de categorizar e buscar imagens tem diminuído rapidamente (quem nunca se esqueceu em qual pasta armazenou aquela foto perfeita?). Uma maneira de automatizar este processo é utilizar um sistema de Recuperação de Imagens com Base no Conteúdo – RIBC (em inglês Content-Based Image Retrieval).

Na abordagem RIBC, como nome indica, o próprio conteúdo visual é utilizado na análise da imagem. De maneira geral esta análise é realizada utilizando alguma técnica de Processamento Digital de Imagens ou Visão Computacional. Mas o que seria este conteúdo visual de uma imagem? De forma simples, é possível definir o conteúdo visual com base em atributos de baixo nível como cores, formas e texturas presentes na imagem.

Assim, para a categorização de uma base de dados visuais qualquer (como as fotos de suas últimas férias), algoritmos que, por exemplo, detectam correlações entre as cores, orientação em texturas ou formas presentes nas imagens são empregados na geração de vetores de características (feature vectors).

Consultas a uma base já categorizada podem ocorrer de várias formas:

  • busca por exemplo, onde uma imagem de exemplo é fornecida. Tal imagem pode ser um desenho criado pelo usuário ou algum imagem pré-existente;
  • busca por distribuição de cores, onde a distribuição de cores esperada é fornecida (60% azul e 40% verde representando imagens panorâmicas com o horizonte ao fundo);
  • busca por formas, onde a forma desejada é fornecida (como o formato de um automóvel);

A recuperação da informação visual é, então, realizada pela comparação entre os vetores de características da base e aquele obtido da consulta.

Uma das aplicações mais interessante desta tecnologia, e que serve para ilustar o seu uso, pode ser encontrada no site do Museu Hermitage de São Petersburgo, Rússia. Desenvolvido em parceria com a IBM, o site possibilita ao visitante virtual pesquisar a grande coleção de arte do museu utilizando o sistema QBIC de recuperação de informação visual. Consultas por distribuição de cores e por desenho de exemplo são permitidas e os resultados são bastante interessantes (veja um exemplo nas imagens abaixo).

Consulta

Consulta por distribuição de cores no sistema QBIC.

Resultado

Resultado de busca do sistema QBIC.

A RIBC é um campo de pesquisa ainda em aberto e muito desafios não possuem soluções satisfatórias como, por exemplo, a realização de consultas semânticas como “fotos de cachorros”. E, exatamente por isso, é uma área tão interessante ;-).

Inovação, Internet, Processamento de Sinais, Visão Computacional 0 Comentários

1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)

Escalabilidade transparente

Escalabilidade é um conceito importante em qualquer sistema web, embora eu ache que às vezes as pessoas se preocupam demais com isso. A grande maioria das aplicações web simplesmente não precisam escalar muito. Existe, então, um trade-off entre tempo de desenvolvimento e o esforço extra necessário para planejar e implementar sua arquitetura de forma a escalar da melhor maneira possível. Quando você não precisa lidar com enormes volumes de dados e usuários simultâneos, muitas vezes a decisão correta, do ponto de vista de negócio, é minimizar o tempo de desenvolvimento e arcar com algum custo extra de hardware caso preciso. Hardware que fica mais barato a cada dia.

Existem outras alternativas, que tentam garantir que sua aplicação é escalável sem cobrar um preço caro em termos de tempo e esforço de desenvolvimento. Um ponto chave é minimizar o compartilhamento de dados entre componentes da sua aplicação. Se você não compartilha nada, fica mais fácil escalar. Esse modelo, chamado de “shared nothing”, é encorajado por diversos frameworks para desenvolvimento web, e é praticamente obrigatório quando se desenvolve com Ruby on Rails, por exemplo.

Quando sua aplicação segue o modelo “shared nothing”, você pode obter escalabilidade simplesmente usando os serviços da Amazon. Precisa de mais servidores web? Adicione instâncias à sua conta da Elastic Computing Cloud. Precisa de mais servidores de banco? A mesma coisa, mas as instâncias são configuradas de outra forma (que você pode definir, através de uma imagem de máquina virtual). Espaço em disco? Sem problema. Tudo sobe e desce de forma quase instantânea. Um grande avanço comparado ao processo tradicional de estimar suas necessidades de hardware e comprar os servidores com alguma antecedência — ou sair correndo para apagar o incêndio quando ele estoura.

Pois agora tem gente que acha que mesmo serviços como os da Amazon são muito complicados. Estão querendo transformar escalabilidade em algo totalmente transparente para o desenvolvedor. Um exemplo disso é a Heroku, que lançou recentemente um serviço de escalabilidade automática. Você registra sua aplicação (Ruby on Rails) com eles e eles cuidam de escalar usando os serviços da Amazon. Você não precisa se preocupar com a monitoração dos seus nodos de processamento, decidir quando adicionar ou remover nodos, etc. Você pode até desenvolver sua aplicação usando um IDE web que eles oferecem.

Claro que um serviço desses tem suas desvantagens. Em primeiro lugar, você perde em flexibilidade: vai ter que usar as versões de Ruby, Rails e bibliotecas que a Heroku suporta. Não há como integrar facilmente sua aplicação com sistemas legados. E assim por diante.

Mesmo assim, é mais um grande avanço em uma das tendências-chave por trás da Web 2.0: a redução de barreiras de entrada. Cada vez que um obstáculo técnico ao sucesso de um produto web é removido, fica mais fácil e barato desenvolver novos produtos inovadores. Sob essa ótica, viva a escalabilidade transparente!

Desenvolvimento, Internet, Web 2.0 0 Comentários

1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)

Ruby On Rails

Quem trabalha com “Desenvolvimento Web” quase certamente já ouviu falar de Ruby On Rails. Assim como muitas tecnologias, RoR (pra encurtar) gerou muito hype nos últimos meses e, consequentemente, uma legião de fanboys que pregam fervorosamente que RoR é a melhor coisa que já inventaram desde o pão-fatiado. :-)

O quê

Mas em que consiste exatamente o tal “Ruby On Rails”? Traduzindo diretamente do site oficial:

Ruby On Rails é um framework web de código aberto que é otimizado para a satisfação do programador e produtividade sustentável. Ele permite que você escreva código elegante ao favorecer convenção ao invés de configuração.

E ainda:

Ruby On Rails é um framework completo para desenvolvimento de aplicações web de acordo com o padrão Model-View-Controller (ou MVC).

Até aí, nenhuma novidade. Antes da popularização de RoR, já existiam diversos outros excelentes frameworks como ASP.NET, a pilha Servlets+JSP+Struts+Hybernate e PHP/Zend, só pra citar alguns. O diferencial de RoR está justamente na adoção da metodologia de desenvolvimento de software “Ágil”, ao focar as funcionalidades do framework nas necessidades diretas dos desenvolvedores e diminuir tanto quanto possível o tempo gasto com instalação e configuração do ambiente.

Por esse motivo, RoR se tornou especialmente popular entre desenvolvedores e empresas que adotam processos semelhantes ao “Extreme Programming”, onde a elaboração rápida de um protótipo e a constante refatoração do código são essenciais. RoR realmente prima nestes casos. Chega a ser assustador a facilidade com que se gera o esqueleto e o protótipo de uma aplicação MVC, ou o número ínfimo de linhas de código que são necessárias para implementar funcionalidades relativamente sofisticadas.

Porquê

Descontando um pouco do exagero típico dos fanboys, é fácil notar com pouco tempo de uso porque Ruby On Rails se popularizou tão depressa.

  • Convenção ao invés de Configuração: Levante a mão quem nunca perdeu pelo menos umas 2 horas de trabalho tentando instalar ou configurar uma aplicação/sistema/etc e descobriu no fim do dia que o problema era um “;”, ou um path errado. Pois é, RoR procura acabar com essa dor-de-cabeça ao eliminar tanto quanto possível os malfadados arquivos de configuração através da adoção de uma série de convenções que permite integrar as diferenças partes do framework sem praticamente nenhuma intervenção direta do desenvolvedor.As convenções englobam todo tipo de aspecto de uma aplicação web: o nome dos modelos e tabelas relacionais associadas; o nome da colunas das tabelas que constituem chaves primárias e estrangeiras; o nome dos arquivos e das classes que implementam cada camada da estrutura MVC; o nome e identificador dos campos HTML e diversas outras.
  • ActiveRecord: Active record é um design pattern utilizado para acessar bancos de dados e fazer o mapeamento Objeto-Relacional. O padrão em si é bem mais antigo do que RoR, mas a implementação utilizada em RoR em específico prima pela qualidade e é um dos pontos fortes e mais badalados do framework. A extensa utilização de instrospeção, tanto do lado da estrutura relacional, quanto da parte das classes e objetos torna praticamente desnecessário escrever mais do que meia dúzia de linhas de código para se fazer o mapeamento de uma classe/tabela.
  • ActionView: Da mesma forma que o módulo ActiveRecord é responsável pela implementação dos modelos, ActionView é o módulo responsável pela implementação das visões. O diferencial está no fato de este módulo ser fortemente influenciado pela metodologia ágil: quase todas as funcionalidades tipicamente utilizadas para construção de uma interface web podem ser adicionadas através de uma API concisa e intuitiva. Mesmo as tendências mais recentes das aplicações Web modernas — como Javascript, DHTML e AJAX — estão fortementes integradas ao framework. Em RoR, usa-se apenas uma linha de código para adicionar funcionalidades relativamente complexas como “atualizar uma tabela/list assincronamente” ou “adicionar um campo de texto com auto-sugestão” (no estilo Google Suggest))
  • Plugins: Outra grande vantagem de Ruby On Rails é sua extensibilidade. Devido à sua crescente popularidade, existem hoje literalmente centenas de plugins (normalmente gratuitos) disponíveis para os desenvolvedores incrementarem suas aplicações conforme as necessidades individuais de cada projeto — permitindo assim que uma gama enorme de problemas sejam rapidamente resolvidos sem necessariamente tornar o core do framework demasiadamente inchado. Mas cuidado: em alguns casos, é preciso ficar atento para não se perder mais tempo escolhendo o melhor plugin que implementa uma deterinada funcionalidade do que efetivamente instalando e utilizando o plugin. :-)
  • Ruby: Flamewars discutindo qual a melhor linguagem são quase tão antigas quanto a própria computação — portanto não vou me alongar demasiadamente nesse tópico — mas é inegável que parte da atratividade de RoR advém da linguagem Ruby. Pra quem ainda não conhece, sugiro o tutorial rápido do site oficial, ou ainda o divertidíssimo“Guia Pungente”, por “Why The Lucky Stiff”.

Por que não

Nenhuma boa análise técnica estaria completa sem uma seção de “Contras”, e esse post não poderia ser diferente.

  • Performance: Um dos compromissos que precisam ser feitos para se tirar proveito da elegância e agilidade de se utilizar uma linguagem como Ruby é o desempenho. Por ser uma linguagem dinamicamente tipada que executa sobre uma interpretador (pra lá de ineficiente, diga-se de passagem), Ruby On Rails é inegavelmente um framework com overhead alto. Muita gente vai argumentar que baixa performance não é tão crítico se sua arquitetura tem boa escalabilidade, e outros ainda irão citar diversas técnicas para minimizar esse overhead, mas ainda assim, em alguns casos a recomendação é deixar de usar justamente as funcionalidades que tornam o framework interessante.Por outro lado, as comunidades por trás de Ruby e RoR estão cientes desse problema e tem trabalhado para atenuá-lo. A versão 2.0 de RoR, por exemplo, já apresenta significantes melhorias, e a próxima grande revisão da linguagem Ruby que deve ser lançada ainda nessa década também promete ganhos substanciais de performance, graças à utilização de um nova máquina virtual.
  • Código legado: Uma das máximas de RoR — “Convenção ao invés de configuração” — perde seu appeal quando consideramos sistemas legados. Nesses casos, é provável que sua base de dados ou suas classes existentes não tenham adotado as mesmas convenções utilizadas por RoR. Com isso, é necessário adicionar diversas diretrizes no código para sobrescrever os valores e padrões utilizados pelas tais convenções. Não chega a ser a mesma dor-de-cabeça de se editar um “hibernate.cfg.xml” ou um “web.xml”, mas é possível que você acabe sendo forçado a escrever alguns trechos de [gasp!] SQL. :-)
  • Documentação: Algumas tecnologias promissoras perdem momento devido à carência de documentação. Ruby On Rails sofre do problema inverso: excesso de documentação. Hoje em dia é natural utilizar a Internet para buscar por trechos de código, recomendações, receitas ou (no caso de RoR) plugins para se solucionar um problema específico ou implementar corretamente uma funcionalidade. O problema é que, frequentemente, a documentação ou plugin encontrados estão defasados por terem sido escritos/implementados com foco em uma versão do framework que já está deprecada. Como o desenvolvimento de RoR é muito dinâmico — a versão 1.0 foi lançada em Dez/05; a versão 1.1 em Mar/06; a 1.2 em Jan/07; e a 2.0 em Dez/07 — e não existem garantias de compatibilidade, muitas vezes torna-se difícil encontrar a solução correta para a versão específica do framework que você está utilizando.

Pra finalizar

Se você se é desenvolvedor Web, mora em Belo Horizonte, se interessou por Ruby On Rails e gostaria de saber mais a respeito, o Instituto Turing está oferencendo um curso intensivo à partir do dia 14 de abril. Para maiores informações, mande e-mail para cursos@institutoturing.org.

Desenvolvimento, Internet, Web 2.0 3 Comentários

1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)

Firefox 3 Beta 5: Ainda melhor e mais rápido!

Há algum tempo contei das minhas experiências com o Firefox 3 beta 4. Fiquei impressionado com o desempenho, mas alguns bugs ainda me incomodavam (especificamente, a caixa de texto de Compose do GMail se corrompia, mostrando linhas e pixels espúrios enquanto eu digitava).

Ontem eu comecei a usar a nova beta 5. Surpreendentemente ela é ainda mais rápida que a beta 4, e resolveu todas as questões que levantei no outro post. Até onde vi, é um browser pronto para uso no dia-a-dia; o consumo de memória está baixíssimo (e sem memory leaks; a beta 4 rodou por vários dias sem iniciar, até ser substituída por essa nova).

Acreditem: o Firefox 3 beta 5 é o melhor browser que conheço – não tem para Safari, Opera ou (ha-ha!) Internet Explorer.

Internet 0 Comentários

1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)

Next Entries »