Blackmagic DaVinci Resolve / Fusion Forum



DRT statt CST in Resolve?



... was die Arbeit mit dieser speziellen Software betrifft.
Antworten
cantsin
Beiträge: 16346

DRT statt CST in Resolve?

Beitrag von cantsin »

Darren Mostyn macht hier ein Fass auf und argumentiert, dass man statt Resolves mitgeliefertem "Color Space Transform"-Effekt (CST) zur Umwandlung von Gammas und Farbräumen (wie z.B. Log zu Rec709) lieber Third Party-DRTs (Device Rendering Transforms) verwenden solle. Diese werden als DCTLs ausgeliefert und installiert und setzen daher Resolve Studio voraus.

DRTs gibt es sowohl als Gratis-, als auch als kommerzielle Software. Es handelt sich faktisch um alternative Tone Mapper, die den erweiteren Farbraum und die erweiterte Dynamik von Log/Wide Gamut in den engeren Farbraum und den geringeren DR von Rec709 hineinkomprimieren.

Bei meinen eigenen Experimenten mit den DRTs JP2499 sowie OpenDRT erhalte ich jedoch hauptsächlich stärkere Bildkontraste mit weniger Farbseparation - sozusagen einen stilisierten Filmlook-Filter - ggü. CST und bin daher bei CST geblieben.

Mich würden daher mal Eure Erfahrungen und Tips interessieren. Gut möglich, dass ich das Licht noch nicht richtig gesehen habe...

Hier das Video:


Und hier eine KI-Zusammenfassung von Google Gemini:
Das Video ist ein Tutorial über die Verwendung von Device Rendering Transforms (DRTs) in DaVinci Resolve für das Farbmanagement.

Was ist ein DRT?

Ein DRT ist der letzte Schritt im Farbmanagementprozess. Es nimmt einen weiten Farbraum, wie DaVinci Wide Gamut, und wandelt ihn in einen Anzeigefarbraum wie Rec. 709 um.

Das Color Space Transform (CST)-Tool in DaVinci Resolve ist eine Form von DRT, die der Host seit Jahren verwendet.

Drittanbieter-Entwickler haben ihre eigenen benutzerdefinierten DRTs erstellt, die oft bevorzugt werden, weil sie ansprechendere Ergebnisse liefern und den Workflow vereinfachen, indem sie Tone-Mapping automatisch handhaben.

Im Video vorgestellte DRTs

Der Host vergleicht vier DRTs an vier verschiedenen Aufnahmen (einer Testkarte, Innenaufnahmen, Außenaufnahmen und Nachtaufnahmen):

1. DaVinci Resolves CST: Das Standard-DRT, das der Host seit Jahren verwendet, erfordert manuelle Anpassungen von Einstellungen wie Tone-Mapping und Sättigungskompression.

2. JP2499: Ein kostenloses DRT von Juan Pablo Zambranos GitHub-Seite. Es macht manuelle Tone-Mapping-Anpassungen überflüssig und liefert einen ansprechenden, wenn auch unverwechselbaren Look mit einer leichten Wärme- und Farbverschiebung.

3. Mononodes Look Lab Print: Ein DCTL von Mononodes, das der Host speziell wegen seines Print-Elements verwendet. Es bietet eine saubere Transformation mit exzellentem Tone-Mapping, das Highlights und Farben sehr gut handhabt.

4. OpenDRT: Ein kostenloses DRT von Jed Smith. Es bietet standardmäßig einen Look mit hohem Kontrast, kann aber für einen neutraleren Ausgangspunkt auf ein "Basis"-Level eingestellt werden.

So installieren und verwenden Sie ein DCTL (DRT):

Gehen Sie zu Project Settings > Color Management > Lookup Tables.

Klicken Sie auf Open L Folder, um auf das Verzeichnis zuzugreifen, in das Sie die DCTL-Dateien legen.

Nach dem Hinzufügen der Dateien gehen Sie zurück zu den Resolve-Einstellungen und klicken Sie auf Update Lists, starten Sie dann die Software neu.

Sie können das DCTL dann auf einer Node anwenden, indem Sie es aus dem DCTL-Menü auswählen.

Das Video schließt mit der Demonstration, wie jedes DRT die verschiedenen Arten von Aufnahmen handhabt, und erklärt, warum der Host die Verwendung von DRTs von Drittanbietern bevorzugt, um einen besseren und konsistenteren farbverwalteten Look zu erzielen, insbesondere bei schwierigen Aufnahmen wie Nachtaufnahmen mit Neonlichtern.
"Wieso eigentlich überhaupt was drehen? Warum nicht jahrelang nur darüber philosophieren?" -stip



vago
Beiträge: 23

Re: DRT statt CST in Resolve?

Beitrag von vago »

cantsin hat geschrieben: Mo 04 Aug, 2025 15:47 Mich würden daher mal Eure Erfahrungen und Tips interessieren. Gut möglich, dass ich das Licht noch nicht richtig gesehen habe...

Hallo Cantsin,

sind ja einige, die das auf Youtube gerade rauf und runterbeten, neben Darren u.a. auch Cullen Kelly ...
Von daher ging es mir genauso wie dir, ich musste es mal ausprobieren (hatte früher schon ein paar Mal versucht das JP2499 zu verwenden und hatte immer Probleme, allerdings muss ich zugeben, ich hab am Schluss des Gradens damit rumgespielt und der Erfolg war eher bescheiden.
Mit dem OpenDRT erziele ich bessere Erfolge (als mit JP2499) - zumindest für meinen Geschmack. Allerdings auch nur wenn ich das von Anfang an als ->REC709 Node am Ende verwende ...
Ob es wirklich besser als Davinci Resolves CST ist? Da bin ich mir auch noch nicht schlüssig und werd noch ein bisschen rumspielen .... bin aber neugierig auf die Diskussion hier.

LG
Michael



TheBubble
Beiträge: 2038

Re: DRT statt CST in Resolve?

Beitrag von TheBubble »

Vorweg: Ich habe das Video nur auszugsweise und im Schnelldurchgang (mit häufigem Vorspringen) angesehen. Fast eine halbe Stunde ist mir zu lang.

Mir ist unklar, warum überhaupt geraten wird Eingangs- und Ausgangstransformationen für jeden Clip anzulegen - die einfache und zukunftsorientierte Vorgehensweise wäre es einfach das Farbmanagement zu aktivieren und sich danach auf die kreative Farbanpassung zu konzentrieren. Da von DaVinci Resolve sowieso alles als Fließkommazahlen verarbeitet wird, geht auch nichts verloren und man kann drauf los graden.

Einer der Gründe zusätzliche technische (und folglich nicht kreative) Transformationen einzufügen wäre nur dann vorhanden, wenn es zu einem (unbeabsichtigten) Fehlverhalten kommt: Beispielsweise können einzelne Pixel Werte außerhalb des Zielfarbraums haben, die dann beim Clippen (in jenen Zielfarbraum) zu einer unschönen Farbverschiebung führen. Das kann man aber trotz aktivem Farbmanagement beheben, manuell, per LUT, per DCTL oder per Plugin.

Ein mir bekanntes (und hier auch schon mal vor Jahren besprochenes) Beispiel sind Aufnahmen eines inzwischen über 10 Jahre alten Camcorders, der einen erweiterten Farbraum unterstützt, wodurch beispielsweise ein Himmelblau durch Clippen zum unschönen Türkis wird.

Falls jemand dieses Problem hat, einfach bei mir melden, ich hätte eine Lösung als DCTL.



stip
Beiträge: 1312

Re: DRT statt CST in Resolve?

Beitrag von stip »

Das ist ja einfach "nur" eine weitere Display Transformation, wenn auch sehr schön gelungen m.M.
Im Prinzip ist es aber dasselbe wie eine LUT die bestimmtes Log Material nach zB BT-.1886 transformiert oder eben Resolve's CST's bzw Davinci YRGB Color Managed oder auch die ACES Transformation: die machen alle nichts anderes als ein log oder raw Bild dahin zu bringen, dass es "normal" auf einem Bildschirm aussieht. Die Unterschiede sind rein subjektiv, ein Look. Der eine eher neutral (Resolve), der andere schon mit mehr oder weniger fertigem look (zb OpenDRT, 2499).

Unterm Strich: es ist Geschmacksache welche Transformation einem am besten gefällt.



roki100
Beiträge: 17991

Re: DRT statt CST in Resolve?

Beitrag von roki100 »

"Deine Zeit ist begrenzt. Verschwende sie nicht damit, das Leben eines Anderen zu leben"
(Steve Jobs)



cantsin
Beiträge: 16346

Re: DRT statt CST in Resolve?

Beitrag von cantsin »

TheBubble hat geschrieben: Mo 04 Aug, 2025 20:47 Einer der Gründe zusätzliche technische (und folglich nicht kreative) Transformationen einzufügen wäre nur dann vorhanden, wenn es zu einem (unbeabsichtigten) Fehlverhalten kommt: Beispielsweise können einzelne Pixel Werte außerhalb des Zielfarbraums haben, die dann beim Clippen (in jenen Zielfarbraum) zu einer unschönen Farbverschiebung führen.
Es geht bei den DRTs sowieso nur ums letzte Glied in der Kette, also typischerweise die Transformation von Davinci WideGamut + Davinci Intermediate Gamma nach Rec709.

Mostyns Argumentation ist hier, dass das Standard-Tonemapping/Gamutmapping von Resolve, das sowohl bei CST, als auch beim Resolve Color Managed-Workflow verwendet wird, nicht gut darin ist, Farben, die außerhalb von sRGB/Rec709 liegen in den engeren Farbraum zu mappen, auch nicht mit den unter "Gamut Mapping" gebotenen Einstelloptionen. [Wenn man den Resolve Color Managed-Workflow wählt, stehen diese Parameter - da nun unsichtbar für den User - sowieso immer auf den Standardwerten und können nicht mehr geregelt werden.] Das betrifft vor allem Neonröhren/-reklamen und ähnliche Lichtquellen bzw. Motive, deren Farben dann in Rec709 ausbluten.

Mostyn argumentiert, dass Third Party-DRTs wie OpenDRT und Mononodes Look Lab Print besser darin sind, solche extremen Farbtöne in Rec709 zu "zähmen" und sie daher Arbeit in der Post ersparen bzw. einen besseren Ausgangspunkt fürs eigene Grading bieten.

Für mich sieht das aber eher so aus, als ob sie die Farbsättigung (im Vergleich zu CST) generell runterregeln [was theoretisch auch mit einer Korrekturnode vor CST ginge] und dadurch problematische Grenzfälle umgehen.
"Wieso eigentlich überhaupt was drehen? Warum nicht jahrelang nur darüber philosophieren?" -stip



roki100
Beiträge: 17991

Re: DRT statt CST in Resolve?

Beitrag von roki100 »

Ich habe OpenDRT ausprobiert und muss sagen, es ist schon besser. Viel natürlicherer Look, vor allem bei Skintones.
(Boris, wenn du noch da bist, es ist genau was für dich bzw. VLOG)
"Deine Zeit ist begrenzt. Verschwende sie nicht damit, das Leben eines Anderen zu leben"
(Steve Jobs)



cantsin
Beiträge: 16346

Re: DRT statt CST in Resolve?

Beitrag von cantsin »

Hier mal ein eigener Test, mit für Rec709 kritischen Farbtönen von nächtlichen LED-/Neonlichtern. Das Ausgangsmaterial war ein mit einer Nikon Z6iii geschossenes und in DNG umgewandeltes Foto-Raw, im Resolve Projekt interpretiert als Davinci WideGamut/Intermediate und dann jeweils mit CST, OpenDRT und JP_2499 nach Rec709 gewandelt:
CST default_1.2.1.jpg
CST default-settings.png
CST, mit Standardeinstellungen


CST tweaked_1.3.1.jpg
CST tweaked-settings.png
CST, mit getweakted Einstellungen (vor allem: Gamut-Mapping + Knee)


OpenDRT default_1.4.1.jpg
OpenDRT default-settings.png
OpenDRT, auf Standard-Setting


OpenDRT tweaked_1.5.1.jpg
OpenDRT tweaked-settings.png
OpenDRT, mit getweakted Settings.



(JP_2499 folgt, wegen der Forums-Software-Beschränkungen für Dateianhänge, im nächsten Posting)
"Wieso eigentlich überhaupt was drehen? Warum nicht jahrelang nur darüber philosophieren?" -stip
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.



cantsin
Beiträge: 16346

Re: DRT statt CST in Resolve?

Beitrag von cantsin »

JP_2499 default_1.6.1.jpg
JP_2499 default-settings.png
JP_2499, Default


JP_2499 tweaked_1.7.1.jpg
JP_2499 tweaked-settings.png
JP_2499, Tweaked




Nochmal alle Bilder im Direktvergleich (CST, CST tweaked, OpenDRT, OpenDRT tweaked, JP_2499, JP_2499 tweaked):
CST default_1.2.1.jpg
CST tweaked_1.3.1.jpg
OpenDRT default_1.4.1.jpg
OpenDRT tweaked_1.5.1.jpg
JP_2499 default_1.6.1.jpg
JP_2499 tweaked_1.7.1.jpg

Lustigerweise finde ich ja, dass CST z.B. das ausblutende Rot der Verkehrsampel noch am besten in den Griff kriegt...
"Wieso eigentlich überhaupt was drehen? Warum nicht jahrelang nur darüber philosophieren?" -stip
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.



roki100
Beiträge: 17991

Re: DRT statt CST in Resolve?

Beitrag von roki100 »

Auch in deinem Beispiel finde ich OpenDRT schon besser.

Ich finde das mit den Farben/Skintones sehr interessant, scheint also (wie damals vermutet als ich VLOG in FCP kennengelernt habe) tatsächlich ein VLOG-Problem zu sein? Hier ein Beispiel:

CST
(Ohr rötlich, seltsame Farben ehrlich gesagt, wirkt zu digital...)
Bildschirmfoto 2025-08-05 um 01.37.43.jpg
OpenDRT
Bildschirmfoto 2025-08-05 um 01.36.44.jpg
sehr ähnlich auch in FCP (nur Belichtung angepasst)
Bildschirmfoto 2025-08-05 um 01.36.22.jpg
Selbst das (Lumix) Like709-Profil wirkt viel näher an OpenDRT als an CST.
"Deine Zeit ist begrenzt. Verschwende sie nicht damit, das Leben eines Anderen zu leben"
(Steve Jobs)
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.



TheBubble
Beiträge: 2038

Re: DRT statt CST in Resolve?

Beitrag von TheBubble »

Mir gefallen die CST Varianten auch noch am Besten, wobei bei den Ampeln die eigentliche Lampe, bei der Fahrradampel die Maske mit dem Fahrrad, auffällig schärfer umrandet sind. Aber das sind Details, auf die kaum ein normaler Betrachter achten wird, schon gar nicht wenn die Einstellung nur kurz ist.

Ich habe hier noch ein extremes Beispiel zur Illustration, was Clipping einzelner Komponenten eines Farbvektors verursachen kann (auch wenn dies hier kein HDR-Beispiel ist):

Ein Clip wird importiert, der mit einer (alten) Kamera aufgenommen wurde, deren Sensor aber einen größeren Farbraum als Rec.709/sRGB erfassen kann. Die zusätzlichen Farben sind in sRGB/Rec.709 nicht darstellbar, sie liegen außerhalb des Farbwürfels. Gespeichert wurden sie ursprünglich von der Kamera als YCbCr-Vektoren, die nach RGB rücktransformiert allerdings außerhalb des RGB-Würfels des Rec.709/sRGB Farbraums liegen.

Alle folgenden Bearbeitungen und Analysen wurden im Rec.709/sRGB Farbraum vorgenommen.

Zuerst sieht es so aus:
Still Default.jpg
Sehr auffällig ist die Farbe des Himmels, so sieht ein blauer Himmel für mich jedenfalls nicht aus.

Das könnte man jetzt manuell korrigieren (oder es zumindest versuchen), aber analysieren wir zuerst mit einem Hilfsmittel das Problem:
Still Default ooG Highlighed.jpg
Alles was entsättigt (grau) ist, liegt im RGB-Würfel. Alle roten Pixel haben einen Farbvektor, von dem mindestens eine Komponente größer 1.0 ist, d.h. der Vektor zeigt auf einen Punkt (eine Farbe) außerhalb des darstellbaren Farbwürfels.

Diese unzulässigen Werte einzelner Vektorkomponenten müssen vor der Darstellung abgeschnitten (geclipped) werden, was praktisch alle Medienplayer machen. Hierbei entsteht die seltsame Farbgebung.

Anstelle mich manuell am Problem zu versuchen, korrigiere ich die problematischen Pixel automatisiert. Alle anderen Pixel bleiben unangetastet, was allerdings auch Vor- und Nachteile hat (die hier im Beispiel aber keine Rolle spielen):
Still Fixed.jpg
Analysiert man jetzt die reparierte Variante, dann liegen hier alle Pixel innerhalb des darstellbaren Farbwürfels:
Still Fixed ooG Highlighted.jpg
Ob das Ergebnis gefällt ist Geschmackssache. Tatsächlich weicht es die ursprüngliche Variante mit Clipping mathematisch gesehen weniger stark vom Original ab, als die "Verbesserte".

Es sieht aber nicht mehr so ungewöhnlich aus.
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.



Axel
Beiträge: 16956

Re: DRT statt CST in Resolve?

Beitrag von Axel »

TheBubble hat geschrieben: Di 05 Aug, 2025 02:46 Ob das Ergebnis gefällt ist Geschmackssache..
Darauf läuft es hinaus. Grading lässt sich gut mit Kochen vergleichen, und ob man nun mit Salinensalz (CST) oder Meersalz (DRT) würzt, darauf hätten Köche durchaus eine Antwort (wenn auch eine hypothetische. Profiköche müssen auf die Lebensmittelinflation reagieren, und so gilt: was der Gast nicht bemängelt …)

Mein Problem mit beiden ist mein Workflow. Ich möchte nicht nach dem Import und während des Schnitts noch auf Log-Grauschleier-Footage starren. Wenn ich nicht einen groben Denkfehler mache (? - bitte kommentieren) lösen nur RCM und ACES dieses Problem - beide ja ebenfalls mit unterschiedlichen Look-Charakteristika.
Na und? Im Fernsehen wird ja auch alles wiederholt ...



 Aktuelle Beiträge [alle Foren]
 
» Canon EOS C70 aktuell für 2.499 Euro erhältlich!
von rush - Di 6:50
» DRT statt CST in Resolve?
von Axel - Di 4:53
» Empfehlung neues Videoschnittprogramm
von popaj - Di 1:17
» Panasonic S5 - Allgemeine Fragen, Tipps und Tricks, Zeig deine Bilder/Videos usw.
von roki100 - Di 0:11
» Anfängerfragen Audio allgemein und speziell
von Jörg - Mo 22:52
» Verikalen Kameraschwenk mit After Effects CS6 stabilisieren
von Jott - Mo 22:21
» Ruckelige Bewegungen - noch was zu retten?
von Bildlauf - Mo 21:46
» Viltrox bringt 25mm/1.7 APS-C Budget-Objektiv
von rush - Mo 21:45
» Windows Laptops bald mit Apple M3 Mac auf Augenhöhe?
von markusG - Mo 20:17
» LUT me now!
von Bildlauf - Mo 19:56
» Neuer Portkeys PT5 III Kameramonitor wiegt ca. 150g und ist etwas heller als zuvor
von Bildlauf - Mo 19:43
» Projekt "The Unfinished Film" - Adobe lädt ein zum Remix per KI
von caiman - Mo 17:00
» Olight und Linogy: Moderne AA(A)- Lade- und Akku-Technologien bei Kickstarter
von slashCAM - Mo 16:36
» BIETE: MacBook Pro 16" | M1 Max Chip | 32GB | 1TB
von benedika - Mo 16:08
» DJI Mini 5 Pro kommt in 5 Wochen - mit 50 Min Flugzeit und LiDAR
von patfish - Mo 10:49
» DJI RS4 Mini im Verbund mit Sony FX30 und Sigma 17-40mm F1.8 DC Art / Teil 2
von slashCAM - Mo 10:48
» Filmoptimierte Steuerung Canon R6 II
von Jörg - Mo 9:05
» Sony A7III Video ruckelt
von KirstenW - Mo 6:49
» SWIT Crew - Neue Profi-Videofunkstrecke mit Timecode und Metadatenübertragung
von tom - So 14:18
» Was schaust Du gerade?
von roki100 - So 10:22
» Einmal Denoising und zurück - Neue Filmkorn-Simulation bei Netflix
von Axel - Sa 22:42
» BMD Production Camera 4k in 2025?
von Ziggy Tomcat - Sa 18:24
» Godox AM1600R 88K - aufblasbares Full-Color LED-Flächenlicht mit 1.600W
von slashCAM - Sa 17:12
» Linsen (Vintage, Anamorphic & Co.)
von roki100 - Fr 22:55
» >Der LED Licht Thread<
von Rockcrusher - Fr 20:18
» 28 Years Later - offizieller Trailer
von 7River - Fr 20:01
» Der nächste Schlag für die Filmindustrie
von iasi - Fr 18:12
» ALEXA 35 Xtreme mit bis zu 660 fps vorgestellt - und neuer ARRICORE Codec
von TheBubble - Fr 16:46
» Photoshoppen wird einfacher - KI gleicht eingefügte Bildobjekte an
von cantsin - Fr 14:48
» Adobe Premiere Pro - erste Beta unterstützt nativ ARM unter Windows
von slashCAM - Fr 11:54
» Externe USB4 SSD als Mac Systemplatte nutzen - am Beispiel der Corsair EX400U
von rudi - Fr 10:10
» 7artisans 15mm/4.0 asph. Nikon Z OVP
von thsbln - Do 15:17
» DJI fordert mit neuer Osmo 360° Kamera den Marktführer heraus
von slashCAM - Do 14:21
» Jetzt ist es offiziell - DJI Osmo 360 Kamera kommt am 31. Juli
von Clemens Schiesko - Do 14:17
» Verkaufe Walimex pro Flex LED 1000 Bi Color *SET*
von leonlhs - Do 9:00