Schau halt Dein Werkzeug mal an, es ist bestimmt alles da.
Du mußt Dich halt "reinfuchsen" in die Funktionalität des Programmes!
Ich arbeite mit Edius, Du reitest auf Vegas!
** S8-Hobbyfilmer seit 1970, Video seit 1988, Schmalfilmdigitalisierer seit 2007 **
** Aktuelle Hauptkameras: DJI Pocket 3 Gimbal-Kamera, Xiaomi 14T Pro und Sony ZV-1** http://www.videoundbild.de/
Na ja, das ist ja gerade fraglich, ob solche "hau ruck" Methoden besonders zielführend sind.
Im Interesse der Bildqualität wäre eine einwandfreie Konversion schon das Beste.
Aber in die Diskussion wollte ich eigentlich nicht neu einsteigen, das ist hier schon mal lang und breit diskutiert worden.
WoWu hat geschrieben:Mir geht es also zunächst einmal um die Ursache und erst in zweiter Linie um die korrekte Wandlung .
Und auch primär um die Werte "unten" denn dass man als Folge des Fehlers "oben" weiter raus muss, ist schon klar.
Meiner Auswertung nach will die Kamera Schwarz auf Y=16 (Unterschwinger unbenommen) legen.
Anmerkung: H.264 erlaubt es optional VUI Parameter zu übermitteln. Unter ihnen gibt es einen Flag, der "full range" kennzeichnet, außerdem können vordefinierte Primärfarben, Transferfunktion und Matrix-Koeffizienten übermittelt werden. Ich habe bisher nicht untersucht, ob die Datei VUI Parameter enthält.
Man darf bei diesen Überlegungen aber nicht vergessen, dass auch nach einem Absenken/Begrenzen von Luminanz auf 16-235 trotzdem noch in RGB nicht darstellbare YCbCr-Farbkoordinaten gibt.
Jan hat geschrieben:Also handelt es sich blöd gesagt bei dem Türkisstich einiger User um eine falsche Interpretierung der genutzten Software / des Players ?
Ja. Falsch ist aber zu hart, da keine bestimmte Vorgehensweise vorgeschrieben ist. Für das hier besprochene Beispiel trifft es ungünstig besser. Die Software benutzt einfach die Methode, die sich am schnellsten durchführen lässt. Solange keine Koordinaten weiter außerhalb des Bereichs darstellbarer RGB-Farben auftauchen, verursacht sie auch nur kleinere Unterschiede.
Jan hat geschrieben:Ich hatte nämlich nie diesen Türkisstich bei meinen eigenen Panasonic Aufnahmen betrachten können und das trotz Aufnahmen bei praller Sonne.
bArtMan hat geschrieben:Wie soll ich die denn bearbeiten/importieren, um das zu vermeiden.
Ich kann zum Verhalten einzelner Schnittprogramme und, falls das hier besprochene Problem auftritt, zu eventuellen Lösungsmöglichkeiten derzeit leider nichts sagen.
Ob man bei einigen Programmen, falls sie die hier besprochene Farbveränderung zeigen, mit einem Plugin weiterkommt, müsste von mir einzeln untersucht werden.
Vergleicht man, unabhängig von meinem Beispiel, einmal die Ausgabe von verschiedenen Wiedergabeprogrammen, dabei auch insbesondere mit unterschiedlichen Einstellungen bei der Hardwarebeschleunigung, dann bekommt man einen guten Eindruck, wie unterschiedlich bei den Umrechnungen von YCbCr nach RGB vorgegangen wird. Welche Variante dabei nun "besser" ist, dürfte für viele Benutzer nicht leicht zu entscheiden sein.
Bruno Peter hat geschrieben:Im Falle EDIUS einfach mit dem YUV-Korrekturwerkzeug behandeln!
Ich kenne dieses Korrekturwerkzeug nicht, ich vermute aber, dass es die drei Kanäle (Y, Cb, Cr) analog zu den bekannten RGB-Farbkurven-Effekten unabhängig voneinander verändert. In diesem Fall kann es leider nur Symptome mildern, jedoch keine eigentliche Problemlösung sein.
Der Grud ist, dass bei solch einem Vorgehen auch alle nicht betroffenen Pixel, die gar nicht angefasst werden müssten, verändert werden. Daher sollte dies nur als Hilfslösung verwendet werden.
Zuletzt geändert von TheBubble am So 04 Aug, 2013 00:47, insgesamt 2-mal geändert.
Man darf bei diesen Überlegungen aber nicht vergessen, dass auch nach einem Absenken/Begrenzen von Luminanz auf 16-235 trotzdem noch in RGB nicht darstellbare YCbCr-Farbkoordinaten gibt.
Das ist wohl richtig, spielen aber vermutlich erst bei den korrekten Farben eine übergeordnete Rolle. Hier gehet es ja noch mehr ums das "grobe".
Hast Du denn schon mal in Sektion 7 nachschauen können, wi das "vui_prameters_present_flag" steht ?
Ich kann mir heute kaum mehr vorstellen, dass das von irgend einem Hersteller nicht benutzt wird, weil ja der ganze Parametersatz in VUI übertragen wird.
Das wäre ja schonmal der erste Hinweis, denn wenn das VUI Flag auf 1 steht und video_full_range_flag auf 0, dann liegt das Problem bereits in Adobe Premiere.
Die beiden Flags wären also schon mal hochinteressant.
Ich erinnere mich, jemand hat doch auch den HDMI Test gemacht und da waren die Flags ja auch korrekt gesetzt. Kann also gut sein, dass die Kamera hier aussen vor ist, sobald die beiden Werte auch stimmen.
Man darf bei diesen Überlegungen aber nicht vergessen, dass auch nach einem Absenken/Begrenzen von Luminanz auf 16-235 trotzdem noch in RGB nicht darstellbare YCbCr-Farbkoordinaten gibt.
Das ist wohl richtig, spielen aber vermutlich erst bei den korrekten Farben eine übergeordnete Rolle. Hier gehet es ja noch mehr ums das "grobe".
Es kann trotzdem grobe Abweichungen geben, das muss man einfach mal an einem Beispiel durchrechnen:
Denken wir uns die Farbe Y=200, Cb=80 (+128), Cr=-80 (+128) aus, dann liegt jede der drei Komponenten für sich im zulässigen Wertebereich.
Das entspricht (BT.709-Transformation) der nicht darstellbaren Farbe R=76.8, G=222, B=345. (Nicht darstellbar aufgrund der zu hohen Blau-Komponente.) Begrenzen wir Blau auf 235, dann wurde der Farbton bereits auffällig verändert.
WoWu hat geschrieben:
Hast Du denn schon mal in Sektion 7 nachschauen können, wi das "vui_prameters_present_flag" steht ?
Leider nein. Ich suche noch nach einem Weg (mit möglichst wenig Aufwand oder neuer Software) zuverlässig an die Parameter zu gelangen, ohne selbst programmieren zu müssen.
Denken wir uns die Farbe Y=200, Cb=80 (+128), Cr=-80 (+128) aus, dann liegt jede der drei Komponenten für sich im zulässigen Wertebereich.
Das entspricht (BT.709-Transformation) der nicht darstellbaren Farbe R=76.8, G=222, B=345. (Nicht darstellbar aufgrund der zu hohen Blau-Komponente.) Begrenzen wir Blau auf 235, dann wurde der Farbton bereits auffällig verändert.
Aber da wären wir dann ja schon bei der Tranformation, also hinter der eigentlichen Kamera.
Ich würde (für mich) zunächst einmal gern die Fehlerquellen nacheinander ausschliessen und dann an der verbleibenden Fehlerquelle die Methoden untersuchen, um dann letztlich auch den Fehler festmachen zu können.
Ich hab das jetzt so verstanden, dass Du eine "PAL" Version in den Fittichen hast.
Ich muss dann mal sehen, ob ich noch irgendwo ein Signal aus einer "NTSC" Version bekomme, um auszuschliessen, dass es da noch Unterschiede oder andere Settings gibt.
Denn es gibt ja wohl auch einige Sony Kameras, die das auch unterschiedlich darstellen. Das kann ja irgendwie kein Zufall sein, dass einige Sonys das richtig und andere wieder falsch machen.
Aber lass uns erst mal die PANA abklären.
WoWu hat geschrieben:
Aber da wären wir dann ja schon bei der Tranformation, also hinter der eigentlichen Kamera.
Ich würde (für mich) zunächst einmal gern die Fehlerquellen nacheinander ausschliessen und dann an der verbleibenden Fehlerquelle die Methoden untersuchen, um dann letztlich auch den Fehler festmachen zu können.
Wenn ich es richtig verstehe, dann suchst Du den Grund, warum bzw. wie die Kamera diese YCbCr-Farben überhaupt erzeugt?
Jau, das sieht doch gut aus.
Damit wird der Strom korrekt signalisiert.
Hab ich eigentlich erwartet, weil HDMI auch richtig funktioniert hat.
Wenn das nun nicht noch an unterschiedlichen "Versionen" liegt, kann man sich eigentlich schon auf die Transformation konzentrieren.
War denn Dein Programmstrom (normal nach PP übertragen auch türkis ?
Mit andern Worten, haben wir es mit einem solchen "Fehler" zu tun ?
... Nee, die Erzeugung schliesse ich mal aus, weil das ein statisches Offset ist. Ich gehe davon aus, dass es aus der Übertragung bzw. beim Konvertieren nach RGB passiert.
WoWu hat geschrieben:War denn Dein Programmstrom (normal nach PP übertragen auch türkis ?
Mit andern Worten, haben wir es mit einem solchen "Fehler" zu tun ?
PP == Premiere? Keine Ahnung, habe ich hier nicht. Getestete Wiedergabesoftware zeigt aber auch den türkisen Farbton, der meinem Beispiel links entspricht.
Das Problem ist einfach, dass Software etwas tun muss, wenn sie YCbCr-Koordinaten wie in meinem Beispiel eben bekommt. Wie sie solche Fälle behandeln soll ist nicht festgelegt, beeinflußt aber das (subjektive) Ergebnis.
Ich bin der Meinung, es ist festgelegt, weil eben ein Interpretationsraum lediglich in der Wandlung von PbPr nach CbCr besteht, weil wir da noch im Wertebereich von 0;1 bzw. -0,5;+0,5 liegen.
Korrigier mich, wenn ich da falsch liege aber die Wertetransformation nach 709 ist eigentlich nur noch eine Umrechnung, mal von nicht signifikanten Veränderungen abgesehen. Und selbst wenn die Werte in der Kamera noch in 256 Werten vorliegen, verändert sich lediglich eine Konstante (*1/256)
Insofern weiss ich da im Augenblick nicht, wo die Variable im Ablauf liegt ?
Übersehe ich etwas ?
WoWu hat geschrieben:Korrigier mich, wenn ich da falsch liege aber die Wertetransformation nach 709 ist eigentlich nur noch eine Umrechnung, mal von nicht signifikanten Veränderungen abgesehen. Und selbst wenn die Werte in der Kamera noch in 256 Werten vorliegen, verändert sich lediglich eine Konstante (*1/256)
Insofern weiss ich da im Augenblick nicht, wo die Variable im Ablauf liegt ?
Übersehe ich etwas ?
Hinweis: Die von Dir angehängte Matrix kommt aus BT.601. Nur damit sich niemand wundert, wenn er damit mein Beispiel oben nachrechnet und andere Zahlen erhält.
Ja, Du übersiehst meinem Verständnis nach etwas.
Mit der RGB->YCbCr Matrix (egal ob nun aus 601 oder 709) führst Du erstmal nur einen Koordinatenwechsel durch. Soweit, so gut. Das ist (solange nicht gerundet oder auf ganze Zahlen quantisiert wird) auch reversibel.
Im RGB-Koordinatensystem benutzen wir für die RGB-Koordinaten tatsächlich nur einen kleinen Wertebereich, der würfelförmig ist. Seine Kanten sind parallel zu den Achsen des Koordinatensystems. Beim Koordinatenwechsel wird dieser Würfel gedreht und verzerrt.
Als nächstes wird auch der genutzte Wertebereich des YCbCr-Koordinatesystems auf einen Würfel begrenzt, dessen Kanten ebenfalls parallel zu den Achsen des Koordinatensystems liegen. Der gedrehte und verzerrte RGB-Würfel liegt beinahe vollständig innerhalb des neuen Würfels. Es gibt aber auch Koordinaten im YCbCr-Würfel, die nicht im verzerrten RGB-Würfel liegen.
Die Werte in dem YCbCr-Würfel werden nun auf ganzzahlige Tripel abgebildet und übertragen (das spielt für die Überlegungen hier keine Rolle).
Zum Vorgehen in folgender Situation steht in BT.709 jedoch nichts (oder ich habe es bisher übersehen):
Wenn eine YCbCr-Koordinate innerhalb des erlaubten würfelförmigen YCbCr-Wertebereichs liegt, aber nicht innerhalb des sich darin befindenen gedrehten und verzerrten RGB-Würfels, dann liegt sie auch nach der Rücktransformation ausserhalb des RGB-Würfels.
Solche Koordinaten sind das hier zu berücksichtigende Problem, wenn man sie darstellen will.
Noch zwei vereinfachte zweidimensionale Beispiele (siehe Anhang), die von der Problematik her ähnlich sind:
1. Durch den eingeschränkten Wertebereich für x,y, ist nicht jeder Ort mit x,y-Koordinaten erreichbar, der mit r,alpha-Koordinaten erreichbar ist.
Hat man nun r,alpha-Koordinaten im orangen Bereich und will diese mit x,y ausdrücken, dann geht das nicht. Behelfsweise kann man sie auf einen Punkt auf den Rand des Quadrats verschieben, wenn ein Verwerfen keine Option ist.
2. Im zweiten Beispiel ist es ähnlich. Nicht alle Punkte im xy-Quadrat liegen im kleineren und gedrehten ab-Quadrat.
Ich hoffe, dass es das ist, was Du übersehen hast. (Es hat eine Weile gedauert, die Erläuterung samt Beispielen zu schreiben.)
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
** S8-Hobbyfilmer seit 1970, Video seit 1988, Schmalfilmdigitalisierer seit 2007 **
** Aktuelle Hauptkameras: DJI Pocket 3 Gimbal-Kamera, Xiaomi 14T Pro und Sony ZV-1** http://www.videoundbild.de/
Du wirst doch noch in der Lage sein Dich dort anzumelden?
** S8-Hobbyfilmer seit 1970, Video seit 1988, Schmalfilmdigitalisierer seit 2007 **
** Aktuelle Hauptkameras: DJI Pocket 3 Gimbal-Kamera, Xiaomi 14T Pro und Sony ZV-1** http://www.videoundbild.de/
WoWu hat geschrieben:
Eher glaube ich auch, dass Adobe da Mist gebaut hat und die Signale falsch interpretiert. Für Adobe ist die anloge Welt eben noch quicklebendig.
Wolfgang,
a) das Bild wird von allen Softwareplayern identisch gezeigt.
Das hat nichts mit Adobe zu tun. Deine Vermutung ist falsch, wie sehr leicht bewiesen wer kann (einfach mal den Clip in einem Software-Player angucken)
b) Es ist auch kein Alleinstellungsmerkmal der X909.
Etliche Cams, darunter die X909, zeichen Y bis 255 auf.
Bei der RGB-Umsetzung am PC wird YCbrCr 16-235 auf RGB 0-255 gemappt.
Immerhin steht nun fest, dass Y tatsächlich 16-255 in diesem File ist.
Für andere Cams würden sich ähnliche Ergebnisse ergeben.
@ Reiner, ich will in die fruchtlose, gehabte Diskussion nicht wieder einsteigen.
Sie war nicht zielführend und wird es auch nicht werden.
@Bubble
Der Übergang von RGB nach YCC ist mir schon klar, und auch die damit zusammenhängende Problematik nur haben wir es hier damit nicht zu tun, weil wir keine RGB Signale aus der Kamera zu fassen bekommen, denn das sind bereits ins YCC Modell umgerechnet und wird im Datenstrom korrekt signalisiert. (video_full_range_flag : 0 )
Frage ist jetzt, warum versteht das eine Programm es richtig, HDMI Geräte auch, und andere Programme ignorieren die Flags und überführen das Signal nach RGB ohne die Flags zu beachten.
Seit Monaten die gleiche Diskussion um die Panasonic Camcorder und trotz vieler Profis hier im Forum immer noch kein Ende in Sicht? Es ist doch nun relativ Latte, ob ich die MTS Files vor dem Import in 16-235 umwandle oder im NLE die 255er Spitzen bis auf 235 herunterziehe.
Fakt ist, die Panasonic Files kann man entweder auf einer Wiedergabekette Nativ genießen, die den kompletten Tonwertumfang darstellen kann, oder man MUSS sie bearbeiten, wenn man einen Film draus schneiden möchte.
Von allen Camcordern oder Fotoknipsen die ich bereits besaß, hat das die Panasonic Reihe exklusiv.
Klar, wenn Du mit einem hauRuck Workaround leben kannst, kannst Du das natürlich so machen.
Es scheint Dir gar nicht bewusst zu sein, was Du dann mit dem Rest der Pixels eigentlich machst.
Aber mach mal, dann bist Du auf alle Fälle damit raus aus der Diskussion, denn den Ansatz gibt es zu tausenden in den Blogs, weil keiner nach der Lösung sucht. -aus welchem Grund auch immer-.
Hat aber auch eben nur die übliche Blog-Qualität.
Welche Programme verstehen das Original-Kameramaterial nicht richtig nach Eurer Erfahrung?
** S8-Hobbyfilmer seit 1970, Video seit 1988, Schmalfilmdigitalisierer seit 2007 **
** Aktuelle Hauptkameras: DJI Pocket 3 Gimbal-Kamera, Xiaomi 14T Pro und Sony ZV-1** http://www.videoundbild.de/
Reiner M hat geschrieben:
a) das Bild wird von allen Softwareplayern identisch gezeigt.
Probier doch mal diverse Abspielprogramme aus. Jeweils mit und ohne Hardwarebeschleunigung. Die Unterschiede sind nicht zu uebersehen.
WoWu hat geschrieben:
Frage ist jetzt, warum versteht das eine Programm es richtig, HDMI Geräte auch, und andere Programme ignorieren die Flags und überführen das Signal nach RGB ohne die Flags zu beachten.
Ich verstehe Dein Festhalten an den Flags nicht. Fuer das "Farbproblem" ist es doch egal, ob ein erweiterter Wertebereich genutzt oder nicht genutzt wird.
Ich habe gezeigt, dass man die Werte konvertieren kann, mit subjektiv besseren Ergebnissen. Ich habe erklaert, welche Pixel ich veraendere und warum. Viel mehr gibt es eigentlich nicht zu sagen.
Allenfalls die Frage, wann man dies praktisch anwenden kann, koennte fuer Benutzer noch interessant sein.
Nein, ganz so einfach ist es leider nicht, weil auch das nur ein (anderer) Workaround ist, aber nicht die Fehlerbeseitigung.
An die farbinterpretation muss man gar nicht mehr ran, weil die Festlegung im Übergang von RGB=> YPP bzw.YCC bereits vorgenommen ist und ja auch in Ordnung ist, wenn man die Werte wieder in die korrekten Bereiche zieht, sodass nichts mehr geclipoped wird.
Farbe ist also korrekt, sie liegt nur falsch im Wertebereich.
Daher ist die Signalisierung wichtig, weil nur sie dem Decoder mitteilt, was im Payload kommt und da wird gesagt:
"Du bekommst jetzt ein Nutzsignal im EINGESCHRÄNKTEN WERTEBEREICH
video_full_range_flag : 0 .
Das heist für den Decoder, erwarte Schwarz auf 16 und weiss auf 235.
Nun machen einige Programme das aber nicht ... Frage ist eben, warum.
Warum stellt z.B.PP ein analoges Signal da und setzt Schwarz mit einem OFFSET auf?
Was veranlasst PP dazu, dort ein analoges Signal zu interpretieren und dass dann 1:1 in das digitale Wertesystem zu übernehmen, also SW oberhalb von 16 zu starten.
Selbst wenn die Kamera über 235 aufnehmen würde, wäre das nicht so schlimm, weil sie dann nur heller wäre, aber es würde Blau nicht zum clippen bringen. Und das ist ja die Ursache für die Farbverfälschung.
Daher scheint doch entweder etwas an der Signalisierung oder an dessen "Verständnis" im NLE nicht zu stimmen.
Ich hatte damals so ein kleines Signalmuster von Reiner, das hab ich über Compressor nach ProRes gewandelt ... ging einwandfrei. In PP sah das dann wieder so aus, wie bei Reiner auch.
Ein Kollege hat die paar Frames mal in das Quantel geladen und nur kurz: "alles ok" zurück gemailed. Scheint also auch da zu funktionieren.
Irgendwo muss also ein Bug stecken und ich tippe mal auf die Signalisierung, denn der Payload ist ja ok. Er liegt nur falsch oder wird falsch interpretiert.
WoWu hat geschrieben:Nein, ganz so einfach ist es leider nicht, weil auch das nur ein (anderer) Workaround ist, aber nicht die Fehlerbeseitigung.
An die farbinterpretation muss man gar nicht mehr ran, weil die Festlegung im Übergang von RGB=> YPP bzw.YCC bereits vorgenommen ist und ja auch in Ordnung ist, wenn man die Werte wieder in die korrekten Bereiche zieht, sodass nichts mehr geclipoped wird.
Woher willst Du wisen, dass unser Ziel-RGB vom Farbumfang her nicht geringer als das Quell-RGB vor der Wandlung nach YCbCr ist?
WoWu hat geschrieben:
Nun machen einige Programme das aber nicht ... Frage ist eben, warum.
Warum stellt z.B.PP ein analoges Signal da und setzt Schwarz mit einem OFFSET auf?
Was veranlasst PP dazu, dort ein analoges Signal zu interpretieren und dass dann 1:1 in das digitale Wertesystem zu übernehmen, also SW oberhalb von 16 zu starten.
Frag die Entwickler. Niemand sonst wird das definitiv beantworten koennen.
WoWu hat geschrieben:
Selbst wenn die Kamera über 235 aufnehmen würde, wäre das nicht so schlimm, weil sie dann nur heller wäre, aber es würde Blau nicht zum clippen bringen. Und das ist ja die Ursache für die Farbverfälschung.
Das Clippen ist nur die Ursache, weil man nicht einfach clippen darf. Rechne meine Beispielwerte mal per Hand nach. Stelle dir die Farbraume mal grafisch in Bezug zueinander vor. Ueberlege, weche Alternativen eine Software hat, wenn sie entsprechende YCbCr-Werte vorgesetzt bekommt und darstellen muss. Tu dabei ruhig so, alsob alles korrekt signalisiert wurde, aber rechne ein Beispiel durch. Kannst die Rechnung auch gerne posten.
Woher willst Du wisen, dass unser Ziel-RGB vom Farbumfang her nicht geringer als das Quell-RGB vor der Wandlung nach YCbCr ist?
Weil alles stimmt, sobald Du das OFFSET abstreifst. An den Räumen veränderst Du damit ja nichts, nur an der Lage.
Das Clippen ist nur die Ursache, weil man nicht einfach clippen darf. Rechne meine Beispielwerte mal per Hand nach.
Aber das heisst doch, dass "unter dem Clip" alles in Ordnung ist und nicht das Signal gefärbt ist, weil die Kamera es so (interpretierte)/ hergibt, sondern weil das NLE es durch den Clip so hinzaubert.
Aber gerade da stellt sich eben die Frage, warum einige NLEs das anders machen.
Zumal Gamut ebenso korrekt signalisiert wurde (siehe HDMI) und die Farbgewichtung eigentlich schon im de-bayering festgelegt wird und nachfolgend im Grunde nur noch umgerechnet wird.
Eine solche "Farbgestaltung" findet im Prozessweg (ohne Farbkorrektur) eigentlich gar nicht mehr statt.
Findet sie dennoch statt, ist das ein Bug, weil das nicht vorgesehen ist.
Irgendwas wird an dem Stream falsch (oder gar nicht) interpretiert, da bin ich mir ziemlich sicher.
WoWu hat geschrieben:Weil alles stimmt, sobald Du das OFFSET abstreifst. An den Räumen veränderst Du damit ja nichts, nur an der Lage.
Welchen Offset möchtest Du denn wo konkret abstreifen? 16 von allen Y-Werten subtrahieren?
WoWu hat geschrieben:
Eine solche "Farbgestaltung" findet im Prozessweg (ohne Farbkorrektur) eigentlich gar nicht mehr statt.
Findet sie dennoch statt, ist das ein Bug, weil das nicht vorgesehen ist.
Clippen ist auch eine Farbgestalltung. Solche Prozesse haben auch eher wenig mit der üblichen Farbkorrektur zu tun. Sie sind bei Farbraumwandlungen einfach erforderlich, wenn der Zielfarbraum nicht vollständig innerhalb des Quellfarbraums liegt.
WoWu hat geschrieben:Klar, wenn Du mit einem hauRuck Workaround leben kannst, kannst Du das natürlich so machen.
Es scheint Dir gar nicht bewusst zu sein, was Du dann mit dem Rest der Pixels eigentlich machst.
Aber mach mal, dann bist Du auf alle Fälle damit raus aus der Diskussion, denn den Ansatz gibt es zu tausenden in den Blogs, weil keiner nach der Lösung sucht. -aus welchem Grund auch immer-.
Hat aber auch eben nur die übliche Blog-Qualität.
Irgendwann muss man ja mal anfangen, sich mit seiner Kamera zu arrangieren. Wenn man wartet, bis dieses Forum eine Lösung herausgearbeitet hat, lagert schon tonnenweise Material auf der Platte, das man eigentlich schon geschnitten haben wollte. Außerdem ist jedes zusätzliches Umwandeln auch eine Hauruckmethode, mit der ich auch nicht Leben möchte.
Es geht ja eben gerade darum, nicht umzuwandeln. Das macht das NLE ja schon und versaut das Signal damit erst.
Denn wie Du sehen kannst, kommt es offenbar sauber aus der Kamera, sowohl nach HDMI, als auch offenbar im Datenstrom.
Und wenn in diesem Forum soviel Zeit verschwendet wird, wie bisher in den Blogs und den Foren diesem Thema geopfert wurde, dann könnten wir uns erst nochmal entspannt zurücklehnen.
Bisher hat doch noch niemand systematisch gesucht und alle nur schlaue Tipps für Workarounds gegeben.
Welchen Offset möchtest Du denn wo konkret abstreifen? 16 von allen Y-Werten subtrahieren?
Wenn ich sehe, dass im NLE eine analoge Abhebung nicht nur im Waveform angezeigt wird, (was ja auch ein Messfehler sein könnte), aber leider auch das Bild entsprechend aussieht, dann übernimmt das NLE den Wert 16 nicht korrekt. Entsprechend sieht ja auch 235 aus, das brachial nach oben verschoben wird.
ich weiss nun nicht, welche Werte im NLE daraus entstehen und wohin die transformiert werden, ich hab es jedenfalls mit der 7,5 IRE Korrektur bei PP alles in die Reihe bekommen. Was das für die digitale Wertetabelle heisst, weiss ich so aus dem Kopf. Man müsste die PP Werte mal irgendwie zu fassen bekommen.
Übrigens sieht auch alles sauber aus, wenn man das Programm zwangsweise (manuell) auf die Werte (16/235) setzt.
Wenn das PP aufgrund der Signalisierung alleine täte, wäre alles paletti.
Machen sie aber nicht.
Muss man von Hand machen.
Entweder kriegt das Programm die Signalisierung nicht, liest sie nicht aus oder interpretiert sie falsch.
Dass sie da ist, haben wir gesehen. Und das andere Programme das können, auch.
WoWu hat geschrieben:Wenn ich sehe, dass im NLE eine analoge Abhebung nicht nur im Waveform angezeigt wird, (was ja auch ein Messfehler sein könnte), aber leider auch das Bild entsprechend aussieht, dann übernimmt das NLE den Wert 16 nicht korrekt. Entsprechend sieht ja auch 235 aus, das brachial nach oben verschoben wird.
Mir ist es zunächst egal, was diverse NLEs und Wiedergabeprogramme machen, ich interessiere mich nur dafür, wie Du von den Rohdahten aus vorgehen möchtest. Bitte schlage eine konkrete Umrechungsvorschrift (incl. der Behandlung aller eventuellen Sonderfälle in den Einganbedaten) YCbCr nach RGB vor, am Besten mit vorgerechnetem Beispiel, um Missverständnisse zu vermeiden.
Das muss ich gar nicht vorschlagen... der ColorSpaces vom YCC steht spätestens im REC 709 nachzulesen.
Frage ist eben nur, wie der Farbraum im NLE definiert ist.
Ich gehe aber auch davon aus, dass es einem Standard entspricht.
Insofern bestehen da überhaupt keine Sonderwünsche, ganz im Gegenteil. Eigentlich ist zu klären, warum solche Standarverhalten (die es sein sollten) zu so einem Ergebnis führen.
Man müsste mal ein Bild von YCC=>RGB (über PP)=> YCC rechnen und sehn, ob die (quasi) identischen Werte dabei wieder herauskommen.
Denn streng genommen dürften ja nur in Y ein paar Levelshifts vorkommen.
Ich tippe mal drauf, da kommen Bananenwerte bei raus.
Damit hätte man dann auch die Ursache.
WoWu hat geschrieben:Das muss ich gar nicht vorschlagen... der ColorSpaces vom YCC steht spätestens im REC 709 nachzulesen.
Doch musst Du, denn Du beharrst darauf, von Dir nicht klar definierte Offsets anzuwenden zu wollen. Auch bestreitest Du, dass die "problematischen" Farben im konkreten Beispiel nicht ursprünglich zu YCbCr-Koordinaten gehören, die nicht in RGB(709) darstellbar sind - zumindest solange man vorher diesen von Dir nicht klar definierten Offset anwendet.
Schaffe daher bitte anhand eines konkreten Beispiels Klarheit.
Ich hatte angenommen, dass Du so ein Kamerasignal mal in PP einfüttern kannst, um die Ergebnisse zu analysieren.
Aber, wie Du sagst, kannst Du das gar nicht.
So bleibt die Diskussion natürlich theoretisch.
Um jetzt nachzuvollziehen, was Adobe da macht, ist die Theorie natürlich wenig effektiv.
Und was herauskommt, wenn ich zwei Standardtransformationen am Schreibtisch durchführe, dazu brauche ich eigentlich keinen externen Input.
Das macht mein Rechner von allein, wenn ich ihm die Parameter gebe.
Hier geht es aber um ein paar Unbekannte, die eine externe Software hinzufügt.
Die kann man aber auf dem einfachsten Weg ermitteln, indem man sie ausliest.
Aber wenn Du den Fehler Vorort nicht einmal sichtbar machen kannst, ist das schwer.
Wie gesagt, ich dachte, Du seist dafür ausgerüstet.
Die Offset Grössenordnung hab ich Dir übriges oben gegeben. Wenn ich die exakten Werte kennen würde, könnte ich sie auch selbst einfügen. Aber die kennt eben nur PP, oder ein Anwender, der sie mal kurz auslesen kann.
Wie gesagt, es geht mir hier nicht um Farbcorrekturen und deren verfahren, sondern um die Ermittlung eines Fehlers.
Vermutlich unterscheiden sich hier unsere Ansätze.
Workarounds gibt es ja offenbar ausreichend.
Dann landen wir hier wahrscheinlich (mangels Hard/Software) in einer Sackgasse.
Ich habe das Gefühl, wir reden beide über andere Dinge. Ich über die interessante Sache der tatsächlich aufgezeichneten Daten und deren Darstellung am PC (mit eigener Software), Du über das Verhalten Deines Schnittprogramms.
Und nein, ich habe hier zu Hause kein Premiere Pro CC und plane dies aufgrund des Abo-Angebots derzeit auch nicht anzuschaffen. Ich habe auch nie gegenteiliges behauptet oder angeboten, dass Verhalten des Programms zu untersuchen.
Und ja, es ist interessant die Transformation selbst durchzuführen, denn erst dann wird einem klar, wie die Praxis aussieht und mit welchen besonderen Fällen man rechnen muß.
Und ja, ich habe Zugriff auf die Rohdaten (MTS-Datei und dekomprimiertes YCbCr-Frame) und kann deshalb hoffentlich alle interessanten Fragen über diese Daten beantworten. Dazu brauche ich keine bestimmte Schnittsoftware.
Die von mir gezeigten Varianten (links und rechts in der Bitmap) sind das Ergebnis meiner eigenen Software zur Wandlung von YCbCr nach RGB.
Wenn es mir gelingt die Rohdaten (YCbCr) zufriedenstellend nach RGB(709) oder sRGB umzurechnen und das Ergebnis anderen auch zusagt, was scheinbar der Fall ist, dann bin ich zufrieden.
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.
