Hallo zusammen,
vielen Dank für die zahlreichen Antworten.
Ich habe von der DR 18 Beta nun auf die aktuelle 18er Version ein Update gemacht.
Absurderweise hat sich das dadurch etwas gebessert, weg sind die Artefakte jedoch immer noch nicht.
Mich wundert es insofern, da ich in einem anderen Studio und ähnlichem Setup, mit einer EOS-R, immer saubere Ergebnisse bekommen habe.
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.
ISO war auf 640 nach 8bit wurde auch nicht konvertiert. Hatte 10bit ProRes HQ gewählt.
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.
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?
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)
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.
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.)
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.
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.
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?
Ich habe jetzt nochmal mit 4:2:0 und 200Mbit/S (10bit) aufgenommen und folgendes festgestellt. Das Material ist nun nativ aus der Cam ohne Konvertierung.
Werde den Hintergrund noch gleichmäßiger leuchten, sobald ich die 3 LED Panels für unten habe. Aktuell leuchte ich nur mit drei Flächen von oben.
Etwas weniger Artefakte. In 5.9K bei 4:2:0 und 10bit mit 200Mbit/s
Bildschirmfoto 2022-07-25 um 13.42.16.png
Woher kommt dieser Peak?
Bildschirmfoto 2022-07-25 um 13.42.25.png
Bildschirmfoto 2022-07-25 um 13.43.11.png
Bildschirmfoto 2022-07-25 um 13.43.24.png
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.