Infoseite // Canon 5D MarkII mit eingeschränktem Dynamikumfang?

Newsmeldung von slashCAM:


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.

Dies ist ein automatisch generierter Eintrag


Hier geht es zur Newsmeldung mit Link und Bildern auf den slashCAM Magazin-Seiten




Antwort von joey23:

Warum sollten Apple-User von solchen "Feinheiten" nichts wissen wollen? Komische Aussage.



Antwort von Axel:

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.



Antwort von MarcBallhaus:

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



Antwort von Axel:

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.



Antwort von Marco:

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.

Marco



Antwort von deti:

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



Antwort von MacPro:

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)



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

Deti






Antwort von Marco:

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.

Marco



Antwort von WoWu:

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.

Hier noch ein Link zur Mark II und QT
http://www.film-tv-video.de/newsdetail. ... no_cache=1



Antwort von Marco:

Oh nein, nicht schon wieder ...

Marco



Antwort von WoWu:

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.



Antwort von Marco:

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

Marco



Antwort von MacPro:

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. 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.
Hier noch ein Link zur Mark II und QT
http://www.film-tv-video.de/newsdetail. ... no_cache=1
Die haben den Grund dahinter aber auch nicht wirklich verstanden.



Antwort von WoWu:

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.



Antwort von PowerMac:

Bei digitalen Kinoformaten könnte das schon was bringen, bei TV-Auswertungen sicher nicht.



Antwort von Marco:

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






Antwort von MacPro:

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.

Edit: Marco war schneller;-)



Antwort von WoWu:

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 ?



Antwort von MacPro:

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.



Antwort von Marco:

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



Antwort von MacPro:

hehe;-)



Antwort von Axel:

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.



Antwort von WoWu:

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.



Antwort von Marco:

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.

Marco



Antwort von WoWu:

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






Antwort von Marco:

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.

Marco



Antwort von MarcBallhaus:

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



Antwort von Marco:

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



Antwort von MarcBallhaus:

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



Antwort von deti:

ffmpeg ist dein Freund.

Deti



Antwort von Matzel:

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ß



Antwort von Axel:

Gute Nachrichten.



Antwort von MarcBallhaus:

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



Antwort von filmpraxis:

Ich habe den Beitrag mit Interesse verfolgt. Wir doktorn schon lange an diesem Problem herum. Ich kann bestätigen, dass es mit Apple QT 7.6 auf dem PC funktioniert. Einfach installieren neu starten und sich freuen - nach all den aufwendigen Versuchen, es irgendwie anders zu lösen.

Ich habe es auch mit EDIUS 5.01 getestet. Der original Clip sieht schon prima aus und gewinnt noch Qualität, wenn man diesen in de Canopus HQ Codec umrechnet.

Tipp für einen schnellen Test: MOV im QT abspielen, dann im Menü auf "kopieren" gehen und in einem Bildbetrachter/Bildbearbeitung auf "Einfügen" gehen. Mit allen anderen QT Versionen wird das Bild hier dunkler.

Thomas Wagner






Antwort von MarcBallhaus:


Ich habe es auch mit EDIUS 5.01 getestet. Der original Clip sieht schon prima aus und gewinnt noch Qualität, wenn man diesen in de Canopus HQ Codec umrechnet. Ein Codec der die Qualität verbessert? Ah ja. Sehr interessant.

Tipp für einen schnellen Test: MOV im QT abspielen, dann im Menü auf "kopieren" gehen und in einem Bildbetrachter/Bildbearbeitung auf "Einfügen" gehen. Mit allen anderen QT Versionen wird das Bild hier dunkler.

Thomas Wagner Eben nicht. Oh Leute ... in QT gibt es einen Kompatibilitätsmodus für FCP, der macht das Bild dunkler was an der Gamma Verschiebung liegt. Das hat damit überhaupt garnichts zu tun.

---------

Ich habe nun die neue Version von QT installiert und das Problem bleibt das selbe. Ein PNG, rausgerechnet mit MPEGStreamclip hat mehr Dynamikumfang als der selbe Frame mit QT nach PNG. Bei letzterem sieht man im Histogramm deutlich, dass schlichtweg oben und unten etwas abgeschnitten wurde, und zwar genau bei 16 und 235.

MB



Antwort von Marco:

Habe gerade das Update in der Windows-Version installiert. Damit ist das Problem definitiv behoben. Ich finde es nur heftig, dass Apple dafür satte drei Jahre gebraucht hat.

MarcBallhaus, ich kann es auf dem Mac momentan nicht mit einer Waveformdarstellung prüfen. Aber der Bildvergleich zeigt nach dem Update gegenüber der Quicktime-Vorversion erkennbar mehr Details in Lichtern und Schatten. Also eine Verbesserung kann ich erkennen, aber ich weiß nicht, ob das Clipping damit - so wie es in der Windows-Version der Fall ist - ganz behoben ist.

Marco



Antwort von MarcBallhaus:

Habe gerade das Update in der Windows-Version installiert. Damit ist das Problem definitiv behoben. Ich finde es nur heftig, dass Apple dafür satte drei Jahre gebraucht hat.

MarcBallhaus, ich kann es auf dem Mac momentan nicht mit einer Waveformdarstellung prüfen. Aber der Bildvergleich zeigt nach dem Update gegenüber der Quicktime-Vorversion erkennbar mehr Details in Lichtern und Schatten. Also eine Verbesserung kann ich erkennen, aber ich weiß nicht, ob das Clipping damit - so wie es in der Windows-Version der Fall ist - ganz behoben ist.

Marco Die Verbesserung kann ich erkennen, betrifft aber den Gamma, nicht das Clipping.

MB



Antwort von Marco:

Änderungen im Gamma habe ich eigentlich gar nicht berücksichtigt. Es sind erkennbare Verbesserungen in den dunkelsten Schwarz- Weißbereichen. Aber für mich derzeit auf dem Mac leider nicht messbar.

Marco



Antwort von domain:

Eine ausschließliche Gammaveränderung kann ich mir eigentlich nicht wirklich vorstellen, das wäre ja ein Witz. Das Bild würde zwar weicher aussehen (Spreizung der 226 auf 256 Stufen mit feineren Abstufungen) aber das würde das Clippingproblem ja in keiner Weise lösen.



Antwort von Marco:

Ich bin auf dem Mac mal den Umweg über eine Grafiksoftware gegangen, um es zumindest per Histogramm vergleichen zu können. Leider habe ich aus der alten QT-Version nur noch einen einzigen Screengrab, in dem die Lichter nicht so sonderlich kritisch waren. Aber im Schwarzbereich war dort mit QT 7.5 noch deutlich das Clipping erkennbar und auch per Histogramm messbar. Mit QT 7.6 zeigt der gleiche Clip auch im Histogramm im Schwarz keinerlei Clipping mehr. Was dort vorher durch Clipping im Schwarz weggeschnitten war, ist nun als Bildinformation im Bereich 0-15 erhalten.


Marco



Antwort von Axel:

Das Problem ist, zumindest für Quicktime, behoben, der Thread obsolet. Alles jetzt noch zu beklagende Clipping rührt von der Belichtung bei der Aufnahme her.



Antwort von MarcBallhaus:

Das Problem ist, zumindest für Quicktime, behoben, der Thread obsolet. Alles jetzt noch zu beklagende Clipping rührt von der Belichtung bei der Aufnahme her. Aha. Und warum sehe ich dann einen Unterschied von der SELBEN Aufnahme, zwischen MPEGStreamclip und QT? Egal ob angezeigt oder exportiert, QT schneidet bei 16 und 235 ab und stretcht auf 0 und 255.

MB



Antwort von domain:

Jetzt wirds aber wirklich interessant, mal gespannt bin ob Ballhaus recht hat, das wäre ja ein starkes Stück






Antwort von Marco:

...



Antwort von Marco:

Nachdem ich jetzt mal MPEG Streamclip auf dem Mac installiert hab und ein paar Vergleiche zwischen Streamclip und QuicktimePlayer auf Mac-Plattform und Frame-Exporte aus beiden Tools mit den Windows-Ergebnissen verglichen habe, verstehe ich gar nichts mehr.

Marco



Antwort von Marco:

Hab nochmal hin- und herverglichen, auch zwischen Mac und PC. Zwischen der vorherigen Quicktime-Version 7.5 und der aktuellen Version 7.6 ist auf jeden Fall ein gewaltiger Unterschied. Deutliches Clipping in Schwarz und Weiß bei Version 7.5, im Prinzip kein Clipping mehr in Schwarz und Weiß bei Version 7.6 - weder auf dem Mac, noch auf dem PC.

Die Quicktime-decodierten Signalversionen zwischen Mac und PC sind im Grunde genommen identisch. Geprüft habe ich die Signale auf dem PC mit Waveform, Histogramm und RGB-Parade. Vom Mac habe ich dazu die Canon H.264-Files in FCE importiert und von dort als Quicktime-File mit PNGs exportiert.
Außerdem habe ich vom Mac über MPEG Streamclip PNGs exportiert. Diese Streamclip-Signale sind wiederum grundsätzlich identisch mit den Versionen, die ich auf dem PC per Streamserver an Quicktime vorbeigeschleust hab. Also den Output von Streamclip auf Mac und Streamserver auf PC kann ich eigentlich gleich setzen. Und natürlich auch hier kein Clipping in Lichtern und Schatten.

Trotzdem gibt es einen deutlich erkennbaren und leicht messbaren Unterschied zwischen den "Stream"-Versionen und den Quicktime-Versionen. Die Quicktime-Versionen kommen fast nie unter RGB 16, haben insgesamt ein "helleres" Gamma und stauchen (nicht: clippen) das Weiß dann letztlich etwas mehr. Von Clipping im Weiß kann dort aber dennoch nicht Wirklich die Rede sein, bzw. wenn, dann wäre das in einem Bereich von nur etwa 1 oder maximal 2 Prozent. Ich könnte das, was ich dort sehe, gerade im Vergleich zu der vorherigen Quicktime-Version aber nicht als Clipping bezeichnen. Im Schwarz eh nicht.
Insgesamt scheinen die Quicktime-Versionen dennoch etwas mehr Dynamik zu verschenken als die "Stream"-Versionen. Nur weiß man ohne Testbild als Basis nicht, welches der Signale authentischer ist.

Im Gegensatz zum Output von Quicktime 7.5 könnte ich jetzt mit beiden Versionen leben.

Marco



Antwort von MarcBallhaus:

@Marco ... machs doch nicht so kompliziert, exportier je ein ein PNG aus MPEGStreamClip und QT - am Mac -, und lad beides in Photoshop. Dann kannst du im Histo sehen, dass die QT Variante clippt. Schränkt man mittels Tonwertkorrektur die Dynamik in der MPSC-Version auf 16 und 235 ein, sieht das PNG exakt genau so aus wie das aus QT. Also clippt QT.

MB



Antwort von Marco:

Das hatte ich auch gemacht (wenn auch nicht in Photoshop). Da clippt es ebenfalls nicht, bzw. so minimal, dass es eigentlich nicht relevant ist. Und die Unterschiede zur vorherigen QT-Version sind riesig.

Marco



Antwort von MarcBallhaus:

Das hatte ich auch gemacht (wenn auch nicht in Photoshop). Da clippt es ebenfalls nicht, bzw. so minimal, dass es eigentlich nicht relevant ist. (...)

Marco Du bist ja witzig. Also clippt es doch!

Dann filme mal Nachts und dann wirst du sehen, dass das was vorher minimal war, plötzlich ein Problem ist, weil die Kontraste Nachts am höchsten sind und du dann vor allem auf Highlights und Zeichnung in den Tiefen angewiesen bist, während die Mitten schnurzegal sind, bei Tagaufnahmen ist es genau anders herum.

MB



Antwort von Marco:

Hab mal eine lineare Kontrastkurve (von RGB 0 bis 255) als Quicktime H.264 gerendert und verschiedene Decodings analysiert. Wenn das H.264-Signal auf einem Mac decodiert wird, wird die Kontrastkurve verändert. Mit einem unkomprimierten AVI passiert das dort nicht. Auf dem PC passiert's auch mit H.264 nicht. Zudem sind die Varianten, die (vom Mac aus) aus MPEG Streamclip als Frameexport mit Gamma 2.2 rausgehen, nahezu identisch mit den Quicktime-Ausgaben (geprüft auf dem PC). Aber Ausgabe mit Gamma 1.8 aus Streamclip ist deutlich näher am Original.

Also bei allem, was ich bisher von den Mac-Outputs der H.264-Files gesehen habe, ist eine Änderung der Kontrastkurve deutlich erkennbar, bei Quicktime mehr, bei Streamclip weniger dramatisch, je nach Exporteinstellung. In keinem der Fälle wird die Kontrastkurve des Originals beim H.264-Decoding auf dem Mac korrekt reproduziert. Clipping ist nur noch geringfügig auszumachen (3 Prozent).

Ich denke, das Clipping-Problem mit Quicktime ist größtenteils behoben, aber die Darstellung der Kontrastkurve bei Mac-Bearbeitung kann noch ein Stück optimiert werden.

"Du bist ja witzig. Also clippt es doch!"

Bei kritischen Signalen wurden mit Quicktime 7.5 noch 13 Prozent des Signals geclippt. Mit Quicktime 7.6 sind es nur noch etwa 3 Prozent. Den genaueren Wert kenne ich erst, seitdem ich es mit dem Grauverlauf testen konnte (bei den Realvideos, die ich letzte Nacht unter die Lupe nahm, war das so genau gar nicht zu analysieren). Das ist ja schon eine enorme Verbesserung.
Die eigentliche Signalveränderung hat zwar viel mit der Veränderung der Kurve, aber weniger mit dem Clipping zu tun. Das war mit QT 7.5 noch ganz anders. Würden die das Gamma noch optimieren, wäre vermutlich bei der Sichtprüfung schon gar kein Unterschied mehr erkennbar. Tatsächlich lässt sich per Gammakorrektur die nach Mac-Export gekrümmte Kurve wieder zum Original hin begradigen. Also größtenteils ist's ein Gamma-Problem. Der Verlust durch Clipping bleibt natürlich auch nach der Gamma-Korrektur.

Das Histogramm erweist sich dabei übrigens nicht als gutes Messinstrument. Die Waveform-Anzeige macht deutlicher, was passiert.

Marco



Antwort von MarcBallhaus:

Die Rede ist hier nicht von H.264 am Mac allgemein, sondern von Aufnahmen der 5D die in H.264/MOVs vorliegen. Was du beschreibst ist reine Theorie, was ich schreibe ist Praxis. Sorry, nicht falsch verstehen, aber dein Ergebnis mag theoretisch richtig sein, praktisch ist es aber einfach nicht der Fall.

Das Histogramm ist m. e. das beste Werkzeug um den Tonwertumfang aufzeigen, denn für nichts anderes ist es da.



Antwort von MarcBallhaus:

Der Unterschied zum Quicktime PNG ist nicht minimal sondern erheblich. Vom Histo mal abgesehen, sind rechts obene im Bild schwarze Löcher, ebenso im Rhein links, während das Bild aus MPEGStreamclip hier noch deutliche Zeichnung hat.






Antwort von Axel:

Du hast Recht, QT hat im Schwarz ziemlich viel geclippt. Nur beim Mpeg SC Bild können über eine Tonwertkorrektur (allerdings nur dann) die winterlich kahlen Zweige links im Himmel wieder sichtbar gemacht werden.

Was bleibt also, wenn man mit FCP schneiden will? Originaldatei aus der Kamera in Color importieren und als 10bit unkomprimiert ausgeben ...



Antwort von Marco:

Natürlich ist der Umgang mit generierten Testbildern fern der Praxis. Aber bisher fehlt solchen Überprüfungen der Canon-Clips ja jegliche objektive Referenz! Solange man nicht weiß, wie ein Bild überhaupt im Originalzustand aussehen könnte, kann man kaum verlässliche Aussagen darüber machen, welches Werkzeug das Bild letztlich optimal darstellt und wo genau welcher Fehler passiert. Da muss ich Wolfgang recht geben, dass ein von der Canon generierter, genormter Farbbalken sehr wertvoll wäre (und besser als ein selbst generiertes und zu H.264 encodiertes Testbild).

Der Unterschied auf deinen Screenshots ist wirklich deutlich. Aber selbst das Signal aus Streamclip clippt noch immer ein wenig. Das Clipping im Schwarz, das auf deiner Quicktime-Version zu sehen ist, scheint zudem in etwa den o.g. 3 Prozent zu entsprechen. In diesem Motiv auch rein visuell erkennbar, in denen, die ich bisher habe, leider nicht.

Ist das Original-File vielleicht irgendwo als allgemein zugänglicher und legaler Download erhältlich?

Was mich dabei am meisten stört ist vor allem der Unterschied zwischen dem Mac- und dem PC-Decoding. Wenn ich ein Canon 5D-File aus FCE als unkomprimiertes AVI exportiere und diesen Output mit dem Original Canon-Signal auf dem PC vergleiche, dann muss ich das Gamma des FCP-Signals um den Wert 0.4 anheben, um eine prinzipiell vergleichbare Darstellung zu haben. Also beim Vergleich der Mac- und der PC-Ausgabe erschlägt der Unterschied im Gamma erstmal jeden anderen Fehler.

Marco



Antwort von MarcBallhaus:


Ist das Original-File vielleicht irgendwo als allgemein zugänglicher und legaler Download erhältlich?
Das sind alles Mood Aufnahmen, mit 1-2 Minuten Länge. Ich guck aber mal, was an Ausschuss dabei ist wo ich vielleicht nach 5 Sekunden abgebrochen habe ... hast du eine eMail Adresse für mich?

MB



Antwort von Marco:

Ich habe im Web noch ein paar Quellen gefunden. Ich schau erstmal, ob dort vielleicht noch ein paar kritische Motive drunter sind.

Marco



Antwort von MarcBallhaus:

Ich habe im Web noch ein paar Quellen gefunden. Ich schau erstmal, ob dort vielleicht noch ein paar kritische Motive drunter sind.

Marco Da würde ich nicht so viel drauf geben, weil ich hab kaum was gesehen, wo die Leute die richtigen Settings gefunden haben.

MB



Antwort von Bruno Peter:

Könnt Ihr diesen Clip dort rechts unten bei VIMEO brauchen?

http://www.vimeo.com/1764260?pg=embed&sec=1764260



Antwort von Marco:

Ja, danke für den Link.

Marco



Antwort von Marco:

Bei dieser Aufnahme war die Kamera schon krass fehleingestellt, aber dennoch konnte ich damit ansatzweise auch das Clipping im Schwarz nachvollziehen. Hatte heute nochmal eine Ladung von rund 10 völlig verschiedenen 5D-Clips durchgeschleust. Das Problem mit dem falschen Gamma beim FCE-Export und dem Korrekturwert von +0.4 dafür auf dem PC ist bei allen gleich.

Anscheinend besteht auf dem PC mit Quicktime-Decoding das Clipping-Problem in den Schatten nicht, auch nicht zu den geringen 3 Prozent. Aber das ist mit den mir zur Verfügung stehenden Clips nicht eindeutig auszumachen. Dieser letzte Clip ist qualitativ einfach grottig schlecht. Trotzdem gibt es dort in den Schatten hie und da ein "Detail", das nach Quicktime-Decoding auf dem Mac nicht mehr reproduzierbar ist, gleich wie an einer Farbkorrektur geschraubt wird.

MarcBallhaus, wenn du ein kurzes Sample eines Motives, ähnlich dem auf dem Screenshot gezeigten, finden würdest, das wäre schon interessant. Denn bei einem hochwertigerem Signal könnte ich verlässlicher testen, ob und wie sich das Clipping zwischen PC- und Mac-Quicktime-Decoding unterscheidet. Mein Mailkontakt:


zum Bild


Ohne Zweifel aber ist mit dem Quicktime-Decoding noch ein bisserl was im Argen, trotz erheblicher Verbesserung gegenüber der Vorgängerversion.

Marco



Antwort von MarcBallhaus:

@Marco

Ich habe dir nen Rohschnipsel geschickt. Der ist zwar buggy, weil ich vergaß die Automatik abzuschalten, aber dafür auch nur 20 MB groß. Aber zum testen ist das ja vielleicht garnicht so schlecht.

Gib doch mal ein Feedback, würde mich freuen.

MB






Antwort von Marco:

Super, danke für den Clip! War genau das richtige Motiv.

Also erstmal zum PC, das ist schnell abgehandelt. Ob ich auf dem PC den Clip mit der Windows-Version von MPEG Streamclip, dem QuicktimePlayer oder der Schnittsoftware (die für das Decoding auf Quicktime zurückgreift) decodiere, macht keinen Unterschied. Das Gamma stimmt scheinbar und selbst die tiefsten Schatten werden nicht geclippt.

Da der zweifelsfrei objektivierbare Bezug z.B. in Form eines genormten Farbalkens aus der Kamera fehlt, ist die Annahme, dass das Gamma der Windows-Versionen korrekt ist, immer noch zu einem Teil spekulativ. Ich berufe mich dabei auf die Testreihe mit dem intern generierten Graukeil, der nach Quicktime H.264-Encoding und anschließendem Decoding korrekt dargestellt wurde. Das birgt aber dennoch ein gewisses Fehlerpotential.

Auf dem Mac:
Da ich die Signale auf meinem MacBook nicht richtig prüfen kann, habe ich jeweils einen Export zu PNG Bildsequenzen gemacht. Einmal mit MPEG Streamclip und einmal mit FCE. Die PNG-Sequenzen habe ich dann auf dem PC überprüft.
Beide Versionen - Export aus FCE und Export aus MPEG Streamclip sahen gleich aus. Um den Wert 0.4 verändertes Gamma und zudem das leichte Clipping in den Schatten.

Wenn ich aus Streamclip einen anderen als den einzelnen Frameexport wähle, habe ich keine Wahl beim Gamma. Ich denke, es wird dann immer 2.2 benutzt. Genau das scheint auf dem Mac bei Streamclip und bei Quicktime zur größten Abweichung zu führen.
Ich habe dann nochmal das erste Frame des Clips aus Streamclip mit Gamma 1.8 exportiert. Das Resultat ist besser, liegt irgendwo zwischen der 2.2-Version und den Windows-Versionen und das Clipping scheint grundsätzlich eliminiert.

Was mich aber wundert ist, dass beim Mac Streamclip-Export zum einen das Gamma bei der 1.8-Exportoption letztlich nicht zu einer Abweichung von 0.4 Werten gegenüber der 2.2-Exportoption liegt und damit noch immer nicht gleich den Windows-Versionen ist.
Zum andern sind auch dort (bei der Gamma 1.8 Exportoption) die dunkelsten Schatten noch stark komprimiert, so dass es bei einem solch kritischen Motiv nur knapp an einem Clipping vorbeischießt.

Also mal unabhängig davon, welches Werkzeug auf welcher Plattform zur optimalen Decodierung führt, gelingt es mir nicht, beim Decoding der 5D-Clips auf Mac und PC ein einheitliches Resultat zu erhalten.

Marco



Antwort von PowerMac:

Den Gamma-Shift wird es deshalb geben, da Quicktime den Mac-eigenen Gammawert von 1.8 ausgleichen versucht. Wobei ich beispielsweise einen Monitor-Gamam von 2.2 habe… Schon wieder falsch:) Unmöglich einen Standard für die "richtige" Rezeption aufzustellen. Zuviele Monitore, Betrachtungssituationen, Parameter…



Antwort von Marco:

Sowas fürchte ich auch. Ich bin auf dem Mac noch nicht sattelfest. Ich dachte nur immer, dass das Gamma von 1.8 lediglich für Mac-interne Betrachtung und Player relevant wäre, der endgültige Videoexport aber grundsätzlich für eine 2.2-Wiedergabe ausgelegt sein müsste. Ich glaube, bei anderen Videoformaten wird dem in Quicktime (auf Mac) auch Rechnung getragen. Nur H.264 scheint da aus der Reihe zu tanzen.
Womit auch wieder die Frage im Raum steht, welches Gamma-Mapping denn die Canon D5 beim H.264-Encoding verwendet.

Meine Unsicherheit, ob das mit Quicktime 7.6 auf Windows-Plattform denn wirklich so perfekt ist, wie es auf den ersten Blick scheint, ist womöglich auch nicht so ganz ungerechtfertigt. Es gibt Vermutungen (in anderen Foren), wonach das nur eine "Quick'n'Dirty"-Lösung ist, bei der etwas unglücklich zwischen 3 verschiedenen Farbräumen hin und hergewandelt wird, was zwar zu einem Signal ohne Clipping von Schwarz und Weiß führt, das 8-Bit-Signal dabei aber überstrapaziert wird, so dass Informationen an anderer Stelle verloren gehen. Erkennbar wird das an Lückenbildung im Histogramm. Das hatte ich auch mit etwas Verwunderung bemerkt.
Außerdem gibt es hie und da Äußerungen dazu, dass das Gamma beim H.264-Decoding per Quicktime auf Windows-Plattform etwas zu hoch angesetzt wird und das Bild dadurch heller scheint als es sein sollte. Dann würde letzten Endes ja fast gar keine Decodierungsversion mehr stimmen (zumal das Resultat von der Windows-Version von MPEG Streamclip mit dem Quicktime-Resultat identisch ist).
Möglicherweise ist ja das Resultat von MPEG Streamclip auf Mac (und die Streamserver-Variante auf PC) noch das beste, im Sinne von: am nächsten am Original.

Marco

Nachtrag:
Die Lösung, die den authentischsten Eindruck macht und zudem in jedem Meßinstrument die wenigsten Artefakte zeigt, ist die mit dem Streamserving per AviSynth.
Am suspektesten ist dagegen noch immer der Weg über Quicktime. Da wurden mit der Lösung des einen Problemes offenbar neue Probleme geschaffen.
MPEG Streamclip mit Gamma 2.2 Output hat zwar ebenso wenig Artefakte wie die AviSynth-Lösung, aber vermutlich falsches Gamma und clippt. MPEG Streamclip mit Gamma 1.8 clippt zwar wohl nicht mehr, zeigt aber schon mehr Artefakte (aber immer noch weniger als Quicktime auf Windows) und es bleibt fraglich, ob das Gamma hier korrekt ist (die Frage stellt sich allerdings bisher bei jeder der hier beschriebenen Lösungen).



Antwort von MarcBallhaus:

Bitte gerngeschehen :)

Ich folgere nun, dass du nicht das Clipping in dem Maße hast, wie ich es hatte?

MB



Antwort von Marco:

Hab oben noch was ergänzt. Ich würde dir gerne ein paar Resultate inklusive den Anzeigen der Messinstrumente (Waveform, Histogramm und RGB-Parade) zukommen lassen. Die Tatsache, dass ein jedes Werkzeug ein anderes Resultat produziert, bremst allerdings.

Mein momentanes Fazit wäre, dass trotz Quicktime-Update für ein Resultat mit möglichst wenig Qualitätsverlust Quicktime vermieden werden sollte, auf dem PC noch immer besser der Weg über Frameserving gegangen sollte, auf dem Mac MPEG Streamclip mit optimalen Gamma-Mapping (sofern möglich).
Wer allein damit zufrieden ist, dass das Quicktime-Update das Clipping mehr oder minder verbessert hat und andere Faktoren eher in die theoretische Nische abstellt, findet mit dem Quicktime-Update natürlich schon eine einfache Lösung.

Für dich persönlich ist vermutlich eher die Mac-Seite von Bedeutung, oder?

Marco



Antwort von MarcBallhaus:

Für dich persönlich ist vermutlich eher die Mac-Seite von Bedeutung, oder?

Marco Ja, schon eher. Ich hab zwar noch diverse PCs, aber eben auch ein Macbook und ein paar ordentliche Mac Pro. Aber wenns nur auf dem PC bequem geht, dann eben PC.

MB



Antwort von Marco:

Auf Windows habe ich tatsächlich kein Clipping, auch nicht mit Quicktime 7.6. Aber die Resultate sind dennoch fragwürdig, mit Ausnahme der Frameserver-Methode.

Ich komme heute nicht mehr dazu Beispiele zusammenzustellen. Ich werd's morgen oder übermorgen nachholen.

Marco



Antwort von Marco:

Die zusammengefassten Beispiele sind -> hier downloadbar. Ordnerbezeichnungen in Verbindung mit Dateibezeichnungen sollten selbsterklärend sein.

In den Histogrammen (nicht wundern, die sind logarithmisch) gut zu erkennen, dass nur die AVISynth-Lösung Artefaktfrei bleibt. Wenn man genau vergleicht, sieht man auch, dass die Artefakte genau dort entstehen, wo das Signal gestaucht oder gespreizt wurde. Artefakte wie sie bei Farbraum- und Farb- und Luminanzsignaländerungen in einem 8-Bit-Signal leicht zu provozieren sind.

Marco