Reiner, du kannst umrechnen was du willst, RGB255 ist Luminanz 255 und nicht Luminanz 235. Für YCbCr gibt es einen extra Monitor.
Ich hab dir ja schon vor längerer Zeit mal geschrieben, lade dir spasseshalber mal Avid runter, die nehmen nämlich die Lumawerte zur Skalierung und man sieht eindeutig die Zusammenhänge. So wie du das machst interpretierst du dir deine Skalen nur solange zurecht, bis sie in dein Bild passen (Premiere schreibt eben nicht die Lumawerte an die Skala, wohl wissend, das die nicht mit ihrer Anzeige auf dem Computermonitor korropondieren (würden).)
@Reiner
Unterabgetastete Werte erzeugen in RGB Illegale Farben weil die schwarzen Werte, wie in dem Beispiel „positiv“ Rot, „negativ“ Grün und „negativ“ Blau.
haben.
Du hast zwar geschrieben, sie könnten nicht dargestellt werden, aber Auswirkung kommt in Deiner Beschreibung einwenig kurz.
Die Bereiche außerhalb des sichtbaren Bildbereichs sind im Video unsichtbar (negative RGB-Werte oder solche > 1,0).
Erst dann, wenn sie in den sichtbaren Bildbereich gedrückt werden (ihre Luma-Werte werden verändert) entstehen echte Bildinformationen (videotechnisch legale Luminanzwerte) und unterwegs selbstverständlich legale Farben.
Da es sich aber um diskrete Ausgangwerte handelt (vor RGB! In der Aufnahme tatsächlich enthalten) gewinnt das Video an Bildinformationen (Details/und oder Farben).
dienstag_01 hat geschrieben:Reiner, du kannst umrechnen was du willst, RGB255 ist Luminanz 255 und nicht Luminanz 235. Für YCbCr gibt es einen extra Monitor.
Folgt man Deiner Annahme, hieße dass: Kein Video kann es schaffen, auf einem PC-Monitor RGB-Werte (egal in welchem Kanal) größer 235 zu produzieren ... ;) Und die ganze 16-235 Diskussion wäre eh obsolet.
Reiner M hat geschrieben:Folgt man Deiner Annahme, hieße dass: Kein Video kann es schaffen, auf einem PC-Monitor RGB-Werte (egal in welchem Kanal) größer 235 zu produzieren ... ;) Und die ganze 16-235 Diskussion wäre eh obsolet.
Wäre echt schade, wenns so wäre. ;)
JEDES standardkonforme Video ist 16-235 und wird von Softwareplayern auf 0-255 gemapped (sehen wir mal von den Fehlinterpretationen der Player ab, die gibt es). Und das ist keine Annahme, sondern Fakt.
Wenn im Web auch 601/709 erwartet wird, was passiert dann, wenn ich RGB im Web hochlade? Bisher hat das immer sehr gut funktioniert! Und ich dachte, wenn es um PC/ Web geht, dass ich hier RGB hochladen sollte. Habe ich aus Avid in 601/709 exportiert, sahen die Videos flau aus.
Blackeagle123 hat geschrieben:Wenn im Web auch 601/709 erwartet wird, was passiert dann, wenn ich RGB im Web hochlade? Bisher hat das immer sehr gut funktioniert! Und ich dachte, wenn es um PC/ Web geht, dass ich hier RGB hochladen sollte. Habe ich aus Avid in 601/709 exportiert, sahen die Videos flau aus.
Verstehe ich richtig, dass du mit DNxHD an Sorenson übergibst?
Wenn deine Korrektur normal in 709 (16-235) stattgefunden hat, ist RGB richtig. Es bleibt aber 16-235 ;)
dienstag_01 hat geschrieben:
JEDES standardkonforme Video ist 16-235 und wird von Softwareplayern auf 0-255 gemapped (sehen wir mal von den Fehlinterpretationen der Player ab, die gibt es). Und das ist keine Annahme, sondern Fakt.
Genau!
Aber was meinst Du denn nun wirklich? Eben noch schriebst Du das Gegenteil:
dienstag_01 hat geschrieben:Reiner, du kannst umrechnen was du willst, RGB255 ist Luminanz 255 und nicht Luminanz 235.
Wird nun aus Y16-235 ein RGB-Bereich 0-255, oder doch nicht? ;)
Ich halte Deine neue Aussage für besser.
Es wird gemapped, anhand von definierten Standard-Verfahren. Und zwar vorwärts wie auch rückwärts.
Für den Wokflow ist es deshalb sehr wichtig zu verstehen, wo was wie greift, abhängig von NLEs, Einstellungen und Effekten. Man sollte YC-Werte und RGB nicht durcheinanderwerfen.
Reiner M hat geschrieben:Wird nun aus Y16-235 ein RGB-Bereich 0-255, oder doch nicht? ;)
Diese Aussage ist und bleibt falsch.
Wenn von 16-235 nach 0-255 gemapped wird, dann betrift das die Luminanz des Bildes. Es kann nur beides 16-235 oder beides 0-255 sein, nicht das eine das, das andere jenes.
Dein Bild liegt in Premiere in 16-235 vor (Luma und RGB) und wird in der ANZEIGE nach 0-255 gemapped.
Is so.
Gibt auch andere NLEs, die das Mapping nicht machen. Da muss es aber eine Methode geben, das zuzuschalten (über Filter o.ä.), sonst könnte man auf einem Computermonitor nicht arbeiten. Premiere schaltet standardmäßig das Mapping an.
Erst dann, wenn sie in den sichtbaren Bildbereich gedrückt werden (ihre Luma-Werte werden verändert) entstehen echte Bildinformationen
von "magischer" Hand ?
Was sollte denn die Werte noch verändern, dass sie zu sichtbaren Informationen werden ?
Bitte? Meinst Du das jetzt ernst? ;)
Die Veränderung findet z.B. durch Stauchen der Luma-Kurve statt. Nicht von "magischer" Hand, sondern von der Hand dessen, der das Video im NLE vorliegen hat. Er nutzt geeignete Effekte. Es gibt unterschiedliche Werkzeuge dafür. Darum geht es hier doch die ganze Zeit. ;)
Aus meiner Sicht ist das pauschale Stauchen auf 16-235 kein gutes Werkzeug.
Wer das aber gar nicht macht, verzichtet eben darauf. Auch gut. Ganz sicher ist Nicht-machen nicht der optimale Workflow, wenn ich schon eine Cam habe, die 0-255 bietet und damit Vorteile.
Der größte Teil der Cams am Markt dürfte inzwischen so arbeiten, seit vielen Jahren gibts das. Das ist alles nichts Neues. ;)
Wie bitte machst Du aus illegalen Farben durch "Stauchung" legale Farben ? (Und was soll "Stauchung" sein, welcher Rechenprozess verbirgt sich dahinter)?
Aber wir drehen uns mal wieder im Kreis.
Alles klar.
Jeder soll die Kamera benutzen, mit der er klar kommt ... mit allen Ãœberraschungen, die sich so einstellen.
dienstag_01 hat geschrieben:
Diese Aussage ist und bleibt falsch.
Wenn von 16-235 nach 0-255 gemapped wird, dann betrift das die Luminanz des Bildes. Es kann nur beides 16-235 oder beides 0-255 sein, nicht das eine das, das andere jenes.
Mach Dich mal über die Umrechnung YUV nach RGB schlau. Du wirst zahlreiche Formeln, Tabellen und Matrizen finden, die dir zeigen, wie tatsächlich umgerechnet wird.
Aber paar Praxistest (Du hast ja Pr und Ae):
Leider hat Premiere Pro keinen Colorpicker. Aber After Effects. Die Mimik ist dort die selbe wie in Premiere Pro. Einziger Unterschied: In AE musst Du das Projekt auf 32bit umstellen, was bei Premmiere Pro der Standard ist. Dann funktioniert es identisch.
Der AE- "Colorpicker" zeigt Dir nicht die RGB-Werte der Monitor-Ausgabe, sondern die im internen RGB-Speicher, der für das Processing verwendet wird. Da schau mal rein. Du wirst Werte angezeigt bekommen, die Dein Monitor ganz sicher nicht darstellen kann. RGB-Werte. Die DEINER Meinung nach von einem Video gar nicht produziert werden können. Höchstens in der Monitor-Ausgabe. ;)
In Premiere Pro bleibt nur der Blick in die RGB-Parade. "100" meint dort RGB 1,0 bzw. RGB 255. Nichts anderes. Hast Du Werte zwischen 90 und 100? (entspräche so ungefähr RGB 236-255).
WoWu hat geschrieben:Wie bitte machst Du aus illegalen Farben durch "Stauchung" legale Farben ? (Und was soll "Stauchung" sein, welcher Rechenprozess verbirgt sich dahinter)?
Wolfgang, lies bitte in Ruhe noch mal diesen Thread. Da ist m. E. alles wunderbar erklärt. ;)
WoWu hat geschrieben:
Jeder soll die Kamera benutzen, mit der er klar kommt ... mit allen Ãœberraschungen, die sich so einstellen.
Da bin ich voll bei Dir.
Nur sollte er auch mit den Werkzeugen in der Post klar kommen. Wenigstens soweit, dass "gute" Videos dabei rauskommen (was immer dieser subjektiv gefärbte Begriff für ihn auch meint).
Reiner, du willst wieder mal die Realität nicht wahrhaben.
Rec709 beschreibt auch für RGB 16-235. Vollkommen unabhängig von deiner Umrechnung.
Aber, damit du mal begreifst, was im Hintergrund deines geliebten AE so alles passiert: Neues Projekt, 8bit (reicht), ohne Farbmanagment, weisse Farbfläche auf Layer: RGB255. Jetzt schalte mal Farbmanagment ein: 709 16-235. Und jetzt schau mal, was dein Picker anzeigt. Ist das Weiss anders geworden? Hier kannst du lernen, was Mapping bedeutet.
Edit: Sorry, funktioniert scheinbar nicht mit Farbflächen, musst ein Video nehmen. Kannst du dir ja aus Premiere hohlen.
Edit: was aber schön geht, in AE zwei Farbflächen übereinander, RGB255 und RGB235 und dann Farbmanagment an (709 16-235).
WoWu hat geschrieben:Wobei sich darin schon der nächste Fehler verbirgt, weil in den Wandlungen in erster Linie, mit dem Lumawert und nicht mit der Luminanz, also nicht in einem linearen Umfeld gerechnet wird. Daraus resultiert dann, dass Pixel mit einem positiven Wert heller erscheinen, als sie sein dürfen.
Statt also mit den "komplizierten" Umrechnungen zu arbeiten, die eigentlich nur Näherungsformeln sind, sollte man erst mal das Gamma entfernen und erst anschliessend die Berechnungen vornehmen. Das Gamma kann dann durch Investierung der Formel wieder aufgebracht werden.
Wie die Entwickler von Applikationen, die Videos an RGB-Geräten ausgeben, das umsetzen, ist sicher noch einen Tick komplexer. Nicht umsonst unterscheiden sich die Ausgaben diverser Player auf dem selben PC. Die Umrechnung von YUV nach RGB ist aber der entscheidenende Teil. Kommt man nicht dran vorbei.
WoWu hat geschrieben:
Also, so toll ist die ganze Umrechnung nicht und weicht an allen Ecken und Kanten vom Original ab.
Mag ja sein, aber seit Anbeginn aller Zeiten, seit dem die Bildausgabe von YC nach RGB nötig wurde, eben das Verfahren dafür. Ohne Umrechnung gehts eben nicht.
Was aber auch nicht schlimm ist. Die ganze Videobearbeitung lebt von Kompromissen und vom "Versuch", ein wirklichkeitsgetreues Bild zu erzeugen. Da weicht doch jede Aufnahme "an allen Ecken und Kanten vom Original ab.". Und zwar heftig, oder?;)
Reiner M hat geschrieben:Was aber auch nicht schlimm ist. Die ganze Videobearbeitung lebt von Kompromissen und vom "Versuch", ein wirklichkeitsgetreues Bild zu erzeugen. Da weicht doch jede Aufnahme "an allen Ecken und Kanten vom Original ab.". Und zwar heftig, oder?;)
Beste Grüße,
Reiner
sowieso:-), jedoch für mich am ehesten die frage, wie nehme ich einfluss darauf bzw kontolliere dies?
dienstag_01 hat geschrieben:Reiner, du willst wieder mal die Realität nicht wahrhaben.
Rec709 beschreibt auch für RGB 16-235. Vollkommen unabhängig von deiner Umrechnung.
Bitte Dienstag. Informiere Dich einfach über die Basics ... z. B. yuv2rgb
dienstag_01 hat geschrieben:
Aber, damit du mal begreifst, was im Hintergrund deines geliebten AE so alles passiert: Neues Projekt, 8bit (reicht), ohne Farbmanagment, weisse Farbfläche auf Layer: RGB255. Jetzt schalte mal Farbmanagment ein: 709 16-235. Und jetzt schau mal, was dein Picker anzeigt. Ist das Weiss anders geworden? Hier kannst du lernen, was Mapping bedeutet.
Edit: Sorry, funktioniert scheinbar nicht mit Farbflächen, musst ein Video nehmen. Kannst du dir ja aus Premiere hohlen.
Ach!!! ;)
Farbmanagement! ... Etliche verstehen es noch nicht mal in Photoshop ...
(was aber auch nicht schlimm ist)
Ich hatte weiter oben beschrieben, dass es einen gravierenden Unterschied macht, wenn eine Quelle ein embedded Profile besitzt.Das gilt auch, wenn Du einen Farbraum in AE erzwingst.
Dienstag, das ist Technik für Fortgeschritttene. Bitte lass' uns das hier, an dieser Stelle, nicht vertiefen! Ich fürchte, dann sind wir allein ...
Die Auswirkungen hängen von beliebig kombinierbaren Zuständen der Quell- und Zielfarbräume ab und würden endlose Diskussionen zur Folge haben. (z. B. Was passiert, wenn ein Video explizit auf REC.709 (16-235) kodiert ist (kann man nämlich machen) und nicht nur auf REC.709 (wie die meisten, die so vorliegen)? Und was ist da eigentlich der Unterschied? Was passiert dann, wenn dann noch der Farbraum umgestellt wird, und was passiert mit Fotos (Photoshop kann auch Fotos als REC.709 (16-235) speichern!)) und Farbflächen und wieso ist eigentlich alles so flau oder sowieso anders als ich dachte? ... ;)
Genau vor solchen Auswirkungen möchte ich die Warnen, die Ihr Y(!)) 0-255 Video pauschal auf Y(!)16-235 trimmen. Egal ...
Gerne biete ich Dir einen Wokshop dazu an. Lass' uns zusammensitzen und das Stück für Stück in Ae angehen. Vielleicht wird dann manches klarer. Gerne lerne ich umgekehrt was von Deinem Avid. Komm mal vorbei.
Reiner, hier geht es nicht um Fortgeschrittene, sondern um Grundlagen.
Du behauptest, eine weisse Farbfläche kann GLEICHZEITIG den Lumawert Y=235 haben und RGB255. Das ist Unsinn. Da du aber in den Adobeapplikationen mit dieser Annahme gut arbeiten kannst, bitte, mach es.
Falsch bleibt sie trotzdem.
Sobald du aber in den Austausch mit anderen Applikationen trittst, kommst du mit deiner zurechtgebogenen Welt schnell an ihre Grenzen. Machst du nicht, ich weiss. Biste fein raus.
Wenn du es aber hier schreibst und darauf Theorien und Erklärungen aufbaust, wird es eben ganz schnell Mist.
(Letztes Jahr hatten wir hier schon mal diese Diskussion, da hat dir auch jemand die Specs für 709 als Bild gepostet. Explizit für Leute wie dich mit R16-235, G16-235 und B16-235. War scheinbar ausserhalb deines Wahrnehmungsspektrums)
Reiner M hat geschrieben:Was aber auch nicht schlimm ist. Die ganze Videobearbeitung lebt von Kompromissen und vom "Versuch", ein wirklichkeitsgetreues Bild zu erzeugen. Da weicht doch jede Aufnahme "an allen Ecken und Kanten vom Original ab.". Und zwar heftig, oder?;)
Beste Grüße,
Reiner
sowieso:-), jedoch für mich am ehesten die frage, wie nehme ich einfluss darauf bzw kontolliere dies?
lg
srone
srone, das ist wohl DIE Frage schlechthin, die sich wohl alle Cam- und NLE-Hersteller, aber alle Benutzer stellen.
Es gibt wohl keine allgemeingültige Antwort. Wenn es eine gäbe, hieße sie m. E. ganz platt: Durch einen wohlüberlegten Workflow!
Sein Ziel: Das beste Verhältnis zwischen Qualität und Effizienz in der Bearbeitung schaffen. Und der Workflow hängt eben auch von den Werzeugen ab, die zur Verfügung stehen. Sie sollten an den richtigen Stellen optimal eingesetzt werden. Sehr platt, oder? Natürlich stehen dahinter konkrete Maßnahmen. Ich hatte schon angedeutet, dass ich Videos meiner Canon DSLR anders behandle als die der Panas.
Beispielsweise ist Luma-Korrektur m. E. clip-abhängig und gehört für mich in eine Pre-Post-Phase, also nach dem Grobschnitt, aber vor dem eingentlichen Schnitt. Dann nämlich fließen in der Timeline bei der Erstellung des Ziel-Videos gut vorbereitete Assets zusammen, die sich (hoffentlich) harmonisch ergänzen werden und keinerlei "Problemstellen" (Rauschen, Verwackelungen, schlechter Ton und eben unschöne Belichtung) mehr besitzen. Das ist aber nichts Festgeschriebenes, wenns brennt im Projekt, kommts womöglich eher auf Durchsatz an als auf Qualität. Nur huddeln, das sollte dennoch nicht passieren. ;)
Ich hab hier mal die Lage der Kurve zu 16-255.
Das ist dem C-Log nachempfunden, also kein Standardsignal.
Das ist schon so, wie ich oben geschrieben habe, das ist ATI, um für den amerikanischen Analogmarkt die TV Zulassung zu kriegen.
Das ist also ein Zugeständnis für US-analoge TV Geräte.
dienstag_01 hat geschrieben:
Du behauptest, eine weisse Farbfläche kann GLEICHZEITIG den Lumawert Y=235 haben und RGB255. Das ist Unsinn.
Dienstag, solange Du Dich nicht über die diversen Umrechnungsverfahren YUV nach RGB schlau gemacht hast, und mir daran aufzeigst, dass aus Y16-235 niemals RGB0-255 oder RGB 0,0-1,0 gemappt werden kann, brauchen wir nicht weiterreden.
Es ist für mich nur schwer verständlich, dass Du einem Software-Player das Mapping von Y16-235 nach RGB0-255 zugestehst, aber einem NL nicht. Dabei ist die Aufgabe des NLEs, ein Bild zu erzeugen, dass später von genau diesem Player möglichst identisch gezeigt wird. Ich weiß, Du schiebst es auf die AUSGABE des Vorschaumonitors im NLE. Doch der Blick in die RGB-Parade hat mit dem Vorschau-Monitor nichts zu tun. Schau da bitte endlich mal rein.
Solange Du nicht die sehr einfachen Praxistest, die ich Dir aufgezeigt habe, durchführst und adäquat beantwortest ohne fadenscheinige Ausflüchte in besondere Konstrukte wie Profilumstellungen, die hier gar nicht zur Debatte stehen, brauchen wir nicht weiterreden. Obwohl diese Test und die Antworten sehr einfach sind.
Ich bin mir ziemlich sicher: Du hast es bemerkt! Man kann nämlich gar nicht übersehen, dass REC.709-Videos RGB-Werte bis 1,0 erzeugen und REC.709 Videos mit Signalen im Headroom sogar über +1,0 nämlich bis zum Signalwert max. +1,069V aus der Luma-Wave. Und das im RGB-Speicher, nicht auf dem Monitor, der kann nämlich 32bit gar nicht anzeigen. Wie soll das also gehen? Wo kommen diese Werte her? Erklär mal bitte!
Ja, Ae mappt sogar "Superweiß" (die Brightwhite area) nach RGB , aber eben oberhalb RGB+1,0 , wo es hingehört. Wozu das gut ist? Besondere Verfahren eben ... ;)
Nimms bitte nicht persönlich. Komm lieber vorbei und zeig mir, wie es geht! Würde mich freuen. ;)
Reiner M hat geschrieben:Was aber auch nicht schlimm ist. Die ganze Videobearbeitung lebt von Kompromissen und vom "Versuch", ein wirklichkeitsgetreues Bild zu erzeugen. Da weicht doch jede Aufnahme "an allen Ecken und Kanten vom Original ab.". Und zwar heftig, oder?;)
Beste Grüße,
Reiner
sowieso:-), jedoch für mich am ehesten die frage, wie nehme ich einfluss darauf bzw kontolliere dies?
lg
srone
srone, das ist wohl DIE Frage schlechthin, die sich wohl alle Cam- und NLE-Hersteller, aber alle Benutzer stellen.
Es gibt wohl keine allgemeingültige Antwort. Wenn es eine gäbe, hieße sie m. E. ganz platt: Durch einen wohlüberlegten Workflow!
Sein Ziel: Das beste Verhältnis zwischen Qualität und Effizienz in der Bearbeitung schaffen. Und der Workflow hängt eben auch von den Werzeugen ab, die zur Verfügung stehen. Sie sollten an den richtigen Stellen optimal eingesetzt werden. Sehr platt, oder? Natürlich stehen dahinter konkrete Maßnahmen. Ich hatte schon angedeutet, dass ich Videos meiner Canon DSLR anders behandle als die der Panas.
Beispielsweise ist Luma-Korrektur m. E. clip-abhängig und gehört für mich in eine Pre-Post-Phase, also nach dem Grobschnitt, aber vor dem eingentlichen Schnitt. Dann nämlich fließen in der Timeline bei der Erstellung des Ziel-Videos gut vorbereitete Assets zusammen, die sich (hoffentlich) harmonisch ergänzen werden und keinerlei "Problemstellen" (Rauschen, Verwackelungen, schlechter Ton und eben unschöne Belichtung) mehr besitzen. Das ist aber nichts Festgeschriebenes, wenns brennt im Projekt, kommts womöglich eher auf Durchsatz an als auf Qualität. Nur huddeln, das sollte dennoch nicht passieren. ;)
Beste Grüße,
Reiner
eben drum, lohnt es sich gelegentlich, ein paar worte darüber zu verlieren, um den "workflow" weiter zu entwickeln. :-)
Dienstag, solange Du Dich nicht über die diversen Umrechnungsverfahren YUV nach RGB schlau gemacht hast, und mir daran aufzeigst, dass aus Y16-235 niemals RGB0-255 oder RGB 0,0-1,0 gemappt werden kann, brauchen wir nicht weiterreden.
Reiner, es geht weder um gemapped noch um RGB 0,0-1,0.
Es geht einzg un allein darum das Y235 nicht in der RGBParade plötzlich als Lumawert 255 stehe kann. Als 1,0 schon. Und als 235.
Das hat mit deinen Umrechnungen überhaupt nichts zu tun, die gehören hier nicht her.
Um dir mal zu zeigen, wie es ein NLE handhabt, dass sich nicht vor den Bit-Werten als Skaleneinteilung drückt, siehe Screenshots.
Du glaubst jetzt nicht, dass Avid deine Umrechnung VERGESSEN hat ;)
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
dienstag_01 hat geschrieben:
Du glaubst jetzt nicht, dass Avid deine Umrechnung VERGESSEN hat ;)
Natürlich nicht. ;)
Wenn Du Dich schlau gemacht hättest, wüsstest Du, dass es verschiedene Matrizen für die Umrechnung gibt. Avid benutzt offensichtlich eine andere, aber es benutzt eine. Ganz sicher. Weils nicht anders geht. Es sei denn, Du hast eine neue Lösung gefunden? ;)
Man kann Y(16-235) selbstverständlich nach RGB 16-235 überführen, aber eben auch nach RGB 0-255. Die Definitionen sehen das vor. Sehr einfach.
Es gibt für beide Verwendungen sehr konkrete Gründe.
Ich rede übrigens über PREMIERE PRO (und AE). Zu Avid werde ich nichts sagen, da kenne ich mich nicht aus.
Du aber redest über Premiere Pro und kommst dann mit Beispielen aus Avid? ... ;)
Noch mal die Bitte:
Mach das das einfach in Premiere Pro und Ae. Es sollte Dir doch leicht fallen, die Ergebnisse korrekt zu interpretieren?
Wenn also das Infofeld in AE aus einem Video für ein Pixel RGB 255 anzeigt, was meint das?
Richtig: Dann ist auch RGB 255 drin. Sehr einfach, oder? Obwohl nur Y235 als Ausgangswert da war.
Wenn Du wieder glaubst, das sei falsch, dann erkläre mir bitte endlich, wo dieser Wert 255 herkommt. ;)
Egal, wie Avid das macht:
Premiere Pro mapped Y16-235 (wenn keine Besonderheiten vorliegen, was aber sein kann) nach RGB 0,0 bis 1,0 in den 32bit RGB-Raum. Die Umrechnung erfolgt nach Standard-Matrizen nach RGB-Full_range.
Übrigens: Der Wertebereich RGB 0,0 bis 1,0 wird per Definition nach RGB 0-255 überführt, wenn eine 8bit-Verarbeitung ansteht. RGB 32bit 1,0 ist also per Definition RGB 8bit 255. Immer. Nichts anderes.
Und so nebenbei sei angemerkt: Der Premeire Pro Vorschau-Monitor ist leistungsfähiger als Du wohl denkst. Er greift direkt auf den RGB-Speicher zu und zeigt so gut wie möglich die Inhalte des Speichers, nur eben in 8bit. Es wird nicht der Grafikkarte überlassen, hier zu korrigieren.
Wenn also RGB (16-235) tatsächlich im Speicher vorliegt sieht man das im Vorschau-Monitor sofort. RGB235 und RGB255 unterscheiden sich in der Helligkeit ja stark genug. Die Grafikkarte wird das nicht auf 0-255 aufblasen, und es gibt keinen Grund für Premiere Pro, das zu tun. Wäre ziemlich kontraproduktiv. Aber auch das lässt sich leicht überprüfen: Wenn man will. ;)
Ach ja. nach wie vor: Du bist herzlich eigeladen ...
Wenn deine Korrektur normal in 709 (16-235) stattgefunden hat, ist RGB richtig. Es bleibt aber 16-235 ;)
Das ist falsch! Hier kommt die Erklärung.
Avid schreibt dazu:
Avid exports RGB data and quicktime stores this data somehow (can be converted to YUV, but you never know). Only if you do a "same as source export" the data is stored in YUY without converting to RGB.
But you can export RGB data in differnt ways:
RGB: 0/0/0 -> Video Black, 255/255/255 -> 100% video white
this means you can't have video levels below 0% and over 100% => exports for computer video use RGB to get a good black and white.
601: 16/16/16 -> Video black, 235/235/235 -> 100% video white
this means you can have video levels below 0% and over 100% => for uncorrected material like raw camera footage use 601, else you'll get clipping!
So viel zum generellen Import/ Export.
weiterhin:
1. When exporting from inside MC, if you choose your export to be 601/709, all levels will remain UNCHANGED. So they will either be at broadcast 601/709 levels (if you have made sure your footage is legal), or outside those levels (if you have let your footage outside the specs).
2. When exporting from inside MC, if you choose your export to be RGB, then all values in your signal will be expanded (remapped) from 16-235 to 0-255. So everything under 16 will be crushed to 0, and everything over 235 will be clipped to 255. All values in between (17-234) will be "stretched" over 1-254.
If your DVD/BD encoder app does not understand that video is coming in at 16-235 (and some of those apps will not understand this), it will (incorrectly) assume that the incoming file is 0-255, and will remap those values back to 16-235 (so that they are 601/709 legal again). That means that your 16-235 stuff will look washed out (greyish blacks, dullish whites), as the (empty) values 0-15 have been pushed up 16 steps, and the (empty) values 236-255 will have been lowered 20 steps. Your black is now somewhere around 30 rather than 16, and your whites are now somewhere around 220 rather than 235. If you hook up the DVD player to a scope, it will easily show this.
So me, personally, when sending stuff to a DVD/BD encoder app, I would want that DVD/BD encoder app to have the option to realize that the source is already within 601/709, and NOT touch the levels, as I don't see any benefit in changing levels that are already correct, and I dislike the unnecessary remapping from 16-235 to 0-255 and back, since it is bound to cause rounding errors (and likely to cause issues like banding).
I use TMPGenc for DVD encoding (it recognizes color spaces, or you can manually set them) and Squeeze for BD. Both allow me control over 16-235 remapping in their (advanced) settings.
Was bedeutet, dass der sicherste Weg der ist, aus Avid "Same as Source" zu exportieren (also 601/709) und dann eine BluRay- (h.264) oder DVD-Datei (mpeg2) im 601 oder 709 Farbraum zu erzeugen, die das DVD-Programm gar nicht mehr konvertiert, z.B. Encore.
Also ebenfalls genau das, was ich in meiner ersten Antwort geschrieben habe.
zusätzlich schreibt Avid:
Files meant for viewing on a computer monitor (you tube, websites, quicktime) should be RGB and files meant for broadcast tape or DVD/BluRay should be 601/709.
Was dann wohl bedeutet, dass Web Werte von 0-255 erwartet, was ich von Anfang an geschrieben habe!
Es bleibt eben nicht 16-235 wenn ich RGB exportiere sondern wird auf 0-255 gestaucht, sonst würde ja der RGB-Export gar keinen Sinn machen.
Demnach muss ich eben mit dem 601/709 Setting oder "Same as Source" exportieren, wenn ich für Web exportiere.
Und zu Adobe:
Adobe arbeitet so, dass Grafiken automatisch in den 601/709 Farbraum gestaucht werden, weil Premiere den Farbraum als RGB erkennt. Alles andere muss manuell angepasst werden (s. Waveform Monitor). Dazu sollte dann auch das Material von DSLRs gehören - wobei ich mir hier gerade nicht sicher bin ob Premiere das DSLR-Material nicht sogar auch in den richtigen Farbraum bringt.
Hoffe, dass damit jetzt alle Unklarheiten beseitigt wurden.
Viele Grüße!
Zuletzt geändert von Blackeagle123 am Sa 19 Jul, 2014 10:57, insgesamt 3-mal geändert.
Ich bin mir ziemlich sicher: Du hast es bemerkt! Man kann nämlich gar nicht übersehen, dass REC.709-Videos RGB-Werte bis 1,0 erzeugen und REC.709 Videos mit Signalen im Headroom sogar über +1,0 nämlich bis zum Signalwert max. +1,069V aus der Luma-Wave.
Natürlich geht das, dafür gibt es in der ColorCorrection von Avid ja extra die Möglichkeit, das Signal oben und unten zu beschneiden, wobei dadurch natürlich auch genau diese Informationen verloren gehen. (Stichwort Clipping)
Blackeagle123 hat geschrieben:Es bleibt eben nicht 16-235 wenn ich RGB exportiere sondern wird auf 0-255 gestaucht, sonst würde ja der RGB-Export gar keinen Sinn machen.
Demnach muss ich eben mit dem 601/709 Setting oder "Same as Source" exportieren, wenn ich für Web exportiere.
Nee, RGB ist schon richtig.
Ich wehre mich nur, dass als 0-255 zu bezeichnen/anzuerkennen. Das hängt mit ein paar Seltsamkeiten beim Export für Youtube zusammen. Aber auch, dass einige Avid-User dann eine zweite Farbkorrektur fürs Web machen: 0-255.
Blackeagle123 hat geschrieben:
Und zu Adobe:
Adobe arbeitet so, dass Grafiken automatisch in den 601/709 Farbraum gestaucht werden, weil Premiere den Farbraum als RGB erkennt. Alles andere muss manuell angepasst werden (s. Waveform Monitor). Dazu sollte dann auch das Material von DSLRs gehören - wobei ich mir hier gerade nicht sicher bin ob Premiere das DSLR-Material nicht sogar auch in den richtigen Farbraum bringt.
Premiere Pro erkennt ganz sicher den richtigen Farbraum der Quellen. ;)
Wie geschrieben, benutzt Premiere Pro dafür unterschiedliche Importer, die von der Quelle abhängen. Was in einer Quelle vorhanden ist, kann dafür vor dem Laden in Erfahrung gebracht werden. Es lässt sich ja auch mit Tools außerhalb von Premiere Pro anzeigen.
Wenn DSLRs Videodateien produzieren im Format YUV 4:2:0 (wie bei Canon), dann ist da auch YUV drin, also YCbCr, und nicht RGB.
Diese Videos werden selbstverständlich korrekt geladen und gemäß Codec-Angabe dekromprimiert (H.264). Sie liegen dann im internen YUV-Speicher des NLEs. Um damit in der Timeline arbeiten zu können, müssen sie zusätzlich in den RGB-Speicher und liegen schließlich für die Verarbeitungsprozesse im NLE sowohl als YCbCr wie auch als RGB 32bit in den internen Speichen vor.
Bei RGB-Fotos passiert es einfach umgekehrt: Sie werden dekomprimiert und in den RGB-Speicher geladen. Um sie videotechnisch bearbeiten zu können werden sie zusätzlich nach YCbCr umgerechnet.
Es ist eben nötig, dass zeitgleich beide Speicherformate vorhanden sind, weil etliche Verarbeitungsprozesse und Effekte auf den YCbCr - Speicher zugreifen und dort wirken (solche Effekte sind in Pr mit "YUV" gekennzeichnet), andere im RGB-Speicher arbeiten. Beide Speicher werden ständig synchronisiert.
danke für diese technisch präzise Antwort :-)
Jetzt weiß ich auch endlich mal, was Adobe Premiere da macht, das war mir immer ein Rätsel.
Weißt Du denn auch, wie es beim Export aussieht? Denn da steht ja nirgends dabei, ob es RGB oder 601/709 ist. Gibt es deswegen die Bezeichnung mpeg-2 und mpeg-2 DVD? Ich dachte bisher, dass das nur Voreinstellungen für den Export sind - oder ist damit auch ein Farbraum verknüpft?
das verwendete Farbmodell wird nicht von Premiere Pro vorgegeben, sondern vom Exporter. Zum Schluß ist es der benutzte Codec, der das Modell und den Farbraum vorgibt.
Bei manchen Formaten (z. B.AVI) kann man den zu verwendeten Codec anwählen. Einige dieser Codecs erlauben es dann zwischen RGB, RGBA oder YUV zu wählen.
Bei wenigen Formaten geht nur RGB (meist Bildsequenzen wie TIFF), bei den meisten anderen nur YUV (auch JPEG ist übrigens YUV). Dann sind keine Codec-Einstellungen möglich.
Schau also: Sind Codec-Einstellungen möglich? Wenn ja, welche.
Wenn nein: Produziere einfach eine Test-Ausgabe und schau hinterher mit einem Tool wie Media-info oder so mal in die Datei. Dort wirst Du die Infos dazu finden.
Und zu Youtube, Vimeo & Co.: Wähle als Format einfach H.264. Premiere Pro bietet dann mehrere passende Vorgaben (Presets) mit optimierten Einstellungen für die Videoplattform. Auswählen, exportieren, hochladen.
Das wird dann wohl PAL, YUV, BT.709 in den gewünschten Framesizes und Datenraten sein. Und das ist richtig so und völlig okay. ;)
Und nicht nur für die genannten Videoportale, sondern ganz allgemein fürs Web.
Blackeagle123 hat geschrieben:danke für diese technisch präzise Antwort :-)
Das war wohl gegen mich gerichtet. Vielen Dank.
Du musst immer sehen, ich bin hier einer der wenigen, die auf beiden Systemen zu hause sind. Mir fällt daher auf, wenn jemand totalen Kokolores erzählt.
Blackeagle123 hat geschrieben:Jetzt weiß ich auch endlich mal, was Adobe Premiere da macht, das war mir immer ein Rätsel.
Glaubst du wirklich, was Reiner so beschreibt?! Na, viel Spass.
Nochmal zurück zum Web: Das ist ja auch ein weites Feld und Video in Browsern produzieren eine Menge Fehler. Was *erwartet* aber nun Youtube und Co.?
Vielleicht sagt man am genauesten: RGB 0-255 mit einem Videolevel von 16-235. Ich finde diese Einschränkung wichtig, da es Konstellationen gibt (aus Premiere heraus hab ich das mal getestet), dass Weisswerte oberhalb von 235 sichtbar werden (gemacht werden können). Aus Avid hab ich das noch nicht probiert, (der sagt ja, dass er abschneidet) mach ich vielleicht mal.
Edit: ich sprech hier natürlich von DNxHD RGB.
Für DVD: Ich gehe für DVD auch immer über DNxHD RGB aus dem Avid und über Sorenson Squeeze in Encore (oder direkt in Encore).
So funktionieren die beiden Welten ZUSAMMEN.
Nochmal zu RGB 0-255: Einige Avid User verstehen das so, jetzt zwischen 0 und 255 farbkorrigieren zu können/sollen. FALSCH.
Premiere: Als Beispiel der Export nach h264: Habe ich hier Lumawerte oberhalb von 235, so werden sie im Video nicht verändert. Sie werden aber nicht angezeigt (sind da, kann man *sichtbar* machen. Auch nach Premiere re-importieren). Bei DNxHD (RGB) sind die Werte weg, abgeschnitten.
Zwei Codecs, unterschiedliche Vorgehensweisen. Unpräzise Beschreibung ;)
dienstag_01 hat geschrieben:
Du musst immer sehen, ich bin hier einer der wenigen, die auf beiden Systemen zu hause sind. Mir fällt daher auf, wenn jemand totalen Kokolores erzählt.
...
Glaubst du wirklich, was Reiner so beschreibt?! Na, viel Spass.
Ich kenne viele, die meinen, wenn sie ein Werkzeug besitzen, dass sie es auch beherrschen. ;)
Beantworte lieber meine Fragen. Erklär mir endlich , wie die RGB-Angaben im Infofeld von Ae zustande kommen. Bitte!
Denn Du behauptest durchgehend allen Ernstes, dass das nicht geht. Und eben genau das ist FALSCH. Hätte dir ja eigentlich AUFFALLEN müssen ... ;)
dienstag_01 hat geschrieben:
Nochmal zurück zum Web: Das ist ja auch ein weites Feld und Video in Browsern produzieren eine Menge Fehler. Was *erwartet* aber nun Youtube und Co.?
Vielleicht sagt man am genauesten: RGB 0-255 mit einem Videolevel von 16-235. Ich finde diese Einschränkung wichtig, da es Konstellationen gibt (aus Premiere heraus hab ich das mal getestet), dass Weisswerte oberhalb von 235 sichtbar werden (gemacht werden können). Aus Avid hab ich das noch nicht probiert, (der sagt ja, dass er abschneidet) mach ich vielleicht mal.
Edit: ich sprech hier natürlich von DNxHD RGB.
Werde bitte konkret: Was lädts Du nach Youtube oder sonstwo ins Web hoch? DNxHD? Könnte ja ein Ansatz sein ...
dienstag_01 hat geschrieben:
Für DVD: Ich gehe für DVD auch immer über DNxHD RGB aus dem Avid und über Sorenson Squeeze in Encore (oder direkt in Encore).
So funktionieren die beiden Welten ZUSAMMEN.
Und? Ich benutze für die Zwischendateien gerne einen Uncompressed. Damit kann die DVD aber auch nichts nichts anfangen.
Dienstag, spannend ist doch: Was ist schließlich auf der DVD drauf?
Welches Format? Welches Farbmodell? RGB?
Wenn man das weiß kann man auch gleich in diesem Format aus Pr exportieren und kann dann ohne neue Transkodierung brennen.
Sag also bitte ganz einfach, was zu produzieren ist. Für den Upload nach Youtube, für den Upload ganz allgemein ins Web und für das Brennen auf DVDs. ;)
Ach ja: Mich würde interessieren: Welche Fehler das sind, die da in Mengen in Videos in Browsern auftreten sollen. Kannst Du das näher ausführen und belegen?
Sag also bitte ganz einfach, was zu produzieren ist. Für den Upload nach Youtube, für den Upload ganz allgemein ins Web und für das Brennen auf DVDs. ;)
Reiner, als REINER (!!!) Adobe-User musst du nur aufs jeweilige Knöpfchen drücken, dann funktioniert alles. Ist mein Ernst.
Was aber falsch ist, sind deine teils obskuren technischen Auslassungen. Lies dir nochmal den Absatz von TheBubble hier auf Seite 2 im Thread durch und akzeptiere, dass an irgendeiner Stelle der SPRUNG des Videofarbraums mit 16-235 zum Computerfarbraum mit einer Range von 0-255 stattfinden muss. Adobe macht den eiinfach im Hintergrund, eher unbemerkt von den Nutzern, man kann auch sagen, sie werden mit solchen Fakten nicht behelligt (Avid geht da einen anderen Weg, ob der nun besser oder schlechter ist, sei mal dahingestellt).
Jetzt gibt es aber Leute, die sagen, ich hab doch gehört, die Norm für Video ist 16-235 (Vielleicht, weil sie eine DVD machen wollen).Wieso zeigt mir mein After Effects für Weiss 255 an, obwohl es doch 235 sein sollte? Ab da wird es kompliziert. Du führst zum Verständnis Formeln ein und fängst an Unterschiede zu beschreiben, wo es keine gibt, siehe Luma 235 ist in der RGB Parade Luma 255 - ist technisch und logisch Quatsch.
Man sollte versuchen, die Schwierigkeiten klar zu sehen und zu beachten. Sobald du mal über einen externen Dienstleister/Studio gehen musst, bei dem du nicht einfach den Abgleich: Premiere? Premiere! machen kannst, tauchen manche Probleme sicher gar nicht auf. Ab dem Punkt oder wenn hier Leute mit anderer Software arbeiten, wirds WIRKLICH kompliziert (und falsch).
Sag also bitte ganz einfach, was zu produzieren ist. Für den Upload nach Youtube, für den Upload ganz allgemein ins Web und für das Brennen auf DVDs. ;)
Reiner, als REINER (!!!) Adobe-User musst du nur aufs jeweilige Knöpfchen drücken, dann funktioniert alles. Ist mein Ernst.
Dienstag, sind Dir die Antworten etwa unangenehm? ;)
Web: H.264, YUV (ist inzwischen praktisch defacto-Standard dafür, mit OpenSource versucht man die Lizenz-Probleme zu umgehen, hat sich aber noch nicht durchgesetzt. Ist aber auch YUV)
DVD: MPEG2, YUV
Da kommt nirgends RGB vor. Alle Hinweise in diese Richtung münden in falsche oder ungenaue Informationen und verunsichern m. E. nur die User.
----------
RGB ist nur nötig zur Bearbeitung der Videos in der Timeline und um z. B. in bestimmten Workflows Zwischenergebnisse zu produzieren (beispielsweise dafür, wenn im Compositing Alpha-Channels gebraucht werden, oder für Datenaustausch, oder für Spezialaufgaben, u.ä.).
Selbstverständlich erscheint das YUV-Video dann in RGB auf dem PC- Bildschirm. Sowohl im Browser wie auch vom PC-Software-DVD-Player. Aber das machen Software-Umsetzer in den Playern, die Y16-235 in aller Regel nach RGB0-255 umrechnen (ja, Weiß ist dort auch 255/255/255, was ja Deiner Meinung nach gar nicht sein dürfte, oder?)
RGB ist m. E. in der Videoproduktion der Zielformate kein Thema für diese Aufgaben (web/dvd). Punkt.
----------
dienstag_01 hat geschrieben:
Wieso zeigt mir mein After Effects für Weiss 255 an, obwohl es doch 235 sein sollte? Ab da wird es kompliziert. Du führst zum Verständnis Formeln ein und fängst an Unterschiede zu beschreiben, wo es keine gibt, siehe Luma 235 ist in der RGB Parade Luma 255 - ist technisch und logisch Quatsch.
Inhaltlich ist das Quatsch, Dienstag.
Erstens soll es nicht RGB 235 sein. Nur bei Dir. Bei AE-Usern nicht. ;)
Wenn es sollte, würde man einfach den Zielfarbraum begrenzen. Es soll ja aber nicht. Ich will ja keine Vorteile im Workflow verschenken.
Zweitens: Es gibt in RGB kein Luma! Nur Farbe. Tja, so ist das. ;)
Auch RGB 255/255/255 ist eine Farbe, zusammengesetzt aus drei einzelnen Farbwerten.
Der Y-Kanal geht bei der Berechnung gleichzeitig in die unterschiedlichen RGB-Farbkanäle ein und darin auf. Da passiert aber nix 1:1. Sondern komplexe Floating-Berechnung erledigen das. ;)
Vielleicht solltest Du Dich doch mal über die Umrechnung zwischen den Farbmodellen informieren? Egal, Du magst halt nicht ... - weißt ja, wie es richtig geht - verräts es aber nicht. ;)
Denn noch steht sie aus die Antwort, auf die ich bestehen muss, weil Du behauptest, ich läge falsch und Dich daran hochziehst. Deine Chance Nr. 5 (oder so): Beweise es!
Wie erklärst Du den RGB-Wert 255 in Ae in einem REC.709-Video-File?
Bitte konkret!
Und ohne den ausweichenden Hinweis auf "kompliziert". Ist es nämlich nicht. ;)
dienstag_01 hat geschrieben:
Man sollte versuchen, die Schwierigkeiten klar zu sehen
Ich sehe sie. O ja. ;)
Wie wärs mit Grillwurst, Bier und ein wenig Fachsimpeln über Ae und Avid? Die Einladung steht nach wie vor. Würde mich echt freuen. :)
Reiner M hat geschrieben:Zweitens: Es gibt in RGB kein Luma! Nur Farbe. Tja, so ist das. ;)
Auch RGB 255/255/255 ist eine Farbe, zusammengesetzt aus drei einzelnen Farbwerten.
Der Y-Kanal geht bei der Berechnung gleichzeitig in die unterschiedlichen RGB-Farbkanäle ein und darin auf. Da passiert aber nix 1:1. Sondern komplexe Floating-Berechnung erledigen das. ;)
RGB255 heisst: Rot:255, Grün: 255, Blau:255.
Und das sind die LUMAWERTE. HELLIGKEIT. 1:1. Nix, komplexe Floating-Point-Berechnung. Junge, Junge.
Reiner M hat geschrieben:Wie erklärst Du den RGB-Wert 255 in Ae in einem REC.709-Video-File?
Bitte konkret!
Hab ich dir schon mal geschrieben (Du kannst dir übrigens auch den Color Picker von Photoshop nach Premiere holen, egal): 255 in der Ansicht heisst 235 im Video. So ist der Standard. ich hab ihn nicht gemacht ;)
(Und das der Austausch von Premiere nach AE so gut klappt, du solltest dich bei Adobe bedanken.)
Edit: Für Web und DVD bin ich von der Spezifikation Rec709 als Norm ausgegangen. Jetzt fällt mir gerade auf, dass du so auf RGB und YUV rumreitest. Verstehe ich dich richtig, dass du annimmst, dass YUV 16-235 sozusagen RGB 0-255 ist?
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.
