Predator hat geschrieben:
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.
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.
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.
Aber heute Morgen hast du geschrieben, dass dein Video in Quicktime verwaschen aussieht. Da kannst du ja nicht das Histogramm aus dem Schnittsystem nehmen.
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.
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.
@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.
WoWu hat geschrieben: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.
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".
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.
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".
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).
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).
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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 ..
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.
Rechtliche Notiz: Wir übernehmen keine Verantwortung für den Inhalt der Beiträge
und behalten uns das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
