Para mostrar um pouco do Anima, revisitei o primeiro tutorial deste blog: Como contar objetos. O resultado coloquei num vídeo.

A interface ainda tem seus defeitos (como o fato dos diálogos não abrirem onde querem, às vezes fora da janela principal), mas estamos trabalhando nisso também.

O importante neste projeto é que está sendo construído como uma plataforma de testes e desenvolvimento, isto é, arquitetura de software favorecendo a extensão.

Por enquanto, é um software mais para desenvolvedores, e “beta-testers”, mas pretendemos facilitar as coisas para o usuário comum, com dicas e informações na interface. Alguns alunos do LaCA já estão utilizando o Anima para implementar seus projetos de pesquisa e as novas ferramentas estão por vir.

As metodologias ágeis começaram a ser conhecidas a partir da publicação do manifesto ágil, em 2001. Estes autores reuniram suas experiências e colocaram no papel na web, em pontos claros e sem muita conversa, um conjunto de princípios pelos quais eles defendem que o desenvolvimento de software deve se guiar.

Durante sua pesquisa, Jean separou dois métodos (ou frameworks, ou metodologias, ou modelos… deixo para os acadêmicos a discussão de nomenclatura), estudou e aplicou nas nossas equipes de desenvolvimento, das quais também participo.

Usamos o SCRUM e o XP.

Na prática

Antes que me pergunte, não chegamos a adotar a controversa programação em pares do XP, mas é algo que não descartamos para o futuro.

Um quadro de scrum na Animati Computação Aplicada

Usamos os ciclos curtos de entrega ao cliente, a priorização para a implementação de funções que agregam valor ao software, a refatoração frequente do código, a padronização da codificação para que todos possam entender o código todo, o quadro de tarefas do Scrum com gráfico e tudo, e alguns outros.

A figura aqui ao lado é o quadro durante o primeiro sprinte de um projeto de computação científica que ainda está em andamento. Dá para ver que não é nada sofisticado, mas acreditem: isso funciona. O importante é que todos ficam sabendo o que já está pronto e o que ainda falta fazer.

O fato de sabermos que nenhum código é imutável, e que qualquer coisa pode ser refatorada a qualquer momento diminui a insegurança de tentar algo novo, e faz com que se tenda a adotar uma das boas práticas: encapsular. Isso é particularmente importante em projetos como os que trabalhamos às vezes, em que não há certeza sobre o que  vai funcionar no final.

Quanto ao quadro, é ótimo para manter a equipe sempre informada, mas pode ser que tenhamos que achar outra solução, agora que algumas equipes vão incluir estudantes de mestrado e graduação, que não ficam na mesma sala. E teremos que achar um substituto para as reuniões diárias também.

Os clientes

Até agora todos gostaram das entregas mais frequentes. É mais fácil discutir requisitos com algo para ver. A confiança na equipe também aumenta conforme o cliente  vê o trabalho sendo feito.

As metodologias ágeis nas empresas de software

A adoção de metodologias ágeis é uma tendência mundial. É bom para TODOS os projetos? Claro que não, essas coisas nunca são unânimes. Mas é bom para uma boa parte de empresas.

Por isso, aqui em Santa Maria, algumas empresas se uniram, entre outras coisas, para melhorar seus processos. E escolhemos o SCRUM para estudar e implementar. A Animati e a Sicon já tinham começado, e agora as outras empresas do CentroSoftware tembém vão “agilizar” seus projetos de software.

Queremos que Santa Maria torne-se um pólo de desenvolvimento de software,  e que passe a se beneficiar de uma parte maior do conhecimento gerado em suas universidades.

Porque isso é uma boa notícia

É fato notório para a comunidade de usuários e desenvolvedores que a arquitetura do ImageJ é ultrapassada, que falta flexibilidade na interface, que alguns formatos de dados não são suportados, etc.

Tanto é, que várias iniciativas já iniciaram no sentido de ‘reformar’ o ImageJ, mas morrem na praia quando se deparam com obstáculos como falta de $$$ e discordâncias sobre qual seria a melhor ‘reforma’.

O novo projeto – imagejdev.org – tem os dois. O apoio financeiro de uma agềncia do governo americano, e um conjunto de diretrizes e objetivos, que foram levantados a partir de estudos prévios de vários projetos de ‘reforma do ImageJ’. Além disso Wayne Rasband, o ‘pai do ImageJ’, também apoia o projeto, o que facilita muita coisa.

A missão

Uma missão conhecida por todos norteia um projeto, estabelecendo quais aspectos são importantes (e evitando repetidas crises de identidade periódicas).

A missão do imagejdev inclui manter uma versão oficial do ImageJ em desenvolvimento, atender a maior comunidade possível e manter o máximo possível de compatibilidade com os plugins que já existem. Além disso, deve servir como uma central online de recursos (downloads, listas de plugins, etc.), como é comum em projetos open-source.

O plano técnico

Estão fixadas metas e objetivos técnicos, também. A íntegra pode ser lida em inglês em ImageJ as an Extensible Image Processing Framework.

Destaco os seguintes:

• Separação entre os métodos matemáticos e a interface: isto é fundamental para que se possa desenvolver versões customizadas e fáceis de usar, para usuários iniciantes e outros casos especiais. Também possibilitaria o uso do ImageJ como uma biblioteca, para o desenvolvimento de outros aplicativos.
• Crescer com o apoio da comunidade, sem perder compatibilidade com plugins já existentes: isto é um grande desafio, e foi empecilho para muitos outros projetos precursores deste.
• Expandir funcionalidades interagindo com outros projetos: Já está previso o envolvimento da equipe com dois projetos: o VisBio, e o CellProfiler. O novo ImageJ deverá ser capaz de trabalhar integrado a estes softwares. Se a experiência der certo, é claro que podemos pensar em outros…

Como acompanhar os próximos acontecimentos

Na sessão blogs, já há alguns posts de integrantes do projeto, e tem RSS (já assinei).

Eu também vou acompanhar, por isso vale também assinar o RSS do ImageSurvey, e me seguir no twitter!

Como pesquisar

O  SourceForge.net tem formulários de pesquisa simples em quase todas as suas páginas. Você pode começar por aí, mas o melhor mesmo é ir para a pesquisa avançada.

A busca pelas suas palavras-chave ocorre no título e na descrição dos softwares e, às vezes a informação que se busca não está lá, como a linguagem de programação, ou alguma funcionalidade/ compatibilidade em especial. A opção é usar o google, que superestima os resultados porque inclui entradas de fórum, e todo o tipo de texto que estiver no site.
Também é possível navegar pelos tópicos, ou pesquisar somente um ou mais tópicos específicos, mas como não há um tópico “image processing”, é preciso procurar pelos projetos em suas áreas de aplicação ou em tópicos parecidos.
Por isso as quantidades a seguir devem ser tratadas como meras estimativas…

Survey: primeira aproximação

Num universo de mais de 320 mil projetos, comecei pelo óbvio: a expressões mais usadas para descrever softwares do tipo que procuro:

• image processing – 255 projetos encontrados;
• image analysis – 30 projetos;
• computer vision – 95 projetos.

Foram encontrados 380 projetos (0,12 % do número total) nas áreas que escolhi. Provavelmente o número é maior, pois estas expressões, apesar de bastante usadas, não precisam necessariamente fazer parte do título ou da descrição de um projeto que faça uso de algoritmos de processamento e análise de imagens.

Conhecendo os projetos

Existem algumas formas de refinar estas buscas ou mesmo organizar a ordem de apresentação, usando as estatísticas apresentadas na página de resultados.

Screenshot dos resultados da pesquisa.

Existe um wiki com a documentação do SourceForge, que explica com as coisas funcionam, mas eu custei um poco para achar. Lá você encontra a explicação sobre as estatísticas que são calculadas para cada projeto. São estas últimas que mais me interessam, pois permitem que se saiba um pouco sobre os resultados da busca, antes de começar a seguir os links.

Num primeiro momento, seus resultados serão organizados em ordem decrescente de relevância (Relevance). Este conceito relaciona suas palavras-chave com as do projeto, ou seja, diz o quanto aquele projeto se aproxima da busca que você fez.

Na coluna seguinte, aparece  a Atividade (Activity) de cada projeto. Clicando sobre ela, você reorganiza seus resultados pelo valor da atividade. Esta é uma métrica de comunicação do projeto. Ela mede a quantidade de entradas em fóruns, listas de email, relatórios de bugs, entre outros.

O Rank é um agregador de estatísticas usado para gerar as listas de projetos mais ativos. É útil para ter uma visão geral da colocação do projeto.

As colunas seguintes são a data em que o projeto foi registrado, a data em que o último arquivo foi criado, e o número de downloads do software (quando o software já existe).

Além disso existem ainda outras características que podem ser vistas no modo estendido de mostrar resultados. Para isso procure os links Details, Images e Filters, no canto superior direito (logo acima da publicidade…). Clicando em Detail, você ativa a visão expandida, que dá mais informações como Linguagem de programação, licença, estágio de desenvolvimento, entre outros.

O link Filters, ativa uma barra de filtragem para a pesquisa, que  permite filtrar projetos por linguagem de programação, sistema operacional, licença, estágio de desenvolvimento, entre outros.

Barra de filtro da pesquisa.

E agora?

Agora você já tem informações suficientes para escolher alguns projetos e conhecê-los melhor. Em relação à quantidade total de projetos, achei que a área de processamento e análise de imagens ainda é tímida. Tem muitos projetos de “grupo de um só”, e outros que começam e se perdem em “betas infinitos”, para morrer na praia.

Acho que falta um pouco de visão dos novos programadores. Trabalhar para um projeto opensource não significa necessariamente trabalhar de graça. Muitos destes softwares são vendáveis. O software é gratuido, mas um bom profissional pode oferecer instalação e assistência técnica para clientes corporativos, que pagam pela garantia de que o software vai funcionar. Quem melhor para oferecer estas garantias do que um desenvolvedor do projeto?

No SourceForge.net há uma área (recém criada) chamada Marketplace. Lá você oferece serviços, e seu currículo inclui os projetos dos quais participa ou já participou.

Então, que tal trocar as horas perdidas com o Orkut por uma coisa mais útil?

Fiz uma análise de final de ano em 2008 e descobri que uma das expressões que mais trouxe leitores a este blog foi “como usar imagej”. Sendo assim, nada mais promissor que ter um artigo com este título, para que quem procura, encontre exatamente a informação de que precisa.

Como usar o ImageJ?

A resposta para esta pergunta começa por outra pergunta: o que você precisa/quer fazer com o ImageJ?

O ImageJ é um software para processamento e análise de imagens, desenvolvido por  Wayne Rasband no National Institute of Mental Health, USA. em Java. Com ele é possível realizar várias tarefas de processamento e análise de imagens. Alguns exemplos do que se pode fazer com ele estão nos tutoriais já publicados aqui no ImageSurvey.

Há ferramentas de ajuste de brilho e contraste, ferramentas de segmentação e análise, medição de distâncias e ângulos, possibilidade de processar e analisar imagens de uma só vez, entre outros.

Este tutorial pretende ser um guia para iniciantes, que contém algumas explicações e muitos links para os recursos que você vai precisar para se tornar um expert em ImageJ (ou só fazer o dever de casa, se este for seu objetivo…)

1. Baixe e instale:

Download ImageJ.

Encontre o arquivo para o seu sistema operacional, baixe e instale.

(updade de 07/07/2009) Se estiver usando Ubuntu, como eu, é só ir em Adicionar/Remover aplicações, pesquisar ImageJ e mandar instalar.

2. Inicie o programa:

Da mesma forma que você faz com todos os outros que estão instalados no seu computador.

Janela principal do ImageJ.

Para quem está acostumado a aplicativos Microsoft, pode parecer estranho um programa abrir apenas um pequeno menu, sem aquela área de trabalho que ocupa a tela toda. Você se acostuma…

3. Abra uma imagem

No menu File, você vai encontrar comandos familiares, como Open… e Open recent. Open Samples abre uma das imagens de exemplo do ImageJ, e Open Next abre a próxima imagem do diretório e fecha a que estiver aberta.

4. Escolha suas armas

Entre os grupos de recursos nativos estão:

• Ferramentas de seleção
• Compatibilidade com vários formatos de imagens, incluindo DICOM, e TIFF
• Ajustes de cor e histograma
• Ferramentas de medição manuais e (algumas) automáticas
• Escala de imagens
• Segmentação
• Processamento de imagens binárias
• Filtros
• Transformada de fourier

Todos os recursos estão acessíveis no menu e alguns tem botões para acesso rápido na barra de ferramentas. É possível automatizar tarefas através das macros, ou usando pilhas de imagens (veja na lista de tutoriais).

Boa parte da interface é auto explicativa, mas existe um help/manual na página oficial do ImageJ.

5. Não é suficiente?

A meu ver o melhor de todos os recursos é o que permite estender o programa: a possibilidade de se escrever plugins!

Onde encontrar plugins:

No wiki do ImageJ – Plugins
Na página oficial – plugins

6. Mais recursos

6.1 Tutoriais do ImageJ no ImageSurvey:

Lista atualizada em 19 de março de 2009:

• Como contar objetos – Parte I
• Como contar objetos – Parte II
• Agrupando imagens em pilhas
• Processamento em lote
• Tutorial ImageJ – medição de área foliar
• Tutorial ImageJ: Macros
• Watershed em imagens binárias, e um exemplo útil com ImageJ
• Como captar imagens para processamento usando sua câmera digital
• Tutorial: Diâmetro de esferas, com ImageJ
• Tutorial ImageJ: como “medir a cor” dos objetos

6.2 Documentação do ImageJ

• Help/Manual oficial do ImageJ
• Wiki da documentação (não tem informação sobre quem é o “dono”).
• Recursos para desenvolvedores

6.3 Fóruns e listas de email:

Lista oficial: Eu assino a lista e acho bastante ativa. Antes de perguntar pesquise o arquivo de emails.

Se alguém souber de alguma lista em português, deixe um comentário.

Mais tutoriais? Assine o RSS feed do ImageSurvey e você recebe assim que forem publicados!

A maioria dos desenvolvedores (e não programadores, apesar da humildade de Edsger W. Dijkstra) de software concorda que são muito mais produtivos quando fazem uso de sistemas de software eficientes. Estes desenvolvedores podem, desta maneira, ser mais produtivos e contribuir para a evolução de tais sistemas. Podem, inclusive, trabalhar mais rapidamente e fazer uso destes sistemas no desenvolvimento de aplicações específicas, moldando o sistema final conforme as necessidades do usuário.

Conhecimento posto em prática

Philip G. Armour, no livro “As Leis do Processo de Software”, informa que o software não é um produto, mas conhecimento posto na prática. Ele mesmo crê que o desenvolvimento de software e o processo de aplicação como são geralmente definidos e compreendidos é limitado por algumas das realidades do mundo dos negócios onde o software se torna um produto. O ponto crucial deste suposto antagonismo é que o desenvolvimento de um conhecimento que seja aplicado é, e sempre será, uma atividade de descoberta.

É claro que podemos definir rigorosamente um processo para todos os aspectos de nosso trabalho que são perfeitamente estruturados e organizados. Porém, não podemos definir rigorosamente um processo para atividades do nosso trabalho que são baseadas na descoberta. Armour contribui, desde 2000, para a Communications of the ACM, escrevendo regularmente para a coluna The Business of Software. Recentemente, Armour criou um blog denominado de Systems: Psychology and Software.

Uma criação pura da mente

Andriy Solovey, autor do famoso blog Software Creation Mistery argumenta que o software é uma criação pura da mente, incluindo três atividades principais: compreensão, evolução e troca de experiências. A compreensão se refere ao aprendizado e entendimento dos conceitos e implementações do sistema. A evolução refere-se à construção, modificação e o suporte ao crescimento do sistema, enquanto que a troca de experiências permite a comunicação e a troca de idéias sobre o sistema.

Linhas de produção

Recentemente participei de uma escola de verão sobre linhas de produção de software (Software Production Lines) e do workshop de esforços em reuso de software. O Evento foi organizado pela RISE e CESAR no Recife. Após ouvir as palestras de Paul Clements do Software Engineering Institute e de Rob van
Ommering da Philips Research acabei observando que a grande diferença entre os conceitos de engenharia de software tradicional, onde podemos aceitar que o software seja um conhecimento posto na prática nas palavras de Armour, e a engenharia de linhas de produção de software, conforme Clements e Ommering, é a grande importância dada aos requisitos de software.

A abordagem da engenharia de linhas de produção de software é fundamentada na utilização de técnicas avançadas de engenharia que permitem desenvolver sistemas de software similares a partir de um conjunto de especificações (requisitos) comuns a todos esses sistemas usando, para atingir seus objetivos, um meio comum de produção.

As linhas de produção de software têm recebido muita atenção pela comunidade científica e tecnológica que alguns estudiosos chegam a acreditar que estamos diante de um novo paradigma para que empresas possam otimizar seus processos de engenharia de software. Muito embora esta idéia não seja original… (lembro de módulos, objetos, componentes entre tantas outras palavras que foram usadas no final do século XX para descrever a reusabilidade pregada pela programação orientada por objetos, por aspetos e genérica) encontra suporte justamente na linha de produção.

Milhares de softwares precisam ser desenvolvidos, testados, validados e colocados em funcionamento. E, desta maneira, as palavras de Solovey, de que o software é uma criação pura da mente, acabam soando românticas demais. Produção é a palavra-chave. Software é um produto.

Qual caminho escolher?

Qual abordagem utilizar para desenvolver sistemas eficientes para o processamento de imagens? A possibilidade de lidar com diversos tipos de imagens e de estruturas de dados é ainda um dos principais problemas encontrados na programação de sistemas de processamento de imagens. Este fato aumenta significativamente a quantidade de código necessário para a implementação das operações, visto que um algoritmo implementado para imagens binárias, por exemplo, tem que ser  reescrito para imagens em níveis de cinza, mesmo que este algoritmo seja logicamente semelhante ao já codificado. Desta forma, a incorporação de um novo tipo de dado ou de estrutura de dados, tradicionalmente, ocasiona o retrabalho de novos algoritmos para que estes trabalhem de acordo com os novos dados.

Câmeras Canon

É claro que o avanço dos paradigmas de programação orientada por objetos e genérica produziu resultados bastante animadores sobre o reuso de software (por exemplo, a incorporação do polimorfismo paramétrico inclusive na linguagem Java) nos últimos anos. Porém, a utilização de arquiteturas escalares de alto desempenho baseadas em graphic processor units (GPUs) com aplicações em processamento de imagens têm levantado novamente a questão entre reuso versus desempenho.

O desenvolvimento baseado em componentes tem guiado a construção de sistemas de processamento imagens nos últimos anos. Assim, parece-me bastante oportuna a abordagem de linhas de produção de software (realçando a reusabilidade de código) para a efetiva produção em larga escala. Um pequeno exemplo é a quantidade de softwares distintos que a Canon necessita produzir para as mais variadas câmeras fotográficas e dispositivos de imageamento. Em baixa escala, é o conhecimento posto na prática que lidera  e portanto, a engenharia de software tradicional ainda é a melhor opção.

No próximo guest-post, Marcos d’Ornellas escreve sobre o impacto da abordagem da engenharia de software convencional e da abordagem que emprega o conceito de linhas de produção de software baseado nas ferramentas de software disponíveis (mais conhecidas) para o desenvolvimento de sistemas de processamento de imagens.

Crédito das imagens:

O banner “guest-post” é derivado de uma imagem de Alessandro Martins. As cameras canon são de pie.

Do que gostei:

Visualização 3D com tins de cinza no eixo Z, permite identificar características como a irregularidade na iluminação do fundo.

• A idéia da área de trabalho com texto, produzindo um log completo da seção de trabalho. Guarda resultados numéricos e os métodos e operações que você faz. É ótimo para facilitar a elaboração de relatórios e tutoriais. O log inclui o tempo utilizado para cada processo, em milisegundos.
• Cada operação que gera uma nova imagem, coloca no título da janela o nome da operação (e as vezes alguns parâmetros). Você não fica confuso, mesmo quando seu processo gera um amontoado de imagens na tela.
• Tem um amplo conjunto de operações, inclusive transformadas, que são difíceis de se encontrar já implementadas (é comum o pesquisador ter que implementar a sua própria versão só para usar em uma pesquisa).
• A visualização em 3D, com o nível de cinza no eixo Z pode ser muito útil em análises preliminares. O ImLab a colocou em local de fácil acesso.
• A documentação do código foi organizada para que novos desenvolvedores possam conhecer o software e desenvolver novas ferramentas.

Do que não gostei:

• Ainda não tem help. Assim fica bem difícil descobrir como fazer o que se precisa, ou entender como cada processo é realizado. Entendo que não exista tanto tempo disponível para compor manuais grandiosos, mas uma leve descrição de cada função agrega um valor enorme a qualquer software.
• O projeto tem pouca atividade em listas de discussão e fóruns, o que caracteriza um baixo número de usuários ativos, apesar de ter mais de 10 mil downloads. Isso não significa que o software não é bom, apenas pouco utilizado, e não há uma grande comunidade preocupada em mantê-lo atualizado e livre de bugs.
• Também faltam mensagens de erro que mostrem ao usuário quando ele está tentando fazer algo que não é possível, como fazer operações binárias com uma imagem RGB.

Recomendo!

Para quem é curioso, sabe C++ (mesmo que só um pouco) e quer experimentar novas técnicas e possibilidades.

O que falta…

A meu ver, para que um software possa ser usado para pesquisa ou aplicações comerciais por usuários-não-desenvolvedores ele precisa de documentação. Não falo de documentação de código (como entendem a maioria dos desenvolvedores), mas de documentação para o usuário! Help, manual! Que diga como utilizar, e quais as fórmulas matemáticas foram usadas para implementar os processos. Um bom manual (que fica ótimo em formato wiki) ensina os usuários a executar as tarefas que necessitam e permite aos pesquisadores que analisem seus resultados de forma segura.

So what?

Acho que o projeto tem imenso potencial, mas precisa urgente de:

• Mais desenvolvedores;
• Mais usuários;
• Usuários e desenvolvedores que se disponham a escrever um manual.

Fazer parde de um projeto OpenSource pode ser um passo importante para quem está na graduação, ou mesmo aprendendo de forma independente uma linguagem de programação. Você amplia sua experiência prática com situações reais, aprende a trabalhar em equipe, conhece pessoas do meio.

Se você ainda não é um exímio programador, comece por identificar bugs, escrever manuais e mensagens de erro. Depois pode passar a corrigir alguns bugs e, quando estiver pronto, pode ajudar a implantar novidades.

Ao responsável pelo projeto,

sugiro investir mais na divulgação:

• Faça um botão (como os que tenho no rodapé do ImageSurvey), e vamos espalhá-lo pela web.

• Apresente-se! Crie uma página pessoal. Uma das coisas que aprendi ao criar um blog é que ser anônimo na internet é como ser anônimo fora dela: as pessoas não confiam em quem não conhecem.

Aos leitores deste post

Se você faz parte ou conhece algum projeto de software livre para processemento e análise de imagens? Escreva um comentário e conte comigo para ajudar a divulgar seu projeto.

Imagens inseridas neste post são trabalhos derivados de imagens de Jeffrey Beall e ArchanaR, respectivamente.

Uso o Gimp há algum tempo para preparar as imagens para a web porque acho a interface deles para .jpg e .png ótima. Mas meu uso se restringia a este e uns outros poucos recursos.

Instalando…

Screenshot da caixa de ferramentas principal do Gimp.

Comecei este artigo fazendo algo que já deveria ter feito há tempos: baixando e instalando a última versão do Gimp. Para quem está acostumado com coisas da microsoft, a primeira impressão pode ser estranha. Ele abre duas pequenas janelas, uma com um menu e outra com uma caixa de ferramentas. Não há a famosa área de trabalho, que esconde todo o seu desktop. Depois que me acostumei a trabalhar assim, achei bem melhor.

Recursos

No item ‘File’ do menu principal, você encontra o ‘Open’, que vai permitir que abra uma imagem, como é padrão para a maioria dos programas. Aliás, há algumas ferramentas básicas que estão acessíveis por mais de um caminho – o que aumenta a chance de qualquer usuário encontrá-las sem ajuda.

O software conta com boas ferramentas de seleção, vários modos do operações de histograma (brilo, contraste, curvas, etc.), um bom conjunto de filtros, entre muitos outros recursos. Ele também trabalha com layers, stacks e transparências.

E ainda tem o melhor recurso de todos: qualquer programador (de C) pode fazer um plugin com a função que quiser. Há um site com orientação aos desenvolvedores.

Help

Quando tentei usar o Help, recebi uma mensagem de que ele não está instalado. Voltei à página inicial e encontrei um arquivo de instalação do help – para a versão 2.4 (a última é a 2.6). Por isso, quem quiser ajuda tem que usar a página dos manuais de usuários. A documentação mais recente existe em 10 línguas, incluindo inglês (claro) e espanhol, mas não portuquês.

Na nossa língua, existem dois sites principais, o gimp.com.br e o OGimp, que traze alguns tutoriais e outras informações, e também um fóruns, onde você pode perguntar e pedir ajuda.

Se o gimp ainda não tem aquele recurso de que você precisa, peça aos desenvolvedores. Pedir pode parecer estranho para alguns de nós, acostumados à relação impessoal com fabricantes tradicionais, mas em software livre é diferente: a equipe de desenvolvimento precisa saber o que os usuários querem ver implementado, para melhorar o software.

Junte-se ao grupo!

Para quem, como eu, acredita que software livre é um bom caminho e quer contribuir, há uma lista de formas de ajudar o Gimp, onde fica claro que qualquer pessoa pode fazer algo.  Aliás, se você for um bloger como eu e quiser contribuir com o projeto sem mudar muito a sua rotina, é só passar a usá-lo, e contar para todo mundo, como fiz lá no rodapé.