Infoseite // Panasonic HC-X 909 und Slashcam Test

Frage von -paleface-:


Hallo,
ich wollte mir die Panasonic HC-X 909 als "für mal eben rasch was filmen" kaufen.
Nun stand ich gestern bei Saturn (720€ günstiger als im Web) und hatte das Teil in der Hand.
Nun schau ich in die Einstellungen und sehe dass man wohl mit NUR 50p und 50i filmen kann + iframe.

Beim Camcorder Vergleich von Slashcam steht aber auch noch 25p.

Hab mir dann zu Hause das Handbuch runter geladen und auch dort steht nix neues.

Meine Frage nun, kann man auch mit 25p filmen?
Und kann man wie bei einer DSLR auch auf NTSC schalten? Weil in der Tabelle steht gar dass dort 24p möglich ist.

Bye



Antwort von TheBubble:

Nun schau ich in die Einstellungen und sehe dass man wohl mit NUR 50p und 50i filmen kann + iframe.

Beim Camcorder Vergleich von Slashcam steht aber auch noch 25p. 25fps gehen. Die Einstellung wird im Menü aber nicht als 25p oder 25fps bezeichnet, sondern wird "Digital Cinema" genannt und ist nur anwählbar, wenn vorher ein i-Format ausgewählt wurde.
Hab mir dann zu Hause das Handbuch runter geladen und auch dort steht nix neues. Genau das steht auch im Handbuch.
Und kann man wie bei einer DSLR auch auf NTSC schalten? Leider nein.
Weil in der Tabelle steht gar dass dort 24p möglich ist. Mit der NTSC-Variante der Kamera gehen 24fps, vermutlich als i-Format verpackt.



Antwort von -paleface-:

Hmm danke erst einmal.

In der Slashcam Tabelle steht aber 1920*1080 bei 25fps.
Das IFormat ist ja nur 960*540px.

Oder liege ich falsch?



Antwort von TheBubble:

In der Slashcam Tabelle steht aber 1920*1080 bei 25fps.
Das IFormat ist ja nur 960*540px.

Oder liege ich falsch? Es geht wirklich in HD, ich meine damit nicht das iFrame Format (entschuldige, wenn ich mich missverständlich ausgedrückt habe, mit i-Format meinte ich ein Interlace-Format, nicht iFrame).

Stelle zuerst den Manuellen Modus ("MNL") und dann als Aufnahmemodus ein Interlace-Format, z.B. HA1920 ein. Gehe dann in das Menü und aktiviere unter den Aufnahmeeinstellungen ("Record Setup") die Option "Digital Cinema" (nicht mit der Option "Digital Cinema Colour" verwechseln!). Das entsprechende Symbol erscheint nun im Display, solange der Modus aktiv ist.



Antwort von -paleface-:

Ah ok.

Also geht nur 25i nicht 25p?

Hmm.....eigentlich schade!



Antwort von TheBubble:

Also geht nur 25i nicht 25p? Damit es kein Missverständnis gibt: 25i (auch manchmal als 50i bezeichnet) sind 50 Fields, verpackt in 25 Interlace-Frames. 25p wären für mich volle 25 Frames, d.h. keine Fields.

Die Kamera macht AFAIK die 25fps indem sie 25p in 25 Interlace-Frames verpackt. D.h. Du wirst der Schnittsoftware unter Umständen sagen müssen, dass sie es als 25p interpretieren soll. Es sind aber trotzdem volle 25 Frames, die herausgeholt werden können.



Antwort von Skeptiker:

Theorie zu 'fps' (Progressive Segmented Frame) z. B. hier:
http://de.wikipedia.org/wiki/Progressiv ... nted_Frame

Von Canon Camcordern (HF G10) ist diese Methode, 25p zu speichern, bekannt, ob Panasonic sie bei der X909 (ich habe eine, filme aber mit 50p) auch anwendet, müsste ich nachsehen/ausprobieren.

Aber TheBubble hat's wohl schon getestet und beschreibt ja, wie man es einstellt.

Der Unterschied:
25 Bilder interlaced wären 50 Halbbilder pro Sekunde. Zeitlich aufgelöst also 50 Bewegungsphasen pro Sekunde.
25 Bilder progressive als fps wären ebenfalls 50 Halbbilder pro Sekunde. Aber zeitlich aufgelöst nur 25 Bewegungsphasen pro Sekunde, da immer 2 Halbbilder denselben Zeitpunkt darstellen.



Antwort von -paleface-:

Ich bin noch immer leicht skeptisch.

Hier
http://www.amateurfilm-forum.de/technik ... on-hf-g10/

Sagen sie wiederum es geht nicht.
Im Handbuch steht über den Cinema Modus 3 Zeilen. Und Null infos was das genau ist.

Denke muss nochmal in den Saturn und einfach was auf eine Karte aufzeichnen.



Antwort von Jan:

Komisch das beispielsweise der VLC Player bei Digital Cinema Material auch 50i anzeigt, genau wie bei gleicher HA Qualität ohne Digital Cinema.

Windows (Eigenschaften) meint bei beiden Filmen übrigends das es angeblich 25 P Bildmaterial sein soll.


Es ist wohl eine Interpretation des Players / Schnittprogrammes, was da wirklich anliegt.


Panasonic spricht zumindest nirgendwo von 25 P.


VG
Jan






Antwort von -paleface-:

Hab in einem Englischen Forum gelesen das der Cinema Modus eher was mit der Aufmachung des Bildes zu tun hat.
Wobei es sich da um einen älteren Panasonic Camcorder gedreht hat.

Kennt denn jemand zufällig einen anderen Camcorder in der Preisregion der wirkliches 25p kann? Oder gar 24p?

Nur mal damit ich einen Vergleich habe und zur not eine B-Auswahl.



Antwort von Jogi:

...Kennt denn jemand zufällig einen anderen Camcorder in der Preisregion der wirkliches 25p kann? Oder gar 24p?.. Die meisten Hersteller verzichten bei den kleinen Consumermodellen auf 25p. Es bringt auch nix wenn bei einer Framerate von 25 Vollbidern aus der Hand gefilmt wird. Dafür sind 50p besser geignet. Ich frage mich ernsthaft was du mit 24p anfangen willst wenn nicht gerade für's Kino gedreht wird. Aber auch in Hollywood werden mittlerweile 24 Bilder in Frage gestellt. J. Cameron will zukünftig nicht mehr mit diesen Framerates drehen wie unlängst zu lesen war.



Antwort von WoWu:

Mit der NTSC-Variante der Kamera gehen 24fps, vermutlich als i-Format verpackt. Gibt es von der Kamera unterschiedliche Versionen ?

@The Bubble

OT
Konntest Du schon einmal ein Frame aus Reiners Kamera analysieren ?
Ich wäre an den Ergebnissen interessiert, zumal ich hier nun höre, es gibt ggf. eine NTSC Version.

OT off



Antwort von TheBubble:

Gibt es von der Kamera unterschiedliche Versionen ? Ja, AFAIK zwei Hauptversionen ("PAL" und "NTSC"), zzgl. von Unterversionen (mir sind bekannt: mit internem Speicher HC-X900M, ohne Speicher HC-X900 bzw. HC-X909). Ob es zwischen den Hauptversionen Hardwareunterschiede gibt: Keine Ahnung.
@The Bubble

OT
Konntest Du schon einmal ein Frame aus Reiners Kamera analysieren ?
Ich wäre an den Ergebnissen interessiert, zumal ich hier nun höre, es gibt ggf. eine NTSC Version.

OT off Ich habe von ihm leider nichts mehr gehört und auch keine vom ihm beanstandete Aufnahme von ihm bekommen. Daher habe ich diese Woche an einem sonnigen Tag selbst Probeaufnahmen gemacht, für die ich den Himmel möglichst türkis bekommen wollte (was ja der Kritikpunkt war).

Soweit so gut, eine erste Auswertung der 4:2:0-YCbCr-Daten eines Intra-Frames (d.h. vor der Umwandlung zu RGB, die ursprüngliche Datei habe ich zunächst ohne weitere Software direkt von der Speicherkarte entnommen) habe ich gemacht. Dies lieferte aber ein zunächst überraschendes Ergebnis, weswegen ich nächste Woche noch weiter auswerten will. Auch möchte ich der Vollständigkeit halber noch ausprobieren, ob die zur Kamera mitgelieferte Software einen Unterschied gegenüber dem direkten Entnehmen der Dateien von der Speicherkarte macht.



Antwort von WoWu:

Danke für die Info.
Wenn Du Erkenntnisse hast, wäre ich Dir für ein Mail ausgesprochen dankbar.



Antwort von -paleface-:

...Kennt denn jemand zufällig einen anderen Camcorder in der Preisregion der wirkliches 25p kann? Oder gar 24p?.. Die meisten Hersteller verzichten bei den kleinen Consumermodellen auf 25p. Es bringt auch nix wenn bei einer Framerate von 25 Vollbidern aus der Hand gefilmt wird. Dafür sind 50p besser geignet. Ich frage mich ernsthaft was du mit 24p anfangen willst wenn nicht gerade für's Kino gedreht wird. Aber auch in Hollywood werden mittlerweile 24 Bilder in Frage gestellt. J. Cameron will zukünftig nicht mehr mit diesen Framerates drehen wie unlängst zu lesen war. Was Hollywood macht interessiert mich nicht :-D
Ich persönlich mag dieses 50p gefilme NULL!

Und warum soll man damit nicht aus der Hand filmen können?



Antwort von Skeptiker:

@-paleface-:

Es ist tatsächlich so, dass die besten Consumer Videokamera von Panasonic, Canon, Sony in der PAL-Ausführung kein 24p können, die NTSC-Versionen hingegen schon (welche genau, sagen die Datenblätter). Aber die können dann auch nur 30i(=60i)/30p/60p.
Bei den DSL(R)s sieht es teils anders aus (Bsp. GH3, Canon 650D).

P.S.: Die neue Canon HF G30 scheint 1080/25p als MP4 zu bieten. Aber die ist natürlich nicht so kompakt wie eine Pana X909 und etwa doppelt so teuer.



Antwort von -paleface-:

Also auf 24p kann ich noch verzichten.
Aber 25 wären schon schön.

Verstehe ich nicht warum sowas nicht angeboten wird. ging doch früher auch immer.



Antwort von Skeptiker:

Verstehe ich nicht warum sowas nicht angeboten wird. ging doch früher auch immer. Verstehe ich auch nicht.
Sparmassnahmen ? Oder am Ende pure Idiotie ??






Antwort von TheBubble:

Danke für die Info.
Wenn Du Erkenntnisse hast, wäre ich Dir für ein Mail ausgesprochen dankbar. Ein kurzes Update: Ich bin dran geblieben und mit der Untersuchung so gut wie fertig, ich müsste die Ergebnisse aber noch so zusammenfassen, dass es für das Forum geeignet ist, wenn ich sie ins Forum schreiben sollte.



Antwort von WoWu:

Alles klar, vielen Dank.



Antwort von TheBubble:

Zwischendurch schon mal ein erstes Ergebnis:

Die rechte Hälfte des Beispiels (siehe Anhang) zeigt hellblaue Farben und entspricht der Erwartung, die linke Hälfte zeigt grünblauen Farbflächen, die vermutlich die gleiche Ursache haben wie die Farben, die anderen Forumsteilnehmern auffielen. Beides ist das gleiche Frame, von mir jedoch unterschiedlich nach RGB gewandelt.

Es handelt sich um keine manuelle Farbkorrektur der RGB-Bitmap, auch in der rechten Hälfte könnten grünblaue Farben dargestellt werden, falls sie vorhanden wären.

(Schwarz und weiß habe ich bei der RGB-Bitmap in beiden Hälften auf 0 bzw. 255 angepasst, die Transferfunktion allerdings nicht verändert.)

Ich finde, dass man an dem hellen Blau rechts nichts aussetzen kann.



Antwort von domain:

Unterschiedlich sagt ja nicht viel.
Was hast du da unterschiedlich behandelt?



Antwort von WoWu:

@Bubble

zunächst mal schoenen Dank. Ich hab das jetzt so verstanden, dass es bisher lediglich unterschiedliche Wandelmethoden nach RGB waren.

Kannst Du was zur Wertebelegung der Kamera sagen, wo die beiden Endwerte (sw/ws) liegen?
Mich interessiert, ob es tatsächlich NTSC Varianten an Kameras gibt, die von dem eigentlichen Wertebereich abweichen, wenn ja, wohin.
Mein Verständnisdefizit besteht darin, dass bei einem Offset unter Einbehaltung der weisswerte, das NTSC Signal nur 661mV wäre.
Daher denke ich, dass die Info, wo die Werte vom Kamerahersteller untergebracht sind, ein Schritt wäre, das zu klären.

Ich habe da versucht, weitere Infos zu finden, aber es gibt einfach nichts substatielles. Nur so Bloggeschwafel, aber nichts Belastbares.

Aber nochmal, herzlichen Dank zunächst.



Antwort von TheBubble:

Unterschiedlich sagt ja nicht viel.
Was hast du da unterschiedlich behandelt? Es gibt im YCbCr-Farbmodell Farben, die nicht im zur Darstellung am PC-Monitor verwendeten RGB-Rarbraum vertreten sind.

Um die Bitmap an all diesen Stellen nicht undefiniert (z.B. transparent) lassen zu müssen, muss man diese Farben durch darstellbare Farben ersetzen. Die dafür verwendete Methode ist unterschiedlich.

Bei den zu ersetzenden Farben muss es sich nicht um hellblau handeln, es können auch völlig andere Farbtöne sein (und sind es je nach Motiv auch).
zunächst mal schoenen Dank. Ich hab das jetzt so verstanden, dass es bisher lediglich unterschiedliche Wandelmethoden nach RGB waren. Die grundlegende Methode ist bei beiden Varianten die in BT.709 beschriebene Transformation. Die Behandlung nicht darstellbarer Farbkoordinaten erfolgt jedoch unterschiedlich.
Kannst Du was zur Wertebelegung der Kamera sagen, wo die beiden Endwerte (sw/ws) liegen? Ich habe schon ein Histogramm und weitere Beispiele vorbereitet (die auch "superweiß" zeigen), wollte das aber für alle übrigen Forums-Leser nicht völlig ohne Erklärung posten. Vielleicht schaffe ich es die Tage, das fertig zu stellen.

Vorab: Der Y-Kanal beginnt bei einem schwarz von 16 und belegt Werte bis 255. Wobei mir derzeit bei den verwendeten Motiven - rein subjektiv - eine Umwandlung mit weiß bei ursprünglich 235 (für R, G und B) am besten gefällt (was auch dem Standard entspricht). Dies habe ich auch für die obige Umwandlung so gemacht.

Die zusätzlichen Werte sind aber für eine eventuelle Nachbearbeitung interessant.

Wie gesagt, ich wollte eigentlich noch mehr Ergebnisse posten. Vielleicht eher unter der Rubrik Postproduktion, da ich vermute, dass es auch für Besitzer völlig anderer Kameras interessant ist.

Daher bin ich grundsätzlich auch an kurzen Beispieldateien anderer Kameras interessiert, insbesondere auch von Geräten aus dem High-End Bereich.
Mich interessiert, ob es tatsächlich NTSC Varianten an Kameras gibt, die von dem eigentlichen Wertebereich abweichen, wenn ja, wohin.
Mein Verständnisdefizit besteht darin, dass bei einem Offset unter Einbehaltung der weisswerte, das NTSC Signal nur 661mV wäre.
Daher denke ich, dass die Info, wo die Werte vom Kamerahersteller untergebracht sind, ein Schritt wäre, das zu klären. Ich vermute, dass der Unterschied bei den NTSC-Varianten in den Frameraten und der Ausgabe eines analogen NTSC-Signals an entsprechenden Anschlüssen liegt. Auch nach meinem derzeitigen Verständnis der relevanten Normen dürfte sich die digitale Repräsentation nicht unterscheiden. Definitiv kann ich aber nichts sagen, ich hatte die NTSC-Variante nie zur Verfügung.



Antwort von Reiner M:


Vorab: Der Y-Kanal beginnt bei einem schwarz von 16 und belegt Werte bis 255. Das überrascht nicht. Es entspricht dem, was die Waverform-Monitore zeigen, wie schon an anderer Stelle ausgeführt. Andere Eregbnisse wären überraschend.
Wobei mir derzeit bei den verwendeten Motiven - rein subjektiv - eine Umwandlung mit weiß bei ursprünglich 235 (für R, G und B) am besten gefällt (was auch dem Standard entspricht). Dies habe ich auch für die obige Umwandlung so gemacht. Meint das jetzt, Du hast die Lumawerte nach unten korrigiert, um ein "am besten gefällt"-Bild zu erhalten?
(Unabhängig davon, ob Du das direkt im Luma-Kanal machst oder durch die Nutzung anderer Koeffizienten bzw. Wertetabellen bei der yuv2rgb-Wandlung).
Wie gesagt, ich wollte eigentlich noch mehr Ergebnisse posten. Vielleicht eher unter der Rubrik Postproduktion, da ich vermute, dass es auch für Besitzer völlig anderer Kameras interessant ist. Ist es, meine ich.
Ich würde jedoch statt "interessant" eher "wichtig" sagen.

Beste Grüße,
Reiner



Antwort von TheBubble:

Meint das jetzt, Du hast die Lumawerte nach unten korrigiert, um ein "am besten gefällt"-Bild zu erhalten?
(Unabhängig davon, ob Du das direkt im Luma-Kanal machst oder durch die Nutzung anderer Koeffizienten bzw. Wertetabellen bei der yuv2rgb-Wandlung). Nein, beide gezeigten Umrechnungen von YCbCr nach RGB sind nach BT.709 erfolgt. Das danach ggf. erforderliche Behandeln nicht darstellbarer Farben erfolgte unterschiedlich. Da die ueberwiegende Mehrheit hier jedoch mit sRGB Monitoren das Forum liest, habe ich fuer den richtigen Kontrast zuletzt 16-235 auf 0-255 gestreckt (die Transferefunktion aber vorerst noch unveraendert gelassen). Interessehalber habe ich auch andere abweichende Varianten ausprobiert, diese haben mir jedoch subjektiv nicht so zugesagt.



Antwort von WoWu:

Moin Bubble,
schönen Dank für dir Zwischenmeldung.
ich stimme mit Dir überein dass die Repräsentanz bei allen Normen 16/235 sein müsste und das Offset dann jeweils an den analogen Componenten vorgenommen wird.
Einige Hersteller scheinen aber die 7,5 IRE Reglung falsch zu verstehen und arbeiten sie als Wert 32 in ihr Signal ein ... mit den entsprechenden Folgen, auch im oberen Bereich. Dann müssen sie nämlich in den Raum oberhalb von 235 weil ihr Signal sonst nur 661 mV beträgt und keine 700mV.
Frage ist bei der 909 also ob die Repräsentanz im korrekten Bereich dargestellt ist oder davon abweichend.
In dem Fall (korrekt) macht Premiere nämlich den Wandelfehler und arbeitet die 7,5 in das Arbeitssignal ein. (grad so, als würden wir noch analog arbeiten- da wäre das nämlich korrekt- vielleicht zeigen sie ja deswegen eine Analogskale an).
Ansonsten, wenn die Kamera es mit einem Offset (32) versieht, wäre das ein falsches Verständnis der (7,5) Reglung.
Mich interessiert eigentlich nur, ob die Kamera den Fehler macht oder PP, wobei selbst dann PP noch einwenig versagt, weil sie den Fehler erkennen und korrigieren müssten.
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.






Antwort von Jan:

Also handelt es sich blöd gesagt bei dem Türkisstich einiger User um eine falsche Interpretierung der genutzten Software / des Players ?


Ich hatte nämlich nie diesen Türkisstich bei meinen eigenen Panasonic Aufnahmen betrachten können und das trotz Aufnahmen bei praller Sonne.



Das wäre ja mal eine Entdeckung Jungs !



VG
Jan



Antwort von WoWu:

@ Jan

Es kommt jetzt einwenig darauf an, wo panasonic die Werte hingelegt hat.
In der Tat gibt es ein paar Firmen, die das in NTSC Versionen falsch umgesetzt haben. JVC hat das in den ersten Kameras der 100er Serie auch falsch gemacht und dann mit einem Firmwareupdate schnell wieder beseitigt und das Offset auf die analogen Ausgänge gelegt, was dann ja auch korrekt war.
Aber so ganz kann ich das von Panasonic nicht glauben.
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.

Na, bei UHD ist dann ja endgültig alles vorbei und endlich mal geklärt.
Dann gibt's wahrscheinlich auch keine europäischen Formate mehr. Mal abwarten, ob da noch was kommt.



Antwort von bArtMan:

Bei meiner X909 habe ich auch öfter einen Türkisstich. Ich nutze die kopierten Originalfiles mit Vegas 10. Wie soll ich die denn bearbeiten/importieren, um das zu vermeiden.



Antwort von WoWu:

Warte mal ab, was Bubble jetzt herausfindet.
Man muss die Sache erst einmal auf eine solide Basis stellen und schaun, wie die Signale in der Kamera übertragen werden.
Alles Andere wäre wieder Internetspekulation, davon gibt es tausende im Netz aber mindestens ebenso viele tolle Vorschläge.



Antwort von bArtMan:

Alles klar. Ich dachte, er hätte schon die Lösung.



Antwort von WoWu:

Die Lösung ist schon klar, aber die Ursache noch nicht.
Wichtig ist nur zu wissen, dass die Kamera die Aufnahmen nicht "versaut". Nun muss man nur noch sehen, an welcher Stelle der "Mist" gebaut wird.
Die Lösung ist dann die korrekte Konversion ... nur dazu muss man eben wissen, wie das Signal anliegt, damit man den Weg weiss, um es korrekt ans Ziel zu bringen.



Antwort von Bruno Peter:

Bei meiner X909 habe ich auch öfter einen Türkisstich. Ich nutze die kopierten Originalfiles mit Vegas 10. Wie soll ich die denn bearbeiten/importieren, um das zu vermeiden. Im Falle EDIUS einfach mit dem YUV-Korrekturwerkzeug behandeln!



Antwort von bArtMan:

Und in Vegas?



Antwort von Bruno Peter:

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!






Antwort von WoWu:

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.



Antwort von bArtMan:

Genau diese Korrektur finde ich besser als die Standardverfahren. Den Himmel bekomme ich schon blau aber ist irgendwie Gefrickel.



Antwort von TheBubble:

Hallo WoWu,
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.



Antwort von TheBubble:

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.
Ich hatte nämlich nie diesen Türkisstich bei meinen eigenen Panasonic Aufnahmen betrachten können und das trotz Aufnahmen bei praller Sonne. 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.
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.



Antwort von WoWu:

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.



Antwort von TheBubble:

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



Antwort von WoWu:

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.



Antwort von TheBubble:

Noch einmal zu den Flags. Folgendes hat das verwendete Programm ausgegeben, ich habe allerdings keinen Vergleich mit einem anderen Programm gemacht:

vui_parameters_present_flag : 1
video_full_range_flag : 0

Viele Grüße



Antwort von TheBubble:

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?






Antwort von WoWu:

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.



Antwort von TheBubble:

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.



Antwort von WoWu:

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 ?



Antwort von TheBubble:

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



Antwort von Bruno Peter:

Und in Vegas? Schon mal folgenden Weg getestet: Klick!?



Antwort von bArtMan:

Habe da leider keinen Account.



Antwort von Bruno Peter:

Du wirst doch noch in der Lage sein Dich dort anzumelden?



Antwort von bArtMan:

Ja sicher und vielen Dank auch.



Antwort von Reiner M:

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.

Beste Grüße,
Reiner






Antwort von WoWu:

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



Antwort von Angry_C:

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.



Antwort von WoWu:

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.



Antwort von Bruno Peter:

Welche Programme verstehen das Original-Kameramaterial nicht richtig nach Eurer Erfahrung?



Antwort von TheBubble:

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



Antwort von WoWu:

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.



Antwort von TheBubble:

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



Antwort von WoWu:

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.



Antwort von TheBubble:

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






Antwort von Angry_C:

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.



Antwort von WoWu:

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.



Antwort von TheBubble:

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.



Antwort von WoWu:

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.



Antwort von TheBubble:

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.



Antwort von WoWu:

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.



Antwort von TheBubble:

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.



Antwort von WoWu:

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. So begreife ich das mittlerweile auch.
Hat einwenig gedauert bei mir, ist aber jetzt angekommen.
Nur der Ausgangspunkt war ja ein sehr konkreter und keine allgemeine Diskussion über die Veränderbarkeit von Daten; sondern der Versuch einer Ursacheneinkreisung für die Veränderung anhand eines konkreten Beispiels.
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ß. das kann ich bestens nachvollziehen, nachdem wir uns hier lange Zeit mit den Varianten des De-bayerings beschäftigt haben und uns mittlerweile fragen, wie das eigentlich früher ohne diese Variante gelaufen ist.
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. Das kann nicht ganz sein, denn wenn eine Schnittsoftware bei der Transformation einen beliebigen Algorithus anwendet, dann wirst Du ihn nicht ohne weiteres .... oder nur über successive Annäherung mühsam reengineeren können und se wird immer mit einem hohen Mass an Unsicherheit verbunden sein.
Einfacher -und zielführender- wäre es in der Tat, eine Wandlung durchführen zu lassen und das Resultat zu analysieren. Der Grad der Sicherheit ist dann relativ hoch.
Davon war ich eigentlich ausgegangen ... das war aber meine Fehleinschätzung.
Sorry, dass ich das nicht schneller begriffen habe.

Die eigenen Umrechnungsalgorithmen sind in einem Workflow, in dem man mit den Rohdaten umzugehen hat recht hilfreich, obwohl es nach wie vor fraglich ist, wann und warum man von standardisierten Werten abwichen soll.
Aber es gibt sicher hin und wieder das Erfordernis.
Ob man nun dafür gerade eigene Software braucht ist fraglich.
Im Fall der besagten Fehlereingrenzung (in diesem konkreten Fall) sehe ich da aber keine hilfreiche Verwendung.

Reines Missverständnis. Sorry.



Antwort von Reiner M:

ich hab es jedenfalls mit der 7,5 IRE Korrektur bei PP alles in die Reihe bekommen. Auch das ist falsch, Wolfgang. Nicht besonders "wissenschaftlich", wenn Du auf ein singuläres Ereignis pochst ...

Das lag bei Dir nachweislich nur daran, dass Du einen Clip verwendet hast, mit dem das so möglich war (der ganz einfach die entsprechenden Helligkeitswerte nicht repräsentierte). Purer Zufall. Ist so. - Hatten wir mehrfach belegt und festgestellt.

Vergiß die NTSC-7.5IRE-Geschichte endlich. Die spielt genau null Rolle. Das ist PAL. Da liegt keine Anhebung vor.

Ich hatte bereits nachgewiesen, dass a) das Signal korrekt aufsitzt (Y 16 bei 300mV; passende Clips gibts hier zu Hauf.) und b) der Bereich oberhalb 1V größer als 7.5IRE ist, nämlich ca. 9IRE und somit genau die 236-255er Werte ausmacht.
Bubble hat das im Wesentlichen bestätigt.

Es braucht übrigens überhaupt keine großartigen Interpretation und abenteuerlichen Mutmaßungen. Das alles ist auf einem Blick im Waveform-Monitor zu erkennen. Und zwar nicht nur in PP, auch in anderen NLEs.

Gestützt wird es eindeutig dadaurch, dass nun auch bewiesen ist, dass die Cams >235 aufzeichnen. Dieser Bereich liegt oberhalb 1V (700mv) und fließt gemäß REC.709 nicht in die RGB-Umsetzung ein.

Die "Türkisfärbung" ist ein Seiteneffekt aus dem Clipping an der 1V-Linie bei der RGB-Umwandlung, mehr nicht. Ein Zufall in der Farbrepräsentanz durch die weggeschnitten Blautöne verursacht.

Clips, die dieses Türkis in RGB aufweisen, sind allerdings besonders geeignet, um zu zeigen, dass die PC- und Browser-Softwareplayer alle gleich arbeiten. Auch dort wird RGB entsprechend gewandelt und Türkis gezeigt. Also alles oberhalb 700mV weggeschnitten.
Unterschiede im Bild ergeben sich bestenfalls aus Gamma usw.

Alles völlig harmlos.
Man korrigiere Luma ...

Und diese Empfehlung ist eben für alle Besitzer von Cams mit Aufnahmewerte 16-255 o. ä. für Videos mit Ziel PC wichtig - unabhängig von "Türkis".

Beste Grüße,
Reiner






Antwort von WoWu:

Lies noch mal in Ruhe durch, was Du da geschrieben hast, vielleicht erkennst Du ja beim erneuten lesen, den Blödsinn.

Alles normal und Grünstich kommt nur vom Clip ...
Und die NLEs, bei denen es funktioniert machen alles falsch..alles klar.


Dir ist entgangen, dass wir schon ein ganzes Stück weitergekommen sind.
Mitlesen wäre hilfreich gewesen, auch wenn man nicht alles versteht.
Schau Dir das Bit für die range an, wie er im Stom gesetzt ist und dann schau, was Adobe daraus macht.
Dann hast Du den Fehler.

Du und Deine "Nachweise" ... das einzige, was von Dir bisher gekommen ist war: "verbiegt es mit dem Gamatool".

Toller Nachweis einer Lösung.
Sorry Reiner, aber es wird lächerlich.



Antwort von Reiner M:

Wolfgang, "Blödisnn" ist kein Argument ;)

Zeige mir die NLEs auf PCs, bei denen es funktioniert.
Wir haben Dir zahlreiche NLEs vorgeführt, die völlig identisch - weil richtig so! - arbeiten.

Farben werden nun mal gemischt. Wenn Blau rausfällt und Grün dominiert, kanns weder Weiß noch Blau werden, oder? Farbenlehre.
Zieht man die Helligkeit nach unten, gibt es die Werte im Blaukanal wieder. Was aufgrund der yuv2RGB-Matrix kein Hexenwerk ist. Alles gut.

Beste Grüße,
Reiner



Antwort von Angry_C:

Es gibt kein NLE, bei dem das funktioniert, weder auf PC, noch auf dem Mac. Wieso auch, es ist ja auch nur sinnig. Wieso sollte ein NLE das Material von einer Cam, die bis 255 aufzeichnet, manipulieren und einschränken? Schade ist doch nur, dass der Bereich 235-255 in den NLEs nicht im Bild dargestellt wird, sondern nur am Messgerät.



Antwort von WoWu:

@Angry_C

Schau Dir mal an wie MPEG funktioniert,
Dann erkundige Dich mal was das
"vui_prameters_present_flag" bedeutet.
Danach schau Dir mal das video_full_range_flag in Deinem Datenstrom an und erkundige Dich mal, was es bedeutet, wenn es auf "0" steht.

Und dann zeig mir nochmal wo es steht, dass der Gamet descripreprter falsch gesetzt ist, wo Du selbst festgestellt hast, dass er stimmt.

Mann, mann überleg doch erst mal einwenig, bevor Du sowas schreibst.

Aber wir sind wieder auf dem untersten Niveau gelandet ....
Macht mal darauf ruhig ohne mich weiter.



Antwort von Reiner M:

Du und Deine "Nachweise" ... das einzige, was von Dir bisher gekommen ist war: "verbiegt es mit dem Gamatool". Dann lies noch mal in Ruhe in den anderen Thread - Du wurdest von mir und anderen mit zahllosen Beweisen bedient, die den Sachverhalt hinreichend erklären und die richtigen Werkzeuge bennen, um das zu korrigieren - bei Bedarf.
Du hast zwar alles abgestritten, aber nichts dagegen zu setzen. Trotz mehrfacher Bitten und Aufforderung. Das setzt sich leider fort. Irgendeine Erklärung ohne die Wörter "Blödsinn" &Co. zu verwenden griffbereit?

Jetzt ist zusätzlich glasklar, weil bewiesen, das Y von 16 bis 255 läuft und daher über 700mV liegen muss! Wenn Du darauf die REC.709 yuv2RGB-full-Matrix anwendest, fallen diese Werte out-of-range. Ganz einfach. Alles nach Standard.
Sorry Reiner, aber es wird lächerlich. Da sag ich mal besser nix zu. ;)

N.B. Mit dem ersten Update (V7.0.1) vor etwa drei Wochen oder so sind die beiden Fehler in den Effekten RGB Curves und Luma Curves in Premiere Pro behoben (war ja Auslöser der Diskussion im anderen Thread). Funktioniert wieder genau so, wie es sein muss! Sie haben Deinen Vorschlag, es so zu lassen, nicht umgesetzt. ;)

Beste Grüße,
Reiner



Antwort von Angry_C:

@Angry_C

Schau Dir mal an wie MPEG funktioniert,
Dann erkundige Dich mal was das
"vui_prameters_present_flag" bedeutet.
Danach schau Dir mal das video_full_range_flag in Deinem Datenstrom an und erkundige Dich mal, was es bedeutet, wenn es auf "0" steht.

Und dann zeig mir nochmal wo es steht, dass der Gamet descripreprter falsch gesetzt ist, wo Du selbst festgestellt hast, dass er stimmt.

Mann, mann überleg doch erst mal einwenig, bevor Du sowas schreibst.

Aber wir sind wieder auf dem untersten Niveau gelandet ....
Macht mal darauf ruhig ohne mich weiter. Mir ist es Wurscht, wie alles funktioniert, ich bin kein Theoretiker sondern mache einfach. Ich fühle mich wenigstens wohl auf dem untersten Niveau, aber du scheinst hier irgendwie nicht reinzupassen. jede Menge Theorie, ob auch alles stimmt, traut sich eh keiner zu hinterfragen, und wenn doch, dann bist du anschließend lange Zeit weg. ist doch auch doof...



Antwort von WoWu:

Prüf es doch einfach nach, ob es stimmt.
Wenigstens besser als das Gelabere.
Oben stehen sehr konkrete Fakten.

Edit.
Warst Du das nicht, der mal gesagt hat, er würde für eine Hamburger Firma arbeiten, die Digitalkameras konstruieren ?
Und hast nach Kodiertabellen gefragt ?

Und jetzt das ?
Wie passt das denn zusammen, oder verwechsele ich da was.



Antwort von Angry_C:

Nee, ist schon richtig, allerdings ist das Imageprocessing nicht mein Gebiet, daher damals auch der Hilferuf für die Berechnung der Lookuptables.



Antwort von -paleface-:

Hab ja KEINEN schimmer über was ihr da redet :-D
Ist mir zu technisch.

Aber es wird übrigens NICHT die 909 sondern die AC90.
Ich denke da hab ich genau das was ich möchte. Kostet zwar auch mehr, aber da muss ich nun durch.






Antwort von WoWu:

Nee, ist schon richtig, allerdings ist das Imageprocessing nicht mein Gebiet, daher damals auch der Hilferuf für die Berechnung der Lookuptables. Tja, umso grösser ist eben meine Überraschung, dass das Elementarste nicht verstanden wird. Da hatte ich eine ganz andere Projektion.

Jemand der in einer Konstruktionsfirma für digitale HD Kameras arbeitet und nicht im Ansatz weiss, wie MPEG funktioniert ... und dann so kommt.
Hmmm schon komisch.
Na jedenfalls weiss ich jetzt, warum manche Firmen mit ihren Konstruktionen nicht in die Hufe kommen.



Antwort von Angry_C:

Nee, ist schon richtig, allerdings ist das Imageprocessing nicht mein Gebiet, daher damals auch der Hilferuf für die Berechnung der Lookuptables. Tja, umso grösser ist eben meine Überraschung, dass das Elementarste nicht verstanden wird. Da hatte ich eine ganz andere Projektion.

Jemand der in einer Konstruktionsfirma für digitale HD Kameras arbeitet und nicht im Ansatz weiss, wie MPEG funktioniert ... und dann so kommt.
Hmmm schon komisch.
Na jedenfalls weiss ich jetzt, warum manche Firmen mit ihren Konstruktionen nicht in die Hufe kommen. Och, in unserer Firma muss nicht jeder bis ins Detail wissen, wie diverse Codecs aufgebaut sind. Wir haben Ingenieure, die wissen, was zu tun ist, damit am ende ein 3G/6G SDI Stream, ob debayert oder als RAW rauskommt.

Alles andere erledigen diverse Recorder von der Stange;-)

Und dass wir nicht in die Hufe kommen, das würde ich nicht sagen. Wer Fussball schaut, wird unsere Bilder jedes Wochenende auf die Augen bekommen. Sogar in Superslomo;-)

Aber das gehört nicht in dieses Thema...



Antwort von WoWu:

Na, herzlichen Glückwunsch. Da bin ich ja froh, dass in Deiner Belgschaft ein paar Leute sind, die Dir helfen können.
Da gibt's ja noch viel nachzuholen, aber wenigstens gibt es dann ja jemand, der Dir die Grundfunktionen eines der meistbenutzten Codecs einmal erklären kann und Du bist dann nicht länger auf nebulöse Blockeinträge von Leuten angewiesen, die,mindestens ebensowenig darüber wissen, wie Du und Dir weismachen, die Kamera würde etwas anderes tun, als das, was in den VUI Parametern vorgegeben ist.
Also, wende Dich mal vertrauensvoll an die Ingenieure eurer Firma, ob Sie Dir nicht mal die elementaren Funktionen von MPEG verraten können.
Es hat noch keine Praktiker geschadet, etwas technische Grundkenntnis zu erwerben.
Oder wüsstest Du einen ?



Antwort von Jan:

Jetzt mal eine ganz blöde Frage, weil ich selbst nie diese Türkisbilder auf meinen ca. 10 Stunden X 909 / X 929 bei praller Sonnen und in die Sonne Aufnahmen hinbekommen habe, stellt ihr rein zufällig Digital Cinema Colour auf ein ?


Digital Cinema Colour ist bei Panasonic der x.v.Colour Farbraum.


Kann es sein dass ein Programm das falsch interpretieren kann ?


Übrigends kann ich auf den sehr vielen Tiefflieger Bildern auch nicht den Türkisstich erkennen, der hier ab und zu gepostet wird. Bei mir sind alle Digital Cinema / Colour Aufnahmevarianten deaktiviert.


Ich schaue meine Clips nur mit dem Win Media oder VLC Player an.


Nichts im Schnittprogramm.


PS: Jemand meint das bei Digital Cinema Colour wieder 0 - 255 greifen soll, und bei Deaktivierung 16 bis 235 !



VG
Jan



Antwort von Reiner M:

@TheBubble,

Du hattest es zwar weiter oben schon mal geschrieben, aber erlaube mir, dass ich trotzdem noch mal gezielt nachfrage:

a) Die von Dir untersuchten YCbCr-Daten stammen direkt aus einer Cam-Aufzeichnung, in diesem Fall Aufnahmen der X909, richtig?
b) Das File ist REC.709 kodiert, richtig?
c) Der Y-Kanal enthält in diesem Fall Bytewerte von 16 bis 255. Habe ich Dich da richtig verstanden?

Beste Grüße,
Reiner



Antwort von WoWu:

@Jan

Sowas wie xvColor ist kein eigener Parameter.
Es gibt derzeit nur die Wahl im (video_full_range_flag) das entweder auf 0 oder 1 gesetzt wird.
Steht es auf NULL, schreibt die Kamera alle Werte in den eingeschränkten Bereich.
Steht es auf 1 (wäre bei xvColor der Fall) dann in den vollen Bereich.

Steht etwas genauer in den Implementation Guidelines für MPEC Codierung.

Für HDMI wird noch ein Code für die Gamutbeschreibung extra auf der Schnittstelle generiert, der die Signalisierung an den Fernesher übernimmt, weil der Fernseher ja keinen Bitstream bekommt, die besagten Flags also nicht lesen kann.

Auch in den HDMI Implementierungen nachzulesen.



Antwort von Jan:

Aber zumindest beeinflusst es die Wiedergabe und wird bei der Aufnahme auch vermerkt. Danke für (video_full_range_flag) was ich nicht kannte.



Jetzt würde mich bei den Türkisfreunden nur interessieren, ob sie im xvYCC Modus aufgenommen haben ?


VG
Jan



Antwort von WoWu:

Es bleibt noch eine andere Variante .... der Kamerastrom ist in Ordnung und im begrenzten Farbraum und die Software steht auf -default Grafik- Das wäre wie "1".
Dann entspricht die Implementierung allerdings nicht den MPEG Vorgaben, weil da -default- "0" vorgeschrieben ist.

Der Witz ist ja, sobald man im Programm das manuell setzt, also das tut, was das flag eigentlich bewirken sollte und die beiden Werte statt 0 auf 16 und statt 255 auf 235 setzt, funktioniert alle bestens.
Also, ein Handgriff und alles ist so, wie es sein soll.
Ohne Banding, ohne Stauchen ohne Neurendering, alles so, wie das Original es aus der Kamera hergibt.



Antwort von Reiner M:

Jetzt würde mich bei den Türkisfreunden nur interessieren, ob sie im xvYCC Modus aufgenommen haben Nein, Digital Cinema (X.v.Colour) geht mit 1080p50 bei der Cam auch nicht. Oder?

Beste Grüße,
Reiner

Edit:
Jan, ich hatte schon öfter darauf hingewiesen, dass dieser "Türkisstich" sehr selten ist (Zufall der Farbanteile) und i.d.R. im Automatikmodus auftaucht. Du kannst ihn vielleicht erwzingen, wenn Du bei strahlend blauen Himmel bei Tageslicht mit hohen Kontrasten ein schattiges Objekt im Vordergrund durchgezeichnet belichtest. Das Ergebnis ist entweder ein ausgebrannter Himmel oder - mit etwas Pech - ein Blau, dass unterschiedlich stark ins Türkis schlägt. Selten, aber kommt vor.



Antwort von Reiner M:

Es bleibt noch eine andere Variante .... der Kamerastrom ist in Ordnung und im begrenzten Farbraum und die Software steht auf -default Grafik- Das wäre wie "1". Der Kamerastrom ist in Ordnung und die Werte liegen nicht im begrenzten Farbraum, wie TheBubble betätigt hat, oder?
Der Witz ist ja, sobald man im Programm das manuell setzt, also das tut, was das flag eigentlich bewirken sollte und die beiden Werte statt 0 auf 16 und statt 255 auf 235 setzt, funktioniert alle bestens.
Also, ein Handgriff und alles ist so, wie es sein soll.
Ohne Banding, ohne Stauchen ohne Neurendering, alles so, wie das Original es aus der Kamera hergibt. Abenteuerlich ... ;)

Y16 steht auf 0mV, 235 auf 700mv. Wie REC.709 es vorgibt.
Dein "Handgriff" würde bedeuten, dass ein Software-Clipper vor der RGB-Umwandlung automatisch und ohne Rückfrage massiv eingreifen muss, um Y255 auf Y235 zu mappen und alle anderen Werte darunter auch. Wie bitteschön soll das "ohne Stauchen", ohne Neurechnen gehen?
Mit dem Original aus der Kamera hätte ein ein solches Ergebnis gerade nichts mehr zu tun. Die Cam hat 16-255 aufgezeichnet! Nicht 16-235.

Beste Grüße,
Reiner



Antwort von WoWu:

Machs doch einfach mal .... da clipped nix. Der Arbeitsbereich wird nur festgelegt.
Du solltest Dein Programm mal etwas genauer anschauen.

Ich kann mich auch nicht erinnern, dass Bubble in Bezug auf den Strom Bilddaten oberhalb des 709 Bereiches bestätigt hat.
Ziter doch mal .... nicht einfach mal so eine Behauptung in den Raum stellen.

Ich habe übrigens gerade mit einem Supporttechniker unseres NLEs gesprochen (über ein anderes Thema) und beiläufig dieses Thema anklingen lassen ... nach dem Motte: warum geht das bei Euch und nicht bei Andern.

Er konnte (und wollte) nichts zu andern Herstellern sagen aber er sagt, dass die p50 Implementierung noch gar nicht normiert ist und dass AVCHD.org lediglich eine proprietäre Implementierung vornehmen (lassen), die nicht annaehernd ausreichend spezifiziert ist.
Und das die ( ' benutzte ein Wort, das ich mal mit Hühnerfarm übersetzen würde), nicht mal halbwegs vernünftige Implementierungsanweisungen für P50 herausgibt.
Die Imp. in ihrem NLE ist streng nach den MPEG Vorschriften vorgenommen worden und alle Tools aus der AVC -Toolbox die ihre H.264 Implementierung ohnehin für die professionelle Anwendung hat.

Darüber hinaus unterscheidet sich ihre Implementierung von andern Herstellern noch darin, dass sie für p50 auch die Clock umschalten und so die gesamte Makroblockmenge bearbeiten. Sie benutzen dazu auch die Clock Steuerung des Datenstroms.
Er sagt, das tun nicht unbedingt alle.
Entweder machen sie p25 daraus oder verarbeiten u.U. nur die halbe Makroblockmenge.
Dafür gibt es kein 1440x1080 in ihrer Implementierung, weil das keiner AVC Spezifikation entspricht. (Ist noch gar nicht aufgefallen)

Er hat keine Namen anderer Hersteller genannt.
Er hat also nichts dazu gesagt, warum es bei andern nicht geht, sondern nur, warum es bei ihnen geht.
Über diese 255er Lösung, dass die Kamera bereichsübergreifend arbeiten soll, wusste er nichts.

Nur mal so als Nebeninformation.

Und nun macht daraus, was ihr wollt.
Das Problem ist bei mir nicht existent.



Antwort von Reiner M:

Machs doch einfach mal .... da clipped nix. Der Arbeitsbereich wird nur festgelegt.
Du solltest Dein Programm mal etwas genauer anschauen. Wolfgang, dann erkläre mir bitte noch einmal, wie Du es schaffen willst, eine Aufnahme, die nachweislich Y16-254 (255) enthält, so neu festzulegen, dass daraus Y16-235 wird, ohne Eingriff in die Daten. Du hättest genau zwei Möglichkeiten: Stauchen oder clippen. Falls Du anderer Meinung bist: Nenne mir bitte eine konkrete Möglichkeit, das nur mit Neufestlegen des Arbeitsbereiches ohne Datenverlust zu lösen.
Bitte.

Nochmal: Die Aufnahme enthält Videodaten bis 254.

Zur Veranschaulichung erneut das Bild aus Premiere Pro, das ich schon mal gezeigt hatte (siehe unten). Auf einen Blick ist kristallklar zu sehen (linken grünen Balken am Waveform-Monitor beachten!):

a) Das Signal sitzt korrekt auf und beginnt bei 300mV (Y=16)
b) Das Signal läuft weit über 1V hinaus. (Ich hatte an einem zweiten Bild gezeigt, dass es etwa +9IRE sind).

Nun leg da mal den Arbeitsbereich neu fest. Nach unten schieben? Um 19 Werte (Wenn oben Y=254 ist)? Du würdest a) negative Schwarzwerte erhalten (bis -3, was nicht geht) und b) Du würdest die Schwarzwerte in den Bereich Y0-15 drücken. Hilft das denn?
Ich habe übrigens gerade mit einem Supporttechniker unseres NLEs gesprochen ....
Er konnte (und wollte) nichts zu anderen Hrstellern sagen aber er sagt, dass die p50 Implementierung noch gar nicht normiert ist und dass AVCHD.org lediglich eine proprietäre Implementierung vornehmen (lassen), die nicht annaehernd ausreichend spezifiziert ist. Seit 2011 ist AVCHD 2.0 verabschiedet, in dem u. a. progressive bis 60p beschrieben ist. Ja, es ist richtig, dass davor einige Implementierungen vorläufig, außerhalb des bis dahin verabschiedeten AVCHD geschehen sind - sonst wäre es ja auch gar nicht zum Bedarf und zur Festlegung der Version 2.0 gekommen.
Im Wesentlichen hat AVCHD 2.0 diese existierenden Implementierungen aufgegriffen und bestätigt.
Die Unternehmen, die das gemacht haben, waren übrigens die Erfinder des AVCHD und die Eigner dieses Formats selbst: Sony und Panasonic. Was ist daran proprietär?

Doch ja, die Welt dreht sich weiter.

Das Thema ist auch nicht AVCHD-spezifisch. Auch darauf abzuheben, hilft nicht!
Es ist REC.709, in dem die Nutzung der Videodaten von 0 bis 254 vorgesehen ist. REC.709 ist nicht automatisch 16-235! Das sieht der Standard eindeutig so vor. Im digitalen Zeitalter hat der Headroom neue Bedeutung erlangt. Sonst würde es auch mit X.v.Colour nicht klappen.
Über diese 255er Lösung, dass die Kamera bereichsübergreifend arbeiten soll, wusste er nichts. Das macht ja nichts. Es zeichnen auch andere Kameras anderer Hersteller so auf (Beispiele aus Userhand dieses Forums hatten wir Dir reihenweise vorgestellt). Die kennt er dann sicher auch nicht. Ist das ein Argument?

Ich denke eher: Es wurde ganz einfach bisher "übersehen", weil noch immer die im digitalen Zeitalter längst überholte 16-235+Headroom-Story propagiert wird und man einfach nicht glauben will, was danach nicht sein darf. ;)


Es mag ja sein, Wolfgang, dass es für Dich, in Deiner Welt mit NTSC, Broadcast und den zugehörigen Gerätschaften keine Rolle spielt. Das will ich gar nicht beurteilen. Nur: Dann ist ja alles gut - für Dich.

Meine Lösung ist einfach (weil ich mein Programm und meine Cams kenne und damit Ergebnisse erzielen will und muss): Bild im Waveform-Monitor betrachten und bei Bedarf z. B. mit Luminanzkurve korrigieren. Das hilft nicht nur gegen Türkis, sondern verbessert die gesamte Wiedergabe der Lichter, wenn Signale oberhalb 1V in der Quelle vorliegen - völlig unabhängig von der Cam selbst.

Der Vorteil: Ich kann es lassen oder tun. Ich kann es nach meinem Geschmack frei festlegen und soweit treiben, bis die Farben in der RGB-Parade nicht mehr clippen. Dann habe ich ein ausgewogenes Farbverhältnis zwischen den Kanälen, wie es die Cam aufgezeichnet hat.

Dein ständiger Hinweis auf Banding usw. ist ja richtig. Ist mir auch sehr bewußt. Doch es geht im NLE bei jedem Schritt letzendlich um das kleinere Übel, um das optimale Bild, nicht um ein technisch perfektes Bild. Sonst müsste man bereits andere Cams und andere Aufzeichnungsformate wählen.

Meine Videos sind für PCs, Beamer, Präsentationen und Browser angelegt - das werde ich tunlichst berücksichtigen, um optimale Bildeindrücke zu erzielen. Und da hilft es mir u. U. sehr, Luma zu korrigieren. Ganz einfach. Praxisnah, zielführend, erfolgsorientiert. Der Rest ist Theorie.

Beste Grüße,
Reiner



Antwort von Angry_C:

- das werde ich tunlichst berücksichtigen, um optimale Bildeindrücke zu erzielen. Und da hilft es mir u. U. sehr, Luma zu korrigieren. Ganz einfach. Praxisnah, zielführend, erfolgsorientiert. Der Rest ist Theorie.

Beste Grüße,
Reiner Genau so sieht"s aus:-)



Antwort von Jan:

Jetzt würde mich bei den Türkisfreunden nur interessieren, ob sie im xvYCC Modus aufgenommen haben Nein, Digital Cinema (X.v.Colour) geht mit 1080p50 bei der Cam auch nicht. Oder?

Beste Grüße,
Reiner

Edit:
Jan, ich hatte schon öfter darauf hingewiesen, dass dieser "Türkisstich" sehr selten ist (Zufall der Farbanteile) und i.d.R. im Automatikmodus auftaucht. Du kannst ihn vielleicht erwzingen, wenn Du bei strahlend blauen Himmel bei Tageslicht mit hohen Kontrasten ein schattiges Objekt im Vordergrund durchgezeichnet belichtest. Das Ergebnis ist entweder ein ausgebrannter Himmel oder - mit etwas Pech - ein Blau, dass unterschiedlich stark ins Türkis schlägt. Selten, aber kommt vor.
Hab noch mal nachgeschaut, der Cinema Modus (Digital Cinema) ist bei 1080 P 50 gesperrt, der Menüpunkt Digital Cinema Colour (X.v.Colour) ist aber frei wählbar, auch bei 1080 P 50.


Ohne jetzt gross den ganzen Artikel gelesen zu haben, hätte ich fast auf die Fehlerquelle getippt.


Wenn der User das aber richtig ausgelesen hat (video_full_range_flag), ist das aber wohl richtig interpretiert.


VG
Jan



Antwort von TheBubble:

Wieso sollte ein NLE das Material von einer Cam, die bis 255 aufzeichnet, manipulieren und einschränken? Schade ist doch nur, dass der Bereich 235-255 in den NLEs nicht im Bild dargestellt wird, sondern nur am Messgerät. Jeder NLE muss sich entscheiden, wo er Schwarz und Weiß setzen will. Was bei der einen Kamera zu abgeschnittenen Helligkeitswerten über 235 führt, würde sonst zu flauen gräulichen Grautönen führen, wo Weiß sein sollte.

Aufgrund des unterschiedlichen Inhalts diverser Videodateien muss man leider sagen, dass das optimale Verhalten eines NLE die Nachfrage beim Benutzer wäre.



Antwort von TheBubble:

Jetzt ist zusätzlich glasklar, weil bewiesen, das Y von 16 bis 255 läuft und daher über 700mV liegen muss! Wenn Du darauf die REC.709 yuv2RGB-full-Matrix anwendest, fallen diese Werte out-of-range. Ganz einfach. Alles nach Standard. Out of range RGB kann auch dann entstehen, wenn Y unter 235 liegt.



Antwort von TheBubble:

Jetzt mal eine ganz blöde Frage, weil ich selbst nie diese Türkisbilder auf meinen ca. 10 Stunden X 909 / X 929 bei praller Sonnen und in die Sonne Aufnahmen hinbekommen habe, stellt ihr rein zufällig Digital Cinema Colour auf ein ? Ohne Digital Cinema Colour. Allerdings habe ich mir schon Mühe geben müssen (und auf passendes Wetter warten), um den Effekt so deutlich sichtbar machen zu können.
PS: Jemand meint das bei Digital Cinema Colour wieder 0 - 255 greifen soll, und bei Deaktivierung 16 bis 235 ! Es entstanden immer Werte bis 255 (unabhängig von Digital Cinema Colour).



Antwort von TheBubble:

a) Die von Dir untersuchten YCbCr-Daten stammen direkt aus einer Cam-Aufzeichnung, in diesem Fall Aufnahmen der X909, richtig? Ja.
b) Das File ist REC.709 kodiert, richtig? Das nehme ich an.
c) Der Y-Kanal enthält in diesem Fall Bytewerte von 16 bis 255. Habe ich Dich da richtig verstanden? Ja, Von ca. 16 an aufwärts bis 255 (mehr geht ja nicht).



Antwort von TheBubble:

Steht es auf NULL, schreibt die Kamera alle Werte in den eingeschränkten Bereich.
Steht es auf 1 (wäre bei xvColor der Fall) dann in den vollen Bereich. Ich hatte auch ein paar Test-Clips mit xvColor gemacht, aber scheinbar ist bei keiner der Dateien das Flag auf 1 gesetzt. Müsste man weiter untersuchen.



Antwort von WoWu:

ändert sich was am : vui_prameters_present_flag ?



Antwort von TheBubble:

ändert sich was am : vui_prameters_present_flag ? Scheinbar immer auf 1, es folgen ja auch die VUI Daten.

PS: Ich kann, zumindest bisher, die Aufnahmen mit und ohne xvColor nicht anhand der Flags unterscheiden.



Antwort von WoWu:

Ich müsste mal in den Implementierungsvorschriften nachsehen, ob meine Erinnerung an die Defaultposition richtig ist, von der ich meine, dass der Decoder auf 'non' ziehen müsste.
Wenn das nicht so wäre, würde das den Fehler erklären, aber ich meine er müsste auf 0 ziehen.
Aber wenn nicht, dass könnte natürlich auch das VUI flag den Decoder steuern, unabhängig davon, ob da Daten folgen, oder nicht, denn die werden übersprungen, wenn das flag nicht darauf hinweist.

Aber es ist schon komisch, dass die Daten sich nicht ändern.
Deutet auf einen Fehler hin.
Ändert sich denn etwas an Schwarz, sitzt das nach wie vor auf 16 oder rutscht das ab?



Antwort von TheBubble:

Ich habe es noch mal probiert: Eine Datei mit und eine Datei ohne "Digital Cinema Colour" (x.v.Color) erstellt. Wenn ich mir mit h264_analyze die Flags ausgeben lasse, dann finde ich im VUI-Bereich keinen Unterschied. Die Kamera erkennt bei der Wiedergabe von der Speicherkarte jedoch den Unterschied und blendet ein entsprechendes Symbol ein.

Ich vermute daher, dass dies vielleicht unter den sonstigen AVCHD-Daten abgelegt sein könnte. Leider habe ich keine Spezifikation.



Antwort von WoWu:

VUI ist eigentlich ein TS-Tool.
Scheint also so zu sein, als würde es dann aus der Metadatendatei genommen, also nicht aus dem Multiplex.
Ich muss da aber auch mal nachschauen.
Übrigens überträgt Canon-Log genau dasselbe 7,5 IRE Offset und schneidet die Ordinate bei 32.
Das ist schon genau das Problem, was ich anfänglich beschrieben habe.



Antwort von TheBubble:

Interessant. Ich frage mich allerdings, warum Canon Werte ungenutzt lässt, immerhin sind max. 256 Abstufungen nicht unbedingt verschwenderisch und es dürfte klar sein, dass die Aufnahmen ohnehin nur digital nachbearbeitet werden.

Findet man von den Log-Kurven der verschiedenen Hersteller eigentlich auch irgendwo die exakten Formeln?

Mangels verlässlicher AVCHD-Informationen komme ich derzeit nicht weiter, was die zusätzlichen Meta-Daten angeht.

Interessehalber habe ich mir inzwischen den verwendeten Y-Wertebereich in Dateien aus verschiedenen Kameramodellen von unterschiedlichen Herstellern angesehen. Man findet wiklich jede Kombination: 0-255, 16-255, 16-235.

Um aber nochmal zum Thema der grünblauen Farbe zurückzukommen: Die Kamera scheint wirklich häufiger Werte ausserhalb des sRGB-/BT.709-RGB-Frabraums aufzuzeichnen - vermutlich weil sie wegen xvYCC ohnehin einen entsprechenden Sensor hat und die YCbCr-Tripel die Speicherung dieser Farben eben erlauben. Achtet man auf eine "mittige" Belichtung, dann ist das in der Regel kein Problem, bei starken Helligkeitsunterschieden/großen Konrasten kann es aber zu Clipping nach/bei der Umwandlung zu RGB kommen.

Ich habe inzwischen einen Filter für VirtualDub erstellt, der unter anderem meine anfangs gezeigte Umwandlung von YCbCr nach RGB verwendet. Sehr nützlich, da man die Unterschiedlichen Darstellungs-Varianten nun interaktiv begutachten und bei Bedarf auch mal Dateien umwandeln kann.



Antwort von TheBubble:

Interessant. Ich frage mich allerdings, warum Canon Werte ungenutzt lässt, immerhin sind max. 256 Abstufungen nicht unbedingt verschwenderisch und es dürfte klar sein, dass die Aufnahmen ohnehin nur digital nachbearbeitet werden.

Findet man von den Log-Kurven der verschiedenen Hersteller eigentlich auch irgendwo die exakten Formeln?

Mangels verlässlicher AVCHD-Informationen komme ich derzeit nicht weiter, was die zusätzlichen Meta-Daten angeht.

Interessehalber habe ich mir inzwischen den verwendeten Y-Wertebereich in Dateien aus verschiedenen Kameramodellen von unterschiedlichen Herstellern angesehen. Man findet wiklich jede Kombination: 0-255, 16-255, 16-235.

Um aber nochmal zum Thema der grünblauen Farbe zurückzukommen: Die Kamera scheint wirklich häufiger Werte ausserhalb des sRGB-/BT.709-RGB-Frabraums aufzuzeichnen - vermutlich weil sie wegen xvYCC ohnehin einen entsprechenden Sensor hat und die YCbCr-Tripel die Speicherung dieser Farben eben erlauben. Achtet man auf eine "mittige" Belichtung, dann ist das in der Regel kein Problem, bei starken Helligkeitsunterschieden/großen Konrasten kann es aber zu Clipping nach/bei der Umwandlung zu RGB kommen.

Ich habe inzwischen einen Filter für VirtualDub erstellt, der unter anderem meine anfangs gezeigte Umwandlung von YCbCr nach RGB verwendet. Sehr nützlich, da man die Unterschiedlichen Darstellungs-Varianten nun interaktiv begutachten und bei Bedarf auch mal Dateien umwandeln kann.



Antwort von WoWu:

Wobei die drei Kombinationen (0-255, 16-255, 16-235. ) eigentlich alle (für sich) klar sind:
Der erste sowieso für alle full range Anwendungen (z.B die xvYCC)
der Zweite für alle NTSC orientierten Werte, wie sie Canon z.B. auch benutzt und die das Setup berücksichtigen und der Dritte für alle normierten Werte nach REC 709.

Dass das in NTSC basierten Modellen eigentlich nicht vorkommen sollte wenn sie REC 709 entsprechen, ist viele aber alle non-standard Recorder arbeiten die 7,5 IRE Offset leider noch in die Werte ein.
Dadurch verlagert sich die Kurve auf der X-Achse um 0,452% ins Negative und kommt so zum Schnitt mit der Y Achse auf rd. 7,3%.
Damit haben sie ihr analoges Offset, das aber eigentlich hier fälschlicherweise in die Werte übernommen worden ist, denn im digitalen Bereich hat das eigentlich gar nichts mehr zu suchen.
Es sei denn, Du willst die geringe Absenkung des Störabstandes bei der Korrektur nutzen.
Was die Formeln betrifft- ob es eine Zusammenstellung gibt, weiss ich so auch nicht. Meistens geben sie ja nur die klassischen Wertepunkte an und den Rest müsste man sich dann daraus interpolieren.

Was diese 7,5 IRE Abhebung betrifft, das ist eine lange Geschichte, die das verursacht hat, aber nachvollziehbar. Nur dass sie eben im digitalen wertebereich nichts mehr zu suchen hat.
Nur dass es einige Hersteller immer noch machen, das ist überraschend.

Was den vollen Wertebereich betrifft, da hat man ja nun endlich bei UHD reagiert und einen deutlich grösseren Farbraum bei voller Wertenutzung standardisiert.
Deswegen ist es eigentlich müßig, da noch für Hd drüber nachzudenken. Da tut sich nichts Neues mehr.



Antwort von TheBubble:

Ich muss vielleicht noch ergänzen, dass auch die 16-255 aus einer "PAL"-Kamera kamen.

Klar, für neue UHD-Projekte spielt es dann keine Rolle mehr, aber solange es noch massig HD und SD Material gibt, das weiterverwendet wird, und UHD derzeit vom flächendeckenden Einsatz noch weit entfernt ist, sollte man sich schon Gedanken machen und ggf. auch Software entsprechend anpassen, wenn man das maximal mögliche herausholen will.



Antwort von TheBubble:

So, ich habe einen neuen Beitrag aufgemacht, in dem ich meinen Lösungsvorschlag noch einmal erläutere:

YCbCr nach RGB: Wenn aus blau türkis wird.

Ein Filter für VirtualDub ist zum Ausprobieren ebenfalls dabei.

Ich würde mich über Feedback zum Filter freuen.



Antwort von Jan:

Danke für die Mühe.


Noch etwas anderes...


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 ?


VG
Jan



Antwort von TheBubble:

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

PS: Wir können das auch gerne in meinem neuen Thread diskutieren, wenn es mit YCbCr zu tun hat. Der andere Thread braucht ohnehin noch ein paar Klicks ;-)