Zuerst einmal, indem wir spezifizieren, wo dieses Problem überhaupt auftritt:
(NLE meint hier immer Avid, Videos sind FullHD, Betriebssystem ist Windows)
Codec DNxHd:
- Ausgabe als ITU-R 709: Quicktime Player nimmt falschen Farbraum
- Ausgabe als RGB: Quicktime Player nimmt richtigen Farbraum
Codec Quicktime Animation
- Ausgabe als ITU-R 709: Quicktime Player nimmt falschen Farbraum
- Ausgabe als RGB: Quicktime Player nimmt richtigen Farbraum
Codec mp4/h264
- Ausgabe als ITU-R 709: Quicktime Player nimmt falschenFarbraum und hat zusätzlich noch ein Gamma-Problem
- Ausgabe als RGB: Quicktime Player nimmt falschen Farbraum
Wie man sieht, kann man Codecs wie DNxHd und Animation hier ausklammern, man muss nur das richtige Ausgabeformat wählen.
Bei einem h264 Codec gibt es unter Windows immer Probleme (auch z.B. im VLC Player).
Die Workarrounds in Quicktime Player Pro und VLC Player funktionieren nur mit h264 RGB (auch z.B. aus After Effects ausgegeben).
Lösungen, die ich kenne:
Die Workarrounds zur Anzeige in den Playern oder mp4 files in Flash veröffentlichen (html5 scheint auch zu funktionieren). Sorenson Squeeze mit MainConcept funktioniert meines Wissens auch (da gibt es eine spezielle Option, den Schwarzwert als 16 festzulegen oder ähnliches).
Hinzufügen muss man noch, dass diese Probleme nur die ANZEIGE der Videos betreffen, die werden also nicht falsch gerendert.
dienstag_01 hat geschrieben:Zuerst einmal, indem wir spezifizieren, wo dieses Problem überhaupt auftritt:
Das ist eine gute Idee, ich habe mich gestern auch mal dran versucht.
dienstag_01 hat geschrieben:Codec DNxHd:
- Ausgabe als ITU-R 709: Quicktime Player nimmt falschen Farbraum
- Ausgabe als RGB: Quicktime Player nimmt richtigen Farbraum
Ich weiß nicht, was der "Wechsel" (?) des Farbraums bedeutet (da ich mit großer Wahrscheinlichkeit im YUV-Farbraum ausgebe, wäre es logisch, wenn ich den auch benutze, um zu graden, besonders im Hinblick auf Werte über 235 und unter 16), rein visuell ändert sich wenig, "709" ist etwas milchig, wie zu erwarten. Könnte mal jemand erklären, wieso der Wechsel des Anzeige-Farbraums den Schwarzwert ändert? WoWu, wo steckst du, wenn man dich mal braucht?
Ich mache das natürlich auf einem Mac, ist hoffentlich hierfür aussagekräftig.
Folgende Überlegung: Das Umkodieren von Mpeg4 (H.264 von EOS, AVCHD) in einen Intermediate (DNxHD, ProRes, Canopus) ist zwar eine De-Kompression, aber trotzdem verlustbehaftet (mit Animation oder einem anderen verlustfreien Codec wäre das genauso). Es findet einmalig eine Änderung statt, unvermeidbar. Weitere, absichtsvolle Änderungen am Material sind jetzt allerdings um locker den Faktor 100 präziser. Behalte ich im Hinterkopf, dass seit der einmaligen Wandlung die Darstellung kongruent bleibt und dass ich eine Anzeige erhalte, die nur relativ zum Player etwas heller oder dunkler ist, bedeutet das: Ich kann DNxHD auf Sicht graden (EDIT: Nein! s.u.), und der DNxHD-Film wird die für QT passenden Einstellungen haben.
Problematisch wird erst der Export in ein anderes Format. Ich habe die drei Intermediate-Versionen mal aus QT als mp4 (nicht "mov") exportiert (hier im Attachment, für den VLC sind die Dinger mit 4 frames zumindest auf OSX zu kurz, der QT-Player öffnet sie, ein anderer Player wäre auch zu versuchen). Ergebnis: Die "709"-Variante ist am nähesten am Original, die ProRes-Variante ist minimal dunkler, die RGB-Variante etwas heller. Ich hoffe, die Verwirrung ist jetzt nicht komplett (bei mir schon). Ich würde ausserdem gern wissen, ob ihr zu denselben Ergebnissen kommt (meine Displays sind auf Gamma 2.2 eingestellt).
dienstag_01 hat geschrieben:Lösungen, die ich kenne:
Die Workarrounds zur Anzeige in den Playern oder mp4 files in Flash veröffentlichen (html5 scheint auch zu funktionieren). Sorenson Squeeze mit MainConcept funktioniert meines Wissens auch (da gibt es eine spezielle Option, den Schwarzwert als 16 festzulegen oder ähnliches).
Hinzufügen muss man noch, dass diese Probleme nur die ANZEIGE der Videos betreffen, die werden also nicht falsch gerendert.
Der DNxHD-Master ist, wie gesagt nicht "falsch"*. Ich sehe es auch so, dass man mit für den Ausgabecodec passenden Einstellungen exportieren muss (obwohl das "oder ähnliches" mich nicht so begeistert). Oder man sollte auf QT verzichten.
(*EDIT: Doch! Denkfehler! Wenn man eine abweichende Gamma-Anzeige mit "Helligkeit" auf Sicht korrigiert, ist das NICHT das gleiche. Die weitestgehend korrekte Anzeige beim Graden ist unverzichtbar!)
Zu guter Letzt: Millionen von Videos werden auf Macs erstellt, wo diese Problematik, wie mein Versuch zeigt, "nativ" besteht. Schön wäre, wenn überall nur ein Standard gelten würde und man überdies wüsste, dass jeder vor einem neutral kalibrierten Display hockte, aber dies ist nunmal keine perfekte Welt ...
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Ich weiß nicht, was der "Wechsel" (?) des Farbraums bedeutet (da ich mit großer Wahrscheinlichkeit im YUV-Farbraum ausgebe, wäre es logisch, wenn ich den auch benutze, um zu graden, besonders im Hinblick auf Werte über 235 und unter 16), rein visuell ändert sich wenig, "709" ist etwas milchig, wie zu erwarten. Könnte mal jemand erklären, wieso der Wechsel des Anzeige-Farbraums den Schwarzwert ändert?
Ich rede wieder von PC (ich stell das mal voran, sonst sehe ich hier ein grosses Durcheinander entstehen).
ITU-R 709 ist der Standardfarbraum im Avid (ob das YUV ist, weiss ich schon gar nicht). Der ist mit Werten zwischen 16-235 definiert. QT Player sollte den Schwarzwert 16 des exportierten Videos als "reines" Schwarz interpretieren, macht es aber nicht. Gebe ich das Video allerdings im RGB Farbraum (0-255) aus (ohne an der Farbkorrektur etwas zu verändern, schwarz bleibt also 16), zeigt er es richtig. QT Player scheint also je nach Farbraum die Werte unterschiedlich zu interpretieren.
Der DNxHD-Master ist, wie gesagt nicht "falsch"*. Ich sehe es auch so, dass man mit für den Ausgabecodec passenden Einstellungen exportieren muss (obwohl das "oder ähnliches" mich nicht so begeistert). Oder man sollte auf QT verzichten.
Ich glaube nicht, dass man so einfach auf QT "verzichten" kann. Beim Abspielen des Videos auf PC wird QT standardmäßig als Videocodec benutzt (das nicht nur im QT Player, sondern scheinbar auch im VLC - gleicher Fehler).
Das "oder ähnliches" bezog sich auf die Angabe in Sorenson Squeeze, die genau "Set Black Normalization Level to 16" heisst. Damit klappt die Interpretation der Player.
In einem früheren Thread hat WoWu die Vorgehensweise für den Quicktime Player erklärt. Einzige Einschränkung, es funktioniert nur mit Quicktime Player Pro.
VLC Player:
Extras -> Einstellungen -> Alle -> Video -> Ausgabemodule
Hier statt Standard z.b. Open GL verwenden
KÖNNTE aber Einbußen bei der Performance geben.
1. Schnippsel H.264 konvertiert zu DNxHD, Einstellung "709" (leicht milchig).
2. Selben Clip konvertiert zu DNxHD "RGB Levels" (visuell identisch).
3. Original H.264
4. Alle drei hintereinander in FCP ProRes-Timeline, aber nicht als ProRes gerendert, sondern gleich:
5. einmal als DNxHD "709"
6. als DNxHD "RGB"
als Master exportiert.
Sichtvergleich mit dem Originalclip, alle drei parallel im QT-Player: Durchgängig in Helligkeit und Farbe nicht zu unterscheiden !!!
7. Beide Versionen als H.264-mov exportiert für's Web. Ergebnis: Alle etwas zu dunkel im Parallel-Vergleich zum Original.
8. Beide Versionen und zusätzlich das Kamera-Original exportiert als mp4 (x264). Ergebnis (siehe Anhang, komischer Clip, ich weiß, ich hab aber keine Veröffentlichungsrechte an dem meisten Kram auf meinem Rechner, das stammt noch von der 5D, als sie nur 30fps konnte, daher das Stromfrequenz-Flackern): Visuell nicht zu unterscheiden.
Vorsichtiges Fazit: RGB-Levels liefert eine zuverlässige Anzeige, als Grading- und Mastercodec unbedenklich.
Klärungsbedarf besteht noch bei der Frage, wie man diesen Master wieder in andere Codecs ausgibt. Mein letzter Test widerspricht ja diesem, es ist zum Mäusemelken!
Eines blieb aber gleich: Das DNxHD mit den RGB-Levels.
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Ich habe mir die Clips mal angeschaut.
Beim Vergleichstest-Clip sehe ich deutliche Unterschiede zwischen dem 1. (Original) und den beiden weiteren (die sehen gleich aus, heller).
Zwischen dem Vergleichstest-Clip und dem Original-Clip sehe ich auch einen (kleinen) Unterschied, aber vielleicht höre ich schon die Flöhe husten. (Also vielleicht eher nicht)
Wirklich interessant ist aber, wie der Vergleich deines NLE Vorschaufensters (oder Monitors) zu den Clips ausfällt, da gibts bei mir (PC) die Probleme, da Quicktime die falsch anzeigt (zu hell, Gammaschift wie oben beschrieben).
Und, wenn bei dir der Vergleichstest-Clip 3 mal identische Sequenzen liefert, wirds noch interessanter für plattformübergreifendes publishing.
dienstag_01 hat geschrieben:Beim Vergleichstest-Clip sehe ich deutliche Unterschiede zwischen dem 1. (Original) und den beiden weiteren (die sehen gleich aus, heller)
Das sieht hier, auf dem Windows-Bürorechner, wo ichs mir gerade nochmal ansehe, auch so aus. Hmmm ...
dienstag_01 hat geschrieben:Zwischen dem Vergleichstest-Clip und dem Original-Clip sehe ich auch einen (kleinen) Unterschied, aber vielleicht höre ich schon die Flöhe husten. (Also vielleicht eher nicht).
Es ist nicht leicht. Wenn man zwei Bilder auf einem Schirm hat, zumal einem TFT, ändert der Blickwinkel schon einiges, deswegen tausche ich mal hoch und mal runter. Vor allem bei "709" (beim gleichen Frame) scheint mir das Rot der Lampe etwas intensiver zu sein. Manchmal glaube ich, das mp4 vom Original ist heller, manchmal nicht.
dienstag_01 hat geschrieben:Wirklich interessant ist aber, wie der Vergleich deines NLE Vorschaufensters (oder Monitors) zu den Clips ausfällt, da gibts bei mir (PC) die Probleme, da Quicktime die falsch anzeigt (zu hell, Gammaschift wie oben beschrieben ...
Wer wie ich früher völlig unbedarft davon ausgeht, dass sein Video überall gleich aussieht, lernt früher oder später auf die harte Tour, dass das falsch ist. Zumal als Mac-User, wenn überwiegend alle (subjektiv gesehen) ihre Monitore zu dunkel eingestellt haben. Immerhin erschrecke ich nicht mehr, wenn ich Clips woanders sehe. Schätze also, ich bin mittlerweile ziemlich nah am hypothetischen Neutral-Ideal.
Ich weiß noch nicht, was man aus all dem schließen soll, auf jeden Fall werde ich auch zuhause nochmal genau die Clips vergleichen. Aber schon jetzt scheint klar zu sein: Wenn jetzt im Augenblick der Einstein der Gamma-Relativität zur Tür reinkäme, würde er, anstatt uns abschließend zu erleuchten, wahrscheinlich eher die Zunge rausstrecken.
@Axel
Ich würde mir mal nochwas wünschen:
Die Clips nicht als h264 aus deinem NLE ausgeben, sondern als DNxHd (jeweils RGB und 709) und diese Files dann mit x264 komprimieren. Gibts da einen Unterschied? Vielleicht stellst du die nochmal rein.
(Ich glaube nämlich, dass h264 mov schon keine ordentlichen Farbraumangaben macht. Das das trotzdem bei dir auf dem MAC stimmt, ist vielleicht dem für den MAC-Monitor angepassten Quicktime Player zuzuschreiben.)
Hier noch ein (älterer) Artikel für MAC: hier
Vielleicht hilft er trotzdem.
dienstag_01 hat geschrieben:@Axel
Ich würde mir mal nochwas wünschen:
Die Clips nicht als h264 aus deinem NLE ausgeben, sondern als DNxHd (jeweils RGB und 709) und diese Files dann mit x264 komprimieren. Gibts da einen Unterschied?
Ja, lies dir meine Punkte 4, 6 und 8 durch. Der "Vergleichstest in RGB.mp4" ist hintereinander H.264 aus der 5D "Original", und dann DNxHD von dieser Datei (mit QT konvertiert), einmal als RGB und einmal als 709 in einer ProRes-Timeline, die aber nie gerendert wird, sondern gleich als DNxHD RGB exportiert. Den eigenständigen DNxHD-Film habe ich dann mit MpegStreamclip zuerst als H.264 mov ausgegeben, wobei er bei mir deutlich dunkler aussah als das Original (hänge ich morgen mal an). Anschließend habe ich ihn mit x264 zu mp4 exportiert, wiederum vom DNxHD-Master.
dienstag_01 hat geschrieben:Vielleicht stellst du die nochmal rein. (Ich glaube nämlich, dass h264 mov schon keine ordentlichen Farbraumangaben macht. Das das trotzdem bei dir auf dem MAC stimmt, ist vielleicht dem für den MAC-Monitor angepassten Quicktime Player zuzuschreiben.)Vielleicht stellst du die nochmal rein.
Klar. Ein bisschen doof, dass hier nur so kleine Fitzel als Attachments gehen. Wir bräuchten einen aussagekräftigen Schnippsel mit >Memory Colors drin, also Hautfarben und sowas. Und dann könnten wir ihn gemeinsam bearbeiten.
dienstag_01 hat geschrieben:Hier noch ein (älterer) Artikel für MAC: hier
Vielleicht hilft er trotzdem.
Falls er eine "echte" Lösung anbietet, habe ich sie wohl überlesen. Ich glaube, bei dem, was wir hier empirisch einzugrenzen versuchen, kommen wir irgendwann der Sache noch mehr auf die Schliche.
Sehr interessant trotzdem die beiden Grafiken, wobei die linke die mit dem Milchglas-Effekt sein soll. So stark ist der Unterschied bei meinen Tests nie ausgefallen, auch hier auf Windows sehe ich nur eine leichte Abweichung (kein QTPro auf diesem Rechner).
Einen Einfluss haben freilich auch die Monitore. Meine haben 2.2 nach diesem Gamma-Estimator- was, wie gesagt, für Apple immer noch untypisch ist.
dienstag_01 hat geschrieben:@Axel
Ok, hatte ich falsch verstanden. Ich dachte, du hast aus h264 mov ein h264 mp4 gemacht.
Ich werde auch mal was mit deinem Original probieren.
Nein, mach doch lieber was aus einem gescheiteren Material. Das ist erstens vom Motiv her vom Jupiter und zweitens schon viel zu stark datenreduziert. Ideal wäre doch mal ein Schnippsel Original-Material (irgendein HD-Codec), und dann können wir alle mit demselben Zeug arbeiten. Gibt's eigentlich noch Rapidshare?
Ich habe doch ersteinmal dein Material genutzt. Und nach zwischenzeitlichem Fast-Verzweifeln bin ich zu einem Ergebnis gekommen.
Was ich im einzelnen gemacht habe:
Im Avid ein 1080p 29,97 Projekt erstellt (ein dem Originalvideo entsprechendes Format gibt es nicht im Avid und mit 720p ging gar nichts, scheint aber eine Besonderheit der NTSC-Zugehörigkeit und 720p zu sein).
Dein Video (Original) in das Projekt einmal verlinkt (AMA), einmal als Footage im RGB-Farbraum und einmal im 709 importiert. Das Ergebnis waren drei unterschiedliche Videos (in Helligkeit/Kontrast).
Diese Differenz hat mich aber erstmal nicht interessiert - das es zwischen RGB und 709 Unterschiede geben muss, ist klar, das das verlinkte File nicht einem der beiden Farbräume entspricht, naja, kann an mp4 oder Mac-PC oder sonstwas liegen.
Ich habe jedenfalls mit dem 709-File weiter gearbeitet, das war am kontrastreichsten.
Bevor ich es ausgegeben habe, habe ich noch Schwarzbild (Blacklevel = 16) an den Anfang eingefügt. Warum? Dieses Schwarz sollte der Player als "echtes" Schwarz anzeigen, ansonsten wird das Video zu hell wiedergegeben.
Dann einmal als DNxHd RGB ausgegeben und zum anderen mit Sorenson Squeeze zu h264 verarbeitet.
Ergebnis ist: kein Gammashift, die beiden Videos sehen gleich aus. Natürlich gibt es KLEINE Unterschiede, aber irgendwelche Informationen müssen ja "wegkomprimiert" sein.
Hier die beiden Videos (das in DNxHd ist nur 3 Sekunden lang):
dienstag_01 hat geschrieben:Wie ist das auf dem Mac?
Ist das Schwarz schwarz?
Sehen die Videos annähernd gleich aus?
Das Schwarz ist bei beiden Schwarz (oder ich sage lieber: es sieht absolut schwarz aus und ist bei beiden gleich, nebeneinander gelegt in QT).
Das DNxHD ist sehr deutlich heller, die Beschreibung "milchig" passt hier. Ich wendete WoWus >Filmeigenschaften >Visuelle Einstellungen >Transparenz >Komposition (auf PC mit QT-Pro anscheinend "100%") an. Ergebnis: Das DNxHD ist immer noch einen Tick heller, aber es hat so ziemlich dieselbe Helligkeit wie der Ursprungsclip von der 5D, dein mp4 ist minimal, aber erkennbar dunkler.
Wird es uns je gelingen, ein diesem Chaos zugrundeliegendes Prinzip zu finden?
EDIT: Arbeitshypothese zur Diskussion.
Wir haben drei Anforderungen, auf die wir uns konzentrieren sollten, was ansonsten irgendwo heller oder dunkler aussieht, scheint zumindest teilweise an willkürlichen Falschdarstellungen zu liegen, gegen die kein Kraut gewachsen ist (don't blame it on the sunshine).
Die Punkte:
Erstens, dass im NLE und bei der Farbkorrektur das DNxHD so angezeigt wird wie der zugrundeliegende Originalclip und zwar eben auf dem System, Rechner und Monitor, auf dem es ursprünglich betrachtet wurde und nicht in Hollywood auf einem DaVinci oder bei Dr. Honigtau Bunsenbrenner auf dem Expiallegoroskop. Mit welcher DNxHD-Variante ist das gegeben?
Antwort:
Zweitens, dass der Export eines eigenständigen Masters in DNxHD (darum geht der ganze Tanz schließlich) auch außerhalb des NLEs, in QT, noch genauso aussieht. Evtl. (Tests) könnte WoWus Filmeigenschaftenmethode etwas beisteuern, um einmalig und auch für den weiteren Export (immerhin, die Einstellung verlangt, gesichert zu werden, wird also wohl permanenter Flag des Videos) den Gammashift in dieser Phase zu unterbinden ?!?
Vorschläge, wie man das rauskriegt:
Drittens, dass überprüft wird, bei welchen Exportoptionen in andere Codecs welche Abweichungen zu erwarten sind. Ich exportiere den ersten Frame des Originalclips als Jpeg (s. Attachment, bei einem Screenshot wäre das - meinem Verständnis nach - schon nicht mehr unabhängig von den jeweiligen Monitorkalibrierungen), und das kann als Vergleichsfolie dienen.
Wir könnten uns die große Arbeit machen, sämtliche Exportvarianten als solche Jpegs zu exportieren und sie in Photoshop als Streifen immer wieder mit dem Original abzuwechseln, als schnelle Orientierung, in welchem Codec bei welchem Ausgangsmaterial ich die besten Ergebnisse erziele ...
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Axel hat geschrieben:Das DNxHD ist sehr deutlich heller, die Beschreibung "milchig" passt hier.
Traurig, traurig. (Hier hast du die Satndardeinstellungen genommen, ohne an den QT Settings zu drehen?!)
Hier nochmal ein DNxHd File in 709. Sieht das genauso aus, wie das DNxHd RGB File?
Zu deinen Strukturvorschlägen:
Ob das Video zu hell oder zu dunkel dargestellt wird, sollte man hier nicht ausblenden, schließlich geht es ja hier um Gammashift. Und das der Schwarzwert bei einer mp4 Ausgabe falsch wiedergegeben wird, damit logischerweise auch alle anderen Farbwerte, kenn ich zur Genüge.
zu ERSTENS: DNxHd RGB funktioniert auf meinem PC. ob 709 auch, teste ich heute abend nochmal (ist jetzt zu hell hier). Da vergleiche ich allerdings nicht Originalclip mit gerendertem Clip, sondern die Vorschau im NLE und dem gerenderten. Weil, darum gehts letztendlich, wird mein korrigierter Clip in einem Player auch korrekt wiedergegeben. Der Vergleich Originalclip und gerenderter Clip könnte dazu natürlich auch viel beitragen, wenn der Ortiginalclip nicht gerade mp4 wäre, und dem ist ja im Player scheinbar nicht zu trauen. Und ein anderes Format? Schwierig, da Avid in mxf captured und das die Player nicht abspielen.
zu ZWEITENS: muß ich nochmal drüber nachdenken
zu DRITTENS: abgelehnt, da jpgs und Photoshop nichts mit der Darstellung in Quicktime zu tun haben.
Als Anhang habe ich zusätzlich noch einmal ein Video hochgeladen, wo der Schwarzwert auf dem PC nicht stimmt. Wie ist das bei dir?
dienstag_01 hat geschrieben:Wie ist das auf dem Mac?
Ist das Schwarz schwarz?
Sehen die Videos annähernd gleich aus?
Das Schwarz ist bei beiden Schwarz (oder ich sage lieber: es sieht absolut schwarz aus und ist bei beiden gleich, nebeneinander gelegt in QT).
Das DNxHD ist sehr deutlich heller, die Beschreibung "milchig" passt hier. Ich wendete WoWus >Filmeigenschaften >Visuelle Einstellungen >Transparenz >Komposition (auf PC mit QT-Pro anscheinend "100%") an. Ergebnis: Das DNxHD ist immer noch einen Tick heller, aber es hat so ziemlich dieselbe Helligkeit wie der Ursprungsclip von der 5D ...
Muss ich korrigieren: Immer noch, wie man im Attachment sieht (beachtet vor allem den Reflex oben rechts) deutlich heller.
Auch hat es eine Farbverschiebung gegeben, und zwar offensichtlich bei meinem gestrigen Export von DNxHD zu mp4, gut zu sehen am roten Licht, dessen Mittelpunkt (lt. PS Colorpicker) im Original 240/55/25 ist, bei "WoWu" dagegen 227/41/42.
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
dienstag_01 hat geschrieben:Hier nochmal ein DNxHd File in 709. Sieht das genauso aus, wie das DNxHd RGB File?
Das Schwarz ist eindeutig Dunkelgrau, auch im Video selbst, das jetzt jeder auf Anhieb als neblig bezeichnen würde. Der Clip war m.E. von Anfang an ungeeignet.
dienstag_01 hat geschrieben:zu DRITTENS: abgelehnt, da jpgs und Photoshop nichts mit der Darstellung in Quicktime zu tun haben.
Damit magst du recht haben. Allerdings sieht ein als Jpeg oder Tiff exportiertes Frame in meiner (natürlich QT-)Vorschau genauso aus wie das Frame im Video, auf dem der Playhead steht. Ich weiß natürlich nicht, wie es bei dir aussieht, aber ich habe z.B. auch weder deine Augen noch deine Netzhaut. Entscheidend ist imho, dass charakteristische relative Unterschiede in Photoshop noch immer zu sehen sind. Mit welchem Grad der Exaktheit, das können wir uns glaube ich schenken.
dienstag_01 hat geschrieben:Als Anhang habe ich zusätzlich noch einmal ein Video hochgeladen, wo der Schwarzwert auf dem PC nicht stimmt. Wie ist das bei dir?
dienstag_01 hat geschrieben:Das Schwarzwert-Video ist hier
Das Schwarz am Anfang ist wieder nicht von dem DNxHD-RGB zu unterscheiden, nur der 709 fiel hier aus dem Rahmen. Das Video ist einen minimalen Tick dunkler als das DNxHD, aber darum eben ziemlich nah am Original.
Vor allem - bitte bestätige, ob du das auch siehst - ist das rote Lämpchen nun wieder Karmesin anstatt Purpur. Unglaublich. Siehst du, was ich meine?
EDIT: Ich stelle fest, dass keiner, der TS eingeschlossen, einen Piep um unsere Sorgen gibt. Entweder hat niemand diese Probleme oder alle anderen haben resigniert.
Mit ProRes ist übrigens innerhalb der Mac-Welt alles paletti. Ob ein Nicht-QT-Video (sagen wir DV, HDV, EX oder AVCHD, also eigentlich alles außer diesen EOS Movs und dem EX der JVC) vor dem QT-Wrapper anders ausgesehen hatte, kriegt man gar nicht mit. Was ich nicht weiß, macht mich nicht heiß. Man weiß, dass man nicht mit Gamma 1,8 graden darf, ansonsten geht man davon aus, dass es keine echte Referenz gibt. Die Nagelprobe sind DCPs im Kino. Deren Ausgabe wird aufwändig kalibriert. Aber wer kann schon sagen, wie sich Schwarzwerte bei abnehmender Lampenleistung verhalten oder wenn ein Polarisationsfilter für 3D auch bei einer 2D-Show vor der Optik verbleibt (was, wie ich wette, nicht die Ausnahme, sondern die Regel ist)?
Was man deutlich sehen kann, ist, dass der Unterschied zwischen dem mp4 normalisiert und dem herkömmlichen mp4 gewaltig ist.
Das hast du ja für deinen MAC auch beschrieben.
Noch mal eine Frage zu dem test_gamma_avid (RGB), was zeigt der Colorpicker für den Schwarzwert? Bei mir 0. Du hast aber anfangs mal geschrieben, das sähe milchig aus.
dienstag_01 hat geschrieben:Noch mal eine Frage zu dem test_gamma_avid (RGB), was zeigt der Colorpicker für den Schwarzwert? Bei mir 0. Du hast aber anfangs mal geschrieben, das sähe milchig aus.
Nein, nicht das Schwarz. Nur das Schwarz des 709 sieht milchig aus.
Ich möchte dich nicht völlig verwirren (so wie ich es allmählich bin): Aber ich machte gerade folgendes:
Deine test_gamma_avid und test_gamma_avid-709 im Schwarzvorspann übereinander in QT geöffnet: Deutlich ist, dass 709 nur Dunkelgrau ist. Ich machte ein Bildschirmfoto davon (das aus verschiedenen Gründen m.E. nicht "korrekt" sein kann). In Photoshop hatte das RGB 0/0/0, das 709 26/26/26 (siehe Anhang, wenn überhaupt, dann hätte ich 16/16/16 erwartet >dabei auch zu sehen, dass auch ein Mac-User gerne alles mit VCL öffnet ;-))).
ABER:
Bei einem Frame-Export hatten beide Frames 0/0/0 ...
IM VLC-Player sowohl als auch in MpegStreamclip hatten beide Screenshots des 709 0/0/0 ...
WoWus Einstellung änderte nichts (der Screenshot ist nach dem Sichern und erneuten Öffnen).
Dass der Frame-Export die Gammawerte offenbar "zurückkorrigierte", verwirrte mich extremst, da die Photoshop-Comp ein paar Posts weiter oben mit diesen exportierten Frames gemacht ist und man darauf (bei mir zumindest) einen Helligkeitsunterschied deutlich sieht. Immerhin bestätigt es deinen Einwand, dass Jpegs & Co unzuverlässig sind.
Muß mich erstmal sammeln. Ich werde mal noch etwas ausprobieren und poste dann das Ergebnis.
Interessant ist, das auf meinem PC die Veränderung der Visual Settings in QT bei den DNxHd Videos keinerlei Auswirkung hat. Auf dem MAC scheinbar schon (und bei mp4 hier natürlich auch).
Wenn ich das Video als 709 ausgebe, dann stimmen die Werte aus dem Player exakt mit denen im Avid überein. D.h. 709 stimmt in QT, ist aber für den Computerbildschirm nicht verwendbar, da falscher Farbraum, Ergebniss zu hell und zu kontrastarm.
Das das RGB Video die Farben verändern muß ist logisch, muss doch die Anpassung aus dem Workspace Avid mit 709 (16-235) zum Monitorfarbraum RGB (0-255) vorgenommen werden.
Aber das Bild "stimmt" in QT von Helligkeit und Kontrast her.
(Dabei bin ich mir aber sehr sicher, dass Avid hier nichts umgerechnet hat, sondern dem QT Player nur signalisiert, das er es im festgelegten Farbraum zu interpretieren hat.)
mp4 h264 schicke ich gesondert.
Zuletzt geändert von dienstag_01 am Fr 01 Apr, 2011 17:39, insgesamt 1-mal geändert.
Axel hat geschrieben:Attached: Deine beiden Testfilme im FCP-Histogramm. Hmmm ...
Habe doch nur einen Film hochgeladen. Oder was sind das für welche?
Mich würde ja interessieren, wie die RGB-Werte der einzelnen Farben von bars_RGB.mov im QT Player mit Standardeinstellung auf dem MAC sind. Keine andere Software, nichts verändert (kann alles nur wieder zu neuen Fehlern führen).
Liegen die in dem Bereich der von mir aufgeführten Werte?
Axel hat geschrieben:Werde das mit den Farbbalken gerne testen, geht nur nicht von der Arbeit aus ...
Super. Danke.
In meinem Kopf schiebt sich nämlich schon was zusammen...
Als kleiner Pausenfüller mal eine THEORIE, warum hier keine anderen User posten: Ich denke, dass viele mit anderen Produkten arbeiten. Adobe arbeitet von Haus aus im RGB-Farbraum. Wenn ich dort meine Farbkorrektur mache, schön Schwarz bis 0 und Weiss bis 255, dann hab ich auf dem Desktop oder im Internet eher keine Probleme, erst bei TV oder DVD o.ä. Da kanns dann happig werden. Ich arbeite für beides, TV/DVD und Desktop/Internet, aber ich will nicht zwei Farbkorrekturen machen. Deshalb denke ich, dass manche das noch gar nicht bemerkt haben.
dienstag_01 hat geschrieben:
In meinem Kopf schiebt sich nämlich schon was zusammen...
... warum hier keine anderen User posten...
...Weil wir uns in gute, aber für uns relativ unwichtige Dialoge
nicht einmischen...
...Weil wir wissen, dass es hier lediglich um "Aggregate" geht ...
Bevor man sich darüber im Klaren ist, dass es auch wichtig wäre,
seinen eigenen individuellen (momentanen) Rhodopsin-Status
zu kennen (schwierig) um ihn mit dem eines anderen Individuums
abzustimmen (noch schwieriger), sollte man sich hinterfragen,
ob man überhaupt zu den durchschnittlichen farbnormalsichtigen
Beobachtern gehört.
Zapfenerregungsfunktion im Gleichmarsch gibt es nicht und ein
jedes Farbkonstanzsystem im Hirn ist unterschiedlichst ausgeprägt.
Quicktime-Gammashift Problem.
Warum ist die Banane krumm?
@Filbert
Nee, kannte ich noch nicht. Danke.
Habs nur überflogen, die Sichtweise beim RGB-Export liegt mir aber bissel einseitig beim Clipping. Für unser Thema hier ist wichtig, das ich von einem korrekt korrigiertem Video ausgehe. Sonst wirds noch wilder.
Hallo Axel, würdest du vieleicht nochmal nach den Farbwerten von bars_RGB.mov auf einem Mac testen (hatte sie in einem Post weiter oben mal einzeln aufgeführt)? Dann wüsste man, ob es zumindest mit DNxHD im RGB Modus funktioniert.
Ich habe die Postings im Einzelnen nicht nachvollziehen koenne, aber so wie es aussieht, springt Ihr munter zwischen YCb'Cr' 601 und YCb'Cr' 709. Das ist aber nicht dasselbe, wenn nicht von 709 nach 601 korrekt gewandelt wurde (oder vv). Und selbst dann gibt es noch Rundungsfehler.
Bei 709 werden die digitalen Ausdehnungsräume der Werte 1–16 und von 241–254 in der Chroma– Achse und von 1–15 und 236–254 in der Luma Achse ausgenutzt. In 601 nicht. Man kommt also um die Wandlung nicht herum: (235-16)/(240-16) = 219/224
Soviel ich weiss, benutzt Apple noch die alten SD-Werte aus 601. Trifft das auf eine 709 Verarbeitung, fuehrt das zu den bekannten Fehlern. Monitore arbeiten meistens nach einem LUT und brauchen kein extra aufbereitetes Signal.
Bei aller Praxisfreundlichkeit gehoert schon dazu, zu wissen, in welchem Farbraum eigentlich welches Element der Verarbeitungskette arbeitet und was es bedeutet ... und ggf. wie man dazwischen wandelt. Aber vielleicht verbirgt sich das ja hinter den Postings, die ich nicht alle gelesen habe.
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.
