Postproduktion allgemein

Titel: · vom: So 27 März, 2011 17:49

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?

Titel: · vom: So 27 März, 2011 23:57

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.

Titel: · vom: Mo 28 März, 2011 08:41

Titel: · vom: Mo 28 März, 2011 11:43

Titel: · vom: Do 31 März, 2011 14:04

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.

Titel: · vom: Do 31 März, 2011 17:06

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.

Titel: · vom: Do 31 März, 2011 17:45

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

Titel: · vom: Do 31 März, 2011 18:41

Titel: · vom: Do 31 März, 2011 19:04

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

Titel: · vom: Fr 01 Apr, 2011 00:07

Titel: · vom: Fr 01 Apr, 2011 00:21

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

Titel: · vom: Fr 01 Apr, 2011 00:28

Titel: · vom: Fr 01 Apr, 2011 04:56

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

Titel: · vom: Fr 01 Apr, 2011 11:06

Titel: · vom: Fr 01 Apr, 2011 12:43

Titel: · vom: Fr 01 Apr, 2011 13:14

Titel: · vom: Fr 01 Apr, 2011 13:25

Das Schwarzwert-Video ist hier

Titel: · vom: Fr 01 Apr, 2011 13:31

Titel: · vom: Fr 01 Apr, 2011 13:40

Titel: · vom: Fr 01 Apr, 2011 14:27

Hier noch ein paar Screenshot-Vergleiche:

Titel: · vom: Fr 01 Apr, 2011 14:28

und das letzte:

Titel: · vom: Fr 01 Apr, 2011 14:33

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.

Titel: · vom: Fr 01 Apr, 2011 15:23

Titel: · vom: Fr 01 Apr, 2011 15:41

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

Titel: · vom: Fr 01 Apr, 2011 16:37

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.

Titel: · vom: Fr 01 Apr, 2011 17:11

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?

Titel: · vom: Fr 01 Apr, 2011 17:38

Titel: · vom: Fr 01 Apr, 2011 17:51

Titel: · vom: Fr 01 Apr, 2011 18:18

Titel: · vom: Fr 01 Apr, 2011 19:23

Bingo. RGB kontra YUV.

Titel: · vom: Fr 01 Apr, 2011 19:24

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/93322/532294.aspx#532294

Grüße, Filbert

Titel: · vom: Fr 01 Apr, 2011 19:51

Titel: · vom: Fr 01 Apr, 2011 19:58

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

Titel: · vom: Mo 09 Mai, 2011 15:21

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.

Titel: · vom: Di 10 Mai, 2011 00:10

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.