O site Linux Photography fez uma entrevista com Martin Nordholts, desenvolvedor do GIMP, tratando de vários assuntos - previsões de novas funções, integração com o GEGL, novas funcionalidade que serão acrescentadas na versão 2.8 e muito mais.
Linux Photography: Martin, obrigado por dispor um tempo para essa entrevista. Para começar, você pode nos dizer algumas palavras sobre você e sobre o seu envolvimento com o GIMP?
Martin Nordholts: Depois da minha primeira contribuição, em outubro de 2006, gradualmente me envolvi cada vez mais e hoje estou dando contribuições mais ou menos diárias, incluindo conserto de bugs, mantendo relatórios de erros, revisando e unindo códigos e trabalhando em novas funcionalidades. Ocasionalmente, eu também contribuo com o framework GEGL, mas o GIMP ocupa a maior parte do meu tempo. Em meu trabalho cotidiano, eu trabalho como desenvolvedor de software para uma famosa fabricante de telefones móveis.
LP: Falando do ponto de vista de um fotógrafo, há uma longa espera por funcionalidades como gerenciamento de cores, edição de cores em maior profundidade ou "efeito em camadas" a serem incluídas no GIMP. Agora que o GEGL está pronto para o prime time, como que o uso do GEGL no GIMP permitirá essas funcionalidades?
MN: Quando o GEGL estiver completamente integrado, o GIMP oferecerá edição de cores em alta profundidade e não destrutiva incluindo o tão falado efeito em camadas. O gerenciamento de cores é uma questão separada e um gerenciamento de cores de alta qualidade irá requerer trabalho no framework GEGL e no núcleo do GIMP.
LP: Com a versão 2.6 do GIMP recém lançada, o GEGL é usado no GIMP para muitas operações. Qual é a quantidade de trabalho ainda necessária para que o GEGL esteja pronto para ser usado plenamente no GIMP?
MN: Para o GIMP 2.6, muitas operações de cores foram portadas para o GEGL. Para o GIMP 2.8, já acabamos a projeção de código para o GEGL também. A projeção de código é o que combina as camadas em um único objeto - por exemplo uma imagem. Com a estrutura da imagem representada como um gráfico GEGL, é fácil inserir nodes não destrutivos e sei que o Øyvind - desenvolvedor do GIMP - está fazendo alguns protótipos que, até onde sei, são quase indolores.
Poderíamos dizer que o GIMP tem um núcleo isolado capaz de fazer edição de cores em grande profundidade e não destrutiva. O que precisa ser feito é adaptar o código para que os usuários possam usar plenamente esse núcleo atualmente isolado. É impossível e inútil especular sobre uma data específica em que isso estará finalizado. Apenas podemos afirmar que o trabalho está sendo feito e eventualmente estará acabado.
LP: Como foi a integração do GEGL no GIMP 2.6? Você sente que o trabalho de base feito nas versões anteriores do GIMP está dando bons frutos; e processo foi relativamente simples ou você o descreveria como "doloroso"?
MN: O trabalho que tem sido feito até agora (incluindo no 2.8) tem sido bastante simples. Como muitas vezes é o caso, só é necessário algum tempo dedicado para pensar e programar.
LP: Agora as perguntas queria perguntar há muito tempo (e provavelmente não sou o único...). Em quanto tempo veremos as diferentes funções mencionadas anteriormente serem incluídas no GIMP? Talvez possamos falar sobre o gerenciamento de cores primeiro: ele está lá agora nas preferências do GIMP e no menu "Imagem". Sinto que tenho tudo que necessito para um avanço em cores gerenciadas, mas você planeja adicionar mais algumas funções? O código atual precisa de mudanças drásticas para ser compatível com o GEGL?
MN: Eu mesmo estou interessado em melhorar o gerenciamento de cores, mas não darei atenção especial a ele antes que o GEGL estiver quase completamente integrado. Especular sobre datas específicas é, repito, impossível e inútil. Algum programador pode se interessar e começar a trabalhar nesse exato momento, ou pode levar muitos anos até que alguém ache tempo e motivação suficientes para melhorar a situação.
LP: A próxima questão é sobre uma maior profundidade de cores - um assunto querido por um coração de fotógrafo. Se 8bits por canal presume ser o código inteiro, posso imaginar que mudar essa suposição significa refazer tudo. Está correto? Quais são os principais desafios para se ter uma versão do GIMP com mais bits por canal?
MN: Já que o GEGL é um framework novo, realmente não há por que reescrever o código herdado de 8bits por canal, mas sim substituir esse código inteiramente. Fará sentido escrever wrappers* para os componentes herdados para também serem usados com o novo framework , mas isso não é exatamente reescrever o código. Na verdade, não vejo grandes desafios a não ser a maior profundidade de cores, o código simplesmente precisa se escrito.
Planos a longo prazo não funcionam bem num projeto dirigido por voluntários, mas existem alguns planos soltos. Se nada der errado, o GIMP 2.8 terá a projeção de código portada para o GEGL. Quando isso estiver terminado, o passo natural é começar a realmente usar o novo framework e suas novas funções. Talvez o GIMP 2.10 fará uso disso de alguma maneira.
LP: E agora sobre o "efeito em camadas" ou ainda melhor: edição não destrutiva (uma função doida e legal, se me perguntar)?
MN: A não destrutividade será fácil porque os paths do código herdado de 8 bits por canal ainda podem ser usados para transferir informações. A maior profundidade de cores será difícil devido à necessidade de novos/mais paths. O gerenciamento de cores é a parte mais difícil porque isso afeta toda a estrutura da edição de imagem.
LP: Isso também clama por uma pergunta sobre o design da interface de usuário - editar imagem é uma tarefa complexa e uma interface de usuário simples para uma tarefa complexa não é fácil?
MN: O time responsável pela interface de usuário (principalmente Peter Sikking) está dando uma contribuição valiosa. Sei que existem planos para uma interface de usuário para as função não destrutivas mas não me lembro de nenhum detalhe no momento.
LP: Existe mais algumas funções que você gostaria de mencionar?
MN: Existem discussões sobre uma interface baseada numa janela única por aba que pode, provavelmente, interessar algumas pessoas. As recentes mudanças também fizeram progresso em direção a uma melhor manipulação de seleções flutuantes e suporte para grupo de camadas que até podem estar no GIMP 2.8. O GIMP 2.8 também contará com três projetos do Google Summer of Code que estão em processo de fusão, chamados simple vector layer support, on-canvas text editing e tagging of GIMP resources.
LP: Quais são as áreas em que o GIMP se beneficia de ajuda?
MN: Na verdade, não acredito em chamar por ajuda. Se as pessoas estão interessadas em ajudar, elas ajudarão. Caso contrário, não irão. Pessoas em todas as áreas são bem-vindas. Desenvolvedores, mantenedores de relatórios de erros, mantenedores do website, autores de documentação, etc, etc.
LP: Sei que você pode ou não estar interessado em fotografia, mas qual é a sua opinião sobre o nível dos programas open source para fotografia em geral?
MN: Devo admitir que não sou muito interessado em ser fotógrafo. A fotografia me interessa mas nunca tive tempo para realmente fazer algo sério. Eu não sou, em outras palavras, a pessoa certa para julgar a qualidade dos programas open source para fotografia do ponto de vista de um profissional. Mas todos nós podemos ver que os programas estão em constante evolução e novos programas estão surgindo, a situação está melhorando continuamente.
LP: Fazendo o papel de advogado do diabo: com grandes desenvolvedoras se tornando cada vez mais poderosas e capazes de lidar com diferentes tipos de arquivos de imagem, ainda há espaço para um "bom e velho editor" como o GIMP?
MN: O que posso dizer? Se algum outro editor superar o GIMP em termos de ferramentas, que assim seja. Entretanto, suspeito que, uma vez que nós tenhamos acabado o trabalho que atualmente estamos fazendo, o GIMP será muito atrativo para as pessoas que atualmente se dedicam a processamento de profundidade com grande quantidade de bits por exemplo. Acho a competição (se alguém quiser usar esse termo) nada além de interessante.
----------------------
Correções?? Manda nos comentários!!!!
Linux Photography: Martin, obrigado por dispor um tempo para essa entrevista. Para começar, você pode nos dizer algumas palavras sobre você e sobre o seu envolvimento com o GIMP?
Martin Nordholts: Depois da minha primeira contribuição, em outubro de 2006, gradualmente me envolvi cada vez mais e hoje estou dando contribuições mais ou menos diárias, incluindo conserto de bugs, mantendo relatórios de erros, revisando e unindo códigos e trabalhando em novas funcionalidades. Ocasionalmente, eu também contribuo com o framework GEGL, mas o GIMP ocupa a maior parte do meu tempo. Em meu trabalho cotidiano, eu trabalho como desenvolvedor de software para uma famosa fabricante de telefones móveis.
LP: Falando do ponto de vista de um fotógrafo, há uma longa espera por funcionalidades como gerenciamento de cores, edição de cores em maior profundidade ou "efeito em camadas" a serem incluídas no GIMP. Agora que o GEGL está pronto para o prime time, como que o uso do GEGL no GIMP permitirá essas funcionalidades?
MN: Quando o GEGL estiver completamente integrado, o GIMP oferecerá edição de cores em alta profundidade e não destrutiva incluindo o tão falado efeito em camadas. O gerenciamento de cores é uma questão separada e um gerenciamento de cores de alta qualidade irá requerer trabalho no framework GEGL e no núcleo do GIMP.
LP: Com a versão 2.6 do GIMP recém lançada, o GEGL é usado no GIMP para muitas operações. Qual é a quantidade de trabalho ainda necessária para que o GEGL esteja pronto para ser usado plenamente no GIMP?
MN: Para o GIMP 2.6, muitas operações de cores foram portadas para o GEGL. Para o GIMP 2.8, já acabamos a projeção de código para o GEGL também. A projeção de código é o que combina as camadas em um único objeto - por exemplo uma imagem. Com a estrutura da imagem representada como um gráfico GEGL, é fácil inserir nodes não destrutivos e sei que o Øyvind - desenvolvedor do GIMP - está fazendo alguns protótipos que, até onde sei, são quase indolores.
Poderíamos dizer que o GIMP tem um núcleo isolado capaz de fazer edição de cores em grande profundidade e não destrutiva. O que precisa ser feito é adaptar o código para que os usuários possam usar plenamente esse núcleo atualmente isolado. É impossível e inútil especular sobre uma data específica em que isso estará finalizado. Apenas podemos afirmar que o trabalho está sendo feito e eventualmente estará acabado.
LP: Como foi a integração do GEGL no GIMP 2.6? Você sente que o trabalho de base feito nas versões anteriores do GIMP está dando bons frutos; e processo foi relativamente simples ou você o descreveria como "doloroso"?
MN: O trabalho que tem sido feito até agora (incluindo no 2.8) tem sido bastante simples. Como muitas vezes é o caso, só é necessário algum tempo dedicado para pensar e programar.
LP: Agora as perguntas queria perguntar há muito tempo (e provavelmente não sou o único...). Em quanto tempo veremos as diferentes funções mencionadas anteriormente serem incluídas no GIMP? Talvez possamos falar sobre o gerenciamento de cores primeiro: ele está lá agora nas preferências do GIMP e no menu "Imagem". Sinto que tenho tudo que necessito para um avanço em cores gerenciadas, mas você planeja adicionar mais algumas funções? O código atual precisa de mudanças drásticas para ser compatível com o GEGL?
MN: Eu mesmo estou interessado em melhorar o gerenciamento de cores, mas não darei atenção especial a ele antes que o GEGL estiver quase completamente integrado. Especular sobre datas específicas é, repito, impossível e inútil. Algum programador pode se interessar e começar a trabalhar nesse exato momento, ou pode levar muitos anos até que alguém ache tempo e motivação suficientes para melhorar a situação.
LP: A próxima questão é sobre uma maior profundidade de cores - um assunto querido por um coração de fotógrafo. Se 8bits por canal presume ser o código inteiro, posso imaginar que mudar essa suposição significa refazer tudo. Está correto? Quais são os principais desafios para se ter uma versão do GIMP com mais bits por canal?
MN: Já que o GEGL é um framework novo, realmente não há por que reescrever o código herdado de 8bits por canal, mas sim substituir esse código inteiramente. Fará sentido escrever wrappers* para os componentes herdados para também serem usados com o novo framework , mas isso não é exatamente reescrever o código. Na verdade, não vejo grandes desafios a não ser a maior profundidade de cores, o código simplesmente precisa se escrito.
Planos a longo prazo não funcionam bem num projeto dirigido por voluntários, mas existem alguns planos soltos. Se nada der errado, o GIMP 2.8 terá a projeção de código portada para o GEGL. Quando isso estiver terminado, o passo natural é começar a realmente usar o novo framework e suas novas funções. Talvez o GIMP 2.10 fará uso disso de alguma maneira.
LP: E agora sobre o "efeito em camadas" ou ainda melhor: edição não destrutiva (uma função doida e legal, se me perguntar)?
MN: A não destrutividade será fácil porque os paths do código herdado de 8 bits por canal ainda podem ser usados para transferir informações. A maior profundidade de cores será difícil devido à necessidade de novos/mais paths. O gerenciamento de cores é a parte mais difícil porque isso afeta toda a estrutura da edição de imagem.
LP: Isso também clama por uma pergunta sobre o design da interface de usuário - editar imagem é uma tarefa complexa e uma interface de usuário simples para uma tarefa complexa não é fácil?
MN: O time responsável pela interface de usuário (principalmente Peter Sikking) está dando uma contribuição valiosa. Sei que existem planos para uma interface de usuário para as função não destrutivas mas não me lembro de nenhum detalhe no momento.
LP: Existe mais algumas funções que você gostaria de mencionar?
MN: Existem discussões sobre uma interface baseada numa janela única por aba que pode, provavelmente, interessar algumas pessoas. As recentes mudanças também fizeram progresso em direção a uma melhor manipulação de seleções flutuantes e suporte para grupo de camadas que até podem estar no GIMP 2.8. O GIMP 2.8 também contará com três projetos do Google Summer of Code que estão em processo de fusão, chamados simple vector layer support, on-canvas text editing e tagging of GIMP resources.
LP: Quais são as áreas em que o GIMP se beneficia de ajuda?
MN: Na verdade, não acredito em chamar por ajuda. Se as pessoas estão interessadas em ajudar, elas ajudarão. Caso contrário, não irão. Pessoas em todas as áreas são bem-vindas. Desenvolvedores, mantenedores de relatórios de erros, mantenedores do website, autores de documentação, etc, etc.
LP: Sei que você pode ou não estar interessado em fotografia, mas qual é a sua opinião sobre o nível dos programas open source para fotografia em geral?
MN: Devo admitir que não sou muito interessado em ser fotógrafo. A fotografia me interessa mas nunca tive tempo para realmente fazer algo sério. Eu não sou, em outras palavras, a pessoa certa para julgar a qualidade dos programas open source para fotografia do ponto de vista de um profissional. Mas todos nós podemos ver que os programas estão em constante evolução e novos programas estão surgindo, a situação está melhorando continuamente.
LP: Fazendo o papel de advogado do diabo: com grandes desenvolvedoras se tornando cada vez mais poderosas e capazes de lidar com diferentes tipos de arquivos de imagem, ainda há espaço para um "bom e velho editor" como o GIMP?
MN: O que posso dizer? Se algum outro editor superar o GIMP em termos de ferramentas, que assim seja. Entretanto, suspeito que, uma vez que nós tenhamos acabado o trabalho que atualmente estamos fazendo, o GIMP será muito atrativo para as pessoas que atualmente se dedicam a processamento de profundidade com grande quantidade de bits por exemplo. Acho a competição (se alguém quiser usar esse termo) nada além de interessante.
----------------------
Correções?? Manda nos comentários!!!!
