Sony A7III S-Log • Farbproblem lösen Thema ist als GELÖST markiert

[mash_gh4]

@FocusPit,
ist nur eine Vermutung, aber Du solltest mal den Gamma Wert sowie Kontrast und Helligkeit an Deinem Moni messen, mir scheint als wäre er so hell, das Du das footage dunkler machst, was dazu führt, das User mit halbwegs kalibriertem Moni/workflow, Deine Screenshot als min 2 Blenden zu dunkel sehen.
Wenn Dein korrekt belichtetes footage also tendenziel zu hell rüberkommt, solltest Du nicht das footage dunkler machen, sondern den Moni! :-)

das ist in der tat ein sehr kluger und hilfreicher einwurf!

wobei es halt im zusammenhang mit resolve, abhängig davon ob die frei oder studio-version genutz wurde bzw. auf welchem system, in der regel nicht ganz einfach ist, das tatsächlich ausreichend in den griff zu bekommen.

[FocusPIT]

Hallo klusterdegenerierung,
es ist ein Eizo ColorEdge, er ist kalibriert mit Spyder 5 Elite. Ich glaube nicht, dass es daran liegt. Eher an den 2.0 höheren Blendeneinstellung durch SLog2, sie erlaubt nicht den Kontrast zu senken ohne das die Tiefen zulaufen.
Gruß FocusPIT

[cantsin]

Das "Problem", das hier im Ausgangsmaterial vorliegt, ist, dass SLog2 mit 2 Blenden überbelichtet wurde, und dass Sonys Standard-LUT bzw. die Standard-Transformationen von SLog2 nach Rec709 dafür nicht ausgelegt sind und deshalb ein ausgebleichtes Bild produzieren. Arri LogC-Transformationen zu verwenden ist IMHO Rumdoktern an den Symptomen - weil LogC (wie auch SLog3) einen anderen Gamma hat, der besser zur Überbelichtung passt, wirkt das Bild mit LogC-nach-Rec709-Umwandlung zwar stimmiger, enthält aber Falschfarben und ist eine Pi-mal-Daumen-Annäherung.

Daher der IMHO bessere Workflow:

Node 1: Belichtung absenken per "Offset"-Korrektur (und sonst nichts), dabei sich visuell bzw. am Waveform-Monitor am Output von Node 2 orientieren.

Node 2: SLog2 -> Rec709-Umwandlung, entweder per LUT oder (IMHO besser:) Color Space Transform.

Node 3: Weißabgleich-Korrektur mit Resolves Kalt-/Warm- und Tint-Reglern im Color-Tab, dabei am besten auf den Waveform-Monitor achten (und das Zusammenschieben der RGB-Kurven)

Node 4: Verbesserung des Kontrast durch Gain-Anhebung, so dass die Spitzlichter mehr an die "Decke" des Waveform-Monitor gehen, Gamma-Korrektur, um danach die Mitten abzusenken.

[Axel]

Aus irgendeinem Grund oder aus irgend mehreren ist das SLog2-Bild ziemlich verkackt. Das SLog3-Bild ist in vieler Hinsicht besser:

Ich habe hier gar nicht viel dran gedreht, nur:
"Exposure" - den Global-Regler auf 11.50 - sodass in der Waveform der ganze Klumpatsch eher in der Mitte liegt, als Kompensation für die Überbelichtung, die richtig war.
Node 2 - Kontrast, WB (ja, sollte man trennen, aber ich war faul):


Problem bei beiden Bildern ist das Banding rechts neben dem Bild. Ich erinnerte mich vage, dass es einen De-Banding-Filter in den Effekten gibt. Das ist eigentlich ein ganz bezaubernder Weichzeichner, dessen Problem ist, dass er neben dem Banding auch Bilddetails verwischt.

Das SLog2-Bild reagiert gar nicht korrekt auf Temp. bzw. Auto-WB (die Pipette). Das Bild ist tatsächlich zu blau, und muss in Richtung Gelb (nicht: Orange) verschoben werden, d.h. minimal minus Blau. Es ist außerdem zu Magenta, also mi-nimal plus Grün. Komisch bleibt es trotzdem.

Mit ACES ist aber auch das SLog2-Bild okay:

Die Gradation sollte in ACES eher mit den HDR-Wheels gemacht werden, das war ein guter Tip von Farbkanal.
P.S.: Sehe gerade erst das Banding unten links.

[mash_gh4]

Node 1: Belichtung absenken per "Offset"-Korrektur (und sonst nichts), dabei sich visuell bzw. am Waveform-Monitor am Output von Node 2 orientieren.

genau!

diese lösung ist zwar streng mathematisch auch nicht ganz perfekt, weil eben alle gebräuchlichen LOG-aufzeichnungsformate sich aus zwei verschiedenen transferkurven zusammensetzten -- einen linearen teil für die ganz duklen bereiche, und log für die mitten und helleren abschnitte --, und durch diese verschiebung die lage dieses übergangs zw. den beiden kurvenabschnitten nicht mehr exakt passt bzw. einige werte in recht dunklen abschnitten nicht mehr ganz genau in der eigentlich vorgesehenen weise zurückübersetzt werden bzw. der aufnahmesituation entsprechen, trotzdem ist das natürlich weit eher vernachlässigbar als die verwendung völlig anderer farbräume bzw. übertragungskurven -- also: IDTs, die für andere kameras bestimmt sind.

ganz korrekt wäre: zuerst mit der ITD die umwandlung in den lin od. log arbeitsfarbraum vorzunehmen, und dort dann die belichtungskorrektur mittels multiplikation od. addition vornehmen...
derartiges geht natürlich nur in ACES od.ä. arbeitsräumen, die eine ausreichend hohen dynamikumfang gleichmäßig abdecken...

aber auch ansonsten finde ich cantsins ansatz hier wirklich vorbildlich und korrekt!

[mash_gh4]

Problem bei beiden Bildern ist das Banding rechts neben dem Bild. Ich erinnerte mich vage, dass es einen De-Banding-Filter in den Effekten gibt. Das ist eigentlich ein ganz bezaubernder Weichzeichner, dessen Problem ist, dass er neben dem Banding auch Bilddetails verwischt.
...
P.S.: Sehe gerade erst das Banding unten links.

ja -- genau diese störungen wirde ich persönlich auch als das unguteste problem in diesem beispiel sehen.

diese form der artefakte ist leider bei ganz vielen log-formaten in 8bit footage zu entdecken und hat seine ursache nur zum teil in den relativ flachen abbildung der betreffenden transferfunktionen. mindestens genauso problematisch sind die deutlich größeren gamut bezüge, wie sie bei diesen formaten genutzt werden. die daraus resultierenden resultierenden im vergleich zu rec.709 sehr geringen werteunterschiede der farbangeben führen dazu, dass sie im zuge der h.264/5 kompression nicht die nötige berücksichtigung finden, weil derartige kompression sich ja unter anderem zu nutze macht, dass unser auge erst ab einem gewissen grad farbunterschiede bewusst wahrnimmt bzw. in unterschiedlichen helligkeits- und frabkontrastkontexten in jeweils verschieden starker weise. es ist also nicht ganz optimal, dass hier ein völlig anders codiertes material mit jenen mechanismen komprimiert wird, die eigentlich nur im falle von rec.709 korrekt der menschlichen wahrnehmung gerecht werden. beim auspacken und zurückübersetzten zeigen sich dann leider sehr oft genau diese effekte, weil eben die entsprechende farbdiffernzierung nicht mehr vorhanden ist bzw. die sprünge und quantisierungschritte extrem ungut verstärkt werden.

[klusterdegenerierung]

Hallo klusterdegenerierung,
es ist ein Eizo ColorEdge, er ist kalibriert mit Spyder 5 Elite. Ich glaube nicht, dass es daran liegt. Eher an den 2.0 höheren Blendeneinstellung durch SLog2, sie erlaubt nicht den Kontrast zu senken ohne das die Tiefen zulaufen.
Gruß FocusPIT

Sorry, aber das ergibt leider so garkeinen Sinn.
Spyder tendieren zudem zu zu hellen Einstellungen.

Wenn man Slog2 2 Blenden drüberbelichtet ist man nicht nur 0,7 Blenden zuweit gegangen, sondern dann ist das Bild so hell, das einem die Tiefen physikalisch gesehen nicht absaufen können, das müßte dann am korrigieren in Resolve liegen.

Warum Dein footage von Dir so dunkel und eingesuppt rüber kommt frage ich mich dennoch.
Als ich es in Resolve hatte in der Art wie ich es hier empfohlen hatte, war es schon fasst passend, da brauchte man so viel nicht dran machen.

Das bei Dir dann solche Screenshots raus kommen zeugen von irgendeinem workflow Fehler.
Es sei denn es ist Dein Geschmack, das ist dann was ganz anderes.

[FocusPIT]

... habe jetzt ein neues Video aufgenommen mit PP9 SLot3 und S-Gamut3 mit ähnlichem Setting. Die Belichtung stimmt. Bin prinzipiell so vorgegangen wie cantsin es vorgeschlagen hat: ohne LUT, mit color space transform. Die Blumen in der vorderen Vase haben sich in der Farbigkeit zu blasseren Farben hin entwickelt. In der Ausgabe kommen sie der Wirklichkeit recht nah. Habe durch Eure Tipps einige Tiefen und auch Höhen erlebt. Danke Euch.
Im Angang ist das neue Video und die zwei Ausgaben:
https://www.magentacloud.de/share/rtqnztby5i
PS:::Das Banding ist fast verschwunden

[klusterdegenerierung]

Ich frag mich immer wofür man colortransformen soll, ist wie ich habe eine weiße Wand und möchte sie weiß haben, dafür muß ich sie aber erst gelb streichen um sie weiß überzumalen, damit sie weiß ist, was sie ja schon vorher war!

Macht mich Kirre sowas! Wenn man doch SGamut Slog3 hat, warum dann nicht RCM input SGamut Slog3, einfacher geht es nun wirklich nicht.

[klusterdegenerierung]

Also bei mir sieht das mit SgamutSlog3 ohne transform so aus.
Das andere Bild ist angehoben und etwas Farbkorrigiert anhand der Parade.

Hattest Du nicht gesagt das footage sei 2 Blenden überbelichtet?
Da kann was nicht stimmen, denn schau mal wo es in der Parade liegt, das sind min 2 Blenden unter normal, es sein denn es war so dunkel, bzw soll so dunkel.

Ich werde aus dem ganzen nicht schlau, auch verstehe ich nicht mehr, worum es eigentlich geht.

[mash_gh4]

Ich frag mich immer wofür man colortransformen soll, ist wie ich habe eine weiße Wand und möchte sie weiß haben, dafür muß ich sie aber erst gelb streichen um sie weiß überzumalen, damit sie weiß ist, was sie ja schon vorher war!

Macht mich Kirre sowas! Wenn man doch SGamut Slog3 hat, warum dann nicht RCM input SGamut Slog3, einfacher geht es nun wirklich nicht.

das problem an diesen einfacheren methoden bzw. arbeitsräumen besteht darin, dass man manche werte nach der ersten umwandlung nicht mehr ohne weiteres zurückholen kann bzw. verliert, und auch das zurechtbiegen sich nur an irgendwelchen technischen eigenheiten der wiedergabegeräte orientiert, statt an den gesetzen der licht- und farbphysik.

ACES und co. bzw. diese etwas aufwendigeren abläufe, die heute als state of the art gelten, transformieren die farbwerte des ausgangsmaterials zuerst einmal in einen arbeitsraum, wo man möglichst exakt die lichtwerte der tatsächlichen aufnahmesituation nachbildet bzw. nach ähnlichen pysikalischen gesetzmäßigkeiten mit licht und farben umgeht (=scene referred), dort nimmt man auch die verschiedenen korrekturen vor, und erst ganz zum schluss wird das ergebnis wieder auf jenen sehr beschränkten abbildungsfarbraum zusammengestaucht, den unsere bildschirme bzw. distributionsmedien verlangen (=display referred).

natürlich ist das umständlicher und auf den ersten blick nicht ganz einleuchtend, aber es hat schon seine vorzüge, weshalb sich das im professionellerem umfeld mittlerweile weitestgehend durchgesetzt hat.

RCM ist ein ziemlich eigenartiger sonderfall, der nicht ohne weiteres einer der beiden arbeitsweisen zugerechnet werden kann, aber gerade darin bzw. in seiner schwer vernünftig nachvollziehbaren arbeitsweise liegt eben auch der grund, warum man von dieser lösung nicht unbedingt überzeugt sein muss.

[klusterdegenerierung]

das problem an diesen einfacheren methoden bzw. arbeitsräumen besteht darin, dass man manche werte nach der ersten umwandlung nicht mehr ohne weiteres zurückholen kann bzw. verliert, und auch das zurechtbiegen sich nur an irgendwelchen technischen eigenheiten der wiedergabegeräte orientiert, statt an den gesetzen der licht- und farbphysik.

ACES und co. bzw. diese etwas aufwendigeren abläufe, die heute als state of the art gelten, transformieren die farbwerte des ausgangsmaterials zuerst einmal in einen arbeitsraum, wo man möglichst exakt die lichtwerte der tatsächlichen aufnahmesituation nachbildet bzw. nach ähnlichen pysikalischen gesetzmäßigkeiten mit licht und farben umgeht (=scene referred), dort nimmt man auch die verschiedenen korrekturen vor, und erst ganz zum schluss wird das ergebnis wieder auf jenen sehr beschränkten abbildungsfarbraum zusammengestaucht, den unsere bildschirme bzw. distributionsmedien verlangen (=display referred).

natürlich ist das umständlicher und auf den ersten blick nicht ganz einleuchtend, aber es hat schon seine vorzüge, weshalb sich das im professionellerem umfeld mittlerweile weitestgehend durchgesetzt hat.

RCM ist ein ziemlich eigenartiger sonderfall, der nicht ohne weiteres einer der beiden arbeitsweisen zugerechnet werden kann, aber gerade darin bzw. in seiner schwer vernünftig nachvollziehbaren arbeitsweise liegt eben auch der grund, warum man von dieser lösung nicht unbedingt überzeugt sein muss.

Ich weiß jetzt nicht genau wovon Du sprichst und ich kann auch nicht für ACES etc. sprechen, aber bei RCM vertust Du dich, denn da kann man alles rückgängig macht, nativ bleiben oder machen wie man will, was ja das besondere an RCM ist.

Es ist ja nichts anderes, als ein kontrolierter Raum, bei dem wenn alles gut läuft, die Farbräume der Cams bzw des Materials erkannt und übernommen werden, was granate ist.
Tut es dies nicht, gibt man einfach seinen Farbraum an und alles ist gut und easy.

Möchte man dies nicht, lässt man es oder schaltet es ab und das Material sieht aus wie immer, auch neues fremdes Material braucht nichts zu befürchten, es verhält sich wie ein Projekt ohne Farbmanagment.

Den Fehler den vielleicht einige machen, die mit Log arbeiten ist, das sie im RCM einen kleineren Ausgangsraum angeben als das log selbst ist, das kann natürlich nur scheitern, deswegen muß hier immer der größte Farbraum als Basis gewählt sein, damit alle anderen vollständig darin Platz finden und das ist wide gamut.

Bei mir wird jedes neue Projekt darin geöffnet und egal was man importiert, alles sieht aus wie immer, auch Rec.
Hat man log und es wird erkannt, boom passt es zur Rec Ansicht wie A auf Eimer, wenn nicht, wählt man den entsprechenden Farbraum für dieses Material, kann man auch im Mediabrowser mit 6000 files im Batch machen, ist ein klick.

Zumindest ich der fasst nur Log filmt, tue mir das andere nicht mehr an, denn die FX6 wird erkannt, transformen brauche ich nicht mehr und eine look lut vom Hersteller passt fasst nie.

[FocusPIT]

... Habe den Farbraum transformiert. Die Farbprofile sehen bei mir anders aus. Hier screenshots:

[mash_gh4]

Ich weiß jetzt nicht genau wovon Du sprichst und ich kann auch nicht für ACES etc. sprechen, aber bei RCM vertust Du dich, denn da kann man alles rückgängig macht, nativ bleiben oder machen wie man will, was ja das besondere an RCM ist.

ich muss zwar zugeben, dass ich, wie vermutlich die meisten, nicht wirklich ganz genau beschreiben kann, wie RCM intern arbeitet, aber ich denke, ich lieg nicht ganz daneben, wenn ich behaupte, dass es urspünglich als verbesserung der klassischen display referred zugangsweise entwickelt wurde, aber eben z.b. die helligkeit durch einen zusätzlich genutzten kanal besser bewahren kann und durch die interne verwendung hoher fließkomma-auflösung dem verlust von werten vorzubeugen versucht. im laufe der zeit wurde das natürlich immer weiter verbessert, so dass es heute ohnehin bereits große ähnlichkeit zu ACES und co. aufweist. allerdings kann man in dieser hinsicht dann auch gleich letzteren weg wählen, der dann ja bekanntlich auch den austausch zw. verschiedenen programmen deutlich erleichtert bzw. überall in ähnlich transparenter weise funktioniert.

ich persönlich arbeite lieber mit werkzeugen, wo ich auch ein wenig genauer verstehe bzw. erklären kann, wie und warum einzelne operationen in genau dieser weise arbeiten, aber ich kann natürlich gut verstehen, dass man auf diesen punkt nicht unbedingt so großen wert legen muss und auch mit anderen zugängen glücklich werden kann.

deine recht pragmatische herangehensweise an die dinge weiß ich also durchaus zu schätzen. damit dürftest du in vielen fällen den tatsächlichen praktischen erfordernissen weit besser gerecht werden als es mir möglich ist. ich kann es halt trotzdem nicht ganz lassen, manchmal auch diese theoretischen und technischen hintergründe und erklärungsversuche hier ein wenig auszubreiten.

[cantsin]

... Habe den Farbraum transformiert. Die Farbprofile sehen bei mir anders aus. Hier screenshots:

Warum transformierst Du nach Sony S-Gamut?

[FocusPIT]

... wurde mir so angegeben, was wäre besser?

[mash_gh4]

... wurde mir so angegeben, was wäre besser?

das hängt vom arbeitsfarbraum ab, den du gewählt hast.

womit man dann vermutlich gleich bei der nächsten frage landet. ;)

darum besser gleich sauber durchgängig gemäß ACES best practice.

[FocusPIT]

... Die Aufnahme ist im Farbraum S-Gamut3/S-Gamut. Hier wie richtig erkannt, die nächste Frage: Da mein Arbeitsfarbraum ja der oben genannte Farbraum ist (oder?), sollte ich dann in den Farbraum ACES transformieren?
(-:

[mash_gh4]

... Die Aufnahme ist im Farbraum S-Gamut3/S-Gamut. Hier wie richtig erkannt, die nächste Frage: Da mein Arbeitsfarbraum ja der oben genannte Farbraum ist (oder?), sollte ich dann in den Farbraum ACES transformieren?

du kannst entweder, so wie man es früher gemacht hat, in rec.709 arbeiten, oder aber, was heute eher empfohlen wird, in viel größeren linearen od. math. korrekten log-arbeitsräumen (der unterschied zw. den beiden letzteren besteht hauptsächlich darin, wie werkzeuge reagieren).

ACES nutzt ganz konsequent die zweitere herangehensweise. dort wird wirklich alles eingehende material mittels IDTs (input device transform) gleich beim import in einen sehr großen einheitlichen arbeitsraum übersetzt, und erst ganz zum schluss -- dh. beim exportieren und natürlich auch in der vorschau -- wird es nach rec.709 gewandelt, wie du es für die praktische verwertung der resultate benötigst.

im grunde sind das aber alles dinge, die ohnehin weitestgehend unter der oberfläche verborgen bleiben -- d.h. im praktischen arbeiten ändert sich dadurch nicht viel --, aber man sollte halt die hintergründe trotzdem kennen und berücksichtigen, um an den paar stellen, wo das notwendig ist, passende einstellungen auswählen zu können.

es gibt dazu ohnehin unmengen an video-tutorials, einführenden anleitungen und dokumentationsmaterial, wo das viel besser und genauer erklärt wird als es mir hier möglich ist.

[cantsin]

Um das mal abzukürzen: In Resolves "Color Space Transformation" gibt es für "Output Color Space" und "Output Gamma" jeweils die Einstellung "Use timeline". Diese solltest Du auch wählen, dann wird das SLog-Material in den Arbeitsfarbraum Deines Schnittprojekts übersetzt.

Außerdem würde ich bei "Gamut Mapping" noch "Saturation Compression" auswählen. (Damit verhinderst Du, dass Farben, die ausserhalb des Arbeitsfarbraums liegen, ausbluten.)

[dienstag_01]

... Die Aufnahme ist im Farbraum S-Gamut3/S-Gamut. Hier wie richtig erkannt, die nächste Frage: Da mein Arbeitsfarbraum ja der oben genannte Farbraum ist (oder?), sollte ich dann in den Farbraum ACES transformieren?

du kannst entweder, so wie man es früher gemacht hat, in rec.709 arbeiten, oder aber, was heute eher empfohlen wird, in viel größeren linearen od. math. korrekten log-arbeitsräumen (der unterschied zw. den beiden letzteren besteht hauptsächlich darin, wie werkzeuge reagieren).

ACES nutzt ganz konsequent die zweitere herangehensweise. dort wird wirklich alles eingehende material mittels IDTs (input device transform) gleich beim import in einen sehr großen einheitlichen arbeitsraum übersetzt, und erst ganz zum schluss -- dh. beim exportieren und natürlich auch in der vorschau -- wird es nach rec.709 gewandelt, wie du es für die praktische verwertung der resultate benötigst.

im grunde sind das aber alles dinge, die ohnehin weitestgehend unter der oberfläche verborgen bleiben -- d.h. im praktischen arbeiten ändert sich dadurch nicht viel --, aber man sollte halt die hintergründe trotzdem kennen und berücksichtigen, um an den paar stellen, wo das notwendig ist, passende einstellungen auswählen zu können.

es gibt dazu ohnehin unmengen an video-tutorials, einführenden anleitungen und dokumentationsmaterial, wo das viel besser und genauer erklärt wird als es mir hier möglich ist.

Ich bin mir nicht sicher, aber meiner Kenntnis nach muß man bei Verwendung von Color Managment (egal was) den Farbraum für das Monitoring auf seine Gegebenheiten anpassen. Was wohl meist 709 ist. Und das geht, glaube ich, nur mit einer Decklink-Karte.
Wurde hier ja schon oft diskutiert, vielleicht funktioniert es, wenn man direkt in Arbeitsfarbraum gleich Output-Farbraum wandelt. Also 709.
Aber vielleicht ist auch eine Decklink vorhanden.

[mash_gh4]

Ich bin mir nicht sicher, aber meiner Kenntnis nach muß man bei Verwendung von Color Managment (egal was) den Farbraum für das Monitoring auf seine Gegebenheiten anpassen. Was wohl meist 709 ist. Und das geht, glaube ich, nur mit einer Decklink-Karte.
Wurde hier ja schon oft diskutiert, vielleicht funktioniert es, wenn man direkt in Arbeitsfarbraum gleich Output-Farbraum wandelt. Also 709.
Aber vielleicht ist auch eine Decklink vorhanden.

ich persönlich arbeite mittlerweile praktisch nicht mehr mit resolve, da mir das ding einfach zu oft mit GPU out of memory meldungen um die ohren fliegt, viele dinge dort einfach nicht ausreichend sauber und nachvollziehbar umgesetzt sind, und es sich je nach betriebsystem und freier od. studio-version immer geringfügig anders verhält bzw. unterschiedliche probleme auf lager hat...

mit anderer software (mistika, nuke und div. freien linux-kram) komm ich diesbezüglich besser zurecht, und hab auch das gefühl, dass einem dort manches tatsächlich besser von der hand geht.

aber natürlich kann ich gut verstehen, dass für viele hier resolve weiterhin die erste wahl darstellt, weil es halt deutlich günstiger zu erstehen und vergleichsweise einfach zu bedienen ist.

wenn man sich aber an den gegenwärtig allgemein üblichen handwerklichen gepflogenheiten orientiert, sollte es im grunde ziemlich gleichgültig sein, welche software man bevorzugt bzw. praktisch verwendet.

[cantsin]

Wenn man Resolve in den Standardeinstellungen und ohne Decklink bzw. mit GUI-Monitor betreibt, wird als Arbeitsfarbraum zwar ein Wide Gamut-Farbraum (standardmäßig "Davinci YRGB") gewählt, aber die GUI-Ausgabe automatisch in sRGB gewandelt.

Für @FocusPIT heisst das einfach, dass das sLog-Material in den Arbeitsfarbraum (und zwar simpel per "Use timeline" in Color Space Transform) gewandelt wird, dann stimmt auch das sRGB-Monitoring im Programm.

[dienstag_01]

Wenn man Resolve in den Standardeinstellungen und ohne Decklink bzw. mit GUI-Monitor betreibt, wird als Arbeitsfarbraum zwar ein Wide Gamut-Farbraum (standardmäßig "Davinci YRGB") gewählt, aber die GUI-Ausgabe automatisch in sRGB gewandelt.

Für @FocusPIT heisst das einfach, dass das sLog-Material in den Arbeitsfarbraum (und zwar simpel per "Use timeline" in Color Space Transform) gewandelt wird, dann stimmt auch das sRGB-Monitoring im Programm.

Darauf zielte meine Frage.
Das heisst aber auch kein ACES? Oder trotzdem?

[cantsin]

Darauf zielte meine Frage.
Das heisst aber auch kein ACES? Oder trotzdem?

Macht in der Praxis bei Projekten wie dem hier beschriebenen keinen Unterschied. Man kann in Resolve den Arbeitsfarbraum auf Davinci YRGB oder ACES setzen, trotzdem funktioniert die sRGB-GUI-Vorschau und dann der Export z.B. nach Rec709-Video.

Um mal hier mit einem eigenen Beispiel alle sich hartnäckig haltenden Mythen zu entkräften, dass das nicht geht, oder dass man sich in der Praxis Farbverschiebungen bzw. -inkonsistenzen zwischen GUI-Anzeige, exportiertem Video und Web-Video einhandele (was bei früheren Resolve-Versionen tatsächlich noch der Fall war):

Hier ein Video, das mit einer Panasonic S5 in 10bit-VLog und V-Gamut aufgenommen wurde, dann in Resolve im YRGB-Arbeitsfarbraum per auf eine Timeline-Node gesetztem "Color Space Transform" von VLog und V-Gamut in den Gamma und den Farbraum der Timeline umgewandelt wurde, und dann im Resolve-GUI (auf einem normalen Computermonitor) so aussieht:

screenshot_resolve_gui.jpg

Ausschnittsvergrößerung von Resolves GUI-Player:

screenshot_resolve_gui_player.jpg

Aus Resolve direkt importierter Screengrab (per "Grab Still" im Color-Tab + "Export" aus der Gallery):

resolve-frame_grab-1.1_1.1.1.jpg

Das Projekt wurde als DNxHR HQX 10bit exportiert und dann mit ffmpeg in h264-mp4 umgewandelt. Screengrab des mp4-Videos aus dem mpv-Player:

mpv-screengrab.jpg

Das mp4-Video wurde schließlich auf Vimeo hochgeladen und sieht darin so aus:

screenshot_-_vimeo.jpg

Wer jetzt die Farbwerte auf Pixelebene messen würde, würde wahrscheinlich zwischen allen diesen Screengrabs leichte Abweichungen finden (was aber bei den ganzen Umrechnungen IMHO sowieso nicht vermeidbar ist). Für mich sind die Farben hier von der Resolve-GUI-Anzeige übers exportierte Video bis zum Vimeo-Player konsistent genug.

[mash_gh4]

Macht in der Praxis bei Projekten wie dem hier beschriebenen keinen Unterschied. Man kann in Resolve den Arbeitsfarbraum auf Davinci YRGB oder ACES setzen, trotzdem funktioniert die sRGB-GUI-Vorschau und dann der Export z.B. nach Rec709-Video.

mittlerweile funktioniert das zum glück in praktisch allen besseren programmen ähnlich. im mistika halt mit den display-filtern und im nuke bzw. nuke-studio über die OCIO-settings der monitoring fenster. im wesentlichen läuft's aber überall auf's selbe hinaus, wenn man die richtigen einstellungen für die entsprechende unterstützung aktiviert.

[dienstag_01]

Darauf zielte meine Frage.
Das heisst aber auch kein ACES? Oder trotzdem?

Macht in der Praxis bei Projekten wie dem hier beschriebenen keinen Unterschied. Man kann in Resolve den Arbeitsfarbraum auf Davinci YRGB oder ACES setzen, trotzdem funktioniert die sRGB-GUI-Vorschau und dann der Export z.B. nach Rec709-Video.

Um mal hier mit einem eigenen Beispiel alle sich hartnäckig haltenden Mythen zu entkräften, dass das nicht geht, oder dass man sich in der Praxis Farbverschiebungen bzw. -inkonsistenzen zwischen GUI-Anzeige, exportiertem Video und Web-Video einhandele (was bei früheren Resolve-Versionen tatsächlich noch der Fall war):

Hier ein Video, das mit einer Panasonic S5 in 10bit-VLog und V-Gamut aufgenommen wurde, dann in Resolve im YRGB-Arbeitsfarbraum per auf eine Timeline-Node gesetztem "Color Space Transform" von VLog und V-Gamut in den Gamma und den Farbraum der Timeline umgewandelt wurde, und dann im Resolve-GUI (auf einem normalen Computermonitor) so aussieht:

screenshot_resolve_gui.jpg



Ausschnittsvergrößerung von Resolves GUI-Player:

screenshot_resolve_gui_player.jpg



Aus Resolve direkt importierter Screengrab (per "Grab Still" im Color-Tab + "Export" aus der Gallery):

resolve-frame_grab-1.1_1.1.1.jpg


Das Projekt wurde als DNxHR HQX 10bit exportiert und dann mit ffmpeg in h264-mp4 umgewandelt. Screengrab des mp4-Videos aus dem mpv-Player:

mpv-screengrab.jpg


Das mp4-Video wurde schließlich auf Vimeo hochgeladen und sieht darin so aus:

screenshot_-_vimeo.jpg


Wer jetzt die Farbwerte auf Pixelebene messen würde, würde wahrscheinlich zwischen allen diesen Screengrabs leichte Abweichungen finden (was aber bei den ganzen Umrechnungen IMHO sowieso nicht vermeidbar ist). Für mich sind die Farben hier von der Resolve-GUI-Anzeige übers exportierte Video bis zum Vimeo-Player konsistent genug.

Welche Resolve Version ist das, die 17?
Was ich auch noch für eine potentielle Fehlerquelle halte, sind die immer mehr gebräuchlichen Wide Gamut Monitore. 8bit 709 ohne Farbmanagment auf so einen Monitor ausgegeben, bringt die nächste Unsicherheit.

[cantsin]

Welche Resolve Version ist das, die 17?
Was ich auch noch für eine potentielle Fehlerquelle halte, sind die immer mehr gebräuchlichen Wide Gamut Monitore. 8bit 709 ohne Farbmanagment auf so einen Monitor ausgegeben, bringt die nächste Unsicherheit.

Ja, Resolve 17, auf einem auf sRGB kalibriertem Monitor.

[FocusPIT]

... Habe in "use timline" ausgegeben, was zu einem stark rot-stichigen Bild führte. Habe dann in "ACES" ausgegeben und danach die Sat auf ca. 80 angehoben. Das ergab das bisher beste Ergebnis. Kein Rot-Stich, kein ausblühen der Farben in der vorderen Vase, kein Banding neben der Zeichnung in der weißen Wand. Abbild in DaVinci und im Video gleich. Was zu beseitigen ist sind die Ausblühungen auf den weißen Servietten. Habe sie bewußt gelegt, dachte jedoch nicht, das sie ein Problem werden könnten. Hier die Bilder:

[Axel]

Habe durch Eure Tipps einige Tiefen und auch Höhen erlebt. Danke Euch.

Eine Labsal, einen Frager zu haben, der mit den Bemühungen der Mitforisten gnädig ist und tatsächlich nach Abdriften in die Quantenmechanik nach nur zwei Postings noch aufrichtig interessiert ist.

Ich frag mich immer wofür man colortransformen soll, ist wie ich habe eine weiße Wand und möchte sie weiß haben, dafür muß ich sie aber erst gelb streichen um sie weiß überzumalen, damit sie weiß ist, was sie ja schon vorher war!

Ja, sowas Ähnliches dachte ich eben auch.

Macht mich Kirre sowas! Wenn man doch SGamut Slog3 hat, warum dann nicht RCM input SGamut Slog3, einfacher geht es nun wirklich nicht.

Nun ja, es gab halt schon komische Farben und auch Banding. Zwischenbericht von mir: ich bleibe mit der A7S3 bei ACES, das ist am einfachsten vom Workflow her und unterscheidet sich gefühlt farblich nicht von CST oder RCM.

Aber FocusPIT, du hast die A73. Hast du überhaupt schonmal den Tip von DSLR Shooter ausprobiert, Gamma: SLog2 und Color Mode: ITU 709 MATRIX zu kombinieren? Damit hättest du schonmal eines gemacht, nämlich die Glaubenskriege um die richtige Farbrauminterpretation zu ignorieren. Das ist kein Standardprofil, und wenn ich raten dürfte, handelt es sich um Footage, das kinderleicht von Hand zu graden ist. Kreisch!

Vor Jahren überzeugte mich mein Videokumpel, von der Ur-Pocket (HD) umzusteigen auf A6500 (UHD). Ich hätte lieber die Ursa Mini gehabt, war aber erstens damals nicht so reich und dachte mir schon, puh, Mini oder nicht, das ist ein Klotz!

Jedenfalls, entsetzt, schockiert und verzweifelt über die videomäßige Farbwelt meiner neuen kleinen Kamera, suchte ich nach Lösungen. Ich fand sie recht schnell auf EOSHD. Ein Typ hatte die A7R2 im Profil zu einer Ursa Mini umgemodelt, um sie als B-Cam zu verwenden. Das Profil war beliebt und nannte sich GFilm.Da die A6500 dieselbe Color Science hatte wie die A7R2, machte ich das auch. Das Profil hat die Dynamik von SLog2 (knapp 11 Blenden, was nicht schlecht ist, die Ursa hat auch nur eine mehr). Ich filmte immer mit Gamma Assist, und nach dem WYSIWYG-Prinzip, keine Belichtungsassistenten oder solcher Schrott. Ich gradete immer von Hand, von Farbraumkonvertierungen hörte ich hier zum ersten Mal mit einiger Unlust, als ich mit SLog3 und der A7S3 Ernst machen wollte.

Hier siehst du ein paar gegradete Shots und dahinter dieselben in "rohem" GFilm:


Du selbst kannst GFilm wegen der anderen (besseren!) Color Science der A73 nicht verwenden, ich schätze aber, das DSLR-Shooter-Profil entspricht dem in etwa. In einer 709-Timeline mangelt es an Kontrast und Sättigung, da braucht man keine Gentechnik studiert zu haben, um das zu sehen, und das Bearbeiten macht einfach mehr Spaß. Aber gut, ich bin halt auch Amateur ...

[FocusPIT]

Das hatte ich nicht geschrieben: "Macht mich Kirre sowas! Wenn man doch SGamut Slog3 hat, warum dann nicht RCM input SGamut Slog3, einfacher geht es nun wirklich nicht." Ich weiß nicht wie das in den Post kommt.

Wie auch immer. Ich habe die screenshots zu den Eingaben gepostet damit ihr seht was ich eingestellt habe um Mißverständnisse zu vermeiden. Was ist jetzt noch nicht ok mit den Eingaben?
Habe zwischenzeitlich (transform node 2, gain offset node 3) gain und offset weiter angepaßt. Die weißen Servietten sind nun nicht mehr ausgeblüht, die Wände sind, nun ja fast weiß. (-:

[FocusPIT]

noch zu axel,
es sind so viele tipps, ich kann sie einfach nicht so schnell abarbeiten, aber es kommt noch. Danke weiterhin Euch Allen für Eure Zähigkeit.

[klusterdegenerierung]

Ich bin mir nicht sicher, aber meiner Kenntnis nach muß man bei Verwendung von Color Managment (egal was) den Farbraum für das Monitoring auf seine Gegebenheiten anpassen. Was wohl meist 709 ist. Und das geht, glaube ich, nur mit einer Decklink-Karte.

Definitiv nein, mit Decklink hat das garnichts zu tun.
Man sollte halt nur den Output einstellen, den man auch am Ende benutzt, bzw dargestellt haben möchte und so ist es natürlich sinnvoll wie meißtens der Fall Rec709 zu nehmen.

Der voreingestellte Farbraum sollte möglichst größer sein als das was man importiert, deswegen wide gamut, verändert auch erstmal nix, weil ja die meißten kleiner sind und dann gut darin Platz finden.

Was hier weiter Oben passiert ist mir ehrlich gesagt ein Rätsel, denn erst ist es SGamut, dann weiß man es nicht, dann wird es einem vorgeschlagen, keine Ahnung von wem oder was, aber auf der anderen Seite heißt es ich habe in Slog3 aufgenommen.

Da sollte man dann schon mal ins Profil der Cam gucken, ob da SGmut oder SGamutCine gewählt ist, was schon einen Unterschied macht.
Wiederum seltsam ist, das wie von Zauberhand das zu dunkle Material dort angeblich durch Transform heller wird.

Also entweder wird hier mit Äpfel und Birnen jongliert oder die Linke weiß nicht was die rechte tut.

[klusterdegenerierung]

Das hatte ich nicht geschrieben: "Macht mich Kirre sowas! Wenn man doch SGamut Slog3 hat, warum dann nicht RCM input SGamut Slog3, einfacher geht es nun wirklich nicht." Ich weiß nicht wie das in den Post kommt.

Wie auch immer. Ich habe die screenshots zu den Eingaben gepostet damit ihr seht was ich eingestellt habe um Mißverständnisse zu vermeiden. Was ist jetzt noch nicht ok mit den Eingaben?
Habe zwischenzeitlich (transform node 2, gain offset node 3) gain und offset weiter angepaßt. Die weißen Servietten sind nun nicht mehr ausgeblüht, die Wände sind, nun ja fast weiß. (-:

Ich verstehe eines nicht, ich war davon ausgegangen, das was nicht mit dem Import und der korrekten Darstellung der Farbräume stimmt.
Was dann danach Deine Vorlieben sind, oder ob Du beim aufzeichen Probleme mit dem Weißabgleich hattest, ist ja erstmal zweitrangig

Wichtig ist doch vielmehr, dass das Material korrekt visualisiert wird, damit man eine Grundlage für eine visuell korrekte Korrektur hat.
Hast Du auch mal meinen workflow probiert, oder nur den von cantsin?

[FocusPIT]

Bin weiterhin mit ACES beschäftigt und versuche die Feinabstimmung. Bin dabei nach den Angaben von cantsin vorgegangen:
"Node 1: Belichtung absenken per "Offset"-Korrektur (und sonst nichts), dabei sich visuell bzw. am Waveform-Monitor am Output von Node 2 orientieren.

Node 2: SLog2 -> Rec709-Umwandlung, entweder per LUT oder (IMHO besser:) Color Space Transform.

Node 3: Weißabgleich-Korrektur mit Resolves Kalt-/Warm- und Tint-Reglern im Color-Tab, dabei am besten auf den Waveform-Monitor achten (und das Zusammenschieben der RGB-Kurven)

Node 4: Verbesserung des Kontrast durch Gain-Anhebung, so dass die Spitzlichter mehr an die "Decke" des Waveform-Monitor gehen, Gamma-Korrektur, um danach die Mitten abzusenken."

Für Node 2 gab es folgende Änderung: Output Color Space: ACES, Output Gamma: Gamma 2.4

Hier der screenshot: