WoWu hat geschrieben:
Schon der Umstand dass Du korrigieren musstest zeigt, das was falsch war.
Naja, ich habe wie fast überall empfohlen (z.B. Philipp Bloom, Fenchel & Janisch etc.) mit einem "flachen Picture-Profil" gefilmt. Hier war es das Canon Neutral-Profil mit völlig heruntergeschraubtem Kontrast, null Schärfe und leichter Entsättigung. Es ist doch so "zwangsläufig" notwendig, dass man in der Post Kontrast und Schärfe verändert!
a) die Aussage, die Du zitierst, ist von WoWu, nicht von mir. ;)
b) Wissenschaft ist immer nur ein Spiegel der Zeit. Natürlich wird sie sich weiterentwickeln. Es ist ein immer währender Prozess. Wir werden schon nicht so einfältig sein, dass wir glauben, wir hätten die Weisheit mit Löffeln gefressen, und dass unsere Modelle für alle Zeiten gültig sind. Das würde bedeuten, wir sprechen den kommenden Generationen genau die Fähigkeiten ab, die wir für uns selbst so gern in Beschlag nehmen und die uns bis hier hin geführt haben. Die, die nach uns kommen, sind dann selber groß und werden selber denken - und womöglich anders, als wir heute.
WoWu hat geschrieben:Hallo Reiner.
So ganz kann ich die Brücke zu den Kompromissen nicht schlagen weil jedes Verfahren schon seine "Regeln" hat und innerhalb derer die verfahren auch gut, nachvollziehbar und wiederholbar funktionieren.
Hallo Wolgang,
Klar hat es "Regeln".
Nehmen wir kurz die Grauskala. Du hast 220 hart von einander getrennte Werte, um sie vollständig abzubilden. Für mich ist das - bezogen auf die Realität! - ein heftiger "Kompromiss". Nicht? - Das ist sicher kein "Anwenderfehler".
Wenn jetzt bei Berechnungen Zwischenwerte auftreten, werden sie wegen des Integer-Formats der Speicherwerte gerundet - also verfälscht. Ein weiterer Kompromiss. Auch da kann der Anwender gar nichts für. Liegt an der Art, wie diese Daten verarbeitet werden können. Nach Regeln der Informatik.
Die Hersteller versuchen nun, Wege zu finden, die den Regeln der Videobearbeitung folgen, aber derartige Kompromisse minimieren unter Nutzung der Möglichkeiten, die die Informatik bietet.
Ich würde das nicht Kompromiss nennen, es gibt ja bessere Verfahren.
Wenn Du ein Fahrrad kaufst, hast Du ja (normalerweise) auch nicht im Hinterkopf ,damit - statt eines Autos- mit der Familie damit in urlaub zu fahren.
Ich denke, wer sich für 8 Bit entscheidet, sollte 10 oder 12 Bit nicht hinterher heulen und auch nicht versuchen, es mit Verdeckung nachzuahmen.
Insofern ist es für mich kein Kompromiss, sondern ein in sich schlüssiges System. -Eben wie ein Fahrrad-
@@ Stephan
Solche Empfehlungen auszusprechen heisst nicht gleichzeitig zu wissen, was die Konsequenzen sind.
Die wenigsten Anwender haben das Videothema wirklich durchdrungen.
Aber es gibt auch in 8 Bit genügend Beispiele, wo feine Verläufe unbeschädigt über den Bildschirm gehen. Nur sind 8Bit eben an der Grenze dessen, was vom Mensch noch (so eben) als "nicht stufig" wahrgenommen wird.
Und einige Sachen funktionieren eben schon nicht.
Darauf sollten die Empfehlungen, wenn sie substantiell sind, auch hinweisen, bevor man unbesehen solche Profile anpreist.
Denn der Umgang mit den "flachen" Übertragungskurven, sollte schon beherrscht werden, bevor man da einsteigt.
Aber das ist oft leider oft nicht das Ziel solcher Werbeveranstaltungen.
Die Tage von 8 Bit sind ja ohnehin auch bald gezählt und ein paar Probleme damit dann auch schon fast Vergangenheit.
Mir scheint, wir befinden und noch in der Steinzeit der Videotechnologie. So wie damals, als man als Schüler noch verstehen und lernen musste (Allgemeinbildung), wie der Rund-Funk (so mit funkendem Lichtbogensender) im Innersten funktioniert.
Ja hallo wo sind wir denn heute?
Interessiert uns z.B. wie die Datenübertragung beim Smartfon funktioniert?
Beim Auto wird der Diagnosestecker und der Werkstätten-PC aktiviert.
Die Zeiten sind vorbei, als man die Unterbrecherkontakte noch mit Feinschleifpapier abhobelte und mit Zigarrettenpapier die Vorzündung einstellte.
Auf diesem Stand aber wollen uns einige „Spezialisten“ einreden, dass man nach Faust erkennen müsste, was die Video-Welt im Innersten zusammenhält, einfach grotesk ...
Ja, das merkt mann, dass die meisten nur noch den Startknopf drücken wollen, ihr Film aber hinterher wie der neuste Blockbuster aussehen soll.
Das hat schon beim 8mm Schmalfilm nicht geklappt.
Die sehen heute noch aus wie Omas Geburtstag.
Damals brauchte man genauso Ahnung und gutes Equipment, wie heute.
Da hat sich nichts geändert.
Muss ja auch nicht. Wer mit 8 Bit eine Nachtdämmerung aufnimmt und davon ausgeht, dass es wie in 12 Bit aussieht, hat sich eben das Fahrrad zur Urlaubsreise gekauft.
Dann muss er damit leben.
Dumm gelaufen, kann man da nur sagen.
Er hätte sich ja mal informieren können, ob das so reibungslos geht.
Ja hallo wo sind wir denn heute?
Also ich bin in der Gegenwart angekommen.
Wo Du noch bist, kann Du vermutlich nur selbst sagen.
Insofern trifft das "wir" nicht zu. Du musst fragen, wo "Du" bist.
Was ist eigentlich das Problem?
(mal vom pissing contest abgesehen (; ...)
-OP hat Banding im Clip.
(ob man dies nun durch optimierte Kameraeinstellungen vermeiden kann, ist zunächst egal, wenn auch zu empfehlen)
-Lösung:
Grain,Dither, Blur und Farbkorrekturen
-professionelle Arbeitsweise:
Das 8Bit Material in 32bit float wechseln
(dies ist keine Farbraumkonvertierung, nur eine Bittiefenveränderung!).
Hierdurch werden die vorher extrem groben 8 bit Abstufungen wesentlich feiner.
-Dann die Lösung anwenden.
-Ausgabe im Zielformat und Farbraum, nach Angabe des Empfängers (z.B. Youtube)
-Fertig.
So, nun zum Farbraum, der getrennt von Bittiefe zu verstehen ist.
YCbCr->RGB (oder umgekehrt):
Es wird hier von einem Verfahren gesprochen das in 8Bit integer die YCbCr Werte (16-235 pro Kanal) auf RGB (0-255 pro Kanal) wandelt.
Hierbei werden ganz offensichtlich, wie Reiner sagte, die Werte 0-15 und 236-255 abgeschnitten und gehen bei einer Rückwandlung verloren.
Dies schneidet alle illegalen Farben raus und zerstört Zusatzinformation, die in den Werten sind.
DUMMES VERFAHREN! Finger weg.
Zudem werden 220 Einzelwerte auf 256 umgerechnet.
Das ist Interpolation, auch / gerade wenn es die Formel nutzt, es füllt Bereiche auf, die nicht gespeichert sind.
Zurück zur Bittiefe:
Die illegalen Werte werden übrigens auch bei 16/32bit integer abgeschnitten.
Bei signed integer rettet man immerhin die (8bit) 0-15 Werte, da die ins negative rutschen.
Die (8bit) Bereiche 236-255 sind dennoch futsch da ja bereits 235 auf 65536 landet (das 16Bit Maximum) oder 235 auf 4294967296 landet(das 32bit Maximum).
Erst wenn man signed float (egal ob 16 oder 32 bit) benutzt, können alle "Überlaufswerte" erhalten bleiben.
Unverständnis:
Wenns' denn schon sein muß, warum wandelt man nicht einfach YCbCr 0-255 auf RGB 0-255.
Dann bleibt alle Information erhalten und man verwirrt sich nicht selbst und zerstört nicht sein Signal dabei.
Nun erhöhe die Bittiefe auf 32bit float und wende Lösung an.
FERTIG.
edit:
ach ja, wenn man dann ein legales Signal ausgeben möchte, dann clamped man einfach die illegalen Werte bei der Ausgabe.
Ein Szenario, bei dem ich mir das 16-235 auf 0-255 Verfahren Sinnvoll vorstellen kann ist, wenn die Kamera das Signal 100% Weiß auf 235 legt und 100% Schwarz auf 16
Wenn nun aber über- bzw. unterbelichtete Bereiche in den Rest gefüllt werden, ist wieder ein 0-255 auf 0-255 zu empfehlen.
enrico perei
motion picture visual effects and stereoscopic 3D
lead, supervision, artistic & consultancy services
Ihr seid echt BRUTAL!!! Ganz ehrlich, ihr braucht ein eigenes Forum!
Ich habe mir echt alles durchgelesen, einiges verstanden, dann aber wieder nicht! Am Ende ist man total verwirrt, weil ständig widersprochen oder von anderen Ausgangsituationen, Umständen geredet wird usw. Ihr seid echt zu KRASS!!!
Ich kleiner Wicht traue mich dennoch mal dazwischenzugrätschen! Das Material aus meiner 700D ist ja laut Aussagen einiger User hier REC709 (16/235). Ich habe den Clip nun einfach mal nur in AE importiert, nichts verändert und in H264 exportiert. Ergebnis: der aus AE exportierte Clip ist kontrastloser als das Original. Auch in der Vorschau in AE sieht man bereits, dass es blasser aussieht.
1. Ich meine hier gelesen zu haben, dass mein gewählter Export-Codec H264 auch wieder "nur" Rec709 mit 16-235 bietet. Warum ist der Clip aber dann heller und kontrastärmer als der Original-Clip? Liegt das daran, dass er von Rec709 (16-235) zu RGB (0-255) und beim Export wieder zu Rec709 (16-235) umgewandelt wird? Oder habe ich das jetzt total falsch verstanden?
2. Kann man die Vorschau oder den Farbraum in AE ändern, sodass der importierte Clip genauso kontrastreich aussieht wie wenn das Original mit einem Software-Player abgespielt wird? Oder ist dieser Helligkeits- bzw. Kontrastunterschied nach dem Import völlig normal?
3. Wird nun durch den bloßen Import schon an den Farben und Kontrasten gedreht bzw. das Material negativ "belastet" oder sozusagen nur "anders" dargestellt?
4. Wenn ich nun Rec709-Material habe, wie sollte ich dann meine AE-Komposition einstellen? Wie sollte der Workflow aussehen, damit das Material so wenig wie möglich hin- und hergewandelt wird?
Wenns' denn schon sein muß, warum wandelt man nicht einfach YCbCr 0-255 auf RGB 0-255.
Dann braucht man aber eine Kamera, die R'dG'dB'd kann.
Das ist aber kein Videostandard und ich kenn auch keine Kamera, die das macht.
Nur wer unbedingt die FullRange haben will, soll doch vxYCC machen.
Ist doch alles da.
@Stephan
Weil AE gern in RGB arbeiten möchte damit es mit den üblichen Grafikmedien zusammenarbeiten kann und in der Umrechnung liegt der Hase begraben.
EnricoPerei hat geschrieben:-OP hat Banding im Clip.
(ob man dies nun durch optimierte Kameraeinstellungen vermeiden kann, ist zunächst egal, wenn auch zu empfehlen)
Der OP hat komplett synthetisch generiertes Material :-)
pixler hat geschrieben:Tach allerseits,
Ich habe ein AfterEffects Projekt (reine Grafik, kein Video) in 16 Bit erstellt und das Master in 10Bit (ProResHQ) exportiert.
Irgendwann hat mal jemand dann noch was zu Kameras gefragt und das war dann Ansporn genug ;-)
Stephan82 hat geschrieben:Ich hänge mich mal an das Thema dran, weil ich mit Banding oder Blocking selbst immer wieder Probleme habe. Was genau was ist kann ich als Anfänger auch nicht unterscheiden.
Hier mal 2 Screenshots aus After Effects. Footage stammt von einer 700D@1080p@H264.
@Stephan82 immer mit der Ruhe ;-)
1) Du musst mal schauen wie AE das Material interpretiert (decoding) und verarbeitet (Ausgabe). --> AE-Handbuch/Hilfe
2) Und du musst schauen wie interpretiert der Decoder mit dem du das Material abspielst (also der Codec/media-player den du verwendest). --> Media-Player verwenden wo das genau eingestellt werden kann (MPC z.B.)
Versuch das alles ausfindig zu machen - sonst drehst du an mehreren Stellen ohne Ziel..
EnricoPerei hat geschrieben:
Zudem werden 220 Einzelwerte auf 256 umgerechnet.
Das ist Interpolation, auch / gerade wenn es die Formel nutzt, es füllt Bereiche auf, die nicht gespeichert sind.
Enrico, das ist falsch. Da wird nichts interpoliert. Hast Du die Formel verstanden?
Denke vielleicht auch noch mal darüber nach:
Wie viele Bytes hast Du in YCbCr in den Chrominanzkanälen, die "Blau" bedeuten (Sättigung)? Und wie viele Bytes stehen Dir ingesamt zur Verfügung, um einen "Blau"-Ton zu erzeugen (Sättigung * Helligkeit)?
Vergiss bitte die Idee, dass die Wertebereiche "16-235" in YCbCr und RGB identische Inhalte hätten, oder wenigstens solche, die quasi 1:1 zugeordnet werden könnten.
EnricoPerei hat geschrieben:
Zurück zur Bittiefe:
Bei signed integer rettet man immerhin die (8bit) 0-15 Werte, da die ins negative rutschen.
Erst wenn man signed float (egal ob 16 oder 32 bit) benutzt, können alle "Überlaufswerte" erhalten bleiben.
Das stimmt, aber Signed Integer kommt in Premiere Pro und After Effects nicht vor. 16bit-Float gibt es dort auch nicht.
Also 32bit, und alles ist gut.
EnricoPerei hat geschrieben:
Unverständnis:
Wenns' denn schon sein muß, warum wandelt man nicht einfach YCbCr 0-255 auf RGB 0-255.
Das wird ja auch gemacht. Z. B. bei JPEG. Da liegt das Bild dann aber auch in Y0-255.
Aber eben nicht bei Videos die in YCbCr nach REC.709 gespeichert sind.
Da liegt das Bild im dafür definierten Bereich Y16-235. Alles außerhalb, gehört nicht zum Bild, das ein Wiedergabegerät ausgeben soll, wenn es auch nach REC.709 arbeitet.
Stephan82 hat geschrieben:
Naja, ich habe wie fast überall empfohlen (z.B. Philipp Bloom, Fenchel & Janisch etc.) mit einem "flachen Picture-Profil" gefilmt.
Es gibt in AE unter Effekte-> Farbkorrektur -> Belichtung.
Hast Du den schon mal probiert?
@Stephan82
Wenn du Probleme mit dem Kontrast hast, die auf Fehlinterpretation von 16-235 hindeuten, schau dir den Clip in verschiedenen Playern an. Überall gleich?
Darüber hinaus gibt es ein Tool, 5DtoRGB, kann man sich runterladen, da kann man die bewusst von Canon falsch implementierte Farbraummatrix fixen. Kann man mal ausprobieren (ich selbst hab es nur einmal flüchtig getan und keine wirklich signifikanten Unterschiede festgestellt).
Und, Quicktime auf einem halbwegs aktuellen Stand?
Für alle anderen, die Interesse an der Diskussion, wie Adobe arbeitet haben, hier gehts weiter ;)
Was habe ich gemacht:
Ein 8bit File importiert (h264). Man sieht deutlich die Werte (WFM) im Head- und Footroom, in der Videovorschau nicht.
Dieses 8bit File mit dem FastColorEffect bearbeitet. der Effect arbeitet in 8, 16 und 32 bit.
Adobe beschreibt in seinen Blogs, wie man Premiere Effekte in 8bit rechnen lässt, am Beispiel eines DV Files:
Steve Hoeg, one of the Premiere Pro engineers, provided some examples of how Premiere Pro will handle color precision in different scenarios: 1. A DV file with a blur and a color corrector exported to DV without the max bit depth flag. We will import the 8-bit DV file, apply the blur to get an 8-bit frame, apply the color corrector to the 8-bit frame to get another 8-bit frame, then write DV at 8-bit.
Ich habe also Das Flag für Maximale Bittiefe ausgeschaltet, Premiere rechnet in 8 bit.
Das Ergebnis ist, das File hat die Korrekturen, die es nach Meinung einiger gar nicht haben dürfte, berechnet.
In einem weiteren Test habe ich das File ohne Korrekturen exportiert (h264). Auch hier ist der Head- and Footroom beibehalten.
Was heisst das nun.
Sollte Premiere die Videouelle beim Import von 16-235 nach 0-255 mappen, gäbe es in 8 bit diese Werte gar nicht.
Das wiederum kann nur heissen, dass Premiere die Werte so lässt wie sie sind und nur die Vorschau nach 0-255 mapped. Es werden also keine Werte verändert (es wird eine Art LUT für die Vorschau angewendet), was ein signifikanter Unterschied ist. Aber eben für die Berechnung auch besser.
Desweiteren liegt jeder falsch, der annimmt, für die Verwendung (*Nutzbarmachung*) der Headroom-Daten wären 32 oder 16bit zwingend notwendig. Man solte es in Premiere natürlich trotzdem tun, aber es funktioniert auch in 8bit ;)
Alles klar?!
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Zuletzt geändert von dienstag_01 am Mo 11 Aug, 2014 23:37, insgesamt 2-mal geändert.
domain hat geschrieben:Interessiert uns z.B. wie die Datenübertragung beim Smartfon funktioniert?
Natürlich. Dich etwa nicht?
domain hat geschrieben:Auf diesem Stand aber wollen uns einige „Spezialisten“ einreden, dass man nach Faust erkennen müsste, was die Video-Welt im Innersten zusammenhält, einfach grotesk ...
Muss man nicht. Man kann die Programme natürlich einfach so benutzen, wie sie sind. Aber dann versteht man auch nie, warum die Programme etwas tun und wie sie es tun und warum man als Benutzer für ein optimales Ergebnis bestimmte Dinge lassen sollte.
Mit etwas Grundlagenwissen kann man auch leichter entscheiden, welches Programm man sich kaufen sollte und was man erwarten kann.
Es stellt sich sowieso die Frage, ob ein Forum dazu da ist, dass einige Leute lediglich sagen: "lies erstmal das Manual" oder "probiere doch aus" oder irgendwelche Marketingsprüche dummschwätzig wiederholen, ohne selbst zu wissen was sie eigentlich genau bedeuten oder ob nicht so eine Diskussion,-auch wenn sie manchmal etwas in die Tiefe geht-, unter dem Strich nicht doch die bessere Variante auch für "Einsteiger" ist und dem Zweck einer solchen Plattform sehr viel näher kommt.
Was ich aber gar nicht verstehe sind die Typen, die 10 Seiten lesen und dann so einen Schmarn von sich geben.
Wenn Sie's nicht verstehen, zwingt sie doch keiner weiter zu lesen.
Sollen sie doch ihre Zeit besser nutzen und ein Bier trinken, dann haben sie wenigstens anschliessend noch den Flaschenpfand.
EnricoPerei hat geschrieben:
-professionelle Arbeitsweise:
Das 8Bit Material in 32bit float wechseln
(dies ist keine Farbraumkonvertierung, nur eine Bittiefenveränderung!).
Genaugenommen bedeutet dies sogar mehr als nur mit zusätzlichen Bits zu arbeiten, da sowohl negative als auch große Werte erhalten werden können. Floats verhalten sich allerdings anders als Integers, die darstellbaren Zahlenwerte sind nicht gleichmäßig verteilt.
EnricoPerei hat geschrieben:
Hierdurch werden die vorher extrem groben 8 bit Abstufungen wesentlich feiner.
Das ist leider falsch.
EnricoPerei hat geschrieben:
Es wird hier von einem Verfahren gesprochen das in 8Bit integer die YCbCr Werte (16-235 pro Kanal) auf RGB (0-255 pro Kanal) wandelt.
Hierbei werden ganz offensichtlich, wie Reiner sagte, die Werte 0-15 und 236-255 abgeschnitten und gehen bei einer Rückwandlung verloren.
Dies schneidet alle illegalen Farben raus und zerstört Zusatzinformation, die in den Werten sind.
DUMMES VERFAHREN! Finger weg.
Dies ist bei einer 8-Bit-Verarbeitung der einzig machbare Weg. Lediglich durch einen konsequent genutzten erweiterten Wertebereich lassen sich diese Informationen erhalten.
Nebenbei: Nicht nur durch das "Abschneiden" gehen Informationen verloren, 8-Bit-BT.709-YCbCr kann im Prinzip Farben beschreiben, die nicht im 8-Bit-BT.709-RGB-Würfel liegen.
EnricoPerei hat geschrieben:
Zudem werden 220 Einzelwerte auf 256 umgerechnet.
Das ist Interpolation, auch / gerade wenn es die Formel nutzt, es füllt Bereiche auf, die nicht gespeichert sind.
Das hat nichts mit Interpolation zu tun. Es ist lediglich eine Spreizung des Wertebereichs durch Multiplikation mit einer konstanten Zahl.
EnricoPerei hat geschrieben:
Erst wenn man signed float (egal ob 16 oder 32 bit) benutzt, können alle "Überlaufswerte" erhalten bleiben.
Im Grunde richtig, aber man kann sich natürlich auch ein Integer-Format definieren, dass nach oben hin genügend Spielraum lässt.
EnricoPerei hat geschrieben:
Wenns' denn schon sein muß, warum wandelt man nicht einfach YCbCr 0-255 auf RGB 0-255.
Macht man ja - für die Ausgabe.
Es ist nur eben so, dass im Digital-Video-Bereich aus historischen Gründen ein kleinerer Wertebereich festgelegt ist. Wenn man mit derartigen Geräten kompatibel sein will, dann muss man dies halt so machen.
Für Neuentwicklungen, losgelöst von aller alter Technik, wäre ein Festhalten an diesen alten Vorgaben nicht unbedingt sinnvoll. Ich würde entweder Fließkommazahlen oder, wenn Integer-Werte (mit mehr als 8 Bit pro Sample), einen erweiterten Wertebereich mit Spielraum nach oben und unten hin für sinnvoll halten.
Allerdings: Die meiste Software beginnt nicht als völlig neue eigenständige Entwicklung.
Zuletzt geändert von TheBubble am Mo 11 Aug, 2014 23:53, insgesamt 1-mal geändert.
WoWu hat geschrieben:oder ob nicht so eine Diskussion,-auch wenn sie manchmal etwas in die Tiefe geht-, unter dem Strich nicht doch die bessere Variante auch für "Einsteiger" ist und dem Zweck einer solchen Plattform sehr viel näher kommt.
Die richtige Darstellung der Zusammenhänge ist eindeutig die bessere Wahl.
EnricoPerei hat geschrieben:Es wird hier von einem Verfahren gesprochen das in 8Bit integer die YCbCr Werte (16-235 pro Kanal) auf RGB (0-255 pro Kanal) wandelt.
Hierbei werden ganz offensichtlich, wie Reiner sagte, die Werte 0-15 und 236-255 abgeschnitten und gehen bei einer Rückwandlung verloren.
Dies schneidet alle illegalen Farben raus und zerstört Zusatzinformation, die in den Werten sind.
DUMMES VERFAHREN! Finger weg.
Dies ist bei einer 8-Bit-Verarbeitung der einzig machbare Weg. Lediglich durch einen konsequent genutzten erweiterten Wertebereich lassen sich diese Informationen erhalten.
Man kann in meinem weiter oben geposteten Beispiel sehen, dass keine Werte abgeschnitten werden. Die Grundannahme, dass YCbCr 16-235 auf RGB 0-255 gewandelt werden, ist für Premiere demnach nicht zutreffend. (was ja auch viel besser ist)
ich kapier zwar momentan auch nicht viel, warte noch auf entrauschtes footage, dann entscheide ich ob's sich überhaupt lohnt und wem man auch künftig zuhören sollte.
@ TO (offtopic)
darf man mal nachhaken, wie du entsättigt hast?
Über Kanalberechnungen oder nur so irgendwo ein sanftes, schnelles >>clicks'chen<< ...?
Oft ist bei solchen Geschichten (man lese: kann sein, muss nicht sein) aus der Praxis (man verstehe: also wenn das Kind schon in den Brunnen gefallen ist) ein dummer Klick zuviel dran.
mach mal n Standbild und zeig uns die drei Kanäle, und zwar als Bild, nicht als Diagramm. Ich hoffe, es zickt nur der Blaue (wie so oft).
dienstag_01 hat geschrieben:
Was habe ich gemacht:
Ein 8bit File importiert (h264). Man sieht deutlich die Werte (WFM) im Head- und Footroom, in der Videovorschau nicht.
Dieses 8bit File mit dem FastColorEffect bearbeitet. der Effect arbeitet in 8, 16 und 32 bit.
Adobe beschreibt in seinen Blogs, wie man Premiere Effekte in 8bit rechnen lässt, am Beispiel eines DV Files:
Steve Hoeg, one of the Premiere Pro engineers, provided some examples of how Premiere Pro will handle color precision in different scenarios: 1. A DV file with a blur and a color corrector exported to DV without the max bit depth flag. We will import the 8-bit DV file, apply the blur to get an 8-bit frame, apply the color corrector to the 8-bit frame to get another 8-bit frame, then write DV at 8-bit.
Ich habe also Das Flag für Maximale Bittiefe ausgeschaltet, Premiere rechnet in 8 bit.
Das Ergebnis ist, das File hat die Korrekturen, die es nach Meinung einiger gar nicht haben dürfte, berechnet.
In einem weiteren Test habe ich das File ohne Korrekturen exportiert (h264). Auch hier ist der Head- and Footroom beibehalten.
Was heisst das nun.
Sollte Premiere die Videouelle beim Import von 16-235 nach 0-255 mappen, gäbe es in 8 bit diese Werte gar nicht.
Das wiederum kann nur heissen, dass Premiere die Werte so lässt wie sie sind und nur die Vorschau nach 0-255 mapped. Es werden also keine Werte verändert (es wird eine Art LUT für die Vorschau angewendet), was ein signifikanter Unterschied ist. Aber eben für die Berechnung auch besser.
Desweiteren liegt jeder falsch, der annimmt, für die Verwendung (*Nutzbarmachung*) der Headroom-Daten wären 32 oder 16bit zwingend notwendig. Man solte es in Premiere natürlich trotzdem tun, aber es funktioniert auch in 8bit ;)
Alles klar?!
Nee, eben nicht klar! - Das heißt: MIR schon ... ;)
Dienstag, ....
Sorry, das ist leider komplett und durchgehend falsch!
Es beweißt einmal mehr: Die Grundlage ist falsch und und Du ziehst folglich die falschen Schlüsse daraus. Es erstaunt, mich wirklich, auf welche abstrusen Schlusssfolgerungen man kommen kann. :-(
Aber schauen wir mal kurz drauf, warum ich dieser Meinung bin.
Dass ich hier in dieser Diskussion mit DIR allerdings soweit in die GRUNDLAGEN von Premiere Pro einsteigen muss, hätte ich wirklich nicht gedacht! :-(
Aber gut. Immerhin: Der folgende Text ist für alle Premiere Pro Anwender interessant, die noch nicht wissen, wann Effekte für 8bit- und wann für 32bit-Verarbeitung sorgen werden. Und das sollte man unbedingt wissen.
----------
Aus der Premiere Pro Doku:
Hinweis:
32-bpc-Effekte werden nur mit 32 Bit pro Kanal gerendert, wenn alle anderen Effekte in der Render-Pipeline ebenfalls 32-bpc-Effekte sind. Wenn Sie einen 8-bpc-Effekt in einer Sequenz platzieren, die einen 32-bpc-Effekt enthält, werden alle Effekte in der betreffenden Sequenz von Premiere Pro mit 8 Bit gerendert.
Alles klar? (Wenn nicht: Die Adobe-Doku bietet weitere Erläuterungen dazu).
Jetzt muss man nur noch verstehen: Was ist was und wann passiert was?
Premiere Pro hat dafür in seiner Oberfläche leider keine direkte Anzeige, gibt aber in der Effekte-Liste SEHR WICHTIGE Hinweise dazu, die für den RICHTIGEN Workflow von großer Bedeutung sind. Sollte man sich unbedingt ansehen!
Schauen wir einfach in die Effekte-Liste. Als Hilfestellung liegt hier ein Screenshot bei, auf den ich mich nun beziehe.
Hinter jedem Effekt sind bis zu drei Symbole in drei Spalten zu sehen:
1. Symbol meint: Effekt ist GPU-(CUDA)-fähig. Wenn GPU-Rendern aktiv ist, rechnet dieser Effekt automatisch mit der Bittiefe 32bit. (genauer: mit der Bittiefe der Grafikkarte) Übrigens auch unabhängig von "Maximaler Bittiefe".
2. Symbol meint: Der Effekt rechnet in 32bit.
3. Symbol: Der Effekt arbeitet direkt in YCbCr-Speicher.
Wenn man einen Effekt einsetzen will, sollte man also hinsehen, was da markiert ist und wie es kombiniert ist. Das hat Folgen für den Workflow.
"Schnelle Farbkorrektur"
Der Effekt "Schnelle Farbkorrektur" arbeitet also a) direkt in YCbCR, und das in 32bit (!), und das in der Grafikkarte, sofern eingeschaltet.
Da kommt nun mal 32bit-Verarbeitung bei rum!
Und warum? Weil Adobe es so vorgibt und jeden Anwender mit den Symbolen darauf hinweist!
Dienstag, "FastColorEffect" ist "Schnelle Farbkorrektur", oder?
Dann ist Dein Beispiel oben ja gerade dafür der Beleg! Für eine 32bit-Verarbeitung. Und für nichts anders.
Du hast also den falschen Effekt für Deinen *Beweis* gewählt. Und dann daraus völlig falsche Schlüsse konstruiert. :-(
Korrigiere mich, wenns anders ist.
2. Beispiel
Schau in meinem Screenshot auf den Effekt "Färbung". Der ist nur mit dem Symbol "GPU-Verarbeitung" markiert, jedoch nicht mit 32bit.
Wie arbeitet dieser Effekt? In 8bit oder in 32bit? Erklärung dazu:
- Sobald GPU-Unterstützung in Pr aktiv ist, rechnet dieser Effekt in der Bittiefe der Grafikkarte, i. d. R. 32bit-Float, wenn Du eine Nvidia Quadro hast, so gar in 64bit-Float. Premiere Pro bleibt in 32bit, weil es die Daten aus der Graka dafür passend angeliefert bekommt und eben nicht in 8bit.
- Ist GPU-Unterstützung abgeschaltet, arbeitet dieser Effekt auf der CPU, und dort in 8bit. Erst jetzt fällt Premiere Pro in den 8bit-Modus. Weil es die Rechenergebnisse in 8bit angeliefert bekommt.
8bit-Effekte Nur die Effekte, die keine Symbole besitzen, sind echte 8bit-Effekte!
Beim Einsatz dieser Effekte fällt Premiere Pro in den 8bit-Modus (siehe meine Zitat aus der Doku oben).
Und zwar deshalb, weil es die Rechenergebnisse in 8bit bekommt. Es gibt bei diesen Effekten keine Möglichkeit, auf einer Hardware-Komponente (CPU, GPU) Float-Ergebnisse zu erzeugen.
--------
Das muss genügen, Dienstag. Kann man alles wunderbar in der Adobe-Doku nachlesen.
Dein Zitat über DV 8bit passt übrigens überhaupt nicht zum Thema und behandelt NICHT die Unterschiede zwischen 8bit- und 32bit-Modus in Pr.
Anders als Dein Beispiel, stützt sich meins oben auf genau die richtige Vorgehensweise. Schau noch mal hin, jetzt weißt Du ja, worauf es ankommt.
Nimm also für eigene Experimente bitte ganz einfach einen solchen echten 8-bit-Effekt und machs nochmal, ja? Alles andere ist Unsinn.
Und dann beantworte mir meine Fragen: Wo sind die Headroom-Daten hin? Und: Werden sie in einem daraus exportierten File enthalten sein? Ja oder nein?
Dann haben wir die RICHTIGEN Grundlagen geschaffen, und dann kannst Du noch mal über die RICHTIGEN Schlussfolgerungen daraus nachdenken ...
Aber ich schätze, Du wirst stattdessen das nächste Sonderkonstrukt anliefern ... bin sehr gespannt darauf. ;)
Beste Grüße,
Reiner
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Vorweg sollte man nochmal auf die Aussage des Adobe-Entwicklers verweisen, die beschreibt, dass man durch Ausschalten der Maximalen Bittiefe sehr wohl im 8bit Modus ist.
Nichtdestotrotz wird das hier angezweifelt. Na gut ;)
Ich habe jetzt mal einen reinen 8bit Effekt in die Bearbeitungs-Pipeline gesetzt und Cuda selbstverständlich ausgeschaltet. Jetzt ist alles *richtiges* 8bit.
Das Ergebnis ist, dass man die Werte aus Head- und Footroom sehr wohl *ins Bild* holen kann. Was ausschließt, dass beim Import die Werte auf 0-255 gemapped werden, sonst kämen die Werte in 8bit nicht vor.
Aber vielleicht gibt es ja nicht nur richtige 8bit-Bearbeitung, sondern *ganz, ganz richtige* 8bit-Bearbeitung ;)
Edit: Das Ausgangsfile für folgende Bearbeitung ist das erste Bild in meinem Post oben, die Lumawerte liegen im Head- und Footroom.
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
dienstag_01 hat geschrieben:Vorweg sollte man nochmal auf die Aussage des Adobe-Entwicklers verweisen, die beschreibt, dass man durch Ausschalten der Maximalen Bittiefe sehr wohl im 8bit Modus ist.
Nichtdestotrotz wird das hier angezweifelt. Na gut ;)
Dienstag, lass' es. Es führt zu nichts. Diese Themen sind erklärungsbedürftig (leider) und spielen hier keine Rolle.
Nur so viel: Es geht dabei um Fälle, in denen Assets, Videos oder Bilder, eine hohe Bittiefe mitbringen, und sicherzustellen ist, dass sie adäquat verarbeitet werden.
Lies bitte die Doku.
dienstag_01 hat geschrieben:
Ich habe jetzt mal einen reinen 8bit Effekt in die Bearbeitungs-Pipeline gesetzt und Cuda selbstverständlich ausgeschaltet. Jetzt ist alles *richtiges* 8bit.
Das Ergebnis ist, dass man die Werte aus Head- und Footroom sehr wohl *ins Bild* holen kann. Was ausschließt, dass beim Import die Werte auf 0-255 gemapped werden, sonst kämen die Werte in 8bit nicht vor.
Aber vielleicht gibt es ja nicht nur richtige 8bit-Bearbeitung, sondern *ganz, ganz richtige* 8bit-Bearbeitung ;)
Wie vorhergesehen: Ich habe nichts anderes erwartet!
Der nächste Sonderfall --- Hauptsache ausweichen, abschweifen und vom Hölzchen aufs Stöckchen kommen.
Und wieder die falschen Schlüsse ... Unglaublich!
Du hättest CUDA nicht abschalten müssen ... Schau einfach in die Effekte-Liste und auf die Symbole! Dein Effekt ColorBalance arbeitet eh nicht auf Cuda.
M. E. verstehst Du offensichtlich wieder NICHT, was Du eigentlich machst. Oder willst Du mich hier mutwillig veralbern?
Es geht um Effekte. Daran klebst. Du kannst in Premiere Pro nicht den Arbeitsbereich von 32bit auf 8bit umstellen! Deine Aussage dazu, dass sein nun echtes 8bit, ist einfach falsch! Oder kennnst Du irgendeinen Parameter der das erzwingt? Sag' jetzt bitte nicht "Maximale Bittiefe" ...
Es klebt an den 8bit-Effekten.
Nur zu Erklärung für Leute, die wirklich verstehen wollen, was in Deinem Beispiel abgeht, und das hat was mit der Abarbeitungsfolge von Effekten zu tun. Auch wichtig für den Workflow:
---------
Du hast in der Effektliste mit der 32bit-Farbkorrektur (Symbol in der Effektliste!) im Effektstapel VOR dem 8bit-Color-Balance den Tonwertumfang so verändert, dass die Head-/Footroom-Daten in den bildgebenden Bereich fallen.
Warum sollte das nicht gehen? Ist Dir klar, dass Effekte NACHEINANDER abgearbeitet werden? Liegt in der Natur der Sache. So ist die Computerei nun mal. Die Adobe-Doku erklärts ...
Also: Zunächst arbeitet Premiere Pro am Effekt Schnelle Farbkorrektur. Den folgenden Effekt kennt es zu diesem Zeitpunkt noch nicht (ja, so gehts nun mal in der Computerei). Es ist im 32bit-Modus.
Dann folgt der Effekt, der in 8bit gerechnet wird. Und nun ist Premiere Pro im 8bit-Modus. Verursacht allein durch diesen Effekt, durch sonst nichts.
Du konntest also die Daten aus Head- und Footroom wegen der Abarbeitungsfolge noch retten, danach gibts den nicht mehr.
In der Luma-Wave siehst Du immer das Ergebnis aller Berechnungen in Folge. Völlig richtig hier also 8bit. Aber nach der schrittweisen Verabeitung der Effekte.
Wenn Du sehen willst, wie sich Arbeitsschritte einzeln auswirken, schalte alle Effekte zunächst ab, und dann nacheinander von oben nach unten wieder an.
Preisfrage: Sind in der Luma-Wave Foot- und Headroom noch da? Ja oder nein? - Ich meine nicht die Daten, die du VORHER runtergezogen hast.
-------
Jetzt mal was zum Spielen an diesem Beispiel.
1. Drehe mal bitte nicht an den Parametern im Effekt Fast Color.. Wo sind Head- und Footroom? Exportiere das File. Sind sie drin?
2. (für Fortgeschrittene):
Lass Dein Beispiel so, also mit angepasstem Tonwertumfang, aber verändere mal die Reihenfolge im Effektstapel.
Also ziehe ColorBalance einfach VOR Fast Color Correction.
Und nun? Was passiert? Wo sind Deine Daten hin? Du hast sie doch runtergezogen ...
Tja ...
---------
Sorry, Dienstag, ich kann Dir hier beim besten Willen keinen Grundkurs in Premiere Pro liefern. Wirst Du verstehen, oder? Das langweilt sicher nicht nur mich.
Wenn Du ernsthaft diskutieren willst, lass endlich diese Sonderfälle weg! Kein einziger, den Du hier bisher präsentiert hast (und die Liste ist lang), war zweckdienlich. Sie haben alle nur bestätigt, wo es hakt. Und mit jedem weiteren Sonderfall-Beispiel wirst Du mit sehr großer Wahrscheinlichkeit mehr davon zeigen.
Schau sie alle noch mal in Ruhe an. Wie viele willst Du noch abliefern? Ich könnte Dir gerne auch Tausend Sonderfälle basteln. Doch wozu?
Ich frage mich: Was willst Du eigentlich?
Nimm also für eigene Experimente endlich ganz einfach einen solchen echten 8-bit-Effekt und machs nochmal, ja? Alles andere ist Unsinn.
Und dann beantworte mir ganz schlicht meine Fragen: Wo sind die Headroom-Daten hin? Und: Werden sie in einem daraus exportierten File enthalten sein? Ja oder nein?
Nur darum geht es. Und das beantwortets Du einfach nicht. Warum?
Reiner M hat geschrieben:Aus der Premiere Pro Doku:
Zitat:
Hinweis:
32-bpc-Effekte werden nur mit 32 Bit pro Kanal gerendert, wenn alle anderen Effekte in der Render-Pipeline ebenfalls 32-bpc-Effekte sind. Wenn Sie einen 8-bpc-Effekt in einer Sequenz platzieren, die einen 32-bpc-Effekt enthält, werden alle Effekte in der betreffenden Sequenz von Premiere Pro mit 8 Bit gerendert.
Alles klar? (Wenn nicht: Die Adobe-Doku bietet weitere Erläuterungen dazu).
und:
Steve Hoeg, one of the Premiere Pro engineers, provided some examples of how Premiere Pro will handle color precision in different scenarios:
1. A DV file with a blur and a color corrector exported to DV without the max bit depth flag. We will import the 8-bit DV file, apply the blur to get an 8-bit frame, apply the color corrector to the 8-bit frame to get another 8-bit frame, then write DV at 8-bit.
Man ist scheinbar gelegentlich der Meinung, Adobe beherrscht die englische und deutsche Sprache nur unzureichend.
Im deutschen Text steht nicht, dass das Ergebnis in 8bit ist (nachdem alle Effekte in voller Auflösung gerechnet wurden), sondern dass jeder Effekt in 8 bit gerechnet wird. Im englischen Text steht es genauso.
Hmm, muss wohl trotzdem falsch sein.
Ich möchte in die Diskussion ja nicht einsteigen, aber diese ganze 8/23 Bit Diskussion bei 8 Bit Material zu führen ist eigentlich überflüssig, weil spätestens beim Rücksprung nach 8 Bit jeder "vermeintliche" Vorteil wieder verpufft.
Was bleibt sind die Nachteile einer solchen ebenso wie einer RGB Bearbeitung.
Mal ganz abgesehen davon, dass ohnehin nicht alle Effekte durchgängig in 32 Bit zur Verfügung stehen und das umschalten nach 8 Bit immer zu Unschärfen führt. Und auch was den "vermeintlich" besseren Störabstand betrifft ... der ist bei dem 8 Bit Material bereits Bestandteil des Bildes, wird also vom 32 Bit "Vorzug" gar nicht erfasst. Bestenfalls aufgesetzte Grafiken ... und auch nur solange, wie es im Rechner ist. Spätestens wenn es 8 Bit werden ist das auch vorbei.
Warum also die 8/32 Bit Diskussion, wenn man mit 8 Bit umgeht ?
In der VFX-Welt kann ich das noch nachvollziehen, aber in der reinen Videobearbeitung ?
(Ich kenn das von andern Programmen übrigens auch nur so, dass pro Effekt auf 8Bit gegangen wird ... mag ja sein, dass Premiere das anders macht. Nur ist es ziemlich egal, weil bei jeder Umschaltung, egal ob Effektline oder individueller Effekt, das Bild immer an Schärfe verliert).
@WoWu
Diese ganze Diskussion dreht sich gerade um den Punkt, dass Reiner M der Meinung ist, Head- und Footroomdaten seien nur nutzbar, wenn eine 32bit Verarbeitung erfolgt. In 8bit sei sowas gar nicht möglich.
Und ich sage dazu, ach, gähn...
dienstag_01 hat geschrieben:
Im deutschen Text steht nicht, dass das Ergebnis in 8bit ist (nachdem alle Effekte in voller Auflösung gerechnet wurden), sondern dass jeder Effekt in 8 bit gerechnet wird. Im englischen Text steht es genauso.
Hmm, muss wohl trotzdem falsch sein.
Das kommt halt dabei raus, wenn man die Doku nicht liest, sondern einzelne Sätze rausfriemelt und nach Fällen sucht, die einen passen. ;)
Noch mal der Tipp:
Reiner M hat geschrieben:
Lies bitte die Doku.
Weil:
Reiner M hat geschrieben:
Ich kann Dir hier beim besten Willen keinen Grundkurs in Premiere Pro liefern. Wirst Du verstehen, oder?
Und: Beantworte doch einfach meine Fragen! Geht das nicht?
Ich verstehe, die Problemstallung hatte ich so bisher nicht verstanden.
Und warum soll das nur bei 32 Bit so sein ?
Der Arbeitsbereich ist doch nicht abhängig von der Verarbeitungstiefe ?
Oder hab ich da jetzt wieder was falsch verstanden ?
dienstag_01 hat geschrieben:@WoWu
Diese ganze Diskussion dreht sich gerade um den Punkt, dass Reiner M der Meinung ist, Head- und Footroomdaten seien nur nutzbar, wenn eine 32bit Verarbeitung erfolgt. In 8bit sei sowas gar nicht möglich.
Und ich sage dazu, ach, gähn...
Bisher hast Du dazu nicht einen einzigen Beweis geliefert. Nur solche, die, wenn überhaupt, belegen, dass es nur in 32bit geht. ;-))) Nicht bemerkt?
Ach ja: Wein DEIN Premiere Pro komplett in 8bit arbeitet - wie Du behauptest (meins tut das nie!): Was meint das. Ist das dann das ganze System? Das Projekt? Die Sequenz? Oder der Clip?
Bin gespannt ...
Beste Grüße,
Reiner
Zuletzt geändert von Reiner M am Di 12 Aug, 2014 16:16, insgesamt 1-mal geändert.
WoWu hat geschrieben:Ich verstehe, die Problemstallung hatte ich so bisher nicht verstanden.
Und warum soll das nur bei 32 Bit so sein ?
Der Arbeitsbereich ist doch nicht abhängig von der Verarbeitungstiefe ?
Oder hab ich da jetzt wieder was falsch verstanden ?
Es ist ein ganz trivales Problem der Informatik, Wolfgang.
Premiere Pro nutzt bei 8bit-Effekten in RGB den Wertebereich 0-255. Logisch.
Der bildgebende Bereich der REC.709-Files (Y16-235) wird in Pr und Ae nach 0-255 gemappt. Alles außerhalb ist in RGB 0-255 nicht speicherbar und geht bei der Umrechnung folglich verloren. Faktisch geht damit der Head- und Footroom verloren und wird in exportierten Videos nicht wieder auftauchen. Kann man ganz leicht testen, sowohl in Pr wie in Ae.
Aber Dienstag will es nicht testen. Warum auch immer. Ich habe ihn schon xfach gebeten. ;)
Das ist genau das, was Du in dem von Dir gezeigten Adobe-Zitat weiter oben beschrieben steht. Man muss auf 32bit gehen (After Effects) oder dort bleiben (Premiere Pro) um diese Daten in negativen Werten und oberhalb 1.0 in RGB speichern zu können. Das sagt jedenfalls Adobe dazu.
Aber Dienstg mag diesen Artikel nicht und ignoriert ihn. Warum auch immer. ;)
Beste Grüße,
Reiner
Zuletzt geändert von Reiner M am Di 12 Aug, 2014 16:39, insgesamt 1-mal geändert.
Es stellt sich also die Frage, wenn im 709 Bereich oberhalb von 235/240 und im unteren Bereich gar nichts ist, weil es sich in einem Standardsignal um Überschwinger handeln muss, die man, ausser bei einem Analogsignal ohnehin nicht mehr braucht, was man dann eigentlich speichern will.
Mit andern Worten. Wenn die Werte bei einem Mapping Y"CbCr=> RGB verloren gehen, -was verliert man ausser Störsignalen eigentlich ?
Und was passiert -wenn man wirklich solche Signale rübergerettet haben sollte, bei einem Rücksprung nach 709 damit.
Setzt man sich seine Störsignale dann wieder ins Bild ?
Oder selbst wenn da Nutzsignale drin gewesen sein sollten ... was passiert damit, wenn ich nach 709 Zielmaterial gehe ... werden meine illegalen Werte dann wieder eingesetzt und mein Kunde haut mir das dann bei der technischen Abnahme um die Ohren ?
Ich verstehe das Problem (und die Anwendung) einfach nicht ?
Reiner M hat geschrieben:Aber Dienstag will es nicht testen. Warum auch immer. Ich habe ihn schon xfach gebeten. ;)
Ich hab es getestet und es funktioniert.
Leider habe ich mich an die Anweisungen von Adobe gehalten und die müssen falsch sein. Sonst müsste man annehmen, Adobe mapped die Werte nicht und Reiner M läge falsch. Wer will das?!
WoWu hat geschrieben:Ich verstehe das Problem (und die Anwendung) einfach nicht ?
Das Problem ist schon ziemlich speziell, stimmt. Aber es gibt nun mal Cams, die in diesem eigentlich illegalen Wertebereich aufnehmen, egal, ob man das gut findet oder nicht. Will man diese Daten nutzen, müssen sie natürlich in den legalen Bereich, das ist klar.
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.
