Der Abschnitt betont, daß lediglich das erhöhen der Bittiefe keine Banding Probleme löst (logisch).
Das andere über die verschiedenen Ergebnisse in den Bittiefen bezieht sich eigentlich auf die Algorithmen und wie sie sich verhalten.
Dinge die Pixel umherschubsen und verschmieren werden in jeder Bittiefe dein Banding zerstören oder minimieren.
Durch höhere Bittiefen hast du aber einfach mehr Raum dafür, der dann bei der Rückwandlung wiederum andere Ergebnisse liefert.
Aber unabhängig davon, Blur und Grain/Dither sind nunmal die bewährtesten Mittel, um Banding etwas zu bendigen.
Und das wollte OP eigentlich nur wissen.
(oh, hehe und ich wandle oft RGB in YUV, um mir das Signal anzusehen, auch wenn ich oft keine Korrekturen in dem Raum durchführe)
Manchmal kann man auch gute Masken und Keys in exotischen Farbräumen erstellen...
(;
enrico perei
motion picture visual effects and stereoscopic 3D
lead, supervision, artistic & consultancy services
Aber unabhängig davon, Blur und Grain/Dither sind nunmal die bewährtesten Mittel, um Banding etwas zu bendigen.
Das mag wohl sein, aber es ist eben eine Fehlerverdeckung.
Mein Ansatz geht ja hin zur Fehlervermeidung.
Und der beginnt mit einem sauberen Workflow und damit, Tools zu benutzen, von denen man sich auch über die negativen Auswirkungen auf die Bildqualität im klaren ist und darüber, dass es immense Unterschiede zwischen einem Computersignal in einer Grafikumgebung und einem Videosignal gibt.
Und deswegen weiss ich nicht, womit dem Ts mehr gedient ist, ihm zu sagen wie man es verdeckt oder wie man es vermeidet.
Ich denke, auf lange Sicht ist das Vermeiden der bessere Ansatz.
Aber das ist, wie immer, eine Frage des Anspruchs an die Bildqualität, die man generieren möchte.
WoWu hat geschrieben:
[...] aber es ist eben eine Fehlerverdeckung.
Mein Ansatz geht ja hin zur Fehlervermeidung.
[...]
Das ist mir klar und ich bin absolut deiner Meinung.
Ich denke, man muß beides sagen und jeder entscheidet dann für sich selbst, wie weit er womit geht.
Fix it in Post ist eh eine Mentalität, die uns zwar unglaublich viel Arbeit (die eigentlich unnötig und vermeidbar ist) einbringt dennoch oft auf Unverständnis und Kopfschütteln stößt.
Wir sind Künstler Jim, keine Mechaniker.
enrico perei
motion picture visual effects and stereoscopic 3D
lead, supervision, artistic & consultancy services
WoWu hat geschrieben:Deine Filter drückt aber weiss von 255 auf 240. Das deutet darauf hin, dass von REC709 nach RGB falsch gewandelt wurde.
Das ist ein Missverständnis.
Stephan82 hat geschrieben:b) Eingabe: Lichter 255 auf 240
Die Erhöhung der Werte in der Eingabe erhöhen den Kontrast (Also Weiss wird weisser). Und die Range 0-255 besagt, dass AE FullRange (für den Computermonitor) arbeitet.
Dort einen Fehler zu suchen ist jedenfalls sinnlos.
Stephan82 hat geschrieben:
Ich weiß nicht ob ich dich richtig verstanden habe. Ausgabe Tiefen und Ausgabe Lichter müssen auf 16 und 235 eingestellt werden, oder? Und bei Eingabe Tiefen/Eingabe Lichter darf ich mich dann nur in dem Bereich zwischen 16 und 235 bewegen?
Nein, tue das bitte nicht! Du würdest die Schwarz- und Weißwerte auf Dauer beschneiden. Im exportierten Video würden die tiefen Schwarzwerte und die hellen Lichter definitiv nicht mehr vorkommen! Das Video würde flach erscheinen. Willst Du das? ;)
Stephan82 hat geschrieben:
Ich habe folgendes gemacht:
1.Clip mit der Cam gefilmt
2.Clip in After Effects importiert (8 Bit Komposition) und in die Timeline gezogen.
3.Einstellungsebene über dem Footage erstellt
4.Schwarz-Weiß-Effekt auf die Einstellungsebene draufgezogen
5.Tonwertkorrektur-Effekt auf die Einstellungsebene draufgezogen. Im Kanal RGB habe ich dann folgende Werte verändert:
a) Eingabe: Tiefen 0 auf 10
b) Eingabe: Lichter 255 auf 240
c) Gamma: 1 auf 0,9
d) Ausgabe: Tiefen unverändert 0
e) Ausgabe: Lichter unverändert 255
Das war alles!!!
Mit der Tonwerkorrektur hast Du bei der EINGABE die Werte verändert. Das hast Du wohl getan, weil Dein Schwarz nicht schwarz genug war und entsprechend Weiß nicht am Anschlag war - laut Histogramm.
Wichtig: Das ist RGB! Nicht YCbCR.
Mit dieser Aktion hast Du dafür gesorgt, dass nun RGB 10 auf RGB 0 abgebildet wird und RGB 240 auf RGB 255. Der Wertebereich ist gespreizt. Die Folgen sind klar. Wie man ihnen sinnvoll begegnen kann, wurde schon erzählt. Da ist nichts falsch, nichts kaputt, und es liegt kein Fehler vor ... ;)
Das exportierte Video wird nach dieser Tonwertkorrektur ein Schwarz bis Y=16 und ein Weiß bis Y=235 enthalten. Da meinen die Werte dann YCbCR, nicht RGB.
Alles gut. - Solange Du nicht in diesem Effekt an den AUSGABE-Werten rumdrehst . ;)
Lass Dich nicht irre machen.
Deine Ausgabewerte sind 16/235 entsprechend REC 709 Einstellung.
Das hast Du schon richtig verstanden.
Schon der Umstand dass Du korrigieren musstest zeigt, das was falsch war.
Und ob man das mit Wortspielereien ..." Schwarz nicht schwarz genug und Weiss am Anschlag"... schön redet oder das Kind beim Namen nennt.
Fehler ist Fehler und Banding entsteht nicht von allein.
Genau, lass Dich nicht irre machen. Der Effekt meint RGB-Werte. Punkt.
Und in After Effects wird der Wertebereich Y 16-235 des Quellvideos breits beim Import IMMER völlig korrekt nach RGB 0-255 übertragen. Alle Arbeiten (Effekte) erfolgen dann in diesem Wertebereich, und zwar vollumfänglich, es sei denn, man arbeitet direkt in YCbCr, das macht der Effekt Tonwertkorrektur aber nicht.
Beim Export wird der Vorgang umgekehrt: Aus RGB 0-255 wird Y 16-235.
Alles gut. Die Verabeitungskette ist vollkommen integer. Du hast zum Schluss ein völlig normales, standardkonformes Video nach REC.709 vorliegen.
Folge: Wenn Du die RGB Werte beschneidest (z. B. mit den AUSGABE-Parametern des Effekts Tonwertkorrektur), wird das Video nicht mehr Y16-235 enthalten, sondern irgendwas um Y22-220 oder so, weil ja jetzt die oberen und unteren RGB-Werte fehlen und die korrespondierenden Y-Werte nicht erzeugt werden können! Tue es nicht ...
Was man übrigens sehr leicht AUSPROBIEREN kann, wenn man After Effects hat ... ;) - ein mehr als hinreichender Beweis.
Das Banding kommt allein aus der Tonwertspreizung, verursacht durch die Verengung der Eingabe-Parameter des Effekts.
Und dafür wurden hier adäquate Lösungsansätze bereits von Praktikern vorgestellt, die After Effects auch sehr gut kennen. Deren Tipps würde ich mir näher ansehen. ;)
Reiner M hat geschrieben:Und in After Effects wird der Wertebereich Y 16-235 des Quellvideos breits beim Import IMMER völlig korrekt nach RGB 0-255 übertragen.
Immer?
Ich sag mal so: Grau ist alle Theorie - die von Reiner M ist bissel grauer ;)
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
dienstag_01 hat geschrieben:
Immer?
Ich sag mal so: Grau ist alle Theorie - die von Reiner M ist bissel grauer ;)
Ist das ein File, dass Du in Avid auf RGB 16-235 getrimmt hast? ;)
Dann zeigt mal den korrespondierenden Y-Wert, gerne anhand einer Luma-Wave... - Aber bitte nicht außerhalb AE / Pr ... - Darüber reden wir hier.
Ja, das passiert immer, Dienstag.
Wenn Du den Farbraum umstellst, oder eine LUT drauflegst die ihn simuliert, oder ein File ein embedded Profile mitbringt, oder ganz schlicht ein Video einbringst, in dem die unteren/oberen RGB-Werte nicht vorkommen ..., ja dann kommen die RGB-Werte auch nicht vor. Super easy.
Ich kann Dir eine Graukarte aufzeichnen. Sie wird in After Effects garantiert keine schwarzen und weißen Werte jenseits 50% nach unten oder oben zeigen. Und? Was beweist das?
Machs doch richtig, entlang der gestellten Frage.
Nimm einfach ein ganz normales REC.709-Video wie es beispielsweise aus einer Cam kommt. Importiere es nach AE ohne Farbraumanpassungen, wie üblich.
Teste es dann aus. Z. B. mit dem Effekt Tonwertkorrektur und dort mit Beschneidung der Ausgabe-Werte (das ist die Frage von Stephan), exportiere das Video und lade es z. B. in Pr. Vergleiche Original und Kopie in der Luma-Wave. Mach das selbe mit Farbraumanpassungen usw. - Dann weißt Du, wie das System funktioniert.
Reiner M hat geschrieben:Machs doch richtig, entlang der gestellten Frage.
Nee, ich weiss ja, was geht und was nicht. Aber ich schau mir gerne mal deine Behauptungen an:
Reiner M hat geschrieben:Und in After Effects wird der Wertebereich Y 16-235 des Quellvideos breits beim Import IMMER völlig korrekt nach RGB 0-255 übertragen.
;)
Immer?
Naja, korrekt sieht es so aus:
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Reiner M hat geschrieben:Das, Dienstag, glaube ich definitiv nicht! ;)
Dafür, dass du mir nicht glaubst, bin ich dir eher dankbar. Stellt mich das doch in eine Reihe mit den Sachbuchautoren, denen du ja auch nicht glaubst ;)
welche Sachbuchautoren meinst Du? Behandeln die Systeme, in denen der bildgebende Bereich in der digitalen Verarbeitung eines Videos nach RGB 0-255 gemappt wird?
Meine Lektüre-Empfehlung für Dich: Die Adobe-Handbücher. ;)
Sorry, Dienstag, neben vielen falschen Dingen, die Du hier erzählst, beweisen die Screenshots, die Du hier eingestellt hast, doch eindeutig, dass Du gar nicht verstehst, was Du eigentlich machst. ;)
Sie passen weder zur Fragestellung noch sind sie geeignet, zu beweisen, dass AE nicht in RGB 0-255 arbeiten würde.
Meine Tipps, das mal sachgerecht und strukturiert auszuprobieren, ohne krampfhaft nach Sonderfällen zu suchen, nimmst Du nicht an und weichst ständig aus.
Mir musst Du nicht beweisen, Dienstag. Es genügt, wenn Du es richtig machst. Denn Du und andere, denen Du hier mit Ratschlägen und Tipps beistehst, werden davon profitieren.
Da Du es nicht ausprobieren willst, und auch offensichtlich nicht beantworten kannst, welche Y-Werte aus Deinen RGB-Werten in Deinen Screenshots resultieren, zeige ich hier eben jedem, den es interessiert, noch einmal, was die Auswirkungen sind, wenn man Videos unsachgemäß, basierend auf falschen Behauptungen, bearbeitet.
Ich würde Dir empfehlen, die folgenden Ausführungen sorgfältig zu lesen! Ich fürchte aber, das wirst Du nicht ... ;)
----------
Beigefügt habe ich ein zip mit drei sehr kurzen Videos. Aufgenommen ist ein Testchart, das für Tests in RGB und YCbCr ausgelegt ist. Die gesamte Grauskala ist drin, sowie alle Farben mit ihren Sättigigungen von 0-100%, die Achsen im Vektorskop darstellen, also die reinen RGB- und YCbCr-Farben.
Video 1 zeigt das Testchart pur. Video 2 ist das Ergebnis nach einer Tonwertkorrektur der Ausgabe-Parameter auf RGB 16-235 - Das ist der Fall, den Stephan wissen möchte. Video 3 ist das Ergebnis des Videos pur, jedoch geladen in Ae in einen Farbraum HDTV (Rec.709)16-235.
Mit diesen Videos kannst Du nun selbst spielen.
Screenshot 1 zeigt die Wirkung in AE. Von oben nach unten: A) Nativ, B) mit Tonwerktkorrektur, C) nach Farbraumumstellung. Beachte bitte die RGB-Werte, die das hellste Pixel ausmachen, sowie das Histogramm, das eindeutig von 0-255 läuft. Die Ergebnisse habe ich jeweils exportiert. Das sind die Beispiel-Videos 1,2,3.
Screenshot 2 zeigt die Resultate in Premiere Pro.
Beachte bitte,
- dass das native Video in der Luma-Wave genau im bildgebenden Bereich zwischen 300mV und 1V liegt, also Y16-235 ist!
- dass die Farben im Vektorskop bis auf die 100%-Markierung laufen.
- dass die Farben in der RGB-Parade von 0 bis 100 (RGB 0.0 - 1.0 bzw. 0-255) laufen!
Nun das Resultat des Effekts Tonwertkorrektur mit Ausgabe-Beschneidung:
- die Luma-Wave läuft nicht mehr von 300mv bis 1V. Der schwärzeste Punkt ist nun nicht mehr Y16, der weißeste nicht mehr Y235! Böse Falle!
- Folgerichtig zeigt die RGB-Parade oben und unten leere Bereiche! Logisch: Die RGB-Werte 0-15 und 236-255 fehlen! Die Wertezellen 0-15 und 236-255 sind aber noch da, nur eben leer. Genauer: Es gibt einfach keine Farbpixel mit diesen Werten!
- Schlimmer noch: Das Vektorskop zeigt eindeutig eine Veränderung der Farbsättigung! Die Farbigkeit des Bildes hat sich reduziert. Alle Farben haben gelitten! Das Bild wird optisch flau, wie man sehen kann. Ein häufiges Problem vieler Anwender, die falsch vorgehen. ;)
Ich kann mir beim besten Willen nicht vorstellen, das das gewünscht ist, weder am PC, noch an einem TV als Ausgabemedium, denn die Ergebnisse, die die Meßgeräte zeigen, werden an einem TV identische Wirkungen erzielen. Probiers einfach aus ... ;)
Die Verarbeitungskette in Premiere Pro und After Effects ist völlig integer. Das meint: REC.709-Video rein -> bearbeiten -> exportieren -> Resultat: REC.709.Video.
Was passiert, wenn man da eingreift, z. B. zusätzlich eine REC.709-16-235-LUT drauflegt, oder den Farbraum auf REC.709(16-235) umstellt (was faktisch dasselbe ist), zeigt das dritte Video:
Schaue Dir einfach Wave, Vektorskop und RGB-Parade an. Dem ist wohl nichts hinzuzufügen.
Derartige Farbraumumstellungen sind Sonderfällen vorbehalten. Die diskutieren wir hier besser nicht ... ;)
Jetzt kannst Du jeden Effekt, auch die Tonwertkorrektur und Farbraumvorgaben, beliebig selbst abmischen, ausprobieren und staunen, was da alles bei raus kommen kann!
Fazit: Wir haben gelernt:
AE und PR arbeiten im RGB-Wertebereich bei 8bit 0-255. Das entspricht in YCbCr dem Wertebereich Y 16-235. Wenn bestimmte RGB-Wertebereiche nicht vorkommen, heißt das nur, dass es keine Pixel im Bild gibt mit diesen Werten. RGB 0-255 gilt trotzdem. IMMER. ;)
Die Verabeitung ist integer und Bedarf keiner händischen Korrekturen, abgesehen von seltenen Spezialfällen.
Wenn man da eingreifen möchte (weil z. B. ein Spezialfall vorliegt), muss man entweder sehr genau wissen, was man da tut, und welche Konsequenzen es hat, oder man testet es aus. Recht simpel.
Ich empfehle Dir dringend, es auszutesten. ;)
Beste Grüße,
Reiner
PS: Meine Einladung an Dich steht nach wie vor.
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
@Reiner M
Wenn du sagst, dass man für den Export aus Premiere und AE den Wertebereich auf 0-255 belassen soll, dann ist das selbstverständlich richtig.
(Das dürfte auch die meisten Praktiker interessieren)
Dabei gibt es wie immer eine Einschränkung: wenn das exportierte File in einer anderen Applikation (ausserhalb von Adobe) verwendet werden soll, muss man beim Import das File u.U. remappen. Diese Notwendigkeit ist aber beim Austausch von Files häufig gegeben, also kein Fehler.
Wenn du aber sagst, dass der Wertebereich Y 16-235 grundsätzlich RGB-Werten von 0-255 entspricht, ist das genauso grundsätzlich falsch.
Vielleicht findet sich ja mal jemand bei Adobe und erklärt es so, dass auch du es verstehst. (Einen entsprechenden Artikel hatt ich schon in einem anderen Thread verlinkt, kam übrigens auch von Adobe ;) )
(Meine Einwände oben haben sich übrigens auf das von dir gebrauchte Wort IMMER bezogen. Zwar wissentlich von dir ignoriert, sprichst du jetzt IMMERhin von andersgearteten Spezialfällen. Es gibt also noch ein Quentchen Hoffnung ;) )
dienstag_01 hat geschrieben:
Dabei gibt es wie immer eine Einschränkung: wenn das exportierte File in einer anderen Applikation (ausserhalb von Adobe) verwendet werden soll, muss man beim Import das File u.U. remappen. Diese Notwendigkeit ist aber beim Austausch von Files häufig gegeben, also kein Fehler.
1. Ich habe Dir extra Videos beigefügt. Importiere sie wohin Du willst.
2. Das, was schließlich in einem exportierten Video vorliegt, ist NIE das, womit wir in Ae arbeiten. Das sollte Dir eigentlich klar sein. Was erwartest Du also? Erklär mal bitte.
Innerhalb von AE arbeiten wir mit RGB 0-255. Was daraus beim Export entsteht, bestimmt allein der verwendete Codec.
Wenn Du also H.264 für den Export wählst, wird YUV gemäß REC.709 dabei rauskommen, der RGB-Wertebereich 0-255 aus dem Arbeitsbereich von AE wird im Videofile als YCbCr mit Y16-235 gespeichert, ganz automatisch. Ohne weiteres Zutun. Jeder zusätzliche, unsachgemäße oder voreilige Eingriff zerstört das Video!
Habe ich wohl deutlich genug gezeigt.
Ach ja: Um Spezialcodecs für Datenaustausch geht es hier übrigens auch nicht. Weder beim Fragesteller stephan, noch bei den meisten anderen, die einfach nur ein Video erstellen wollen. Was also soll dieser "Sonderfall" hier schon wieder? ;)
Bevor Du Dich um Sonderfälle kümmerst, solltest Du erstmal verstehen, wie es grundsätzlich läuft. Sonst leitest Du doch zwangsläufig falsche Schlüsse daraus ab. ;) Das zeigen ja Deine Screenshot oben hinreichend ... falsche Schlussfolgerungen. ;)
dienstag_01 hat geschrieben:
Wenn du aber sagst, dass der Wertebereich Y 16-235 grundsätzlich RGB-Werten von 0-255 entspricht, ist das genauso grundsätzlich falsch.
Stimmt. Sorry. ich habe mit "IMMER" etwas überzogen ...
Wenn Du nämlich mit 10bit-, 16bit- oder gar 32bit-Wertebereichen arbeitstest, stimmt 0 bis 255 natürlich nicht. ;)
Es bleibt aber IMMER der volle Wertebereich. ;)
So ist liegt das Video in meinen Premiere Pro - Beispielen nämlich gar nicht in RGB 0-255, sondern in RGB 32bit 0.0-1.0 . Weil das dort der Standard-Wertebereich ist, solange bis ... - ach lassen wir das. ;)
dienstag_01 hat geschrieben:
.. sprichst du jetzt IMMERhin von andersgearteten Spezialfällen. Es gibt also noch ein Quentchen Hoffnung ;) )
Mach' Dir da mal keine falschen Hoffnungen, Dienstag! ;)
Die "Spezialfälle", die ich meine, ändern an dem AE-Wertebereich RGB 0 bis 255 nichts. Nur an der Verteilung der Werte.
Dafür habe ich Dir doch extra den "Spezialfall" Umstellung des Farbraums nach HDTV (Rec.709) 16-235 im Beispiel plastisch vor Augen geführt. :-(
Es bleibt bei RGB 0-255, oder nicht? Nicht zu sehen?
Nur treten jetzt Pixel mit bestimmten RGB-Werten einfach nicht auf. Aber das hat unschöne Konsequenzen für den Export unbd damit für das Video.
Probiers aus ...
So, nun kannst Du ja erklären, wofür man diesen "Spezialfall" braucht. ;)
@Reiner M
Du hast es sicher gerne, mal bissel nachzudenken. Und ich weiss hier wirklich nicht weiter ;)
Schau dir den Clip mal in verschiedenen Browsern an, unbedingt auch im Firefox mit HTML5. Was issn da los?
was möchtest Du denn erreichen? Was soll schließlich zu sehen sein? Nur die schwarze Fläche mit dem einem weißen Quadrat, oder die verschachtelten Quadrate?
-------------
Aber ein paar Infos dazu, soweit sie in unsere Diskussion passen:
Das Video ist so hergestellt, dass im bildgebenden Bereich (Y16-235) nur die eine schwarze Fläche und das eine weiße Quadrat liegen. Alle Player, die das so wiedergeben arbeiten korrekt nach REC.709.
In Premiere Pro:
Dieser Bereich liegt in RGB 0.0 bis 1.0 (0-255).
Die übrigen Quadrate liegen im Foot- und Headroom.
Der Bereich Y kleiner 16 wird in Premiere Pro zu negativen RGB-Werten führen, der Bereich Y größer 235 zu RGB-Werten größer 1.0 .
Beim erneuten Export werden diese Bereiche berücksichtigt und sind im exportierten Video wieder erhalten, doch nur, solange Du in 32bit bleibst,
Alles gut.
In Ae:
Das Video wird in Ae in jedem Fall nur den bildgebenden Bereich anzeigen, also nur die schwarze Fläche und das eine Quadrat. Logisch.
ABER:
Wenn Du im 8bit-Modus bist, bekommst Du nur die Werte 0 und 255 angezeigt. Sonst nichts. Der Export wird auch nur das exportieren.
Schaltest Du das Projekt auf 32bit um, bekommst Du plötzlich Werte außerhalb 0-255 angezeigt, sobald Du mit der Maus über das Bild fährst. Die Anzeige des Bildes verändert sich nicht.
Der Export wird die Werte speichern und wieder zu Y-Werten kleiner 16 und größer 235 führen.
Alles ganz alles normal, wie zu erwarten.
Und zur Praxis:
Wenn nun Player bei der Wiedergabe von der REC.709-Empfehlung abweichen (das können die Programmierer frei entscheiden), und auch den Head- und den Footroom anzeigen, und Du das nicht möchtest, solltest Du auf ein solches Video in Premiere Pro bewußt den Video-Limiter anwenden und den gespeicherten Datenbereich in YCbCr hart auf 300mV bis 1V begrenzen. Oder im 8bit-Modus arbeiten.
Wenn Du dagegen alle Quadrate immer sehen willst, in jedem Player, wende eine Luminanzkorrrektur an bis die Bereiche außerhalb in den Bildgebenden Bereich fallen.
Wenn es Dir egal ist, lasse es so.
Auf keinen Fall solltest Du mit hier mit unpassenden Werkzeugen arbeiten und z. B. am Farbraum rumspielen.
Reiner M hat geschrieben:Beim erneuten Export werden diese Bereiche berücksichtigt und sind im exportierten Video wieder erhalten, doch nur, solange Du in 32bit bleibst,
Das ist jetzt nicht direkt der ultimative h264 Codec in 32bit.
Wir bleiben mal schön bei 8 ;)
Reiner M hat geschrieben:Beim erneuten Export werden diese Bereiche berücksichtigt und sind im exportierten Video wieder erhalten, doch nur, solange Du in 32bit bleibst,
Das ist jetzt nicht direkt der ultimative h264 Codec in 32bit.
Wir bleiben mal schön bei 8 ;)
Was bitte schön verstehst Du da nicht?
Natürlich ist YcbCr bei einem 8bit-Video 8bit.
Premiere Pro arbeitet in 32bit und lädt beim Import Y-Werte außerhalb Y16-235 in RGB-Werten kleiner 0.0 und größer 1.0. Daraus werden beim Export vom Codec wieder Y-Werte kleiner 16 und größer 235 generiert. Rein-rum-raus - und alles ist gut. Tipp am Rande, den ich nun gar nicht mehr geben mag: Probiere es aus! ;)
Doch Vorsicht: Sobald Du Premiere Pro in den 8bit-Modus zwingst, sind die Head- und Footroomdaten weg und können vom Codec folglich auch nicht mehr in das Video gepackt werden.
Anm: Genau damit zerstören sich manche Anwender bei der Produktion von Zwischenergebnissen ganz beiläufig Videodaten, die noch sinnvoll sein könnten. Alles eine Frage des Workflows.
Reiner M hat geschrieben:Daraus werden beim Export vom Codec wieder Y-Werte kleiner 16 und größer 235 generiert.
Genau. Und in RGB werden beim Export natürlich Werte kleiner 0 und größer 255 erzeugt. Nach der Theorie von Reiner M.
Absurd.
Dienstag .... :-)))
Jetzt wirds echt lustig, um nicht zu sagen lächerlich ...
Willst Du mich veralbern?
Ja,ja, wenn die Erkenntnis aufschlägt, dass die eigenen Grenzen erreicht wurden, wirds in aller Regel hahnebüchend ... ;)
Wir haben doch eben durchgehend über H.264 geredet (Dein Youtube-Video) und über YCbCr, oder nicht? Anderer Meinung?
Was hat RGB-Speicherung damit zu tun? Gar nichts. Falls doch: Sei so gut und erkläre es.
Aber auch das habe ich schon längst beantwortet. Es wäre Dir nicht entgangen, wenn Du aufgepasst hättest:
Reiner M hat geschrieben:
Innerhalb von AE arbeiten wir mit RGB 0-255. Was daraus beim Export entsteht, bestimmt allein der verwendete Codec.
Nochmal passender für Premiere Pro (falls das mißverständlich war):
Innerhalb von Premiere Pro arbeiten wir standardmäßig mit RGB 32bit-Float. Was daraus beim Export entsteht, bestimmt allein der verwendete Codec.
Speicherst Du H.264 als RGB? Ja, dann ...
Wenn Du nun wissen möchtest, wie das im Zusammenhang mit Codecs funktioniert, die Videodaten in RGB speichern, ob das geht oder nicht, hättest Du fragen können. Oder wenn Du einen sinnvollen Beitrag hättest liefern können, der es erklärt, auch sehr gerne das.
Unsinnige Unterstellungen sind m. E. jedoch völlig Fehl am Platz! Du bekommst hier gerade kostenlose Nachhilfestunden geboten. ;)
Daher: Probiers es einfach aus.
Hier gibts jetzt jede Menge Erklärungen dazu. Du kannst es ja noch mal in Ruhe lesen - oder auch lassen. Lernen ist ja hier kein Pflichtprogramm. ;)
Reiner M hat geschrieben:Wir haben doch eben durchgehend über H.264 geredet (Dein Youtube-Video) und über YCbCr, oder nicht? Anderer Meinung?
Was hat RGB-Speicherung damit zu tun? Gar nichts. Falls doch: Sei so gut und erkläre es.
Du bist wohl neuerdings der Meinung, die RGB-Werte stehen in einem willkürlichen Verhältnis zu den YUV Werten?! Heute so und morgen so ;)
Natürlich nicht. Y16-235 heiss RGB 16-235. Und Adobe mapped diese Werte auf 0-255.
Glaubst du mir nicht. Weiss ich.
Glaubst du auch den von Adobe verlinkten Erklärungen nicht. Weiss ich auch.
Glaubst du auch der Mathematik nicht. Kann man hier deinen Ausführungen entnehmen.
dienstag_01 hat geschrieben: Und Adobe mapped diese Werte auf 0-255.
Na, bravo! Wir sind einStück weiter ... Genau so ist es, und zwar in den Verabeitungsspeichern der Programme. Doch lernfähig ... ;)
dienstag_01 hat geschrieben: Y16-235 heiss RGB 16-235.
Hier ist noch Bedarf zur Fortbildung ...
Dienstag, Du musst unterscheiden, worüber Du redest.
Im Arbeitsspeicher der Programme wird Y16-235 als RGB 0-255 abgebildet. Das hast Du ja inzwischen erkannt.
Mit welchen Werten eine Datei importiert wird oder dann via Export/Codec ausgegeben wird, ist von den internen Arbeitsspeichern unabhängig. Es finden "mappings", Transformationen, Umrechnungen statt.
Das gilt auch bei Datein, die mit RGB-Inhalten angeliefert oder produziert werden.
Gib einfach mal ein Video (z. B. Dein Youtube-.mp4) als PNG-Sequenz aus. Da ist dann RGB 0-255 drin. Und nun? Wo ist denn Dein RGB 16-235 geblieben? ;)
Maßgeblich ist der bildgebende Bereich für den Import und den Export!
Die Import- und Exportfunktionen kennen die Formate. Deshalb liest man in den Produktdatenblättern, welche Formate die Programme lesen und welche sie ausgeben können. Oder man kauft sich benötigte Codecs als Plug-Ins. Uns schon geht, was die können. Das ist also Sache der Codecs.
Dann passiert z. B. das:
Bei YUV / Y16-235 -> Ae/Pr intern: RGB 0-255 -> Export: Codec-Spezifikationen
Bei PNG /TIFF usw.: RGB 0-255 -> Ae/Pr intern: RGB 0-255 -> Export Codec-Spezifikationen.
Usw.
Das NLE (genauer: Importer und Exporter) weiß also, wo das Bild zu finden ist (bildgebender Bereich) und welche Umrechnungsregeln herangezogen werden müssen, um vom Import in den Arbeitsspeicher und von dort in den Export zu kommen. Total easy. ;)
----------
Davon getrennt nochmal (wie schon so oft, aber Du bringst es wieder aufs Tablett):
YCbCr hat mit RGB nichts zu tun! Das ist ein anderes Farbmodell. Die Informationen sind völlig unterschiedlich aufgebaut. Will man zwischen diesen Modellen Daten austauschen, müssen sie aufwendig umgerechnet werden.
Deine Annahme, da gibts ein Beziehungsverhältnis 1: 1 ist falsch!
Das schlimme daran ist: Alle Folgerungen, die Du darauf aufbaust, sämtliche Aussagen, Thesen und Behauptungen in diesem Zusammehang sind daher von vornherein auch falsch. Weils Fundament schon nicht passt. Leider ... ;)
Ich würde mich an Deiner Stelle tatsächlich noch mal näher mit diesen Themen beschäftigen. Mehr kann ich Dir da nicht ans Herz legen.
Aha, man darf Fortschritte konstatieren.
In einem anderen Thread hast du noch behauptet, Y 16-235 sei IMMER (scheinbar dein Lieblingswort) RGB 0-255. Jetzt wird schonmal gepapped.
Wenn du jetzt noch verstehst, dass das eine Besonderheit von Adobe und nicht generell so ist, chapeau, dann gehts in riesen Schritten in die richtige Richtung. Und wenn du dann auch noch verstehst, dass YCbCr sehr wohl was mit RGB zu tun hat, wo glaubst du eigentlich kommen die Werte - um das Verständnis zu erleichtern, sagen wir mal bei einem 3-Chip-Camcorder - her ;), dann, ja dann Reiner...
Ich wage gar nicht, mir das auszumalen ;)
Wer beim Import 16 auf 0 und 235 auf 255, sowie alle Werte dazwischen entsprechend mapped, vermurkst sein ganzes Bild, weil er bei der Bearbeitung mit gespreizten Farben gearbeitet hat!!
Egal, ob man das dann wieder beim Export rückmapped oder nicht, es ist NICHT das Original!
WTF ?!
enrico perei
motion picture visual effects and stereoscopic 3D
lead, supervision, artistic & consultancy services
EnricoPerei hat geschrieben:Wer beim Import 16 auf 0 und 235 auf 255, sowie alle Werte dazwischen entsprechend mapped, vermurkst sein ganzes Bild, weil er bei der Bearbeitung mit gespreizten Farben gearbeitet hat!!
An irgendeiner Stelle passiert das bei jedem Video (wir sprechen von Rec709 16-235, also Standard), was auf einem Videomonitor mit den richtigen Kontrasten ausgegeben wird. Ob das nun nur die Vorschau ist und intern wird mit den *richtigen* Werten weitergearbeitet oder ob die Werte intern umgerechnet werden, sei mal dahingestellt.
dienstag_01 hat geschrieben:
In einem anderen Thread hast du noch behauptet, Y 16-235 sei IMMER (scheinbar dein Lieblingswort) RGB 0-255.
Da sieht man mal, wie verdreht manches dargestellt werden kann... ;)
Kann aber auch sein, dass ich extraterristisch spreche ...
Nein: YCbCr und RGB sind völlig verschiedene Farbmodelle.
Ja: in Ae und Pr wird Y16-235 aus einen REC.709-Video nach RGB 0-255 übertragen.
War das jetzt Deutsch? Ist es angekommen? ;)
Schau bitte mal gleichzeitig in die YCbCr-Parade und in die RGB-Parade von Premiere Pro. Du siehst zeitgleich die Inhalte zweier verschiedener, völlig getrennter Speicherbereiche in Pr. Die haben miteinander nichts zu tun. Sie produzieren aber beide das selbe Bild.
Sehen sie unterschiedlich aus? Deutet irgendetwas darauf hin, dass sie in einer 1: 1 - Beziehung stehen? Hmmm ?
Dann frag Dich mal, warum das so ist.
Wenn in anderen Programmen der RGB-Arbeitsspeicher 16-235 umfasst, (was ja möglich ist, wie schon so oft erklärt, aber eben nicht in Premiere Pro und After Effects), dann sind die Werte trotzdem in völlig unterschiedlicher Ausprägung gespreichert.
Zum Thema "Mathematik": Ja, der glaube ich! Ich kenne aber auch die Formeln, die für die Umrechnung zwischen YC und RGB nötig sind. Sowohl um YC nach RGB 16-235 zu kommen wie auch von YC nach RGB 0-255, (was völlig ungespreizt funktioniert, weil die Koeefizienten andere sind).
Und zum Thema "Adobe-Doku": Auch der glaube ich. Ich kenne sie aber auch. ;)
Ich gehe mal davon aus, dass von Dir heute nur noch weitere Verdrehungen und aus dem Kontext gerissene, neueingefärbte Aussagen aus alten Texten von mir folgen werden, die alle weder konstruktiv noch zielführend sind, (wobei mir ihr Sinn selbstverfreilich absolut klar und auch ein Stück weit verständlich erscheint),
Gute Nacht & Beste Grüße,
Reiner
Melde Dich einfach, wenn Du doch mal Spaß an einem Treffen hast. Oder wenn Du Antworten zu meinen vielen Fragen liefern möchtest, die fast alle offen geblieben sind.
EnricoPerei hat geschrieben:Wer beim Import 16 auf 0 und 235 auf 255, sowie alle Werte dazwischen entsprechend mapped, vermurkst sein ganzes Bild, weil er bei der Bearbeitung mit gespreizten Farben gearbeitet hat!!
An irgendeiner Stelle passiert das bei jedem Video (wir sprechen von Rec709 16-235, also Standard), was auf einem Videomonitor mit den richtigen Kontrasten ausgegeben wird. Ob das nun nur die Vorschau ist und intern wird mit den *richtigen* Werten weitergearbeitet oder ob die Werte intern umgerechnet werden, sei mal dahingestellt.
Boah ...
@EnricoPerei
Nein, da wird nichts vermurkst!
Für die Übertragung von YC nach RGB 0-255 werden andere Formeln verwendet, als bei YC nach RG 16-235. das Ergebnis sind völlig glatte Übergänge (vorausgesetzt, sie sind in YCbCr bereits glatt gewesen).
EnricoPerei hat geschrieben:Wer beim Import 16 auf 0 und 235 auf 255, sowie alle Werte dazwischen entsprechend mapped, vermurkst sein ganzes Bild, weil er bei der Bearbeitung mit gespreizten Farben gearbeitet hat!!
An irgendeiner Stelle passiert das bei jedem Video (wir sprechen von Rec709 16-235, also Standard), was auf einem Videomonitor mit den richtigen Kontrasten ausgegeben wird. Ob das nun nur die Vorschau ist und intern wird mit den *richtigen* Werten weitergearbeitet oder ob die Werte intern umgerechnet werden, sei mal dahingestellt.
REC.709 ist ein Standard(wie Du es ja auch sagtest, kein Farbraum), der weit mehr als nur einen Farbraum mit legalen Farben sichert.
Schau Dir mal hier Punkt 5, digital representation an: http://www.itu.int/dms_pubrec/itu-r/rec ... !PDF-E.pdf
Die Werte 1-254 sind für Videodaten reserviert, wobei 16-235 den legal Colours entsprechen und beim Senden Werte größer und kleiner ceclamped werden.
16 ist nicht Schwarz, es ist ein klein wenig darüber und 235 ist eben nicht Weiß
Wenn ein Mapping nun im Display geschieht, ist das kein Problem.
Aber gerade für die Bearbeitung ist es sehr wichtig, daß man die Farben nicht spreizt!!
Egal, ob Blur, Glow, verschiedenen Merge Operationen oder was auch immer, deine Algorithmen werden völlig andere Zahlen ergeben, ergo anders aussehen.
Auch aus diesem Grunde bin ich einer der Puristen.
Wir bearbeiten unser Material unprocessed (ich will nicht raw sagen, da das nicht dem bekannten RAW entspricht).
Wenn wir uns das, was wir gerade machen, im Zielformat anschauen wollen, dann legen wir ein LUT drauf (aber nur die Anzeige, NICHT das Material!).
Erst am Ende, oder wenn irgendeine Operation dies mal erforderlich macht, wird gewandelt.
AUF DIESE WEISE BLEIBT DAS ORIGINAL MATERIAL INTEGER!
enrico perei
motion picture visual effects and stereoscopic 3D
lead, supervision, artistic & consultancy services
EnricoPerei hat geschrieben:AUF DIESE WEISE BLEIBT DAS ORIGINAL MATERIAL INTEGER!
Aus diesem Grund arbeite ich mit Avid ;)
Danke übrigens für den Link, sowas habe ich schon länger gesucht (und Reiner M fällt beim Lesen von Aussagen wie *R, G, B, Y ist 16* sicher in Ohnmacht)
Was genau Adobe da macht, ich weiss es nicht 100%ig, aber ich bin doch ziemlich sicher, dass sie nur die Vorschau auf 0-255 mappen - also eine Art LUT - aber wie soll ich das genau rausbekommen/beweisen. After Effects jedenfalls kann man Arbeitsfarbräume zuweisen, da werden bspw. bei vollem Weiss auch nur 235 angezeigt, ich denke nicht, dass sie die Werte erst von 235 nach 255 wandeln und dann mit dem Colorpicker wieder 235 anzeigen, sondern genau umgekehrt: sie zeigen den Originalwert 235 an und mappen die Vorschau auf 255, sonst wäre es auf dem Monitor nur Hellgrau. Aber egal.
Wie gesagt, Avid ist da konsequent und man weiss, wo man ist.
Zuletzt geändert von dienstag_01 am So 10 Aug, 2014 23:09, insgesamt 1-mal geändert.
EnricoPerei hat geschrieben:
Die Werte 1-254 sind für Videodaten reserviert, wobei 16-235 den legal Colours entsprechen und beim Senden Werte größer und kleiner ceclamped werden.
16 ist nicht Schwarz, es ist ein klein wenig darüber und 235 ist eben nicht Weiß
Alles bekannt. ;)
Du redest da über Y-Werte in YCbCr-Speicherung. Okay?
Wieviele Bytes stehen Dir denn in YCbCr zur Verfügung, um in RGB den Blau-Kanal zu füllen? In RGB sind es 256 oder 220 Bytes im Blaukanal, je nachdem, ob Du RGB 0-255 oder RGB 16-235 wählst.
Oder 32.768 Bytes bei einem RGB 16bit Arbeitsfarbraum. Oder ganz viele Bytes bei RGB 32bit Float.
Ist es also schlecht in 16bit und 32bit zu arbeiten, weil da ja lauter Lücken vorkommen müssen? Riesige Spreizungen vorhanden sind? Hmmm..
Wieviele Bytes hast Du in YCbCr, um in RGB "braun" zu erzeugen in allen Nuancen (Helligkeiten, Sättigungen)? Leider gibts keinen "Braun-Kanal", weder hier noch dort, was die Sache womöglich schwieriger macht, oder auch nicht. ...
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.
