und nachfolgende Fragestellung bzw. Problem: Welche Methoden gibt es, um in einem DCP Colour Banding zu vermeiden (d.h. sichtbare Abstufungen innerhalb eines feinen, auf ein sehr enges Spektrum begrenzten Farbverlaufs)?
Meine zugrundeliegenden TIFFs kommen aus After Effects und sehen einwandfrei aus. Ich habe den betroffenen Bereich mittlerweile bis zu einer Farbtiefe von 32bit und mit Billionen Farben berechnet; darüber hinaus auch mal einen Rauschfilter probiert. Leider tritt das Colour Banding stets nach der Konvertierung in JPEG2000 auf - also praktisch dem letzten Schritt, der gar nicht mehr Bestandteil meiner eigentlichen Nachbearbeitung ist, sondern 'nur' die Wandlung ins Abspielformat.
Ergänzend: Es passiert unter DCPomatic wie auch unter OpenDCP - die ich bislang immer verlässlich verwendet habe und die für meine Zwecke (Enkodierung kurzer Zeichentrickfilme) ausgereicht haben.
Über Hinweise jedweder Art würde ich mich sehr freuen.
Blöde Frage: In welcher Betrachtungsumgebung hast Du das Banding gesehen? DCP-Test im Kino?
Es ist ja ein Unterschied davor da, wenn Du sagst es tritt vor der Konvertierung kein Banding auf? Bist Du in einer von Dir nachvollziehbar color managed 10-Bit Betrachtungsumgebung?
Einige DCP-Software hat darüberhinaus stark eingeschränkte Test-Möglichkeiten.
Danke für Hinweise.
Ja, Verlauf ist computergeneriert.
Ich habe es in diesem Fall leider nicht in einem Kino getestet, sondern lediglich im DCP-o-matic Player; unter Betrachtung am iMac und auf einem Wacom Cintiq. Auf beiden war der Effekt nach Öffnen des DCPs ausmachbar.
Ich füge hier mal Links zum Ausgangs-TIFF und dem daraus generierten .j2c zum Vergleich ein - sofern das für irgendwelche Aufschlüsse gut ist.
Animator hat geschrieben: ↑Mo 31 Jan, 2022 14:16
Danke für Hinweise.
Ja, Verlauf ist computergeneriert.
Ich habe es in diesem Fall leider nicht in einem Kino getestet, sondern lediglich im DCP-o-matic Player; unter Betrachtung am iMac und auf einem Wacom Cintiq. Auf beiden war der Effekt nach Öffnen des DCPs ausmachbar.
Ich füge hier mal Links zum Ausgangs-TIFF und dem daraus generierten .j2c zum Vergleich ein - sofern das für irgendwelche Aufschlüsse gut ist.
Ich denke, die Verläufe müssen in 10 oder vielleicht auch 8bit in der Vorschau funktionieren. Das Umwandeln von 32 oder mehr Bit bringt, glaube ich, nichts.
Artefakte bei Farbverläufen und Jpeg sind ein Klassiker.
Ich habe gerade das TIFF und das J2C in den Media Player Classic Homecinema gezogen - auf meinem Vorschaumonitor ist bei beiden kein Banding zu sehen.
Die JPEG 2000 liegt ja in 12bit vor - von daher wird das auch im Kino super aussehen, keine Sorge.
Ich habe momentan auch stark den Verdacht, dass es von den Programmen abhängt, in denen man es betrachtet.
Den DCP-o-matic Player hätte ich da erst mal als verlässliche Referenz angenommen... fälschlicherweise vermutlich. Ich konnte die .mxf-Datei zwischenzeitlich sogar in Playern öffnen, die auf DCP-Wiedergabe überhaupt nicht ausgelegt sind (VLC und ElMedia) - und in beiden sieht das Bild tatsächlich besser aus als in DCP-o-matic (bzw. es sieht faktisch vollkommen akzeptabel aus).
Animator hat geschrieben: ↑Mo 31 Jan, 2022 17:49
"Bei mir wid Colormetry Bt601 angezeugt, hmm"
Dazu muss ich rückfragen: Heisst das, dass es verkehrt enkodiert wurde?
Nö, das kann nur eine Fehlinfo der Software sein, die Bluboy da benutzt.
Bei mir zeigt die Info ganz korrekt XYZ als Farbraum an - so wie es sein soll für ein DCP.
Es ist faktisch nicht möglich, den X'Y'Z' Farbraum eines DCPs artefaktfrei auf einem normalen Monitor anzuzeigen. Das ist auch nicht das Ziel oder die Aufgabe dieser Player.
Muss man im Kino anschauen.
Von OpenDCP würde ich langsam die Finger lassen, das bringt es nicht mehr.
Rechtliche Notiz: Wir übernehmen keine Verantwortung für den Inhalt der Beiträge
und behalten uns das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
