Infoseite // Wie Lösen wir das Quicktime-Gammashift Problem?

Frage von NEEL:


Da das Thema Gammashift in allen möglichen Foren anklingt, hier ein Thread zum Sammeln von bekannten und unbekannten Lösungsansätzen.

Also: Wie Lösen wir das Quicktime-Gammashift-Milchglasproblem?



Antwort von dienstag_01:

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.



Antwort von Axel:

Zuerst einmal, indem wir spezifizieren, wo dieses Problem überhaupt auftritt: Das ist eine gute Idee, ich habe mich gestern auch mal dran versucht.
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).
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 ...



Antwort von dienstag_01:

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.



Antwort von dienstag_01:

Hier nochmal die beiden Workarrounds für PC:

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.



Antwort von Axel:

Ich habe dieses gemacht:

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.



Antwort von dienstag_01:

@Axel

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.



Antwort von Axel:

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 ...
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.
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.



Antwort von dienstag_01:

@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.






Antwort von Axel:

@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.
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.
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.



Antwort von dienstag_01:

@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.



Antwort von Axel:

@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?



Antwort von dienstag_01:

@Axel

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):

h264

DNxHd

Wie ist das auf dem Mac?
Ist das Schwarz schwarz?
Sehen die Videos annähernd gleich aus?



Antwort von Axel:

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 ...



Antwort von dienstag_01:

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?



Antwort von Axel:

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.



Antwort von dienstag_01:

Das Schwarzwert-Video ist hier



Antwort von Axel:

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.
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.
Als Anhang habe ich zusätzlich noch einmal ein Video hochgeladen, wo der Schwarzwert auf dem PC nicht stimmt. Wie ist das bei dir? Nicht gefunden.






Antwort von Axel:

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)?



Antwort von dienstag_01:

Hier noch ein paar Screenshot-Vergleiche:



Antwort von dienstag_01:

und das letzte:



Antwort von dienstag_01:

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.



Antwort von Axel:

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 ;-))).


zum Bild


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).

zum Bild


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.

Nur: Was ist verlässlich?



Antwort von dienstag_01:

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).



Antwort von dienstag_01:

Ich habe nochmal neue Tests gemacht, diesmal mit Colorbars.

Das bars_RGB zum runterladen.

Die dazugehörigen RGB-Werte sind folgende:

254 254 254
190 191 1
1 191 189
2 190 3
189 1 187
190 0 2
1 0 190
0 0 2

von Weiß nach Schwarz.

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.



Antwort von Axel:

Attached: Deine beiden Testfilme im FCP-Histogramm. Hmmm ...
(10 Prozent würden immer hin die ominösen 26/26/26 erklären)

Verkriechen sich die Experten oder ist dies das Doofi-Forum?



Antwort von dienstag_01:

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?






Antwort von Axel:

Attached: Deine beiden Testfilme im FCP-Histogramm. Hmmm ... Habe doch nur einen Film hochgeladen. Oder was sind das für welche? Hier die beiden Videos (das in DNxHd ist nur 3 Sekunden lang):
Hier nochmal ein DNxHd File in 709. Sieht das genauso aus, wie das DNxHd RGB File? Versteh ich aber, mein Desktop zuhause ist nach den ganzen "tests" das reinste Durcheinander.

Werde das mit den Farbbalken gerne testen, geht nur nicht von der Arbeit aus ...



Antwort von dienstag_01:

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.



Antwort von Jott:

Bingo. RGB kontra YUV.



Antwort von Filbert:

Hab den Thread aus Zeitmangel noch nicht im Detail verfolgt, aber falls ihr den noch nicht kennt:
Color Levels In Avid Media Composer Import And Export.

aus http://community.avid.com/forums/p/9332 ... spx#532294

Grüße, Filbert



Antwort von DWUA:

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?

;))



Antwort von dienstag_01:

@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.



Antwort von dienstag_01:

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.



Antwort von WoWu:

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.



Antwort von dienstag_01:

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.






Antwort von WoWu:

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).



Antwort von dienstag_01:

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.



Antwort von WoWu:

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 ?



Antwort von dienstag_01:

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.



Antwort von WoWu:

Nochmal ......

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.



Antwort von dienstag_01:

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.



Antwort von B.DeKid:

Mal ne ganz simple Frage

Eos Material wandeln > DNxHD

709 oder RGB Profil nutzen

Ziel die bearbeitung auf Win PC in Premiere CS3 , Sony XDCAM EX Profil Vorlage.

...............

Anfangs hab ich es in "RGB" gewandelt mittlerweile in 709 .

Mir kam es so vor das der / das 709 stabiler schien wenn mann Farbanpassungen macht .

Wöre einer von euch beiden mal so nett was dazu zu sagen , Danke

Danke.

MfG
B.DeKid



Antwort von NEEL:

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ß.



Antwort von dienstag_01:

@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.






Antwort von Axel:

Das nennt man Quicktime-Gammashift-Bug. 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.

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.
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.
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.



Antwort von WoWu:

@ NEEL

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.



Antwort von dienstag_01:

@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.

Ist das vorstellbar?



Antwort von WoWu:

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.



Antwort von dienstag_01:

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.

Und, leider, Quicktime-Updates bringen nichts.



Antwort von WoWu:

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.



Antwort von dienstag_01:

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.



Antwort von Axel:

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.
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.



Antwort von dienstag_01:

Es waren 26/26/26, 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.






Antwort von B.DeKid:

Un wenn wir schon bei Fakten sind dann würde ich gerne mal eine Antwort auf meine Frage haben bzgl

EOS > DNxHD
In RGB oder in 709 wandeln

Um in Premiere XDCAM EX Profil ( Vorgabe) zu arbeiten

................

Kann da vielleicht mal jemand was passendes zu posten antworten ?

( Dienstag hatte dies ja eben ansatzweise schon getan, nur hat mich dies noch nicht so richtig befriedigt.)

Weil als praktischer USER hat mir bis Dato noch kein Posting hier ein Licht aufgehen lassen und ich seh immer noch "schwarz" ;-))

MfG
B.DeKid



Antwort von dienstag_01:

Jetzt drehnse hier alle frei...
Aber das B.DeKid "schwarz" sieht und das bei unseren Schwarzwertproblemen ist irgendwie ein Zeichen.



Antwort von WoWu:

Kid, das kommt immer darauf an, wie Du weiterarbeiten willst.
Was wird Dein Endprodukt ?



Antwort von B.DeKid:

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.

MfG
B.DeKid



Antwort von WoWu:

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.



Antwort von B.DeKid:

Naja die Cam gibt ja *.mov mit H.264 aus .

Und ich wandel es eben um um dann damit zu arbeiten.

Somit ist die Antwort wohl noch nicht gegeben.

MfG
B.DeKid



Antwort von Axel:

Ich habe nochmal neue Tests gemacht, diesmal mit Colorbars.

Das bars_RGB zum runterladen.

Die dazugehörigen RGB-Werte sind folgende:

254 254 254 - 254/254/254
190 191 1 - 200/201/3
1 191 189 - 3/201/200
2 190 3 - 5/200/7
189 1 187 - 200/3/198
190 0 2 - 200/0/5
1 0 190 - 3/0/200
0 0 2 - 0/0/5

von Weiß nach Schwarz. 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:

zum Bild




Antwort von dienstag_01:

@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?



Antwort von Axel:

Die roten Werte sind in der Auflistung sind die von dir im QT-Player abgenommenen, richtig? Ja. 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.






Antwort von jogol:

Das löst zwar nicht das QT-Gammashift Problem, ist aber ein sehr gutes Nachschlagewerk für den ganzen technischen Krempel: http://www.arridigital.com/technical/digitalfactbook



Antwort von Predator:

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?



Antwort von dienstag_01:

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.



Antwort von Predator:

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.

QTInput("c:\Gamma.mov", color=2)
Levels(0, 1, 255, 0, 255)

Edit2: Doch net. Geht zwar schon, aber schon in der preview bekomme ich einen leichten rotstich



Antwort von NEEL:

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.

Edit: Für den Rewrap gibts Software: http://www.opencubetech.com/page53/XFConverter

Eigentlich sollte das Problem doch durch umflaggen beim Rewrap ganz einfach lösbar sein...



Antwort von dienstag_01:

Das Problem ist wohl Vegas. Vegas arbeitet immer im 0-255 Farbraum Das machen doch die anderen NLE's auch.



Antwort von dienstag_01:

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)?



Antwort von Predator:

Klar, Export ist auf RGB gestellt. Histogramm sieht aber fast gleich aus wie bei ITU709.

MXF Dateien werden nicht von TMPGenc gelesen, blöderweise.

Ach, ich bleib einfach bei Cineform und benutze DNxHD, wenn ich Sachen in After Effects schiebe.



Antwort von NEEL:

MXF Dateien werden nicht von TMPGenc gelesen, blöderweise. Dann nimm doch den Adobe Media-Encoder. Wenn ein Rewrap nach MXF die gesuchte Lösung für den Gammashift-Bug ist (und darauf deutet alles hin) sollte es ja wohl nicht am nachgeschalteten MPEG-Encoder scheitern.






Antwort von dienstag_01:

Wo nimmst du das Histogramm ab?



Antwort von WoWu:

Hast Du "Lion" drauf ?
In 10.6.x wurde noch nicht ganz auf Quicktime verzichtet. Erst in 10.7.x wird offenbar komplett auf AV Foundation und nicht mehr in QT-C gearbeitet.
Da ist nach meinen Beobachtungen das Problem mit 10.7 (endlich) weg.



Antwort von Predator:

In Vegas.

Die Sache ist ja mittels AVIsynth fast gelöst. Ich muss nichtmal die Level ändern.

Eine in TMPGenc importiere AVS Datei mit dem Inahlt "QTInput("c:\Gamma2.mov", color=2)", also ein simples rewrapping, reicht aus um den korrekten Farbraum zu forcieren. Allerdings ist dann aufeinmal ein unerklärlicher Rotstich mit dabei.



Antwort von dienstag_01:

In Vegas.
Aber heute Morgen hast du geschrieben, dass dein Video in Quicktime verwaschen aussieht. Da kannst du ja nicht das Histogramm aus dem Schnittsystem nehmen.



Antwort von Predator:

In Vegas.
Aber heute Morgen hast du geschrieben, dass dein Video in Quicktime verwaschen aussieht. Da kannst du ja nicht das Histogramm aus dem Schnittsystem nehmen. Ich glaub wir reden bissl aneinander vorbei.
ich hab die Histogramme von ITU709 und RGB nur verglichen um zu sehen, ob es überhaupt einen Unterschied macht.

Die ganze Problematik ist, dass .mov dateien nicht als 16-235 sondern als 0-255 interpretiert werden. Wenn ich DNxHD in AVI rendern könnte, wäre das Problem sofort beseitigt. Wie eben bei Cineform was einen AVI Wrapper hat. Wenn ich Cineform in eine .mov datei stecke wird sie von tmpgenc auch falsch erkannt.

Das ganze Problem ist: .MOV



Antwort von dienstag_01:

Die ganze Problematik ist, dass .mov dateien nicht als 16-235 sondern als 0-255 interpretiert werden. Hab ich ja nun heute gerade nochmal getestet (PC), da ist das nicht richtig.
Siehe letzten Post auf der vorherigen Seite.



Antwort von Predator:

Die ganze Problematik ist, dass .mov dateien nicht als 16-235 sondern als 0-255 interpretiert werden. Hab ich ja nun heute gerade nochmal getestet (PC), da ist das nicht richtig.
Siehe letzten Post auf der vorherigen Seite. Stimmt. Die Frage ist, warum das bei dir richtig angezeigt wird und bei mir nicht. Es muss dann wohl am Export in Vegas liegen.



Antwort von dienstag_01:

Ich rede aber vom QT-Player. Das Video bleibt dabei Schwarz 16 und Weiss 235.



Antwort von Predator:

Davo spreche ich ja auch. Ein aus Vegas exportierer DNxHD clip, bei dem Schwarz bei 16 und weiss bei 235 ist, wird in QT falsch abgespielt. Schwarz ist grau.

Ich lad grad mal die Trial von Premiere CS5.5.
Mal gucken wie es sich da verhält.






Antwort von dienstag_01:

Probier mal, Premiere könnt ich dann auch mal testen.



Antwort von gast5:

http://kb2.adobe.com/cps/402/kb402801.html

vielleicht könnt ihr ja damit was Anfangen..

Die Geschichte hatte ja auch EDIUS bis zur 5.5 betroffen wurde aber in der aktuellen Version6 gefixt ..

betroffen waren alle h264AVC Materialien im MOV oder Mp4 Container die sich der QT Schnittstelle bedient haben...

http://videotreffpunkt.com/thread.php?threadid=10403

hat auch mich Wahnsinnig gemacht.. besonders das bei den "Profis" Achselzucken herrschte und manchen wars noch gar nicht aufgefallen...



Antwort von WoWu:

@motiongroup
Ich glaube, die meinen etwas anderes. Das, was das Papier beschreibt hatte ich anfänglich auch unter Gammashift verstanden, dass die Gammakurve mit dem falschen Faktor ansteigt ....
.... aber die meinen, dass der Farbraum falsch interpretiert wird.

Irgendwo hat er dann sein "Superweisstaste" gedrückt und das NLE macht den Wertebereich auf.
Aber Achselzucken herrscht da eigentlich nicht ....
Und was das AVCHD material betrifft, sollten die Benutzer mal feststellen, ob sie nicht im xvYCC Farbraum arbeiten und nicht in 709.
Da liegt wahrscheinlich der Hase im Pfeffer.



Antwort von dienstag_01:

Irgendwo hat er dann sein "Superweisstaste" gedrückt und das NLE macht den Wertebereich auf.
Sehr sarkastisch, aber leider falsch.

Es geht gerade darum, dass ein standardkonformes Video (16-235) exportiert als h264 im Quicktimeplayer (und auf QT aufsetzende Player) blass und verwaschen angezeigt wird. Der Player müsste ja eigentlich das Video auf den Monitorfarbraum 0-255 "aufspannen". Macht er aber nicht. Bei anderen Codecs, die den Farbraum mit übergeben (macht ja h264 nicht) funktioniert es eigentlich (scheinbar auch nicht aus allen NLE's).

Die Lösung die ich gefunden habe, lautet Sorenson Squeeze 7 und dort das "Input Level is 16" setzen. Direkt aus dem NLE (Avid, Adobe) geht es meiner Meinung nach nicht.



Antwort von WoWu:

Warum sollte ein Player den Wertebereich von 16-235 "aufspannen" ?
1-255 ist lediglich der Übertragungsrahmen, in dem 16-235 mit Videoinhalten gefüllt ist. Über HDMI bekommt man nichtmal mehr Inhalte als bis 240 rüber, es sei denn, es wird dem Empfänger im Auxillary Video Frame mitgeteilt, dass es sich um xvYCC handelt.
Da wird sonst nix "aufgespannt".



Antwort von dienstag_01:

Wenn du dir z.B. eine DVD am Computer anschaust, dann wird auch "aufgespannt", sonst würde sich das das blasse Zeug niemand anschauen, weil der Farbraum nur von Hell- zu Dunkelgrau geht.



Antwort von WoWu:

So einen Quatsch hab ich schon lange nicht mehr gelesen .... schau Dir mal den beschreibenden Standard EIA-CEA-861-B an.
Die Hersteller halten sich schon daran .... und "spannen nix auf".



Antwort von dienstag_01:

Möglicherweise hast du recht. Aber dann wird es eben von Sorenson mit einem Profil verknüpft, dass Schwarz Schwarz und Weiss Weiss ist. Bekomme ich aus dem NLE nicht hin (und habe ALLES versucht).



Antwort von WoWu:

Dann ist der Farbraum vorher bereits "gespreizt" worden.
Dann stimmen aber auch die ganzen Farben nicht mehr ... nicht dramatisch .. aber immerhin stimmen sie nicht mehr.

Abhilfe: Feststellen welches der Originalfarbraum war.
Und ohne Experimente darin weiterarbeiten.
Das klappt auch.

U.u. kommt aus AVCHD ein xvYCC, je nachdem, mit welcher Kamera das Material aufgenommen wurde. Den muss man zuerst mal nach 709 umrechnen und dann damit weiterarbeiten. Das gibt zwar leichte Farbänderungen, aber mit dem xvYCC kann er ohnehin nix anfangen.
(Nur für den Fall, dass das so ist ... Oben steht ja nix weiter, woher das Material kommt und wie es bis dato bearbeitet wurde).



Antwort von dienstag_01:

Lieber Wolfgang, mit der Kamera hat das ausnahmsweise mal gar nichts zu tun.
Mein Beispiel: ich arbeite mit Avid, Arbeitsfarbraum 709. Ich gebe ein Video aus, Broadcast, 709. Das wird dann weiterverwendet im Studio, alles ok.

Jetzt will ich von dem selben Video ein h264 ausgeben, für Previewzwecke auf Computermonitoren, Internet etc. Und da hakt es mit den Quicktime-Exportfunktionen von Avid. Aber auch wenn ich über After Effects gehe, müsste ich das Video nochmal neu farbkorrigieren (0-255) und dann als RGB ausgeben, um meinen ursprünglichen Bildeindruck zu erhalten.

Interessant ist, wenn ich es mit Flash abspiele (Internet, nicht umgerechnet, als mp4), dann wird das Video mit vollem Kontrast wiedergegeben. Das nenne ich "aufgespannt".

Von mir aus könnte ja der Encoder den Farbraum auch umkodieren (vielleicht macht Sorenson das ja auch), aber ich möchte keine extra Farbkorrektur machen müssen.

Edit: Wenn ich 16-235 farbkorrigiere und dann als DNxHD RGB ausgebe, dann funktioniert es ja auch.



Antwort von WoWu:

Und da liegt eben der Irrtum. Du bleibst in 709 und gehst nicht über 0-254. Das Quicktime Problem hat damit nämlich überhaupt nichts zu tun sondern damit, dass Quicktime einen falschen gamma-Korrekturfaktor benutzt hat, nämlich 1,8 und eigentlich... so wie der Rest der Welt, hätte 2,2 bzw. 2,5 benutzen müssen.
Das hat absolut nichts mit dem Übertragungsrahmen zu tun. Der bleibt bei 16-235 ... verlässt Du ihn, kommt zum Fehlgamma auch noch eine Spreizung hinzu. Das sind zwei verschiedene Paar Schuhe. Edit: Wenn ich 16-235 farbkorrigiere und dann als DNxHD RGB ausgebe, dann funktioniert es ja auch. Na also. Zeigt doch, dass es der falsche Faktor bei Quicktime ist. Dem rückst Du aber nicht mit der Spreizung des Übertragungsrahmens zuleibe.



Antwort von dienstag_01:

Daraus werde ich jetzt nur in soweit schlau, das dieses Problem nichts mit dem Gamma-Wert zu tun hat. Aber mit Spreizung?
Ich möchte nur, das ein in h264 exportiertes Video genauso aussieht, wie eins mit DNxHD (zum Beispiel).



Antwort von WoWu:

Nee, das hat mit Gamma zu tun .... Ein zusätzliches Problem entsteht dann durch falsche Handhabung, nämlich durch die Spreizung.
Das haben vor dir tausende von Editoren gewollt und Apple hat es nicht geschafft, das zu korrigieren. Dafür gäbe es kein probates Mittel, weil man an den Wert nicht ran kam, nur eine vergleichende Gammakorrektur im Prog.Amp.
Oder eben kein QT benutzen.
Das ist jetzt nicht zynisch gemeint, es war wirklich so.
Apple hat dann immer Besserung versprochen, aber den Bug erst beseitigt, als (jetzt) mit Lion auch die letzten Reste von Quicktime verschwunden sind.
Mit dem FCPX + Lion geht es mit FCPX und Snow Leo immer noch nicht.

Das hat viele Cutter wirklich krätzig gemacht ... mit Recht. Aber anders geht's (ging's) nicht.



Antwort von dienstag_01:

Wie gesagt, mit DNxHD funktionierts, wird ja auch von Quicktime genutzt, mit h264 nicht. Darüberhinaus arbeite ich am PC.
Also, die Begründung im Gamma zu suchen, wirds nicht sein.



Antwort von WoWu:

Doch, es ist nur das Gamma.
Das haben Heerscharen von Editoren schon über Jahre bemängelt.
Vielleicht zwei Worte, um es transparenter zu machen:
Du musst Dir das wie eine Zahlenreihe vorstellen, die in den "Kästchen" von 16 bis 235 liegen.
Diese Zahlen sind errechnet und stellen den Helligkeitsverlauf da. (Der Anstieg des Helligkeitsverlaufes ist das Gamma)
Wenn Du bei allen Zahlen aber den falschen Multiplikator benutzt, sind alle Zahlen falsch und stellen das falsche Gamma da.
Nun nutzt es nix, wenn Du dieselben falschen Zahlen, einfach in andere "Kästchen" legst und nicht von 16 anfängst, sondern von Null und nicht bei 235 endest, sondern bei 254. Davon werden die Zahlen nicht richtiger, sie liegen dazu noch an den falschen Stellen, denn der Empfänger bekommt gesagt: das was bei 16 liegt ist eben Schwarz (da liegt aber mittlerweile etwas Graues) und das was bei 235 liegt ist weiss, ... da liegt aber nichts weisses, denn das ist bei 254. Die Werte sieht sich der Empfänger aber gar nicht an, weil sie ihn nicht interessieren. Bloss dazwischen, da findet er nun auch noch jede menge leere Kästchen, die er aber in der Darstellung irgendwie füllen muss. Er erfindet also Farben, die sich im Bild dann als Dither darstellen.

Es hilft also nur, die Zahlen in den Kästchen liegen zu lassen, wo sie hingehören und sie statt mit dem falschen Faktor, nun mit dem Richtigen zu berechnen. Dann klappt das auch.
Ich weiss, das war jetzt sehr einfach dargestellt, aber Spreizung ist auch, wie ich finde nicht das Wort.



Antwort von dienstag_01:

Was wäre denn der richtige Faktor?



Antwort von WoWu:

Für sRGB Darstellung 2,2
QT hat aber 1,8, das war für die Printdarstellung auf dem Laserprinter die korrekte Korrektur.



Antwort von dienstag_01:

Ich beschreib dirs nochmal genauer: Wenn ich mein Video mit Schwarz 16 in 709 als h264 ausgebe, dann macht QT-Player daraus 34.
Das hat doch nichts mit Gamma zu tun.
Das ist eher ein Farbraum-Wirrwar.

und ich würde mir lediglich wünschen, dass Schwarz 16 als Schwarz 0 dargestellt wird.
Wie gesagt, mit Sorenson gehts.



Antwort von WoWu:

Ich kann die 34 im Augenblick nicht so nachvollziehen,was das für ein Wert ist und wie er entstanden ist, (64 würden wieder Sinn machen, dann wären das 10 statt 8 Bit) ... aber wir reden schon über genau dasselbe Problem, es sei denn, bei der Ausgabe wird zusätzlich noch ein falscher Farbraum angegeben und wir haben es mit 2 Schwachstellen zu tun, nämlich mit dem Gammafaktor und mit der Verlagerung der Werte im Transportraum, zumal H264 der erste Codec ist, der auch erweiterte Farbräume verarbeitet. Hier würde ich einmal genau in den Detaileinstellungen nach schaun.



Antwort von dienstag_01:

Ich weiss jetzt nicht, was der Transportraum ist, aber:

für mich sieht das nach einer Fehlinterpretation aus. QT-Player bekommt ein Video in 709 und setzt den dunkelsten Wert auf 16. Der ist aber schon auf 16. Also wird daraus 32 (34 liegt in der Toleranz). Beim Weiss passiert übrigends dasselbe: aus 235 wird 219, spricht für meine Vermutung.



Antwort von WoWu:

Aber der Player liest doch den Wert aus der Tabelle , die er übermittelt bekommt und kopiert sie, er sie bekommt. Wenn er ein 8 Bit Signal sieht, stellt er es auch so da. In den 16. werterem stellt er auch nur ein, was sich im Zuspielsignal befindet. Wenn da ein anderer Wert drin ist als Hex-für-Schwarz, dann wird er den auch da reinschreiben. Und wenn der Wert Hex- für irgend einen Grauton ist, dann stellt er den auch als ersten Wert da.
Da bin ich jetzt überfragt, ob die zugespielten Werte über QT berechnet wurden oder ob der QT Player im PC die Sichtkorrektur vornimmt. Kommt auf den Workflow des Materials an.



Antwort von dienstag_01:

Scheinbar nicht.

Edit: Hab da mal ein Buch drüber gelesen (DVD Studio Pro von Uli Plank), ist schon etwas her, ich erinnere mich aber, dass er auch beschrieben hat, das verschiedene Player die Werte verschieden interpretieren. Software-Player, nur da taucht das Problem ja auf, weil der Computermonitor mehr Werte darstellt, als in der Videospezifikation vorgesehen sind.



Antwort von WoWu:

Nur das ist ja in 709 in Stein gemeisselt und das wäre auch für mich völlig neu, dass der QU Player die Werte nicht normgerecht überträgt. Das Einzige, das QT bisher hatte, war das Shifting. Denn das würde sich noch ganz anders bemerkbar machen, weil Bit 1 und Bit 255 Synchronbits sind, in denen ohnehin keine Werte für die Verarbeitung sitzen.
Nee, nee, das sind schon die üblichen Verdächtigen ..



Antwort von dienstag_01:

Sorenson Squeeze nennt die Einstellung, mit der's klappt: Input Video is RGB 16-235.
Spricht auch irgendwie für eine Art von "Interpretation".

Edit: Weil, danach zeigt der Player das Video mit S=0 und W=254, ob er das nun so rechnet oder der Player das nur "richtig" interpretiert, hab ich noch nicht rausbekommen.



Antwort von WoWu:

:-)) Nee, das ist nur eine andere Bezeichnung als 709. Das ist genau, was es eigentlich ist: Korrekt. Und ziemlich unmissverständlich. Nur in 709 steht natürlich noch ein bisschen mehr drin, als nur die Westgrenzen für das Videosignal.
Aber ist völlig richtig.

Morgen haut der NEEL uns windelweich, dass wir hier zu nachtschlafender Zeit seinen Thread vollmachen.
Ich spring jetzt raus, bevor ich mir morgen Prügel einhandle.



Antwort von dienstag_01:

Ok, halten wir mal fest:

ein Video auf einem Comutermonitor darzustellen, beinhaltet die Schwierigkeit, dass dessen Farbraum größer als der in den Specs für Video beschriebene ist.
Mit einigen Codecs ist das kein Problem, mit so gängigen wie h264 aber schon. Ergebnis: das Video hat einen eingeschränkten Kontrastumfang, sieht flau aus.
Bei Verwendung des Videos im Internet unter Zuhilfenahme von Flash (mp4 Container, zum Beispiel YT) tritt das Problem nicht auf.
Mein Workflow: Video in 709 bearbeiten und farbkorrigieren (16-235), mit Sorenson Squeeze encodieren (Input is 16-235), Ergebnis: Luminanzwerte werden über den kompletten Luminanzbereich von 0-255 dargestellt (voller Kontrast).
Der Weg über After Effects und den Adobe Media Encoder hat mir noch nicht die gewünschten Ergebnisse gebracht, möglicherweise gibts den aber.

Edit: Für die Darstellung des Videos im QT-Player gibt es noch den Workarround mit vorrübergehenden Umstellung der Transparenzeigenschaften unter visuelle Eigenschaften (QT Pro), Nachteil: keine globale Einstellmöglichkeit, müsste man für jedes Video neu machen.
Ebenfalls möglich ist, die Videoeigenschaften der Grafikkarte zu verändern, hab ich aber keine Erfahrung, wie sich das auf z.B. Videos auswirkt, die eigentlich "richtig" wiedergegeben werden.



Antwort von gast5:

http://www.photoscientia.co.uk/Gamma.htm


bringt etwas Luft rein..



Antwort von dienstag_01:

bringt etwas Luft rein. Nur zum Teil. Die falsche Darstellung von h264 Videos (wie oben beschrieben) bleibt natürlich auch an einem kalibrierten Monitor falsch.



Antwort von gast5:

nein dem ist nur dann so wenn die verwendete Software auf einer nicht modifizierten QT Import Export Schnittstelle aufbaut..

Bei Edius war dies bis zur Version 5.5 so was aber in der Edius 6 behoben wurde. Den obigen Link zu den Playern habe ich nur hinzugefügt um aufzuzeigen das eine Beurteilung am PC überhaupt nicht möglich ist...
Was nützt es die Gammawerte zu kalibrieren wenn die NLE oder die Player schon beim Import alles falsch interpretieren??

Wie gesagt, es ist den Profis über Jahre nicht aufgefallen....Bei Adobe haben sie über 4 Jahre gebraucht um zu erkennen aber nicht zu reagieren den bis zur CS4 wurde es nicht behoben.

Die Auflistung was wann mit welchem Material geschieht ist der einzig praktikable Ablauf.

erstens beim Import falsch interpretiert.
zweitens bei der Ausgabe falsch verarbeitet..

Lösung dafür finden via Splitscreen, Diffkeyer, Vectorscope, Viewer usw.

Für das Material den passenden Weg merken..

http://chrismarquardt.com/blog.php?id=7 ... 7447333704



Antwort von WoWu:

Ich hatte das oben schon angemerkt.
Der Autor des Artikel hat sein FCPX mit 10.6.x betrieben, das aber noch diverse Teile von QT benutzt.
Sobald er auf 10.7 umstellt, das nun keinerlei Reste von QT mehr aufweist, klappt auch das Gamma in FCPX.
In irgend einem Thread hatte ich auch beschrieben, warum das so ist. Will ich jetzt nicht wiederholen.



Antwort von gast5:

Wo hast du das her Wolfgang .... ich bin auf Lion unterwegs und QT ist vorhanden.. QTX und QT7...

Es stimmt zumindest das der GammashiftBug bei mir nicht nachweisbar ist wobei ich aber im Moment selten mit h264 AVC MOV oder Mp4 arbeite..

bei meinem aktuellen Projekt verwende ich umgepacktes AVCHD Material welches via Clipwrap in den MOVContainer umgepackt wurde, da die AVCHD Clips nicht mit der CAM eigenen Verzeichnisstruktur angeliefert wurden und somit mit FCProX nicht nativ verstanden wird..



Antwort von soan:

Schonmal versucht die von dir exportierten Clips auf einem anderen Rechner zu sichten?

Ich hatte mal Probleme mit diversen "nicht kalibrierten" Software-Playern, die durch diverse Settings die Videos bei der Wiedergabe schlicht und ergreifend falsch wiedergegeben haben. Das fängt bei den Output-Settings der Grafikkartentreibern schon an und zieht sich durch etliche Instanzen.

Eventuell wurde das Output-Modul des NLE zb von der VLC-Player-Installation umgeschrieben und dadurch mit falschen Werten belegt?

Ich hab keinen Bock mir den ganzen Thread hier durchzulesen, ich kann aber aus eigener Erfahrung sagen:

- Installation von Software-Playern wie zb VLC kann einem das ganze System madig machen, selber schon mehrmals erlebt.
- falsche Einstellungen zb der GraKa-Treiber kann die komplette Wiedergabe madig machen - ist zwar banal aber muss man erstmal drauf kommen.

Vielleicht hilft es ja, wenn nicht - dann nicht ;-)



Antwort von WoWu:

Wo hast du das her Wolfgang .... Eigene Erkenntnis, denn wir haben das Gammshift mit FCPx natürlich gleich mal ausprobiert .... es war aber auch bei FCPx noch da.
Als wir dann auf Lion umgestellt hatten, haben wir unmittelbar neu getestet. Ergebnis: weg.
So wie wir das sehen, hing es mit der QT Verwendung zusammen weil in 10.6 noch diverse Classes aus der QT C-API benutzt wurden.
Das ist in 10.7 nun nicht mehr so und damit dürfte QT, und nun auch der Gamma Bug, Vergangenheit bleiben.



Antwort von gast5:

na ja Fehler behoben, aber QT ist immer noch mit von der Partie in Form von QTX 10.1 und QT7..



Antwort von WoWu:

Ja, ich befürchte, das bekommst Du wirklich nur raus, wenn Du komplett umgestellt hast und selbst die Bezeichnung am besten nur noch hinter vorgehaltener Hand benutzt. :-))
(Aber sind die Server nicht auch umgestellt) ??

Aber Apple scheint wirklich nicht viel Aufwand mit der Behebung von Problemen zu betreiben oder Bugs zu fixen .... das ist eigentlich einwenig schade denn was nutzt mir die nächste Technologie, die alles viel besser macht, wenn ich die Alte noch die nächsten Jahre benutzen muss.



Antwort von gast5:

sorry aber ich verstehe dich nicht.. was soll ich umstellen??

ich bin auf OSX Lion und FCutPro X QT ist nach wie vor an Board in beiden Versionen ... der Bug ist zwar weg und das ist auch gut so..
Server?? wie was? ich schneide Privat mit nem neuen 2011 MacBookPro17" fertig alles..



Antwort von WoWu:

Ich hatte das QTX und 10.1 falsch interpretiert. Disregard ... :-)



Antwort von gast5:

okok nur wie sieht es nun mit der Aussage aus das unter Lion kein QT mehr vorhanden ist, resp. verwendet wird??



Antwort von WoWu:

wenn du in 64bit arbeitest, ist das so. Weil das System auf AV-Foundation aufsetzt. Es hat zwar nicht soviel Classes und Methode, wie Quicktime, aber immerhin mehr als noch QTKit.
Es ist ja weniger eine Frage, wie ein Player heisst, sondern mehr, mit welchen Tools er arbeitet.



Antwort von gast5:

na das ist mal eine Brotkrümelsuche aber danke für das Lösen des Gordischen Knotens..

http://www.philiphodgetts.com/2010/08/i ... oundation/



Antwort von Ma2ko:

Besser spät als nie!
Das Problem hat mich erst die letzten paar Monate beschäftigt.
Da ich keinen Mac habe konnte ich viele Lösungsansätze nicht ausprobieren.
Ich konnte z.B. nicht den codec x264 statt h264 in Quicktime verwenden.
Laut Beschreibung verwedet mein encoder Avidemux x264 was mir aber
nichts gebracht hat. VLCplayer, winMedia player, Premiere CS3 und
youtube haben das Video korrekt wiedergegeben. Vimeo, Quicktime und
mein auf QT basierender JW player haben es verwaschen.(aus schwarz
wurde dunkelgrau)

Getstet unter winXP und win7 mit Firefox und Opera

vimeo


youtube


Ich habe hunderte posts darüber gelesen, das Problem liegt daran wie QT
mp4 wiedergibt.
In irgendeinem Forum schrieb jemand dass mit HandBrake dieses
Problem nicht auftritt. Und es ist (zumindest bei mir) tatsächlich so.
Ich verwende in HandBrake die gleichen Einstellungen wie in Avidemux
mit dem Unterschied dass bei der Wiedergabe in QT schwarz immernoch
schwarz bleibt und nicht dunkelgrau.

hier das neu codierte Video im JW player
http://www.leerywitter.com/frameprj.html

Gruß, Marko



Antwort von axl*:

Mit dem Video kann ich nix anfangen. Alles abgesoffen und ausgefressen.

Das Thema betrifft ja nur die Darstellung der jeweiligen App. Ich verbiete das einfach im Setup der Grafikkarte und habe durchgehend keine Probleme:



Antwort von dienstag_01:

Ich verbiete das einfach im Setup der Grafikkarte und habe durchgehend keine Probleme: Vergleiche die beiden Videos auf YT und Vimeo nochmal genau, dann wirst du sehen, dass deine *Lösung* keine Lösung ist.
Diese *Lösung* gibt es in dem Sinne auch gar nicht, da der Farbraum bei mp4/h264 von dem einen Player so, von dem anderen Player eben anders interpretiert wird. Ein einheitliches Ergebniss ist da nicht zu erhalten.



Antwort von Angry_C:

Auf dem PC: H264 Mp4 wird mit dem Windows Mediaplayer korrekt angezeigt und mit VLC milchig und desaturiert.

Auf dem Mac unter Mountain Lion: Alles H264 Material, auch direkt aus AVCHD oder H264.mov wird mit Quicktime Player milchig und desaturiert mit falsche Farben angezeigt und mit dem VLC player, einem Bluray SW Player und Toast Player wird es exakt so angezeigt wie es in der Adobe Premiere Timeline Vorschau auch zu sehen ist.

Das ist momentan mein Stand und denke es ist unter OSX der Quicktime player, der den Farbraum und Gamma falsch interpretiert, während VLC das auf dem PC nicht richtig hinbekommt.



Antwort von axl*:

Auf meinem Windows System gibt es dieses Problem nicht. Dass vorher die Windows Farbverwaltung korrekt eingerichtet wurde ist unumgänglich.

Ich habe gerade ein durchgehendes Video mit der Cam direkt vom Monitor abgefilmt um das zu dokumentieren. Das ist natürlich qualitativer Murks, aber für das Erkennen von Gammaveränderungen genügt es. Es wird dort zwischen Mediaplayer, VLC, Divxplayer, sowie Youtube und Vimeo live hin und her geschaltet. Die Abweichungen sind marginal. Mein System ist zusätzlich gespidert und die dortige Monitorausgabe deckt sich ziemlich gut mit der Anzeige eines Studiomonitors.





Antwort von dienstag_01:

@axl*
Darum geht es doch gar nicht. Versuche folgendes: exportiere ein mp4/h264 Video aus deinem NLE. Schau dir diese Video in verschiedenen Softwareplayern an. Es wird verschieden wiedergegeben werden.



Antwort von axl*:

???

Was meinst du denn, was in meinem Video gezeigt wird? Es wird eben NICHT verschieden wiedergegeben.

Ich hatte das von dir beschriebene Problem früher auch und nun habe ich es nicht mehr.



Antwort von Angry_C:

Alles klar, unter Osx konnte ich feststellen, dass nur der Quicktimeplayer und Fcpx mein mit einem colorimeter calibriertes Displayprofil berücksichtigt, alle anderen Player und Premiere Pro greifen darauf nicht zurück. Wenn ich nun als Displayprofil einfach das sRGB Profil auswähle, sieht es in jedem Player gleich aus.

Habe nun erstmal den Monitor auf Werksseitig sRGB gestellt und das sRGB Displayprofil beibehalten - kalibriere nochmal neu. Vielleicht hatte ich da falsche Einstellungen verwendet.

Vielleicht weiß das jemand von Euch. Ich habe einen Dell 2711 Ultrasharp. Verwende ich beim Kalibrieren die Einstellungen für einen Wide Gammut LCD?



Antwort von Angry_C:

???

Was meinst du denn, was in meinem Video gezeigt wird? Es wird eben NICHT verschieden wiedergegeben.

Ich hatte das von dir beschriebene Problem früher auch und nun habe ich es nicht mehr. Ja, anhand deines Videos kann man gut erkennen, dass du keine Probleme mit unterschiedlicher Anzeige hast.

Auf dem PC hat bei mir nur der VLC ein helleres Bild, sonst passt es.



Antwort von axl*:

Beim Umstellen der Farbprofile in der Windows Farbverwaltung, gerade im Zusammenhang mit Spidern, muss das System zur vollständigen Übernahme neu gestartet werden. Das hat mich mal Einiges an Nerven gekostet. Der Königsweg scheint es zu sein zunächst den Spider zu deaktivieren, dann die Farbverwaltung einzurichten, jeweils neu starten und dann erst neu spidern.



Antwort von Angry_C:

Der Witz unter Windows (zumindest Win7), mein Profil deaktiviert sich nach einiger Zeit (tage-wochen) von selbst. Dann hat er plötzlich wieder standard srgb angeschmissen.



Antwort von axl*:

Das Spider Profil oder das Win Profil?



Antwort von WoWu:

Vielleicht weiß das jemand von Euch. Ich habe einen Dell 2711 Ultrasharp. Verwende ich beim Kalibrieren die Einstellungen für einen Wide Gammut LCD? Normalerweise nicht.
Und im Betrieb auch nur, wenn der Monitor eine color-gamut conversion function hat.



Antwort von Angry_C:

Das Spider Profil oder das Win Profil? Das Spyderprofil wird deaktiviert. Ich weiß nicht, woran das liegt. Schalte ich dann einmal zum Windows Profil und wieder zurück, ist alles wieder gut.



Antwort von Angry_C:

Vielleicht weiß das jemand von Euch. Ich habe einen Dell 2711 Ultrasharp. Verwende ich beim Kalibrieren die Einstellungen für einen Wide Gammut LCD? Normalerweise nicht.
Und im Betrieb auch nur, wenn der Monitor eine color-gamut conversion function hat. Danke Wolfgang, dann war das vielleicht mein Einstellungsfehler. Muss ich testen...



Antwort von dienstag_01:

???

Was meinst du denn, was in meinem Video gezeigt wird? Es wird eben NICHT verschieden wiedergegeben. Sorry, hatte ich vorhin noch nicht gesehen.
Ich hatte das von dir beschriebene Problem früher auch und nun habe ich es nicht mehr. Schalte doch mal spaßeshalber deine Nvidia-Einstellung auf Video-Player um, da müsstest du schon einen sehr alten VLC-Player haben, dass der das Video falsch anzeigt.
Ich will damit sagen, dass war alles mal sehr verworren, hat sich aber inzwischen stark verbessert. Ich würde trotzdem nicht davon ausgehen, dass es mit allen klappt.
An den Einstellungen der Grafikkarte zu drehen war aber für jemanden, dem es darum ging, seine Videos möglichst kompatibel für viele Player auf verschiedenen Rechnern zu machen, eigentlich nie der Weg.
Aber egal, scheinbar ist es sogar wieder an der Zeit, die Kompatibilität zwischen Windows und Mac neu zu untersuchen. Da hatte ich nämlich bisher zwei verschiedene Files für :(