domain hat geschrieben:
Ja das funktioniert so bei mir, siehe zweites Bild als ein auf 100% korrigierter Ausschnitt aus dem JVC GZ-HD40 Ausschussclip von oben, wo die Lichter doch ziemlich überzeichnet waren und in der Waveform mit über 100% angezeigt wurden.
Das Thema hat m.E. schon einige Praxisrelevanz. Ich möchte nicht wissen, bei wie vielen Clips ich hätte noch etwas mehr retten können, denn diese Technik wende ich erst seit ca. einem halben Jahr an.
Schöne Ergebnisse! Manch ein Video gewinnt eben tatsächlich dadurch. Zwar nicht viel, aber eben Bildinhalt, der die Bildwirkung positiv beinflusst.
@olja
Was willst du mit x.v. Color?
Ich denke, auch bei dir ist es wie bei den anderen: 0 milliVolt entspricht einem Lumawert von 16 und 700mV dem von 235. Laut Standard. Und so kommt es aus der Kamera. (plus Überschwinger) Damit in deinem NLE nicht alles flau aussieht, mappen sie das auf 0-255. Wenn du es ausgibst, nach 709, wird daraus wieder 16-235, ein Videoplayer auf deinem Computer macht daraus wieder 0-255.
x.v. Color wäre doch nur interessant, wenn die Kamera schon anders aufnehmen würde.
dienstag_01 hat geschrieben:@olja
Was willst du mit x.v. Color?
Ich denke, auch bei dir ist es wie bei den anderen: 0 milliVolt entspricht einem Lumawert von 16 und 700mV dem von 235. Laut Standard. Und so kommt es aus der Kamera. (plus Überschwinger) Damit in deinem NLE nicht alles flau aussieht, mappen sie das auf 0-255. Wenn du es ausgibst, nach 709, wird daraus wieder 16-235, ein Videoplayer auf deinem Computer macht daraus wieder 0-255.
x.v. Color wäre doch nur interessant, wenn die Kamera schon anders aufnehmen würde.
Ich will eigentlich nichts damit. Reine Neugier, wie es im NLE oder Wavefom aussieht, wenn ich in der Cam den Modus schalte. Und wenn ich was umschalte, erwarte ich irgendwie ein anderes Ergebnis. Wozu sollte es denn eigentlich sonst gut sein ? http://de.wikipedia.org/wiki/X.v.Colour
War nur so mal Zwischendurch, da ich gerade bei dem Thema bin ;-)
Das gesamte Thema ist speziell für mich schon immer etwas mit Frust verbunden gewesen, weil der Waveformmonitor ein eigenes Vorschaubild liefert, das mit dem Vorschaubild der Timeline nicht übereinstimmt.
Im Waveform-Monitor wird in Liquid nämlich immer der gesamte Wertebereich angezeigt.
Also konkret: in der Timeline ein Himmel ev. mit Türkisstich, aber im Waveformonitor ein weicheres Bild mit schönem Himmelblau.
Alles zusammen halt ein ziemliches Kuddelmuddel, ein Wirrwarr und zum junge Hunde kriegen :-)
domain hat geschrieben:Das gesamte Thema ist speziell für mich schon immer etwas mit Frust verbunden gewesen, weil der Waveformmonitor ein eigenes Vorschaubild liefert, das mit dem Vorschaubild der Timeline nicht übereinstimmt.
Im Waveform-Monitor wird in Liquid nämlich immer der gesamte Wertebereich angezeigt.
Also konkret: in der Timeline ein Himmel ev. mit Türkisstich, aber im Waveformonitor ein weicheres Bild mit schönem Himmelblau.
Alles zusammen halt ein ziemliches Kuddelmuddel, ein Wirrwarr und zum junge Hunde kriegen :-)
Verstehe ich jetzt nicht so ganz...welchen Sinn hat das Ganze dann ? Ich will doch skimmen und zeitgleich den Waveform betrachten. Die Position des Playheads muß doch identisch mit der Timeline und Waveform sein. Noch besser sogar vertikal, anlog dem Bild. (paßt aber auch bei FCPX nicht soo ganz)
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Verstehe ich auch nicht, aber vielleicht funktioniert das aufpoppende Waveformfenster in Overlay-Technik und ich habe am Grafikkartentreiber zu viel herumgekurbelt, also selber schuld.
Man muss gewisse Sachen positiv sehen, So erkenne ich wenigstens auf Anhieb, wie das Bild aussehen könnte, wenn auch der 100+ Bereich integriert wäre und danach muss ich ihn halt bewusst herunterziehen. Sehr groß sind die Abweichungen zur Timelinevorschau ja nicht.
Domain hat geschrieben:Man muss gewisse Sachen positiv sehen, So erkenne ich wenigstens auf Anhieb, wie das Bild aussehen könnte, wenn auch der 100+ Bereich integriert wäre
Na jetzt wirds Quatsch, mehr als 255 kann dein Monitor sowieso nicht ;)
Ja das ist klar. Nein der Gradationsverlauf ist einfach ein anderer. Aber eigentlich bräuchte ich nur den Waveformonitor alleine, denn sobald er weggeklickt wird, sehe ich den Effekt ohnehin spontan in der Timeline.
Was für ein Theater wegen eines Premiere Bugs hier.
Ich konnte es nicht lassen und habe mir die Premiere CC Testversion installiert, um zu sehen, warum sich hier quasi gestritten wird.
Es wurde ganz am Anfang geschrieben, dass es sich nur um den RGB Kurven Effekt handeln würde und der Luminanzkurveneffekt immer noch so arbeitet wie bei Premiere Pro 6.
Das ist bei mir nicht der Fall. In meinen Tests betrifft es sehr wohl die Luminanzkurve.
Ziehe ich ein MTS-File der Panasonic X929 rein, bei dem die Highlights mal wieder über 100% liegen, weil sie nunmal bis 255 aufzeichnet und lege dort, wie ich es neuerdings nach Reiners tollen Tipp immer handhabe, den Luminanzkurveneffekt drauf, dann schneidet dieser alleine schon beim aktivieren des Effekts alles über 100% ab, und somit sind die ganz hellen Partien für die Rückgewinnung verloren. (Also nix aus türis wird blau).
Bis Premiere Pro 6 passierte beim Aktivieren des Filtern gar nichts, und ich konnte oben den Endpunkt der Kurve anfassen und alles so weit mit der dringend benötigten Stauchung nach unten ziehen, um bei den ausgebrannten Stellen die Zeichnung wieder hereinzuholen und auch das Türkis zu berichtigen.
Das ist jetzt nicht mehr möglich! We kann man (z.B. Wowu) bei Premiere CC dann von Bugbeseitigung reden???
1) Es existiert ein Standard, nach dem Videosignale gehandhabt werden. (REC 709-für 8 oder 10 Bit) Danach werden 8 Bit im Wertebereich von 16-235 übertragen.
2) Es existierte eine nicht standardisierte Übertragungsmethode auf der Basis der FotoCD von Kodak, in dem Videosignale auch in Bereichen ausserhalb des Standards übertragen werden können (1-16 / 235-255) (x.v.Color oder xvYCC)
Das Tool erwartet also ein standardkonformes Videosignal innerhalb der zugelassenen Werte und kein proprietäres Signal.
Es verhält sich als standard-konform.
Nun sagst Du, die Kamera nimmt nicht standard-konform auf.
Das bedeutet, sie arbeitet (demnach immer) im xvYCC Mode, denn irgendwelche "Zwischenmodi" gibt es im Standard nicht.
Besonders hässlich ist das natürlich, weil bei xvYCC schon aufgrund der anderen monochromatischen Primärfarben es bei einer solchen ausbleibenden Tranformation zu Farbverschiebungen im Spektrum kommt.
Das wäre also nicht weiter tragisch, wenn die entsprechende Signalisierung zum Folgegerät funktioniert und ein korrektes Mapping durchgeführt würde.
Sowohl das Signalbit muss dabei von der Kamera gesetzt sein als auch vom NLE verstanden und korrekt interpretiert werden.
Geschieht das nicht, liegt ein Fehler vor.
-entweder in der Kamera oder im NLE-, nicht jedoch im Tool, das ein normgerechtes Videosignal verarbeiten soll.
Nur suchen müsst Ihr den Fehler schon allein.
Sich darüber aufzuregen, dass Adobe sich an den Standard hält, bringt es ja nun auch nicht.
Das leuchtet mir soweit ein, daher mäkelte ich ja auch zu genüge an der SD909-X929 herum.
Ich denke aber nicht, dass Adobe sich im Falle von Premiere CC bewusst an Standards gehalten hat. Es wird ein Fix geben.
Adobe ist sicherlich daran interessiert, alle Kameras unterstützen zu können. Die Panasonic Consumer Camcorderreihe, die seit Jahren einen hohen Stellenwert einnimmt, ist sicherlich nicht einzige, die über dem Standard hinaus aufzeichnet.
Mit der alten Luminanzkurve konnten alle Kameras behandelt werden, mit der neuen nicht mehr.
Warten wir den Fix mal ab.
Und, ich gebe Dir Recht, natürlich will Adobe möglichst viele Kameras unterstützen, wird aber von Standards nicht abweichen.
Es ist ja auch möglich, Kameras ausserhalb des Standards zu unterstützen. Man muss nur finden, woran es liegt, dass die Bereiche im xvYCC Bereich nicht signalaisiert werden, zumal es ja offenbar funktioniert, denn Reiners File habe ich ja korrekt Mappen können, nur eben nicht mit einem Adobe Programm.
Bleibt also festzustellen, warum die Signalisierung mal klappt und mal nicht.
Denn Verfahren für ein korrektes xvYCC Mapping gibt es ja.
Und die Signalisierungsverfahren sind ja auch in HDMI etabliert, daran mangelt es also auch nicht.
Warum also sollte Adobe hier vom Standard abweichen ?
Sinnvoller wäre ein korrektes Mapping.
Warten wir es also ab, ob - und ggf. wie- ein Fix stattfindet.
WoWu hat geschrieben:
Bleibt also festzustellen, warum die Signalisierung mal klappt und mal nicht.
Denn Verfahren für ein korrektes xvYCC Mapping gibt es ja.
Und die Signalisierungsverfahren sind ja auch in HDMI etabliert, daran mangelt es also auch nicht.
Warum also sollte Adobe hier vom Standard abweichen ?
Sinnvoller wäre ein korrektes Mapping.
Warten wir es also ab, ob - und ggf. wie- ein Fix stattfindet.
Die Antwort ist m.E. ganz einfach: die eigentlichen Programmierer führen nur Anweisungen ihrer Vorgesetzten aus, also quasi mit Null Ahnung von der Materie selbst behaftet. Wenn aber selbst die „Anschaffer“ zu wenig von der Materie verstehen, dann kommt eben so ein derzeit immer noch zu beobachtender Murks heraus, dessen Bereinigung offenbar Jahre dauern kann.
Bei der sieben Jahre alten Mumie Liquid wundert es mich nicht, dass sie xvYCC mit dem konventionellen Timeline-Gamma durcheinander mischten, aber bei den neueren Programmen schon sehr.
Da bin ich gar nicht sicher, dass die Kamera das nicht schon hat.
Seitdem HDMI 1.3a im Nov 2006 veröffentlicht wurde, ist das eigentlich jedermann zugänglich.
Es gibt in jedem Datensatz die 'Gamut Boundary Description'. Dort findet jede Hard-und Software die Gamutbeschreibung.
Man müsste eben nur wissen, ob Adobe die ausliest und was da von Seiten Pana reingeschrieben wird:
"0b000 oder 0b010" Das wären die beiden Vaianten, die nach meiner Einschätzung in Frage kämen.
Vielleicht hat ja jemand Gelegenheit, nachzuschauen, dann wüsste man, ob Pana da goofed oder Adobe. Vielleicht sagt Adobe ja auch "wie haben mit HDMI nix am Hut".... ergo, lesen wir die Discriptoren nicht aus.
Das wäre natürlich 'saudumm'.
Ich vermute, irgendwie ist das anders.
Ich hatte eine Sony EX1, Olja eine Canon Legria und Reiner, glaube ich, eine Pana.
Die NLEs, von denen hier Bilder mit Werten oberhalb von 235/100 angezeigt werden, sind Avid, Premiere und FCP.
Das ist doch nicht mal eben son kleiner Flüchtigkeitsfehler.
Erstens werden oft Überschwinger mit Signalinhalt verwechselt und zweitens gibt es nun mal diese festen Regeln.
Es gibt den Standard, es gibt die Gamuts und es gibt die Signalisierungen für die gamuts, ebenso wie definierte Konvertierungen.
Die Firmen können sich nun daran halten, oder auch nicht.
Ich bin der Meinung, die, die sich nicht daran halten, sollten das als BUG ansehen.
Insofern ist Adobe da ja auf dem richtigen Weg. Fehlt offenbar nur noch das Auslesen der Steuerbits. (?)
Und auf das Mischmasch der unterschiedlichen Ergebnisse bei unterschiedlichen Usern und NLEs würde ich erst einmal ein grosses Fragzeichen setzen.
Du siehst doch, was alles wofür gehalten wird ... und mit welchen haarstreubenden Herleitungen.
Dabei liegen die Fakten auf dem Tisch.
Es kann natürlich auch sein, dass es da noch Missverständnisse in den verantwortlichkeiten gibt:
Wenn Pana immer in xvYCC schreibt, es auch signalisiert, der Monitor sich auch umstellt, heisst das dann auch, dass z.B. ein NLE eine Konvertierung vornehmen muss ???
Oder müsste Pana bei nicht xvYCC ein anderes Gamut produzieren ?
Die Verantwortlichkeiten sind nicht so ganz klar, ich könnte mir aber ebenso gut Letzteres vorstellen.
Das beinahe schon etwas Tragische an der ganzen Angelegenheit ist ja, dass wir bisher immer glaubten, dass die Türkisverfärbungen im Himmel ein typischer Farbstich speziell der Panas wäre.
Das geht ja nun schon über die Jahre, ohne dass man die eigentliche Ursache bisher erkannte und die ist ganz anders geartet als man dachte.
Div. Erkenntnisse kamen ja erst in den letzten Monaten auf, aber wieviele User haben sich über „Farbstiche“ schon bisher gekrämpft und sie auch in ihre finalen Videos übernommen?
Dabei wäre aus meiner Sicht die Lösung schon seit Jahren ziemlich einfach gewesen: man gehe einfach davon aus, dass die moderneren Kameras alle Superweiß codieren können.
Wenn eine Altmodische dann nur bis 235 codieren kann, dann sieht das Bild im NLE in den Lichtern halt etwas matt Grau aus, ist auch keine Tragödie, der Unterschied ist minimal.
Wenn irgendjemand aber seine Superweißvideos TV-konform rausrendern wollte, dann kann es doch bitte für kein NLE ein Problem sein, die 255-Werte in den eingeengten 235-Raum umzumappen.
Das liegt eigentlich nur daran, dass solche Probleme in Foren besprochen werden, in denen sich die Meisten um keinen Standard kehren, geschweige denn, sie kennen.
Eine Problemherleitung ist eigentlich ganz trivial, wenn man die Rahmenbedingungen kennt und nicht gleich jeden Spike für ein Nutzsignal hält.
Das ist, wie in der Schule ... wer das Ein-mal-Eins kennt, kann auch rechnen. Die andern können nur bezahlen, was auf der Kasse steht.
WoWu hat geschrieben:
Ich bin der Meinung, die, die sich nicht daran halten, sollten das als BUG ansehen.
Bisher wurde hier in diesem Zusammenhang kein einziges NLE genannt und vorgestellt, das das anders machen würde.
Die hier bisher vorgestellten funktionieren alle gleich.
Aber kommt ja vielleicht noch.
motiongroup hat geschrieben:Das kannst du mit deiner hd40 ebenso nachstellen wie der HD 3 und der HD 7 von jvc das sich per Menü ein und aus schalten lässt..
Mach mal den Versuch Peter, mal mit mal ohne.. Danach staunen was die alte Software noch so drauf hat.. ..
Die Geschichte hat in dem Fall drei Namen bei pana.. Deep color, xvColorsystem und digital Cinema color.. von 0-255....
Ja so einen Cinemamode hat die Panareihe, und in der Beschreibung wir auch der größere Farbraum erwähnt, trotzdem erzeugt die Kamera auch mit ausgeschaltetem Cinema Color Mode Helligkeitswerte weit über 100% und das sind keine Spikes.
Ausgefressene Wolken oder weiße T-Shirts lassen sich mit ihrer ganzen Zeichnung vollständig restaurieren".
Vielleicht hat ja auch Panasonic seit Jahren einen Bug in ihren Kameras und der erweiterte Farbraum lässt sich gar nicht abschalten?
WoWu hat geschrieben:Da bin ich gar nicht sicher, dass die Kamera das nicht schon hat.
Seitdem HDMI 1.3a im Nov 2006 veröffentlicht wurde, ist das eigentlich jedermann zugänglich.
Es gibt in jedem Datensatz die 'Gamut Boundary Description'. Dort findet jede Hard-und Software die Gamutbeschreibung.
Man müsste eben nur wissen, ob Adobe die ausliest und was da von Seiten Pana reingeschrieben wird:
"0b000 oder 0b010" Das wären die beiden Vaianten, die nach meiner Einschätzung in Frage kämen.
Vielleicht hat ja jemand Gelegenheit, nachzuschauen, dann wüsste man, ob Pana da goofed oder Adobe. Vielleicht sagt Adobe ja auch "wie haben mit HDMI nix am Hut".... ergo, lesen wir die Discriptoren nicht aus.
Das wäre natürlich 'saudumm'.
Kann man dadurch feststellen, indem man die Signalisierung ausliest, sofern die Kamera zwei unterschiedliche Modi zulässt.
Man muss einfach nicht weiter rumspekulieren.
Das hat, wie domain schon sagte,. über Jahre keinen weiter gebracht.
Es gibt harte Fakten, an denen man das aufklären kann.
Man muss in den Datenstrom reinschaun.
Bubble könnte das vielleicht, weil man ein Entwicklungstool dafür braucht.
Du köntest mal ausprobieren, was sich in den 2 Modi denn bei HDMI tut, ob es da Unterschiede gibt, weil man mit hoher Wahrscheinlichkeit annehmen kann, dass die Fernseher die Werte korrekt auslesen.
Neben den hier schon genannten HD-Cams kann ich auch noch eine SD DV PAL stellen, meine alte Pana NVGS250. Auch sie liefert die Signale oberhalb "100".
Das kannst Du gern machen, mich interessiert in diesem Zusammenhang aber erst einmal eine moderne Kamera, von der man ausgehen kann, dass sie sich in einem technisch aktuellen Zustand befindet.
Und kein Konvolut an Erkenntnissen, die man nach Belieben einordnen kann.
Das war das Manko der ganzen Jahre.
Nun, es wurde aber auch die ganzen Jahre nicht anders gelöst, als es in den NLEs gelöst ist.
Das Spannende ist für uns nun nur, dass es da einen Bereich gibt, der für die Bearbeitung der Videodaten am PC bedeutsam ist und unser Augenmerk verlangt.
Selbst dann, wenn es ein "Bug" wäre, der sich festgefressen hat in zahllosen NLEs über Jahre hinweg, in unterschiedlichen Cams oder sonstwo (was ich alles kaum glauben kann - it is like it is - works as designed), sollte man die Augen davor nicht verschliessen. Es geht um praxisrelevanz. Und in der Praxis treffen solche Cams mit solchen NLEs zusammen. Haufenweise. Täglich.
Das ist, wie mit dem Gammashift bei Apple, der hat sich auch 20 Jahre gehalten und jeder musste nachkurbeln, weil Apple noch das Gamma ihrer Laserdrucker unterstützt hat.
Meinst Du das in etwa ?
Das ist doch Quatsch, was Du da erzählst, dass es eine Lösung sei, hinterher zu kurbeln, sich den ganzen Farbverlauf zu zerquetschen und sich jede Menge Artefakte einzuhandeln, nur weil Dir nichts besseres als ein schlechter Workaround einfällt.
Was hast Du dagegen, einmal die Ursache zu finden und zu benennen ?
Aber- keiner hindert Dich daran, weiter so zu arbeiten. So ist das ja nicht.
Ich muss mich hier auch nochmal einklinken.
Bei der Bearbeitung von völlig überbelichteten Files (Austausch - Avid-After Effects, DNxHD) ist mir schon mal passiert, dass es zu reproduzierbaren Fehlern in Form von farbigen Klötzchen im Bild gekommen ist.
Ich hab die nur verhindern können, wenn ich den bist 255 überbelichteten Bereich schon vor dem Austausch runtergezogen habe.
Hier im Thread stand was von Lumawerten bis 240. Ist das korrekt? Sollte dort die Grenze sein? Das Material war NTSC (wie auch die Waveforms hier von mir), natürlich HD.
@Wowu
Nein, ich meine:
Alle NLEs (nicht nur eins), die bisher hier vorgestellt wurden, arbeiten gleich. Richtig?
Viele Cams (nicht nur die Panas und nicht nur HD) zeigen in diesen NLEs Werte über 100. Richtig?
Es handelt sich dabei weder um Noname-Produkte fragwürdiger Herkunft, noch um die Spielzeugabteilung.
Jedoch: Sie arbeiten eben allesamt nicht so, wie Du es erklärst.
Ich habe nichts dagegen, die Ursachen zu finden. Ich denke aber, das ist geschehen.
Beste Grüße,
Reiner
PS zum Thema "Quatsch" ;)
Unabhängig vom Problem: Eine Lösung ist doch dann gut, wenn sie zum Erfolg führt.
Zu diesem speziellen "Problem": Die Hersteller der NLEs bieten unterschiedliche Werkzeuge an, um diesen Bereich manipulieren zu können wie Clipper oder Curves.
Was bietest Du?
Alle NLEs (nicht nur eins), die bisher hier vorgestellt wurden, arbeiten gleich. Richtig?
Nein
zeigen in diesen NLEs Werte über 100. Richtig?
Transienten: Ja
Videomaterial: Nein
Sie arbeiten eben allesamt nicht so, wie Du es erklärst.
Nicht ich erkläre das, sondern die Norm, nach der ALLE Videorecorder arbeiten, nach der z.B. HDMI arbeitet, alle Broadcaster und alle TV Geräte: SMPTE 240M / 260
Ich zeige nur auf, was in dieser Norm steht.
Und jeder Hersteller, der sich nicht sofort mit -non-konformität- aus dem Markt katapultieren will, wird sich an diesen Standard halten.
Nur einer bezweifelt das ... Du ... Richtig ?
Ich denke aber, das ist geschehen.
Du hast einen Workaround, deine türkisfarbenen Bilder einzufärben, aber nicht die Lösung des Problems.
Wenn Du an der Stelle das Denken einstellen willst, kannst Du Dich gern auf diesen Workaround zurückziehen.
Es hindert Dich doch keiner.
@dienstag_01
Jau, Chroma geht bis 240
@ Reiner
Nun Fang doch nicht an den begriff "Lösung" neu zu definieren, ich glaube, jeder kann sich den begriff schon allein definieren.
Für Dich ist Lösung eben das, was für Andere Workaround ist ... ist ja ok.
WoWu hat geschrieben:
Und jeder Hersteller, der sich nicht sofort mit -non-konformität- aus dem Markt katapultieren will, wird sich an diesen Standard halten.
Nur einer bezweifelt das ... Du ... Richtig ?
Nö! ;) Ganz im Gegenteil! Ist ja meine Rede ...
Du hast sehr schön den Grund beschrieben, warum es in den NLEs genau so implementiert ist, wie es ist. Wären diese Hersteller - gemäß Deiner Aussage! - nicht alle längst weg vom Fenster, wenn das ein Dauer-Bug wäre?
An derTatsache, dass es die Hersteller so implentieren - sowohl die der Cams, wie auch die der NLEs! - kommt man eben nicht vorbei.
Nur einer weiß es eben besser als die zahllosen Entwickler und Entwicklergenerationen bei den Herstellern ... Du ... Richtig? ;)
Kann ja sein - ist aber nicht praxisrelevant. ;)
Ich habe Dir den Tipp schon öfter gegeben: Setzt Dich doch mal mit deren Labore zusammen. Womöglich klärt sich das ganz einfach auf. Womöglich werden sie Dir dankbar sein. Andersrum hätten sie längst einen Clipper vor den Importer der NLEs oder in die Cams geklebt, wenn das so sein müsste wie Du schreibst. Nichts leichter als das.
Ich würde mich nun nicht mehr so gern an den Diskussionen der Spekulationen beteiligen und mit denen, die Interesse an einer Lösung haben, gern dem Kern widmen.
Ich kann mich noch an die Zeit erinnern als diese eine Thematik der XvColorsysteme bei den jvc eingeführt wurden und Vegas 8 glaube ich mit der Unterstützung dieses Systems angefangen hatte..
Ich bin mir nicht mehr ganz sicher aber die Software konnte angewiesen werden das Projekt zur Gänze als xvColor anzusehen.. Ich bin mir nicht 100% sicher das ein Automatismus besonders beim Mischbetrieb mit unterschiedlichen Materialien zuverlässig wäre ..
Marco oder Wolfgang kann da sicher genaueres dazu sagen..
Ich habe eine solche jvc und auch eine pana v 707 da und werd's im laufe des Tages testen wenn gewünscht... Eines weis ich schon jetzt nachgewiesen in einigen Projekten, die 707 fährt von 0-255.... Nachgewiesen in fcpx und davinci Ressolve.. Und die prores bleiben im selben Bereich...
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.
