Se vieni da Darktable, potresti essere abituato a questo nella camera oscura:
mentre Ansel ti offre questo:
Non è un caso, ed è ora di spiegare perché, e perché questo non verrà esteso con opzioni di personalizzazione.
Le immagini nascono dalle pipeline
Una pixel pipeline è una sequenza di filtri in cui i pixel vengono elaborati per finire su un supporto. Photoshop chiama quei filtri livelli , attenendosi a una metafora ereditata dalla carta e dal matte painting. Da Vinci Resolve, Blender, Natron, ecc. li chiamano nodi , attenendosi a una metafora fondata sui grafi orientati e sui diagrammi di flusso , ben noti agli ingegneri. Entrambi hanno un modo di mostrare come quei filtri sono organizzati, o con una pila di livelli o con il grafo dei nodi (detto anche diagramma di flusso).
La parte importante è che l’ordine conta.
Una breve storia del cattivo design
Darktable chiama quei filtri moduli. Ma «moduli» fa riferimento alla logica della programmazione modulare : ogni modulo è programmato separatamente, usando un’API uniforme, e non sa nulla degli altri moduli. La pipeline stessa non sa nulla degli interni dei moduli, si limita a collegare gli ingressi e le uscite. È un modo pulito di sviluppare, ma è del tutto irrilevante per l’utente finale.
Il problema è che Darktable ha 2 tipi di moduli:
- i moduli del tavolo luminoso (e i moduli nel pannello sinistro della camera oscura), che sono cassette degli attrezzi arbitrarie e quindi elementi/riquadri puramente della GUI,
- i moduli della camera oscura, che sono sia un filtro di pixel situato da qualche parte nella pipeline, sia anche una cassetta degli attrezzi della GUI. (uguale ai moduli precedenti).
E quei moduli diversi, oltre a chiamarsi allo stesso modo, hanno esattamente lo stesso aspetto…
Qui ci sono 3 errori:
- nominare un oggetto della GUI con il nome della sua implementazione tecnica invece che con il suo scopo funzionale,
- nominare e rappresentare 2 oggetti concettualmente diversi allo stesso modo,
- non riuscire a rappresentare l’ordine dei moduli in modo chiaro e gerarchico.
Di conseguenza, molti utenti considerano ancora tutti i moduli come cassette degli attrezzi arbitrarie, e hanno chiesto per anni dei modi per riordinarli arbitrariamente nella finestra, cosa che una leadership tecnica smidollata (o piuttosto la sua mancanza) ha concesso loro, sotto forma di un gruppo di moduli programmato in modo terribile (3500 righe di codice, sottilmente difettoso) e troppo complicato, che divora il 3 % della tua CPU anche quando non interagisci con l’applicazione, per tutto il tempo in cui la tua camera oscura resta inattiva.
La ciliegina sulla torta è che i gruppi sono etichettati da icone, per amore della compattezza, ma quelle icone sono assolutamente criptiche e solo gli utenti di lunga data fingono di sapere cosa rappresentano (ne ho disegnata una che rappresenta raggi di luce che attraversano una lente sottile, che la gente scambia per un UFO – ho imparato da quell’errore).
I buoni flussi di lavoro tengono conto della pipeline
Sono 3 anni che vengo pagato dagli utenti per spiegare loro i dettagli del software, e per rispondere sempre alla stessa domanda: da dove iniziare un flusso di lavoro e come svilupparlo. Ciò che ancora mi colpisce è che persone con una laurea magistrale, che hanno letto la documentazione e visto la maggior parte dei miei video, non sono ancora in grado di iniziare da sole un flusso di lavoro di editing delle immagini. O questo grida a un cattivo design oppure la maggior parte delle persone con un’istruzione superiore sono degli idioti. In realtà, anche se le persone fossero idiote, è più facile rendere il design a prova di idiota1 che aspettarsi che mettano su cervello da un giorno all’altro, quindi in entrambi i casi il design è cattivo rispetto al pubblico di riferimento.
Se apri Photoshop, i livelli si impilano l’uno sull’altro in modo piuttosto intuitivo. Tutti abbiamo lavorato con i livelli nei progetti artistici alle elementari. Non ti verrebbe in mente di iniziare a lavorare sul livello più in basso dopo aver messo qualcosa di nuovo sopra. Ebbene, i circa 70 moduli di Darktable, organizzati in schede per tema, in un modo che non tiene conto né della pipeline né del flusso di lavoro, sono garantiti a scoraggiare i nuovi arrivati e a promuovere cattive abitudini tra i veterani.
I flussi di lavoro sensati tengono conto della pipeline, il che significa che l’ordine in cui regoli i filtri dovrebbe essere definito da dove quei filtri si collocano nella pipeline. Ma dico che tengono conto della pipeline, e non che sono definiti dalla pipeline, perché l’inizio e la fine della pipeline (proprietà della scena e del display) dovrebbero essere impostati per primi, così da avere una buona visione d’insieme di ciò che facciamo nel mezzo. Specialmente se hai intenzione di manipolare segnali HDR su un display SDR, devi prima metterti i tuoi occhiali da sole HDR per vedere il tuo segnale in SDR. Ma ciò che vedi non è ciò che c’è nella tua pipeline. Ecco perché il flusso di lavoro non segue 1:1 la pipeline, ma le resta comunque piuttosto vicino.
Immagina di impostare una dominante di colore nel modulo bilanciamento del colore, prendendo di mira le alte luci tramite l’impostazione guadagno. Poi trovi la foto troppo scura e la schiarisci con il modulo esposizione. Ma esposizione viene (molto) prima di bilanciamento del colore nella tua pipe, quindi ora devi aggiornare l’impostazione della dominante di colore perché sarà probabilmente troppo pesante sui mezzitoni. Ora, convolvi questo con un altro modulo intermedio (o più) che userebbe una maschera parametrica su una qualsiasi metrica di chiarezza o luminanza… Sei avviato verso l’editing circolare, un tipo di esperienza di editing particolarmente inefficiente e frustrante in cui ogni nuova impostazione invalida la precedente. Certo, c’è chi pensa che, essendo la fotografia un’arte, sia tutta una questione di opinioni e preferenze, quindi in fondo niente di tutto ciò conta. Arte o no, un castello di carte crollerà interamente ogni volta che inizi a pasticciare con i piani inferiori, quindi in fondo si tratta di quanto tempo accetti di sprecare, e questo non ha nulla a che vedere con opinioni o preferenze. Sosterrei anche che gli hobbisti del fine settimana hanno vincoli di tempo tanto quanto i fotografi professionisti: questi ultimi per ragioni economiche, i primi perché i fine settimana hanno solo 2 giorni e dovranno tornare in ufficio il lunedì mattina con abbastanza divertimento in corpo da sopportare un’altra settimana.
Allora come fai a sapere quando allontanarti dall’ordine della pipeline? Beh, prenoti una sessione con me per la dimostrazione. Ma c’è un’altra soluzione (maggiori dettagli sotto)…
In ogni caso, offrire agli utenti più opzioni per personalizzare l’interfaccia (e forse rinforzare l’iniziale idea sbagliata che i moduli siano solo riquadri della GUI) non lo risolverà. In realtà è dare alle persone più opzioni per farsi del male. Ciò che vuoi e ciò che è bene per te…
Riesaminare il problema
Mentre Darktable è degenerato in un parco giochi per smanettoni dove nuovo significa migliore e ogni problema richiede altro codice buffo, Ansel punta a risolvere i problemi semplici in modo semplice, così da produrre un cavallo da lavoro affidabile. Quindi ricominciamo dall’inizio.
Abbiamo 70 moduli. Sebbene Ansel ne abbia deprecati un buon numero, ce ne sono ancora «troppi», nel senso che sono tutti utili per qualche scopo ma non ti servono tutti in ogni momento, e non tutti nello stesso momento. Inoltre lo spazio sullo schermo è limitato e di sicuro non possiamo averli tutti visualizzati contemporaneamente. E anche se potessimo, presentare un cruscotto da Airbus al fotografo medio non sarebbe piacevole.
Quindi dobbiamo scegliere quali moduli mostrare in quale momento. Enfasi su momento.
Srotolare l’asse del tempo
Seguendo l’idea del just in time, sembra del tutto naturale che l’asse del tempo venga suddiviso in fasi del flusso di lavoro. Così la selezione di tutti i moduli visibili in un dato momento corrisponde a quelli che ti serviranno proprio adesso e nei minuti successivi. Passando alla fase successiva del flusso di lavoro, avanzi nella GUI e cambi la vista. Si chiama presentazione.
Questo traccia un percorso lineare da seguire, per ricavare un po’ di struttura e di guida dall’apparente disordine. Le GUI non servono solo a esporre i controlli, servono anche a insegnare, comunicare e pubblicizzare le possibilità disponibili.
Così ogni scheda è ora una diapositiva della nostra presentazione del flusso di lavoro, che è strettamente legata all’ordine della pipeline. E la struttura è emersa dal disordine.
Con alcune eccezioni. Per esempio, i moduli di riduzione del rumore devono avvenire presto nella pipeline per la coerenza del segnale, eppure compaiono più tardi nel flusso di lavoro rispetto, per esempio, alla calibrazione del colore, perché lavorano a livello di pixel e generalmente non cambiano la dominante di colore globale (a meno che tu non abbia un danno da rumore serio che potrebbe spostare l’asse verde/magenta, ma questo avviene tipicamente sopra gli 8000 ISO). Lo stesso vale per gli algoritmi di nitidezza: nessuno di questi cambierà drasticamente la chiarezza, la tonalità o la croma al punto da invalidare le precedenti (in termini di flusso di lavoro) impostazioni globali di colore ed esposizione, e le impostazioni corrette saranno anche soggette a quanto hai alzato l’esposizione della foto (aggravando così la forza visiva del rumore). Queste eccezioni alla regola sono rese chiare dall’analisi numerica dei filtri di pixel, il che significa che chi non ha letto il codice sorgente con una previa conoscenza di elaborazione del segnale non avrà la minima idea.
Implementazione
Principio
- Fasi del flusso di lavoro == schede dei moduli.
- Queste schede hanno nomi testuali, che potrebbero occupare più spazio nella GUI ma non devi leggere una documentazione e/o indovinare cosa significano: c’è scritto sull’etichetta.
- La prima e l’ultima scheda sono speciali
- Mostrano rispettivamente la lista dei moduli abilitati (pipeline) e l’intera lista dei moduli disponibili (tutti).
- Non tutte le schede sono immediatamente visibili
- A seconda della larghezza del pannello laterale, alcune schede saranno nascoste, il che va bene perché le seguirai da sinistra a destra in sequenza, quindi non hai davvero bisogno di sapere cosa viene dopo
- All’interno delle schede, i moduli sono organizzati come livelli nell’ordine della pipeline
- Cioè dal basso verso l’alto. È così che dovresti impostarli. Quindi la pila di moduli rappresenta la pila di effetti/filtri/livelli sopra l’immagine raw.
TL;DR: segui l’ordine della GUI da sinistra a destra, e dal basso verso l’alto (perché sono livelli), e hai il tuo flusso di lavoro senza tediose letture della documentazione.
I moduli della camera oscura possono essere riordinati in qualsiasi scheda tenendo premuto Ctrl+Shift2 mentre esegui un trascina-e-rilascia con il mouse, sopra le intestazioni dei moduli. Tieni presente che questo riordina i moduli anche nella pipeline, non va usato come comodità della GUI. È meglio farlo nelle schede «pipeline» o «tutti», dove hai una visione completa del contenuto della pipeline.
Sostituire i moduli preferiti
Il design attuale non ha alcun modo di definire i moduli preferiti in una scheda speciale. Non vedo il senso di aggiungere altro ingombro per risolvere il problema di avere ingombro all’inizio.
Per quei moduli speciali, puoi assegnare delle scorciatoie agli eventi «mostra» (ovvero apri, mostra, visualizza, apri) o «abilita» (ovvero attiva). Vai al menu Modifica, poi in fondo clicca su Scorciatoie da tastiera, poi con il cursore speciale che ottieni, clicca sull’intestazione del tuo futuro modulo preferito (sul suo nome). Esempio qui con il modulo esposizione:
Per impostazione predefinita, ti verrà proposto l’evento «mostra», nella colonna elemento (un’altra etichetta che dovrei cambiare). Puoi cambiarlo con l’evento «abilita» o «istanza» (ovvero istanzia). L’effetto non conta per questo, non ho testato in quale caso viene usato e comunque il tutto è un groviglio ingarbugliato.
In ogni caso, queste scorciatoie ti porteranno istantaneamente ai tuoi moduli preferiti senza inquinare ulteriormente lo spazio della GUI.
Conclusione
Questo non risolve il problema del fatto che i moduli sono chiamati con qualcosa che non interessa agli utenti, e del fatto che i moduli di elaborazione delle immagini hanno lo stesso aspetto di quelli che non elaborano immagini. Ho alcune idee al riguardo, ma sarà per un’altra volta.
Note a margine
Molti altri strumenti precedentemente nascosti in criptici pulsanti-icona sono stati unificati nel menu globale. Questo menu può essere aperto premendo Alt seguito dalla lettera mnemonica del menu (che verrà sottolineata una volta premuto Alt). Una volta aperto, il menu è navigabile con i tasti freccia.
Il ritorno al tavolo luminoso è ora mappato sul tasto Escape/Return. Nel tavolo luminoso, la ricerca testuale delle foto è anch’essa mappata su Ctrl+F (come ti aspetteresti). Sfogliare le foto si può fare con i tasti Freccia, la selezione con il tasto Spazio, e aprire una foto in camera oscura si può fare premendo il tasto Invio.
Questo significa che l’applicazione è ora quasi interamente navigabile con la tastiera senza dover ricordare le scorciatoie. Quelle scorciatoie sono comunque visualizzate nel menu, a destra delle voci.
La tabella di tutte le scorciatoie si trova ora nel menu Aiuto, in precedenza era accessibile solo… tramite una scorciatoia.
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. ↩︎
