Was ist der zuverlässigste Broadcast-Safe-Filter?

[SonyTony]

Hallo,
wir produzieren diesmal ohne gesonderte Farbkorrektur für eine Sendeanstalt.
Also werden die Farben im Schnitt korrigiert, was meist ganz vernünftig funktioniert.
(Ob das Sinn macht steht hier nicht zur Debatte)
Ein Problem könnte nur die TA sein, was die illegalen Farben angeht.
In der Vergangenheit waren viele Filter nicht besonders zuverlässig.
Hat jemand damit Erfahrung und weiß, welche Broadcast-Safe-Filter am zuverlässigsten sind?
Ich habe hier Final Cut, Resolve Studio und eine Avid-Lizenz,
alle haben sie Filter, aber vielleicht funktionieren sie unterschiedlich gut.
Oder gibt es einen Drittanbieter, der das Video zuverlässig limitieren kann?

[Jott]

Der in fcp zum Beispiel tut doch genau was er soll? Da kam noch nie Protest. In den anderen professionellen NLEs wird's sicher auch so sein. Was ist deine Sorge? Der gewählte Farbraum muss halt stimmen.

[dosaris]

... ohne gesonderte Farbkorrektur für eine Sendeanstalt.

Ein Problem könnte nur die TA sein, was die illegalen Farben angeht.
In der Vergangenheit waren viele Filter nicht besonders zuverlässig.

was müsst Ihr den abgeben?
rec-709?

Es ist doch kaum möglich, dass man darin ungültige FarbCodes generiert?!?

od rec-2020?

[cantsin]

... ohne gesonderte Farbkorrektur für eine Sendeanstalt.

Ein Problem könnte nur die TA sein, was die illegalen Farben angeht.
In der Vergangenheit waren viele Filter nicht besonders zuverlässig.

was müsst Ihr den abgeben?
rec-709?

Es ist doch kaum möglich, dass man darin ungültige FarbCodes generiert?!?

Du kannst immer noch versehentlich 0-255 statt 16-235 rausrendern.

[dosaris]

... Du kannst immer noch versehentlich 0-255 statt 16-235 rausrendern.

d'accord

Es scheint also ein terminologisches Problem zu sein.

unter 16-235 vestehe ich vorwiegend Amplituden-conformance Y im EBU-range.

mit Farbkorrektur für eine Sendeanstalt sehe ich eher UV im rec-709 bzw rec-2020-Farbraum

[dienstag_01]

was müsst Ihr den abgeben?
rec-709?

Es ist doch kaum möglich, dass man darin ungültige FarbCodes generiert?!?

Du kannst immer noch versehentlich 0-255 statt 16-235 rausrendern.

Ja, aber dann nützt dir auch kein Filter was ;)

[Frank Glencairn]

Warum sollten denn die Limiter/Legalizer in Avid, FinalCut und Resolve verschieden gut funktionieren?
Die machen alle drei genau das selbe, und sind auch gleich zuverlässig.

[SonyTony]

Genau, es geht um illegale Farben im rec709.
Hatte mal vor sehr langer Zeit in eine Produktion in Premiere geschnitten.
Da gab es gemecker in der TA trotz Filter.

[SonyTony]

und ich meinte damit einige illegale luma oder chroma werte, die nicht konform sind. (Also spikes die in der Korrektur kaum sichtbar sind) An anderer stelle hieß es, dass chroma mit den effekten nicht gefiltert werden kann.

[dienstag_01]

Ehrlich gesagt, würde ich mir darum heutzutage überhaupt keine Gedanken mehr machen.
Einmal sind zu hohe Werte ja ursprünglich Spannungswerte gewesen, die spielen aber in der Digitaltechnik keine Rolle mehr. (Da kann also nichts kaputt gehen.)
Was Farben angeht, ich glaube, das schlimmste, was dir passieren kann, ist, dass die anders dargestellt werden (wegen zu hoher Sättigung z.B.). Das dürfte aber schon auf deinem Vorschausystem passieren, wenn du im Ausgabefarbraum arbeitest (du siehst die also gar nicht anders). Und wenn deine Farben sowieso von Video kommen (und nicht aus der Grafik oder so), dürfte da sowieso nichts drüber liegen.
So denke ich.
Ich würde also gar nichts machen oder, wenn ich da bissel überängstlich bin, irgendeinen Filter drauf. Kontrollieren kann man sowieso nicht selber.

[dosaris]

...
Einmal sind zu hohe Werte ja ursprünglich Spannungswerte gewesen, die spielen aber in der Digitaltechnik keine Rolle mehr. (Da kann also nichts kaputt gehen.)

bis auf die Sonderfälle NULL und 255 (bei 8Bit).
Die sind definitiv VERBOTEN, da sie ursprünglich für elementarystream-interne Muxer-Signalisierung definiert waren.
Sowas macht heutzutage wahrscheinlich keine Implemetierung mehr, die Restriktion gilt aber Norm-gemäß mW formal immer noch.

Dennoch sollte dies kein reales Problem darstellen, da der Video-Encoder diese toxischen Werte schon selber verhindert (sollte!)

[andieymi]

Ehrlich gesagt, würde ich mir darum heutzutage überhaupt keine Gedanken mehr machen.
Einmal sind zu hohe Werte ja ursprünglich Spannungswerte gewesen, die spielen aber in der Digitaltechnik keine Rolle mehr. (Da kann also nichts kaputt gehen.)
Was Farben angeht, ich glaube, das schlimmste, was dir passieren kann, ist, dass die anders dargestellt werden (wegen zu hoher Sättigung z.B.). Das dürfte aber schon auf deinem Vorschausystem passieren, wenn du im Ausgabefarbraum arbeitest (du siehst die also gar nicht anders). Und wenn deine Farben sowieso von Video kommen (und nicht aus der Grafik oder so), dürfte da sowieso nichts drüber liegen.
So denke ich.
Ich würde also gar nichts machen oder, wenn ich da bissel überängstlich bin, irgendeinen Filter drauf. Kontrollieren kann man sowieso nicht selber.

Hast Du schon einmal an eine "Sendeanstalt" geliefert? Tatsächlich hast Du mit vielem Recht was Du sagst, die Schlussfolgerung trifft nur nicht zu, wenn man das Material nicht selbst ausschließlich auf Youtube verwenden willst.

Zur Frage nach den Limitern, wenn es eh nur automatisch durch einen Filter gejagt wird (was meist auch so aussieht) funktionieren die alle. Oder woraus speisen sich deine (schlechten?) Erfahrungen was die Zuverlässigkeit angeht?

[dienstag_01]

Ehrlich gesagt, würde ich mir darum heutzutage überhaupt keine Gedanken mehr machen.
Einmal sind zu hohe Werte ja ursprünglich Spannungswerte gewesen, die spielen aber in der Digitaltechnik keine Rolle mehr. (Da kann also nichts kaputt gehen.)
Was Farben angeht, ich glaube, das schlimmste, was dir passieren kann, ist, dass die anders dargestellt werden (wegen zu hoher Sättigung z.B.). Das dürfte aber schon auf deinem Vorschausystem passieren, wenn du im Ausgabefarbraum arbeitest (du siehst die also gar nicht anders). Und wenn deine Farben sowieso von Video kommen (und nicht aus der Grafik oder so), dürfte da sowieso nichts drüber liegen.
So denke ich.
Ich würde also gar nichts machen oder, wenn ich da bissel überängstlich bin, irgendeinen Filter drauf. Kontrollieren kann man sowieso nicht selber.

Hast Du schon einmal an eine "Sendeanstalt" geliefert? Tatsächlich hast Du mit vielem Recht was Du sagst, die Schlussfolgerung trifft nur nicht zu, wenn man das Material nicht selbst ausschließlich auf Youtube verwenden willst.

Zur Frage nach den Limitern, wenn es eh nur automatisch durch einen Filter gejagt wird (was meist auch so aussieht) funktionieren die alle. Oder woraus speisen sich deine (schlechten?) Erfahrungen was die Zuverlässigkeit angeht?

Ich sehe das bestimmt bissel sportlich, aber welche Schlußfolgerung ist es denn, die nicht zutrifft?

(Und ja, ich hab schon mal *geliefert* ;) )

[andieymi]

Ich sehe das bestimmt bissel sportlich, aber welche Schlußfolgerung ist es denn, die nicht zutrifft?

Dass Grafik das einzige ist, was Falschfarben produzieren kann. Das ist heute mit halb-durchdachten HDR-Workflows nicht mehr das einzige ;)

Aber ja - "sinnlos" ist das zu einem gewissen Grad heute eh. Und gleichzeitig gibt es eben Sender, die nach wie vor Sachen zurückwerfen, was Mehraufwand/Kosten bedeutet, wenn dann mal was nicht passt.

[dienstag_01]

Ja, das ist natürlich alles viel komplexer, als ich oben geschrieben hatte ;)

Wenn der Himmel clipped, ich mir das Material aber nicht genau ansehe sondern einfach aus Zeitgründen einen Limiter drauf lege, dann ist das dann zwar technisch korrekt, sieht aber trotzdem beschissen aus. Lässt TV jetzt dieses Material passieren, technisch korrekt, aber hässlich? Das sehen die doch auch?
(Ich hätte es ja etwas runterziehen können, einen RollOff basteln oder was auch immer.)

[andieymi]

technisch korrekt, aber hässlich? Das sehen die doch auch?

Ich glaub visuelle QC (abgesehen von vielleicht inhaltlicher!) macht da schon lange mehr keiner. Das führt ja zu dem Paradoxon, dass völlig veraltete Normen durch automatisierte QC abgefragt werden und die Lösung dafür scheint ein hässlicher Limiter zu sein.

[Pianist]

Hier wurde zwar nach Bild gefragt, aber nur mal zur Sicherheit: Tonmischung nach EBU R 128 ist bekannt?

Matthias

[SonyTony]

Hier wurde zwar nach Bild gefragt, aber nur mal zur Sicherheit: Tonmischung nach EBU R 128 ist bekannt?

Matthias

Ton ist kein Problem - und diesmal gibt es sogar eine Mischung, da auch mit Sprecher vertont wird.

Was die Farben angeht:
Wenn ich intern für Sendeanstalten arbeite, reichten die Filter bisher immer problemlos.
Selbst wenn gar nicht gefiltert wird, dürfte das durchgehen vermute ich.

Aber wenn extern produziert wird, wird halt sehr genau hingesehen.
Einmal gab es einen netten hinweis: Wir hatten ein paar illegale Farbwerte, haben wir aber netterweise schnell korrigiert.
Sie können es aber auch gleich zurückschicken oder dir in Rechnung stellen.
Das wurde damals meines wissens in Premiere gefiltert, ist aber auch schon fast neun Jahre her, darum bin ich nicht mehr sicher.

Ich nehme in Sony Cine-Profilen full range auf und korriegere dann später nach rec709 hin.
Also kann es natürlich illegale werte geben.
Selbst wenn man im rec-farbraum aufnimmt, kann es sich bei korrekturen immer noch in die "illegalen" Bereiche reinverschieben.

Und: Ja, das sieht dann meistens auch ganz gut aus, wenn man es korrigiert, auch ohne Farbkorrektur.

[SonyTony]

Ich bin gerade in der Finalisierung und scanne den gerenderten Film mit QC Tools einmal durch.
Der findet so einige Spikes, also illegale Farbwerte, wenn auch in sehr geringem Umfang.
Und das passiert mit allen Filtern: In AVID, Premiere, Resolve, Final cut und BCC Plugins.
Es lassen also alle die Spikes durch.
QC Tools scant allerdings noch nicht nach ARD_ZDF_HDF01a - das Profil soll aber bald kommen.
Trotzdem machen mir die Spikes sorgen, obwohl die EBU wohl schreibt, dass sie 1% Abweichung genehmigt und wenn ich auf "hide spikes" klicke ist alles grün, es könnte also in Ordnung sein. Es KÖNNTE..
Es gibt ja einige Beiträge im Netz die schreiben, dass z.B. der Adobe broadcast safe filter bei ihnen versagt hat und er Film aus der technischen Abnahme zurückkam. Darum wollte ich noch einmal nach Erfahrungen fragen: Wer kennt sich aus mit den Werten?
Der Film ist farbkorrigiert und sieht auch nach der Anwendung der Filter gut aus, es geht lediglich um die Ausschläge, die nicht gefiltert werden.

[MK]

QC Tools scant allerdings noch nicht nach ARD_ZDF_HDF01a

Die uralte MPEG-2 Kompression von XDCAM HD verändert selbst perfekt limitierte Werte beim Encoding nochmal minimal so dass es zu leichten Abweichungen kommt... das ist normal.

Y hat bei ARD_ZDF_HDF01a nach unten 1% Toleranz und nach oben 3%, RGB Gamut 5%.

Die Messung muss mit Lowpass-Filter nach EBU R103-2000 erfolgen, dann sind die festgestellten Ausreißer in QCTools wahrscheinlich nicht relevant.

[SonyTony]

QC Tools scant allerdings noch nicht nach ARD_ZDF_HDF01a

Die uralte MPEG-2 Kompression von XDCAM HD verändert selbst perfekt limitierte Werte beim Encoding nochmal minimal so dass es zu leichten Abweichungen kommt... das ist normal.

Y hat bei ARD_ZDF_HDF01a nach unten 1% Toleranz und nach oben 3%, RGB Gamut 5%.

Die Messung muss mit Lowpass-Filter nach EBU R103-2000 erfolgen, dann sind die festgestellten Ausreißer in QCTools wahrscheinlich nicht relevant.

Danke!! :) Genau das habe ich vermutet (und gehofft) :)

[SonyTony]

..und gleich die nächste blöde Frage:
Muss RGB nicht auf 16-135 limitiert werden?
Wenn ich auf die Adobe Media Encoder Filtereinstellungen schaue, filtert er selbst mit den strengsten Einstellungen RGB nur auf 0-255. Brauche ich da einen zuätzlichen Filter? Ich exportiere auf FCPX, dessen Broadcast Filter soweit ich weiß nur Luma filtert.

[MK]

..und gleich die nächste blöde Frage:
Muss RGB nicht auf 16-135 limitiert werden?
Wenn ich auf die Adobe Media Encoder Filtereinstellungen schaue, filtert er selbst mit den strengsten Einstellungen RGB nur auf 0-255. Brauche ich da einen zuätzlichen Filter? Ich exportiere auf FCPX, dessen Broadcast Filter soweit ich weiß nur Luma filtert.

Adobe hatte eine Zeit lang in den internen Scopes die Bezeichnungen falsch... da war 0-255 mit IRE 0-100 bezeichnet was falsch ist da IRE 0-100 der 16-235 Bereich innerhalb des 0-255 Bereichs ist (unter 16 Superschwarz und über 235 Superweiß).

Kann daher also sein dass es auch im Videobegrenzer einfach weiterhin falsch bezeichnet ist (auch für RGB) oder die Limitierung dahinter falsch ist... kann ich aus der Ferne nicht beurteilen. Limitiert werden muss eigentlich RGB Gamut 16-235.

Im Zweifelsfall eine Datei mit bewusst illegalen Farben ausgeben (also z.B. ein Testbild nach 0-255 exportieren), limitieren und das Ergebnis auf den Scopes vorher/nachher checken.

[SonyTony]

Danke! Sieht so aus, dass nur Luma korrekt limitiert wird..
Also doch über Avid Media Composer, die das File beim Export dort gleich ARD/ZDF konform?
Sprich: Was Metadaten und so weiter angeht.
Oder muss es danach doch wieder ausserdem über AME gewandelt werden?

[MK]

RGB Parade und RGB Gamut sind zwei unterschiedliche Sachen. So tief bin ich da auch nicht mehr drin, in der Regel kann man Luminanz/Chrominaz und RGB Gamut legalisieren und noch die Kombination aus Luminanz und Chrominanz (was wohl der Premiere-Anzeige YC auf dem Waveform Monitor entspricht).

Ich habe früher mit dem Broadcast Colors Filter in (damals noch Sony) Vegas Pro limitiert. Dort ist Luma und Chroma in den Presets standardmäßig auf 0-100 limitiert und das Compositesignal aus beidem je nach Preset auf -20 bis +120, -20 bis +110 oder -20 bis 100.

Gab nie Beanstandungen.

[TheBubble]

Achtung, es folgen einige etwas technische Ausführungen.

TL;DR: Überlass es Deiner Software, es ist ihre Aufgabe, solche Probleme zu lösen.

Im Grunde ist jede digitale Repräsentation konform zu Rec.709, die für digitale R, G, B und Y Kanäle den Wertebereich von 16-235 nutzt und für CB und CR einen Bereich von 16-240 einhält. Wirklich unzulässig sind jedoch nur 0 und 255, da diese Werte reserviert (und für Signalisierungszwecke vorgesehen) sind. Es ist wichtig im Hinterkopf zu haben, dass die Vorgaben immer im Hinblick auf unkomprimierte Bitmaps zu sehen sind.

Wenn man nun davon ausgeht, dass eine Y, CB, CR Repräsentation genutzt wird, dann müssen Y, CB und CR in dem oben genannten Wertebereich liegen und die daraus zurückgewonnenen R, G und B Werte sollten auch in ihrem Wertebereich liegen. (Tun sie, wenn die Transformation konform umgesetzt wird).

Rein praktisch gesehen wird man sicherstellen, dass zunächst R, G, und B in den Wertebereich passen, dann nach Y, CB, CR wandeln, die Unterabtastung nach Filterung vornehmen (z.B. 4:4:4 nach 4:2:2) und das gefilterte und unterabgetastete Ergebnis ggf. clippen. Bei der Rückwandlung von 4:2:2 nach 4:4:4 könnten in bestimmten Fällen trotzdem Werte außerhalb des erweiterten Bereichs entstehen, daher muss auch bei einer Rückwandlung/beim Abspielen ggf. geclippt werden.

Danach wird es interessant, zumindest wenn als nächstes eine verlustbehaftete Kompression folgt: Hier entstehen immer Artefakte, die nach der Dekompression beispielsweise zu Werten kleiner 16 führen können. Das ist fast unvermeidlich. Daher muss auch jeder Decoder darauf achten in den erlaubten Wertebereich zu clippen, zumindest in einen erweiterten Bereich von 1-254, der die reservierten Werte garantiert auslässt.

Wie Du siehst ist bereits diese Kurzform relativ kompliziert und es ist daher Aufgabe der erzeugenden Software entsprechende Ausgabedateien zu erzeugen. Genau wie es Aufgabe der abspielenden Software ist, dies ebenfalls einzuhalten.

Vernünftige Anforderungen können daher von Dir bzw. Deiner Software eigentlich nur verlangen, dass die Werte in der Regel den Bereich einhalten und nach der Dekompression nur durch Artefakte und Überschwinger einige Werte außerhalb liegen.

[SonyTony]

Danke für die ausführliche Erklärung!
Ist denn die RGB-Parade eine darstellung der tatsächlichen RGB-Werte und die Null-Linie der Wert 16?
Ist es also ein Anzeigefehler oder Kompressionsfehler wenn die Werte für Blau beispielsweise nach der Filterung im negativen Bereich liegen? Oder ist das unerheblich? Sind also Werte niedriger als 16 nicht nur in vereinzelten Ausbrüchen sondern generell zulässig?

[TheBubble]

Negatives Blau (oder Rot oder Grün) gibt es in der Realität nicht, da es kein "negatives Licht" gibt. Im Kontext von sRGB und BT.709 entsprechen daher alle R, G oder B Werte kleiner 0 bzw. 16 bei der Darstellung dem Zustand "Licht ist aus", weniger geht nicht.

(Anmerkung: Es gibt Farbräume bzw. Repräsentationen, die bei der Kodierung von Farben und Helligkeiten negative Werte verwenden/erlauben. Zur Darstellung muss dann aber immer in einen tatsächlich darstellbaren Farbraum gewandelt werden, so wie auch YCbCr zur Darstellung immer in RGB gewandelt werden muss.)

Was BT.709 angeht: Entweder ein Clip bei 16 bei der Erstellung oder spätestens ein Clip bei der Darstellung. Gelegentliches Unterschreiten der 16 kann vor allem im Zusammenspiel mit analogen Komponenten Vorteile haben, auch wenn an sich Werte kleiner 16 nicht vorkommen sollten.

Wenn alles digital ist würde ich eher vor der Komprimierung den Clip machen, auch wenn das zu Knicks in sanften Werteverläufen (z.B. Helligkeitsverläufen) führt.

Was ich noch zu meinem vorherigen Beitrag ergänzen möchte: Solange alle YCbCr Pixel durch Transformation von RGB Pixeln entstanden sind, dann ist eigentlich alles sicher. Wenn man jedoch YCbCr Pixelwerte direkt erzeugt/erfindet dann gibt es YCbCr-Kombinationen, die außerhalb des RGB-Würfels liegen und daher nicht darstellbar/erlaubt sind. Werden dann diese "out of range" RGB Werte per einfachem Clip angepasst, dann gibt es teils unschöne Farbveränderungen. Diese zusätzlichen Farben haben einige Hersteller nutzbar gemacht, allerdings muss von der Kamera bis zum Display eine solche Erweiterung durchgängig unterstützt werden.

Daher würde ich mich darauf konzentrieren solche Farben zu verhindern indem man soweit wie möglich sicherstellt, dass für RGB Pixel der zulässige Wertebereich eingehalten wird.

Wie das Ganze von Software grafisch aufbereitet wird (RGB Parade, usw.) ist leider nahezu beliebig, da alles nur eine Anlehnung an bzw. Nachahmung von früherer analoger Technik geschieht. So ist 16 auch nur Schwarz bei einer 8 Bit Kodierung. Bei 10 Bit, was immer öfter genutzt wird, wäre der Schwellenwert die 64. Über den Sinn solcher "altmodischen" Werkzeuge in der heutigen digitalen Filmwelt kann man unterschiedlicher Ansicht sein. Vermutlich würde z.B. ein Histogramm oft reichen und besser verständlich sein.

Ich denke, dass es Aufgabe der Software sein sollte, all diese Anforderungen für eine korrekte Repräsentation der Bitmaps still im Hintergrund zu beachten, ohne den Benutzer zu involvieren.

99,95 % machen sich vermutlich eh gar keine Gedanken über all dieses.

PS: In Deinen obigen Screenshots ist die vertikale Skala in Prozent, d.h. die 0-Linie entspricht der 16 bei einet 8 Bit Kodierung.