Se você vem do Darktable, talvez esteja acostumado com isto na sala escura:
enquanto o Ansel oferece isto a você:
Isso não é por acaso, e chegou a hora de explicar por quê, e por que isso não será estendido com opções de personalização.
As imagens nascem de pipelines
Um pipeline de pixels é uma sequência de filtros na qual os pixels são processados para acabar em um meio. O Photoshop chama esses filtros de camadas , seguindo uma metáfora herdada do papel e da pintura em matte. O Da Vinci Resolve, o Blender, o Natron, etc. os chamam de nós , seguindo uma metáfora baseada em grafos direcionados e fluxogramas , mais familiar a engenheiros. Ambos têm uma forma de mostrar como esses filtros estão organizados, seja com uma pilha de camadas, seja com o grafo de nós (também conhecido como fluxograma).
A parte importante é: a ordem importa.
Uma breve história de design ruim
O Darktable chama esses filtros de módulos. Mas “módulos” se refere à lógica de programação modular : cada módulo é codificado separadamente, usando uma API uniforme, e não sabe da existência dos outros módulos. O próprio pipeline não sabe nada sobre o funcionamento interno dos módulos, ele apenas conecta as entradas e as saídas. É uma forma limpa de desenvolver, mas é completamente irrelevante para o usuário final.
O problema é que o Darktable tem 2 tipos de módulos:
- os módulos da mesa de luz (e os módulos no painel esquerdo da sala escura), que são caixas de ferramentas arbitrárias e, portanto, elementos/quadros puramente de GUI,
- os módulos da sala escura, que são ao mesmo tempo um filtro de pixels localizado em algum ponto do pipeline, e também uma caixa de ferramentas de GUI. (igual aos módulos anteriores).
E esses módulos diferentes, além de terem o mesmo nome, têm exatamente a mesma aparência…
São 3 erros aqui:
- nomear um objeto de GUI pelo nome de sua implementação técnica em vez de pela sua finalidade funcional,
- nomear e representar 2 objetos conceitualmente diferentes da mesma forma,
- não conseguir representar a ordem dos módulos de maneira clara e hierárquica.
Como resultado, muitos usuários ainda consideram todos os módulos como caixas de ferramentas arbitrárias, e há anos pediram formas de reordená-los arbitrariamente na janela, o que uma liderança técnica sem espinha (ou a falta dela) lhes concedeu, na forma de um grupo de módulos terrivelmente codificado (3500 linhas de código, sutilmente quebrado) e complicado demais, que consome 3 % da sua CPU mesmo quando você não interage com o aplicativo, enquanto a sua sala escura fica ociosa.
A cereja do bolo é que os grupos são rotulados por ícones, em nome da compactação, mas esses ícones são absolutamente enigmáticos e só os usuários de longa data fingem saber o que representam (eu desenhei aquele que representa raios de luz passando por uma lente fina, que as pessoas confundem com um OVNI – aprendi com esse erro).
Bons fluxos de trabalho levam o pipeline em conta
Faz 3 anos que sou pago por usuários para explicar a eles os pormenores do software, e respondo à mesma pergunta repetidas vezes: por onde começar um fluxo de trabalho e como desenrolá-lo. O que ainda me impressiona é que pessoas com mestrado, que leram a documentação e assistiram à maioria dos meus vídeos, ainda são incapazes de iniciar um fluxo de trabalho de edição de imagem por conta própria. Ou isso é um design gritantemente ruim, ou a maioria das pessoas com ensino superior é idiota. Na verdade, mesmo que as pessoas fossem idiotas, é mais fácil tornar o design à prova de idiotas1 do que esperar que elas criem juízo da noite para o dia, então de qualquer forma o design é ruim em relação ao público-alvo.
Se você abrir o Photoshop, as camadas se empilham umas sobre as outras de forma bem intuitiva. Todos nós trabalhamos com camadas em projetos de arte na escola primária. Não passaria pela sua cabeça começar a trabalhar na camada mais de baixo depois de colocar coisas novas por cima. Pois bem, os cerca de 70 módulos do Darktable, organizados em abas por tema, de uma forma que não leva em conta nem o pipeline nem o fluxo de trabalho, com certeza vão afugentar os recém-chegados e promover maus hábitos entre os veteranos.
Fluxos de trabalho sensatos levam o pipeline em conta, o que significa que a ordem na qual você ajusta os filtros deve ser definida pela posição desses filtros no pipeline. Mas eu digo levar o pipeline em conta, e não ser definido pelo pipeline, porque o início e o fim do pipeline (propriedades da cena e da tela) devem ser definidos primeiro, para se ter uma boa visão do que fazemos no meio. Especialmente se você vai manipular sinais HDR em uma tela SDR, é preciso colocar os seus óculos de sol HDR primeiro para visualizar o seu sinal em SDR. Mas o que você vê não é o que há no seu pipeline. É por isso que o fluxo de trabalho não segue 1:1 o pipeline, mas ainda assim fica bem próximo dele.
Imagine que você defina uma dominante de cor no módulo balanço de cor, mirando as realces através do ajuste de ganho. Depois você acha a imagem escura demais e a clareia com o módulo exposição. Mas a exposição vem (muito) antes do balanço de cor no seu pipe, então agora você precisa atualizar o ajuste de dominante de cor porque ele provavelmente estará pesado demais nos meios-tons. Agora, faça a convolução disso com outro módulo intermediário (ou mais) que usaria uma máscara paramétrica sobre qualquer métrica de claridade ou luminância… Você está a caminho da edição circular, um tipo de experiência de edição particularmente ineficiente e frustrante em que cada novo ajuste invalida o anterior. Claro que há aqueles que pensam que, sendo a fotografia uma arte, é tudo uma questão de opinião e preferências, então no fim das contas nada disso importa. Arte ou não, um castelo de cartas vai desabar por inteiro toda vez que você começar a mexer nos andares de baixo, então no fim das contas é uma questão de quanto tempo você aceita desperdiçar, e isso não tem nada a ver com opiniões ou preferências. Eu também argumentaria que os hobbistas de fim de semana têm tanta restrição de tempo quanto os fotógrafos profissionais: estes por razões econômicas, aqueles porque os fins de semana só têm 2 dias e eles vão precisar estar de volta ao escritório na manhã de segunda-feira com diversão suficiente no sistema para aguentar mais uma semana.
Então, como você sabe quando se desviar da ordem do pipeline? Bem, você agenda uma sessão comigo para a demonstração. Mas existe outra solução (mais sobre isso abaixo)…
De qualquer forma, oferecer aos usuários mais opções para personalizar a interface (e talvez reforçar o equívoco inicial de que os módulos são apenas caixas de GUI) não vai resolver isso. Na verdade, é dar às pessoas mais opções para se prejudicarem. O que você quer e o que é bom para você…
Reexaminando o problema
Enquanto o Darktable degenerou em um playground para geeks onde novo significa melhor e todo problema pede mais código engraçadinho, o Ansel se trata de resolver problemas simples da forma simples, para produzir um cavalo de batalha confiável. Então vamos começar de novo do topo.
Temos 70 módulos. Embora o Ansel tenha descontinuado uma boa parte deles, ainda são “demais”, no sentido de que todos são úteis para algum propósito, mas você não precisa deles o tempo todo, e não de todos ao mesmo tempo. Além disso, o espaço em tela é limitado e definitivamente não podemos ter todos eles exibidos ao mesmo tempo. E mesmo se pudéssemos, apresentar um painel de Airbus ao fotógrafo comum não seria agradável.
Então precisamos escolher quais módulos exibir em qual momento. Ênfase no momento.
Desenrolando o eixo do tempo
Seguindo a ideia do just in time, parece só natural que o eixo do tempo fosse dividido em etapas do fluxo de trabalho. Assim, a seleção de todos os módulos visíveis em um dado momento corresponde àqueles de que você vai precisar agora e nos próximos minutos. Ao passar para a próxima etapa do fluxo de trabalho, você avança na GUI e muda a visualização. Isso se chama apresentação de slides.
Isso traça um caminho linear a seguir, para obter alguma estrutura e orientação em meio à aparente confusão. As GUIs não servem apenas para expor controles, elas também servem para ensinar, comunicar e divulgar as possibilidades disponíveis.
Assim, cada aba agora é um slide da nossa apresentação de slides do fluxo de trabalho, que está intimamente ligada à ordem do pipeline. E a estrutura surgiu da confusão.
Com algumas exceções. Por exemplo, os módulos de redução de ruído têm que acontecer cedo no pipeline por consistência do sinal, mas aparecem mais tarde no fluxo de trabalho do que, digamos, a calibração de cor, porque atuam no nível dos pixels e geralmente não mudam a dominante de cor global (a menos que você tenha algum dano sério de ruído que possa deslocar o eixo verde/magenta, mas isso normalmente acontece acima de 8000 ISO). O mesmo vale para os algoritmos de nitidez: nenhum deles vai mudar drasticamente a claridade, a matiz ou a croma a ponto de invalidar ajustes globais anteriores (em termos de fluxo de trabalho) de cor e exposição, e os ajustes adequados também estarão sujeitos a quanto você aumentou a exposição da imagem (agravando, com isso, a força visual do ruído). Essas exceções à regra ficam claras pela análise numérica dos filtros de pixels, o que significa que as pessoas que não leram o código-fonte com conhecimento prévio de processamento de sinais não farão a menor ideia.
Implementação
Princípio
- Etapas do fluxo de trabalho == abas de módulos.
- Essas abas têm nomes textuais, que podem ocupar mais espaço na GUI, mas você não precisa ler a documentação nem adivinhar o que significam: está escrito no rótulo.
- A primeira e a última aba são especiais
- Elas mostram, respectivamente, a lista de módulos ativados (pipeline) e a lista completa de módulos disponíveis (todos).
- Nem todas as abas ficam imediatamente visíveis
- Dependendo da largura do painel lateral, algumas abas ficarão ocultas, o que não tem problema porque você vai segui-las da esquerda para a direita em sequência, então não precisa realmente saber o que vem depois
- Dentro das abas, os módulos são organizados como camadas, na ordem do pipeline
- Ou seja, de baixo para cima. É assim que você deve ajustá-los. Então a pilha de módulos representa a pilha de efeitos/filtros/camadas sobre a imagem raw.
TL;DR: siga a ordem da GUI da esquerda para a direita, e de baixo para cima (porque são camadas), e você terá o seu fluxo de trabalho sem leitura tediosa da documentação.
Os módulos da sala escura podem ser reordenados em qualquer aba segurando Ctrl+Shift2 enquanto se faz um arrastar-e-soltar com o mouse, sobre os cabeçalhos dos módulos. Esteja ciente de que isso reordena os módulos no pipeline também, não deve ser usado como uma conveniência de GUI. É melhor fazer isso nas abas “pipeline” ou “todos”, onde você tem uma visão completa do conteúdo do pipeline.
Substituindo os módulos favoritos
O design atual não tem como definir módulos favoritos em uma aba especial. Não vejo sentido em adicionar mais inchaço para resolver o problema de ter inchaço logo de início.
Para esses módulos especiais, você pode atribuir atalhos aos eventos de “mostrar” (também conhecido como abrir, mostrar, exibir, desdobrar) ou “ativar” (também conhecido como habilitar). Vá ao menu Editar, depois embaixo clique em Atalhos de teclado, e então, com o cursor especial que você obteve, clique no cabeçalho do seu futuro módulo favorito (sobre o nome dele). Exemplo aqui com o módulo de exposição:
Por padrão, será sugerido a você o evento “mostrar”, na coluna do elemento (outro rótulo que eu deveria mudar). Você pode trocá-lo pelo evento “ativar” ou “instância” (também conhecido como instanciar). O efeito não importa para este, eu não testei em qual caso ele é usado e a coisa toda é uma bagunça emaranhada de qualquer jeito.
De qualquer forma, esses atalhos vão levar você instantaneamente aos seus módulos favoritos sem poluir mais o espaço da GUI.
Conclusão
Isso não resolve o problema de os módulos serem chamados por algo que não interessa aos usuários, e de os módulos de processamento de imagem terem a mesma aparência dos que não são de processamento de imagem. Tenho algumas ideias sobre isso, mas isso fica para outra hora.
Notas laterais
Muitas outras ferramentas antes ocultas em botões de ícones enigmáticos foram integradas ao menu global. Esse menu pode ser desdobrado pressionando Alt seguido da letra mnemônica do menu (que ficará sublinhada ao pressionar Alt). Uma vez desdobrado, o menu pode ser navegado com as teclas de seta.
O retorno à mesa de luz agora está mapeado para a tecla Escape/Return. Na mesa de luz, a busca textual de imagens também está mapeada para Ctrl+F (como você esperaria). A navegação pelas imagens pode ser feita com as teclas de Seta, a seleção com a tecla Space, e a abertura de uma imagem na sala escura pode ser feita pressionando a tecla Enter.
Isso significa que o aplicativo agora é quase inteiramente navegável com o teclado sem ter que lembrar de atalhos. Esses atalhos são exibidos de qualquer forma no menu, à direita das entradas.
A tabela de todos os atalhos agora pode ser encontrada no menu Ajuda; antes ela só era acessível… através de um atalho.
Translated from English by : Claude. In case of conflict, inconsistency or error, the English version shall prevail.
And I mean “idiot-proof” in a “prevent pouring water into the acid” way, not in a “cancel chemistry labs because acid can burn” way. It’s not idiot-proof if the idiot is not allowed to do anything. ↩︎
It’s shitty but that’s because Gtk’s way of handling drag and drop events sucks. ↩︎
