Huitzilopochtli
Beiträge: 411

Re: LUTcalc & Resolve: angehobener Schwarzpegel nach Delog-LUT?

Beitrag von Huitzilopochtli »

mash_gh4 hat geschrieben:
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?



mash_gh4
Beiträge: 4716

Re: LUTcalc & Resolve: angehobener Schwarzpegel nach Delog-LUT?

Beitrag 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 [aber leider im resolve nicht immer ganz perfekt funktioniert bzw. der entwicklung des standards oft spürbar nachhinkt], 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.



Huitzilopochtli
Beiträge: 411

Re: LUTcalc & Resolve: angehobener Schwarzpegel nach Delog-LUT?

Beitrag von Huitzilopochtli »

mash_gh4 hat geschrieben: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 [aber leider im resolve nicht immer ganz perfekt funktioniert bzw. der entwicklung des standards oft spürbar nachhinkt], 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..



mash_gh4
Beiträge: 4716

Re: LUTcalc & Resolve: angehobener Schwarzpegel nach Delog-LUT?

Beitrag von mash_gh4 »

Huitzilopochtli hat geschrieben: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.



Huitzilopochtli
Beiträge: 411

Re: LUTcalc & Resolve: angehobener Schwarzpegel nach Delog-LUT?

Beitrag von Huitzilopochtli »

mash_gh4 hat geschrieben: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 [aber leider im resolve nicht immer ganz perfekt funktioniert bzw. der entwicklung des standards oft spürbar nachhinkt], 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.



mash_gh4
Beiträge: 4716

Re: LUTcalc & Resolve: angehobener Schwarzpegel nach Delog-LUT?

Beitrag 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. ;)



Huitzilopochtli
Beiträge: 411

Re: LUTcalc & Resolve: angehobener Schwarzpegel nach Delog-LUT?

Beitrag von Huitzilopochtli »

mash_gh4 hat geschrieben: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/



mash_gh4
Beiträge: 4716

Re: LUTcalc & Resolve: angehobener Schwarzpegel nach Delog-LUT?

Beitrag von mash_gh4 »

Huitzilopochtli hat geschrieben: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!



Huitzilopochtli
Beiträge: 411

Re: LUTcalc & Resolve: angehobener Schwarzpegel nach Delog-LUT?

Beitrag von Huitzilopochtli »

mash_gh4 hat geschrieben:
Huitzilopochtli hat geschrieben: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?



mash_gh4
Beiträge: 4716

Re: LUTcalc & Resolve: angehobener Schwarzpegel nach Delog-LUT?

Beitrag von mash_gh4 »

Huitzilopochtli hat geschrieben: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 [aber auch, wie sehr dieses verhalten voneinander abweichen kann -- obwohl man dann tatsächlich besser nicht von 'lift' sondern 'offset' und 'multiply' statt 'gain' sprechen sollte], 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. ;)
Huitzilopochtli hat geschrieben: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.



 Aktuelle Beiträge [alle Foren]
 
» Interessante Firmware-Updates für Sony Alpha 1, 7S III und 7 IV
von Bergspetzl - Do 22:46
» Nikon stellt NIKKOR Z 28-400mm f/4-8 VR Superzoom-Objektiv vor
von iasi - Do 22:45
» FCPX/Motion, DaVinci/Fusion... Tipps&Tricks
von roki100 - Do 22:27
» Was schaust Du gerade?
von klusterdegenerierung - Do 22:16
» Sondergagen - Wer aufmuckt, wird nicht mehr besetzt
von iasi - Do 22:13
» Panasonic AG-UX90 Phantomspeisung defekt?
von Fabi283 - Do 22:03
» Mac SSD Speed Messung?
von TomStg - Do 21:43
» Neues SIGMA 50mm F1,2 DG DN | Art Objektiv wiegt 745g
von dienstag_01 - Do 21:21
» Deity Sidius TC Sync Software
von pillepalle - Do 19:58
» Red Komodo 6K + Gimbal, Advanced Ring Grip und viel Zubehör
von Sevenz - Do 19:01
» >Der LED Licht Thread<
von freezer - Do 18:53
» Camera Update 8.6: Viele neue Funktionen für Blackmagic Kameras
von slashCAM - Do 17:42
» Tieraufnahmen mit dem MKE600 + H1 Essential rauschen
von Swat - Do 16:06
» 4 Gründe hartes Licht zu nutzen
von ruessel - Do 15:45
» [gelöst] 3.5mm Klinkenstecker Überwurfmutter
von Skeptiker - Do 14:42
» Panasonic S5 - Allgemeine Fragen, Tipps und Tricks, Zeig deine Bilder/Videos usw.
von Darth Schneider - Do 13:49
» -SONY FX- Erfahrungsaustausch
von rush - Do 13:40
» AOC bringt 44.5" OLED-Riesenmonitor mit 98.5% DCI-P3
von MK - Do 12:07
» Adobe führt die neue Funktion "Structure Reference" in Firefly ein
von slashCAM - Do 10:54
» Exhuma - die Südkoreaner können erfolgreiche Filme drehen
von -paleface- - Do 8:46
» Was hörst Du gerade?
von roki100 - Do 0:22
» Sony A9 III im Praxistest - ein echter Überraschungscoup auch für Filmer
von Mantas - Mi 23:27
» Video Pro X stürzt beim Multi Cam Schnitt ab
von MisterX - Mi 21:47
» Uwe Boll: Wie man Filme produziert ohne pleite zu gehen!
von iasi - Mi 19:53
» Nach 7 Jahren mit der OG BMPCC finde ich das Bild noch immer schön.
von Darth Schneider - Mi 18:58
» Verschachtelte Timeline im richtigen Seitenformat
von Clemens Schiesko - Mi 18:43
» Untertitel in FCPX bei vorhandener Textdatei?
von R S K - Mi 18:34
» Deckenlicht mobil abschatten
von Frank Glencairn - Mi 17:31
» LUTs für Canon R6 Mark II
von TomStg - Mi 12:24
» RED versucht User nach Übernahme durch Nikon zu beruhigen
von dienstag_01 - Mi 11:52
» Entfesseltes Storytelling mit der Video-KI Sora?
von Frank Glencairn - Mi 5:54
» Slashcam 2001 - Das Internet vergisst nichts!
von macaw - Di 21:37
» Dehancer Pro - Filmsimulation auf höchstem Niveau
von Frank Glencairn - Di 18:54
» Wie Dune Teil 2 entstand - DoP Greig Fraser und Hans Zimmer im Interview
von iasi - Di 13:32
» 3 Body Problem - so verfilmt man heute Bücher
von stip - Di 8:30