Frage von Huitzilopochtli:Hallo zusammen,
ich habe mir mit Hilfe von LUTCalc ein paar LUTs erstellt, mit denen ich mein SLOG2/3-Material delogen kann und auf meinem Monitor bearbeiten kann.
1. In LUTcalc verwende ich z.B. folgende Werte:
----
Rec Gamma:Sony S-Log3
Rec Gamut: Sony S-Gamut
Out Gamma: Varicam V709 (gefällt mir)
Out Gamut: sRGB (für Bildschirm)
Damit keine Informationen verloren gehen wähle ich:
Input Range: Data
Output Range: Data
Hard Clip: Unclipped
--------
2. Dann generiere ich ein Set mit Belichtungskorrekturen von bis zu -2 Blenden, da ich bei S-Log stets versuche ein wenig zu überbelichten.
3. In Davinci Resolve lege ich das LUT in meine letzte Node vor dem Schärfen. In den Nodes davor passe ich Kontrast und Schwarzlevel an. Spwphl in den Project settings als auch clip attirbutes habe ich data-levels angewählt.
So weit so gut, nur: Je höher die Belichtungskorrektur, desto höher liegt auch der Schwarzpegel im Waveform-Monitor. Kann mir jemand erklären, warum meine Schwarzwerte bei dieser Vorgehensweise nicht mehr bis null ziehen kann?
Antwort von WoWu:
Du kannst LOG Funktionen nur sehr unzureichend mit LUTs korrigieren, weil die Stützstellen nicht ausreichend sind, um Funktionen komplett umzukehren.
Das wirkt sich bei den meisten LOG Funktionen optisch im unteren Bereich aus.
Wenn Du Dir aus solchen Funktionen mal den Graph etwas genauer ansiehst, wirst Du sehen, was ich meine.
LUTs sind eigentlich nur als Annäherung für Monitordarstellung gedacht.
Antwort von mash_gh4:
Du kannst LOG Funktionen nur sehr unzureichend mit LUTs korrigieren, weil die Stützstellen nicht ausreichend sind, um Funktionen komplett umzukehren.
das würde ich bestreiten. mit 1D-LUTs kann man man dies transformation geradezu perfekt abwickeln! das ist auch die art und weise, wie das in der praxis bspw. in der ACES bzw. OpenColorIO verarbeitung passiert, weil es ressourcenschonender zu bewältigen ist als andere umsetzungsvarianten.
Antwort von WoWu:
Jede Funktion ist durch die entsprechende reverse Funktion präziser abzudecken als mit einzelnen Stützstellen, es ist nur rechenintensiven als die Interpolation zwischen den einzelnen Stützstellen und auch ACES baut auf reverse Funktionen der IDTs auf, lediglich die Monitorwege (OCES) werden (können) in einem ACES Workflow mit LUTs bedient (werden)
Gerade das ist der Vorteil von ACES, dass der Kamerahersteller in der OETF seine internen Funktionen einbetten kann und diese, anders als bei RAW nicht preisgeben muss und das Signal in der RRT exakt rekonstruiert wird und nicht mit irgendwelchen LUTs, mehr oder weniger genau, geschätzt wird.
Die (Nutz-) Signalwege setzen ausnahmslos auf Funktionen auf.
Ansonsten deck doch mal solche unteren Kurvenverläufe (Grafik) präzise mit wenigen Stützstellen ab.
Kann man im Amateurbereich natürlich (mit LUTs) versuchen, darf sich dann aber eben über die dabei entstehenden Fehler nicht wundern.
Das ist vermutlich nur nötig, wenn man ein bestehendes Vodeosignal, also keine IDT hat und das Signal nachträglich (ohne Kenntnis einer OETF) irgendwie nach ACES überführen muss.
Das ist aber der Bastelweg und hat nichts mit dem eigentlichen ACES Workflow zu tun.
Antwort von mash_gh4:
Jede Funktion ist durch die entsprechende reverse Funktion präziser abzudecken als mit einzelnen Stützstellen,...
wenn die tables ausreichend bemessen sind (defaultmäßig werden im OpenColorIO 4096 werte für 1D LUTs benutzt), wird da überhaupt nichts interpoliert, sonder das ausgangsmaterial in seinen klar vorgegeben abstufungen bzw. auflösungsgrenzen 1:1 übersetzt!
wie gesagt: das passiert in genau dieser weise auch in der ACES referenz-implementation...
Antwort von WoWu:
Würde man jeden einzelnen Punkt eines Signals mit Werten belegen, so hätte eine 3D LUT für 10 Bit, also 1024 Punkte, eine Grösse von 1.073.741.824 Werten.
Selbst bei 8 Bit hätte eine 3D LUT 16.777.216 Einträge.
Jeder Eintrag enthält einen RGB-Tripel, so dass diese LUT ziemlich groß wäre.
Glücklicherweise ist eine 3D-LUT dieser Größe für die meisten Anwendungen nicht notwendig, und in der Praxis in der Regel viel kleiner.
Damit diese Datenmenge nicht zu gross wird, verwendet man nur eine begrenzte Zahl an Stützstellen, zwischen denen interpoliert wird.
Die Zahl der Stützstellen variiert zwischen 17 (pro Farbe) für Vorschauzwecke und 64 für einen Renderingansatz, ohne großen Anspruch.
Du hast also nur die Wahl, zwischen einer gigantischen Wertemenge, oder einer Interpolation, mit den entsprechenden Schwächen.
Es trifft nicht zu, was Du sagst, es sei denn, Dein Signal besteht nur aus einer einfarbigen Fläche oder aus einem geringen Qualitätsanspruch.
Nur hilft das jetzt dem TO auch nicht weiter, weil er den unteren Bereich seiner Übertragungsfunktionen nicht mit seiner LUT bearbeitet bekommt, was eben nichts Ungewöhnliches ist.
Antwort von mash_gh4:
ich hab hier ganz bewusst von 1D LUTs gesprochen, die in diesem zusammenhang sinnvollerweise genutzt werden...
um die diversen LOG varianten präzise umzurechnen, ist das vollkommen ausreichend.
Antwort von WoWu:
"ausreichen" sagt bereits alles .... und "bestimmte Anwendungen" ebenfalls.
Eine LUT ist nur ein sehr begrenzter Ersatz für eine korrekte Reversefunktion.
Aber wenn Dir LUTs reichen ... prima, immer eine Frage des Qualitätsanspruchs.
Offenbar reicht es aber für den TO nicht, sonst würde er das Verhalten bei unteren Werten nicht monieren.
Antwort von Huitzilopochtli:
Vielen Dank für die Antworten, wenn ich auch erstmal nicht allzu viel verstanden habe. Ein professioneller Colorist bin ich nicht, trotzdem möchte ich ein möglichst gutes Bild produzieren.
Wenn ich das richtig verstanden habe, dann wird im "professionellen" Bereich nicht mihilfe von LUTs für die Transformation von Log-Material gearbeitet. Das bezieht sich aber nur auf professionelles grading, oder? Immerhin wurde LUTcalc ja von Ben Turley, einem professionellen Kameramann entwickelt, und von einigen im professionellen Bereich verwendet (z.B. Art Adams, dessen Name angeblich für das A bei LC709A steht
http://www.provideocoalition.com/hack-a ... -f-cameras ) . Auch bei Liftgammagain wird LUTcalc durchaus positiv diskutiert.
Wie wird denn im professionellen Bereich Log-Material verarbeitet, wenn nicht mithilfe von LUTs?
Antwort von WoWu:
Professionelle Software, wie sie beispielsweise von ARRI angeboten wird, rechnet LUTs, die z.B. im Kameraweg zur Sichtung eingesetzt wurden (z.B. Day for night) in reverse Funktionen um, die anschließend für Gradingzwecke eingesetzt werden.
Es kommt dabei darauf an, die gesamte Übertragungsfunktionen (lückenlos) im Grading zu rekonstruieren und nicht nur anhand von Stützstellen mehr oder weniger viele Punkte der Kurve zu rekonstruieren.
Das führt zu den besagten Ungenauigkeiten, die manchmal nicht sofort auffallen, speziell in dunklen Bereichen, aber aufgrund der beschriebenen Kurvenbeschaffenheit manchmal zu solchen Effekten führen.
Für einige Applikationen mag das nicht besonders relevant sein, es bleiben aber ungenauigkeiten.
Hinzu kommt, dass LUTs in einigen floatingPoint Berechnungen ohnehin nicht angewandt werden können, weil bestimmte Berechnungen außerhalb des standard Schwarz Weiß Bereiches gar nicht abgedeckt werden.
Auch der Einsatz von 1DLUTs gegenüber 3DLUTs dürfte davon abhängen, ob man eine Gammakorrektur voraussetzt oder nicht. Da ist man in der Wahl also auch nicht so ganz frei ... oder muss seinen Workflow entsprechend angelegt haben.
Geht man also mit LUTs anstelle von Reverse Funktionen um, wird man sich im Vorwege über die Limitierungen bewusst sein und abschätzen können, ob die eingeschränkte Performanz im Projekt ausreichend ist.
Oft bieten LUTs zwar aufgrund ihrer geringeren Anforderung an die Rechenleistung der Hardware zwar einen Geschwindigkeitsvorteil, aber oft eben auch keine ausreichenden Ergebnisse bei hohen Qualitätsanforderungen.
Man wird also bei LUT Konstellationen mit solchen Einschränkungen leben müssen und sie im Grading durch zusätzliche Eingriffe ins Signal zu korrigieren haben.
Ob einem dann die genaue Rekonstruktion der Übertragungsfunktion gelingt, hängt vom Signalinhalt -und natürlich seinem Gradingfähigkeiten- ab.
Antwort von Huitzilopochtli:
wo finde ich denn Informationen zu dieser "professionellen" Reverse function? Bei Arri finde ich nur einen LUT-Generator, der imho wie LUTcalc arbeitet, wenn auch die Möglichkeiten bei LUTcalc umfassender sind.
https://www.arri.com/camera/alexa/workf ... or_spaces/
Antwort von Paralkar:
Wie schauts den da aus mit den IDT & ODT, sind das dann Funktionen oder sowas wie ne 3D LUT?
Antwort von mash_gh4:
Wie schauts den da aus mit den IDT & ODT, sind das dann Funktionen oder sowas wie ne 3D LUT?
es ist ziemlich wichtig, dass man 1D und 3D LUTs nicht einfach in einen topf wirft. die haben ganz andere eigenschaften und grenzen.
was die 1D LUTs betrifft, kann man jedenfalls festhalten, dass es einfach nicht genauer wird, wenn man für irgendeine transformation bereits im vorfeld für jeden möglichen ausgangswert (also 1024 möglichkeiten im falle von 10bit footage) auf ein vorbereitetes resultat in einer liste zurückgreifen kann, statt die dafür notwendigen berechnungen jedes mal von grund auf neu durchführen zu müssen. das kostet nur sinnlos rechenzeit, lässt aber die resultate in keiner weise besser/präziser/glaubwürdiger werden.
man darf in diesem zusammenhang auch nicht übersehen, dass die entsprechenden formeln zur umrechnung ja auch nicht vom himmel gefallen sinn, sondern nur eine möglichst sauber nachvollziehbare technsiche beschreibung darstellen. in der praxis, werden aber sowohl kameraseitig beim encodieren, wie auch in der nachbearbeitung bzw. dem decodieren tabellen eingesetzt, auch wenn sich die enthaltenen tabelleninhalte dabei in vielen fällen auf berechnungen stützen, wie sie ursprünglich in IDTs/OTDs als formel in color transformation language (CTL) festgehalten wurden.
das gesagte gilt allerdings nur für derartige 1D transfomationen mit realistischen auflösungsgrenzen (~8, 10 od. 12 bit ausgangsmaterial). 3D LUTs und die damit verbundenen einschränkungen sind wieder eine völlig andere geschichte.
Antwort von Huitzilopochtli:
das problem beim 1d lut ist aber doch, dass die transformierten luma-werte zwar 100% korrekt sind, allerdings nicht an den farbraum gekoppelt sind wodurch das endergebnis (das bild) nicht besser, sondern eher schlechter und schwieriger zu graden ist. damit will ich sagen, dass ein 1d lut auch nicht die lösung ist, oder?
dh: 3d-luts sind zwar nicht die genaueste lösung, aber die beste (im hinblick auf endergebnis und eingesetzte ressourcen), und sind auch die grundlage bei einem professionellen grading.
kann man das so festhalten?
Antwort von mash_gh4:
in der praxis kombiniert man sehr oft 1D transformationen mit anderen weiteren aufbereitungsschritten (bspw. gamut-anpassungen). das können dann 3D LUTs sein, aber auch matrix-transformationen, die in bezug auf eine rechnerisch exakte umsetzung in etwa das gegenstück zu dem darstellen, was WoWu hier so nachdrücklich auch für 1D operationen einfordert. im gegensatz zur anwendung von 1D LUTs mit realistischen auflösungsbegrenzungen, macht es aber in diesem fall tatsächlich einen unterschied im hinblick auf die erzielbare genauigkeit. deshalb haben 3D LUTs keinen besonders guten ruf, dort wo man ihre aufgabe mit andern mitteln exakter bewerkstelligen kann. nur lässt sich dieses vorurteil nicht ohne weiteres auf 1D transformationen übertragen.
im gegenständlichen fall ging's aber ohnehin nur um probleme (Log-linearisierung), die mit den verhältnismäßig einfachen mitteln der ersteren kategorie gelöst werden können.
Antwort von Huitzilopochtli:
im gegenständlichen fall ging's aber ohnehin nur um probleme (Log-linearisierung), die mit den verhältnismäßig einfachen mitteln der ersteren kategorie gelöst werden können.
heißt das ganz konkret, dass ich zunächst die luma-werte meines log-materials mit einem 1d-lut linearisiere und dann den farbraum (in diesem fall s-gamut -> sRGB) mit hilfe eines 3d-luts transcodieren soll?
Antwort von mash_gh4:
heißt das ganz konkret, dass ich zunächst die luma-werte meines log-materials mit einem 1d-lut linearisiere und dann den farbraum (in diesem fall s-gamut -> sRGB) mit hilfe eines 3d-luts transcodieren soll?
ja -- der ablauf klingt korrekt, nur die übersetzung von s-gamut nach sRGB würde ich besser mit einer ganz einfachen color matrix transformation bewerkstelligen (evtl. über den umweg einer XYZ farbdarstellung, wenn man das ganze aus fertig verfügbaren modulen zusammensetzten will -- dann sind's halt zwei derartige matrix transformationen hintereinander)...
das ist auch der weg, den OpenColorIO und viele darauf aufbauende programme (u.a. auch LUTcalc, aber auch z.b. nuke/natron) gewöhnlich einschlagen.
wenn du das ganze aber für die anzeige in einem programm benötigst, dass nur eingeschränkte LUTs erlaubt, könnte evtl. das werkzeug
ociobakelut für dich ganz nützlich sein. aber im grunde leistet LUTcalc ohnehin genau das selbe in etwas benutzerfreundlicherer weise. ;)
Antwort von Huitzilopochtli:
ok, das werde ich mal probieren. muss mir erstmal genauer anschauen, hab bisher noch nie mit einer matrix gearbeitet.
aber mal blöd gefragt: wäre es dann nicht geschickter grundsätzlich slog2 aufnahmen mit eine rec709-farbraum aufzunehmen? dann spart man sich die transformation des farbraums?
Antwort von WoWu:
Ganz grundsätzlich ist es ohnehin das Beste, keine unnötigen Funktionen zu benutzen und seinen Workflow so dicht wie möglich am Ziel anzulehnen.
LOG s und LUTs sind nur ziemlich hipp aber in den meisten Fällen auch ziemlich kontraproduktiv.
Wenn man schon solche Tools einsetzt, sollte man auch exakt wissen, was sie an welcher Stelle bringen und dass man die Ergebisse nicht mit andern, weniger mit Nachteilen behafteten Mäglichkeiten erzielt.
LUTs haben ihren Ursprung nicht in der Qualität sondern in dem Umstand, dass in der Vergangenheit Rechenprozesse auf schwacher Hardware nicht schnell genug auszuführen ware.
Nun haben sich die Rechenkapazitäten verbessert aber die Nachteile der LUTs leider nicht.
Nur keiner möchte so hippe Sachen aufgeben, egal ob das Produkt darunter leidet oder nicht.
Quick & dirty beschreibt das dann wohl am genausten.
Antwort von mash_gh4:
ok, das werde ich mal probieren. muss mir erstmal genauer anschauen, hab bisher noch nie mit einer matrix gearbeitet.
wenn du ein bisserl im netz danach suchst, findst du jede menge einführender literatur zu diesem thema. ist am anfang ein bisserl abschreckend, aber dann doch wieder recht reizvoll, weil es eine derart effektive umsetzung erlaubt bzw. verstehen lässt, wie das in praxis gehandhabt wird.
aber mal blöd gefragt: wäre es dann nicht geschickter grundsätzlich slog2 aufnahmen mit eine rec709-farbraum aufzunehmen? dann spart man sich die transformation des farbraums?
da hast du prinzipiell schon recht. s-gamut und ähnlich großzügig bemessene farbezugsysteme (bspw- v-gamut) kommen leider auch nicht ganz ohne nachteile daher. gerade mit mit beschränkten auflösungen -- also 8bit s-log od. v-log -- wirkt sich das auf die anzahl der tasächlich genutzten tonwerte genauso fatal aus, wie wir das auch vom zusammenstauchen des dynamikumfangs her kennen. trotzdem gibt es auch hier, ganz ähnlich wie beim bemühen, einen möglichst großen dynmamikunfang abzubilden, gute gründe, sich an einem derart groß bemessenen farbumfang zu orientieren. schließlich decken auch die verwendeten sensoren weit größere farbräume als sRGB ab, und bei der wiedergabe kommen auch immer häufiger größere ausgabebezugsräume zur anwendung. so gesehen macht es schon auch sinn, hier von haus aus einen größere wertebereich vorzusehen und in die nachbearbeitung zu retten, statt werte einfach abzuscheiden bzw. auszuklammen.
 |
Antwort von Huitzilopochtli:
Ganz grundsätzlich ist es ohnehin das Beste, keine unnötigen Funktionen zu benutzen und seinen Workflow so dicht wie möglich am Ziel anzulehnen.
LOG s und LUTs sind nur ziemlich hipp aber in den meisten Fällen auch ziemlich kontraproduktiv.
Wenn man schon solche Tools einsetzt, sollte man auch exakt wissen, was sie an welcher Stelle bringen und dass man die Ergebisse nicht mit andern, weniger mit Nachteilen behafteten Mäglichkeiten erzielt.
LUTs haben ihren Ursprung nicht in der Qualität sondern in dem Umstand, dass in der Vergangenheit Rechenprozesse auf schwacher Hardware nicht schnell genug auszuführen ware.
Nun haben sich die Rechenkapazitäten verbessert aber die Nachteile der LUTs leider nicht.
Nur keiner möchte so hippe Sachen aufgeben, egal ob das Produkt darunter leidet oder nicht.
Quick & dirty beschreibt das dann wohl am genausten.
ja, aus diesem grund verwende ich slog nur wenn ich einen hohen dynamic-umfang auch tatsächlich benötige. in den meisten situationen reicht mir das etwas erweiterte cine4 gamma in kombination mit dem pro-farbraum.
aber genau das spricht doch umso mehr dafür, dass ich bei meinen leider begrenzten 8bit-aufnahmen auch slog2 mit dem pro-farbraum kombiniere. dann ist es anschließend einfacher die aufnahmen mit den unterschiedlichen gammas (slog2 und pro-gamut) zu kombinieren, da wenistens schonmal der farbraum der selbe ist?
setze ich das 1d-lut dann auch in die letzte node?
Antwort von mash_gh4:
ja, aus diesem grund verwende ich slog nur wenn ich einen hohen dynamic-umfang auch tatsächlich benötige. in den meisten situationen reicht mir das etwas erweiterte cine4 gamma in kombination mit dem pro-farbraum.
prinzipiell ist das natürlich ein vernünftiges vorgehen. das entscheide problem, dass dem im weg steht, wurzelt allerdings darinm dass sich cine4 gamma, cine-D od. wie auch immer sie sich nennen mögen, leider nicht wirklich gut linearisieren lassen. in dem punkt sind die ganzen log darstellungen, auch wenn sie in anderer hinsicht noch so problematisch sein mögen, deutlich überlegen.
setze ich das 1d-lut dann auch in die letzte node?
ich würde sie eher an den anfang setzten, die bearbeitung im linearen bezugsraum durchführen, und erst zu schluss wieder in den bezugsraum des ausgabegeräts übersetzten... aber, dass ist eine recht moderne herangehensweise, wie sie natürlich manchen traditionsbewussten kollegen nicht gefällt. ;)
Antwort von Huitzilopochtli:
ja, aus diesem grund verwende ich slog nur wenn ich einen hohen dynamic-umfang auch tatsächlich benötige. in den meisten situationen reicht mir das etwas erweiterte cine4 gamma in kombination mit dem pro-farbraum.
prinzipiell ist das natürlich ein vernünftiges vorgehen. das entscheide problem, dass dem im weg steht, wurzelt allerdings darinm dass sich cine4 gamma, cine-D od. wie auch immer sie sich nennen mögen, leider nicht wirklich gut linearisieren lassen. in dem punkt sind die ganzen log darstellungen, auch wenn sie in anderer hinsicht noch so problematisch sein mögen, deutlich überlegen.
aber ich dachte, dass sich die cinegammas wie ein normales rec709-gamma verhalten. Ein bisschen Kontrast und meistens ist das Ergebnis gut. muss ich das überhaupt linearisieren?
setze ich das 1d-lut dann auch in die letzte node?
ich würde sie eher an den anfang setzten, die bearbeitung im linearen bezugsraum durchführen, und erst zum schluss wieder in den bezugsraum des ausgabegeräts übersetzten... aber, dass ist eine recht moderne herangehensweise, wie sie natürlich manchen traditionsbewussten kollegen nicht gefällt. ;)
ok, aber wenn mein bezugsraum ohnehin sRGB (Darstellung im Internet) ist?
Antwort von WoWu:
@Huitzilopochtli
Das sind alles nur so Bits@Pices, aus denen man überhaupt nichts ersehen kann.
Lass uns doch mal durch den gesamten Workflow gehen. Nur so kannst Du Nägel mit Köpfen machen.
Das beginnt bei der Kamera. Mit welchen Signalen kommst Du aus der Kamera heraus und welchen Vorzug versprichst Du Dir von einer LOG Funktion.
Einfach nur "mehr dynamik" ist keine Erklärung, denn mehr Dynamikumfang erzeugen die Kurven auch nicht, also um welchen Dynamibereich (den Du hervorheben willst) geht es Dir genau ?
Das Ziel hatte ich jetzt so verstanden, dass Du auf 709 hinaus willst aber Dir die Kontrastwerte nicht gefallen und Du daher eine Remapping der Werte willst, das Du mit normaler Matrixbearbeitung im Grading nicht erreichst.
Ist das so richtig ?
Antwort von mash_gh4:
ob es tatsächlich sinvoll ist in linearen arbeitsraum zu arbeiten, hängt natürlich ganz davon ab, welche operationen man vornimmt.
wenn man ohnehin nichts gröberes unternimmt od. bspw. nur die längen der aufeinanderfolgenen clips trimmt, ist es natürlich nicht nötig. wenn man dagegen irgendwas anspruchsvolleres an den farben korrigieren will od.ä., ist meist schon sinnvoll, wenn das betreffende program von grund auf sauber konzipiert ist bzw. entsprechend zeitgemäße arbeitsweisen beherrscht. der unterschied springt nicht unbedingt sofort ins auge, hinterlässt aber definitv seine spuren.
Antwort von Axel:
setze ich das 1d-lut dann auch in die letzte node?
ich würde sie eher an den anfang setzten, die bearbeitung im linearen bezugsraum durchführen, und erst zum schluss wieder in den bezugsraum des ausgabegeräts übersetzten... aber, dass ist eine recht moderne herangehensweise, wie sie natürlich manchen traditionsbewussten kollegen nicht gefällt. ;)
ok, aber wenn mein bezugsraum ohnehin sRGB (Darstellung im Internet) ist?
Mal 'ne ganz ketzerische Frage: wozu dient eigentlich eine Log-Korrektur-Lut beim Grading?
Ich habe in Log aufgenommen, um mehr Dynamik zu haben?
Wunderbar, sehe ich ein.
Dann "normalisiere" ich mit der Lut zuoberst - zu was? rec_709?
Was ich dann sehe, sieht aus wie 709. Warum habe ich dann nicht gleich in 709 aufgenommen?
Wegen der Höhen und Tiefeninformationen, die im Log-Video noch zusätzlich gespeichert sind?
Wunderbar, sehe ich ein. Wir haben aber durch die Lut eine sehr zerstörerische Methode angewendet, die zwischen ein paar sample points eine Korrekturkurve interpoliert. Weitaus grober, als es mehrere traditionelle Korrekturen in 32-bit Fließkommagenauigkeit non-destruktiv könnten (wenn man mal davon absieht, dass
jede Korrektur auf der vorherigen aufbaut, also immer Originalwerte verlassen werden, aber die Schritte sind halt transparent und reversibel, gerundet zu integeren Zahlen von - im Fall von 8-bit - 0-255 wird erst ganz am Schluss).
Bei 10-bit-Log fällt es nicht so arg auf, aber bei 8-bit slog, vlog, clog ist doch nach der Lut offensichtlich Schicht im Schacht. Es wird nie wieder besser als eine alternative rec_709 Aufnahme. Im Gegenteil.
Mit händischen Korrekturen mit Lift, Gamma, Gain und Sättigung geht - im Gegensatz zu dem, was ich früher behauptet und ernstlich geglaubt habe - tatsächlich noch ein bisschen.
Antwort von WoWu:
Moin Axel.
Daher auch meine Frage, was genau er im Signal erreichen will.
Da drüber schwebt nämlich sehr häufig nur das Dynamicgespenst, dem die Übertragungsfunktionen häufig gar nicht gerecht wird und eigentlich für das Ziel, das viele erreichen möchten eigentlich kontraproduktiv ist.
Antwort von Huitzilopochtli:
Moin Axel.
Daher auch meine Frage, was genau er im Signal erreichen will.
Da drüber schwebt nämlich sehr häufig nur das Dynamicgespenst, dem die Übertragungsfunktionen häufig gar nicht gerecht wird und eigentlich für das Ziel, das viele erreichen möchten eigentlich kontraproduktiv ist.
na ich sagte doch, dass ich slog2/3 nur dann einsetze, wenn es der dynamikumfang erfordert. klassisches beispiel wären da z.B. Strukturen am Himmel (Wolken etc.) erhalten, ohne hartes clipping.
Antwort von Huitzilopochtli:
wenn du ein bisserl im netz danach suchst, findst du jede menge einführender literatur zu diesem thema. ist am anfang ein bisserl abschreckend, aber dann doch wieder recht reizvoll, weil es eine derart effektive umsetzung erlaubt bzw. verstehen lässt, wie das in praxis gehandhabt wird.
Folgende Werte habe ich gefunden:
S-Gamut3.Cine to REC709
1,6269474097 -0,5401385389 -0,0868088709
-0,1785155271 1,4179409275 -0,2394254003
-0,0444361150 -0,1959199662 1,2403560812
Entschuldige die Frage, aber wie arbeite ich mit einer Matrix in Resolve? Im Netz habe ich dazu nichts gefunden.
Antwort von WoWu:
Moin Axel.
Daher auch meine Frage, was genau er im Signal erreichen will.
Da drüber schwebt nämlich sehr häufig nur das Dynamicgespenst, dem die Übertragungsfunktionen häufig gar nicht gerecht wird und eigentlich für das Ziel, das viele erreichen möchten eigentlich kontraproduktiv ist.
na ich sagte doch, dass ich slog2/3 nur dann einsetze, wenn es der dynamikumfang erfordert. klassisches beispiel wären da z.B. Strukturen am Himmel (Wolken etc.) erhalten, ohne hartes clipping.
Clipping wird aber nicht durch die Übertragungskurve verhinderst, sondern durch die Belichtung und im oberen (hellen) Bereich hast Du in einer linearen Übertragung mehr Werte, also eine höhere Dynamik, als im du klein Bereiche.
Was Du vermutlich willst, ist eine größere Wertemenge im untren (grau/schwarzen) Bereich.
Um nun zu sehen, welche Übertragungsform ausreichend ist, müsstest Du mal sehn, was Dir an Werten im Grading fehlt, wenn Du die Hellen Bereiche richtig belichtest, also ohne clipping und ab wann Dir dann die mittleren und du klein Bereiche "absaufen" und ob die. ich im Grading zu ziehen sind.
Ich gehe mal davon aus, dass Du in 8 Bit arbeitest, wo LOG Funktionen ohnehin eine Gratwanderung sind weil Du im hellen Bereich die Wertemengen verlierst, die Du im grau/schwarzbereich ggf. benötigst und dann flott im Banding landest.
Du wirst also Dein Dignal nochmal etwas genauer betrachten müssen.
Wie gesagt ... LOG Kurve drauf ... und alles wird gut, ... so einfach ist das nicht ... und erst Recht nicht in 8Bit. Da würde ich noch zweimal drüber nachdenken und zunächst einmal in der korrekten Belichtung anfangen.
Denn, wenn was clipped, entsteht das nicht in der Übertragungsfunktionen.
Antwort von Huitzilopochtli:
Moin Axel.
Daher auch meine Frage, was genau er im Signal erreichen will.
Da drüber schwebt nämlich sehr häufig nur das Dynamicgespenst, dem die Übertragungsfunktionen häufig gar nicht gerecht wird und eigentlich für das Ziel, das viele erreichen möchten eigentlich kontraproduktiv ist.
na ich sagte doch, dass ich slog2/3 nur dann einsetze, wenn es der dynamikumfang erfordert. klassisches beispiel wären da z.B. Strukturen am Himmel (Wolken etc.) erhalten, ohne hartes clipping.
Clipping wird aber nicht durch die Übertragungskurve verhinderst, sondern durch die Belichtung und im oberen (hellen) Bereich hast Du in einer linearen Übertragung mehr Werte, also eine höhere Dynamik, als im du klein Bereiche.
Was Du vermutlich willst, ist eine größere Wertemenge im untren (grau/schwarzen) Bereich.
Um nun zu sehen, welche Übertragungsform ausreichend ist, müsstest Du mal sehn, was Dir an Werten im Grading fehlt, wenn Du die Hellen Bereiche richtig belichtest, also ohne clipping und ab wann Dir dann die mittleren und du klein Bereiche "absaufen" und ob die. ich im Grading zu ziehen sind.
Ich gehe mal davon aus, dass Du in 8 Bit arbeitest, wo LOG Funktionen ohnehin eine Gratwanderung sind weil Du im hellen Bereich die Wertemengen verlierst, die Du im grau/schwarzbereich ggf. benötigst und dann flott im Banding landest.
Du wirst also Dein Dignal nochmal etwas genauer betrachten müssen.
Wie gesagt ... LOG Kurve drauf ... und alles wird gut, ... so einfach ist das nicht ... und erst Recht nicht in 8Bit. Da würde ich noch zweimal drüber nachdenken und zunächst einmal in der korrekten Belichtung anfangen.
Denn, wenn was clipped, entsteht das nicht in der Übertragungsfunktionen.
also wenn ich meinen vordergrund "richtig" belichte, dann clippt mein himmel. also ja, ich belichte selbstverständlich so, dass ich so viele informationen wie möglich im himmel einfange, und bekomme durch das slog noch ausreichend informationen in den schatten. das slog und 8 bit risiken in sich birgt, und nicht immer die beste lösung ist, ist mir klar, und hatte ich ja bereits geschrieben. also von wegen slog drauf und gut ist.
Antwort von Huitzilopochtli:
ja, aus diesem grund verwende ich slog nur wenn ich einen hohen dynamic-umfang auch tatsächlich benötige. in den meisten situationen reicht mir das etwas erweiterte cine4 gamma in kombination mit dem pro-farbraum.
prinzipiell ist das natürlich ein vernünftiges vorgehen. das entscheide problem, dass dem im weg steht, wurzelt allerdings darinm dass sich cine4 gamma, cine-D od. wie auch immer sie sich nennen mögen, leider nicht wirklich gut linearisieren lassen. in dem punkt sind die ganzen log darstellungen, auch wenn sie in anderer hinsicht noch so problematisch sein mögen, deutlich überlegen.
setze ich das 1d-lut dann auch in die letzte node?
ich würde sie eher an den anfang setzten, die bearbeitung im linearen bezugsraum durchführen, und erst zu schluss wieder in den bezugsraum des ausgabegeräts übersetzten... aber, dass ist eine recht moderne herangehensweise, wie sie natürlich manchen traditionsbewussten kollegen nicht gefällt. ;)
also mit der folgenden vorgehensweise habe ich die probleme, die ich in meinem ersten post beschrieben hatte, etwas besser im griff.
Mein Ausgangsmaterial: S-Log3/S-Gamut3.cine XAVC UHD 4.2.0 8bit mit 100Mbit
1. Mit Hilfe von LUTcalc erstelle ich ein 1D-Lut:
Rec Gamma:Sony S-Log3
Out Gamma: Varicam V709 (gefällt mir)
Damit keine Informationen verloren gehen wähle ich:
Input Range: Data
Output Range: Data
Hard Clip: Unclipped
2. Dann generiere ich ein Set mit Belichtungskorrekturen von bis zu -2 Blenden, da ich bei S-Log stets versuche ein wenig zu überbelichten.
3. In Davinci Resolve 12.5.4 lege ich das 1D-LUT als Input-LUT in meine erste Node. In den Nodes danach justiere ich das Bild mit Hilfe von Lift, Gamma und Gain.
4. Als letzte Node verwende ich "Color Space Transform" mit den Werten:
Input Color Space: Sony S-Gamut.Cine
Output Color Space: sRGB
Soweit, so gut. Leider habe ich bis jetzt noch nichts dazu gefunden, wie ich eine 3x3 Color Transformation Matrix in Davinci Resolve anlegen kann.
Antwort von Huitzilopochtli:
ok, ich revidiere: die eben beschrieben vorgehensweise funktioniert nicht, wenn man überbelichtetes S-Log-Material hat. sobald ich die color space transformation in die letzte node lege zerhauts mir alles....
Antwort von mash_gh4:
Folgende Werte habe ich gefunden:
S-Gamut3.Cine to REC709
1,6269474097 -0,5401385389 -0,0868088709
-0,1785155271 1,4179409275 -0,2394254003
-0,0444361150 -0,1959199662 1,2403560812
Entschuldige die Frage, aber wie arbeite ich mit einer Matrix in Resolve? Im Netz habe ich dazu nichts gefunden.
es gibt dazu ausgesprochen trickreiche, nicht ganz unkomplizierte lösungen im resolve, die auf lift gamma gain in einem legendären thread diskutiert wurden: ;)
http://www.liftgammagain.com/forum/inde ... olve.2570/
es ist halt deutlich umständlicher als in anderen programmen, wo es für diese ganz elementare operation fertige nodes gibt.
aufpassen musst du natürlich, wie weit eine derartige umrechnung nach rec709/sRGB innerhalb eines programms überhaupt sinn macht? nur in den seltensten fällen ist das bei derartigen programmen heute noch immer der tatsächliche arbeitsbezugsraum!
Antwort von Huitzilopochtli:
Folgende Werte habe ich gefunden:
S-Gamut3.Cine to REC709
1,6269474097 -0,5401385389 -0,0868088709
-0,1785155271 1,4179409275 -0,2394254003
-0,0444361150 -0,1959199662 1,2403560812
Entschuldige die Frage, aber wie arbeite ich mit einer Matrix in Resolve? Im Netz habe ich dazu nichts gefunden.
es gibt dazu ausgesprochen trickreiche, nicht ganz unkomplizierte lösungen im resolve, die auf lift gamma gain in einem legendären thread diskutiert wurden: ;)
http://www.liftgammagain.com/forum/inde ... olve.2570/
es ist halt deutlich umständlicher als in anderen programmen, wo es für diese ganz elementare operation fertige nodes gibt.
hey ja! ich habs endlich. die diskussion bei liftgammagain hatte ich auch gefunden. nur hat er mich nicht sehr weit gebracht. allerdings bin ich dadurch auf ein interessantes matrix-plugin von paul dore gestoßen
https://github.com/baldavenger/Plugin-Downloads
geschwind die werte eingegeben, und siehe da es funktioniert tadellos! wenn man mit den farbwerten nicht weiter hantiert sieht man erstmal nichts... sobald man aber an der farbtemperatur z.B dreht dann sieht man einen klaren unterschied zum 3D-Lut. tipp topp! vielen dank nochmal!
trotzdem würde ich mich gerne mit dem color-matrix und dctl näher beschäftigen. hast du eine literatur-empfehlung, oder eine gute anlaufstelle, wo ich mehr darüber erfahre?
Antwort von Huitzilopochtli:
aufpassen musst du natürlich, wie weit eine derartige umrechnung nach rec709/sRGB innerhalb eines programms überhaupt sinn macht? nur in den seltensten fällen ist das bei derartigen programmen heute noch immer der tatsächliche arbeitsbezugsraum!
wie meinst du das? ich arbeite mit davinci resolve und produziere hauptsächlich für eine darstellung im internet. da ist sRGB doch der richtige farbraum, oder nicht? meine einstellungen in davinci sind:
Color Science: DaVinci YRGB
Timeline Color Space and Gamma: sRGB
Use Mac Display Color Profile for viewers (->31MU97 Werkkalibrierung)
im Monitor habe ich auf "sRGB" gestellt
oder du meinst du ich sollte innerhalb von davinci einen größeren farbraum verwenden, und dann erst mit der letzten node von dem größeren farbraum in sRGB transformieren?
ich arbeite an einem LG 31MU97, der 99,5% des Adobe RGB-Farbraums darstellen kann. in welchem farbraum würdest du innerhalb von resolve arbeiten?
Antwort von mash_gh4:
sich an sRGB für die ausgabe am schirm und evtl. auch als orientierung für den export zu halten (obwohl ich dort rec709/bt1886 mit seiner leicht abweichenden gammakurve für zweckmäßiger bzw. kompatibler halte), ist schon ok. nur muss man es nicht gleich zur grundlage aller weiteren internen verarbeitung erklären.
resolve bietet ganz grundsätzlich verschieden arbeitsmodi, die dieses problem in völlig unterschiedlicher weise handhaben: YRGB, RCM, ACES
während letzteres ziemlich gut dokumentiert und nachvollziehbar ist , sind die beiden proprietären ansätze trotz der umfangreichen handbücher immer mit sehr viel undurchsichtigem hocuspocus verbunden -- oder zumindest ist das mein eindruck.
jedenfalls ist es heute bei derartigen programmen eher üblich, sich nicht so sehr an den begrenzungen von ausgabegeräten zu orientieren (display referred color managment), wie das bei rec709 od. sRGB noch der fall war, sondern die bearbeitung in scene referred arbeitsräumen vorzunehmen und erst in der abschießenden ausgabe und anzeige bspw. nach sRGB zu übersetzten.
bei davinci YRGB, wie du es hier offenbar nutzt, verhält sich das allerdings noch anders. nur ist das leider nicht unbedingt ganz einfach nachvollziehbar od. in transparenter weise modifizierbar. dieser arbeitsmodus ist bzw.
war eher dafür gedacht, korrekturen auf basis des unmittelbaren visuellen feedbacks abzuwickeln. er ist nicht wirklich gut geeignet, kompliziertere umrechnungen, plugins od. color managed workflows zu unterstützen.
Antwort von Huitzilopochtli:
sich an sRGB für die ausgabe am schirm und evtl. auch als orientierung für den export zu halten (obwohl ich dort rec709/bt1886 mit seiner leicht abweichenden gammakurve für zweckmäßiger bzw. kompatibler halte), ist schon ok. nur muss man es nicht gleich zur grundlage aller weiteren internen verarbeitung erklären.
resolve bietet ganz grundsätzlich verschieden arbeitsmodi, die dieses problem in völlig unterschiedlicher weise handhaben: YRGB, RCM, ACES
während letzteres ziemlich gut dokumentiert und nachvollziehbar ist , sind die beiden älteren proprietären ansätze trotz der umfangreichen handbücher immer mit sehr viel undurchsichtigem hocuspocus verbunden -- oder zumindest ist das mein eindruck.
jedenfalls ist es heute bei derartigen programmen eher üblich, sich nicht so sehr an den begrenzungen von ausgabegeräten zu orientieren (display referred color managment), wie das bei rec709 od. sRGB noch der fall war, sondern die bearbeitung in scene referred arbeitsräumen vorzunehmen und erst in der abschießenden ausgabe und anzeige bspw. nach sRGB zu übersetzten.
bei davinci YRGB, wie du es hier offenbar nutzt, verhält sich das allerdings noch anders. nur ist das leider nicht unbedingt ganz einfach nachvollziehbar od. in transparenter weise modifizierbar. dieser arbeitsmodus ist bzw.
war eher dafür gedacht, korrekturen auf basis des unmittelbaren visuellen feedbacks abzuwickeln. er ist nicht wirklich gut geeignet, kompliziertere umrechnungen, plugins od. color managed workflows zu unterstützen.
ja alles sehr interessant. vor allem mit aces werde ich mich noch eingehender beschäftigen. vielen dank nochmal, bisher war farbmanagement immer ein graus.
nur nich eine frage zur 3x3 matrix. würdest du die transformation s-gamut3.cine -> sRGB an den anfang der node-kette stellen (gleich nach dem input-lut zur gammakorrektur) oder an den schluss? ich habe den eindruck, dass die ergebnisse besser werden, wenn sie am schluss steht..
Antwort von mash_gh4:
würdest du die transformation s-gamut3.cine -> sRGB an den anfang der node-kette stellen (gleich nach dem input-lut zur gammakorrektur) oder an den schluss?
ich würde es unmittelbar an die gamma-transformation anschließen, weil es gewissermaßen zusammengehört bzw. einfach mehr sinn macht, wenn man durchgängig mit klar definierten formaten -- also s-log ODER rec709/sRGB/ACES -- arbeitet. ein mischmasch aus verschiedenen konventionen ist nie wirklich hilfreich.
Antwort von Huitzilopochtli:
sich an sRGB für die ausgabe am schirm und evtl. auch als orientierung für den export zu halten (obwohl ich dort rec709/bt1886 mit seiner leicht abweichenden gammakurve für zweckmäßiger bzw. kompatibler halte), ist schon ok. nur muss man es nicht gleich zur grundlage aller weiteren internen verarbeitung erklären.
resolve bietet ganz grundsätzlich verschieden arbeitsmodi, die dieses problem in völlig unterschiedlicher weise handhaben: YRGB, RCM, ACES
während letzteres ziemlich gut dokumentiert und nachvollziehbar ist , sind die beiden proprietären ansätze trotz der umfangreichen handbücher immer mit sehr viel undurchsichtigem hocuspocus verbunden -- oder zumindest ist das mein eindruck.
jedenfalls ist es heute bei derartigen programmen eher üblich, sich nicht so sehr an den begrenzungen von ausgabegeräten zu orientieren (display referred color managment), wie das bei rec709 od. sRGB noch der fall war, sondern die bearbeitung in scene referred arbeitsräumen vorzunehmen und erst in der abschießenden ausgabe und anzeige bspw. nach sRGB zu übersetzten.
bei davinci YRGB, wie du es hier offenbar nutzt, verhält sich das allerdings noch anders. nur ist das leider nicht unbedingt ganz einfach nachvollziehbar od. in transparenter weise modifizierbar. dieser arbeitsmodus ist bzw.
war eher dafür gedacht, korrekturen auf basis des unmittelbaren visuellen feedbacks abzuwickeln. er ist nicht wirklich gut geeignet, kompliziertere umrechnungen, plugins od. color managed workflows zu unterstützen.
Also ich hab jetzt mal versucht ein paar aufnahmen, die ich gut kenne, mit ACES in Davinci Resolve zu bearbeiten. Was mir gut gefällt ist wie unkompliziert ist, da ich mir ja quasi lediglich gedanken machen muss auf welchem ausgabegerät ich es mir ansehen möchte. trotzdem - und vielleicht meinst du das mit nicht ganz perfekt - die waveform-kurve verhält sich für meine begriffe teilweise recht seltsam wenn man an lift, gamma und gain dreht. am besten komme ich im prinzip mit RCM klar. da machen die einstellungen an den besagten reglern genau das was ich mir vorstelle.
aber vielleicht mache ich auch was falsch. daher mal kurz meine vorgehensweise bei der bildkorrektur nachdem ich das signal via RCM linearisiert habe: wenn ich (slog-material) bewusst um 1-2 blenden überbelichtet habe, dann korrigiere ich das zunächst mit dem gain-regler (YRGB, nicht nur Y) bis die Highlights sauber bei 1023 abschließen. Danach setze ich den Schwarzpunkt mit dem Lift-Regler. Dann korrigiere ich nochmal die Mitten mit dem Gamma-Regler und regle die Sättigung mit saturation. zumindest komme ich so grob an ein einigermaßen passables bild. in der letzten node schärfe ich das bild dann ein wenig nach: dazu lege ich ein layer-node an, unten drehe ich das Y-gain weg und im oberen node die sättigung und schärfe dann nur in der oberen node. zu einem guten ergebnis komme ich so nur via d-Lut/3x3-Matrix oder via RCM. Bei ACES passieren da viele verrückte Sachen :) Oder ist bei meiner vorgehensweise was grundlegendes falsch?
Welchen Farbraum/Gamma würdest du als Arbeitsraum empfehlen? Ich habe mal Rec2020(Gamut) und Rec709 (Gamma) verwendet. Wenn ich dich richtig verstanden habe, dann macht es wenig sinn im sRGB-modus zu arbeiten, da ich wertvolle farbinformation quaasi wegwerfe. Meinen Monitor belasse ich im sRGB-Modus und habe das kästchen "use mac display color profile" angeklickt.
Antwort von mash_gh4:
langsam wird's so kompliziert, dass ich mir auch nicht mehr ganz sicher bin, ob ich dir wirklich in allen punkten korrekte antworten geben kann. ;)
was den punkt mit der der funktionsweise der lift-gamma-gain regler betrifft bzw. deren auswirkung auf die waveform, sprichst du natürlich es sehr wichtiges an. das ändert sich tatsächlich je nach verwendeter interner datenrepräsentation. allerdings gibt's dazu im resolve neben dem linearen ACES auch noch ACEScc (=log / film style grading) und das proprietäre "Davinci ACES" (=gamma 2.6 / video style grading), um die handhabung näher an traditionelle bedinungskonventionen heranzuführen.
ich persönlich finde es aber fast wichtiger, dass derartige dinge möglichst anwendungsübergreifend gleich funktionieren, damit auch komplexere abläufe od. projekt-beschreibungen ausgetauscht werden können. aber das ist vielleicht eine zu technokratische herangehensweise. für einen guten coloristen ist es sicher mindestens genauso wichtig, dass sich die reaktionen unter seinen fingern tatsächlich genauso anfühlen, wie er es mühsam erlernt und sich zurechtgelegt hat.
objektiv kannst du die reaktionsweise auf die entsprechenden eingaben jedenfalls am einfachsten studieren, wenn du einen linearen grauverlauf hernimmst, und die veränderungen in der waveform in verschiedenen modi miteinander vergleichst. (also z.b. die belichtungskorrektur, die im linearen modus, wenn ich nicht irre, einer addition in allen kanälen entsprechen sollte, nicht einer multiplikation -- also lift vs. gain)
ich finde übrigens, dass das entspechende farbmanagment im nuke (non-commercial) noch viel sauberer und übersichtlicher gelöst ist. aber natürlich ist das keine wirklich praktikable lösung, um größere projekte zu graden. deshalb muss man sich wohl einfach mit dem begnügen und zurechtfinden, was resolve diesbezüglich zu bieten hat.
ob es wirklich gute gründe gibt, sich an den traditionellen (auslieferungs-)farbräumen und gamma kurven zur internen repräsentation festzuklammen, wie es dir wohl näher zu liegen scheint, getrau ich mich letzlich nicht zu entscheiden. ich persönlich tendiere jedenfalls eher dazu, mich mehr an dem zu orientieren, was näher an einer optimalen rechnerischen umsetzung dran zu sein scheint -- aber in dem punkt kann ich natürlich auch einer fehleinschätzung bzw. technokratischer verblendung aufsitzen. ;)
Antwort von Huitzilopochtli:
langsam wird's so kompliziert, dass ich mir auch nicht mehr ganz sicher bin, ob ich dir wirklich in allen punkten korrekte antworten geben kann. ;)
was den punkt mit der der funktionsweise der lift-gamma-gain regler betrifft bzw. deren auswirkung auf die waveform, sprichst du natürlich es sehr wichtiges an. das ändert sich tatsächlich je nach verwendeter interner datenrepräsentation. allerdings gibt's dazu im resolve neben dem linearen ACES auch noch ACEScc (=log / film style grading) und das proprietäre "Davinci ACES" (=gamma 2.6 / video style grading), um die handhabung näher an traditionelle bedinungskonventionen heranzuführen.
ich persönlich finde es aber fast wichtiger, dass derartige dinge möglichst anwendungsübergreifend gleich funktionieren, damit auch komplexere abläufe od. projekt-beschreibungen ausgetauscht werden können. aber das ist vielleicht eine zu technokratische herangehensweise. für einen guten coloristen ist es sicher mindestens genauso wichtig, dass sich die reaktionen unter seinen fingern tatsächlich genauso anfühlen, wie er es mühsam erlernt und sich zurechtgelegt hat.
objektiv kannst du die reaktionsweise auf die entsprechenden eingaben jedenfalls am einfachsten studieren, wenn du einen linearen grauverlauf hernimmst, und die veränderungen in der waveform in verschiedenen modi miteinander vergleichst. (also z.b. die belichtungskorrektur, die im linearen modus, wenn ich nicht irre, einer addition in allen kanälen entsprechen sollte, nicht einer multiplikation -- also lift vs. gain)
gute idee mit grauverlauf. was genau meinst du mit lift vs gain? michael fischer schreibt in einem beitrag, dass man zur belichtungskorrektur im linearen raum lediglich das gain halbieren bzw verdopppeln muss.
http://www.michaelfischer.at/blog/85-resolve-workflow
ob es wirklich gute gründe gibt, sich an den traditionellen (auslieferungs-)farbräumen und gamma kurven zur internen repräsentation festzuklammen, wie es dir wohl näher zu liegen scheint, getrau ich mich letzlich nicht zu entscheiden. ich persönlich tendiere jedenfalls eher dazu, mich mehr an dem zu orientieren, was näher an einer optimalen rechnerischen umsetzung dran zu sein scheint -- aber in dem punkt kann ich natürlich auch einer fehleinschätzung bzw. technokratischer verblendung aufsitzen. ;)
also das habe ich mittlerweile schon verstanden, den arbeitsraum möglichst groß zu halten, um keine informationen wegzuwerfen. aber wäre es dann nicht sinnvoll nach der linearisierung einfach wieder den s-gamut farbraum als arbeitsraum zu verwenden? robbie carman von mixing light empfiehlt sogar ein paar farbräume durchzuprobieren und zu spüren wie es sich beim graden verhält. https://mixinglight.com/portfolio/davin ... anagement/
Antwort von mash_gh4:
gute idee mit grauverlauf. was genau meinst du mit lift vs gain? michael fischer schreibt in einem beitrag, dass man zur belichtungskorrektur im linearen raum lediglich das gain halbieren bzw verdopppeln muss. http://www.michaelfischer.at/blog/85-resolve-workflow
danke, dass du mitdenkst und mich korrigierst! :)
ich hab da leider wirklich einen blödsinn geschrieben und das unterschiedliche verhalten in log und lin arbeitsräumen genau verkehrt beschrieben! -- dabei kann man sich das doch eh im kopf ausmalen. das "lift vs. gain" hat sich dabei jedenfalls auch auf diese gegenüberstellung zw. addieren und multiplizieren bezogen, wie sie diesen beiden reglern gewöhnlich (aber nicht unbedingt zwingend) zukommt. 'sorry' nocheinmal für diesen irrtum!
Antwort von Huitzilopochtli:
gute idee mit grauverlauf. was genau meinst du mit lift vs gain? michael fischer schreibt in einem beitrag, dass man zur belichtungskorrektur im linearen raum lediglich das gain halbieren bzw verdopppeln muss. http://www.michaelfischer.at/blog/85-resolve-workflow
danke, dass du mitdenkst und mich korrigierst! :)
ich hab da leider wirklich einen blödsinn geschrieben und das unterschiedliche verhalten in log und lin arbeitsräumen genau verkehrt beschrieben! -- dabei kann man sich das doch eh im kopf ausmalen. das "lift vs. gain" hat sich dabei jedenfalls auch auf diese gegenüberstellung zw. addieren und multiplizieren bezogen, wie sie diesen beiden reglern gewöhnlich (aber nicht unbedingt zwingend) zukommt. 'sorry' nocheinmal für diesen irrtum!
ich dachte das gain bezieht sich auf die highlights, also weißpunkt, und lift auf die shadows, respektive schwarzpunkt. das gamma regelt die mitteltöne ohne dass sich schwarz und weißpunkt großartige verändern (in der theorie zumindest. im gehensatz dazu regelt offset die helligkeit ohne den kontrast zu beeinflussen. wie meinst du das mit multiplikation vs addition?
apropos blödsinn, keineswegs! ich finde das alles gerade sehr interessant meine ganze fragerei läuft darauf hinaus, und das sehe ich genauso technokratisch wie du, dass ich die bearbwitungsschritte reproduzier- und dokumentierbar haben möchte. ich finde es höchst unbefriedigend an jeder einstellung mit unterschiedlichen reglern rumzuwurschteln, um dann irgendwann zu einem einigermaßen einheitlichen bild zu kommen.
das fängt eben auch bei der aufnahme an. zwar versuche ich je nach situation das richtige gamma zu verwenden. bisweilen finde ich es aber sehr schwierig, slog und cine4 aufnahmen etwa, einigermaßen gut zu kombinieren. du hattest das ja schon angedeutet, dass cine4 schwierig zu linearisieren ist. wäre es dann sinnvoller, grundsätzlich bei slog zu bleiben und bei geringer dynamik lieber im linearen rec709-gamma aufzunehmen?
Antwort von mash_gh4:
ich dachte das gain bezieht sich auf die highlights, also weißpunkt, und lift auf die shadows, respektive schwarzpunkt. das gamma regelt die mitteltöne ohne dass sich schwarz und weißpunkt großartige verändern (in der theorie zumindest. im gegensatz dazu regelt offset die helligkeit ohne den kontrast zu beeinflussen. wie meinst du das mit multiplikation vs addition?
was diese regler bezogen auf den werteverlauf machen , wird z.b. in diesen ganz einfachen videos demonstriert:
das entsprechende verhalten ist nicht immer ganz so einfach und ohne weiteres auf alle anwendungen übertragbar -- ganz speziell, wenn man in verschiedenen arbeitsräumen arbeitet, wo es dann auch innerhalb der selben anwendung oft stark unterschiedliche ausprägungen annimmt.
dass ich trotzdem das addieren (~offset) und multiplizieren (~slope) ausdrücklich hervorgehoben habe, hat vor allem damit zu tun, wie man solche globalen eingriffe generell beschreiben und zerlegen kann. ASC CDLs fassen diese elementaren operationen in klarer und allgemeingültigerer form zusammen.
trotzdem schafts oft mehr verwirrung und irrtümer, wenn man manche sachen unbeholfen mathematisch zu fassen und zu beschreiben versucht, statt sie einfach so zu praktizieren, wie man das ohnehin ganz selbstverständlich und ohne langes nachdenken ständig macht. :) -- wenn man aber wirklich eine exakte exposure compensation durchführen will, und dafür keine fertiges werkzeug in der anwending findet, kommt man daran fast nicht herum -- also doch wieder einfach addieren oder multiplizieren, ja nachdem, ob die daten in log od. lin vorliegen. ;)
das fängt eben auch bei der aufnahme an. zwar versuche ich je nach situation das richtige gamma zu verwenden. bisweilen finde ich es aber sehr schwierig, slog und cine4 aufnahmen etwa, einigermaßen gut zu kombinieren. du hattest das ja schon angedeutet, dass cine4 schwierig zu linearisieren ist. wäre es dann sinnvoller, grundsätzlich bei slog zu bleiben und bei geringer dynamik lieber im linearen rec709-gamma aufzunehmen?
vermutlich geht es uns da allen ähnlich. es spricht einiges dafür, die bessere tonalität von cine4, cineD od.ä. zu nutzen, gerade wenn man mit den beschränkten aufzeichnungsmöglichkeiten günstigerer kameras sein auslangen finden muss. dabei stößt man aber in puncto farbwiedergabe ständig an grenzen, die vor allem von der gamutkompression in den kameras stammen, wie sie sich auch beim besten willen nachträglich nicht mehr aus derartigem material herausrechnen od. umkehren lassen. in dieser hinsicht sind log aufzeichnungen deutlich überlegen, auch wenn man dabei die bekannten anderen probleme in kauf nehmen muss.
in der praxis würde ich sagen, dass man deshalb dort, wo man ohnedies nur aufnahmen aus einer od. zumindest gleichen kamera/s nutz, oft mit cine4/cineD u.ä. besser fährt, während dort, wo es verschiedene aufnahmequellen aneinander anzupassen gilt od. möglichst korrekte farbwiedergabe im vordergrund steht, an log- und raw-aufzeichnung kaum ein weg vorbei führt.
