Als je van Darktable komt, ben je in de donkere kamer misschien dit gewend:
terwijl Ansel je dit biedt:
Dat is geen toeval, en het is tijd om uit te leggen waarom, en waarom dit niet zal worden uitgebreid met aanpassingsmogelijkheden.
Beelden worden geboren uit pipelines
Een pixelpipeline is een reeks filters waarin pixels worden verwerkt om uiteindelijk op een medium te belanden. Photoshop noemt die filters lagen , volgens een metafoor die is overgeërfd van papier en matte painting. Da Vinci Resolve, Blender, Natron, enz. noemen ze nodes , volgens een metafoor die geworteld is in gerichte grafen en stroomschema’s , het best bekend bij ingenieurs. Beide hebben een manier om te tonen hoe die filters georganiseerd zijn, ofwel met een lagenstapel ofwel met de nodegraaf (oftewel stroomschema).
Het belangrijke is: volgorde is belangrijk.
Een korte geschiedenis van slecht ontwerp
Darktable noemt die filters modules. Maar “modules” verwijst naar de modulaire programmeerlogica : elke module wordt apart gecodeerd, met een uniforme API, en weet niets van de andere modules af. De pipeline zelf weet niets over de interne werking van modules, hij verbindt alleen de invoer en de uitvoer. Het is een schone manier van ontwikkelen, maar het is volstrekt irrelevant voor de eindgebruiker.
Het probleem is dat Darktable 2 soorten modules heeft:
- de lichttafelmodules (en de modules in het linkerpaneel van de donkere kamer), die willekeurige gereedschapskisten zijn en daarom puur GUI-elementen/-kaders,
- de donkerekamermodules, die zowel een pixelfilter zijn dat ergens in de pipeline zit, als ook een GUI-gereedschapskist (hetzelfde als de vorige modules).
En die verschillende modules zien er, behalve dat ze hetzelfde heten, ook precies hetzelfde uit…
Dat zijn hier 3 fouten:
- een GUI-object benoemen naar de naam van zijn technische implementatie in plaats van naar zijn functionele doel,
- 2 conceptueel verschillende objecten op dezelfde manier benoemen en weergeven,
- de volgorde van de modules niet op een duidelijke, hiërarchische manier weergeven.
Als gevolg daarvan beschouwen veel gebruikers nog steeds alle modules als willekeurige gereedschapskisten, en hebben ze jarenlang gevraagd om manieren om ze willekeurig in het venster te herordenen, wat een ruggengraatloos (gebrek aan) technisch leiderschap hun ook gaf, in de vorm van een verschrikkelijk gecodeerde (3500 regels code, subtiel kapot) en overgecompliceerde modulegroep, die 3 % van je CPU opslokt, zelfs wanneer je niet met de applicatie interacteert, zolang je donkere kamer inactief blijft.
De kers op de taart is dat de groepen met iconen zijn gelabeld, omwille van de compactheid, maar die iconen zijn volstrekt cryptisch en alleen de langdurige gebruikers doen alsof ze weten wat ze voorstellen (ik heb er een getekend die lichtstralen voorstelt die door een dunne lens gaan, die mensen voor een ufo aanzien – ik heb van die fout geleerd).
Goede werkstromen zijn pipeline-bewust
Ik word nu al 3 jaar door gebruikers betaald om hun de ins en outs van de software uit te leggen, en om steeds dezelfde vraag te beantwoorden: waar begin je een werkstroom en hoe rol je hem af. Wat me nog steeds treft is dat mensen met een masterdiploma, die de documentatie hebben gelezen en de meeste van mijn video’s hebben bekeken, nog steeds niet in staat zijn om zelfstandig een beeldbewerkingswerkstroom te starten. Ofwel schreeuwt dit om slecht ontwerp, ofwel zijn de meeste mensen met hoger onderwijs idioten. Zelfs als mensen idioten waren, is het eigenlijk makkelijker om het ontwerp idiootbestendig1 te maken dan te verwachten dat ze van de ene op de andere dag een brein krijgen, dus hoe dan ook is het ontwerp slecht met het oog op het doelpubliek.
Als je Photoshop opent, stapelen de lagen zich vrij intuïtief op elkaar. We hebben allemaal op de basisschool met lagen gewerkt voor kunstprojecten. Het zou niet in je opkomen om aan de onderste laag te gaan werken nadat je er bovenop nieuwe dingen hebt gezet. Welnu, de 70-en-nog-wat modules van Darktable, georganiseerd in tabbladen per thema, op een manier die geen rekening houdt met de pipeline noch met de werkstroom, schrikken gegarandeerd de nieuwkomers af en bevorderen slechte gewoontes onder de oudgedienden.
Verstandige werkstromen zijn pipeline-bewust, wat betekent dat de volgorde waarin je de filters afstelt bepaald zou moeten worden door waar die filters in de pipeline zitten. Maar ik zeg pipeline-bewust, en niet pipeline-bepaald, want het begin en het einde van de pipeline (eigenschappen van de scène en van het scherm) zouden eerst moeten worden ingesteld, om een goed overzicht te hebben van wat we ertussenin doen. Vooral als je HDR-signalen op een SDR-scherm gaat manipuleren, moet je eerst je HDR-zonnebril opzetten om je signaal in SDR te bekijken. Maar wat je ziet is niet wat er in je pipeline zit. Vandaar dat de werkstroom niet 1:1 de pipeline volgt, maar er toch vrij dicht bij blijft.
Stel je voor dat je een kleurzweem instelt in de module kleurbalans, gericht op de hooglichten via de instelling gain. Vervolgens vind je de foto te donker en maak je hem lichter met de module belichting. Maar belichting komt (ver) vóór kleurbalans in je pipe, dus nu moet je de kleurzweeminstelling bijwerken omdat die waarschijnlijk te zwaar zal zijn op de middentonen. Convolueer dat nu met nog een tussenliggende module (of meer) die een parametrisch masker zou gebruiken op om het even welke maat van lichtheid of luminantie… Dan sta je op het punt van circulair bewerken, een bijzonder inefficiënte soort frustrerende bewerkingservaring waarbij elke nieuwe instelling de vorige ongeldig maakt. Natuurlijk zijn er mensen die denken dat, aangezien fotografie een kunst is, het allemaal een kwestie van mening en voorkeur is, dus uiteindelijk maakt niets van dit alles uit. Kunst of niet, een kaartenhuis stort volledig in zodra je begint te rommelen aan de onderste verdiepingen, dus uiteindelijk gaat het erom hoeveel tijd je bereid bent te verspillen, en dit heeft niets te maken met meningen of voorkeuren. Ik zou ook willen betogen dat weekendhobbyisten net zo aan tijd gebonden zijn als professionele fotografen: de laatsten om economische redenen, de eersten omdat weekenden maar 2 dagen hebben en ze maandagochtend weer op kantoor moeten zijn met genoeg plezier in hun systeem om nog een week te doorstaan.
Dus hoe weet je wanneer je van de pipeline-volgorde moet afwijken? Wel, je boekt een sessie met mij voor de demo. Maar er is een andere oplossing (daarover verderop meer)…
Hoe dan ook, gebruikers meer opties bieden om de UI aan te passen (en misschien de aanvankelijke misvatting versterken dat modules alleen GUI-vakjes zijn) gaat het niet oplossen. Het geeft mensen eigenlijk meer opties om zichzelf schade toe te brengen. Wat je wilt en wat goed voor je is…
Het probleem opnieuw bekijken
Terwijl Darktable is afgegleden tot een speeltuin voor geeks waar nieuw beter betekent en elk probleem om meer grappige code vraagt, gaat Ansel over het oplossen van eenvoudige problemen op de eenvoudige manier, om een betrouwbaar werkpaard te produceren. Dus laten we opnieuw van boven af beginnen.
We hebben 70 modules. Hoewel Ansel er een flink aantal van heeft afgeschaft, zijn er nog steeds “te veel”, in de zin dat ze allemaal nuttig zijn voor een bepaald doel, maar dat je ze niet altijd nodig hebt, en niet allemaal tegelijk. Ook is de schermruimte beperkt en kunnen we ze absoluut niet allemaal tegelijk weergeven. En zelfs als we dat konden, zou het presenteren van een Airbus-dashboard aan je gemiddelde fotograaf niet fijn zijn.
Dus we moeten kiezen welke modules op welk moment weer te geven. Nadruk op moment.
De tijdsas afrollen
Voortbordurend op het idee van just in time, lijkt het maar natuurlijk dat de tijdsas zou worden opgesplitst in werkstroomstappen. Zo komt de selectie van alle zichtbare modules op een gegeven moment overeen met degene die je nu en in de komende minuten nodig hebt. Ga je door naar de volgende werkstroomstap, dan ga je door in de GUI en verander je de weergave. Dat heet een diavoorstelling.
Dit tekent een lineair pad om te volgen, om wat structuur en houvast te halen uit de schijnbare rommel. GUI’s zijn niet alleen bedoeld om bedieningselementen te tonen, ze zijn ook bedoeld om de beschikbare mogelijkheden aan te leren, te communiceren en aan te prijzen.
Dus elk tabblad is nu een dia van onze werkstroom-diavoorstelling, die nauw verbonden is met de pipeline-volgorde. En uit de rommel ontstond structuur.
Met enkele uitzonderingen. Zo moeten ruisonderdrukkingsmodules bijvoorbeeld vroeg in de pipeline plaatsvinden voor signaalconsistentie, maar toch verschijnen ze later in de werkstroom dan, zeg, kleurkalibratie, omdat ze op pixelniveau werken en over het algemeen de globale kleurzweem niet zullen veranderen (tenzij je ernstige ruisschade hebt die de groen/magenta-as zou kunnen verschuiven, maar dat is doorgaans boven 8000 ISO). Hetzelfde geldt voor verscherpingsalgoritmen: geen van deze zal de lichtheid, tint of chroma zo dramatisch veranderen dat het de vorige (werkstroomgewijs) globale kleur- en belichtingsinstellingen ongeldig maakt, en de juiste instellingen zullen ook afhangen van hoeveel je de belichting van de foto hebt verhoogd (waardoor de visuele sterkte van ruis verergert). Die uitzonderingen op de regel worden duidelijk gemaakt door numerieke analyse van de pixelfilters, wat betekent dat mensen die de broncode niet hebben gelezen met voorafgaande kennis van signaalverwerking geen idee zullen hebben.
Implementatie
Principe
- Werkstroomstappen == moduletabbladen.
- Die tabbladen hebben tekstuele namen, die misschien meer GUI-ruimte innemen, maar je hoeft geen documentatie te lezen en/of te raden wat ze betekenen: het staat op het label geschreven.
- Het eerste en laatste tabblad zijn speciaal
- Ze tonen respectievelijk de lijst met ingeschakelde modules (pipeline) en de volledige lijst met beschikbare modules (alle).
- Niet alle tabbladen zijn meteen zichtbaar
- Afhankelijk van de breedte van het zijpaneel zullen sommige tabbladen verborgen zijn, wat prima is omdat je ze van links naar rechts in volgorde gaat volgen, dus je hoeft eigenlijk niet te weten wat er hierna komt
- Binnen tabbladen zijn modules georganiseerd als lagen in de pipeline-volgorde
- Dat wil zeggen van onder naar boven. Zo zou je ze moeten instellen. Dus de stapel modules vertegenwoordigt de stapel effecten/filters/lagen bovenop het raw-beeld.
TL;DR: volg de GUI-volgorde van links naar rechts, en van onder naar boven (want het zijn lagen), en je hebt je werkstroom zonder vervelend documentatie te lezen.
De donkerekamermodules kunnen in elk tabblad worden herordend door Ctrl+Shift2 ingedrukt te houden terwijl je met de muis over de modulekoppen sleept en neerzet. Wees je ervan bewust dat dit de modules ook in de pipeline herordent, het is niet bedoeld als GUI-gemak. Doe dit het beste in de tabbladen “pipeline” of “alle”, waar je een volledig overzicht hebt van de inhoud van de pipeline.
Favoriete modules vervangen
Het huidige ontwerp heeft geen manier om favoriete modules in een speciaal tabblad te definiëren. Ik zie het nut niet van het toevoegen van meer bloat om het probleem op te lossen van het aanvankelijk hebben van bloat.
Voor die speciale modules kun je sneltoetsen toewijzen aan de “show”-events (oftewel openen, tonen, weergeven, uitvouwen) of “enable”-events (oftewel activeren). Ga naar het menu Bewerken, klik dan onderaan op Sneltoetsen, en klik vervolgens met de speciale cursor die je krijgt op de kop (op de naam) van je binnenkort-favoriete module. Hier een voorbeeld met de module belichting:
Standaard krijg je het “show”-event voorgeschoteld, in de elementkolom (nog een label dat ik zou moeten veranderen). Je kunt het wijzigen naar het “enable”- of “instance”-event (oftewel instantiëren). Het effect maakt voor deze niet uit, ik heb niet getest in welk geval het wordt gebruikt en het hele geheel is toch een verwarde bende.
Hoe dan ook, deze sneltoetsen brengen je direct naar je favoriete modules zonder meer GUI-ruimte te vervuilen.
Conclusie
Dit lost het probleem niet op dat modules iets heten wat gebruikers niet interesseert, en dat beeldverwerkingsmodules er hetzelfde uitzien als niet-beeldverwerkingsmodules. Ik heb hier enkele ideeën over, maar dat is voor een andere keer.
Kanttekeningen
Veel andere gereedschappen die voorheen verborgen zaten in cryptische icoonknoppen zijn samengevoegd in het globale menu. Dit menu kan worden uitgevouwen door op Alt te drukken, gevolgd door de mnemonische letter van het menu (die onderstreept wordt zodra je op Alt drukt). Eenmaal uitgevouwen is het menu navigeerbaar met de pijltjestoetsen.
Terugkeren naar de lichttafel is nu toegewezen aan de Escape/Return-toets. In de lichttafel is het tekstueel zoeken naar foto’s ook toegewezen aan Ctrl+F (zoals je zou verwachten). Door foto’s bladeren kan met de Pijltjes-toetsen, selecteren met de Spatie-toets, en een foto openen in de donkere kamer kan door op de Enter-toets te drukken.
Dit betekent dat de applicatie nu bijna volledig met het toetsenbord navigeerbaar is zonder sneltoetsen te hoeven onthouden. Die sneltoetsen worden toch in het menu weergegeven, rechts van de items.
De tabel met alle sneltoetsen is nu te vinden in het menu Help; voorheen was hij alleen toegankelijk… via een sneltoets.
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. ↩︎
