Ich denke aber, dass das Gamma-Shift-Problem nicht auf die Differenz von 601 und 709 zurückzuführen ist, sondern das Quicktime den Farbraum falsch interpretiert. Zumindest sieht die Abweichung beim Schwarzwert "größer" aus.
Die Gewichtungen von RGB nach R'G'B' sind in den Standards vorgeschrieben und Apple macht das schon korrekt, aber eben nach 601 und wenn man konsequent in 601 bleibt, funktioniert das auch, bis auf die alten QT Anwendungen, wo noch mit einem alten K/Wert als Konstante gearbeitet wurde. Das ist aber (wie man hört) im neuen System behoben.
(Hab es noch nicht ausprobiert).
Ich beschreib nochmal kurz das Problem, sonst verzetteln wir uns:
Nach dem exportieren aus dem Schnittprogramm hat das Video einen vollkommen anderen Schwarzwert und sieht im Player verwaschen/blass aus. Dieser Effekt tritt nicht bei allen Codecs (aber speziell bei h264) und nicht bei allen Farbräumen auf. Meiner Erfahrung nach tritt dieser Effekt nicht auf, wenn ich Richtung Broadcast/TV weitergearbeitet wird. Aber wenn das Video auf einem Computermonitor wiedergegeben wird, ist es MEIST so.
Das ist keine Beschreibung. das ist bestenfalls eine Beobachtung mit einer Mutmaßung.
Also: Welcher Farbraum kommt aus der Kamera ?
R'G'B' oder Y'CbCr ... wenn ja, welcher ? 601 oder 709
Welches NLE und welche Projekteinstellung ?
Nach welchem Format wird ausgespielt ?
Weil bei einem Ãœbergang nach SD vermutlich wieder nach 601 gegangen wird.
Arbeitet der Monitor mit einem LTU, der auf den identischen Farbraum referenziert ?
Steht der K Wert auf 2.2 ?
Werden irgendwelche Wandlungen durchgeführt, z.B. irgendwelche Roundtrips über 10 bit oder soetwas ?
Welches Frameformat und welche Framerate ?
Das wären so die üblichen Verdächtigen, wenn nicht noch irgendwelche Capture Cards dabei sind, oder Konvertierungen jeglicher Art.
Die Codecs haben, solange man nicht ältere Exoten benutzt, oder ueber JPEG geht, eigentlich keinen Einfluss.
Schaun muss man auch mal, ob das NLE überhaupt 709 kann, viele haben nur das Frameformat aufgebohrt, aber nicht die Farbräume und juckeln noch mit SD Farbräumen rum.
Damit sollte man dem Problem eigentlich zu Leibe rücken können, den ich verwette meinen A. dass irgend eines der Settings nicht stimmt.
Die meisten wissen noch nicht einmal, welchen Farbraum ihre Kamera überhaupt bedient. ... Vielleicht muss man das ja nicht als Praktiker ?
WoWu hat geschrieben:Die meisten wissen noch nicht einmal, welchen Farbraum ihre Kamera überhaupt bedient. ... Vielleicht muss man das ja nicht als Praktiker ?
Stimmt, weiss ich nicht.
Aber nochmal: Das exportierte Video sieht im Softwareplayer anders aus, als im Preview meines NLe's. Das ist das Problem.
Der Computermonitor arbeitet mit RGB-Werten von 0-255. Der Softwareplayer muss also gegebenfalls den Farbraum anpassen, wenn das Video standardmäßig mit 16-235 geliefert wird. Sonst sieht Schwarz Grau aus. Bei vielen Codecs funktioniert das auch. Aber bei einigen nicht (und das sind gerade die, die im Computerbereich Priorität haben, z.B. h264). Nun wäre das zu verschmerzen, wenn man speziell für den Computer-Workflow eben im Bereich 0-255 farbkorrigieren würde und es so funktionierte. Macht es aber auch nicht. Das nennt man Quicktime-Gammashift-Bug.
Merkt niemand, der zwar am Computer arbeitet, seine Ausgabe dann aber wieder über Band etc. Richtung TV gibt.
Wenn etwas angepasst werden muss, dann stimmt irgend etwas nicht in der Kette.
Das ist ein Fehler, der entweder beseitigt werden muss oder die Anpassung muss exakt erfolgen, falls man es absichtlich anpassen möchte.
Dazu muss man wissen, was von wo nach wo angepasst werden muss.
Dazu muss man wissen, womit man es überhaupt zu tun hat.
Dann kann man mit dem Restfehler, der daraus ggf. entsteht entweder leben oder sorgt dafür, dass alle Komponenten nach denselben Regeln arbeiten.
Du wirst also, wohl oder übel mal in Erfahrung bringen müssen, was Deine Geräte da eigentlich so treiben und womit du da eigentlich umgehst, bevor man sagen kann, was an welcher Stelle gemacht werden kann.
Das nennt man Quicktime-Gammashift-Bug.
Und das stimmt auch nicht, das nennt man nähmlich Ahnungslosigkeit.
Nochmal nochmal:
Wie in den vorherigen Posts zu sehen ist, habe ich auch einfach mal Color Bars aus dem Schnittsystem exportiert. Diese werden mit unterschiedlichen Codecs im Player unterschiedlich angezeigt.
Ich hab mich aus dem Thread bislang herausgehalten, da ich zu wenig Ahnung von Codecs habe um das Gammashift-Problem zu lösen. Letzteres ist zumindest unter Avidleuten international bekannt und wird immer wieder auf diversen Foren diskutiert. Wieso ein nun bekanntes Phänomen in Frage gestellt wird, verstehe ich nicht so ganz. Bislang habe ich den Thread aufmerksam verfolgt, weil er sich an der Problemlösung orientierte... wär doch schön, wenn dies so weiterginge...;-)
Mein persönlicher Workaround - zumindest für Webtrailer - ist derzeit, ganz auf quicktimebasierte NLEs zu verzichten und Edius zu verwenden. Was aber längst nicht so angenehm wie die Arbeit mit Avid ist und natürlich keine Lösung sein kann, weil ich von Avid nichts übernehmen kann und jeweils alles neu schneiden muß.
@B.DeKid
Ich kann da nicht wirklich was dazu sagen. Ich weiss nur, dass Adobe im RGB Farbraum arbeitet, was das aber im Einzelnen heisst... Ich nehme an, egal in welchem Farbraum man sich bewegt, intern wird immer mit RGB Werten gearbeitet. Das könnte schon zu Fehlern führen, was dafür spräche, in RGB zu arbeiten. Wenn die Ausgabe (und die Vorschau) aber auf Geräten mit 709 Farbraum stattfindet, ist das möglicherweise gar nicht mehr relevant, da in der Kette sowieso (mindestens) eine Wandlung von RGB nach 709 vorgenommen werden muss.
Aber das sind so Gedanken am grünen Tisch.
@NEEL
Mein persönlicher Workflow ist seit Neuestem Sorenson Squeeze. Das arbeitet genauso wie Adobe mit dem MainConcept Encoder, man kann dort aber noch ein Flag für den 16-235 Farbraum setzten. Und das scheint (hab bis jetzt nur einige wenige Tests gemacht) dann richtig gelesen zu werden.
Vielleicht hat ja Adobe da was in der CS 5.5 geändert, es gibt noch ein paar andere Einstellungen, die man bisher nicht bearbeiten kann (z.B. gibt es bisher nur CABAC, kein CAVLC).
Interessant ist, weil du schreibst, dass es bei dir um Webtrailer geht, dass, wenn ich das "falsch interpretierte" Video mit Flash veröffentliche, es "richtig" aussieht. Das hat mich anfangs zur Verzweiflung gebracht, weil ich immer dachte, ich bin es, der einen Fehler macht.
dienstag_01 hat geschrieben:Das nennt man Quicktime-Gammashift-Bug.
WoWu hat geschrieben:Und das stimmt auch nicht, das nennt man nähmlich Ahnungslosigkeit.
Wer nähmlich mit h schreibt ...
WoWu hat recht damit, dass wir hier nicht Bescheid wissen, und offensichtlich hat er auch recht damit, dass man nur durch Experimentieren ("Praxis") das Problem nicht ursächlich löst.
B.DeKid hat geschrieben:Mal ne ganz simple Frage
Eos Material wandeln > DNxHD
709 oder RGB Profil nutzen
Das ist die praktische Frage. Man kann EOS noch mit AVCHD ersetzen, aber darauf beschränkt sich's. ProRes 10-bit als Arbeitscodec - also auch eine "Rundfahrt" - ist üblichst und macht keinerlei Probleme.
dienstag-01 hat geschrieben:Hallo Axel, würdest du vieleicht nochmal nach den Farbwerten von bars_RGB.mov auf einem Mac testen.
Sobald ich mal wieder am Mac sitze, werde ich das tun, versprochen.
Schätze, so wird es bleiben: Ahnungslose Kurpfuscher, die "bestenfalls" beobachten und mutmaßen können, und der diplomierte Experte, der sich über Praktiker bekringelt. Wie Hannibal Lecter, der aus seiner Zelle heraus die Fahndungsbemühungen der Polizei kommentiert.
Hat jemand den Eindruck, dass er überhaupt daran interessiert ist, eine Lösung zu nennen? Entweder ist er zu weit weg von der Praxis und referiert lediglich Daten, von denen wir bereits angemerkt haben - hence the thread -, dass eine Verständnislücke besteht - oder ein einfaches, nimm 709 und exportiere mit diesen Settings bietet ihm zuwenig Gelegenheit, sich aufzuspielen.
Schopenhauer hat geschrieben:Aber [...] Kompendienschreiber [...] nehmen den Stoff unmittelbar aus Büchern [...]. Daher hat ihr Gerede oft so unbestimmten Sinn, daß man vergeblich sich den Kopf zerbricht, herauszubringen, was sie am Ende denken.
Indirekt hat das zuvor geschriebene schon mit dem "Gamma Bug" zu tun, aber um konkret darauf noch einmal einzugehen.
Der "Gamma Bug" ist eigentlich gar kein wirklicher Bug sondern beruht darauf, dass Apple ursprünglich im DTP den Schwerpunkt hatte und eben nicht im Videobereich sondern in der Printausgabe.
Ausgabegeräte haben aber keinen linearen Gammaverlauf. Daher muss Software diesem Verlauf angepasst werden
Eine Gammakorrektur ist also, vereinfacht beschrieben, die Anpassung einer Eingangsgröße entlang einer Abbildungsvorschrift, an eine Ausgangsgröße.
Abbildungsvorschriften können beispielsweise Kurvenverläufe sein, die ein bestimmtes Medium, Print oder Video und auch hier wieder unterschiedliche Medien, wie z.B. CLTs oder LED, an die Sehgewohnheiten des menschlichen Sehvermögens anpassen.
In hohen Gamma-Werten werden die wahrgenommene Werte (Farben) schneller dunkler als in tieferen Werten.
Nun hat Apple die Gammakorrektur früher so vorgenommen, dass sie zum Laserprinter passte, nämlich mit dem K/Wert ℽ=1.8.
Für die damaligen Fernsehgeräte mit einer Bildröhre waren aufgrund der Leuchtdichteabhängigkeit der Farbphosphore die Gammakurven mit einem Gesamtexponenten ℽ=1,6-3.2 normal. Apple hat sich also für "Print" entschieden und das lange beibehalten, auch nachdem VIDEO Einzug gehalten hat. CCIR601 liess da auch noch mehr Freiheiten als ITU709. Danach ist der Korrekturwert nun mit 2.2 festgelegt und Apple hat das auch wohl ab SNOW LEOPARD geändert.
Bearbeitet man allerdings solche 709 Videos noch mit älteren Systemen oder QT-Einstellungen, stösst man auf diesen "Bug", der eigentlich gar keiner ist. Daher hatte ich oben darauf hingewiesen, dass man sehr wohl beachten muss, welcher Teil der Verarbeitungskette nach welchen Standards arbeitet.
Vorzuwerfen ist Apple lediglich, dass sie 25 Jahre gebraucht haben, um sich von Print nach Video zu orientieren und die Anwender zu lange haben im Wald stehen lassen.
Für ältere Applikationen gibt es also wirklich nur die workarounds, solche unterschiedlichen Gammawerte zu korrigieren.
Die Workarounds hatte ich hier mal gepostet. Ist schon eine Weile her, ich müsste jetzt selbst wieder nachsehen. Aber mit einem Search kommst Du da sicher hin.
@WoWu
Ok, hier spricht ein Fachmann. Sehr schön.
Aber bitte noch nicht genüßlich zurücklehnen.
Ich nämlich arbeite mit Windows.
Nun kann ich mir vorstellen, dass dieses Gammaproblem mit Quicktime auch auf Windows-Rechner exportiert wurde (und wird!). Aber für die Fehlleistungen der Player scheint meines Erachtens noch ein zweiter Punkt hinzuzukommen. Teilweise interpretieren sie auch noch den Farbraum (ich spreche hier mal nur vom Unterschied 0-255 und 16-235) falsch. Daher werden die Videos fälschlicherweise mit einem Grau anstatt Schwarz angezeigt. Dazu dann noch das Gamma-Problem und wir sehen das, was immer als verwaschen und blass etc. beschrieben wird.
Die beiden Themen sind in Wirklichkeit ein Thema, denn das Gammaproblem entsteht aus den zuvor genannten Gründen.
0-254 wird jeweils ein bestimmter Wert zugeordnet, der entlang einer Konstanten (eben 1.8 oder 2.2) errechnet wird.
Daraus ergibt sich, gemeinsam mit einem Festen Wert des Anzeigemediums, eine lineare Gammadarstellung.
Ich kann mir vorstellen, dass QT das Problem auf den PC exportiert hat.
Daher gibt es eben dafuer nur diese zwei Lösungen, entweder darauf achten, dass durchgängig die richtigen Standards Verwendung finden, oder, wenn man alte Applikationen benutzt, eine Gammakorrektur vornehmen, was, zugegeben, nicht ganz einfach ist, will man es nicht nur pi-x-Daumen machen.
Aber ich kann mir vorstellen, dass Apple auch in neueren QT Playern für den PC das Thema beachtet hat. Also würde ich mal updates checken und vor allen Dingen nicht mehr mit 601 rummachen. Das ist eine ziemliche Fehlerquelle und sollte eigentlich seit SD-Zeiten auch erledigt sein.
Also, stell alles konsequent auf 709 um, und check nach PC Updates für QT.
Wenn Du alten Content schon mit den falschen Werten unkorrigiert erstellt hast, musst Du leider manuell ein Gammakorrektur machen.
Muss ich nochmal widersprechen, das ist nicht nur ein Problem.
Auf der ersten Seite dieses Threads ist ein Post von Axel, in dem zwei Schwarzvideos gegenüber gestellt sind (vom 1. April, 15:23). Das eine hatte ich 709 das andere RGB ausgegeben. Das Schwarz ist einfach eine Fläche mit 16/16/16. Fazit: sehen unterschiedlich aus.
Die Postings vom "Neutrino" sind von wenig Relevanz, weil sie mit den Themeninhalten nur sehr begrenzt etwas zu tun haben. Wen er R'G'B' gepostet hätte, könnte man ja noch eine gewisse Ähnlichkeit mit dem Thread erkennen, aber RGB ist ja nun etwas völlig Anderes.
Die Videos sind von mir (nicht von irgendeinem NEUTRINO).
Und ausgegeben sind sie aus dem Avid einmal in der 709 Spezifikation, das andere als RGB. Denk schon, dass das eine Relevanz hat.
dienstag_01 hat geschrieben:Auf der ersten Seite dieses Threads ist ein Post von Axel, in dem zwei Schwarzvideos gegenüber gestellt sind (vom 1. April, 15:23). Das eine hatte ich 709 das andere RGB ausgegeben. Das Schwarz ist einfach eine Fläche mit 16/16/16. Fazit: sehen unterschiedlich aus.
Es waren 26/26/26, in der FCP-Waveform lag dann auch das tiefste Signal bei 10%, was zwar für mich nicht das "warum" erklärt, aber "irgendwie" zusammen passt.
WoWu hat geschrieben:Die Postings vom "Neutrino" sind von wenig Relevanz, weil sie mit den Themeninhalten nur sehr begrenzt etwas zu tun haben. Wen er R'G'B' gepostet hätte, könnte man ja noch eine gewisse Ähnlichkeit mit dem Thread erkennen, aber RGB ist ja nun etwas völlig Anderes.
Neutrino soll wohl ich sein. Mag sein, dass es "R'G'B'" hätte heißen müssen, "709" und "RGB" sind bloß die Preset-Bezeichnungen aus dem DNxHD-Export-Dialog. Blöd, dass Avid so unrelevante Namen in ihre Encoding-Oberfläche tippen ;-)
Ansonsten hast du sicher recht. Meine Beiträge helfen dem Thread nicht weiter. Wie gut, dass es dich gibt, der hier nicht nur "beobachten und mutmaßen" kann, sondern Fakten liefert.
Nein, die Videos kamen von mir und hatten 16/16/16. Das sie bei dir falsch angezeigt werden (0/0/0 im QT-Player ist ja "richtig"), darin liegt das Problem.
Schneiden und bearbeiten dann Ausgabe als DNxHD ( erneut so wie bei der ersten konvertierung als 709 oder eben RGB Modus)
*** Ich lass teils auch Sequenzen als Tif Sequenzen / Stapel ausgeben , hiier intressiert mich auch das Pro und Contra des RGB oder 709***
Dann wandeln für BluRay / DVD Standard sowie auch mp4 h.264 Web Version
Also quasi die normale Ausgabe Kette
...................
Mir gings nun also mehr um Aussagen Richtiung
" Mit RGB oder 709 kommst du bei Premiere bei zB Farbaenderungen an die und die Probs"
Also Praxis orientierte Tips Meinungen Ratschläge.
An sowas dachte ich jetzt mal , weil die Fachmann Diskussionen sind ja alle ganz nett aber für den Grossteil der USER ( inkl. mich) halt doch etwas zu "hoch".
Falls also einer von euch solche Tips / Erklärungen parat hätte waere ich sehr dankbar.
Wenn Dir die Kamera das Signal zur Verfügung stellt, (und die weitere Verarbeitungskette es zulässt) würde ich immer im R'G'B' Modus arbeiten und eine Wandlung erst beim Ausspielen durchführen, weil Du dann die Rundungsfehler nicht durchschleppst und ausserdem, bei unterschiedlichen Zielformaten auch den gespreizteren Farbraum als Quelle hast.
Aber, auch hier... ich muss es leider nochmal sagen: Du musst Deine Verarbeitungskette kennen und wissen, ob alle Komponenten, die mitspielen, das auch können, sonst kommen solche komischen Fehler dabei heraus.
Im Quicktimeplayer bekomme ich etwas andere Werte, im VLC-Player völlig andere Werte. Meine Vorgehensweise: Screenshot im jeweiligen Player gemacht, in Photoshop geladen und die Werte, die ich mit dem Colorpicker genommen hab, in den jeweiligen Farbbalken getippt, anschließend als Jpeg exportiert. Lade ich das Jpeg wiederum in Photoshop, haben sich einige Werte minimal verändert. Solltest du also gegenchecken und Abweichungen von +/- 1 finden, so ist das bei mir auch so.
Tut mir Leid, ich wollte ein Attachment hinzufügen, aber mein maximales Attachment-Dingens ist voll, darum jetzt als etwas unzuverlässige Verlinkung über meinen Mail-Provider:
@Axel
Mal eine Nachfrage zum Verständnis:
Die roten Werte sind in der Auflistung sind die von dir im QT-Player abgenommenen, richtig?
Aber was sind die Farbbalken und die Kreise im Screenshot (bleiben wir erstmal bei dem vom QT-Player)? Wiso gibt es da einen Unterschied zwischen den Balken und den Kreisen? Wenn du die Werte abgenommen hast und dann (für die Kreise???) von Hand eingetragen, müssten die doch gleich sein?
dienstag_01 hat geschrieben:Die roten Werte sind in der Auflistung sind die von dir im QT-Player abgenommenen, richtig?
Ja.
dienstag_01 hat geschrieben:Aber was sind die Farbbalken und die Kreise im Screenshot (bleiben wir erstmal bei dem vom QT-Player)? Wiso gibt es da einen Unterschied zwischen den Balken und den Kreisen?
Oben: VLC, unten: QT-Player X (QT 7 ist aber farblich identisch, zumindest visuell). Die Kreise sind einfach das aus dem jeweils anderen Player, damit man den Unterschied besser sieht.
Ist es eigentlich denkbar, dass meine Monitorkalibrierung zu Verfälschungen führt, wenn ich einen Screenshot mache? Ich habe einfache Samsung Syncmaster, die ich mittels Spyder Pro kalibriert habe. Müsste nicht eigentlich dieses Farbprofil in den Screenshot eingebettet sein? Gibt es eine narrensichere Möglichkeit, die Farbtreue zu checken?
Falls das eine dumme Frage ist, lach ruhig. Und falls du zu dem Zusammenhang Monitor-Farbprofil und Video-Farbraum Informationen oder einen Link hast, her damit.
Ich hol den Thread hoch weil ich eine passende Frage habe.
Ich probiere gerade mit dem DNxHD Codec rum (weil er ne leicht bessere Quali liefert als Cineform) und exportiere aus Vegas 10.
Folgendes Problem:
Ich habe einen Clip. Der ist so farbkorrigiert (in Vegas), dass er von 16-235 geht.
Wenn ich diesen Clip per DNxHD mov exportiere, egal ob mit ITU709 oder RGB wird er von Quicktime als 0-255 decodiert.
Halb so schlimm, allerdings setzt sich das Problem fort, wenn ich den gerenderten clip in TMPGenc importiere. TMPGenc interpretiert den clip auch als 0-255 und dementsprechend flau sieht die Vorschau aus.
Wenn ich dann ein DVD File rendere passiert was ganz witziges. Der 0-255 Farbraum (der ja eigentlich nur werte von 16-235 enthält) wird nicht etwa bei 16 und 235 abgeschnitten...Nein, er wird in 16-235 reingepresst, was dann dazu führt, dass die DVD Datei nur Information von 32-215 enthält....
Lösung: Es muss möglich sein, den DNxHD clip auf 16-235 zu flaggen, nur wie?
Wenn ich diesen Clip per DNxHD mov exportiere, egal ob mit ITU709 oder RGB wird er von Quicktime als 0-255 decodiert.
Was heisst denn das?
Ist ja schon bissel länger her, aber soweit ich mich erinnere, ist der DNxHD Codec der einzige, der in der Anzeige stimmte.
Das heißt, es sieht flau aus in Quicktime.
Das Problem ist wohl Vegas. Vegas arbeitet immer im 0-255 Farbraum und deshalb werden die DNxHD Files wohl auch so dekodiert obwohl sie nur Werte von 16-235 enthalten.
Ich bin gerade einer möglichen Lösung auf der Spur. Per Avisynth scheint man den Farbraum einer Datei bestimmen zu können.
Edit: habs wohl gelöst. Der Levels Filter "clampt" alles was unterhalb und oberhalb von 16-235 liegt ab.
Die einzige Möglichkeit besteht wohl darin, den Quicktime-Container von DNxHD gegen MXF zu tauschen. Dann dürfte auch der Farbraum korrekt wiedergegeben werden.
Ich hab noch mal getestet (Color_Bars). Bei mir funktioniert es, mit DNxHD als RGB ausgegeben - abgespielt im QT-Player (NLE: 16, QTP: 0; NLE: 234, QTP: 254).
Ist beim DNxHD-Export auch der Codec auf RGB eingestellt (im Avid gibt es dafür eine zentrale Einstellung im Exportfenster, zusätzlich die Einstellungen direkt für den Codec)?
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.
