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.WoWu hat geschrieben:Du kannst LOG Funktionen nur sehr unzureichend mit LUTs korrigieren, weil die Stützstellen nicht ausreichend sind, um Funktionen komplett umzukehren.
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!WoWu hat geschrieben:Jede Funktion ist durch die entsprechende reverse Funktion präziser abzudecken als mit einzelnen Stützstellen,...
es ist ziemlich wichtig, dass man 1D und 3D LUTs nicht einfach in einen topf wirft. die haben ganz andere eigenschaften und grenzen.Paralkar hat geschrieben:Wie schauts den da aus mit den IDT & ODT, sind das dann Funktionen oder sowas wie ne 3D LUT?
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?mash_gh4 hat geschrieben: 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.
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)...Huitzilopochtli hat geschrieben: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?
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.Huitzilopochtli hat geschrieben:ok, das werde ich mal probieren. muss mir erstmal genauer anschauen, hab bisher noch nie mit einer matrix gearbeitet.
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.Huitzilopochtli hat geschrieben: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?
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.WoWu hat geschrieben: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.
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.Huitzilopochtli hat geschrieben: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.
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. ;)Huitzilopochtli hat geschrieben:setze ich das 1d-lut dann auch in die letzte node?
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?mash_gh4 hat geschrieben: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.Huitzilopochtli hat geschrieben: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.
ok, aber wenn mein bezugsraum ohnehin sRGB (Darstellung im Internet) ist?mash_gh4 hat geschrieben: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. ;)Huitzilopochtli hat geschrieben:setze ich das 1d-lut dann auch in die letzte node?
Huitzilopochtli hat geschrieben:setze ich das 1d-lut dann auch in die letzte node?
mash_gh4 hat geschrieben: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. ;)
Mal 'ne ganz ketzerische Frage: wozu dient eigentlich eine Log-Korrektur-Lut beim Grading?Huitzilopochtli hat geschrieben:ok, aber wenn mein bezugsraum ohnehin sRGB (Darstellung im Internet) 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.WoWu hat geschrieben: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.
Folgende Werte habe ich gefunden:mash_gh4 hat geschrieben:
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.
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.Huitzilopochtli hat geschrieben: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.WoWu hat geschrieben: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.
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.WoWu hat geschrieben: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.Huitzilopochtli hat geschrieben: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.WoWu hat geschrieben: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.
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 mit der folgenden vorgehensweise habe ich die probleme, die ich in meinem ersten post beschrieben hatte, etwas besser im griff.mash_gh4 hat geschrieben: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.Huitzilopochtli hat geschrieben: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.
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. ;)Huitzilopochtli hat geschrieben:setze ich das 1d-lut dann auch in die letzte node?
es gibt dazu ausgesprochen trickreiche, nicht ganz unkomplizierte lösungen im resolve, die auf lift gamma gain in einem legendären thread diskutiert wurden: ;)Huitzilopochtli hat geschrieben: 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.
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ßenmash_gh4 hat geschrieben:es gibt dazu ausgesprochen trickreiche, nicht ganz unkomplizierte lösungen im resolve, die auf lift gamma gain in einem legendären thread diskutiert wurden: ;)Huitzilopochtli hat geschrieben: 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.
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.