Hier im Forum wurde bereits häufiger von Farbabweichungen berichtet (und dies auch ausführlich diskutiert). Dabei ging es oft darum, dass bei der Wiedergabe am PC ein türkiser bzw. grünblauer Farbton auftritt, wo ein (helles) Blau erwartet wurde.
Hinweis:
Gleich kommt eine Erklärung, mein Lösungsvorschlag mit Beispiel folgt. Wer sich für die Details nicht interessiert, kann die Erläuterungen einfach überspringen und gleich meinen Filter ausprobieren, der das oben angesprochenen Problem unter bestimmten Voraussetzungen behebt.
Hintergrund: Gängige Video-Codecs verwenden zur Speicherung der Farben aller Pixel YCbCr-Koordinaten, zur Darstellung müssen diese in RGB-Koordinaten transformiert werden. Hierbei gibt es YCbCr-Koordinaten, zu denen keine RGB-Koordinate im für RGB-Farben verwendeten Wertebereich gehört.
Für alle, die jetzt nicht sofort folgen können, habe ich den Zusammenhang veranschaulicht (siehe Abbildung "YCbCr-RGB.jpg"):
Der äußere durch Linien dargestellte Würfel veranschaulicht den Umfang der über die verwendeten YCbCr-Tripel beschreibbaren Farben. Der innere, kleinere und farbig dargestellte Bereich zeigt den Farbumfang, der dem sRGB bzw. BT.709-RGB Farbraum entspricht und auf entsprechenden Displays darstellbar ist.
Treten YCbCr-Farben außerhalb des darstellbaren RGB-Farbumfangs auf, d.h. in der Abbildung außerhalb des farbigen Bereichs, dann müssen diese Farben für die Darstellung am RGB-Monitor durch von ihm erzeugbare Farben, d.h. solche im farbigen Bereich, ersetzt werden.
Je nachdem wie dieser Austausch geschieht, findet zwangsläufig eine Veränderung der Farbe statt. Bei der einfachsten (und schnellsten) Methode können auffällige Farbabweichungen auftreten. Verändert man die Methode, dann erhält man andere Ersatz-Farben, die im Einzelfall stimmiger wirken.
Soviel zur Theorie. Ich habe nun Aufnahmen einer Kamera (bei denen ich explizit die von anderen Forums-Usern angesprochenen und am PC meist als türkis erscheinenden Farben provoziert habe) untersucht und festgestellt, dass nach der Dekompression der Frames in eine YCbCr-Bitmap in diesen Bereichen Farben auftreten, deren YCbCr-Koordinaten nicht im darstellbaren RGB-Farbraum liegen. Damit muss der oben angesprochene Austausch dieser Farben stattfinden.
Damit man sich dies besser anschaulich vorstellen kann ein Beispiel (siehe Abbildung "Beispiel.jpg"): In der linken Hälfte wurde die gängige schnelle Variante verwendet, in der rechten Hälfte ein Alternativvorschlag, der von der Farbe her "richtiger" erscheint. Nicht betroffene Farben bleiben in beiden Hälften des Beispiels unverändert.
Zum selber Ausprobieren habe ich noch einen Filter für VirtualDub (1.9.11, 32-bit), mit dem mehrere Varianten der YCbCr-nach-RGB-Umwandlung ausprobiert werden können. Darunter ist als Voreinstellung auch mein eben gezeigter Vorschlag. (Je nach Ausgangsdatei bzw. Dateityp und Codec kann die Installation zusätzlicher VirtualDub-Erweiterungen zur Unterstützung zusätzlicher Dateiformate bzw. Codecs erforderlich sein, wenn z.B. MTS-Dateien geladen weden sollen.)
Wichtig: Nur, wenn die verwendete Kamera auch "erweiterte" YCbCr-Tripel aufzeichnet und auch nur, wenn diese bis zum Import durch VirtualDub erhalten bleiben, kann mein Filter einen Unterschied bewirken. Daher am Besten Originaldateien laden.
Gibt es keine solchen Farben, dann erzeugt auch mein Filter keinen sichtbaren Unterschied. YCbCr-Farben, die innerhalb des RGB-Bereichs liegen, bleiben immer unverändert. Daher kann mein Filter nicht mit Verfahren der nachträglichen Farbkorrektur verglichen werden, bei der neben den zu verändernden Pixels auch als Nebeneffekt auch nicht betroffene Pixel verändert werden könnten.
Der Filter eignet sich also besonders für Kameras, die gegenüber RGB erweiterte Farben aufzeichnen.
Zusätzlich kann der Filter auch dazu verwendet werden, um "Superweiß" oder "Tiefschwarz" zu erhalten bzw. sichtbar zu machen. Näheres habe ich in der Readme-Datei zum Filter aufgeschrieben.
Ich würde mich über Kommentare freuen, insbesondere darüber, ob der Filter als nützlich empfunden wird, ob bei Euren Videos größere Unterschiede sichtbar wurden und falls ja, mit welcher Kamera die Ausgangsdatei erzeugt wurde.
Viel Spaß beim Ausprobieren. :-)
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
TheBubble hat geschrieben: (Je nach Ausgangsdatei bzw. Dateityp und Codec kann die Installation zusätzlicher VirtualDub-Erweiterungen zur Unterstützung zusätzlicher Dateiformate bzw. Codecs erforderlich sein, wenn z.B. MTS-Dateien geladen weden sollen.)
Ich wollte das jetzt mal ausprobieren. Leider weiß ich nicht, welche Erweiterung für MTS-Dateien installiert werden muss. Hast du einen Tipp?
Besprichst du etwa dieses Phänomen, dass eigentlich zur genüge in allen Facetten bereits behandelt wurde?
Siehe diese Himmelblau-Unterschiede, allein verursacht durch eine zu steile Kontrasteinstellung bei der Aufnahme einerseits und durch eine flachere Kontrasteinstellung im rechten Bild anderseits.
In VDUB genügt nach meinen Erfahrungen übrigens eine simple Filtereinstellung, um aus einem Türkishimmel einen normalen zu machen.
@TheBubble
Ich habe probiert dein Plugin runter zu laden aber es werden nur ca. 18 KB von den angegebenen 63 KB gespeichert. Dann habe ich es erneut probiert, worauf SlashCam diese Meldung brachte:
"Entschuldigung, aber du bist nicht autorisiert dieses Attachment anzugucken oder herunterzuladen."
Als ich probiert habe das ca. 18 KB große Zip-File zu öffnen kam die Meldung, ich solle den nächsten Datensatz einlegen, was auf eine unvollständige Zip-Datei hinweist und ist auch mit 7Zip nicht zu öffnen.
TheBubble hat geschrieben:Nur, wenn die verwendete Kamera auch "erweiterte" YCbCr-Tripel aufzeichnet und auch nur, wenn diese bis zum Import durch VirtualDub erhalten bleiben, kann mein Filter einen Unterschied bewirken. Daher am Besten Originaldateien laden.
Gibt es keine solchen Farben, dann erzeugt auch mein Filter keinen sichtbaren Unterschied.
Genau so ist, nur dass in VDUB das Problem viel einfacher zu lösen ist und keine speziellen Scripts erfordert.
Es geht einfach darum, die über 235 zu liegen kommenden Werte, welche die meisten Kameras in YCbCr aufzeichnen, auf 235 herunterzuholen. Bedeutet allerdings auch, dass es keine über 235 liegenden Werte bei 709 RGB mehr gibt, aber ohne Abschneidung sondern mit Integration durch Neuquantisierung.
Jan hat geschrieben:Wen ich das richtig verstehe, läuft das bei den 3 Chipern so ab. Licht wird in RGB aufgeteilt, dann in YCbCr verarbeitet und dann wieder in RGB ausgegeben.
Was soll das ?
TheBubble hat geschrieben:
Ist eben der Lauf der Dinge :-)
Vereinfacht läuft es so:
Das gemischte Licht wird getrennt mit Sensoren für R, G und B Anteile erfasst, so verarbeitet, dann nach YCbCr gewandelt, weiter verarbeitet, dann kommt das Chroma-Subsampling, ggf. wieder ein Zwischenverarbeitung, danach folgt die eigentliche Videokompression und irgendwann darauf folgt die Datei auf der Speicherkarte als Ergebnis.
Die Datei wird gelesen und verarbeitet, die Videodekompression kommt, ggf. kann jetzt etwas an den YCbCr Daten verändert werden, es folgt ein Chroma-Upsampling, jetzt kann wieder etwas verarbeitet werden, danach kommt die Wandlung nach RGB, jetzt ist die letzte Möglichkeit noch etwas zu verändern, und das Ergebnis kann am RGB-Monitor dargestellt werden.
Und warum bleibt man nicht gleich komplett bei einer RGB Kette ?
Da dieser Türkis Fluch ja mehr oder weniger nur mit den 3 Chipern von Panasonic passiert, muss dort doch ein Fehler gemacht worden sein.
Ich kann mich bei einer Canon oder Sony 3 Chiper nie an diese Türkisaktionen erinnern.
Vom türkis Farbstich bin ich bei Wiedergabe und Darstellung verschont.
Das Plugin habe ich nicht ausprobiert.
Vom PC über HDMI habe ich am FHD-TV einen blauen Himmel und kann sogar den vollen Farbwertebereich anschauen (Panasonic X900M).
Wie es mit BluRay oder sonstigen Zuspielern aussieht kann ich nicht sagen.
Die Abspielkette beeinflusst die Darstellung
Da gibt es in 8 bit nichts über 255, bzw. habe selten mehr als 100 Pixel in 255,255,255 (Grauwerte) im original gerenderten Film.
Gruss Tiefflieger
OT
Und ehrlich gesagt stören mich Spitzlichter nicht, bzw. machen sogar das Salz in der Suppe aus.
Aber es funktioniert nur, weil ich bei meinen Filmen mit Smartrendering beim Original bleibe.
Darum bin ich gespannt, wenn 4K TV mit 4:2:2 besser 4:4:4/RGB in 10 bit Farbtiefe satte Farben in wide gamut zeigen.
Dann werden vermutlich die "nativen" 3-Chip Farben erst recht korrekt? oder besser dargestellt.
Wie verhalten sich da wohl veränderte Gamma Farbverläufe (bzw. komprimierte/heruntergezogene Farbwerte?)
Wenn es am Schluss gut oder wunschgemäss aussieht ist das bei Vorführung i.O.
Bzw. ich persönlich muss nur auf mich schauen.
Und warum bleibt man nicht gleich komplett bei einer RGB Kette ?
Weil man im Consumerbereich über 4:2:2 (4:2:0) gehen muss und das gibt es in RGB nicht.
Die falschen Farben entstehen auch nur aus den Rundungsfehlern der Konversion, wo dann plötzlich Werte im negativen Bereich (z.B. bei ROT) abgeschnitten werden müssen und so in der Summe eine andere Farbe (als mit Rot) entsteht.
Ob das Türkisproblem nun darauf zurückzuführen ist, bezweifel ich nach wie vor. -Aber das ist lang und breit besprochen worden-.
Nur deutet eben Deine Beobachtung, dass es andere 3-Chip Kameras nicht habe, gleichwohl wie Tieffliegers Beobachtung, dass das Problem bei ihm auch nicht relevant ist, ebenso darauf hin. Denn die RGB=>YCbCr Wandlung haben die andern 3-Chiper ja auch und hätten mit den gleichen Rundungsfehlern zu kämpfen.
bArtMan hat geschrieben:Ich wollte das jetzt mal ausprobieren. Leider weiß ich nicht, welche Erweiterung für MTS-Dateien installiert werden muss. Hast du einen Tipp?
domain hat geschrieben:Besprichst du etwa dieses Phänomen, dass eigentlich zur genüge in allen Facetten bereits behandelt wurde?
Ja, dieses Phänomen ist quasi das sichtbare Artefakt.
domain hat geschrieben:
Siehe diese Himmelblau-Unterschiede, allein verursacht durch eine zu steile Kontrasteinstellung bei der Aufnahme einerseits und durch eine flachere Kontrasteinstellung im rechten Bild anderseits.
Ja. Wenn Du allerdings bereits mit den "falschen" EInstellungen gefilmt hast, kann mein Plugin verwendet werden. Ähnliche Probleme treten übrigens auch bei anderen Farben auf, fallen dort jedoch weniger auf, da man bei vielen Objekten keine bestimmte Farbe erwartet.
Einfach mal ausprobieren.
domain hat geschrieben:
In VDUB genügt nach meinen Erfahrungen übrigens eine simple Filtereinstellung, um aus einem Türkishimmel einen normalen zu machen.
Nicht ohne sonst unbetroffene Bereiche mit zu beeinflussen, die z.B. türkis sein sollen. Das ist bei meinem Filter das Besondere.
MLJ hat geschrieben:@TheBubble
Ich habe probiert dein Plugin runter zu laden aber es werden nur ca. 18 KB von den angegebenen 63 KB gespeichert. Dann habe ich es erneut probiert, worauf SlashCam diese Meldung brachte:
"Entschuldigung, aber du bist nicht autorisiert dieses Attachment anzugucken oder herunterzuladen."
Als ich probiert habe das ca. 18 KB große Zip-File zu öffnen kam die Meldung, ich solle den nächsten Datensatz einlegen, was auf eine unvollständige Zip-Datei hinweist und ist auch mit 7Zip nicht zu öffnen.
Keine Ahnung, was los ist. Da der Download-Zähler inzwischen hochgezählt hat, vermute ich, das es bei anderen geklappt hat. Funktioniert es jetzt auch bei Dir wieder?
domain hat geschrieben:Genau so ist, nur dass in VDUB das Problem viel einfacher zu lösen ist und keine speziellen Scripts erfordert.
Es geht einfach darum, die über 235 zu liegen kommenden Werte, welche die meisten Kameras in YCbCr aufzeichnen, auf 235 herunterzuholen. Bedeutet allerdings auch, dass es keine über 235 liegenden Werte bei 709 RGB mehr gibt, aber ohne Abschneidung sondern mit Integration durch Neuquantisierung.
Leider ist es nicht so einfach, auch YCbCr-Farben mit Y kleiner 235 und auch mit Cb und Cr im an sich erlaubten Wertebereich können unter Umständen in sRGB/BT.709-RGB nicht vorhanden und damit zunächst nicht darstellbar sein.
Dein Vorschlag der Helligkeitsabsenkung mildert das Problem ab, da in mittleren Helligkeitsbereichen mehr Farben als in hellen und dunklen Bereichen darstellbar sind, löst es jedoch nicht zuverlässig und verändert nebenbei auch noch die Helligkeiten von nicht betroffenen Pixeln, was ebenfalls unerwünscht sein kann.
Jan hat geschrieben:
Und warum bleibt man nicht gleich komplett bei einer RGB Kette ?
Heute (digital): Bessere Kompression durch Dekorrelation und der zusätzlichen Möglichkeit mehr Helliigkeitsinformationen als Farbinformationen abzuspeichern (mittels Farbunterabtastung).
Früher (analog): Geringere Bandbreite für die Farbinformationen, Abwärtskompatibilität mit alten S/W-Geräten.
Jan hat geschrieben:
Da dieser Türkis Fluch ja mehr oder weniger nur mit den 3 Chipern von Panasonic passiert, muss dort doch ein Fehler gemacht worden sein.
Vielleicht verwenden andere Kameras einen Sensor mit anderen Primärfarben. Vielleicht machen sie intern vor der Aufzeichnung so etwas ähnliches wie mein Filter. Ich weiß es nicht.
Jan hat geschrieben:
Ich kann mich bei einer Canon oder Sony 3 Chiper nie an diese Türkisaktionen erinnern.
Es muss nicht Türkis sein. Es ist nur eben so, dass bei dieser Farbe Abweichungen besonders auffällig sind.
MLJ hat geschrieben:Als ich probiert habe das ca. 18 KB große Zip-File zu öffnen kam die Meldung, ich solle den nächsten Datensatz einlegen, was auf eine unvollständige Zip-Datei hinweist und ist auch mit 7Zip nicht zu öffnen.
Ich habe es eben noch einmal ausprobiert: Die ZIP-Datei (ca. 64KB) kann von mir runtergeladen werden und ist intakt. Klappt es jetzt auch bei Dir?
@TheBubble
leider nein, wieder nur ca. 18 KB großes Zip-File und SlashCam schmeißt mich nach dem Download raus und muss mich neu anmelden :( Keine Ahnung was da los ist.
MLJ hat geschrieben:@TheBubble
leider nein, wieder nur ca. 18 KB großes Zip-File und SlashCam schmeißt mich nach dem Download raus und muss mich neu anmelden :( Keine Ahnung was da los ist.
Sehr merkwürdig. Kann das noch jemand bestätigen? Vielleicht kann ich die Datei nur runterladen, weil ich sie hochgeladen habe?
Tiefflieger hat geschrieben:
Ich habe ein Beispiel einer Panasonic SD700 die nach türkis schreit.
Aber nur auf einem Monitor der kein richtiges sRGB darstellen kann.
Der mittlere Teil ist milchig blau und oben rechts im kleinen Fleck ist es bereits dunkleres blau selbst auf einem schwachen Monitor.
Ohne die Bitmaps jetzt im Detail untersucht zu haben, sehen beide subjektiv gut aus.
@TheBubble
ich habe jetzt mal FireFox statt Opera genommen, es hat funktioniert, es scheint also an Opera zu liegen. Merkwürdig nur, das ich sonst mit dem Download von Dateien, auch Zip's keine Probleme hatte, nur bei dieser. Mit was hast du die gepackt ? Microsoft Komprimierte Ordner ? 7Zip ?
@TheBubble
Off-Topic on:
Ich würde mir 7Zip herunterladen weil schnell, einfach und macht jedes Archiv auf, auch die alten Formate. Ich verwende 7Zip jetzt schon eine ganze Weile und möchte das nicht mehr missen. Übrigens: Es ist Frei, also kostenlos und auch sehr gut für Backups geeignet ;)
Off-Topic off
Ich werde deinen Filter mal testen mit VirtualDub (1.9.11) und dir dann hier berichten. Normalerweise verfügt VirtualDub über sehr gute Möglichkeiten auch schwierige Fälle in den Griff zu bekommen, aber man weiss ja nie ;) Du hast den Filter geschrieben oder habe ich da was falsch gelesen ?
MLJ hat geschrieben:
Ich würde mir 7Zip herunterladen weil schnell, einfach und macht jedes Archiv auf, auch die alten Formate. Ich verwende 7Zip jetzt schon eine ganze Weile und möchte das nicht mehr missen. Übrigens: Es ist Frei, also kostenlos und auch sehr gut für Backups geeignet ;)
Off-Topic off
Das verwende ich in der Tat gegegentlich als GUI-Programm. In dem Fall hier packe ich die Software jedoch skriptgesteuert mit den sonstigen Dateien (Readme, usw.) zusammen, ohne großartig manuell tätig werden zu müssen.
MLJ hat geschrieben:
Ich werde deinen Filter mal testen mit VirtualDub (1.9.11) und dir dann hier berichten.
Danke.
MLJ hat geschrieben:
Normalerweise verfügt VirtualDub über sehr gute Möglichkeiten auch schwierige Fälle in den Griff zu bekommen, aber man weiss ja nie ;)
Der Filter ersetzt quasi die Farbumwandlung YCbCr nach RGB, die sonst von VirtualDub selbst durchgeführt wird (und dabei von VirtualDub derzeit nach BT.601 vorgenommen wird, mein Filter erlaubt zusätzlich die freie Wahl).
MLJ hat geschrieben:
Du hast den Filter geschrieben oder habe ich da was falsch gelesen ?
@TheBubble
Tja, bereit für die Testergebnisse ? Ich habe extra meine Arbeit im Studio unterbrochen für den Test, und der hat nicht funktioniert, leider.
Hier die Ergebnisse deines YCbCr Plugins:
Modul "Kernel32.dll" (Fehler !)
Entry Point 0x00CA DecodePointer (Fehlt ! -> Nicht zugeordnet)
Entry Point 0x00EE EncodePointer (Fehlt ! -> Nicht zugeordnet)
"Unresolved Import due to missing Export Funktion" (Dependent Mode)
Module NTDLL.dll, User32.dll und GDI32.dll -> Keine Fehler
Prozessoren: AMD und Intel
Grafikkarten: ATI, Intel und Matrox
Mit Depends und Debugger konnte ich das nicht beheben, also musst du da wohl nochmal ran ;)
VirtualDub verweigert das Plugin im "Plugins" und "Plugins32" Ordner mit der Meldung "Fehlende Import und Export Funktion"
Du hast die Linker Version 10 genommen, auch das nötige Update dafür Installiert ? Seit Version 6 gibt es immer wieder Probleme mit dem MS Compiler, also mal nachsehen :)
Frage: Warum Zeitlich "Limitiert" ? Funktioniert dein Plugin nur für eine bestimmte vorgegebene Zeit ?
Getestet mit Windows 2000 Pro (SP4) und Windows 98SE mit gleichem Ergebnis. Ich hoffe das ich dir damit etwas geholfen habe :)
MLJ hat geschrieben:
Getestet mit Windows 2000 Pro (SP4) und Windows 98SE mit gleichem Ergebnis. Ich hoffe das ich dir damit etwas geholfen habe :)
Dann ist klar, woran das Problem liegt: Dein Betriebssystem ist viel zu alt. Ab Windows XP mit aktuellstem SP und allen Updates sollte es gehen, von mir bei der Entwicklung getestet ist es ab Windows 7 mit aktuellem SP und allen Updates. Fuer Windows 2000 kann der verwendete Compiler bzw. Linker auch keinen Code generieren, daher werde ich da zumindest kurzfristig nichts machen koennen.
Ist aber ein guter Hinweis, ich sollte die Mindestanforderungen in der Doku ausdruecklich erwaehnen.
Das Plugin ist wie in der Doku beschrieben zeitlich limitiert, allerdings recht grosszuegig und es gibt rechtzeitig eine Warnung. Ich will einfach nicht, das sich eine erste Vorschau-Version womoeglich ewig ohne Update haelt.
Meiner Meinung nach gibt es nur wenige Bereiche, wo korrekte Farben überhaupt eine Rolle spielen, wie z.B. in der Produktfoto- und -videografie.
In allen anderen Bereichen spielen Falschfarben heute ein viel größere Rolle, siehe div. Colorgradingmodelle.
Der hier besprochene Fall von Türkisverfärbungen im Himmel spielt neben inkorrekten Hautfarben allerdings eine Sonderrolle.
Im Normalfall allerdings können die Türkisfarben im Himmel durch eine blitzschnelle Korrektur im Waveformmonitor so halbwegs korrigiert werden, dazu braucht man kein VDUB.
Siehe folgende Korrektur im Waveformmonitor durch Herunterholen von 255 auf 235
domain hat geschrieben:Meiner Meinung nach gibt es nur wenige Bereiche, wo korrekte Farben überhaupt eine Rolle spielen, wie z.B. in der Produktfoto- und -videografie.
Selbst in den Bereichen, wo sowieso alles kuenstlerisch verfremdet und gegraded wird, besteht doch ein immenses Interesse an moeglichst gutem und naturgetreuem Ausgangsmaterial (man bedenke nur die Aufreger ueber Bitraten von Kameras und dem Sinn von RAW-Formaten) und letztlich auch daran, dass das fertige kuenstlerische Ergebnis auch moeglichst exakt bei der Vorfuehrung reproduziert wird.
domain hat geschrieben:
Im Normalfall allerdings können die Türkisfarben im Himmel durch eine blitzschnelle Korrektur im Waveformmonitor so halbwegs korrigiert werden, dazu braucht man kein VDUB
Das hat doch nichts mit VirtualDub zu tun. Die von mir gezeigte Korrektur laesst sich eben nicht blitzschnell mit den gaengigen Bordwerkzeugen durchfuehren, denn ich senke nicht einfach Werte pauschal ab und ich halte meine Korrektur auch fuer besser als nur "halbwegs" :-) Das Plugin ist fuer VirtalDub, damit moeglicht viele das umgesetzte Konzept unproblematisch ausprobieren koennen und weil nicht jede Plugin-Schnittstelle den Zugriff auf die YCbCr-Pixel erlaubt.
Ich zwinge natuerlich niemanden, das Maximum aus seinen Aufnahmen herauszuholen :-)
PS: Wenn Du Dein Beispiel als out-of-camera Datei hochlaedst, dann zeige ich mit Deiner Zustimmung hier im Forum mein Ergebnis, wenn Du daran Interesse hast und es nicht selbst ausprobieren moechtest.
Ich bezweifle in keiner Weise den Wert deiner VDUB-Implementation, gute Arbeit.
Aber der besagte Clip zeigt folgende Waveform. Nachdem die oberen Werte das 255-er Limit nicht nur tangieren, sondern streckenweise sogar richtig aufliegen, ist ein korrektes Blau gar nicht mehr zu erzielen.
Diesen Clip habe ich mit der XF100 und dem unbrauchbaren Cine-F-Profil aufgenommen.
Er zeigt aber, dass mit jeder Kamera (mit Ausnahme einiger DSLRs) solche Aufnahmen möglich sind, speziell bei den früheren Panas und grundsätzlich bei allen HX9V oder höher.
domain hat geschrieben:Aber der besagte Clip zeigt folgende Waveform. Nachdem die oberen Werte das 255-er Limit nicht nur tangieren, sondern streckenweise sogar richtig aufliegen, ist ein korrektes Blau gar nicht mehr zu erzielen.
Ich würde sagen, die oben abgebildete Waveform erklärt eine Menge clippendes Weiss im Bild, nicht aber Türkis.
Das stimmt schon. Türkis im Himmel entsteht im Grenzbereich: Blau clippt bereits, aber noch nicht die beiden anderen Kanäle. Insbesondere Grün befindet sich noch zwischen 235 und 255
In diesem Fall ist eine Verbesserung zwar möglich, aber sie gelingt nicht mehr vollständig.
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.
