Canon 5D MarkII mit eingeschränktem Dynamikumfang? von rudi - 20 Jan 2009 10:51:00
Seit ein paar Tagen erhitzen sich die Gemüter im Netz darüber, dass die Clips der Canon 5D MarkII sehr schnell zum Clipping in den Lichtern und Schatten neigen. Wir hatten es schon vermutet, aber im gelinkten Blog wird nun bewiesen, dass es sich dabei ein weiteres mal um die Problematik des Umrechnens von YUV nach RGB handelt. Hierbei werden die YUV-Werte 16...235 auf die RGB-Skala 0...255 abgebildet. YUV-Werte unter 16 und über 235 fallen dabei unter den Tisch. Holger Scheel hatte dies seinerzeit schon bei DV-Codecs untersucht und beschrieben und wie es aussieht, gibt es die selben Probleme jetzt auch bei den Clips der Canon 5D MarkII. Für alle die sich jetzt fragen, was das heißt, in Kurzform: Die Canon Clips haben mehr Informationen in den Lichtern und Schatten, als bei den meisten Codecs beim Dekodieren dargestellt werden.
Also geht jetzt mal wieder die Suche nach einem Codec los, der YUV nativ an das Schnittprogramm weiterreicht, bzw. beim Umrechnen nach RGB den Wertebereich nicht künstlich aufbläst. PC-Anwender dürften aufgrund der breiten Auswahl hier schnell fündig werden, Apple User, die ja gerne von solchen technischen Feinheiten nichts wissen wollen, sollten dagegen mal näher hinschauen, ob z.B bei der Umwandlung nach ProRes so was irgendwo einstellbar ist. Profi-Colorist Stu Mashwitz scheint auf jeden Fall noch nicht fündig geworden zu sein.
Was wohl gemeint ist, dass der entspannte Workflow mit ProRes viele FCPler allzu sorglos macht. Auf die Rettung der Werte über 235 wird hier ohnehin nie hingewiesen, da war "Wolfangs" Videoforum uns voraus. Aber Maschwitz hat´s ja gefunden, mit Color, was ja zum FCStudio dazu gehört.
Na und? Im Fernsehen wird ja auch alles wiederholt ...
Die Daten der Cam kommen in YUV 4:2:0 daher und nicht in RGB. Irgendwie verstehe ich nicht ganz wo das Problem liegen soll? Für meine Begriffe eher in den Settings der Cam, denn man muss den Kontrast auf -4 stellen, nicht auf 0 um ein neutrales Ergebnis zu bekommen.
MB
Ich will lieber mit Weisen irren, als mit Unwissenden recht zu behalten. (Cicero)
MarcBallhaus hat geschrieben:Irgendwie verstehe ich nicht ganz wo das Problem liegen soll?
Es wird garnicht als Problem wahrgenommen, und es betrifft alles Video, nicht nur das der Mark II. Maschwitz, der Schöpfer der MagicBullet Suite und Chef der Effektfirma Orphanage (Sin City) ist ein Fanatiker, aber wie du in dem Link an dem Vorher-Nachher Bild siehst, lohnt es sich, sich mit der Materie zu befassen.
YUV zu RGB bedeutet die Skalierung der Werte (YUV) 16 - 235, wobei die originale Dynamikinformation unter den Tisch fällt. Zu vermeiden in FCP, wie Maschwitz schreibt, nur im Apple 10-bit unkomprimiert Codec und der Rendereinstellung Beim Rendern von Filmen immer höchste Qualität verwenden -, im Original Render in high precision YUV, was freilich nur geht, wenn es ein YUV-Codec ist.
Na und? Im Fernsehen wird ja auch alles wiederholt ...
Zuletzt geändert von Axel am Di 20 Jan, 2009 12:32, insgesamt 1-mal geändert.
Das Problem liegt in der Decodierung. Da trifft nach meiner Erfahrung genau das, was Rudi schreibt. Auf Windows Schnittsystemen sind Codecs, die nach der Decodierung das Signal zwangsläufig clippen, eher selten. Fast alle mappen korrekt oder lassen sich optional umstellen. Auf meinem Mac war das bisher weniger selbstverständlich. Vielleicht hatte ich auch nur zu oft Pech (beim Codecangebot) oder ich brauch noch 'ne Weile.
deti hat geschrieben:In der Anleitung zur Kamera steht doch ganz klar drin:
Recording and Image Quality
...
The movie will be recorded in the sRGB-equivalent color space optimized for movies.
...
Damit ist doch auch implizit festgelegt, dass der volle 8-Bit Raum ausgenutzt wird, oder?
Ich versteh die ganze Aufregung nicht von Leuten, die es eigentlich besser wissen müssten.
Deti
Was ist denn daran „ganz klar“? Das besagt nur, welche Transferfunktion benutzt wird (Primärvalenzen, „Gamma“, Weißpunkt), aber nichts über die Art der Codierung (YCbCr vs. RGB, fullscale vs. videoscale)
MacPro hat geschrieben:
Was ist denn daran „ganz klar“? Das besagt nur, welche Transferfunktion benutzt wird (Primärvalenzen, „Gamma“, Weißpunkt), aber nichts über die Art der Codierung (YCbCr vs. RGB, fullscale vs. videoscale)
Also wenn ich das richtig verstanden habe, legt nur ITU-R Recommendation BT.709 fest, dass die sog. "studio-swing levels" verwendet werden. sRGB erlaubt von sich aus 8-bit und kennt diese Vorschrift nicht. Hätte Canon geschrieben, dass die Kamera sich an ITU-R BT.709 hält, dann hätte ich mich bei Werten jenseits des Intervals zwischen 16 und 235 auch stark gewundert.
Das eigentliche Problem ist ja scheinbar "nur" Quicktime, bzw. die Art, wie bis heute in Quicktime H.264 decodiert wird. Genau das in der Newsmeldung beschriebene Verhalten mit Quicktime H.264-Files besteht nämlich schon einigen Jahren.
QU schneidet da schon zu Recht ab, denn in den Wertebereichen hat ausser xvYCC vom Farbraum Y'CbCr nichts verloren.
Ausserdem unterscheidet sich Y'CbCr von RGB auch noch dadurch, dass er nicht von 16-135 aufgebaut wird, also ähnlich RGB, sondern von der Mitte zu den Seiten. Dadurch werden Werte unter 16 statt Schwarz dunkelgrün und alles oberhalb von 235 "schweinchen rosa". Insofern hat Apple da schon Recht.
Wer die Werte ausserhalb 16-235 benutzen will, soll xvYCC machen.
Na ja, Fakten bleiben eben Fakten, auch wenn man sie ignoriert.
Auch der o.g. Artikel spricht eine deutliche Sprache ... nur dass es 2002 noch kein xvYCC gab. ... Heute aber.
Ja. Fakt ist, dass im Prinzip eigentlich "nur" Quicktime daran gehindert werden muss, das Video in die Hände zu bekommen. Leichter gesagt als getan, aber es geht beispielsweise per Frameserving. Dann gibt's keine Probleme mehr, bzw. wenn noch welche übrig bleiben sollten, lassen sie sich leicht beheben. Da gibt's auch kein Dunkelgrün statt Schwarz oder Rosa statt Weiß.
WoWu hat geschrieben:
Ausserdem unterscheidet sich Y'CbCr von RGB auch noch dadurch, dass er nicht von 16-135 aufgebaut wird, also ähnlich RGB, sondern von der Mitte zu den Seiten
Das gilt aber nur für Cb und Cr!
Hier geht es aber um das Superwhite und superblack, und Y' wird ganz normal von 0 bis 1 (bzw 0-255)aufgebaut.
WoWu hat geschrieben:Dadurch werden Werte unter 16 statt Schwarz dunkelgrün und alles oberhalb von 235 "schweinchen rosa". Insofern hat Apple da schon Recht.
Wer die Werte ausserhalb 16-235 benutzen will, soll xvYCC machen.
Es geht hier nicht um erweiterte Farben, die moniert werden, sondern um die offensichtliche Unmöglichkeit, das komplette Lumasignal auslesen zu können (was QuickTime bei allen anderen Y'CbCr Codecs jedoch ermöglicht (!), sofern die Applikation die nativen (Y'CbCr) Daten von QT anfordert und QT nicht die Umrechnung zu RGB überlässt).
Offensichtlich aber tritt h264 in der QuickTime Architektur aber nach aussen als RGB Codec in Erscheinung, und genau das ist das Problem um das es geht.
Die haben den Grund dahinter aber auch nicht wirklich verstanden.
... dann hab´ich das allerdings auch nicht verstanden.
Es geht hier schlichtweg darum, dass eine Kamera Signale produziert, die, obwohl sie im Y'CbCr Farbraum arbeitet, diesen nicht einhält !
Jede Kamera könnte bei der Wandlung von R'G'B nach Y'CbCr theoretisch den gesamten Bereich nutzen.
Macht eine gute Kamera aber nicht, weil der Wertebereich im Farbraum fest definiert ist.
Damit stimmt dann auch der Farbbalken mit den nachfolgenden Werten wieder überein.
Stimmen Farbbalken und Kamerasignal nicht überein, ist sie entweder schlecht, oder defekt.
Die Farbwerte in solchen Bereichen werden hinlänglich als "illegale Farben" bezeichnet und sofern NLEs sie übertragen, sollten sie gekennzeichnet sein oder man sollte sie kappen können, denn spätestens in Monitoren, die auch xvYCC übertragen, werden diese Signale ohnehin nicht sichtbar sein, wenn kein xvYCC vorliegt. Auch TV-Sendewege werden solche Signale kappen.
Insofern ist es richtig und gewollt, dass dies in NLEs passiert.
Wie schon angesprochen ist der Raum, in dem diese Werte übertragen werden, einem andern Farbraum vorbehalten, der dann auch mehr Farbwerte aufweist, denn es ist ein Unterschied, ob ich einen Farbbereich nur spreize (wie in diesem Fall), oder ob ich tatsächlich mehr Farbwerte darin transportiere.
Wo also ist das Problem, wenn die Werte entweder von der Kamera ... oder, wenn die es nicht kann, vom NLE der vorgeschriebene Farbraum eingehalten wird ?
Was macht es für einen Sinn, Werte zu übertragen, die weder mit dem Farbbalken (und damit mit dem korrekten Farbraum) noch mit einer kontinuierlichen Verarbeitungsweg fehlerfrei zu übertragen sind und dazu noch in Bereichen liegen, die bereits von einem andern Farbraum belegt sind ?
Nur weil sie auf dem eigenen Monitor, der ggf. nicht korrekt begrenzt, einwenig bunter und gesättigter aussehen ?
Also dann hab´ich, wie die Kollegen in dem Artikel auch irgend etwas nicht verstanden.
Ich habe eben ein paar 5D H.264-Clips bearbeitet und verglichen.
Lasse ich für das Decoding den Weg über Quicktime zu, werden an vielen Stellen Schwarz (bei RGB 0) und Weiß (bei RGB 255) geclippt.
Gehe ich aber einen Weg per AVISynth und VDubMode und exportiere das Signal dann zu einem Format, in dem jedes System den vollen Werteumfang problemlos verwalten kann (in diesem Fall war es Newtek HQ 422), dann zeigen die Clips keinerlei Clipping mehr, bzw. an den Stellen, wo vorher die Information durch Clipping einfach weggeschnitten war, ist nun auch im Videobild wieder Information erkennbar.
Zwar sind die wenigen 5D-Files, die ich habe, nicht wirklich gut für solche Demonstrationszwecke geeignet. Die Informations"wiederherstellung" ist dort leichter in der Waveformdarstellung als im Realbild erkennbar. Aber dennoch zeigt es, dass bei einem Quicktime-Decoding schlicht vorhandene Informationen weggeschnitten werden, auf anderem Decoding-Weg aber erhalten bleiben.
Was dabei nach welcher Norm in Hinblick auf spezielle Anwendungen richtig oder falsch sein mag, ist eine Sache. Aber Tatsache ist, dass es nicht die Kamera ist, die die Informationen unterschlägt, dass diese Informationen aber durchaus reproduzierbar bleiben, wenn Quicktime das Signal nicht zu fassen kriegt und dass selbst die Werte in den Grenzbereichen für vielerlei Anwendungen verwertbar und durchaus auch wertvoll sind. Wie oben schon geschrieben: Farbverfälschungen im Bereich 0-15 und 236-255 gibt es dabei nicht.
Es ist meiner Meinung nach, selbst in Hinblick auf eine reine Broadcast-Nutzung, auch nicht gut zu sagen, Quicktime mache das schon richtig so, da ja die grenzwertigen Bereiche in einem (ich nenne es jetzt mal so) "Broadcast-Normsignal" eh nichts verloren haben.
Letzteres mag zwar korrekt sein. Aber deswegen lasse ich mir doch noch lange nicht von einem Decoder einfach so das Signal mitsamt den darin enthaltenen Informationen wegschneiden!
Der elegantere und meines Erachtens professionellere Weg zum "Broadcast-Signal" ist doch immer noch der, der mir zunächst das Originalsignal mit all seinen Facetten so erhält, wie es aufgezeichnet wurde. Ich selbst entscheide dann z.B. mittels einer gezielten Farbkorrektur, wie die Grenzwerte in den Normbereich übertragen werden, denn das geht dann - und nur dann - auch ohne radikales Clipping.
Selbst wenn ich am Ende über ein komplettes Projekt einfach einen Broadcast-Filter drüberfegen lasse, der mir aber schwarze und weiße Grenzwerte mittels einer Kurve in den Bereich über RGB 15 und unter 236 rechnet, bin ich qualitativ besser bedient als mit einem clippenden Decoding.
Solange ich die Wahl habe, lasse ich mir auf keinen Fall von einem Decoder schon im ersten Schritt die Dynamik des Signals derart beschneiden. Dynamik ist ein wertvolles Gut und hier geht es um 13 Prozent davon.
Dabei sollte man sich immer vor Augen halten, dass die Welt jenseits des traditionellen Broadcastings riesig ist. Deshalb sollte auch eine Kamera nicht als gut oder schlecht bezeichnet werden, nur weil sie das so oder so handhabt. Die Frage dabei ist eher, für welche Einsatzzwecke eine bestimmte Kamera denn überhaupt entwickelt wurde.
Ist doch gut, dass mir selbst günstige Kameras so viel Dynamik überlassen und ich selbst entscheiden kann, ob das Endprodukt einer Broadcast-Norm entsprechen kann oder es optimiert für andere Anwendungen sein wird.
Marco
Zuletzt geändert von Marco am Di 20 Jan, 2009 21:49, insgesamt 2-mal geändert.
Also nochmal langsam:
Von Farben ist nirgends die Rede. es geht einzig und alleine um das Lumasignal.
Richtig ist, dass an der Zuordnung Wert 16 Y' = Wert 0 RGB sowie Wert 235 Y' = Wert 255 RGB nicht zu rütteln ist. Alles darüber ist per se schonmal illegal, da ausserhalb des Darstellbaren.
Nun ist es aber Fakt, dass (viele) Kameras auch Lumasignale größer 235 aufzeichnen und auf diese dann in der Nachbearbeitung Zugriff zu haben, ist ein nicht zu unterschätzender Vorteil, wenn man noch etwas Zeichnung aus einem übersstrahltem Bereich herauskitzeln möchte.
Fakt ist, die Canon zeichnet Superweiß auf. Streiten kann man darüber, ob das klug oder unklug gewesen ist von Canon, ob sie besser nicht einfach das Bildsignal in der Kamera schon auf 16-235 gemappt hätten sollen, statt es auf den Bereich des Superwhite auszudehnen. Jedoch hätte das einen Verlust an Tonwerten zu Folge. ITU REC 709 verbietet das Ausnutzen des Headrooms für Videodaten auch nicht, im Gegenteil: Lediglich Level 0 und 255 sind reserviert worden für "Timing references". Der Rest ist für "video data" durchaus vorgesehen.
Dass dieser Headroom per se nicht angezeigt wird, ist schon klar und korrekt, es geht also nur darum, diese Tonwertreserve in die Nachbearbeitung hineinretten zu können.
Ich sehe das Argument durchaus und bei einer Ausbelichtung ggf auch nicht die Schwierigkeiten, wobei dann jede standard Umrechnung zu falschen Ergebnissen führt, weil sie nicht das Signal bewertet, sondern vom vorgegebenen Farbraum ausgehen. Also wird das zu einer falschen Spreizung bei der Überführung nach R'GB führen.
Ich weiss ja nun nicht, ob die Canon einen Farbbalken abgibt, aber der sollte (und ich denke, da haben wir Einvernehmen), immer die Referenz sein.
Hat sie einen FB und was sagt der im Verhältnis zum Signal ?
Mir stellt sich nur die Frage, wenn jemand den Bereich nutzen möchte, warum dann nicht gleich in xvYCC, denn das wäre eine solches Signal, und dann sogar definiert und korrekt umzurechnen.
Was also spricht für so ein (pseudo) Y'CbCr ?
WoWu hat geschrieben:
Mir stellt sich nur die Frage, wenn jemand den Bereich nutzen möchte, warum dann nicht gleich in xvYCC, denn das wäre eine solches Signal, und dann sogar definiert und korrekt umzurechnen.
Was also spricht für so ein (pseudo) Y'CbCr ?
Ne Menge:
1. xvYCC ist schlichtweg NICHT in der Canon implementiert!
2. Welches Programm auf dem Mac kann mit xvYCC umgehen??
3. xvYCC löst das Problem nicht, bzw. ist die Antwort auf eine Frage, die nicht gestellt wurde: xvYCC erweitert den Farbraum, d.h. die Tonwertabstände bleiben im Vergleich zum herkömmlichen Y'CbCr gleich. xvYCC erweitert nicht das Luma. Viel häufiger als extremst gesättigte Farben (die also ausserhalb von sRGB liegen) hat man es eben mit einem übergroßem Szenenkontrast zu tun, der irgendwie in die wenigen zur Verfügung stehenden Tonwertstufen hineingezwängt werden muss. Es gibt genügend Webseiten, die eindrucksvoll demonstrieren, wie selten Farben, die von sRGB nicht abgedeckt werden, in natürlichen Szenen vorkommen.
Es spricht dafür, dass es sich vollkommen problemlos handhaben lässt. Die Canon 5D macht es im Prinzip ja nicht anders als fast alle DV, HDV und AVCHD-Kameras (dort aber womöglich doch nur erweitert nach oben hin, also rauf bis RGB 254/255).
Welches Schnittsystem kann denn mit xvYCC umgehen? Jedes kann im Prinzip mit RGB 0-255 umgehen (solange sich nicht der Decoder stur stellt und zu früh das Skalpell ansetzt).
Aber ich denke, mit xvYCC hat das ohnehin nicht direkt zu tun.
Das Besondere an diesem aktuellen Fall ist eigentlich nur, dass die Aufzeichnung des Signals dabei im Quicktime-Container geschieht und damit die Flexibilität beim Decoding erstmal eingeschränkt wird. Würde dort nicht der Quicktime-Container benutzt werden, hätte sich auch niemand an den Signalen gestört, denn damit ließe sich dann leichter umgehen. Mit all dem meine ich in erster Linie H.264. Wie problematisch oder auch unproblematisch das mit anderen Codecs ist, die in Quicktime eingebettet sind und über Quicktime decodiert werden, weiß ich nicht. Also den Fall der H.264-Clips der Canon 5D sollte man nicht unbedingt auf andere Formate übertragen.
Klar, nicht jeder kann dabei die Normen einfach ignorieren. Je Flexibler eine Bearbeitung bleibt, desto mehr müssen dabei eben die Ziele und die optimalen Wege dafür im Auge behalten werden.
Mir ist noch kein Problem dabei widerfahren, im Schnittsystem mit einem RGB-Signal von 0-255 zu hantieren, selbst wenn es dann am Ende zu sendegerechtem 16-235 komprimiert wurde, um letztlich als YUV-Signal aus der Betacart geschaufelt zu werden.
Marco
Oops, diesmal war MacPro schneller ...
Zuletzt geändert von Marco am Di 20 Jan, 2009 22:25, insgesamt 2-mal geändert.
Der Einwand, dass viele Ausgabegeräte und -Codecs nicht den vollen Luma-Bereich darstellen, steht auf einem ganz anderen Blatt. Der Dynamikbereich bei elektronischer Signalverarbeitung ist begrenzt, und bei der Aufnahme muss einerseits entschieden werden, welcher Bereich besonders gute Zeichnung haben soll (i.d.R. ja Haut) und andererseits muss Clipping vermieden werden. Wie meine Vorposter sagen, geht es hier vor allem darum, auch in der Nachbearbeitung noch Spielraum zu haben, und ich kann nicht sehen, warum das für Fernsehschaffende nicht relevant sein sollte.
Maschwitz, andererseits, führt einen gewaltigen Aufwand, um verschenkte oder begrenzte Signale in digitaler Kompression zu rekonstruieren und während des gesamten Bearbeitungsprozesses zu bewahren. Das Ziel ist freilich hier das Fazen. Kinofilme mit einer DV-Kamera (28 Days Later mit der Canon XL-1 etwa) dürfen kein Bit mehr verschenken, sind aber dann präsentabel.
Professionelle Filmleute, wie Maschwitz leicht verächtlich ausführt, gehen den umgekehrten Weg: Aufzeichnung mit analogem Film in teilweise 8k Auflösung, die flugs zu einem digitalen Intermediate unter 2k komprimiert werden. Die Farbkorrektur erfolgt mit Hardware, die sechsstellige Summen kostet, aber mit Echtzeit-Algorithmen arbeitet, die Farb- und Helligkeitsinformationen mit ähnlichen Ergebnissen beschneidet und verfälscht wie dies Consumerkameras tun. Treffpunkt Kino.
Na und? Im Fernsehen wird ja auch alles wiederholt ...
Kurze Zwischenfrage:
Hat die Kamera einen FB Generator und was sagt das Signal im Verhältnis zum generierten Bildsignal ?
xvYCC löst das Problem nicht, bzw. ist die Antwort auf eine Frage, die nicht gestellt wurde: xvYCC erweitert den Farbraum, d.h. die Tonwertabstände bleiben im Vergleich zum herkömmlichen Y'CbCr gleich. xvYCC erweitert nicht das Luma.
Das ist falsch, scjliesslich haben wir es mit einem Farbraum zu tun.
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.
(Jeweils abzüglich der sync-Werte). Die Definitionen können in 8 oder 10 Bit Quantisierung definiert werden.
Damit würde xvYCC dem Problem sehr wohl gerecht und vor Allem wären die Rückrechnungen nach RGB wieder reproduzierbar und nicht so eine Wundertüte, die keine Formel erfassen kann, denn man macht sein Projekt ja sicher nicht für das NLE. Spätestens, wenn es auf ein Tape geht , wird es oben und unten wieder geclipped, also was hat es gebracht ?
Bis auf den tollen Eindruck beim Arbeiten.
Etwas anderes wird es sein, wenn ich mit meinem Raid zur Ausbelichtung gehe. Da sehe ich auch einen Vorteil, mal von den Rechenfehlern beim Übergang zu R'G'B' mal abgesehen.
Ich weiß nicht, ob die Canon das bietet. Aber ich würde mich auf einen FB-Generator einer Konsumerkameras niemals verlassen wollen. Wer garantiert denn, dass ausgerechnet der normgerecht ist? Ich habe dort schon genügend Fantasiebalken gesehen ...
Davon ableitend aber die reine Interessensfrage: Welchen Aufschluss könnte in diesem speziellen Fall ein Normfarbbalken geben? Dass nicht die Kamera bezüglich, Blende/Gain/Belichtung/Gamma/Schwarz-/Weißwert falsch bedient wurde?
Die Wirkungsweise des Codecs ist dabei ja außen vor.
Oder geht es einfach darum, eine glasklare Aussage treffen zu können, dass Normweiß, Normschwarz und alle Normfarben eines Farbbalkens in diesem Fall in den NLEs zu RGB XYZ gemapped werden?
"Damit würde xvYCC dem Problem sehr wohl gerecht"
Was nichts nützt, solange kein NLE damit umgehen kann.
"Spätestens, wenn es auf ein Tape geht , wird es oben und unten wieder geclipped, also was hat es gebracht ?"
Oben wird dann noch lange nicht unbedingt geclippt. "Tape" ist dabei auch nicht der Faktor. Auch unten nur dann, wenn dem in der Nachbearbeitung - wie oben beschrieben - nicht Rechnung getragen wurde und es zudem auf analogen Wegen weiterschreitet.
Ebenfalls oben schon mehrfach erwähnt: es geht darum, dass sich der Wertebereich nicht nur ansehen, sondern auch nutzen und sogar in ein normgerechtes Broadcast-Signal reinrechnen lässt. Genau so wie beispielsweise das Blackstretch einer Kamera wirkt. Es bringt also selbst für diesen selbststranguliernden Bereich Potential, das nur genutzt werden will.
Am wenigsten Nutzen hat auf jeden Fall ein clippendes Decoding. Das ist einfach nur eine extreme Holzhammer-Methode. Eigentlich fast schon ein GAU im Umgang mit Codecs.
An der Stelle ist es auch eine Frage der Colormatrix der Kamera, denn die müsste aus den negativen Werten wieder positive Werte machen, denn kein Monitor kann negative Werte darstellen. Und gerade solche Prozesse, die letztlich ein Signal ja auch aus seiner Beliebigkeit herausholen, regeln halt standardisierte Verfahren, wie das IEC 61966-2-4 für xvYCC.
Ich sehe ja den Ansatz und kann den Zugewinn ja auch durchaus nachvollziehen, nur weiss ich eben nicht, ob so ein "Zufallsprodukt" die Lösung ist.
Der Farbbalken wäre zumindest ein Hinweis, ob das nachgelagerte Videosignal überhaupt vom Spacing innerhalb der Matrix liegt denn hier entstehen negative Werte, die durch die Color-Space-Conversion Matrix wieder in positive Werte umgerechnet werden. .... Oder eben, ob es tatsächlich lediglich ein "Zufallssignal" ist, was da aus der kamera kommt. Das soll jetzt gar nicht abwertend sein, aber manchmal wird eben für den Consumermarkt was gebaut, was professionellen Anforderungen nicht wirklich entspricht.
Nur würde ich dann nicht darauf setzen, weil dann die nächste Kamera schon wieder ganz anders aussehen kann.
Und, wie gesagt .... das ist ja dann kein Endsignal und an der nächsten Umrechnung geht es entweder flöten, oder sieht ziemlich "random" danach aus.
Am wenigsten Nutzen hat auf jeden Fall ein clippendes Decoding. Das ist einfach nur eine extreme Holzhammer-Methode. Eigentlich fast schon ein GAU im Umgang mit Codecs.
Da bin ich ja uneingeschränkt bei Dir ... aber solche Dinge lassen sich ja auch über andere Kurvenverläufe viel eleganter regeln, als einfach in Werteräume zu gehen, die der nächste Verabeitungsschritt schon nicht mehr kennt.
.
Ebenfalls oben schon mehrfach erwähnt: es geht darum, dass sich der Wertebereich nicht nur ansehen, sondern auch nutzen und sogar in ein normgerechtes Broadcast-Signal reinrechnen lässt.
Und da liegt natürlich eine Gefahr, weil Du ein Signal stauchst, dessen Dehnung gar nicht wirklich bekannt ist. Dabei verlierst Du ziemlich zufällig Werte, die Du Dir mühsam zusammengebaut hast.
Im Grunde sind wir uns über das Ziel ja einig, ich bevorzuge eben nur reproduzierbare (standardisierte) Methoden
Naja, das Problem des Clippings der 5d-Clips lässt sich auf Windows-Systemen auf jeden Fall durch Frameserving - und somit Umgehung von Quicktime - lösen.
Wie das auf Mac-Seite aussieht, weiß ich nicht, würde mich aber auch interessieren. Ich bin mehrfach auf die Info gestoßen, dass es zwar weder direkt über Quicktime-Einstellungen, noch in Final Cut machbar wäre. Aber scheinbar geht es auf irgendeinem, bisher nicht näher beschriebenen Weg in Color.
"Dabei verlierst Du ziemlich zufällig Werte, die Du Dir mühsam zusammengebaut hast."
Ja, ich habe keinen direkten (oder nur einen sehr eingeschränkten) Einfluss darauf, welche Information dann wirklich rübergerettet wird und welche nicht. Aber zumindest kann ich das während des Prozesses (des Filterns) beobachten und damit beurteilen, ob das so o.k. ist.
Wenn die Kamera schon gleich begrenzender aufzeichnet, habe ich ja auch keinen direkten Einfluss darauf und in der Regel noch weniger Kontrollmöglichkeiten (wenn's nicht ein Dreh mit paralleler technischer Kontrolle ist).
Wichtig und entscheidend ist doch, für die jeweilige Umgebung die bestmögliche Lösung für die Bearbeitung des Signals zu finden, wie es die Kamera eben liefert. Landet dabei tatsächlich geclipptes Schwarz und Weiß in meinem NLE, sind mir diesbezüglich die Hände gebunden. Wenn ich aber weiß, dass die Kamera selbst gar nicht geclippt hat und auch nicht so aufgezeichnet hat, kann ich der Sache auf den Grund gehen, eine Lösung für ein Decoding ohne Clipping suchen und jeden weiteren Schritt der geforderten Umgebung anpassen.
Also, wenn man Clips, die mit der 5D gefilmt wurden in Quicktime öffnet und parallel in MPEGStreamClip, so sieht man sehr deutlich, dass im Quciktime Player die Kontraste höher sind als in MPEGStreamClip, wirklich sehr deutlich, insbesondere in den Highlights sind viele Informationen weg.
Und für gewöhnlich sieht QT ja auch aus wie FCP oder Compressor, müsste ich aber separat checken.
MB
Ich will lieber mit Weisen irren, als mit Unwissenden recht zu behalten. (Cicero)
Zumindest in FCE ist die Darstellung identisch mit der des QuicktimePlayers, also per Decoding mit geclippten Schwarz und Weiß. Ich denke, Final Cut, gleich in welcher Version, wird im Hintergrund zum Decoding von MOV-Files automatisch immer Quicktime nutzen und solange das passiert, haben die H.264-Files der Canon keine Chance auf ein ungespreiztes Signaldecoding.
Angeblich soll es in Color ja einen Weg geben, ohne Clipping zu decodieren. Das kann ich aber nicht prüfen.
Läuft MPEGStreamClip auf Mac-Plattform? Dann wäre das ja auch eine einfache Möglichkeit dem Problem zu entkommen.
Die für Windows mancherorts erwähnten Möglichkeiten, per QuicktimePro zu Avid DNxHD zu wandeln (das verschlimmert die Sache sogar noch) oder innerhalb von Windows-Anwendungen CoreAVC zu verwenden, bringen tatsächlich leider nichts, weil damit nicht verhindert wird, dass das Decoding noch über Quicktime läuft. Einzige Ausnahme scheint die Verwendung von Cineform Neo in Verbindung mit CoreAVC zu sein. Selbst überprüft habe ich nur die Methode per Frameserver. Die funktioniert zuverlässig.
Marco hat geschrieben:Angeblich soll es in Color ja einen Weg geben, ohne Clipping zu decodieren. Das kann ich aber nicht prüfen.
Läuft MPEGStreamClip auf Mac-Plattform? Dann wäre das ja auch eine einfache Möglichkeit dem Problem zu entkommen.
MPEGStreamClip gibts für PC? Wusst ich nicht, klar läuft das auf dem Mac. Und Color fürs Decodieren ist ja eher nicht so das richtige Werkzeug dafür ...
Kann MPEGStreamclip Stapel verarbeiten? Hab mich nie so wirklich damit befasst ...
MB
Ich will lieber mit Weisen irren, als mit Unwissenden recht zu behalten. (Cicero)
Hallo,
Apple hat freundlicherweise reagiert und das gestrige QuickTime Update auf 7.6 behebt die Probleme. QT verarbeitet jetzt den vollen gebotenen Range von 0-255 und beschränkt sich nicht mehr an den Videostandard von 16-235. Ich kann nur für Mac sprechen, aber wie ich aus einigen Foren gelesen habe, gilt dies auch für QT unter Windows.
Gruß
FFMPEG habe ich mir angeguckt ... opensource, das ist vom Handling her eher so die PC Abteilung, man muss 4 Programme suchen und installieren um einen Zweck zu erfüllen ... geht garnicht.
Trotzdem danke für den Tipp.
Ich aktualisiere dann mal QT.
MB
Ich will lieber mit Weisen irren, als mit Unwissenden recht zu behalten. (Cicero)
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.
