Angry_C hat geschrieben:
Aber beide Clips verursachen in Premiere Highlights bei ca. 1.07V oder 107%.
Daher würde ich sagen, dass die Kamera immer von 0-255 aufzeichnet, ob x.v. color oder net.
Genau das habe ich eben auch festgestellt und mich gewundert, warum ich Werte über 100 bekomme. Du kannst übrigens das sehr schön im Vectorscope sehen. Gleiches Motiv und nur mal x.v color umgeschaltet. Da siehst Du, warum die Farben kräftiger wirken.
Ja, das ist schon nen Ding. Da die Panasonic ja eher flau aufzeichnet, macht es meiner Meinung nach ja Sinn, mit x.v.colour aufzunehmen, wenn es in der Amplitude eh kenen Unterschied zu machen scheint, und man bei beiden Modi die Highlights "retten muss".
Zumindest hat man dann out of cam schonmal kräftigere Farben, wenn man es mag. Ich mag's ;-)
Davon abgesehn scheinen sich die Waveformanzeigen der NLE's auch noch zu unterscheiden.
Im Moment traue ich nur DaVinci. Zumindest bringt er Übereinstimmung bein Belle Nuit Chart (also auch den Wert 255) Bei FCPX kann ich den mit der Pipette nehmen, aber Waveform endet bei 100 ! Könnte man jetzt auf die Verarbeitung von dem Tiff schieben, aber sehen kann man 255, nur der Waveform zeigt es nicht an.
Mein Wolkenbild sieht im Waveform bei DaVinci auch anders aus.
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Aber beide Clips verursachen in Premiere Highlights bei ca. 1.07V oder 107%.
Daher würde ich sagen, dass die Kamera immer von 0-255 aufzeichnet, ob x.v. color oder net.
Nein, eben nicht !!
Wenn beide Signale am HDMI Eingang die korrekten Werte anstellen (signalisierung) und dazu beide Signale unterschiedlich dargestellt werden, nimmt die Kamera entlang der Spezifikationen korrekt auf !
Premiere baut den Mist.
Nun wird man untersuchen müssen, wieso die nicht mal ein standardisiertes Signal vernünftig gemapped kriegen.
Und damit haben wir auch die erste Antwort auf die Eingangsfrage:
Durch die Änderung im Begrenzungsverhalten haben sie einen bestehenden Bug beseitigt, weil sie, würden sie ein Standardsignal korrekt mappen, bei 235/240 mit einem Clip korrekt handeln würden (die GH2 macht das sogar schon in der Kamera, vermutlich um Datenrate zu sparen).
Jetzt wäre natürlich noch interessant wie sich speedgrade im Verhältnis zu Premiere verhält...ein Vegas ein Edius ein smoke ein Piranha ..
Der colorpipete Test ist nicht uninteressant zumindest um zu sehen wie sich schon alleine die unterschiedliche monitortechnologie auf das Sehen auswirkt..
WoWu hat geschrieben:
Und damit haben wir auch die erste Antwort auf die Eingangsfrage:
Durch die Änderung im Begrenzungsverhalten haben sie einen bestehenden Bug beseitigt, weil sie, würden sie ein Standardsignal korrekt mappen, bei 235/240 mit einem Clip korrekt handeln würden (die GH2 macht das sogar schon in der Kamera, vermutlich um Datenrate zu sparen).
Naja, das neue Premiere macht beim Import der Clips nichts anderes als die Vorgängerversionen. Nur der neue Lumininanzkurvenfilter cuttet einfach mal die Highlights weg. Das ist das schlimmste, was Premiere mit dem Material anstellen kann. Von Bugbeseitigung kann eigentlich keine Rede sein.
motiongroup hat geschrieben:Jetzt wäre natürlich noch interessant wie sich speedgrade im Verhältnis zu Premiere verhält...ein Vegas ein Edius ein smoke ein Piranha ..
Eric Olson hat schon 2009 auf eine spezielle Vegas-Eigenschaft hingewiesen:
Although the 709 transfer function specifies 16 as black and 241 as white. The 8-bit video rendering path in Sony Vegas processes the full 0 to 254. As a result super blacks and super whites are automatically available when color grading. Note, however, that Adobe Premier may delete the x.v.color information. I'm not sure about other NLEs.
Let's featurerequest/bugreport about superwhite and chromaproblems http://www.hv20.com/showthread.php?1219 ... maproblems
There is no harm recording x.v.color mode, because in the worst case, the extra dynamic range is simply ignored.
Because you’re evaluating the internal state of the image data, the scales of the WFM and Parade scopes always reflect 10-bit full range data from 0-1023, regardless of your project’s Colorspace Conversion settings.
Motion, danke. Somit bleibt noch die Frage, warum der Eyedropper 255 anzeigt, Waveform aber bei 700 max ist. Dachte eigentlich, das das Vorschaubild irgendwie analog dem Waveform ist, dachte..
Wie solche Sachen bei FCP behandelt werden, kann man wohl einstellen (White,oder Superwhite), aber bei FCPX wohl nicht (d.h. wie solche Bilder behandelt werden sollen, RGB).
olja hat geschrieben:Somit bleibt noch die Frage, warum der Eyedropper 255 anzeigt, Waveform aber bei 700 max ist. Dachte eigentlich, das das Vorschaubild irgendwie analog dem Waveform ist, dachte..
Ich hatte ja schon mehrmals darauf hingewiesen, dass die meisten NLEs das Video für die Anzeige nach 0-255 mappen müssen. Wenn man mal genau schaut, sieht man auch, dass sie in den Waveforms nie 16 oder 235 oder auch 255 als Einheiten benutzen. Immer Prozent oder IRE oder mV.
Überleg mal, was eine korrekte Anzeige von 16-235 für das Grading bedeuten würde!!!
Ihr setzt jetzt genau das fort, was die Blogs schon viel Jahre tun .... ihr testet einfach wild in der Gegend herum, bekommt 'random" irgendwelche Ergebnisse, völlig egal, was die Ursache ist und ob sie überhaupt vergleichbar sind und streut dazwischen dann noch irgendwelche Stellungnahmen, statt systematisch nun zu untersuchen, warum Premiere das so verarbeitet und es zu einem solchen, falschen Ergebnis führt.
@domain
Die Aussage von dem "Vegas" mann "pflegt" natürlich das eigene Programm.
Grundsätzlich ist es aber so, das alle Programme die Contents richtig mappen sollten (tun sie nicht) und auch die Gamet Informationen korrekt auslesen sollten. (offensichtlich auch nicht)
Denn dann gäbe es keine Unterschiede mehr.
Aber die Gamut Informationen auch nicht richtig auszulesen und den Mangel dann als Vorzug gegenüber andern Programmen zu deklarieren ist natürlich auch nichts anderes als ein Marketingtrick.
Die Thematik wird in der Tat schon seit Jahren diskutiert und betrifft natürlich nicht nur Adobe, aber auch. Ja und? Werden wir mit einer gewissenhaften Ursachenforschung Adobe zu irgend einem Umdenken oder zu irgendeiner Änderung bewegen können?
Im Grunde doch egal. Bei den allermeisten Clps tritt das Problem ja gar nicht auf und wenn, dann weiß man ohnehin was zu tun ist und das ist eine 2cm Mausbewegung auf dem Pad und fertig.
Ärgerlich ist nur, dass man bisher einiges verschenkt hat und neu schneiden wird man deswegen wohl kaum.
Um mal auf Premiere zurückzukommen, der Bug wurde doch bereits von Adobe bestätigt und das er schnell gefixt wird. Was soll man da denn in einem vom Hersteller fehlerhaft bestätigten Programm rumpopeln ?
Der Thread wurde einfach gehijackt und im Moment ist eher der Stand, was die Panas oder meinetwegen auch die Canon, Sonys mit ihren x.v. Colors da in diesem Zusammenhang so treiben und wie sich das Material im NLE od. Fernseher verhält. So richtig klare Aussagen hab ich noch nirgends finden können, da hast Du recht. Überall das gleiche schwammige Gestochere ;-) Wer oder was flagt da, bzw.was wird von wem wie erkannt.
@Domain, so sehe ich das auch. Wir reden hier von Consumercams, wo man evtl. noch ein paar Regler drehen kann, um ein angenehmeres Bild zu bekommen.
Das kannst du selbst leicht nachprüfen indem du einen 0 -255 Gradient BW in verschiedenen Formaten in die Timeline legst als pip nebeneinander legst und kontrollierst.. In fcpx werden sie immer wie auch bei davinci im Normalfall in 10bit verarbeitet..
Anders herum, die xv werden in fcpx bis 100% gemappt was ohne x.v nicht umgesetzt wird.. Bei den Blauwerten geht's bei beiden Varianten bis NULL
sprich für fcpx hab ich einen Schritt weniger zu beachten wenn ich xv aufzeichne mit den panas in diesem Fall, denn bei der Ausgabe ist es so oder so vollkommen egal da ich kein xv bei der Ausgabe aktivieren kann..
Was noch so anfällt.. Bei fcpx ist die Anpassung, Spreizung oder Mapping nicht erst ab der Timeline sondern ab Import resp. schon im Event aktuell..die Scopes schon mal im Eventbrowser antesten..
Interessant wäre es nur wie sich die Geschichte beim SDI HDMI Ausgang verhält ...
Zuletzt geändert von gast5 am Mi 26 Jun, 2013 16:13, insgesamt 1-mal geändert.
Von Adobe gibt es dazu ja keine offizielle Aussage und so, wie sie es jetzt machen, ist es ja auch korrekt.
Bleibt als abzuwarten ob sich was ändert.
Vielleicht ändern sie ja auch ihr Mapping endlich mal so, wie es den Flags entspricht .... das wäre dann endlich mal eine richtige Bugbeseitigung.
Davon hätten dann auch die Amateure mal was und müssten nicht ständig an ihrem Signal kurbeln, um es halbwegs passend zu machen.
Kann gut sein, denn so, wie es gehandhabt wird, ist es eigentlich richtig.
Auch wenn alle Amatuere schreine.
Man kann eben nur hoffen, dass sie durch die "Bug-Reports" angestossen werden und mal nachschaun'n, ob sie nicht lieber die Files standard-konform mappen.
In dem Link steht ja auch nichts anderes, als dass sie es zur Kenntnis genommen haben und man einen Report schreiben könnte.
Ich stimme da Bubbles Ansicht zu, dass es bei der Überführung nach RGB (Floating-Point Bearbeitung) passiert.
Aber dazu müsste man eben den Workflow mal beleuchten.
(Mal ganz abgesehen davon ... wer "Superweiss" haben will, weil sein Monitor kein Colormanagement hat, kann ja YCC machen. Dafür ist es ja vorgesehen.
Der muss ja nicht in 709 arbeiten und erwarten, dass es wie YCC funktioniert.
Da hat er doch genau das, was er sucht.
Ich verstehe also die ganze Aufregung nicht.
Because you’re evaluating the internal state of the image data, the scales of the WFM and Parade scopes always reflect 10-bit full range data from 0-1023, regardless of your project’s Colorspace Conversion settings.
Ok, ich geb jetzt keine Ruhe ;-) Der Belle Nuit in DaVinci schlägt doch bis 1023. Hier kommt mir alles plausibel vor (Colorpicker und Waveform, die Werte sieht man noch vom Picker) Bei FCPX (gleiches Bild) endet der bei 700mV, also 235 !? Da stimmt er nicht.
Lieg jetzt damit falsch ?
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
@Olja
Ich kenn mich leider mit Resolve nicht so gut aus, habe es bei mir wieder gelöscht. Aber teste doch mal: die Charts exportiert (als Video) aus FCP und dann importiert nach Resolve. Und dann mal schauen, was verschiedene Color Managment Einstellungen bringen.
dienstag_01 hat geschrieben:@Olja
Ich kenn mich leider mit Resolve nicht so gut aus, habe es bei mir wieder gelöscht. Aber teste doch mal: die Charts exportiert (als Video) aus FCP und dann importiert nach Resolve. Und dann mal schauen, was verschiedene Color Managment Einstellungen bringen.
Ich kenne Resolve auch nicht gut, ist nicht unbedingt meine Baustelle. Der Tag hat nur 24h ;-)
Aber, der Testchart, der in FCPX bei 700 endet, kommt mit ProRes exportiert und importiert in Resolve wieder auf 1023. Also das gleich Ergebnis :-O. Der fliegt mit auch 10-Bit ein.
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
@Olja
Daran siehst du schon mal, dass dein FCP keen Quatsch macht ;)
Ob das der richtige Workflow mit Resolve ist, weiss ich nicht.
(Sieht so aus, als würde dort wieder auf FullRange gespreizt. Vielleicht muss das so sein. Aber vielleicht funktioniert es mit Color Managment auch anders.)
Ich habe ich ProRes exportiert ! Mehr nicht. Deshalb hab ich es nochmal hinzugeschrieben.Von mir aus nochmal in h264. Wird nur unsauberer, ändert aber nichts.
Büddeschön
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Schön langsam kommt mir vor, dass Tiefflieger gar keinen so blöden Workflow für sich entwickelt hat, denn Veränderungen in der Originalfootage verfolgt er ja nicht.
Schneidet in Magix und lässt die Originalqualität wieder smart rausrendern. Damit werden offenbar alle relevanten Flags über HDMI an seinen Plasma weitergeleitet und dort auch korrekt interpretiert.
Aus dem Grund sieht er daheim auch viel mehr (und betont das ja auch) als wir jemals in seinen unzähligen übermittelten Bildern imstande sein werden zu erkennen: keine überstrahlten Lichter und auch kein Türkis im Himmel.
domain hat geschrieben:Schön langsam kommt mir vor, dass Tiefflieger gar keinen so blöden Workflow für sich entwickelt hat, denn Veränderungen in der Originalfootage verfolgt er ja nicht.
Schneidet in Magix und lässt die Originalqualität wieder smart rausrendern. Damit werden offenbar alle relevanten Flags über HDMI an seinen Plasma weitergeleitet und dort auch korrekt interpretiert.
Aus dem Grund sieht er daheim auch viel mehr (und betont das ja auch) als wir jemals in seinen unzähligen übermittelten Bildern imstande sein werden zu erkennen: keine überstrahlten Lichter und auch kein Türkis im Himmel.
Du vergisst dabei aber den Weißabgleich, der so gut wie nie zufriedenstellend sitzt.
Aus dem Material kann man mit der Luminanzkurve, einer 3-Wege Farbkorrektur, einem unscharf maskieren Filter und natürlich einem guten Rendercodec noch wesentlich mehr herausholen.
domain hat geschrieben:Schön langsam kommt mir vor, dass Tiefflieger gar keinen so blöden Workflow für sich entwickelt hat, denn Veränderungen in der Originalfootage verfolgt er ja nicht.
Schneidet in Magix und lässt die Originalqualität wieder smart rausrendern. Damit werden offenbar alle relevanten Flags über HDMI an seinen Plasma weitergeleitet und dort auch korrekt interpretiert.
Aus dem Grund sieht er daheim auch viel mehr (und betont das ja auch) als wir jemals in seinen unzähligen übermittelten Bildern imstande sein werden zu erkennen: keine überstrahlten Lichter und auch kein Türkis im Himmel.
Ja, für sich. Aber damit würde ich nicht weiterkommen ;-). Ich liefer auch mal ein paar Filmchen ab und bekomme ein paar Taler dafür.
Ich habe ihm auch mal unrecht getan mit den Lichtern, wobei ich mich an dieser Stelle auch mal entschuldigen möchte. Nie habe ich irgendwie groß Gedanken dran verschwendet, sichtbar ausgebranntes Material zu untersuchen, bzw zu verbessern. Allerdings ist das bei der GH2 auch nicht nötig, bzw. auch nicht machbar. Nur bei dem Camcorder .
Unterschiedliche Ausgangsparameter eben. Aber wenn der Thread nur so ein bischen aufklärt, ist ja auch o.k. ;-)
WoWu hat geschrieben:Diese kreuz und quer Testerei ist der reinste Dilettantismus.
Ok, 10 bit ist Quatsch. Aber sonst, irgendwie muss man doch rausbekommen, wie der optimale Workflow funktioniert.
Als erstes würde ich mal das Material so bearbeiten, wie es kommt und die Finger von der Floating Point Konvertierung lassen, denn sobald Du ein Projekt auf 32 Bit umstellst fliegen dir auch in jeder andern Bearbeitung erst einmal die Werte an den Poller.
Und das, mit dem Weisspunkt .... ich wette, den kurbelst Du erst mit solchen Tranformationen weg. Da musst Du schon ganz schön schief belichten, um den zu ziehen. Denn wenn die Farbverhältnisse untereinander stimmen, stimmt der auch. Die stimmen natürlich nicht untereinander, sobald du oben anfängst zu stauchen und unten zu spreizen.
Ich wette fast, der Workflow liegt im 8 oder 10 Bit Integer am besten.
Deswegen hat bei mir das Material von Reiner auch keinen Ärger gemacht und ist prompt korrekt gelandet, weil ich solche "Floating-Point-Ausfllüge" gelassen habe.
Und Tiefflieger scheint das auch zu lassen.
WoWu hat geschrieben:Als erstes würde ich mal das Material so bearbeiten, wie es kommt und die Finger von der Floating Point Konvertierung lassen, denn sobald Du ein Projekt auf 32 Bit umstellst fliegen dir auch in jeder andern Bearbeitung erst einmal die Werte an den Poller.
...
Deswegen hat bei mir das Material von Reiner auch keinen Ärger gemacht und ist prompt korrekt gelandet, weil ich solche "Floating-Point-Ausfllüge" gelassen habe.
Aber ich kann dir trotzdem sagen, wie Premiere arbeitet: Das Material landet nativ im NLE. Da wird nichts in 32bit umkonvertiert oder sonst was. ERST wenn man einen Color Effect oder Corrector anwendet, erfolgt dessen Berechnung entweder in YCbCr (die nennen das YUV, wird ja scheinbar gerne getan), aber nicht RGB, oder, wenn vorher schon ein anderer Effekt angewendet wurde (z.B. Blur), dessen Berechnung in 32bit erfolgte, wird auch die Farbbearbeitung in 32bit weitergeführt. Das aber auch nur bei speziellen Einstellungen für die Berechnung/den Export.
After Effects arbeitet natürlich anders, dort kann man seine Bearbeitungstiefe selber auswählen.
Deine Vermutung, das File von Reiner könnte irgendwie durch Floating-Point falsch gemapped sein oder dadurch Übertragungsfehler beinhalten, kann demnach nicht richtig sein.
Die letzten Bilder von Olja sind aus Davinci Resolve. Ich bin mir auch nicht sicher, ob das einfache Importieren schon eine Konvertierung des Files in 10bit verursacht. Genausogut könnte es sein, dass, weil Resolve prinzipiell in 10bit arbeitet, der Waveform Monitor mit dieser Anzeige versehen ist, egal ob das File in 8 oder 10 vorliegt. Aber weiss ich nicht genau.
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.
