Du arbeitest mit der Gratis-Version von Resolve? (Die Studio-Version kann das Material direkt bearbeiten.)
Eigentlich integriert Resolve beim Color Chart-Matching das in einem Arbeitsschritt. Da wäre allerdings noch die Frage an OSO_1, ob er in dem Color Chart-Matching auch korrekt Panasonic V-Log und V-Gamut für das Ausgangsmaterial eingestellt hat.
Die kostenlose Version kann das Material nicht lesen, die bezahlte hingegen schon.
Ja, macht er...CameraRick hat geschrieben: ↑Do 21 Jul, 2022 15:47
Was ich empfehlen würde: wenn Du einen Colormatch machst, mach den nicht auf V-Log. Der Colorchecker hat 24 Samples, das sind nicht ausreichend um Log vernünftig zu konvertieren. Die Maske vom Colormatch hat ja ein Source-Gamma drin, womöglich macht der also eine Korrektur bevor er Farben verdreht,
Supi. Argumentation wieso ich's anders machen würde steht aber ja auch gleich dahinter. Zumal es (dem Screenshot nach) nur Gamma und nicht den Gamut berücksichtigt.
Genau, mich hätte nur interessiert ob da das exakt gleiche Ergebnis rauskommt wie wenn man vorher umwandelt.
ISO war auf 640 nach 8bit wurde auch nicht konvertiert. Hatte 10bit ProRes HQ gewählt.Bin da ja bei Dir, nur muss der TO noch andere Fehler gemacht haben, als einfach nur den Chart falsch gekippt, wenn er solche Blockartefakte im Material kriegt.
Meine Kandidaten wären falsche ISO (z.B. 3200, knapp unter der zweiten nativen ISO 4000, mit entsprechendem Sensorrauschen), und/oder versehentliches Transcoding zu 8bit-Material.
Das "Problem ist, ich brauche im Studio eine möglichst farbtreue Aufzeichnung, da es sich in dem Fall um Produktvideos handelt, und eine möglichst genaue Wiedergabe der Farben wichtig ist. Daher Colormatch. Oder hat hier jemand eine bessere Idee?Ich finde das Colormatch grob und gewalttätig - es erfordert so viel Korrektur, daß ich es auch gleich von Hand machen kann (oder - noch besser - gleich dem Colormanagement überlassen).
Des weiteren ist das Ganze auch noch ein Magnet für User-Fehler - das Color-Chart nur ein bisschen ins Licht kippen, und das Ergebnis sieht wieder völlg anders aus.
Ich halte es nach wie vor für eine schlechte Idee mit zweifelhaftem Ergebnis (und super Umständlich noch dazu) - aber jeder wie er mag.
Danke für deinen Test, cantsin. Ich hatte bei der S1 die exakt selben Settings wie du, sowohl in der Cam als auch in Resolve.Okay, jetzt wollte ich's mal selbst wissen und habe das hier bewölkte Wetter mal zum Anlass genommen, eben schnell mit meiner Panasonic S5 (mit identischem Sensor, Codec und V-Log-Profil wie die S1 des TOs, ebenfalls in 150 Mbit 10bit LongGop, sowie in Base ISO 640)
Da ich mit DR noch relativ wenig Erfahrung habe, blicke ich da noch nicht weiter durch. Daher erschien mir der Workflow mit dem Colorchecker relativ effizient.Bin zwar auch der Meinung, dass Resolve Color Space Transform mit Tone Mapping und Forward OOTF [bzw. die äquivalente Funktion beim Resolve Color Managed Workflow] der Color Chart-Funktion klar überlegen sind, trotzdem sollte man hier keinen urbanen Mythen Vorschub leisten. (Die Color Chart-Funktion war noch mein Standardmittel zu alten OG Pocket Cinema Camera-Zeiten, als die Standard-LUTs und Bordmittel von Resolve - damals noch Version 14 oder so - noch absolut unbefriedigende Ergebnisse mit dem Material der Kamera erzeugten.)
Wo sich für mich wieder die Frage stellt, was alternativ sinnvoll wäre? Wozu brauchts dann überhaupt die ColorChecker, wenn das nicht richtig funktioniert?Color Match auf LOG Material ist eine ganz schlechte Idee (wie man ja auch sieht)
Ehrlich gesagt würde ich von Color Match insgesamt die Finger lassen.