darktable’s kleurenpijplijn
De meeste beeldverwerkingstoepassingen stammen uit de jaren 90 en/of erven een werkvolgorde uit de jaren 90. Deze toepassingen verwerkten afbeeldingen die waren gecodeerd met 8-bits gehele getallen zonder teken omdat het geheugen- en rekenkundig efficiënter was. Vanwege het gebruik van een gehele-getallen-formaat (wat afrondingsfouten impliceert) moesten ze een “gamma” toepassen (in wezen een overdrachtsfunctie die een macht 1/2.2 of 1/2.4 toepast om de RGB-waarden te coderen) en de bit- diepte in de schaduwen verhoigen om afrondingsfouten te verminderen (mensen zijn erg gevoelig voor details bij weinig licht). De 8-bits gehele-getallen-indelingen zijn ook technisch beperkt tot het bereik van 0-255. Alles buiten dit bereik loopt over en wordt afgeknipt naar de dichtstbijzijnde grens.
Deze werkvolgordes, die gebruikmaken van begrensde RGB-representaties en mogelijk niet-lineaire transformaties om RGB-signalen te coderen, worden “weergave-gerefereerd” genoemd. Ze gaan uit van de aanname dat het beeld in een vroeg stadium van de verwerkingspijplijn is voorbereid voor weergave en bevatten hardgecodeerde aannames over de RGB-waarden van zwart, middengrijs en wit. De meeste beeldverwerkingsalgoritmen die in deze werkvolgordes worden gebruikt, zijn afgestemd op deze aannames. De overlay-overvloeimodus verwacht bijvoorbeeld een middengrijs gecodeerd op 50% (of 128 in codering met gehele getallen).
Helaas verbreekt de niet-lineaire schaling, die verplicht is om de gehele codering te laten werken, de natuurlijke relaties tussen pixelwaarden. Tint en verzadiging veranderen op onvoorspelbare manieren, en waarderelaties tussen aangrenzende pixels worden vergroot of gecomprimeerd, zodat gradiënten ook onvoorspelbaar worden gewijzigd.
Scherm-gerelateerde pijpleidingen breken daarom optische filters (lensvervaging of onscherpte), alfa-compositing (die afhankelijk is van optische en geometrische definities van occlusie), kleuren en gradiënten (lokale relaties tussen chrominantie en luminantie van pixels). Ze schalen ook niet goed naar HDR-afbeeldingen, wat leidde tot de ontwikkeling van veel twijfelachtige lokale en wereldwijde toonmapping-methoden en de beruchte “HDR-look” uit de jaren 2010.
Moderne computers zijn niet gebonden aan dezelfde rekenbeperkingen als die uit de jaren negentig, en kunnen werken op pixels waarvan de waarden volledig onbegrensd zijn (van 0 tot +oneindig) en gecodeerd als reële getallen (met behulp van drijvende-komma-indelingen). Deze mogelijkheden maken een zogenaamde “scene-gerelateerde” werkvolgorde mogelijk, waarin pixels hun oorspronkelijke radiometrische relaties over bijna de gehele verwerkingspijp kunnen behouden. In een scene-gerelateerde werkvolgorde worden pixels alleen voorbereid voor weergave in de laatste fase van de pijplijn, in de weergavetransformatie. Dit betekent dat de RGB-waarden van de pixels evenredig worden gehouden met de intensiteit van de lichtemissie die door de camera ter plaatse wordt geregistreerd, waardoor nauwkeurige alfacompositie en optische filteremulaties mogelijk zijn, terwijl ook wordt geschaald naar elk dynamisch bereik via hetzelfde algoritme (SDR als evenals HDR).
Scène-gerefereerde pijplijnen verliezen echter de handige vaste waarden van wit, middengrijs en zwart die kenmerkend waren voor weergave-gerelateerde pijplijnen, en het instellen van deze waarden, afhankelijk van de scène en de opnameomstandigheden, wordt nu de verantwoordelijkheid van de gebruiker. Dit vereist een complexere gebruikersinterface.
Omdat door de scène gerefereerde waarden geacht worden fysiek zinvol te zijn, kunnen pixels geen intensiteit van nul hebben. Dit zou betekenen dat ze helemaal geen licht hebben, en het bestaan van nullicht verbreekt veel fysiek nauwkeurige algoritmen. In feite betekenen wit en zwart niets voor de oorspronkelijke scène, die slechts een verzameling luminanties is met verschillende intensiteiten. De naar de scène verwezen werkvolgorde is eenvoudigweg bedoeld om een aantal willekeurige scèneluminanties opnieuw toe te wijzen aan wat wit of zwart zal lijken op het uitvoermedium.
Versies van darktable vóór 2.6 hadden een niet-lineaire weergave-gerefereerde pijplijn, ervan uitgaande dat er vroeg in de pijp een niet-lineaire transformatie plaatsvond en middengrijs daarna werd gecodeerd als 50%. Niet alle modules en filters hebben echter pixelwaarden boven de 100% afgekapt, waardoor de mogelijkheid open blijft om die waarden later in de pijp te herstellen.
De weergavetransformatie van de filmisch-module, geïntroduceerd in darktable 2.6, was de eerste stap in de richting van een scene-refereeerde pijplijn, en stelde de verplichte, niet-lineaire, weergavevoorbereiding uit tot het einde van de pijp, samen met de mogelijkheid om custom zwart, grijs in te stellen en witwaarden. De module kleurbalans introduceerde vervolgens een manier om met een variabele definitie van middengrijs om te gaan.
Vanaf darktable 3.2 konden gebruikers kiezen tussen twee werkvolgordes die consistente standaardinstellingen, modules en pijplijnvolgorde voor zowel scherm-relateerde als scene-releateerde verwerking definieerden.
In darktable 3.4 is een volledige scène-gerefereerde maskerings- en overvloeioptie geïntroduceerd, waardoor maskers kunnen worden gedefinieerd voor pixelwaarden boven 100% en met alleen onbeperkte overvloeioperators.
Overschakelen naar scene-gerefereerd is een cognitieve sprong voorwaarts voor de meeste ervaren gebruikers, die gewend zijn te denken op een manier die wordt gerefereerd aan beeldschermen. In een werkstroom die naar het beeldscherm verwijst, is het gebruikelijk om de witwaarde te verankeren en de toonaanpassingen rond dat punt te laten draaien, waarbij wordt geprobeerd de helderheid te maximaliseren en afknippen te vermijden. In een op scène gebaseerde werkstroom zijn wit- en zwartwaarden vloeiend en aangepast aan het uitvoermedium. Het wordt aangeraden dat gebruikers middengrijs verankeren (dat behouden blijft voor elk uitvoermedium) en de weergavetransformatie (filmisch) het dynamische bereik rond dat punt laten vergroten of verkleinen. Omdat 10-bits HDR-wit 4 keer zo helder is als 8-bits SDR-wit, wordt elke strakke definitie van “wit” irrelevant. Maar verankeren voor middengrijs is eigenlijk handiger, omdat het de gemiddelde helderheid van het beeld ongewijzigd houdt door de beeldtransformatie.
Sommige modules (niveaus, rgb niveaus, tooncurve, rgb curve) zijn inherent incompatibel met een scene-refereerde werkstroom, omdat hun grafische interface impliciet RGB-waarden suggereert die binnen het bereik van 0-100% liggen. Hoewel de pixelbewerkingen die ze uitvoeren kunnen worden gebruikt in werkstromen die naar de scène verwijzen of naar de weergave verwijzen, omdat ze intern onbegrensd zijn, staat hun besturingsinterface niet toe dat pixels buiten het bereik van 0-100% worden geselecteerd.
Evenzo hebben overvloeimodi zoals overlay, lineair licht, zacht licht, hard licht, donkerder, helderder, enz. allemaal hardgecodeerde drempels die intern niet-lineaire codering op het scherm verwachten.
In darktable 3.4 en hoger wordt door de cursor over een modulekop te bewegen een tooltip weergegeven met details over de kleurruimten, bereiken en coderingen die de module verwacht, gebruikt en produceert. Hier zijn de definities van de gebruikte termen:
- lineair
- Pixelwaarden zijn evenredig met de radiometrische emissie van de scène, op een manier die nauwkeurige emulatie van fysieke filters mogelijk maakt.
- niet-lineair
- Pixelwaarden worden opnieuw geschaald zodat weinig licht een groter coderingsbereik krijgt, meestal om de 18,45%-referentie middengrijs opnieuw toe te wijzen aan een waarde tussen 46 en 50%.
- scherm-gerelateerd
- Pixelwaarden zullen naar verwachting tussen 0 en 100% van het weergavebereik liggen, waarbij 100% wordt gezien als de luminantie van een 20% reflecterend wit oppervlak (de witte vlek van een Kleur Checker) en 0% als de maximale dichtheid van het uitvoermedium (verzadigde zwarte inkt of minimale achtergrondverlichting van het LED-paneel).
- scene-gereleateerd
- Pixelwaarden zullen naar verwachting groter zijn dan nul tot +oneindig. De betekenis van specifieke pixelwaarden moet tijdens runtime door de gebruiker worden gedefinieerd. Waarden waarnaar naar de scène wordt verwezen, impliceren niet automatisch een lineaire, radiometrisch geschaalde codering.