Infoseite // Kurznews: Premiere Pro CC clippt Color Curves

Newsmeldung von slashCAM:


Caum zu clauben: Die neuen Curves scheinen nicht mehr die alten zu sein...

zur News



Antwort von -paleface-:

Ist das jetzt ein Bug?
Oder soll das so sein?

Weil alter Projekte nicht öffnenzu können weil die Farben dann nicht mehr stimmen ist ein mega Nogo!



Antwort von dienstag_01:

Möglicherweise hat Adobe die Color Curves bloß mit der Kurve des Börsenkurses verwechselt. Kann doch mal vorkommen ;)

Aber wie immer, die Nutzer helfen gern.



Antwort von Alf_300:

Erst Unlängst hat einer geschrieben es gibt gar keine Farben , alles ist Einbildung, da sind dann die Kurven auch nicht so wichtig ;-)



Antwort von dienstag_01:

Ich glaube, der ist von Adobe mit Kußhand genommen worden ;)



Antwort von DV_Chris:

Wo sind jetzt die, die gemeint haben, dass man bei Adobe über Jahre hinweg alte Projekte ohne Probleme mit neuen Versionen öffnen kann?



Antwort von dienstag_01:

Wo sind jetzt die, die gemeint haben, dass man bei Adobe über Jahre hinweg alte Projekte ohne Probleme mit neuen Versionen öffnen kann? Versteh ich nicht. Öffnen geht doch problemlos. Oder ;)



Antwort von iasi:

es scheint wohl ratsam, mit dm Umstieg auf CC noch ein wenig zu warten ...



Antwort von Reiner M:

Der Bericht enthält nur die halbe Wahrheit, zumindest per Stand heute:

Ja, es handelt sich offensichtlich um einen Bug im Effekt "RGB-Kurven" (RGB Curves) in Pr CC.

1. Projekte, die diesen Effekt nicht benutzen, sind nicht betroffen!

Man darf davon ausgehen, dass der Fehler behoben wird.

Nein, anders, als im Artikel dargestellt: der Effekt "Luminanzkurve" (Luma curves) besitzt diesen Bug per heute nicht. Er funktioniert einwandfrei.

2. Projekte, die den Effekt Luminanzkurve verwenden, sind nicht betroffen!

BTW: Ich hatte in mehreren Threads hier im Forum Diskussionen darüber geführt, die den Sinn der Korrektur mittels Luminanzkurve verdeutlichen wollten. Genau darum geht es in diesem Warning-Artikel.
Gelernt hatte ich in diesen Diskussionen, dass etliche User hier im Forum das Vorhandensein von Bildinformationen im Videofile außerhalb des bildgebenden Bereichs gar nicht kannten, sowieso nicht nutzen und sogar vehement abgestritten haben.

3. Diese User sind nicht betroffen. ;)

Wer es trotzdem mal wagen will, das Optimum aus seinen Videos zu holen, dem empfehle ich nach wie vor "Luminanzkurve" - auch in Pr CC zum jetzigen Zeitpunkt.

NB: Die im Artikel angeratene Korrektur der "Super whites" und "sub blacks" mittels "Schneller Farbkorrektur" (Fast Color Correction) birgt die Gefahr der Farbverfälschung (Stichigkeit). Hier hat man schnell mehr Schaden angerichtet als man Nüztzliches gewinnt ... - Parametervielfalt verleitet ...

Und ein Hinweis zum Workflow am Rande (nur für die, die das Thema tatsächlich interessieren mag): Luminanzkorrektur gehört m. E. zu den vorbereitenden Reparatur-Aufgaben wie Stabilisieren, Denoisen oder Rolling-Shutter-Korrektur und sollte gesondert abgefackelt werden. Das eigentliche Projekt stützt sich auf im Grunde fehlerfreies Material.
Man kann natürlich auch alles in eine Kiste packen ... - jeder, wie er mag.


Beste Grüße,
Reiner






Antwort von TheBubble:

Ich vermute mal, dass das unterschiedliche Verhalten nur bei der Verwendung von Fließkomma-Bitmaps auftritt.
Ja, es handelt sich offensichtlich um einen Bug im Effekt "RGB-Kurven" (RGB Curves) in Pr CC. Das ist die Frage. Man könnte auch argumentieren, dass es vorher ein Bug war, der nun beseitigt wurde. Denn immerhin gibt es kein schwärzer als Schwarz (Weiß analog) und das neue Verhalten sollte dem Verhalten bei der Verwendung von Integer-Bitmaps entsprechen.

Letztlich läft es darauf hinaus, dass man sich als Entwickler für ein Verhalten entscheiden muss und dieses auch dokumentieren sollte.



Antwort von Reiner M:

Letztlich läft es darauf hinaus, dass man sich als Entwickler für ein Verhalten entscheiden muss und dieses auch dokumentieren sollte. Ja.
Aber genau dieses Feature war ein Plus seit CS3.

Und da alle anderen Effekte, die das bisher konnten, auch in der CC unverändert funktionieren und den Zugriff auf die Bilddaten außerhalb der bildgebenden Bereiche Dank 32bpc bis in die RGB-Umsetzung hinein erlauben (das können andere NLEs nicht unbedingt), und da RGB-Kurven immer noch ein "YUV"-markierter Effekt ist (also vor RGB wirkt), nehme ich wie die Autoren dieses Artikels an: Es ist es wohl ein Bug im Effekt RGB-Kurven.
Wir werden sehen.

Beste Grüße,
Reiner

Edit: Es macht eigentlich keinen Sinn, einen (für den User) teuren 32bpc-Modus mit Float zu implementieren, um ihn dann wie einen 8bpc-Integer arbeiten zu lassen. ;) Das könnte man für alle Beteiligten viel einfacher realisieren ...



Antwort von TheBubble:

Edit: Es macht eigentlich keinen Sinn, einen (für den User) teuren 32bpc-Modus mit Float zu implementieren, um ihn dann wie einen 8bpc-Integer arbeiten zu lassen. ;) Das könnte man für alle Beteiligten viel einfacher realisieren ... Doch, das kann durchaus Sinn machen. Sowohl aus Nutzersicht (bekannte Erwatungen werden bedient), als auch aus technischer Sicht:

Diverse Effekte können schneller abgearbeitet werden, wenn man zuerst ein paar Tabellen berechnet und anschließend nur noch Zwischenwerte interpoliert. Allerdings müssen diese Tabellen auch ihre Grenzen haben, bei Werten auserhalb des abgedeckten Bereichs nimmt man dann z.B. den nächstliegenden Wert. Dies entspricht dem neuen Verhalten.

Problematisch ist es, das Verhalten einfach zu verändern. Der IMO bessere Weg wäre es den alten Effekt auslaufen zu lassen und einen neuen veränderten Effekt einzuführen.



Antwort von Reiner M:

Problematisch ist es, das Verhalten einfach zu verändern. Der IMO bessere Weg wäre es den alten Effekt auslaufen zu lassen und einen neuen veränderten Effekt einzuführen. Eben.

Ein Grund mehr, eine Bug zu vermuten.

Beste Grüße,
Reiner



Antwort von WoWu:

Ich vermute mal, dass das unterschiedliche Verhalten nur bei der Verwendung von Fließkomma-Bitmaps auftritt.
Ja, es handelt sich offensichtlich um einen Bug im Effekt "RGB-Kurven" (RGB Curves) in Pr CC. Das ist die Frage. Man könnte auch argumentieren, dass es vorher ein Bug war, der nun beseitigt wurde. Denn immerhin gibt es kein schwärzer als Schwarz (Weiß analog) und das neue Verhalten sollte dem Verhalten bei der Verwendung von Integer-Bitmaps entsprechen.

Letztlich läft es darauf hinaus, dass man sich als Entwickler für ein Verhalten entscheiden muss und dieses auch dokumentieren sollte.
Das ist doch eine gute Nachricht ich sehe das wie Bubble, .... ein Bug weniger.

Eine korrekte Transformtion vom anliegenden YCbCr nach RGB beseitigt das Problem nämlich im Ansatz.

Wer hinterher trotzdem "Superweiss" herstellen möchte und über kein Farbmanagment verfügt, kann ja immernoch kurbeln- nur eben in die andere Richtung- und sich bei dunklen Farben den Grünstich einhandeln und bei hellen Farben das Rosa.
Wer's mag .... jedenfalls hat Adobe, spät, aber immerhin, den Fehler erkannt

... bei den Grafik/Videoauflösungen hat es bei Adobe ja auch 10 Jahre gedauert, aber letztlich kam es dann.... genauso überraschend.
Still und heimlich .... Bugs hängt man nun mal nicht so gern an die grosse Glocke.
Aber die Programme reifen immerhin beim Kunden. Nur nicht bei allen Herstellern. Einige Ignorieren ihre Bugs einfach.

(Das wird übrigens alle leidgeplagten Besitzer von Kameras mit türkisfarbenen Bildern freuen.) :-))

Chapeau Adobe.



Antwort von dienstag_01:

Das ist doch eine gute Nachricht ich sehe das wie Bubble, .... ein Bug weniger. Interessante Sichtweise.
Wenn ich die eine Farbkorrekturmethode anwende, kann ich Werte ausserhalb des standardisierten Bereichs sichtbar machen. Und wenn ich eine andere anwende, dann sind die Werte weg.
Und das heisst dann, damit ist ein Bug behoben.
Aber mit WELCHER der beiden Methoden.

Upssss

Oder ist es einfach nur ein Bug MEHR.



Antwort von Reiner M:


Das ist doch eine gute Nachricht ich sehe das wie Bubble, .... ein Bug weniger.

Eine korrekte Transformtion vom anliegenden YCbCr nach RGB beseitigt das Problem nämlich im Ansatz. Das ist falsch.

Bereits die Y-, wie auch die Cb- und Cr-Daten (also die Daten im Videofile) liegen außerhalb des bildgebenden Bereichs. Völlig standardkonform. Ist so.

Die YCbCr-to-RGB-Transformation wird von Premiere Pro korrekt vorgenommen gemäß der Ausrichtungs- und Synchronisationspunkte. Premiere Pro macht das allerdings standardmäßig in einem 32bit-float-RGB-Farbraum, in dem die Bildinformationen außerhalb des bildgebenden Bereichs bewahrt werden können. Das ist wohl gewöhnungsbedürftig?

In einem 8bit- oder 16bit-Integer-Zielfarbraum wird allein aufgrund der technischen Begrenztheit der Speichermethode voll automatisch gekappt.
Leute, die auf solchen Systemen arbeiten, kennen es nicht anders, sehen diese Bildinhalte auch nie.

Der Bug besteht nun darin, dass der Effekt RGB-Kurve (und nur der! - alle anderen funktionieren einwandfrei), praktisch wie auf einer 8bit-Umsetzung arbeitet.

Der "Schaden", den dieser Bug verursacht, hält sich in Grenzen. Er ist nur für Leute bedeutsam, die die Vorteile eines 32bit-Workflows auch mit diesem Effekt nutzen, um z. B. extrem hellen Bildpartien (es geht nicht um inhaltsleeres "Superweiß"), die detailleer und ausgebrannt wirken, noch die Zeichnung zu geben, die im Quellvideo tatsächlich enthalten ist.

Beste Grüße,
Reiner



Antwort von domain:

Da JPEG und folgende keine Synchronisationswerte in den Bilddatenstrom abbilden müssen, also 0 u. 255 und weiters keine Sicherheitsbereiche, also 1-15 und 236-254, konnte schon immer für die Werte Y, Cb und Cr der volle Wertebereich von 8 Bit (oder mehr) verwendet werden.
Ich habe Camcorder gehabt, die sich brav an den eingeschränkten Wertebereich hielten aber auch solche, die ihn voll ausnützten, alles gut im Waveformmonitor zu beobachten.
Eigentlich verstehe ich nicht, dass nicht irgend ein Flag in den Metadaten einen Hinweis auf die beiden Codierungsmethoden gibt.



Antwort von Reiner M:

... konnte schon immer für die Werte Y, Cb und Cr der volle Wertebereich von 8 Bit (oder mehr) verwendet werden. domain,

das ist nicht der Grund.
Es ist zu unterscheiden, ob der Encodierer in der Cam Daten außerhalb des bildgebenden Bereichs speichert oder nicht. Beides ist nach den Standards zulässig und beides kommt vor. Die meisten Cams, die mir bisher untergekommen sind, machen das jedoch.

Davon zu unterscheiden ist, wie diese Bildinformationen aus dem Videofile im NLE behandelt werden. Beim Mappen gemäß einer korrekten yuv2rgb-Umsetzung in einen 8bpc-RGB (bildgebender Bereich umfasst maximal 0-255) ist dafür schlicht kein Platz, weil keine Werte größer 255 gebildet werden können. Folge: Clipping. Aber das bemerkt man gar nicht, weil man es eh nicht anders kennt oder sichtbar machen kann in einem solchen RGB-Raum.

In einem 32bpc-float-RGB (bildgebender Bereich maximal 0.0 - 1.0) ist Platz, weil Werte größer 1.0 darstellbar und erlaubt sind. Premiere Pro nutzt das.

Die "Überhänge" werden nun dort korrekt gemäß der yuv2rgb-Umsetzung gespeichert (>1.0). Die Berechnungen aus Luma mal Colors mal Faktoren ergeben als Ergenisse ganz schlicht diese Werte größer 1.0, wie sie auch Werte größer 255 für 8bpc ergeben würden. Die Werte gößer 1.0 stehen aber in diesem Modus für nachfolgende Operationen, z.B. für eine Luma-Korrektur, zur Verfügung. Das geht mit 8bpc eben nicht.

Der Bug besteht darin, dass der Effekt RGB-Kurve offensichtlich Werte größer 1.0 kappt, sich also quasi wie im 8bpc-Modus verhält. Effektiv gehen dadurch wichtige Informationen, die im Video enthalten sind und die Premiere-Pro-User (alle anderen dürfte das eh nicht interessieren) seit der CS3 nutzen können, verloren.

Beste Grüße,
Reiner






Antwort von Frank Glencairn:

Ich hab Al Monney, den Produktmanager von Premiere gefragt und er hat mir gerade geschrieben:

"This is a known bug Frank, we are sorry. It will be fixed very soon."

Thema durch, weitergehen - hier gibt es nichts zu sehen.



Antwort von Reiner M:

Danke, Frank!

Es drohte gerade wieder in eine leidige Tech-Specs-Diskussion abzugleiten ...

Beste Grüße,
Reiner



Antwort von dienstag_01:

Ich hab Al Monney, den Produktmanager von Premiere Das ist einfach zu schön!
Der Name ist Programm.
Oder auch nur wieder ein Bug ;)



Antwort von Frank Glencairn:

Mooney, es ist AL Mooney - is wohl irgendwie eine unterbewußte Vorstellung mit mir durchgegangen.



Antwort von WoWu:

Da JPEG und folgende keine Synchronisationswerte in den Bilddatenstrom abbilden müssen, also 0 u. 255 und weiters keine Sicherheitsbereiche, also 1-15 und 236-254, konnte schon immer für die Werte Y, Cb und Cr der volle Wertebereich von 8 Bit (oder mehr) verwendet werden.
Ich habe Camcorder gehabt, die sich brav an den eingeschränkten Wertebereich hielten aber auch solche, die ihn voll ausnützten, alles gut im Waveformmonitor zu beobachten.
Eigentlich verstehe ich nicht, dass nicht irgend ein Flag in den Metadaten einen Hinweis auf die beiden Codierungsmethoden gibt. SMPTE240M bzw.260M ist die Norm für Videosignale und regelt das seit den 90er Jahren. Signale ausserhalb der Videonormierung (z.B. xvYCC) benutzen das Signalbit 240. Damit wird auch HDMI umgeschaltet auf -non default-.
Und es gibt auch keine Werte ausserhalb der normierten Bereiche. Luma endet bei 235 und Chroma bei 240.

Ist doch alles klar und funktioniert doch auch in allen NLEs, die die Signale normgerecht behandeln.



Antwort von dienstag_01:

In einem 32bpc-float-RGB (bildgebender Bereich maximal 0.0 - 1.0) ist Platz, weil Werte größer 1.0 darstellbar und erlaubt sind. Premiere Pro nutzt das.

Die "Überhänge" werden nun dort korrekt gemäß der yuv2rgb-Umsetzung gespeichert (>1.0). Die Berechnungen aus Luma mal Colors mal Faktoren ergeben als Ergenisse ganz schlicht diese Werte größer 1.0, wie sie auch Werte größer 255 für 8bpc ergeben würden. Die Werte gößer 1.0 stehen aber in diesem Modus für nachfolgende Operationen, z.B. für eine Luma-Korrektur, zur Verfügung. Das geht mit 8bpc eben nicht. Langsam begreife ich, wieso hier immer so unverständliches Zeugs steht.

Reiner_M glaubt, dass Adobe Premiere sein Material beim Import normgerecht behandelt. Und da es ihm dann gelingt, mit 32bit Effekten Werte von oberhalb 255 wieder *zurück* zu holen, baut er sich sein Weltbild nach dem Motto, 32bit bringen ihm Reserven , die es in 8bit nicht gibt (konkret eben Werte von 255+ bzw. 0-). Und lässt sich dafür auch noch lustige Begründungen einfallen ;) (sei nicht böse, so ist das nun mal).
Wenn er aber wüsste, dass Premiere beim Import den Farbraum auf FullRange (0-255) spreizt und damit erst die Werte, die vorher im Bereich 235-255 lagen, über die magische Grenze von 255 hinausschiebt, würde er, und davon bin ich übertzeugt, zu ganz anderen Schlüssen kommen.

Das ist mir auch erst nach der Diskussion um den richtigen Workflow zwischen Avid und Premiere von vor zwei Tagen klar geworden.
So siehts aus ;)



Antwort von WoWu:

Reiners Denkfehler liegt darin, dass er von einer linearen Übertragung des Signals ausgeht, wie sie auch in der ursprünglichen Fassung von SMPTE240 im Jahr 1986 vorgesehen war.
Darin sind etwas gröbere Quantisierungsschritte vorgesehen und die Übertragung endete bei Referenz-Weiss und umfasste 7 Blenden.
Bei einer solchen linearen Übertragung entsteht ein Gap zwischen Referenz-Ws und FullWell.
Das ist wohl die "Reserve" von der er immer spricht und meint, einige Hersteller würden diese noch ausnutzen. Aber das ist seit 1989 vorbei.
Denn 89 hat Sony den Vorschlag der gekrümmten Übertragungskurve in die Arbeitsgruppe eingebracht und gleichzeitig die "Normalisierung" des Signals vorgeschlagen, was sowohl die volle Ausnutzung des Weissbereiches, als auch die Kompartibilität aller Kameras, aller Hersteller mit sich brachte.
Dafür wurden die Quantisierungsschritte verkleinert.
Seit der Zeit gibt es keine "Reserve" mehr und wenn Signale ausserhalb des Wertebereiches auftauschen, so sind das Transienten und andere Probleme, für die der Bereich extra freigemacht wurde. Das ist aber alles Andere als ein Videosignal, auch wenn man es auch schnellen Waveforms sieht.
Es gibt also diese "Reserve", von der Reiner spricht, nur noch in Kameras, die vor 20 Jahren gebaut wurden. Heute wird die gesamte Dynamic von Peak-Weiss, bis zum Noise Limit übertragen. Da gibt es keine Reserve, dafür aber 2,5 Blenden mehr.



Antwort von dienstag_01:

So sieht die Y-Wavform eines Bildes mit sattem Schwarz und völlig überstrahltem Weiss im Avid aus.
Ist von einer EX1 oder 3.



Antwort von TheBubble:

Das ist wohl die "Reserve" von der er immer spricht und meint, einige Hersteller würden diese noch ausnutzen. Ich vermute die "Reserve" die von ihm angenommen wird, liegt in dem für die Überschwinger freigehaltenen Bereich. Natürlich soll dieser nicht verwendet werden.

Wenn jedoch jemand z.B. einfach eine sRGB Bitmap (0-255) zu BT.709 (16-235) "umlabeld" ohne auch nur einen Wert anzupassen, dann verschiebt sich plötzlich Schwarz- und Weißwert und eine Menge nicht erwünschte Werte (alles nahe 0 und nahe 255) landen in den für Überschwinger reservierten Bereichen. Dies wäre dann die "Reserve", die es so gar nicht geben sollte. Mag sein, dass einige digitale Kameras das auch absichtlich tun und dazu die Übertragungsfunktion für diese Bereiche fortsetzen (vermutlich in der Hoffnung, dass nie jemand ein analoges Signal daraus erzeugt, ohne vorher die nicht erlaubten Werte abzuscheiden oder den verwendetet Wertebereich sonstwie anzupassen).

Eine andere Sache wäre Color Grading, da kann es für bestimmte Arbeitsabläufe nützlich sein, als Zwischenergebnis auch nicht sichtbare Werte zuzulassen, damit diese für weitere Korrekturfilter noch verfügbar sind und ggf. im Arbeitsergebnis nach Anwendung weiterer Filter wieder sichtbar werden können. In dem Fall sollte das genaue Verhalten aber gut dokumentiert werden.






Antwort von Reiner M:

So sieht die Y-Wavform eines Bildes mit sattem Schwarz und völlig überstrahltem Weiss im Avid aus.
Ist von einer EX1 oder 3. Es gibt Bildinformationen über 235? (Laut Skala nebendran). Wo kommen die denn her?

Was passiert im zugehörigen Video, dort in den Lichtern, wenn Du dessen Luma so korrigierst, dass diese Spitzen oberhalb 235 auf unterhalb 235 (100%) runtergedrückt werden (nicht clippen).


Beste Grüße,
Reiner



Antwort von dienstag_01:

Was passiert im zugehörigen Video, dort in den Lichtern, wenn Du dessen Luma so korrigierst, dass diese Spitzen oberhalb 235 auf unterhalb 235 (100%) runtergedrückt werden (nicht clippen). Da lässt sich natürlich minimal noch etwas Zeichnung retten.
Aber, weil du von 235 als 100% schreibst: das ist ja dein Trugschluss. In Premiere sind 100% natürlich 255.



Antwort von Reiner M:

Da lässt sich natürlich minimal noch etwas Zeichnung retten. Danke. ;)

Beste Grüße,
Reiner

Edite:
Und wo kommen diese Werte größer 235 nun her? Ihr erklärt doch laufend: Die gibt es nicht und kann es nicht geben. Macht Avid da etwa was falsch? das ist Luma, also Y. Nicht RGB.



Antwort von dienstag_01:

Ich könnte natürlich auch eine RGB Parade reinstellen.
Aber: Avid macht natürlich nichts falsch, das Bild idt überstrahlt/clipped.
In Premiere wird das Bild nur nochmal gespreizt, deshalb enstehen da Werte oberhalb 1.0 (255), die du dir dann mit einer 32bit Farbkorrektur zurück holst. Und glaubst, das ist was ganz besonderes von Adobe Premiere. Das selbe geht mit Avid in 8bit auch ;)



Antwort von WoWu:

Wenn ich das richtig deute, sind die Punkte weiss und damit (vermutlich) C' und C' geht in 709 bis 240.



Antwort von dienstag_01:

Beides aus dem Avid:



Antwort von Reiner M:

... deshalb enstehen da Werte oberhalb 1.0 (255), die du dir dann mit einer 32bit Farbkorrektur zurück holst. Und glaubst, das ist was ganz besonderes von Adobe Premiere. Das selbe geht mit Avid in 8bit auch ;) Werte über 255? Zurückholen? In 8bit? Mach mal .... ;)

Im Ernst:
Du hast mit Avid ein tolles Programm an der Hand. Es zeigt m. E. wie Premiere Pro auch für Luma in der Waveform Werte größer 100% bzw. Byte 235. Ich habe nichts anderes erwartet.

Hast du Premiere Pro?
In Premiere Pro heißt die Skala statt 100%/235 nur eben Volt (für PAL) bzw. IRE (für NTSC) gemäß den Standard-Empfehlungen. Hier wäre 1.0V Dein 235/100% in Avid.
In beiden NLEs gibt es oberhalb dieser Linie Werte. Dein Video-File würde bei mir ein entsprechendes Bild mit Werten zwischen 1.0V und 1.06V zeigen

Das liegt daran, dass der Standard etwa +10% (genauer +10IRE) Überstrahlungsbereich erlaubt. das ist so festgelegt. Das ist der Bereich zwischen Reference White (100%, 100IRE, 700mv, 1.0V, Byte 235 - je nach Skala des Herstellers.) und White-Peak (+10IRE). Dies kann man auch in Deinem Waveform-Screenshot als Skalenvorgabe sehr schön sehen.

Vertraue dem Avid. Prüfe künftig, ob deine Videos Luma über 100% zeigen und korrigire sie ggf. entsprechend. Das wird sich positiv auf die Farben in den Lichtern auswirken und ggf. augenscheinliche Ausbrennungen partiell retten können.

Wolfgangs Grafik, die er weiter oben gepostet hat, zeigt einen Sonderfall und ist nicht der Weisheit letzter Schluss.

-------------------------

@Wolfgang,

ich weiß ja nicht, wo Du die Grafik her hast. Wieder fehlt der Kontext.

Die Grafik zeigt eindeutig einen Sonderfall, nämlich die Wirkung eines "Clippers" in der Prozesskette. Steht ja auch deutlich drin, in der Grafik.

Dieser Clipper hat die Aufgabe, sendefähige Farben zu erzeugen. D.h. er "clippt" ganz einfach den Bereich zwischen Reference White und White Peak - so zeigt es die Grafik. Oder sind nun 110IRE gleich 700mV? Das glaube ich kaum! Du sicher auch nicht ...

Der Clipper sorgt also dafür, dass die insgsamt 110 IRE Signalbereich in die 100IRE bildgebenden Bereich überführt werden - leider durch Clipping. Da kommt ja sein Name her.

Das kann wohl jedes NLE auch in der Post erledigen. In Premiere Pro heißt dieser Effekt übrigens "Sendefähige Farben". Funktioniert genau so. --- Aber genau das wollen wir ja nicht!

Es gibt Cams, in denen ist das so oder ähnlich realisiert. Z. B. die Canon DSLRs, wie Dienstag bestätigen kann. Diese Cams produzieren keine Signale oberhab 100% in den NLEs. Das ist bereits kameraseitig unterbunden. Genau wie es Deine Grafik erklärt.

Die meisten Cams haben aber keinen implementierten Clipper! ist so.
So z. B. auch nicht Dienstags EX1 oder meine X909 oder tausend andere. Was auch völlig standardkonform ist - das weißt Du auch.

Diese Cams nutzen in Y die nach Standard erlaubten +10 IRE (236-254). Es ist nirgends verboten, das zu tun. Deshalb sieht man dort echte, diskrete Signalwerte im Luma-Wave.

Nach Standard ist der bildgebende Bereich aber nur 100 IRE (0-100) groß (100%, PAL 300mv bis 1.0V =700mV; Y 16-235). Ist ganz einfach so festgelegt.
Alles, was darüber liegt, darf von einem NLE gar nicht angezeigt werden ohne Manipulation. Sonst wäre ja der bildgebende Bereich als solcher plötzlich ein anderer. Ich kann es aber erzwingen, jedoch nur durch Eingriff in die Luminanzkurve.

Die Umsetzung nach RGB ist dann erst ein weiterer Schritt.

Beste Grüße,
Reiner



Antwort von WoWu:

Mach doch mal das Bild dazu auf, was das für "Streusel" sind. So ist das einwenig "fischen im Trüben".

@Reiner...
Die 109% gelten für analoge Signale und für lineare Übertragungen, nicht aber für gammakorrigiertes Material.
Hab ich oben alles geschrieben.
Die Zeichnung ist Teil einer SMPTE Publikation zu 240M
Im Standard ist auch festgelegt, dass Kameras mit dem "Normelizer" ausgestattet sein müssen und so sicherstellen, dass die Bereiche, die ja auch in der Übertragung eine andere Verwendung haben, denn sie sind ja nicht zur Schikane eingefügt, freigehalten werden.
Der Normalizer ist zwar erst 1993 in den Standard eingefügt worden, weil Sony ihn verspätet eingebracht hat, wird aber von den Herstellerfirmen bereits seit der Einbringung ausgeführt.


Es geht also nicht darum, dass der Videobereich eingeschränkt wird, sondern darum, dass die restlichen Bereiche(oberhalb und unterhalb) nutzbar sind -aber eben nicht für Video-

Sofern Kameras ausserhalb des Standards arbeiten (einige DSLR Geräte tun das, wird das Signal aber auch in R'G'B' abgelegt.

Und nun lies den Standard und schau, ob Deine Kamera vielleicht defekt (oder verkurbelt) ist.

Ach, vielleicht noch eine Frage: "warum funktioniert das bei 99% aller Kameras und ebenso (vermutlich) bei allen andern NLEs ?
Nur bei Dir nicht? Hat Adobe da vielleicht doch einen Bug ... oder sind alle andern NLEs defekt ?



Antwort von Reiner M:

M
Ach, vielleicht noch eine Frage: "warum funktioniert das bei 99% aller Kameras und ebenso (vermutlich) bei allen andern NLEs ?
Nur bei Dir nicht? Hat Adobe da vielleicht doch einen Bug ... oder sind alle andern NLEs defekt ? Wir sehen gerade, wie es in Avid läuft ...

Aber erklär Du mal: Wo kommen denn bitte die Y-Werte gräßer 235 her? Dienstag hat sich zurückgehalten.

Du kannst das übrigens sehr leicht in Premiere Pro selbst verifizieren.
Lade Dir die Trial. Kostet nichts. Probiere es aus, prüfe es und schreibe dann bitte an Adobe, dass sie da seit vielen Jahren einen Bug haben - und keiner hats gemerkt.
Nur Du. ;)

Na ja.

Beste Grüße,
Reiner






Antwort von dienstag_01:

Reiner, wenn wir von 255 sprechen, sprechen wir von bit (und nicht von Volt oder IRE).
Und die RGB Parade in Premiere geht von 0-100 und das heisst 0-255 und nicht 16-235. In Premiere. Und deshalb denkst du, dass nur Premiere Werte oberhalb von 255 *zurück holen* kann. Aber das liegt nur daran, dass Premiere die Werte vorher spreizt. Das heisst, auch du (und Premiere) holen die Werte nicht wirklich zurück, die sind nur vorher dahin geschoben/gespreitz worden. Nur das du das nicht merkst.



Antwort von WoWu:

Schau mal, was als Überschrift über dem Bild steht: Y:C steht da.
Und warum sollte ich fehlerhafte Programme ausprobieren.
Ich erinnere mich, Du hast mir mal ein File dieser Kamera zugeschickt, das ich dann in FCP eingeladen habe (allerdings über die ProRes Konvertierung) und es ist genau da gelandet, wo alle andern Materialien auch landen: in 16-235 ....
Warum sollte ich also hinter Adobes Bugs herforschen.?

Und gemerkt hab ich es ja nicht .... Du kurbelst doch ständig an Deinen Signalen rum und glaubst auch noch, ihnen damit etwas Gutes zu tun.

Ich hab keine Probleme, weder mit Signalen, noch mit meinen NLEs.



Antwort von TheBubble:

Aber erklär Du mal: Wo kommen denn bitte die Y-Werte gräßer 235 her? Spielt das eine Rolle? Eine digitale Repräsentation, die genau BT.709 entspricht, darf Werte darüber nur ausnahmsweise im Falle von digitalisierten Überschwingern (im Grunde unerwünschten Störungen) annehmen, deren Ursprung aus einem analogen Signal kommt. D.h. riesige leutchend weiße Flächen gehören z.B. nicht dazu. In rein digitalen Systemen hat das IMO auch nichts zu suchen.

Dies wurde jetzt oft genug widerhoft.

Machen kann man natürlich vieles. Nur sollte man es dann auch als etwas anderes bezeichnen.



Antwort von Reiner M:

Reiner, wenn wir von 255 sprechen, sprechen wir von bit (und nicht von Volt oder IRE). Dienstag, es völlig egal, wie das das nennst. Das ist nur ein Maßstab. Wichtig ist, Du bist in YCbCr - vor der RGB-Umsetzung!
Das, worüber gerade reden, hat also mit RGB nichts zu tun.

Und da lautet nach Standard die korrekte Skalenbezeichnung übrigens IRE (für NTSC) und für PAL-basierte Videos Volt. Adobe hält sich daran.
Die Prozent-Angabe ist gar nicht vorgesehen, nur eine Hilfe für die Programm-Anwender. Eine ähnliche Hilfe stellt die Darstellung als Byte-Werte dar. Das ist alles okay, meint aber immer das selbe.

Also, für ein PAL-basiertes Video gilt in Waveform-Monitoren: 100IRE = Bytewert 235 = 1.0Volt (bzw. = 700mV bei Skalen mit negativem Bereich, der bei -300mV beginnt), = 100%. Effektiv immer das selbe: die Oberkante des bildgebenden Bereichs im Videofile, die dort im Y-Kanal als Bytewert 235 repräsentiert ist.
Und die RGB Parade in Premiere geht von 0-100 und das heisst 0-255 und nicht 16-235. In der RGB-Parade sieht das anders aus. Da läuft die Skala von 0 bis 100% (Byte-Werte 0-255 bzw. 0.0 bis 1.0 bei 32bpc usw.)

Lass das mal mit der Spreizung - das ist ein ganz anderes Thema!
Da geht es darum, nach welchen Matrizen die RGB-Formatierung vorgenommen wird. Da befinden wir uns hinter der YCbCr-Manipulation. Die Veränderung der Luma-Kurve hat natürlich Auswirkungen auf die RGB-Kurven, weil Luma in jeden RGB-Kanal einfließt. Aber nicht umgekehrt. Egal, wie ich es in RGB darstelle - gespreizt, ungespreizt, 8-, 16-, 32-bit, full oder nicht full - das ändert nichts am Inhalt der YCbCr-Kanäle.

Also: Wo kommen in Deinem Avid die Werte größer 235 im Y-Kanal her?

Beste Grüße,
Reiner



Antwort von Reiner M:

Spielt das eine Rolle? Eine digitale Repräsentation, die genau BT.709 entspricht, darf Werte darüber nur ausnahmsweise im Falle von digitalisierten Überschwingern (im Grunde unerwünschten Störungen) annehmen, deren Ursprung aus einem analogen Signal kommt. Das ist falsch.

Beste Grüße,
Reiner



Antwort von Reiner M:

Ich hab keine Probleme, weder mit Signalen, noch mit meinen NLEs. Dann fällt es Dir ja leicht:

Wo kommen die Werte größer 235 im Y-kanal bei Premiere Pro und Avid her?

Du behauptest also, das ist in diesen Programmen ein Bug?


Beste Grüße,
Reiner



Antwort von WoWu:

Huch ?
Das ist falsch ?
Das ist mir aber auch neu, dass das falsch ist.

Vielleicht gibt es ja neue, bahnbrechende Erkenntnisse, wie Transienten entstehen ?



Antwort von Reiner M:

Huch ?
Das ist falsch ?
Das ist mir aber auch neu, dass das falsch ist.

Vielleicht gibt es ja neue, bahnbrechende Erkenntnisse, wie Transienten entstehen ? Nicht ablenken, Wolfgang.
Wie lautet denn Deine Erklärung - außer "Bug". Hast du eine?

Beste Grüße,
Reiner



Antwort von dienstag_01:

Hier das selbe Bild aus Premiere.

Identisch mit Premiere Pro.
Die RGB Paraden sehen aber komplett anders aus. Da sieht man, dass Premiere auf 0-255 spreizt, und daher ist dein Glaube an Rückholung von Werten oberhalb von 255 mit 32bit eine Mär. In Wirklichkeit holst du nur Werte oberhalb von 235 und unterhalb von 255 *zurück*. Und das geht natürlich mit Avid auch in 8bit ;)






Antwort von Reiner M:

Hier das selbe Bild aus Premiere.

Identisch mit Premiere Pro.
Die RGB Paraden sehen aber komplett anders aus. Danke, Dienstag.

Wir sehen also Signale oberhalb 1.0V/100IRE im Y-Kanal.
Avid und Premiere zeigen also praktisch das gleiche Bild, verhalten sich gleich, nutzen nur andere Skalen.

Kannst Du mal den Vergleich der RGB-Paraden zeigen?

Weiter oben hast Du aus Avid die YCbCr-Parade gezeigt (die sieht ja in Premiere Pro auch so aus), aber nicht die RGB-Parade. Oder habe ich die übersehen?

Beste Grüße,
Reiner



Antwort von dienstag_01:

Hier die RGB-Paraden aus Avid und Premiere.

Um Diskussionen vorweg zu nehmen: Das was im Avid über 235 liegt, liegt in Premiere über 255.



Antwort von TheBubble:

Das ist falsch. Quellenangabe?



Antwort von WoWu:

Huch ?
Das ist falsch ?
Das ist mir aber auch neu, dass das falsch ist.

Vielleicht gibt es ja neue, bahnbrechende Erkenntnisse, wie Transienten entstehen ? Nicht ablenken, Wolfgang.
Wie lautet denn Deine Erklärung - außer "Bug". Hast du eine?

Beste Grüße,
Reiner Du kannst doch nicht einfach behaupten, was Bubble sagt sei falsch .... sag doch was richtig ist .... und Bug, ja, wie Dienstag schon sagt... es wird YCbCr wird nach RGB nicht korrekt konvertiert.

Und Du mach es Dir ja auch ziemlich einfach zu sagen, es habe mit RGB nichts zu tun .... schliesslich findet genau da die fehlerhafte Konvertierung statt.

Ob es nun ein Bedienfehler oder ein Bug ist, das weiss ich auch nicht.
Ich weiss nur, dass DEINE Kamerasignale bei mir einwandfrei laufen, ohne zurechgekurbelt werden zu müssen. Und ohne dass irgendwelche Phantomsignale über dem Wertebereich schweben.

Edit:
Hab's in den alten Mails wiedergefunden:
Dein Signal, das angeblich so falsch sein soll:
ich vermute, es ist doch ein Bug, egal ob vor oder im Computer.



Antwort von Reiner M:

Spielt das eine Rolle? Eine digitale Repräsentation, die genau BT.709 entspricht, darf Werte darüber nur ausnahmsweise im Falle von digitalisierten Überschwingern (im Grunde unerwünschten Störungen) annehmen, deren Ursprung aus einem analogen Signal kommt. Das ist falsch.

Beste Grüße,
Reiner Die Antwort ist etwas kurz ausgefallen - sorry. Deshalb noch mal nachgeschoben:

Die Recommendation ITU-R BT.709-5 - Parameter values for the HDTV standards ... sagt dazu nur dies für 8-bit coding (Werte sind die Byte-Werte für 8bit-Aufzeichnung):

- Black level Y: 16
- Nominal Peak Y: 235
- Acromatic level Cb, Cr: 128
- Nominal peak Cb, Cr: 16 and 240

Und:
- Video data: 1 through 254
- Timing references: 0 and 255

Beste Grüße,
Reiner



Antwort von WoWu:

Das ist ja ne schlaue Erkenntnis ...
da hättest Du nur fragen müssen, die hätten wir Dir auch ohne Nachschlagen sagen können ..... klar läuft das in sRGB.
Was soll das also sagen ?
Keiner behauptet, dass das sRGB bei 16und240 aufhört und xvYCC wird ja auch im gesamten Bereich übertragen.
Vielleicht hast Du nur vergessen xvYCC abzuschalten.



Antwort von Reiner M:

Edit:
Hab's in den alten Mails wiedergefunden:
Dein Signal, das angeblich so falsch sein soll Wie Du schon weiter oben geschrieben hattest, ist das das Bild nach einer Konvertierung, nicht das originale Cam File, was wir da in Deinem Waveform-Monitor sehen.
Wie damals: Zeige es mir bitte mit dem Original.

Beste Grüße,
Reiner

Aber vielleicht stellt Dir jetzt Dienstag einen EX1-Clip zur Verfügung. Sein Avid reagiert ja gleich.



Antwort von Reiner M:

Das ist ja ne schlaue Erkenntnis ...
da hättest Du nur fragen müssen, die hätten wir Dir auch ohne Nachschlagen sagen können ..... klar läuft das in sRGB.
Was soll das also sagen ?
Keiner behauptet, dass das sRGB bei 16und240 aufhört und xvYCC wird ja auch im gesamten Bereich übertragen.
Vielleicht hast Du nur vergessen xvYCC abzuschalten. ??? Was willst Du mir sagen?

Die REC.709-Tabelle sagt aus, dass a) 0 und 255 reservierte Werte sind, b) es besondere "level"-Werte gibt (in Y: 16/235; in C: 16/128/240), c) das Videodaten zwischen 1 und 254 zulässig sind. Nix mit Ende bei 235 (240) in YCbCr.

Richtig: 1-15 ist footroom und für besondere Zwecke vorgesehen. 236 bis 254 ist headroom und kann für besondere Zwecke vorgesehen sein. Es gibt aber Kameras, die speichern darin Videodaten. Das ist zulässig.

Beste Grüße,
Reiner



Antwort von TheBubble:

- Black level Y: 16
- Nominal Peak Y: 235 Bitte zitiere wenigstens richtig. In BT.709 steht für die 8-Bit-Repräsentation: - Black level R, G, B, Y 16
- Nominal Peak R, G, B, Y 235 Damit ist ganz klar: RGB (16,16,16) ist Schwarz, alle kleineren Werte (mit Ausnahme von 0) sind es folglich ebenfalls. Für Weiß (235,235,235) verhält es sich analog.

Die Bezeichnung "Video data" ist nicht gleichzusetzen mit "alle diese Werte führen zu sinnvollen Farben/Helligkeiten". Vielmehr umfasst der Bereich neben den Nutzwerten (16-235) auch "working margins" (Quelle dieser Bezeichnung: BT.601). Auch wenn es nicht explizit dort steht: Die Beweggründe waren wohl Überschwinger in den ursprünglichen analogen Signalen, verursacht durch analoge Filter.






Antwort von Reiner M:

- Black level Y: 16
- Nominal Peak Y: 235 Bitte zitiere wenigstens richtig. In BT.709 steht für die 8-Bit-Repräsentation: - Black level R, G, B, Y 16
- Nominal Peak R, G, B, Y 235 Damit ist ganz klar: RGB (16,16,16) ist Schwarz, alle kleineren Werte (mit Ausnahme von 0) sind es ebenfalls. Für Weiß (235,235,235) verhält es sich analog.

Die Bezeichnung "Video data" ist nicht gleichzusetzen mit "alle diese Werte führen zu sinnvollen Farben/Helligkeiten". Vielmehr umfasst der Bereich neben den Nutzwerten (16-235) auch "working margins" (Quelle dieser Bezeichnung: BT.601). Ja klar: Wenn die Quelle RGB ist, gilt RGB. Wir haben es hier aber i.d.R. mit YCbCr-Aufzeichnungen zu tun und sprechen darüber. Deshalb habe ich mir das geschenkt. Sorry.

Das hat nichts mit der RGB-Umsetzung im Computer zu tun. Das ist ein nachfolgender Schritt. In der Regel (!) nutzen Computer-Programme eine full-range-Auflösung und mappen REC.709-YCbCr 16 nach RGB 0 und YCbCr 235 nach RGB 255.
Wie Dienstag richtig erkannt hat, ist das dann der Grund, warum headroom in PC-RGB-Integer nicht abgebildet werden kann, sondern außerhalb liegt.

Beste Grüße,
Reiner

Ach so: Nein, wenn Y-Werte größer 235 in der Quelle vorhanden sind dann führt das auch zu hellerem weiß in RGB - wenn das Zielsystem das zulässt. Ein RGB 240/240/240 ist ein anderes Weiß als RGB 235/235/235. Reference White ist ein Referenzwert, keine Grenze. Das selbe gilt nach unten für Schwarz.

Wenn PC-Programme sich an diesem Referzwert ausrichten und verhindern müssen, dass bei der Umrechnung Werte größer 235/235/235 enstehen, müssen sie alle auftauchenden größeren Werte auf 235/235/235 runterrechnen. Clipping.



Antwort von dienstag_01:

In der Regel (!) nutzen Computer-Programme eine full-range-Auflösung und mappen REC.709-YCbCr 16 nach RGB 0 und YCbCr 235 nach RGB 255. Kann ich nicht beurteilen, was NLEs in der Regel machen. Avid macht das nicht.



Antwort von TheBubble:

Ja klar: Wenn die Quelle RGB ist, gilt RGB. Wir haben es hier aber i.d.R. mit YCbCr-Aufzeichnungen zu tun und sprechen darüber. Deshalb habe ich mir das geschenkt. Sorry. RGB ist nicht die Quelle? Wo hast Du eine Kamera mit YCrCb-Sensor her?!?
Nebenbei: BT.709 leitet EY', ECr' und ECb' aus den bereits nicht mehr linearem ER', EG' und EB' ab. EY,ECr,ECb-Tripel, die keinem gültigen ER,EG,EB-Tripel entsprechen, sind raus.
Das hat nichts mit der RGB-Umsetzung im Computer zu tun. Das ist ein nachfolgender Schritt. Unsinn. Computer nutzen in der Regel sRGB, eine ähnliche, aber andere Spezifikation. Das ist kein "nachfolgender Schritt".



Antwort von Reiner M:

Kann ich nicht beurteilen, was NLEs in der Regel machen. Avid macht das nicht. Vielen Dank für die RGB-Parade.

Aber das ist doch okay. Im Endeffekt ist es doch gleich, meine ich. In Deinen Videos auf dem Bildschirm kommen demnnach keine Werte größer 235 vor - in keinem Kanal. Ist das so?

Wenn Du den Headroom sehen willst, musst Du Luma runterziehen. Dann wird parallel das, was jetzt oberhalb 235 in den RGB-Kanälen zu sehen ist, nach unten wandern und auf dem Bildschirm sichtbar. Geht das?

Wenn ja: Schiebe, bis oberhalb 235 in keinem RGB-Kanal mehr ein Signal ist. Dann ist es optimal.

Beste Grüße,
Reiner



Antwort von Reiner M:

RGB ist nicht die Quelle? Wo hast Du eine Kamera mit YCrCb-Sensor her?!? Wir reden über den Inhalt des Videofiles. Oder schließt Du Deinen Sensor direkt an das NLE an? Mach mal ... ;)

Du kannst mit diversen Utilities leicht prüfen, welches Speicherformat im Videofile vorliegt.
Unsinn. Computer nutzen in der Regel sRGB, eine ähnliche, aber andere Spezifikation. Das ist kein "nachfolgender Schritt". Aha. YCbCr läuft also nativ auf Deinem Bildschirm? - erstaunlich!
Da muss nichts konvertiert werden?

Na, dann ...

Beste Grüße,
Reiner



Antwort von TheBubble:

Fassen wir zusammen: Du hast scheinbar kein Interesse an den Fakten, Abläufen und Hintergründen, sondern willst einfach nur das letzte Wort haben. Schade.

Bei solchen Reaktionen wird irgendwann niemend mehr irgendjemandem irgendetwas erklären wollen.

PS: Die Quelle ist eben nicht YCrCb, denn nicht jedes mögliche YCrCb-Tripel ist erlaubt. Es sind nur solche im erlaubten Wertebereich, die mit erlaubten RGB-Tripeln (nach der Transferfunktion) korrrespondieren.



Antwort von Reiner M:

Fassen wir zusammen: Du hast kein Interesse an Fakten, kein Interesse daran Abläufe und deren Hintergründe zu verstehen, sondern willst das letzte Wort haben. Schade. Vielleicht solltest Du erstmal lesen, was ich geschrieben habe?

Ich habe versucht, Dir zu erklären, was Sache ist. Wenn Du dann aber behauptest, YCbCr aus einem Video einlesen und dann nach sRGB konvertieren sind keine getrennten Schritte, und das als Unsinn deklarierst, weiß ich einfach nicht weiter ... ;) -

Die Tasache, dass sich beide im selben Farbraum tummeln, heißt nicht, dass da nichts umzurechnen wäre. Die internen Darstellungen im Speicher unterscheiden sich gewaltig! GEWALTIG! Es MUSS umgerechnet werden. Dafür gibt es sogar definierte yuv2rgb-Matrizen und zwar getrennt für full-range-Mapping und normales Mapping. Und wenn das nun kein zusätzlicher Schritt ist ... ;)

Beste Grüße,
Reiner



Antwort von dienstag_01:

Reiner, wie ich mein Material im Avid bearbeiten muss/kann, weiss ich.
Was mich nur immer stark verwundert hat, war deine Aussage, dass Premiere (und damit auch AE) so speziell genial ist, weil mit der 32bit Verarbeitung Werte von oberhalb 255 gewonnen werden können. Das hat für mich immer die Frage aufgeworfen, wie ein 8bit Codec die speichern will. Inzwischen ist mir klar geworden, dass diese Werte eigentlich Werte von 235-255 sind, die nur Adobe durch seine Spreizung, du nennst es um-mappen, oberhalb von 255 gelandet sind. Und siehe da, die Verarbeitung geht auch ganz normal in 8bit weiter (Nur scheinbar nicht bei Adobe, muss ich nochmal schauen).

Edit: Wenn TheBubble schhreibt, das nicht jedes YCbCr-Tripel erlaubt ist, dann korrespondiert das mit einer Aussage in der Avid-Hilfe, dass man den Farbraum - es gibt YCbCr und RGB - für genauere Ergebnisse nach RGB wandeln sollte.



Antwort von TheBubble:

Ich habe versucht, Dir zu erklären, was Sache ist. Wenn Du dann aber behauptest, YCbCr aus einem Video einlesen und dann nach sRGB konvertieren sind keine getrennten Schritte, und das als Unsinn deklarierst, weiß ich einfach nicht weiter ... ;) - Das wäre eine ganz normale Farbraumtransformation - meinetwegen nenne es auch "getrennten Schritt", "zusätzlichen Schritt" oder wie auch immer, mir ist das egal, denn ich will ganz bestimmt nicht streiten - es ging in der gesamten Diskussion jedoch gar nicht darum, sondern um Schwarz- und Weißpunkt und die Frage, wozu der freigehaltene Wertebereich eigentlich gedacht ist.






Antwort von Reiner M:

Reiner, wie ich mein Material im Avid bearbeiten muss/kann, weiss ich.
Was mich nur immer stark verwundert hat, war deine Aussage, dass Premiere (und damit auch AE) so speziell genial ist, weil mit der 32bit Verarbeitung Werte von oberhalb 255 gewonnen werden können. ... Also funktioniert es auch bei Dir genau so.

Wie Du weißt, geht es mir bevorzugt um Workflow. Ich kann Usern nur raten, sich diesen Punkt näher anzusehen. Viele Videos werden vermutlich falsch gegradet. Der erste Schritt könnte/sollte womöglich für viele Aufnahmen die Luma-Korrektur sein.

Viele Probleme, z. B. das der "Türkisstichigkeit" der X909 oder das von "ausgebrannten" Stellen in Videos lassen sich teilweise leicht korrigieren. Sehr simple und farbneutral mit Luma.

Du weißt außerdem, dass ich nur über Adobe spreche, weil mir die anderen Programme nicht so bekannt sind. Anders als die meisten hier, beurteile ich Programme, die ich nicht kenne, nicht.

Deshalb Danke für den Einblick in Avid. Auch wenn DU weist, wie Du Dein Material in Avid bearbeiten kannst: Ich wußte es nicht und es hat mir geholfen. Endlich jemand, der nicht nur tönt, sondern Butter bei die Fisch gibt.

Meine Hinweise mit dem 32bit-Modus beziehen sich daher zunächst ganz klar auf die Adobe-Welt. Hier kann man sich nämlich diesen vorgestellten Weg aus Versehen verbauen, wenn man Premiere Pro mit einem 8bit-Effekt in den 8bit-Modus zwingt. Und obwohl Premiere Pro full-range Mapping nutzt, sind die Headroom-Daten nicht verloren - wenn ich mit 32bit arbeite. Das selbe bei AE: Wer originale Cam-Files in AE verarbeitet, sollte das möglichst im 32bit-Modus tun.

Wie das andere NLEs machen, müssen deren Owner selbst rausfinden. Wie Du mit Avid.

Danke, Dienstag. ich fühle mich trotz z. T. heftiger Diskussion, bestätigt. Sowohl was NLEs angeht, als auch was Cams angeht.
Weder Premiere Pro noch Avid haben da einen Bug, man muss nur verstehen, wie es abläuft.

Gute Nacht & Beste Grüße,
Reiner



Antwort von domain:

Viele Probleme, z. B. das der "Türkisstichigkeit" der X909 oder das von "ausgebrannten" Stellen in Videos lassen sich teilweise leicht korrigieren. Sehr simple und farbneutral mit Luma. Du hast recht, die Türkisstiche etc. kommen wohl häufig durch Clipping zustande. Hier mal ein Vergleich. Zuerst ein geclippter Himmel (Blau 100%, R u.G bei 70 und 90%)
Dann im Waveformonitor alle überschießenden Lichter (also die über 235) auf die 100%-Linie gezogen und siehe da, der Himmel zeigt jetzt viel eher die korrekten Farben (Blau zwar immer noch 100%, aber R u.G jetzt bei 60 und 80%).
Nun ist auch ganz klar, wie ein Türkisstich im Himmel eigentlich zustande kommt.







Antwort von WoWu:

Eigentlich geht es darum, ob das Problem durch einen Adobe Bug hervorgerufen wird und wenn ich Reiners Files lediglich nach FCP importieren muss und es (ohne rumkurbeln) im korrekten Bereich landet, dann besteht zumindest keine Notwendigkeit, als erstes den Luma-Level korrigieren zu müssen.
Frage ist also .... macht Apple das richtig, dann hat Adobe den Bug.
Macht Adobe das richtig und man muss erst mal den Pegel anpassen .... tja, wo ist dann der Bug bei Apple .... ich kann jedenfalls keinen erkennen.



Antwort von domain:

WoWu, der ganze Scheiß um den 236 -255 Bereich ist mir inzwischen sowas von wurscht, das kannst du dir gar vorstellen.
Tatsache ist erstens, dass ziemlich viele Camcorder bis 255 codieren und weiters, dass div. NL-Editoren, inkl. Liquid diesen Bereich weder in der Timelinevorschau noch im final Rausgerenderten zeigen können.
Bei Liquid ist nur witzig, dass das Originalbild im speziellen Waveform-Vorschau-Monitor mit dem gesamten Wertebereich gezeigt wird, dann in der Timeline aber nicht mehr. Da wird partiell geclippt.
Habe mich immer schon gewundert, wieso die Bilder verschieden aussehen, halt ein Bug in Liquid.
Nun kommen solche Lichtsituationen Gottlob recht selten vor und wenn, dann weiß ich auch, dass ich noch manches mit dem Herunterholen vom über 235-Bereich retten kann.



Antwort von Reiner M:

Eigentlich geht es darum, ob das Problem durch einen Adobe Bug hervorgerufen wird ... :-))
Wenn etwas nicht so funktioniert, wie man denkt, gibt es zwei Stellen, um das Problem zu analysieren:
1. Es funktioniert falsch. Das ist jedoch nicht so - wie wir hinreichend belegt haben ...
2. ...
... und wenn ich Reiners Files lediglich nach FCP importieren muss und es (ohne rumkurbeln) im korrekten Bereich landet, ... ???
Das hat doch bei Dir gar nicht geklappt! Du konntest doch das FullHD 50p aus der X909 gar nicht importieren. Warum auch immer. Oder kann FCP das tatsächlich nicht? AVCHD FullHD 50p?
Jedenfalls musstest Du es konvertieren. Das, was Du da behauptest, stimmt also nicht. Du hast nicht mein, sondern Dein File, ein modifiziertes, analysiert.

Ich kanns Dir nochmal schicken ...

Beste Grüße,
Reiner



Antwort von WoWu:

@Domain,
die erste Zeile kann ich bestens nachvollziehen.
Nicht aber, dass es nennenswerte Mengen an Videorecordern gibt, die sich nicht an den Standard halten, es sei denn, sie sind als -non-standard- klassifiziert und geben einen der beiden derzeit gebräuchlichen erweiterten Farbräume aus oder sie arbeiten, wie einige DSLRs in AdobeRGB.
Ansonsten gibt es eine Norm, der sich nicht nur Kamerahersteller angeschlossen haben sondern nach der auch der Rest der Industrie arbeitet. (TV/Schnittstellen usw). Nicht umsonst muss man bei HDMI erst einmal signalisieren, dass die "Full Range" kommt, weil die Schnittstelle sonst gar nicht mitspielt.
Dass es Recorder gibt, die so billig verarbeitet sind, dass sie jede Menge Überschwinger produzieren ist gar keine Frage. Nur darf man das nicht mit einem Nutzsignal verwechseln. Wer das tut, ist selbst der Bug. Man muss also schon einwenig wissen, womit man umgeht.
Nur dass sich in diesem Fall einmal mehr deutlich zeigt, dass der Fehler offenbar nicht im Recorder liegt, weil die Signale im Endeffekt nicht geclipped sind, sondern irgendwo im Workflow, denn 2 Importmethoden haben offenbar 2 unterschiedliche Ergebnisse erzielt .... eines in einer 8 Bit Verarbeitung, was ok ist und eines in einer 32 Bit Verarbeitung, was offenbar der Nachbearbeitung bedarf.
Frage ist also, warum ist das so.
Ist es ein Bedienfehler, der aufgrund der Wandlung geschieht oder ist es ein Importbug von Adobe, das lediglich ein falsches Mapping vornimmt.
Dazu muss man tatsächlich nicht wissen, was sich ausserhalb des zugelassenen Übertragungsbereiches befindet.
Und wenn Reiner sich mal die Mühe machen würde, den Standard zu studieren, dann würde er auch differenzieren können zwischen standardconform und out-of standard.
Und sein Videorecorder ist lediglich "out-of", wenn er xvYCC benutzt, ansonsten entspricht das Signal exakt dem Standard und führt in einem andern NLE ja auch zu den erwarteten Ergebnissen. Vielleicht versteht ja auch FCP lediglich das Steuerbit richtig ? Wäre ja mal interessant zu wissen, wie das Signal denn über HDMI auf einem normalen TV aussieht. HDMI liest ja auch das Steuerbit aus .... auch wäre interessant, wie denn sein Signal über HDMI als xvYCC aussieht ? das müsste dann ja "wegfliegen", wenn der gesamte Raum schon in 709' benutzt wird.



Antwort von Reiner M:

Tatsache ist erstens, dass ziemlich viele Camcorder bis 255 codieren ... Danke! :)

Es geht nur darum: Die Nützlichkeit dieses Vorgehens liegt auf der Hand. Die NLEs bieten dafür die nötige Unterstützung. Nun kann jeder selbst entscheiden, ob er das anwenden und somit nutzen möchte und wenn ja, in welchen Sitiuationen.

Beste Grüße,
Reiner



Antwort von WoWu:

@Reiner
In FCP musst Du solche Formate immer nach ProRes überführen.
das ist eben eine der Macken von FCP.
Nur das es hinterher wenigstens vernünftig dargestellt wird, das unterscheidet es offenbar von Premiere.
ich weiss nun nicht, was ich vorziehen würde.
Im Zweifelsfall wahrscheinlich das vernünftige Bildergebnis.



Antwort von WoWu:

Tatsache ist erstens, dass ziemlich viele Camcorder bis 255 codieren ... Danke! :)

Es geht nur darum: Die Nützlichkeit dieses Vorgehens liegt auf der Hand. Die NLEs bieten dafür die nötige Unterstützung. Nun kann jeder selbst entscheiden, ob er das anwenden und somit nutzen möchte und wenn ja, in welchen Sitiuationen.

Beste Grüße,
Reiner Das ist leider eine völlig unbelegte Behauptung.
@Domain
Zähl doch mal auf .... und dann schaun wir mal, was die Herstellerangaben dazu sagt denn es gibt eine Norm für Videorecorder.
Aber zähl erst mal auf, dann wissen wir mehr ...






Antwort von domain:

Dieses gelegentliche "Überschwingen" haben eigentlich alle Camcorder von mir gemacht. Mal mehr, mal weniger. Soll ich mal einzelne Frames mit zugehörigen Waveformdiagrammen veröffentlichen ?
Es ist einfach nicht richtig, dass moderne Cams den Bereich über 235 nicht nutzen.
So nebenbei möchte ich auch erwähnen, dass speziell die VEGAS-Schneider schon seit längerer Zeit besonders stolz darauf sind, dass ihr NLE auch Super-Weiß schneiden und exportieren kann.
Eine kleine Notiz von Wolfgang aus Wien wäre dazu ev. ganz hilfreich.



Antwort von dienstag_01:

eines in einer 8 Bit Verarbeitung, was ok ist und eines in einer 32 Bit Verarbeitung, was offenbar der Nachbearbeitung bedarf. Da habe ich (wir) uns falsch ausgedrückt: Premiere arbeitet nicht in 32bit, sondern berechnet bestimmte (ausgewählte) Effekte in 32bit floating Point.
Ich glaube auch nicht, dass die beiden NLEs das Material verschieden importieren (YC-Kurve ist gleich), sondern nur, dass Premiere seine RGB-Ausgabe für die Vorschau auf FullRange mapped. Wenn man das weiss, ist eigentlich alles gleich.



Antwort von WoWu:

@domain

Die Camcorder sind stolz darauf, dass sie den erweiterten Farbraum xvYCC übertragen, ebenso wie die Sony Recorder.
Einige Firmen überlegen, YCoCg zu übertragen.
Beides sind aber Farbräume, ausserhalb von SMPTE240 und haben nichts mit der Nutzung der Raumes ausserhalb von 709 zu tun.
Darüber hinaus sind die Farbräume anders aufgebaut und müssen durch das Steuerbit signalisiert werden.

Ich stimme Dir zu, dass billige Recorder reichlich Überschwinger produzieren,. das sind aber keine Videosignale, sondern technische Mängel, für die man u.A. solche Wertebereiche geschaffen hat.
Das ist aber alles Andere als eine Nutzung.

Also. es bleibt die Frage: welcher Hersteller nutzt für 220 in der Norm festgelegten Werte, 254 Werte. Und was steckt in den zwischenwerten und wie unterscheidet es sich dann von xvYCC oder YCoCg ?
Ich befürchte, hier verwechselst Du etwas.



Antwort von Reiner M:

@Reiner
In FCP musst Du solche Formate immer nach ProRes überführen.
das ist eben eine der Macken von FCP.
Nur das es hinterher wenigstens vernünftig dargestellt wird, das unterscheidet es offenbar von Premiere.
ich weiss nun nicht, was ich vorziehen würde.
Im Zweifelsfall wahrscheinlich das vernünftige Bildergebnis. Wolfgang,

Wenn ich meine Files konvertiere, sehen die auch anders aus. Ist das nicht der Sinn der Konvertierung?

Wenn ProRes das so macht und Du das mit ProRes löst, ist ja alles gut!

(Vielleicht kannst Du da helfen: Muss man das eigentlich in ProRes parametrisieren oder passiert das vollautomatsich und ohne Rückfrage? Es ist ja offensnsichtlich eine Veränderung des bildgebenden Bereiches. Was noch in der Aufnahme in 110IRE (>700mV, Mit Werten zwischen 236 und 254) gespeichert war, befindet sich danach offensichtlich in 100 IRE (max.700mV, max 235) - so zeigt es Deine Wave)

Jedenfalls kannst nun nicht behaupten, FCP würde "meine" X909 Quelle so anzeigen - Das ist Dein Werk, Deine ProRes-Quelle, die man da sieht.

Beste Grüße,
Reiner



Antwort von WoWu:

eines in einer 8 Bit Verarbeitung, was ok ist und eines in einer 32 Bit Verarbeitung, was offenbar der Nachbearbeitung bedarf. Da habe ich (wir) uns falsch ausgedrückt: Premiere arbeitet nicht in 32bit, sondern berechnet bestimmte (ausgewählte) Effekte in 32bit floating Point.
Ich glaube auch nicht, dass die beiden NLEs das Material verschieden importieren (YC-Kurve ist gleich), sondern nur, dass Premiere seine RGB-Ausgabe für die Vorschau auf FullRange mapped. Wenn man das weiss, ist eigentlich alles gleich. So hab ich das auch eigentlich verstanden.
Da besteht also kein Missverständnis sondern lediglich unterschiedliche "Beschreibung/Ausdruck". :-))



Antwort von Jott:

@Reiner
In FCP musst Du solche Formate immer nach ProRes überführen.
das ist eben eine der Macken von FCP. Aber nur, wenn du vom alten fcp redest. Aber selbst da (fcp 6/7) könnte man AVCHD/H.264 umgewrappt, also immer noch nativ, mal zu Forschungszwecken in eine Timeline werfen, um einen Blick auf's Messgerät zu riskieren. Ohne vorherige ProRes-Wandlung.



Antwort von WoWu:

@Reiner

Das ist nun mal die "Sch..." bei NLEs, die nur proprietäre Codecs können.
Meine Einstellung dazu kennst Du ... und ja, streng genommen verändert man sich die Bildinhalte (zum Nachteil) damit und ... ja, es ist schlecht. Das ist auch einer der Gründe, warum FCPx nicht dort gelandet ist, wo es eigentlich hin sollte, in die kommerzielle Verarbeitung sondern dort, wo es hingehört. Dort, wo man mal schnell was sehen und ausprobieren will.

Nur geht es hier ja darum, wie ein File in den Arbeitsraum übernommen wird.
Und... nein, es musste nichts angepasst werden.

@Jott

Ich weiss ja nicht, wie Du nativ mit AVCHD in 50p arbeitest, aber FCPx kann das leider nicht. Insofern betrifft es nicht nur "das alte" FCP.
-nix mit "in die Timeline werfen-
Vielleicht hast Du ja die "Schwäbische" Spezialversion.



Antwort von Jott:

@Jott

Ich weiss ja nicht, wie Du nativ mit AVCHD in 50p arbeitest Ich staune. Soll ich's dir verraten? Kamera anschließen, importieren und los geht's. Sofern du gestattest, dass ein lediglich umgewrapptes File noch nativ genannt werden darf. Darf es? Es wurde ja nicht angefasst.



Antwort von gast5:

Ich schüttle nur den Kopf.. Wieso sollte das nicht funktionieren..






Antwort von WoWu:

Tja, Kamera stand irgendwo in Europa.... war ja Reiners File.

Und mit Content in die Timeline ....war leider nicht.
Hab ich natürlich zuerst probiert.

Also schüttelt mal ruhig weiter die Köpfe.



Antwort von gast5:

Wo ist da das Problem? Clipwrap oder ein Tool deiner Wahl und in mov verpacken..



Antwort von domain:

An diesem Punkt angelangt würde ich jetzt mal wirklich gerne die Argumente der Sony-VEGAS Enthusiasten hören.
Es noch gar nicht solange her, dass sie speziell ihre Software diesbezüglich besonders hervorhoben, nämlich in der Darstellung von Superweiß als allerneuesten Trend und als ganz besondere Fähigkeit von Vegas.
Also, es gibt ja genug User von diesem NL-Editor, äußert euch doch bitte mal dazu.



Antwort von Jott:

Achtung, motiongroup, du fängst dir gleich wieder einen "Jubelperser" ein. Es DARF nicht funktionieren, wenn wowu das sagt.

Im Ernst: bei der 10.0.0 ging's noch nicht, das hatten sie tatsächlich versiebt, aber gleich nach dem ersten Update. Ist schon fast zwei Jahre her.



Antwort von WoWu:

Domain,
Es ist keine Frage der Darstellbarkeit.
Wenn ich im NLE einen Wert erzeige, egal ob der aus Af oder woher auch immer, der sich im Bereich oberhalb von 235 befindet dann stellt jedes NLE das da.

Hier geht es um das Mapping .... !!!! Nicht um die Darstellung das sind 2 Paar Schuhe.



Antwort von dienstag_01:

Also, es gibt ja genug User von diesem NL-Editor, äußert euch doch bitte mal dazu. Nein, bitte nicht. Ist so schon kompliziert genug ;)



Antwort von WoWu:

Achtung, motiongroup, du fängst dir gleich wieder einen "Jubelperser" ein. Es DARF nicht funktionieren, wenn wowu das sagt.

Im Ernst: bei der 10.0.0 ging's noch nicht, das hatten sie tatsächlich versiebt, aber gleich nach dem ersten Update. Ist schon fast zwei Jahre her. Jott, Du darfst mir gern zutrauen, dass ich weiss, wie man ein File in die TL zieht.
Das können nicht nur Jubelperser, sondern auch Leute im wilden Kolumbien.

Hier geht es aber auch nicht um FCP sondern um Adobe Premiere.
Wenn Ihr also sachbezogene Beiträge habt, prima.
FCP war hier nur ein Nebenschauplatz.
Und wenn ihr die Köpfe schütteln wollt ... auch gut.



Antwort von gast5:

Aber gar nicht Jott, der Dr. soll bei der Wahrheit bleiben, den Testfile unverwurstet in fcpücks legen und messen und parallel das prores file einpflegen.. Langsam Krieg ich bei dem Holler der so im Umlauf ist Kopfweh ....

Außerdem hat doch der Frank schon gesagt das ein Fehler sei und behoben wird..



Antwort von dienstag_01:

Außerdem hat doch der Frank schon gesagt das ein Fehler sei und behoben wird.. Dieser Fehler hat doch nichts mit dem Import zu tun... langsam wirds echt verwirrend.



Antwort von domain:

Hier geht es um das Mapping .... !!!! Nicht um die Darstellung das sind 2 Paar Schuhe. Genau es geht um das Mapping. Und wenn Vegas ein Mapping beherrschte, das auch im rausgerenderten Video deutlich sichtbares Superweiß zeigte, dann war das doch etwas Bemerkenswertes, oder?
Komisch, um das Superweiß ist es bei Vegas etc. ganz still geworden.
Sollte das doch nur ein Gag rein für Amateur-Videos gewesen sein?



Antwort von WoWu:

So mancher Späteinsteiger kommt wohl bei dem Thema sowieso nicht mehr mit .... oder hat Leseschwäche.

Ich steig jetzt aus und üerlass denen das Feld.



Antwort von Reiner M:

Hier geht es um das Mapping .... !!!! Nicht um die Darstellung das sind 2 Paar Schuhe. Nein. Mapping kommt später.
Es geht um Werte größer 235 in Y. Du behauptest, das geht nicht, Premiere Pro hätte einen Bug. Jetzt nicht schummmeln. ;)
Die Waveform ist YCbCr, nicht RGB.

Beste Grüße,
Reiner



Antwort von WoWu:

@ Reiner

Erst kommt das Mapping (vom Kamerafile in den Arbeitsraum) und dann kann man Werte benutzen.
Du kannst keinen Wert darstellen, der sich noch nicht im Rechner befindet.
Das ist nun mal so.

Und die Darstellung ist exakt da, wo sie hingehört und im Gegensatz zu Deinen überstrahlten RGB Werten zeigt auch das Bild keinen einziger überstrahlten Punkt.

Machst Du also was falsch mit den überstrahlten Bildern, oder ich, mit einwandfreien Darstellungen ... ??



Antwort von gast5:

Außerdem hat doch der Frank schon gesagt das ein Fehler sei und behoben wird.. Dieser Fehler hat doch nichts mit dem Import zu tun... langsam wirds echt verwirrend. Aber gar nicht Dienstag.. Der Franc hat bestätigt das im Moment ein Bug vorhanden ist und dieser so schnell als möglich gepatcht wird.. Ich verstehe den Aufwand nicht der hier betrieben wird.. Ist ein Fehler vorhanden warte ich bis der behoben ist und prüfe danach..

Was mir aber wirkliches Kopfweh bereitet ist das der Dr. Fcpücks zur Kontrolle für ne Doktorarbeit nimmt wo das doch der absolute Dreck sein soll.. kopfschüttel ....



Antwort von dienstag_01:

Nee, motiongroup, schau dir doch mal den Fehler an. Der betrifft NUR Premiere CC und NUR einen bestimmten Effekt. Lesen bildet ;)



Antwort von WoWu:

@ Dienstag

... gib's doch auch... wer schon so einen Schwachsinn schreibt: Was mir aber wirkliches Kopfweh bereitet ist das der Dr. Fcpücks zur Kontrolle für ne Doktorarbeit nimmt wo das doch der absolute Dreck sein soll.. kopfschüttel .... ... checked doch das ganze Thema gar nicht.



Antwort von Reiner M:

Machst Du also was falsch mit den überstrahlten Bildern, oder ich, mit einwandfreien Darstellungen ... ?? Wolfgang,
ich bin absolut sicher: Es ist kein technisches Problem. Alles in Butter.

Du weigerst Dich, das mal korrekt am Originalfile zu testen ... Du weigerst Dich, mal eine Testversion eines Programms zu nutzen, um das zu überprüfen - Du behauptest nur.

Ich zitiere mich mal selbst von ganz weit oben:

BTW: Ich hatte in mehreren Threads hier im Forum Diskussionen darüber geführt, die den Sinn der Korrektur mittels Luminanzkurve verdeutlichen wollten. Genau darum geht es in diesem Warning-Artikel.
Gelernt hatte ich in diesen Diskussionen, dass etliche User hier im Forum das Vorhandensein von Bildinformationen im Videofile außerhalb des bildgebenden Bereichs gar nicht kannten, sowieso nicht nutzen und sogar vehement abgestritten haben.

3. Diese User sind nicht betroffen. ;)

Meine Meinung dazu hat sich nur gefestigt. ;-)

Beste Grüße,
Reiner



Antwort von gast5:

Nee, motiongroup, schau dir doch mal den Fehler an. Der betrifft NUR Premiere CC und NUR einen bestimmten Effekt. Lesen bildet ;) Doch doch ich habe den Fred sehr interessiert verfolgt...



Antwort von DV_Chris:

Sorry für den Quereinstieg, aber in einem mir bekannten Programm kann man sowohl pro Clip als auch global einstellen, ob etwas als Weiss oder Super Weiss behandelt werden soll.



Antwort von Reiner M:

FCP war hier nur ein Nebenschauplatz. ???
Für Dich doch ein sehr wichtiger Hauptschauplatz!
Du baust Deine Argumentationskette darauf auf, indem Du mit ProRes mein File umkodierst und dann ohne mit der Wimper zu zucken behauptest, dass sei meine Quelle ... und so sei es richtig - Dank FCP;)

Jetzt hast Du Wege erklärt bekommen, wie Du das mit meinem Original doch noch in FCP prüfen kannst.
Würde mich schon interssieren, wie die Wave von einem originalen Cam-File in FCP aussieht. Dich nicht?

Außerdem würde mich interessieren: Wie arbeitet der ProRes-Konverter? Hat er nun einen solchen eingebauten Autofilter zur Erzeugung sendefähiger Farben (bzw. 16-235-Limitierung) oder muss man das von Hand einschalten beim Kodieren?

Beste Grüße,
Reiner



Antwort von WoWu:

@ Reiner

Du hast Recht, ich habe wenig Interesse, an Adobes Bugs zu forschen, weil wir die Programme ohnehin nicht einsetzen.
Du hast mir dankenswerter Weise ein Originalfile geschickt, das ich ohne grosse Mühe korrekt in ein handelsübliches NLE adaptieren konnte und einwandfreie Bilder (bezogen auf Dein Ergebnis) generieren konnte.

Für mich war das zumindest ein starkes Indiz, dass das File in Ordnung war und ein handelsübliches NLE auch damit umgehen konnte.

Nun erwartest Du nicht im Ernst, dass ich mir irgendeine Testversion runterlasse, mir nochmals vermeintlich problembehaftete Files zusenden lasse und damit solange teste, bis ich einen fehlerhaften Workflow nachvollziehen kann.
Mehr als die erforderlichen Tipps kann man da wirklich nicht geben (Bubbles, Dienstags und meine) sollten ausreichend Material geben, dass Du selbst den Fehler findest, zumal Du alle Voraussetzungen (Kamea, Files, NLE usw. ) hast.
Dir nutzt weder ein Avid, noch ein FCP und wahrscheinlich auch kein Quantle, Dein Problem zu lösen.

Und wenn Du es für kein "technisches" Problem hältst, dann könnte ich Dir da sogar zustimmen, weil dann nur noch ein Bedienfehler bleibt.

Und wenn Du schreibst: Du weigerst Dich, das mal korrekt am Originalfile zu testen Dann überleg mal, was Du da eigentlich schreibst.
Ich habe, entlang der Möglichkeiten am Originalfile getestet, das Du mir übersandt hast.
Wenn Du andere Methoden hast ... bitte führ sie aus. Meine Möglichkeiten wären nur noch gewesen, sie auch mal auf der Quantel anzuschauen, aber das habe ich mir nach den beschriebenen Ergebnissen dann doch geschenkt und bin sicher dass das, auch keine andern Ergebnisse generiert hätte.

Aber es freut mich ja zu hören, dass sich Deine Meinung dazu gefestigt hat und dass Du weiterhin zunächst Deine Kamerapegel zurechtkurbeln willst, um die Files nutzen zu können.
Manchmal ist eben auch der weg das Ziel.



Antwort von WoWu:

Jetzt hast Du Wege erklärt bekommen, wie Du das mit meinem Original doch noch in FCP prüfen kannst. Reiner, Du liest offensichtlich gar nicht, was ich schreibe.

Nur weil irgendein Hirni schreibt, es muss gehen, ist es für Dich Fakt, weil es in deine Argumentation passt.
Klar, hab ich das versucht ... es geht nicht.
Und es ist mir mittlerweile auch ziemlich egal, warum es nicht ging.

Und wenn Dich FCP interessiert .... Gegenvorschlag: Lad Du Dir doch das Trial runter. Statt mir vorzuwerfen, nicht mit Premiere zu experimentieren, liegt es doch näher, dass Du mit FCP experimentierst, schliesslich hast Du doch den Fehler, ich hab damit ja kein Problem.



Antwort von gast5:

Es schrieb nicht ein Hirni sondern zwei Hirnis.. Und wer nicht will der hat schon... Schon mal keine Ahnung .. War immer so und wird sich leider nicht ändern..



Antwort von Reiner M:

Du hast mir dankenswerter Weise ein Originalfile geschickt, das ich ohne grosse Mühe korrekt in ein handelsübliches NLE adaptieren konnte und einwandfreie Bilder (bezogen auf Dein Ergebnis) generieren konnte. Das ist ja das Problem, Wolfgang:

Genau das konntest eben nicht!

Du konntest mein File gar nicht importieren .. :-)))

Diese Behauptung ist immer noch falsch und wird durch penetrantes Wiederholen nicht richtiger.

Aber mach doch mal, Du weisst jetzt, wie es geht.


Und erklär bitte endlich: Warum zeigt Avid Lumawerte größer 235 und sogar größer 240???

Dienstag hat mehrere Screenshots gepostet. Sind die alle falsch? Bugs in Avid? Ein Bedienfehler von Dienstag? Oder liegts an der Cam, die das nicht besser kann? ;)

Ich habe das jetzt mehrfach gefragt. Kannst Du das nicht beantworten oder willst Du nicht?

Wolfgang, es ist kein technisches Problem ... - da bin ich mir sicher. ;)

Beste Grüße,
Reiner



Antwort von WoWu:

Und erklär bitte endlich: Warum zeigt Avid Lumawerte größer 235 und sogar größer 240??? Das haben sowohl Bubble, also auch dienstag, wie ich selbst Dir mehrfach erklärt.
Du must nur lesen und es vielleicht auch verstehen. es ist kein technisches Problem ... - da bin ich mir sicher. ;) Ich wiederhole mich auch hier gern:
Kann sein, dann bleibt nur der Bedienfehler.



Antwort von Jott:

Nur weil irgendein Hirni schreibt, es muss gehen Du hängst aber ziemlich stur an deinem Irrtum! :-)

Dabei wäre es doch wirklich interessant, AVCHD nativ und ein daraus generiertes ProRes-File mal genau zu vergleichen. Gerade mit dem durch den Thread geisternden Musterfile.



Antwort von WoWu:

Jott, ich kann nicht mehr sagen, als dass ich es selbstverständlich (als Erstes) versucht habe, das File (50p) in die TL zu ziehen und es nicht funktioniert hat.
Du brauchst also gar nicht darauf zu beharren, dass ich mich irre und kannst mir glauben, dass ich in der Lage bin, ein File auf eine TL zu ziehen.
(So schlau ist man nicht nur als Schwabe).
ES GING NICHT.
Aber das ist hier ja auch nicht Topic weil wir hier ja nicht den Importweg von FCP untersuchen sondern den Bug von PP.



Antwort von Jott:

Als freifliegendes mts natürlich nicht, falls du davon redest. Premiere lässt das zu, fcp aber will aus diversen Gründen schon immer die Datenstruktur drumherum aus der Kamera haben, auch schon in fcp 6/7, das weißt du wirklich noch nicht? Fehlt die, dann extern in mov umwrappen (z.B: mit ClipWrap, Modus "don't alter video samples"), und schon geht das. Das hat gar nichts mit 1080p50 zu tun.



Antwort von Reiner M:

schliesslich hast Du doch den Fehler, ich hab damit ja kein Problem. Du bist Dir sicher, dass Du da nicht was verdrehst? ;-)

ICH habe kein Problem. Jedenfalls nicht mit dem Programm und seiner Bedienung. Alles easy. Alles gut.

Interessant ist ja schon (da gebe ich Dir Recht): Wir sind hier in einem Premiere-Pro-Thread. Hier gehts um Premiere Pro. Richtig?
- Du hast das Programm nicht,
- Du kennst es nicht,
- Du weigerst Dich auch beharrlich, es mal zu testen und kennenzulernen.

Du erklärst dessen Anwender, konkret mich, aber eigentliche Tausende, für unfähig ;)
und Du unterstellst einem Programm Bugs, wo gar keine sind.
Einfach mal so. Warum eigentlich?

Tolle Beiträge. ;)

Nun gut.

Und zu der ausstehenden Antwort: Du hast mit einer Grafik aufgezeigt, die einen Clipper im Einsatz demonstriert, dass Werte größer 235 nicht auftreten können! Absolut nicht auftreten können.

Tun Sie aber. Die Erklärung mit den "Überschwingern" ist ja durchaus eine mögliche. Sie schließt aber aus, dass nach REC.709 echte Videodaten dort gespeichert sein dürfen. Sie schließt aus, dass es - wie domain völlig richtig angemerkt hat! - zahllose Cams gibt, die das auch tun. Es handelt sich um echte Bildinformationen. Tja - ist so.

Ich nehme mal an, Dienstag wird das bestätigen können. Aber das überlasse ich ihm.

Angehängt ein Bild, dass die Wirkung der "Überschwinger" demonstriert.

Hinweis: Im linken Bildteil fand die Korrektur wie beschrieben statt. Das durch Headroom-Daten zerstörte Bild ist linsk, nicht rechts zu sehen.
Die Werte oberhalb Y235 wurden nach unten korrigiert. - Darauf möchte ich nun wahrlich nicht verzichten. Du darfst das ja gerne. ;)

Das kann nun jeder mit seinem NLE und seinen Cams testen.
Allerdings nur mit originalen Cam-Files. Intermediates oder bereits einmal exportierte Files reagieren ggf. anders. Je nach Codec und gewählten Parametern.

Könnstes Du ja auch tun, wenn Du wolltest ... - Aber wie Du oben schreibst, hast Du ja eigentlich gar kein Interesse an dem Thema... ;-)

Beste Grüße,
Reiner



Antwort von WoWu:

Reiner...
vom gebetsmühlenartigen Wiederholen und dem neuen Aufzeigen des fehlerhaften Bildes werden keine Fakten daraus.

Ich denke, dienstag und Bubble haben sich schon verständlicherweise zurückgezogen ... ich mach das jetzt auch einfach.
Vielleicht kommt Domain ja noch mit seiner Camcorderliste, auf die Du Dich beziehst, ansonsten war das ja auch nix.

Mach mal mit den Andern weiter, das ist für Dich vermutlich zielführender.



Antwort von WoWu:

Als freifliegendes mts natürlich nicht, falls du davon redest. Premiere lässt das zu, fcp aber will aus diversen Gründen schon immer die Datenstruktur drumherum aus der Kamera haben, auch schon in fcp 6/7, das weißt du wirklich noch nicht? Fehlt die, dann extern in mov umwrappen (z.B: mit ClipWrap, Modus "don't alter video samples"), und schon geht das. Das hat gar nichts mit 1080p50 zu tun. Kein Schweiss.
Ich hab dem auch nicht das Gewicht beigemessen, nach dem es hier aussieht und ja auch (so oder so) sofort ein astreines Ergebnis erzielt.

Ich geh sowieso davon aus, dass Apple nach ProRes ebenso mapped wie direkt in die TL denn an der Art die Werte zu interpretieren werden sie keine unterschiedlichen Methoden anwenden.
Aber,wie gesagt, ist ja hier nicht Tonic.



Antwort von gast5:

Schneids grad in Kolumbien *gggg. Aber andere als Hirnis hinstellen..alles klar..



Antwort von WoWu:

Schneids grad in Kolumbien *gggg. Ja, die letzten 14 Tage, oberhalb von 4.600m. auf dem Ritacuba Blanco hat es fast 2 m Neuschnee gegeben.
Das kannst Du Flachlandtiroler wahrscheinlich gar nicht verstehen. Vermutlich glaubt ihr in Österlich, in Kolumbien ist es flach und heiss.
In Geographie auch geschlafen ? Oder gibt's das Fach in Österreich gar nicht.



Antwort von gast5:

Nein und wir haben auch ein anderes Benotungsystem als ihr.. Und sind in den PIZZAstudien gaaaanz weit hinten... Dafür haben wir uns den netten Umgang miteinander bewahrt was dir anscheinend durch den geringeren Partialdruck auf 4600 Meter abhanden gekommen ist....

Wie schon mal festgestellt, ein Doktortitel sagt nichts über die Umgangsformen aus..



Antwort von WoWu:

Die Abwesenheit eine solchen aber ebenso wenig.



Antwort von Reiner M:

Reiner...
vom gebetsmühlenartigen Wiederholen und dem neuen Aufzeigen des fehlerhaften Bildes werden keine Fakten daraus. :-)))

Du hast schon verstanden, dass es im Moment 2:1 gegen Dich steht?
Premiere Pro und Avid zeigen die Lumawellen identisch an. - Nur Dein ProRes - Bild, das nicht aus einer Cam stammt, weicht bisher ab.
Eigentlich meint das ja sogar 2:0.

Beste Grüße,
Reiner



Antwort von olja:

Gibts denn das MTS irgendwo ? Ich spiele gerade mit x.v color vom Camcorder, GH2 Material und GoPro Protune rum (was mir bei der ganzen Geschichte sogar noch am besten gefällt) Jedenfalls bekomme ich bei der GH2 unter 0 (ca. -70mV), beim Camcorder mit x.v color on aber weit mehr (fast -140). Thema ist doch interessant ;-)



Antwort von WoWu:

@Reiner

Du weist doch ...."wer schreibt, der bleibt".
Von mir aus leb doch mit dem Bug.
:-))



Antwort von domain:

Zur allgemeinen Verwirrung kann ich nachträglich noch was beisteuern :-)
Das Waveform-Monitorbild im Avid Liquid zeigt bei der 100% Linie nicht wie fälschlich geschrieben 235 sondern 255 an. Sieht man gut an der Waveform des schon mehrfach erwähnten Belle-Nuit-Testcharts. Hier kommen ja 255-RGB-Felder vor und die stimmen auch exakt mit der RGB-Pipetten-Analyse von Photoshop überein, sie zeigt mehrere Bereiche mit genau 255. Ein Export dieses Testcharts aus Liquid heraus zeigt in der Photoshop-Analyse übrigens wieder exakt dieselben Werte, sofern ohne Limiter exportiert wurde.
Die dicke schräg ansteigende Linie ist übrigens der Graukeil im Testchart.



Und nun zum Sonderbaren: bei einigen Videoclips, hier eines mit partiell starken Überstrahlungen, zeigt der Monitor Werte über der 100% Linie an. Wie kann man sich das erklären? Ich bilde mir zwar ein, irgendwo gelesen zu haben, dass das auf YCbCr bezogen durchaus möglich ist, aber trotzdem sehr seltsam.



Sicher ist nur eines, diese über 100% liegenden Werte werden beim Export gnadenlos abgeschnitten. Es kann im 8 Bit-RGB natürlich keine Werte über 255 geben.
Ebenso sicher ist aber auch die Empfehlung, diese Luminanzwerte in das endgültige Bild zu integrieren, sonst kommt es z.B. zu den typischen Türkisverfärbungen im Himmel, wie weiter oben gezeigt.



Antwort von dienstag_01:

Das Waveform-Monitorbild im Avid Liquid zeigt bei der 100% Linie nicht wie fälschlich geschrieben 235 sondern 255 an. Fälschlicherweise? Wenn du dir das erste von mir eingestellte Bild (y_wave) mal einfach nur kurz anschaust, siehst du auf der linken Seite eine Skala bis 235 und auf der rechten Seite eine bis 100%. Da kann man gar nichts falsch machen.
Das Bild ist aber auch aus dem *richtigen* Avid, Avid Media Composer ;)



Antwort von domain:

Das "fälschlich" bezog sich auf meine eigene weiter oben stehende Erstanalyse.
Liquid trickst also im Waveformmonitor ganz schön herum. Verwendet für importierte Fotos und Grafiken offenbar eine andere Anzeige als bei importierten Video-Clips. Ist sowas eigentlich vorstellbar?



Antwort von Reiner M:

Und nun zum Sonderbaren: bei einigen Videoclips, hier eines mit partiell starken Überstrahlungen, zeigt der Monitor Werte über der 100% Linie an. Wie kann man sich das erklären? Erklären? Nun, das habe ich mehrfach getan.
Nochmal? ;)

----------

In Deiner Avid Liquid Wave sieht man Werte oberhalb 100, aber wohl auch einige wenige unterhalb 0 (ist wohl knapp drunter, oder?). Das meint nun:

- Deine Cam, von der diese Aufnahme stammt, hat in das YCbCr-File in den Y-Kanal Byte-Werte von etwa Y 14 (geschätzt) bis Y 254 geschrieben (ist oben am Anschlag und clippt dort partiell). Das ist nach REC.709 erlaubt. Diese Cam benutzt keine Klammern, Clipper, oder sonstige Filter, um die Aufzeichnung für Y auf den Broadcast-Bereich 16-235 zu trimmen. Andere Cams machen so etwas durchaus.

- Der bildgebende Bereich liegt aber in jedem Fall zwischen 0 und 100. Dieser Bereich wird repräsentiert durch Refrence Black (Y 16) und Reference White (Y 235). Werte außerhalb dieses Bereichs darf das NLE nicht anzeigen. Dazu benutzt es ein Mapping (lassen wir mal Farbe außen vor, konzentrieren wir uns auf Luma):

- Ist der Zielfarbraum ein RGB 16-235, wird Y 16 zu RGB 16, Y 235 zu RGB 235. In der RGB-Ausgabe-Datei kommen nach der Konvertierung die Byte-Werte RGB 0-15 und RGB 236-255 nicht vor.

- Wird nach full-range-Matrix aufgelöst, ist also der Zielfarbraum ein RGB 0-255, wird aus Y 16 ein RGB 0 aus Y 235 ein RGB 255.

Beide Verfahren sind korrekt und zulässig.

In beiden Fällen sollte man als Video-Editor nun eingreifen, je nachdem, was man erreichen möchte oder muss.

Man kann z. B. den in der Cam "fehlenden" Broadcast-Clipper in der Post anwenden und einen Effekt wie "Sendefähige Farben" oder einen "Videobegrenzer" (Clipper) drüberlegen. (So heißen diese Effekte in Premiere Pro). Das sind zwei Klicks. Fertig.

Da ich aber inbesondere die Werte oberhalb "100" sehr gezielt für die inhaltsbezogene Korrektur der Videos nutzen möchte, empfehle ich das mit dem Effekt "Luminanzkurve" zu machen. Die Gründe sind einfach:

- Dieser Effekt wirkt vor der RGB-Umwandlung, also direkt auf den Y-Kanal der in den PC-Speicher gelesenen Daten aus dem Video-File. Vor jedem Mapping.

- Dieser Effekt wirkt nicht auf die Cb- und Cr-Kanäle, verändert also die Farbinformationen in der YCbCr-Datenstruktur nicht. Farbintensitäten und Verhältnis der Farben zueinander bleiben erhalten. Es ist nicht möglich, einen "Farbstich" zu erzeugen, allerdings kann man auch keinen ausgleichen (Deshalb ist "Türkisstich" im Himmel nicht die korrekte Bezeichnung, es ist ein Luma-Problem).

- Dieser Effekt kann gezielt und feinfühlig auf das obere Ende des Luma-Bereichs eingesetzt werden, abhängig vom Bildinhalt. Er macht das eben nicht pauschal über alles.

Viel Erfolg beim Korrigieren Deiner Videos!

Beste Grüße,
Reiner



Antwort von dienstag_01:

Liquid trickst also im Waveformmonitor ganz schön herum. Verwendet für importierte Fotos und Grafiken offenbar eine andere Anzeige als bei importierten Video-Clips. Ist sowas eigentlich vorstellbar? Vorstellbar? Vorstellbar wäre eine andere Importmethode für Videos und Grafiken.
Aber, drück doch mal die Werte oberhalb 100 genau auf 100. Dann sollte doch trotzdem ein 255er Weiss im Bild sein.



Antwort von Reiner M:

Liquid trickst also im Waveformmonitor ganz schön herum. Verwendet für importierte Fotos und Grafiken offenbar eine andere Anzeige als bei importierten Video-Clips. Ist sowas eigentlich vorstellbar? Es trickst ganz sicher nicht. Es zeigt nur, was drin ist, in der Datei. Dies hängt ab vom Farbprofil, mit dem die Datei erstellt wurde (Farbraum, Wertebereiche). Da unterscheiden sich i.d.R. Fotos und Videos.

Beste Grüße,
Reiner



Antwort von dienstag_01:

Da ich aber inbesondere die Werte oberhalb "100" sehr gezielt für die inhaltsbezogene Korrektur der Videos nutzen möchte, empfehle ich das mit dem Effekt "Luminanzkurve" zu machen. Die Gründe sind einfach:

- Dieser Effekt wirkt vor der RGB-Umwandlung, also direkt auf den Y-Kanal der in den PC-Speicher gelesenen Daten aus dem Video-File. Vor jedem Mapping.

- Dieser Effekt wirkt nicht auf die Cb- und Cr-Kanäle, verändert also die Farbinformationen in der YCbCr-Datenstruktur nicht. Erstmal vorweg: vielleicht hast du recht. Möglich.

Aber: wie immer gehst du den Weg, etwas in Premiere zu bearbeiten/zu testen und leitest aus dem Ergebnis deine Schlußfolgerungen ab.

So war das auch mit deiner Aussage, nur eine 32bit Bearbeitung würde Werte von oberhalb 255 wieder zu einem Nutzsignal machen. Ohne zu wissen, dass diese Werte von Premiere bei der Spreizung auf FullRange erst generiert werden und damit eine Aussage: *Premiere macht mit der 32bit-Bearbeitung Werte von 255+ sichtbar* (im Gegensatz zu anderen NLEs) selbstverständlich für jeden, der weiss, dass es bei einer 8bit-Aufzeichnung diese Werte nicht gibt, einfach eine hahnebüchene Falschbehauptung ist. Wir wissen jetzt, dass es eine Besonderheit von Adobe ist, seinen Workflow so anzulegen.

Und jetzt machst du wieder das gleiche: Du schaust dir ein spezifisches Problem in Premiere an und leitest daraus ab. Das muss aber nicht stimmen. Das kann sogar völlig falsch sein. Ich würde an deiner Stelle bedenken, dass das alles Software-Meßgeräte sind, die du hier als Nonplusultra hinstellst. Weisst du denn, wie und woher sie ihre Werte generieren? Vielleicht extrahieren sie die YCrCb-Werte auch aus RGB und interpolieren noch ein bisschen. Muss nicht so sein. Kann aber.

Ich will damit nur sagen, dass deine Methode einige Schwächen hat, weil sie letztlich nichts anderes ist, als eine Interpretation der in Premiere ausgegebnene Werte.

Denk mal drüber nach.



Antwort von Reiner M:

Erstmal vorweg: vielleicht hast du recht. Möglich. Ich bin mir sicher. ;)
Im Grunde hast Du ja alles bestätigen können. Sowohl was die Aufzeichnung in Cams angeht, wie auch was das Verhalten in Premiere Pro, After Effects (in einer älteren Diskussion) und nun auch Avid angeht.
domain belegt gerade, dass sich Avid Liquid auch nicht anders verhält. Wieso sollte es auch? In weiteren NLEs wird es gleich oder ähnlich aussehen. Das kann ich jedoch faktisch nur vermuten, bis es mal ein User zeigt.

Aber: wie immer gehst du den Weg, etwas in Premiere zu bearbeiten/zu testen und leitest aus dem Ergebnis deine Schlußfolgerungen ab. Ach komm, Dienstag! Schon wieder!
Wir sind hier in einem Premiere Pro Thread. Richtig? Und wer meine Beiträge kennt, weiß inzwischen längst, aus welcher Position heraus ich schreibe, oder etwa nicht? Ich zitiere mich sicherheithalber noch mal selbst von weiter oben, falls Du es überlesen haben solltest:
Wie Du weißt, geht es mir bevorzugt um Workflow. Ich kann Usern nur raten, sich diesen Punkt näher anzusehen. Viele Videos werden vermutlich falsch gegradet. Der erste Schritt könnte/sollte womöglich für viele Aufnahmen die Luma-Korrektur sein.

Viele Probleme, z. B. das der "Türkisstichigkeit" der X909 oder das von "ausgebrannten" Stellen in Videos lassen sich teilweise leicht korrigieren. Sehr simple und farbneutral mit Luma.

Du weißt außerdem, dass ich nur über Adobe spreche, weil mir die anderen Programme nicht so bekannt sind. Anders als die meisten hier, beurteile ich Programme, die ich nicht kenne, nicht. (...)

Meine Hinweise mit dem 32bit-Modus beziehen sich daher zunächst ganz klar auf die Adobe-Welt. Hier kann man sich nämlich diesen vorgestellten Weg aus Versehen verbauen, wenn man Premiere Pro mit einem 8bit-Effekt in den 8bit-Modus zwingt. Und obwohl Premiere Pro full-range Mapping nutzt, sind die Headroom-Daten nicht verloren - wenn ich mit 32bit arbeite. Das selbe bei AE: Wer originale Cam-Files in AE verarbeitet, sollte das möglichst im 32bit-Modus tun.

Wie das andere NLEs machen, müssen deren Owner selbst rausfinden. Wie Du mit Avid.

Wenn sich nun Leute mit anderen NLEs dazugesellen, kann ich ihnen nur empfehlen (!!), dass an ihren Systemen Cams/NLEs selbst zu überprüfen! Und diese Empfehlung gebe ich immer, oder nicht? Ich fordere immer zu Ausprobieren, Testen, Schauen auf. Das ist doch der Sinn der Übung!
Kann es noch klarer und noch eindringleicher formuliert werden? Hm? ;)
Was erwartest Du?

Ich werde mir - ganz im Gegensatz zu anderen hier! - nicht anmaßen, fremde Produkte zu beurteilen. Wohl aber kann man darüber diskutieren - solange es sachlich, konstruktiv und am Thema interessiert abläuft! -, um Unterschiede und dann vor allem optimale Wege als Nutzen für die Workflows herauszuarbeiten. Ist nicht genau das unser aller Ziel? Oder geht es hier etwa um Selbstdarstellung und Kompetenzgerangel? - Dann bin ich hier eindeutig falsch.

Du hast die Luma-Geschichte überprüft, domain tut es gerade.

Das führt dann doch zu EUREN Erkenntnissen - die IHR nutzen könnt. Ich habe nichts davon.
Müsst ihr aber nicht nutzen. Überreden will ich garantiert nicht, überzeugen womöglich - aber bestenfalls mit meiner Beteiligung. Überzeugen müsst ihr Euch letztendlich selbst.

Also: Entweder du profitierst davon und willst es auch, oder Du lässt es. So einfach ist es.

Schönen Tag noch,

Reiner



Antwort von dienstag_01:

Im linken Original des Bergbildes sind die Wolken oben stellenweise eindeutig ausgebrannt. Der Grund: Nach der Konvertierung von YUV nach RGB findet man hier großflächig den RGB-Wert 255 in allen drei Kanälen. Womöglich vorhandene Bildinformationen im YUV-Signal werden im 8-Bit-Farbraum einfach gekappt.
Wer nur ein 8-Bit-System zur Verfügung hat, muss sich übrigens mit diesem Ergebnis (vermutlich gar mit einem schlechteren) zufrieden geben. Es geht nicht besser.
Premiere Pro zeigt an diesen Stellen tatsächlich RGB-Werte größer 1 an, die aber auf 8-Bit-Monitoren nicht darstellbar sind. D. h. Premiere Pro "sieht" in seinem Speicher die Details sehr wohl, bei der Konvertierung in den 8-Bit-Monitorbereich wird aber wieder alles ab 32-Bit-Wert 1 in RGB 255 gekappt. Also mache ich sie sichtbar, die verborgenen Details. Das war ein Beitrag von dir aus einem anderen Thread.
Sorry, ich kanns mir nicht verkneifen:
Du weißt außerdem, dass ich nur über Adobe spreche, weil mir die anderen Programme nicht so bekannt sind. Anders als die meisten hier, beurteile ich Programme, die ich nicht kenne, nicht. (...) Du schreibst eben nicht nur über Premiere, sondern stellst Vergleiche an mit anderen NLEs (und allgemein zu 8bit/32bit).
Und diese Vergleiche immer auf Basis deines aus der Arbeit mit Premiere abgeleiteten (Halb-)wissens.

Übrigens: Dein Beitrag oben hatte auch noch eine Überschrift:
*Zum technischen Hintergrund*.

Das Wowu und anderen da die Haare zu Berge stehen, für mich ist das nachvollziehbar ;)



Antwort von Reiner M:

Das war ein Beitrag von dir aus einem anderen Thread.
Sorry, ich kanns mir nicht verkneifen: Und? Was willst Du mir sagen?

Dienstag, After Effects arbeitet standardmäßig in 8bit, Premiere Pro kann ich dahin zwingen ohne es zu merken, Photoshop macht das auch anders ...
Zudem: Dazu lernen, aus Diskussionen heraus, ist das verboten? Schließt Du das aus? Wenn ja, nur für mich, oder auch für Dich?

Soll ich nun etwa die alten Beiträge rausfischen, in denen Du vehement und hartnäckig behauptet hattest (in einer Diskussion mit mir), dass Cams solche Werte gar nicht liefern können? War das nun Wissen? Bis ich Dich endlich nach vielen Stunden überreden konnte, das doch einfach mal AUSZUPROBIEREN? - Und siehe da: Dienstag tat es und war sprachlos!

Was hilft uns denn sowas?

Ich tue es nicht, denn ich hatte mich tatsächlich gefreut, dass DU neue Erkenntnisse gewinnen konntest (ich hatte sie ja längst). Genauso, wie ich mich gefreut habe, dass Du in Avid im Grunde Deine Videos auf die gleiche Weise korrigieren kannst, bei Bedarf, wie ich in Premiere Pro. Du hast Dich nicht gescheut, dafür die Beweise, z. B. die Screenshots, vorzulegen. Und es passt nicht nur für meine X909, sondern auch für Deine EX1 und für domains Cam und sein NLE

Nebenbei belegt das alles mehr als eindeutig, dass Premiere Pro keinen Bug hat und ich keinen Bedienfehler mache - sonst gelte das auch für Dich und Dein NLE, oder etwa nicht? :-))) Machst DU einen Bedienfehler? Ist dein Avid kaputt? - Es wird ja hartnäckig behauptet.
Da stehen MIR die Haare zu Berge ... ;)

Lassen wirs. Du bist offensichtlich nicht daran interessiert, neue Erkenntnisse zu finden, die Dich und andere weiterbringen können, und sich darüber zu freuen. Dein Ansinnen ist ein anderes. Das jedenfalls kommt bei mir an.

Und wer in diesem Thread welches Wissen, Halbwissen und Null-Wissen verbreitet hat, das kann der geneigte Leser übrigens selbst nachlesen. Da brauch er keine Hilfestellung und da muss man niemanden protegieren, denke ich. Die Leut' sind selber groß und können denken. Nimm das mal an. ;-)

Vor allem aber: Sie können es ÜBERPRÜFEN! ;) Einfach MACHEN. Kann ich nur dringend empfehlen. Und sich freuen, wenn was Nützliches bei rumkommt.
Der Rest ist Geschwätz.

Beste Grüße,
Reiner



Antwort von domain:

Aber, drück doch mal die Werte oberhalb 100 genau auf 100. Dann sollte doch trotzdem ein 255er Weiss im Bild sein. So ist es, auch dann gibt es noch das 255-er Superweiß. Das gibt es überhaupt immer wenn es von der Kamera angeliefert wird und ich nicht ausdrücklich den Rec709-Limiter beim Rausrendern anklicke.
Die Zeichnung und die Farben verändern sich allerdings positiv in den Lichtern, wenn ich keine 100+ Werte mehr zulasse. Spielt aber nur bei wenigen Clips eine Rolle, da ich die XF100 mit einem leicht flachen Profil und mit einer halben Blende Unterbelichtung betreibe.



Antwort von dienstag_01:

So ist es, auch dann gibt es noch das 255-er Superweiß. Ich glaube, du machst den selben Denkfehler wie Reiner_M (obwohl, der hats ja schon immer besser gewusst, nur nie gesagt): Scheinbar arbeitet Avid Liquid für die Vorschau in FullRange, die in Rec.709 (16-235) ankommenden Werte werden auf 0-255 gemapped. So macht es auch Premiere. Dieser Weg ist für die Farbkorrektur, die ausschließlich an einem Computermonitor stattfindet, auch nachzuvollziehen, sonst wären Schwarz und Weiss nur Dunkel- bzw. Hellgrau.
Nur geht damit eine Verwirrung der (Zahlen-) Werte und Begriffe einher.



Antwort von Reiner M:

Die Zeichnung und die Farben verändern sich allerdings positiv in den Lichtern, wenn ich keine 100+ Werte mehr zulasse. Das, domain, ist der Sinn und der Nutzen.

Ob es sinnvoll und nötig sein kann, hängt natürlich von der Aufnahme ab. Es gibt Aufnahmen, da bringt es gar nichts. Der Y-Waveform-Monitor verrät es.

Als Beispiel die Wave, die Du weiter oben gepostet hast: Sie zeigt ja vor allem im linken Drittel einen ausgeprägten Bereich über 100. Im Video werden dort über diese Breite hinweg rein weiße Flächen zu sehen sein? (Himmel?Ein Fenster? Egal.)

Wichtig ist: Die Wave zeigt in diesem Bereich am oberen Rand noch Ausfransungen, keine durchgängige Linie. Wenn Du nun diesen Bereich unter 100 drückst (nicht beschneiden), so dass die Peaks unter 100 liegen, werden sich vermutlich in den weißen Flächen noch partiell wenige Zeichnungen, ggf. auch Farben (bei Himmelsbildern oft ein ein sehr, sehr helles Blau) zeigen. Zusätzlich gewinnen dann auch die Bereiche mehr Ausdruck, die derzeit nahe an der 100er-Kante liegen, weil sie ja entsprechend nach unten verschoben werden.

Funktioniert das so bei Dir?

Beste Grüße,
Reiner



Antwort von olja:

Das Thema ist doch eigentlich nicht schlecht und sogar praxisrelevant. Evtl. sollte man es abtrennen und in einem neuen Tröt weiterführen.

Ich hab mal in die geclippten Wolken gefilmt (Automatik, Canon Legria). Nur mit der komme ich über 100. Export übrigens egal (ProRes, oder H264), beim Import sind die Werte weiterhin erhalten, hier wird nichts gekappt.

Trotzdem bekommt etwas Zeichnung wieder, wenn man die Höhen auf 100 drückt.

Die GH2 endet bei 100, selbst bei Überbelichtung.

Bei der Canon ist es irgendwie egal, ob ich mit X.V. Color arbeite, ich erkenne keinen Unterschied im Waveform.
Edit:Anzeige steht auf Millivolt



Antwort von Reiner M:

Ich hab mal in die geclippten Wolken gefilmt... Danke, olja!

Es ist FCP, oder?

Technisch bestätigst Du die Vorgehensweise. Fakt ist also, dass man so z. B. Stellen, die sonst "ausgebrannt" erscheinen, ein Stück weit retten kann. Ist doch was!

Es lohnt sich übrigens, parallel dazu die RGB-Parade im Auge zu behalten. Man kann dann die Wirkung der Luma-Einstellung auf RGB über das persönliche Empfinden hinaus kontrollieren.

Ja, die Kameras unterscheiden sich. Die Aufnahmen aus meiner Canon 60D DSLR zeigen keine Wellen über "100" (700mV, 100IRE 1.0V ... what ever).

Beste Grüße,
Reiner



Antwort von dienstag_01:

Ist das FinalCut?
Und, was ist das denn für ein dunkler bereich auf einem der beiden Bilder?



Antwort von Jott:

Wer der Sache in NLE A, B oder C wirklich auf den Grund gehen möchte, sollte mal z.B. eine FS 700 nehmen. Die kann nämlich alles umschaltbar anbieten, was euch so umtreibt: Clipping bei 100%, Clipping bei 110% (Ausnutzung von Superwhite), stures 709 etc. - dann kann man wunderbar testen und spielen, die Highlights der 110%-Variante runterziehen und scheinbar verlorene oder nicht vorhandene Zeichnung zurückholen, egal ob am nativen File oder via ProRes ... den theoretischen Überbau dazu kann ja dann jemand beisteuern, der Lust dazu hat, aber braucht man den wirklich?

Das Wichtige in der Praxis ist einfach: selber probieren, sehen und lernen, nur das bringt einen wirklich weiter. Da hat Rainer recht.



Antwort von olja:

Ist das FinalCut?
Und, was ist das denn für ein dunkler bereich auf einem der beiden Bilder? Jo, ist FCPX. Der dunkle Bereich gezackt zeigt das Clipende (glaube ich). Ist ja auch nur aus der Vorschau.

Aber egal. Ich suche gerade nach dem Flag für den erweiterten Farbbereich x.v. Color (muß ja dem Player, NLe irgendwie mitgeteilt werden). Ich erkenne im NLE im Moment 0 Unterschied und schnöcker gerade im Mediainfo.

Zumal so Pauschalaussagen wie abgesoffen oder geclippt = tot, nur halt immer bedingt stimmen. Bei der GH2 trifft das mit den tiefen auch nicht zu. Mit den Höhen habe ich mich noch nie beschäftigt, sondern lieber unterbelichtet.

Deshalb interessantes Thema, die Ergebnisse sind ja auch ohne Pixelpeepen erkennbar, somit also praxisrelevant ;-)



Antwort von domain:


Wichtig ist: Die Wave zeigt in diesem Bereich am oberen Rand noch Ausfransungen, keine durchgängige Linie. Wenn Du nun diesen Bereich unter 100 drückst (nicht beschneiden), so dass die Peaks unter 100 liegen, werden sich vermutlich in den weißen Flächen noch partiell wenige Zeichnungen, ggf. auch Farben (bei Himmelsbildern oft ein ein sehr, sehr helles Blau) zeigen. Zusätzlich gewinnen dann auch die Bereiche mehr Ausdruck, die derzeit nahe an der 100er-Kante liegen, weil sie ja entsprechend nach unten verschoben werden.

Funktioniert das so bei Dir? Ja das funktioniert so bei mir, siehe zweites Bild als ein auf 100% korrigierter Ausschnitt aus dem JVC GZ-HD40 Ausschussclip von oben, wo die Lichter doch ziemlich überzeichnet waren und in der Waveform mit über 100% angezeigt wurden.
Das Thema hat m.E. schon einige Praxisrelevanz. Ich möchte nicht wissen, bei wie vielen Clips ich hätte noch etwas mehr retten können, denn diese Technik wende ich erst seit ca. einem halben Jahr an.





Antwort von dienstag_01:

den theoretischen Überbau dazu kann ja dann jemand beisteuern, der Lust dazu hat, aber braucht man den wirklich? Wenn man still vor sich hin arbeitet, was hier keiner tut, dann ist deine Frage berechtigt. Nicht aber wenn man untereinander in Austausch tritt und der eine von Äpfeln und der andere von Birnen redet.



Antwort von Reiner M:

Jo, ist FCPX. Danke. Also auch FCPX macht das so ... Hätte mich auch gewundert, wenn nicht.
Deshalb interessantes Thema, die Ergebnisse sind ja auch ohne Pixelpeepen erkennbar, somit also praxisrelevant ;-) Ja, es ist für mich höchst praxisrelevant!
Der Antrieb, das zu untersuchen, kam aus der Zeit kurz vor der Entscheidung für die X909, die damals schon bekannt war für "Türkis" in hellen Himmelspartien. Es hat sich schnell herausgestellt, dass das mit der vorgestellten Methode ohne Eingriff in die Farben super easy korrigierbar ist. Es ist also kein Farbstich. Die Entscheidung war getroffen.

Praxisrelevant: Da eh jeder Schnipsel durchs NLE muss, korrigiere ich das Türkis nebenbei gleich mit weg, wenn nötig.
Ergibt insgesamt schöne Aufnahmen.

Daher hatte ich X909-Nutzern mit Premiere Pro als NLE, die unzufrieden waren mit "ihrem" Türkis diesen Tipp schon öfter hier gegeben. Geht aber offensichtlich auch mit anderen NLEs.

Beste Grüße,
Reiner



Antwort von dienstag_01:

;)
De Reiner ist schon ein Super-Typ.



Antwort von Reiner M:

Ja das funktioniert so bei mir, siehe zweites Bild als ein auf 100% korrigierter Ausschnitt aus dem JVC GZ-HD40 Ausschussclip von oben, wo die Lichter doch ziemlich überzeichnet waren und in der Waveform mit über 100% angezeigt wurden.
Das Thema hat m.E. schon einige Praxisrelevanz. Ich möchte nicht wissen, bei wie vielen Clips ich hätte noch etwas mehr retten können, denn diese Technik wende ich erst seit ca. einem halben Jahr an. Schöne Ergebnisse! Manch ein Video gewinnt eben tatsächlich dadurch. Zwar nicht viel, aber eben Bildinhalt, der die Bildwirkung positiv beinflusst.

Danke, domain!

Beste Grüße,
Reiner



Antwort von dienstag_01:

@olja
Was willst du mit x.v. Color?
Ich denke, auch bei dir ist es wie bei den anderen: 0 milliVolt entspricht einem Lumawert von 16 und 700mV dem von 235. Laut Standard. Und so kommt es aus der Kamera. (plus Überschwinger) Damit in deinem NLE nicht alles flau aussieht, mappen sie das auf 0-255. Wenn du es ausgibst, nach 709, wird daraus wieder 16-235, ein Videoplayer auf deinem Computer macht daraus wieder 0-255.
x.v. Color wäre doch nur interessant, wenn die Kamera schon anders aufnehmen würde.



Antwort von olja:

@olja
Was willst du mit x.v. Color?
Ich denke, auch bei dir ist es wie bei den anderen: 0 milliVolt entspricht einem Lumawert von 16 und 700mV dem von 235. Laut Standard. Und so kommt es aus der Kamera. (plus Überschwinger) Damit in deinem NLE nicht alles flau aussieht, mappen sie das auf 0-255. Wenn du es ausgibst, nach 709, wird daraus wieder 16-235, ein Videoplayer auf deinem Computer macht daraus wieder 0-255.
x.v. Color wäre doch nur interessant, wenn die Kamera schon anders aufnehmen würde. Ich will eigentlich nichts damit. Reine Neugier, wie es im NLE oder Wavefom aussieht, wenn ich in der Cam den Modus schalte. Und wenn ich was umschalte, erwarte ich irgendwie ein anderes Ergebnis. Wozu sollte es denn eigentlich sonst gut sein ?
http://de.wikipedia.org/wiki/X.v.Colour

War nur so mal Zwischendurch, da ich gerade bei dem Thema bin ;-)



Antwort von domain:

Das gesamte Thema ist speziell für mich schon immer etwas mit Frust verbunden gewesen, weil der Waveformmonitor ein eigenes Vorschaubild liefert, das mit dem Vorschaubild der Timeline nicht übereinstimmt.
Im Waveform-Monitor wird in Liquid nämlich immer der gesamte Wertebereich angezeigt.
Also konkret: in der Timeline ein Himmel ev. mit Türkisstich, aber im Waveformonitor ein weicheres Bild mit schönem Himmelblau.
Alles zusammen halt ein ziemliches Kuddelmuddel, ein Wirrwarr und zum junge Hunde kriegen :-)



Antwort von olja:

Das gesamte Thema ist speziell für mich schon immer etwas mit Frust verbunden gewesen, weil der Waveformmonitor ein eigenes Vorschaubild liefert, das mit dem Vorschaubild der Timeline nicht übereinstimmt.
Im Waveform-Monitor wird in Liquid nämlich immer der gesamte Wertebereich angezeigt.
Also konkret: in der Timeline ein Himmel ev. mit Türkisstich, aber im Waveformonitor ein weicheres Bild mit schönem Himmelblau.
Alles zusammen halt ein ziemliches Kuddelmuddel, ein Wirrwarr und zum junge Hunde kriegen :-) Verstehe ich jetzt nicht so ganz...welchen Sinn hat das Ganze dann ? Ich will doch skimmen und zeitgleich den Waveform betrachten. Die Position des Playheads muß doch identisch mit der Timeline und Waveform sein. Noch besser sogar vertikal, anlog dem Bild. (paßt aber auch bei FCPX nicht soo ganz)



Antwort von domain:

Verstehe ich auch nicht, aber vielleicht funktioniert das aufpoppende Waveformfenster in Overlay-Technik und ich habe am Grafikkartentreiber zu viel herumgekurbelt, also selber schuld.
Man muss gewisse Sachen positiv sehen, So erkenne ich wenigstens auf Anhieb, wie das Bild aussehen könnte, wenn auch der 100+ Bereich integriert wäre und danach muss ich ihn halt bewusst herunterziehen. Sehr groß sind die Abweichungen zur Timelinevorschau ja nicht.



Antwort von dienstag_01:

Man muss gewisse Sachen positiv sehen, So erkenne ich wenigstens auf Anhieb, wie das Bild aussehen könnte, wenn auch der 100+ Bereich integriert wäre Na jetzt wirds Quatsch, mehr als 255 kann dein Monitor sowieso nicht ;)



Antwort von domain:

Ja das ist klar. Nein der Gradationsverlauf ist einfach ein anderer. Aber eigentlich bräuchte ich nur den Waveformonitor alleine, denn sobald er weggeklickt wird, sehe ich den Effekt ohnehin spontan in der Timeline.



Antwort von Angry_C:

Was für ein Theater wegen eines Premiere Bugs hier.

Ich konnte es nicht lassen und habe mir die Premiere CC Testversion installiert, um zu sehen, warum sich hier quasi gestritten wird.

Es wurde ganz am Anfang geschrieben, dass es sich nur um den RGB Kurven Effekt handeln würde und der Luminanzkurveneffekt immer noch so arbeitet wie bei Premiere Pro 6.

Das ist bei mir nicht der Fall. In meinen Tests betrifft es sehr wohl die Luminanzkurve.

Ziehe ich ein MTS-File der Panasonic X929 rein, bei dem die Highlights mal wieder über 100% liegen, weil sie nunmal bis 255 aufzeichnet und lege dort, wie ich es neuerdings nach Reiners tollen Tipp immer handhabe, den Luminanzkurveneffekt drauf, dann schneidet dieser alleine schon beim aktivieren des Effekts alles über 100% ab, und somit sind die ganz hellen Partien für die Rückgewinnung verloren. (Also nix aus türis wird blau).

Bis Premiere Pro 6 passierte beim Aktivieren des Filtern gar nichts, und ich konnte oben den Endpunkt der Kurve anfassen und alles so weit mit der dringend benötigten Stauchung nach unten ziehen, um bei den ausgebrannten Stellen die Zeichnung wieder hereinzuholen und auch das Türkis zu berichtigen.

Das ist jetzt nicht mehr möglich! We kann man (z.B. Wowu) bei Premiere CC dann von Bugbeseitigung reden???



Antwort von WoWu:

Hallo Angry_C

Die Fakten liegen doch auf der Hand:

1) Es existiert ein Standard, nach dem Videosignale gehandhabt werden. (REC 709-für 8 oder 10 Bit) Danach werden 8 Bit im Wertebereich von 16-235 übertragen.

2) Es existierte eine nicht standardisierte Übertragungsmethode auf der Basis der FotoCD von Kodak, in dem Videosignale auch in Bereichen ausserhalb des Standards übertragen werden können (1-16 / 235-255) (x.v.Color oder xvYCC)

Das Tool erwartet also ein standardkonformes Videosignal innerhalb der zugelassenen Werte und kein proprietäres Signal.
Es verhält sich als standard-konform.

Nun sagst Du, die Kamera nimmt nicht standard-konform auf.
Das bedeutet, sie arbeitet (demnach immer) im xvYCC Mode, denn irgendwelche "Zwischenmodi" gibt es im Standard nicht.

Besonders hässlich ist das natürlich, weil bei xvYCC schon aufgrund der anderen monochromatischen Primärfarben es bei einer solchen ausbleibenden Tranformation zu Farbverschiebungen im Spektrum kommt.

Das wäre also nicht weiter tragisch, wenn die entsprechende Signalisierung zum Folgegerät funktioniert und ein korrektes Mapping durchgeführt würde.

Sowohl das Signalbit muss dabei von der Kamera gesetzt sein als auch vom NLE verstanden und korrekt interpretiert werden.

Geschieht das nicht, liegt ein Fehler vor.
-entweder in der Kamera oder im NLE-, nicht jedoch im Tool, das ein normgerechtes Videosignal verarbeiten soll.

Nur suchen müsst Ihr den Fehler schon allein.
Sich darüber aufzuregen, dass Adobe sich an den Standard hält, bringt es ja nun auch nicht.



Antwort von Angry_C:

Das leuchtet mir soweit ein, daher mäkelte ich ja auch zu genüge an der SD909-X929 herum.

Ich denke aber nicht, dass Adobe sich im Falle von Premiere CC bewusst an Standards gehalten hat. Es wird ein Fix geben.

Adobe ist sicherlich daran interessiert, alle Kameras unterstützen zu können. Die Panasonic Consumer Camcorderreihe, die seit Jahren einen hohen Stellenwert einnimmt, ist sicherlich nicht einzige, die über dem Standard hinaus aufzeichnet.

Mit der alten Luminanzkurve konnten alle Kameras behandelt werden, mit der neuen nicht mehr.



Antwort von WoWu:

Warten wir den Fix mal ab.
Und, ich gebe Dir Recht, natürlich will Adobe möglichst viele Kameras unterstützen, wird aber von Standards nicht abweichen.
Es ist ja auch möglich, Kameras ausserhalb des Standards zu unterstützen. Man muss nur finden, woran es liegt, dass die Bereiche im xvYCC Bereich nicht signalaisiert werden, zumal es ja offenbar funktioniert, denn Reiners File habe ich ja korrekt Mappen können, nur eben nicht mit einem Adobe Programm.
Bleibt also festzustellen, warum die Signalisierung mal klappt und mal nicht.
Denn Verfahren für ein korrektes xvYCC Mapping gibt es ja.
Und die Signalisierungsverfahren sind ja auch in HDMI etabliert, daran mangelt es also auch nicht.
Warum also sollte Adobe hier vom Standard abweichen ?
Sinnvoller wäre ein korrektes Mapping.
Warten wir es also ab, ob - und ggf. wie- ein Fix stattfindet.



Antwort von domain:

Bleibt also festzustellen, warum die Signalisierung mal klappt und mal nicht.
Denn Verfahren für ein korrektes xvYCC Mapping gibt es ja.
Und die Signalisierungsverfahren sind ja auch in HDMI etabliert, daran mangelt es also auch nicht.
Warum also sollte Adobe hier vom Standard abweichen ?
Sinnvoller wäre ein korrektes Mapping.
Warten wir es also ab, ob - und ggf. wie- ein Fix stattfindet. Die Antwort ist m.E. ganz einfach: die eigentlichen Programmierer führen nur Anweisungen ihrer Vorgesetzten aus, also quasi mit Null Ahnung von der Materie selbst behaftet. Wenn aber selbst die „Anschaffer“ zu wenig von der Materie verstehen, dann kommt eben so ein derzeit immer noch zu beobachtender Murks heraus, dessen Bereinigung offenbar Jahre dauern kann.
Bei der sieben Jahre alten Mumie Liquid wundert es mich nicht, dass sie xvYCC mit dem konventionellen Timeline-Gamma durcheinander mischten, aber bei den neueren Programmen schon sehr.



Antwort von WoWu:

Da bin ich gar nicht sicher, dass die Kamera das nicht schon hat.
Seitdem HDMI 1.3a im Nov 2006 veröffentlicht wurde, ist das eigentlich jedermann zugänglich.
Es gibt in jedem Datensatz die 'Gamut Boundary Description'. Dort findet jede Hard-und Software die Gamutbeschreibung.
Man müsste eben nur wissen, ob Adobe die ausliest und was da von Seiten Pana reingeschrieben wird:
"0b000 oder 0b010" Das wären die beiden Vaianten, die nach meiner Einschätzung in Frage kämen.
Vielleicht hat ja jemand Gelegenheit, nachzuschauen, dann wüsste man, ob Pana da goofed oder Adobe. Vielleicht sagt Adobe ja auch "wie haben mit HDMI nix am Hut".... ergo, lesen wir die Discriptoren nicht aus.
Das wäre natürlich 'saudumm'.



Antwort von dienstag_01:

Ich vermute, irgendwie ist das anders.
Ich hatte eine Sony EX1, Olja eine Canon Legria und Reiner, glaube ich, eine Pana.
Die NLEs, von denen hier Bilder mit Werten oberhalb von 235/100 angezeigt werden, sind Avid, Premiere und FCP.
Das ist doch nicht mal eben son kleiner Flüchtigkeitsfehler.



Antwort von WoWu:

Erstens werden oft Überschwinger mit Signalinhalt verwechselt und zweitens gibt es nun mal diese festen Regeln.
Es gibt den Standard, es gibt die Gamuts und es gibt die Signalisierungen für die gamuts, ebenso wie definierte Konvertierungen.

Die Firmen können sich nun daran halten, oder auch nicht.

Ich bin der Meinung, die, die sich nicht daran halten, sollten das als BUG ansehen.
Insofern ist Adobe da ja auf dem richtigen Weg. Fehlt offenbar nur noch das Auslesen der Steuerbits. (?)

Und auf das Mischmasch der unterschiedlichen Ergebnisse bei unterschiedlichen Usern und NLEs würde ich erst einmal ein grosses Fragzeichen setzen.
Du siehst doch, was alles wofür gehalten wird ... und mit welchen haarstreubenden Herleitungen.
Dabei liegen die Fakten auf dem Tisch.

Es kann natürlich auch sein, dass es da noch Missverständnisse in den verantwortlichkeiten gibt:
Wenn Pana immer in xvYCC schreibt, es auch signalisiert, der Monitor sich auch umstellt, heisst das dann auch, dass z.B. ein NLE eine Konvertierung vornehmen muss ???
Oder müsste Pana bei nicht xvYCC ein anderes Gamut produzieren ?
Die Verantwortlichkeiten sind nicht so ganz klar, ich könnte mir aber ebenso gut Letzteres vorstellen.



Antwort von domain:

Das beinahe schon etwas Tragische an der ganzen Angelegenheit ist ja, dass wir bisher immer glaubten, dass die Türkisverfärbungen im Himmel ein typischer Farbstich speziell der Panas wäre.
Das geht ja nun schon über die Jahre, ohne dass man die eigentliche Ursache bisher erkannte und die ist ganz anders geartet als man dachte.
Div. Erkenntnisse kamen ja erst in den letzten Monaten auf, aber wieviele User haben sich über „Farbstiche“ schon bisher gekrämpft und sie auch in ihre finalen Videos übernommen?
Dabei wäre aus meiner Sicht die Lösung schon seit Jahren ziemlich einfach gewesen: man gehe einfach davon aus, dass die moderneren Kameras alle Superweiß codieren können.
Wenn eine Altmodische dann nur bis 235 codieren kann, dann sieht das Bild im NLE in den Lichtern halt etwas matt Grau aus, ist auch keine Tragödie, der Unterschied ist minimal.
Wenn irgendjemand aber seine Superweißvideos TV-konform rausrendern wollte, dann kann es doch bitte für kein NLE ein Problem sein, die 255-Werte in den eingeengten 235-Raum umzumappen.



Antwort von WoWu:

Das liegt eigentlich nur daran, dass solche Probleme in Foren besprochen werden, in denen sich die Meisten um keinen Standard kehren, geschweige denn, sie kennen.
Eine Problemherleitung ist eigentlich ganz trivial, wenn man die Rahmenbedingungen kennt und nicht gleich jeden Spike für ein Nutzsignal hält.
Das ist, wie in der Schule ... wer das Ein-mal-Eins kennt, kann auch rechnen. Die andern können nur bezahlen, was auf der Kasse steht.



Antwort von gast5:

Das kannst du mit deiner hd40 ebenso nachstellen wie der HD 3 und der HD 7 von jvc das sich per Menü ein und aus schalten lässt..

Mach mal den Versuch Peter, mal mit mal ohne.. Danach staunen was die alte Software noch so drauf hat.. ..

Die Geschichte hat in dem Fall drei Namen bei pana.. Deep color, xvColorsystem und digital Cinema color.. von 0-255....



Antwort von Reiner M:

Ich bin der Meinung, die, die sich nicht daran halten, sollten das als BUG ansehen. Bisher wurde hier in diesem Zusammenhang kein einziges NLE genannt und vorgestellt, das das anders machen würde.
Die hier bisher vorgestellten funktionieren alle gleich.
Aber kommt ja vielleicht noch.

Beste Grüße,
Reiner



Antwort von Angry_C:

Das kannst du mit deiner hd40 ebenso nachstellen wie der HD 3 und der HD 7 von jvc das sich per Menü ein und aus schalten lässt..

Mach mal den Versuch Peter, mal mit mal ohne.. Danach staunen was die alte Software noch so drauf hat.. ..

Die Geschichte hat in dem Fall drei Namen bei pana.. Deep color, xvColorsystem und digital Cinema color.. von 0-255.... Ja so einen Cinemamode hat die Panareihe, und in der Beschreibung wir auch der größere Farbraum erwähnt, trotzdem erzeugt die Kamera auch mit ausgeschaltetem Cinema Color Mode Helligkeitswerte weit über 100% und das sind keine Spikes.

Ausgefressene Wolken oder weiße T-Shirts lassen sich mit ihrer ganzen Zeichnung vollständig restaurieren".

Vielleicht hat ja auch Panasonic seit Jahren einen Bug in ihren Kameras und der erweiterte Farbraum lässt sich gar nicht abschalten?



Antwort von Angry_C:

Da bin ich gar nicht sicher, dass die Kamera das nicht schon hat.
Seitdem HDMI 1.3a im Nov 2006 veröffentlicht wurde, ist das eigentlich jedermann zugänglich.
Es gibt in jedem Datensatz die 'Gamut Boundary Description'. Dort findet jede Hard-und Software die Gamutbeschreibung.
Man müsste eben nur wissen, ob Adobe die ausliest und was da von Seiten Pana reingeschrieben wird:
"0b000 oder 0b010" Das wären die beiden Vaianten, die nach meiner Einschätzung in Frage kämen.
Vielleicht hat ja jemand Gelegenheit, nachzuschauen, dann wüsste man, ob Pana da goofed oder Adobe. Vielleicht sagt Adobe ja auch "wie haben mit HDMI nix am Hut".... ergo, lesen wir die Discriptoren nicht aus.
Das wäre natürlich 'saudumm'. Wie und wo kann ich das nachschauen?



Antwort von WoWu:

Kann man dadurch feststellen, indem man die Signalisierung ausliest, sofern die Kamera zwei unterschiedliche Modi zulässt.
Man muss einfach nicht weiter rumspekulieren.
Das hat, wie domain schon sagte,. über Jahre keinen weiter gebracht.
Es gibt harte Fakten, an denen man das aufklären kann.

Man muss in den Datenstrom reinschaun.
Bubble könnte das vielleicht, weil man ein Entwicklungstool dafür braucht.

Du köntest mal ausprobieren, was sich in den 2 Modi denn bei HDMI tut, ob es da Unterschiede gibt, weil man mit hoher Wahrscheinlichkeit annehmen kann, dass die Fernseher die Werte korrekt auslesen.



Antwort von Reiner M:

Neben den hier schon genannten HD-Cams kann ich auch noch eine SD DV PAL stellen, meine alte Pana NVGS250. Auch sie liefert die Signale oberhalb "100".

Beste Grüße,
Reiner



Antwort von WoWu:

Das kannst Du gern machen, mich interessiert in diesem Zusammenhang aber erst einmal eine moderne Kamera, von der man ausgehen kann, dass sie sich in einem technisch aktuellen Zustand befindet.
Und kein Konvolut an Erkenntnissen, die man nach Belieben einordnen kann.
Das war das Manko der ganzen Jahre.



Antwort von Reiner M:

Nun, es wurde aber auch die ganzen Jahre nicht anders gelöst, als es in den NLEs gelöst ist.

Das Spannende ist für uns nun nur, dass es da einen Bereich gibt, der für die Bearbeitung der Videodaten am PC bedeutsam ist und unser Augenmerk verlangt.

Selbst dann, wenn es ein "Bug" wäre, der sich festgefressen hat in zahllosen NLEs über Jahre hinweg, in unterschiedlichen Cams oder sonstwo (was ich alles kaum glauben kann - it is like it is - works as designed), sollte man die Augen davor nicht verschliessen. Es geht um praxisrelevanz. Und in der Praxis treffen solche Cams mit solchen NLEs zusammen. Haufenweise. Täglich.

Die Lösung ist längst gegeben.

Beste Grüße,
Reiner



Antwort von WoWu:

Das ist, wie mit dem Gammashift bei Apple, der hat sich auch 20 Jahre gehalten und jeder musste nachkurbeln, weil Apple noch das Gamma ihrer Laserdrucker unterstützt hat.
Meinst Du das in etwa ?

Das ist doch Quatsch, was Du da erzählst, dass es eine Lösung sei, hinterher zu kurbeln, sich den ganzen Farbverlauf zu zerquetschen und sich jede Menge Artefakte einzuhandeln, nur weil Dir nichts besseres als ein schlechter Workaround einfällt.

Was hast Du dagegen, einmal die Ursache zu finden und zu benennen ?

Aber- keiner hindert Dich daran, weiter so zu arbeiten. So ist das ja nicht.



Antwort von dienstag_01:

Ich muss mich hier auch nochmal einklinken.
Bei der Bearbeitung von völlig überbelichteten Files (Austausch - Avid-After Effects, DNxHD) ist mir schon mal passiert, dass es zu reproduzierbaren Fehlern in Form von farbigen Klötzchen im Bild gekommen ist.
Ich hab die nur verhindern können, wenn ich den bist 255 überbelichteten Bereich schon vor dem Austausch runtergezogen habe.
Hier im Thread stand was von Lumawerten bis 240. Ist das korrekt? Sollte dort die Grenze sein? Das Material war NTSC (wie auch die Waveforms hier von mir), natürlich HD.



Antwort von Reiner M:

@Wowu
Nein, ich meine:
Alle NLEs (nicht nur eins), die bisher hier vorgestellt wurden, arbeiten gleich. Richtig?
Viele Cams (nicht nur die Panas und nicht nur HD) zeigen in diesen NLEs Werte über 100. Richtig?
Es handelt sich dabei weder um Noname-Produkte fragwürdiger Herkunft, noch um die Spielzeugabteilung.

Jedoch: Sie arbeiten eben allesamt nicht so, wie Du es erklärst.

Ich habe nichts dagegen, die Ursachen zu finden. Ich denke aber, das ist geschehen.

Beste Grüße,
Reiner

PS zum Thema "Quatsch" ;)
Unabhängig vom Problem: Eine Lösung ist doch dann gut, wenn sie zum Erfolg führt.
Zu diesem speziellen "Problem": Die Hersteller der NLEs bieten unterschiedliche Werkzeuge an, um diesen Bereich manipulieren zu können wie Clipper oder Curves.
Was bietest Du?



Antwort von WoWu:

Alle NLEs (nicht nur eins), die bisher hier vorgestellt wurden, arbeiten gleich. Richtig? Nein zeigen in diesen NLEs Werte über 100. Richtig? Transienten: Ja
Videomaterial: Nein
Sie arbeiten eben allesamt nicht so, wie Du es erklärst. Nicht ich erkläre das, sondern die Norm, nach der ALLE Videorecorder arbeiten, nach der z.B. HDMI arbeitet, alle Broadcaster und alle TV Geräte: SMPTE 240M / 260
Ich zeige nur auf, was in dieser Norm steht.
Und jeder Hersteller, der sich nicht sofort mit -non-konformität- aus dem Markt katapultieren will, wird sich an diesen Standard halten.
Nur einer bezweifelt das ... Du ... Richtig ?
Ich denke aber, das ist geschehen. Du hast einen Workaround, deine türkisfarbenen Bilder einzufärben, aber nicht die Lösung des Problems.
Wenn Du an der Stelle das Denken einstellen willst, kannst Du Dich gern auf diesen Workaround zurückziehen.
Es hindert Dich doch keiner.

@dienstag_01

Jau, Chroma geht bis 240

@ Reiner

Nun Fang doch nicht an den begriff "Lösung" neu zu definieren, ich glaube, jeder kann sich den begriff schon allein definieren.
Für Dich ist Lösung eben das, was für Andere Workaround ist ... ist ja ok.



Antwort von Reiner M:

Und jeder Hersteller, der sich nicht sofort mit -non-konformität- aus dem Markt katapultieren will, wird sich an diesen Standard halten.
Nur einer bezweifelt das ... Du ... Richtig ? Nö! ;) Ganz im Gegenteil! Ist ja meine Rede ...

Du hast sehr schön den Grund beschrieben, warum es in den NLEs genau so implementiert ist, wie es ist. Wären diese Hersteller - gemäß Deiner Aussage! - nicht alle längst weg vom Fenster, wenn das ein Dauer-Bug wäre?

An derTatsache, dass es die Hersteller so implentieren - sowohl die der Cams, wie auch die der NLEs! - kommt man eben nicht vorbei.

Nur einer weiß es eben besser als die zahllosen Entwickler und Entwicklergenerationen bei den Herstellern ... Du ... Richtig? ;)

Kann ja sein - ist aber nicht praxisrelevant. ;)

Ich habe Dir den Tipp schon öfter gegeben: Setzt Dich doch mal mit deren Labore zusammen. Womöglich klärt sich das ganz einfach auf. Womöglich werden sie Dir dankbar sein. Andersrum hätten sie längst einen Clipper vor den Importer der NLEs oder in die Cams geklebt, wenn das so sein müsste wie Du schreibst. Nichts leichter als das.

Aber wurscht.

Beste Grüße,
Reiner



Antwort von WoWu:

Ich würde mich nun nicht mehr so gern an den Diskussionen der Spekulationen beteiligen und mit denen, die Interesse an einer Lösung haben, gern dem Kern widmen.



Antwort von gast5:

Ich kann mich noch an die Zeit erinnern als diese eine Thematik der XvColorsysteme bei den jvc eingeführt wurden und Vegas 8 glaube ich mit der Unterstützung dieses Systems angefangen hatte..

Ich bin mir nicht mehr ganz sicher aber die Software konnte angewiesen werden das Projekt zur Gänze als xvColor anzusehen.. Ich bin mir nicht 100% sicher das ein Automatismus besonders beim Mischbetrieb mit unterschiedlichen Materialien zuverlässig wäre ..

Marco oder Wolfgang kann da sicher genaueres dazu sagen..

Ich habe eine solche jvc und auch eine pana v 707 da und werd's im laufe des Tages testen wenn gewünscht... Eines weis ich schon jetzt nachgewiesen in einigen Projekten, die 707 fährt von 0-255.... Nachgewiesen in fcpx und davinci Ressolve.. Und die prores bleiben im selben Bereich...



Antwort von k_munic:

… , die 707 fährt von 0-255.... Nachgewiesen in fcpx ... .... für mich sieht das grad anders aus:
Pana707, allerdings in einem AutomatikModus (Sport), in FCPX, NICHT optimiert/proxy etc:


zum Bild


Wie man 'schön' sieht durch die clipping Kante, ist da oben bei ca. bei 108% ;) Schluss, unten geht's ganz runter bis Null.....



Antwort von Angry_C:

.... für mich sieht das grad anders aus:
Pana707, allerdings in einem AutomatikModus (Sport), in FCPX, NICHT optimiert/proxy etc:


Wie man 'schön' sieht durch die clipping Kante, ist da oben bei ca. bei 108% ;) Schluss, unten geht's ganz runter bis Null..... Nichts anderes hat Motiongroup geschrieben. 255=107% ;-)



Antwort von olja:

.... für mich sieht das grad anders aus:
Pana707, allerdings in einem AutomatikModus (Sport), in FCPX, NICHT optimiert/proxy etc:


Wie man 'schön' sieht durch die clipping Kante, ist da oben bei ca. bei 108% ;) Schluss, unten geht's ganz runter bis Null..... Nichts anderes hat Motiongroup geschrieben. 255=107% ;-) Superwhite=109%


egal, K_munic, was passiert denn, wenn du die Höhen auf 100 absenkst ?



Antwort von dienstag_01:

Ich könnte wetten, dass bei euch (FCP) 100% dem Wert 255 entsricht. Probierts mal aus.



Antwort von DV_Chris:

Ich könnte wetten, dass bei euch (FCP) 100% dem Wert 255 entsricht. Probierts mal aus. So etwas kann man wohl in jedem Schnittpgrogramm leicht überprüfen, wenn das entsprechende Programm diverse normgerechte Farbbalken erzeugen kann.



Antwort von Angry_C:

Ich könnte wetten, dass bei euch (FCP) 100% dem Wert 255 entsricht. Probierts mal aus. Hab es vor einigen Wochen schon probiert. 100% = 235. In Premiere wie auch in FCPX.

Stellt man die Nvidia Grafikkarte auf 16-235 und zieht die Highlights in Premiere unter 100%, so kommt exakt dann die Zeichnung in ausgefressenen Stellen am Monitor zurück. Das sollte doch Beweis genug sein, oder?



Antwort von k_munic:

… Nichts anderes hat Motiongroup geschrieben. 255=107% ;-) … ihr macht mich fertig! :)
0-255 ist nicht 0-100IRE bzw 0-700mV?

… wer denkt sich denn sowas aus??? LOL

… egal, K_munic, was passiert denn, wenn du die Höhen auf 100 absenkst ?

zum Bild


… dann taucht zB rechts oben in den Wolken Zeichnung auf.
Da wo nur noch gerade Linie war/ist, seh ich immer noch nix .... bzw plattes Weiß - was mich jetzt nicht überrascht.-



Antwort von Angry_C:

… ihr macht mich fertig! :)
0-255 ist nicht 0-100IRE bzw 0-700mV?

… wer denkt sich denn sowas aus??? LOL

Das wurde in diesem Thread eigentlich schon mehrfach erklärt.



Antwort von dienstag_01:

Es brigt nichts, an den Einstellungen der Grafikkarte rumzuspielen.
Entweder es gibt einen Color Picker im NLE oder aber man verwendet den von Photoshop.



Antwort von k_munic:

… Das wurde in diesem Thread eigentlich schon mehrfach erklärt. Da bin ich mir sicher. Ganz sogar.-
Aber so, dass ICH es nicht verstanden habe.

… Ingenieure (und Rechtsanwälte) hatten zu meinen Berufszeiten immer viel Spaß mit mir ..... :D

Bin ein schlichtes Gemüt ...........



Antwort von olja:

Überflieg doch mal :-)
http://www.kenstone.net/fcp_homepage/vi ... tress.html

und auch schon 2007 wurde bei slashcam über x.v. colors geschrieben
https://www.slashcam.de/artikel/Grundla ... lles-.html



Antwort von domain:

Bei 107% kann es sich aber nur um einen empirisch ermittelten Wert handeln.
Der exakte Wert beträgt 108,5106383% als Maximum ;-)



Antwort von dienstag_01:

Überflieg doch mal :-) Ich weiss ja nicht, ob du überhaupt mich gemeint hast ;)
Es gibt aber etwas zu bedenken (und ich glaube, das ist auch in FCP so): die Videolevel 16-235 werden für die Anzeige auf 0-255 gemappt. Das ist, wie wir in diesem Thread sehen konnten, in einigen, nicht allen, Programmen so. Deshalb kommt es immer wieder zu Verwirrung/Missverständnissen. Deshalb verwendet ja FCP auch eine Skala von 0-100 und nicht die dazugehörigen bit-Werte. Denn das wäre dann richtig falsch.



Antwort von olja:

Ich könnte wetten, dass bei euch (FCP) 100% dem Wert 255 entsricht. Probierts mal aus. Hab es vor einigen Wochen schon probiert. 100% = 235. In Premiere wie auch in FCPX.
sonst würde man ja kein Abschneiden bei "Sendefähige Farben" sehen. Denn der drückt auf 235, schneidet ab und die Linie endet bei 100 (wo sie vorher drüber war, 109).

Aber ich spiel heute auch nochmal mit rum.



Antwort von olja:

Überflieg doch mal :-) Ich weiss ja nicht, ob du überhaupt mich gemeint hast ;)
Es gibt aber etwas zu bedenken (und ich glaube, das ist auch in FCP so): die Videolevel 16-235 werden für die Anzeige auf 0-255 gemappt. Das ist, wie wir in diesem Thread sehen konnten, in einigen, nicht allen, Programmen so. Deshalb kommt es immer wieder zu Verwirrung/Missverständnissen. Deshalb verwendet ja FCP auch eine Skala von 0-100 und nicht die dazugehörigen bit-Werte. Denn das wäre dann richtig falsch. Ne, ich meinte k_munic :-)

FCPX kannst Du auf Millivolt einstellen. Hier sollte es eigentlich keinen Interpretationsspielraum mehr geben. Guck mal mein Beispiel. Das geht über 700 (also 235)
http://forum.slashcam.de/download.php?id=9549

Mit der GH2 ist bei 700 schluß. Aber ich probier heute abend nochmal was.



Antwort von Angry_C:

Ich könnte wetten, dass bei euch (FCP) 100% dem Wert 255 entsricht. Probierts mal aus. Hab es vor einigen Wochen schon probiert. 100% = 235. In Premiere wie auch in FCPX.
sonst würde man ja kein Abschneiden bei "Sendefähige Farben" sehen. Denn der drückt auf 235, schneidet ab und die Linie endet bei 100 (wo sie vorher drüber war, 109).

Aber ich spiel heute auch nochmal mit rum. Warum nicht? Wenn das X929 Video mit max 109% reinkommt, sieht man beim "Sendefähige Farben" ein Abschneiden sofort auf dem Waveform. Er drückt auch nicht auf 235 sondern er schneidet alles oberhalb ab und weg ist es.

Ungünstige Lösung.

Ich stauche lieber mit der Luminanzkurve.



Antwort von dienstag_01:

Videocam: 16-135
NLE (Premiere etc.): gemapped auf 0-255
Export als Video (709): 16-235



Antwort von olja:

Ich könnte wetten, dass bei euch (FCP) 100% dem Wert 255 entsricht. Probierts mal aus. Hab es vor einigen Wochen schon probiert. 100% = 235. In Premiere wie auch in FCPX.
sonst würde man ja kein Abschneiden bei "Sendefähige Farben" sehen. Denn der drückt auf 235, schneidet ab und die Linie endet bei 100 (wo sie vorher drüber war, 109).

Aber ich spiel heute auch nochmal mit rum. Warum nicht? Wenn das X929 Video mit max 109% reinkommt, sieht man beim "Sendefähige Farben" ein Abschneiden sofort auf dem Waveform. Er drückt auch nicht auf 235 sondern er schneidet alles oberhalb ab und weg ist es.

Ungünstige Lösung.

Ich stauche lieber mit der Luminanzkurve. Natürlich (wenn man überhaupt über 100 kommt), sonst ist das ja alles sinnlos hier ;-) Ich schaff das nur mit einem Camcorder.

Das Beispiel sollte nur dazu dienen, das 100% nicht 255 sind. Dann müßte der Effekt ja unterhalb von 100 kappen, damit es 235 sind ;-)
Macht er aber nicht. Sendefähige Farben cuttet bei 100 (oder eben 700mV) Reines Gedankenspiel


Evtl. kann ja Reiner mal sein Clippchen für alle zur Verfügung stellen, damit man wenigstens die gleiche Basis für die Spielereien hat.



Antwort von Angry_C:

Hab es vor einigen Wochen schon probiert. 100% = 235. In Premiere wie auch in FCPX.
sonst würde man ja kein Abschneiden bei "Sendefähige Farben" sehen. Denn der drückt auf 235, schneidet ab und die Linie endet bei 100 (wo sie vorher drüber war, 109).

Aber ich spiel heute auch nochmal mit rum. Warum nicht? Wenn das X929 Video mit max 109% reinkommt, sieht man beim "Sendefähige Farben" ein Abschneiden sofort auf dem Waveform. Er drückt auch nicht auf 235 sondern er schneidet alles oberhalb ab und weg ist es.


Ungünstige Lösung.

Ich stauche lieber mit der Luminanzkurve. Natürlich (wenn man überhaupt über 100 kommt), sonst ist das ja alles sinnlos hier ;-) Ich schaff das nur mit einem Camcorder.

Das Beispiel sollte nur dazu dienen, das 100% nicht 255 sind. Dann müßte der Effekt ja unterhalb von 100 kappen, damit es 235 sind ;-)
Macht er aber nicht. Sendefähige Farben cuttet bei 100 (oder eben 700mV) Reines Gedankenspiel


Evtl. kann ja Reiner mal sein Clippchen für alle zur Verfügung stellen, damit man wenigstens die gleiche Basis für die Spielereien hat. Ach so, ja das stimmt.

Ich bin auch erst vor 2 Jahren mit der SD909 darauf gestoßen, dass bei der Panasonic etwas anders ist als bei anderen Camcordern.

Eigentlich kommt man, wenn man nicht stark unterbelichtet, immer weit über 100%.

Das ist eben bei der neuen X929 auch noch so. Daher rate ich auch jedem von einer Panasonic ab, der nicht jeden Clip durchs NLE ziehen möchte.



Antwort von gast5:

Als Auszug von panasonic..

Aufzeichnung von Videos mit intensiveren Farben mit x.v.ColourTM-Technologie.
≥ Schalten Sie in den Manuellen Modus. (l 69)
≥ Richten Sie auf , , , oder ein. (l 56)
≥ Verwenden Sie für wirklichkeitsgetreuere Farben ein HDMI-Mini-Kabel (Sonderzubehör) mit einem Fernseher, der x.v.ColourTM unterstützt.
≥ Wenn Videos, die mit dieser Funktion auf aufgenommen wurden, auf einem Fernsehgerät wiedergegeben werden, das nicht mit x.v.ColourTM kompatibel ist, werden die Farben unter Umständen nicht korrekt wiedergegeben.
≥ Es wird geraten, mit der Einstellung aufzunehmen, wenn das Video auf einem anderen Gerät als einem zu x.v.ColourTM kompatiblen wiedergegeben wird.
≥ x.v.ColourTM ist eine Bezeichnung für Geräte, die mit dem xvYCC-Format, einem internationalen Standard für erweiterte Farben in Videoaufnahmen, kompatibel ist, die Reglungen zur Signalübertragung befolgt.
MENU :## Olja, versuche dich mal an diesem Modi, ich komm heute leider nicht wirklich dazu... Im Moment ist Land unter und das Donauinselfest ist vorbei und die Aufräumarbeiten gestalten sich eher schwierig..

Du kannst aber auch den Unterschied noch genauer in davinci darstellen..
Heute wird es leider nichts mit einem türkisen Himmel, aber es könnte schon sein das es sich bei einer eventuellen Fehlinterpretation des Bereiches negativ auswirkt..

Interessantes Thema.. Und friedlich geht's auch wieder zu... Wenn's die Möglichkeit wider gibt verschick mal die 707 und die jvc in beiden Bereichen gegenüberzustellen..

Übrigens ein Super link danke..
http://www.kenstone.net/fcp_homepage/vi ... tress.html



Antwort von olja:

Als Auszug von panasonic..

Aufzeichnung von Videos mit intensiveren Farben mit x.v.ColourTM-Technologie.
≥ Schalten Sie in den Manuellen Modus. (l 69)
≥ Richten Sie auf , , , oder ein. (l 56)
≥ Verwenden Sie für wirklichkeitsgetreuere Farben ein HDMI-Mini-Kabel (Sonderzubehör) mit einem Fernseher, der x.v.ColourTM unterstützt.
≥ Wenn Videos, die mit dieser Funktion auf aufgenommen wurden, auf einem Fernsehgerät wiedergegeben werden, das nicht mit x.v.ColourTM kompatibel ist, werden die Farben unter Umständen nicht korrekt wiedergegeben.
≥ Es wird geraten, mit der Einstellung aufzunehmen, wenn das Video auf einem anderen Gerät als einem zu x.v.ColourTM kompatiblen wiedergegeben wird.
≥ x.v.ColourTM ist eine Bezeichnung für Geräte, die mit dem xvYCC-Format, einem internationalen Standard für erweiterte Farben in Videoaufnahmen, kompatibel ist, die Reglungen zur Signalübertragung befolgt.
MENU :## Olja, versuche dich mal an diesem Modi, ich komm heute leider nicht wirklich dazu... Im Moment ist Land unter und das Donauinselfest ist vorbei und die Aufräumarbeiten gestalten sich eher schwierig..

Du kannst aber auch den Unterschied noch genauer bei davinci darstellen.. Ich hab ja nur eine etwas ältere Cam (Canon HF 200) die das kann und bei der ich x.v Color ein-, oder ausschalten kann. Ändert aber nichts an der Tatsache, das ich auch ohne x.v. Color Werte über 100 bekomme. In dem Artikel hier von 2007 wird das aber mit Vectorscope verglichen (andere Sättigung)
Hier will ich mal sehen, ob ich beim Abfilmen vom Farbchart einen Unterschied im Vectorscope erkenne.

Egal. Wichtig ist doch eigentlich nur, das unterschiedliche Cams unterschiedlich arbeiten. Während ich bei Cam A darauf achten muß, das nichts Clippt weil das Material dann tot ist und ich lieber unterbelichte, muß das nicht immer so für Cam B gelten, wenn die auf 255 geht und ich noch Zeichnung bekomme. Muß man sich eben nur mal kurz im NLE angucken, ob man so einen Kandidaten mit bei hat.

Davinci, jepp. Da hab ich noch gar nicht geguckt.



Antwort von gast5:

Das wäre dann interessant wie sich der xvColor Clip verhält ...wohin schießt der Clip.. Welcher wird eventuell falsch interpretiert.. Bezieht sich die Anzeige auf den Clip oder aufs Projekt im Verhältnis dazu..
Das wäre die Quintessenz aus dem Kenn Stone link..



Antwort von k_munic:

… Ne, ich meinte k_munic :-)

FCPX kannst Du auf Millivolt einstellen. Hier sollte es eigentlich keinen Interpretationsspielraum mehr geben. Guck mal mein Beispiel. Das geht über 700 (also 235) . ja, nee, Danke! Der 10y alte Ken Stone Artikel übersteigt mein Wohlwollen, Interesse am Hintergrundwissen zu heucheln … ;)


zum Bild


… IRE oder millivolts ändern ja nix an der Darstellung - da werden halt die Skalen anders beschriftet....

Der slashcam Artikel spricht eher meine Sprache.-

Auch wenn ich mich jetzt als SuperDau oute:
'Man' sollte immer diese 'über 100/700' runterregeln, oder?
Zumindest bei mir finde ich ja da 'Inhalte'.-

Oder wäre das zB außerhalb der Funkhäuser wurscht?
Was machen Vimeo und Co, wenn ich jenseits der 'Norm' hochlade?



Antwort von WoWu:

Lasst uns doch erst einmal sehen, wie sich die Kamera an einem HDMI Monitor verhält, damit erst einmal zwei Dinge klar werden:
Sie setzt jeweils das korrekte Flag und die Darstellung entspricht dann auch der Normierung.
Wenn das nämlich nicht der Fall ist, ist der Fehler doch schon ermittelt und Pana muss nachbessern, weil sie keine standard-konformen Signale herausgeben.
Es geht also darum zu schaun, wie sie die Gamet discription setzen.



Antwort von dienstag_01:

Was machen Vimeo und Co, wenn ich jenseits der 'Norm' hochlade? Dann hat hat das Ergebnis zuviel Kontrast.
(Bissel vereinfacht, wie deine Frage)



Antwort von olja:


Auch wenn ich mich jetzt als SuperDau oute:
'Man' sollte immer diese 'über 100/700' runterregeln, oder?
Zumindest bei mir finde ich ja da 'Inhalte'.-

Oder wäre das zB außerhalb der Funkhäuser wurscht?
Was machen Vimeo und Co, wenn ich jenseits der 'Norm' hochlade? Ne, darum gehts ja. Sendefähig ist 16-235 (also 0-100).
Guck mal, wenn Du den Effekt "Sendefähige Farben" auf den clip legst und dann den Waveform betrachtest. Der schneidet das oben dann weg. Das kann eben so nicht dargestellt werden.


zum Bild




Antwort von dienstag_01:

Ne, darum gehts ja. Sendefähig ist 16-235 (also 0-100).
Guck mal, wenn Du den Effekt "Sendefähige Farben" auf den clip legst und dann den Waveform betrachtest. Der schneidet das oben dann weg. Das kann eben so nicht dargestellt werden. Quatsch. Sendefähig heisst der Sendernorm entsprechen. Und dein Computer ist kein TV-Sender (vielleicht noch nicht, wer weiss)
Auf dem Computer kann man selbstverständlich FullRange darstellen (0-255), muss nur der Player verstehen. Flash (Youtube) macht das aber nicht.



Antwort von olja:

Wir reden doch hier nur von sendefähigen Farben und eben dem Bereich. Deshalb die Grafik nochmal. Evtl. etwas unklar ausgedrückt.



Antwort von olja:

..doppel



Antwort von k_munic:

... a-haaa!

Jetzt hab ich 'mal den clip in vier Versionen hier: naturé, also direkt aus der Cam im NLE, kein intermediate/proxy/o.ä., dann mit dem plug-in 'sendefähige Farben (PAL; 100%) Luminanz, 'sendefähige Farben/Sättigung', und dann manuell, Spitzlichter runtergezogen auf 100/700:

Vier deutlich versch. Ergebnisse: Sendefähig/Luminanz' erzeugt nach Export banding im weißen Himmel - net schee.-

Sendefähig/Saturation nimmt die Sättigung 'raus - das freut vermutl. den BildIng, weil's 'ne Norm erfüllt, mich nicht. Ich hab's gern bonbon-bunt. Für meine Zwecke völlig sinnfrei.-

manuelles Absenken der Obergrenze von ~107 auf 100 ergibt mMn!! das 'beste' Ergebnis.-
Wie man schön an den Wolken über der Tribüne ganz hinten in der Bildmitte sieht:
Da, wo im 'Original' nur platt-weiß zu sehen ist, tauchen nach dem manuellen Absenken noch verschiedene 'Weiße' also Details auf. Naja, für 90% meiner Film nice-to-have, aber nicht zwingend notwendig ;)

link zu vier Bildern

... 'tschuldigung fürs thread-jacking - ich wildere ja hier in der Premiere-Ecke - SORRY!!

Danke allen, die mir Alten Mann über die Straße geholfen haben!



Antwort von WoWu:

Nein, mit Broadcastern und Sendefähigkeit hat das nur insofern was zu tun, als Broadcaster auch nur standardkonformes Material senden.
Auch eine HDMI lässt nur standardkonformes Material durch, sofern kein xvYCC signalisiert wird.

Die Norm haben die Hersteller geschaffen (federführend SONY), die in der SMPTE vereinigt sind, um die Kompatibilität der Kameras und des Bildmaterials sicher zu stellen und um auszuschliessen, dass digitale Signale keinen Over/Underflow erzeugen.
So nennt man den Zustand, wenn Daten in nicht dafür vorgesehene Speicherbereiche geschrieben werden.
Ein Underflow liegt vor, wenn bestimmte Zahlengrössen in einem System unterschritten werden.
Aber auch niederfrequente Transienten (Spikes) abzufangen die von Bauteilen aber auch speziell von Filtern erzeugt werden, Amplituden und Gruppenlaufzeiten sicher zu stellen, Video Überschreitungen in inhärenten Coder / Decoder Filterungen zu verhindern usw.

Der freigehaltene Raum ist also keine Schikane sondern dient einem stabilen Videosignal. Und wenn man sich auf dem Waveform mal die Überschwinger (oben und unten) mal ansieht, weiss man auch warum das gemacht worden ist.

Und noch eins .... Es geht kein Weiss dabei verloren, weil der höchste Weisswert des Sensors (PeakWhite) jeweils im obersten Quantisierungswert landet, ob es nun 235 oder 255 ist und wenn eine korrekte Signalisierung bis hin zum TV-Gerät stattfindet (und das ist beim Standard der Fall) und das TV gerät ein Farbmanagement hat, dann wird auch die maximale Leuchtamplitude bei dem entsprechenden Wert dargestellt.

Also, mit Broadcast hat das primär erst einmal nichts zu tun.

Man muss da auch unterscheiden, zwischen FullWell im Wert 235 und der Benutzung eines "Broadcast save" Filters. Der schneidet ab. Aber 235 schneidet nicht ab, das hat dann bereits der Sensor in der Kamera getan.

Nochmal: 235 überträgt die maximale Helligkeit des Sensors.



Antwort von dienstag_01:

Die Frage drehte sich ja hier um Vimeo und Co.
Natürlich wird die maximale Helligkeit mit 235 übertragen. Der Player muss sie aber für den Computerbildschirm auf 255 mappen. Wenn das Video aber FullRange ist, dann mapped der Player aber die im Bild vorhandenen Grauwerte (235 ist ja hier kein Weiss) nach Weiss, dasselbe passiert am unteren Rand, deshalb zuviel Kontrast.



Antwort von WoWu:

@ k_munic

Man sagt ja, "ein Bild sagt mehr als Tausend Worte" ... aber in diesem Fall weniger als eine Waveformdarstellung.
Die Effekte, die Du beschreibst, lassen sich alle begründen, bzw. stehen hier eigentlich gar nicht zur Diskussion (Stauration).

Aber solange nicht zunächst klar ist, wie das Ausgangsmaterial eigentlich übertragen ist, helfen solche Bilder leider nicht.
Davon gibt es tausende in jedem beliebigen Blog .... und dazu eben soviele, streckenweise haarstreubende Erklärungsversuche wenig zielführend.

Wir müssen zunächst mal wissen, wie die Kamera die Signale bei den beiden Modi (standard/xvYCC) ablegt und wie sie sie signalisiert.
Dann kann man systematisch weitergehen.



Antwort von WoWu:

Die Frage drehte sich ja hier um Vimeo und Co.
Natürlich wird die maximale Helligkeit mit 235 übertragen. Der Player muss sie aber für den Computerbildschirm auf 255 mappen. Wenn das Video aber FullRange ist, dann mapped der Player aber die im Bild vorhandenen Grauwerte (235 ist ja hier kein Weiss) nach Weiss, dasselbe passiert am unteren Rand, deshalb zuviel Kontrast. Jetzt bist Du aber bereits im Farbmanagement, das hat mit der eigentlichen Übertragung zunächst mal noch nichts zu tun und hängt natürlich davon ab, ob überhaupt CM gemacht wird ... ist ja gar nicht sicher.
Nur bringt es in die Klärung des eigentlichen Problems natürlich zusätzlich beliebige Verwirrung und in Bezug auf Vimeo&Co kann man getrost davon ausgehen, dass sie standardkonform arbeiten und man mit FullRange gnadenlos in ihrem Begrenzer landet.
Es ist also weniger die Frage, was man sieht, als vielmehr die Frage, was für ein Signal man erstellt.



Antwort von dienstag_01:

@WoWu
Hast recht. War aber trotzdem eine Frage ;)
Ich kann dir leider mit xv Color und HDMI nicht weiterhelfen, denke aber auch, dass die VIELEN Waveforms hier nur bedingt was mit diesem Farbraum zu tun haben. Eher denke ich sowas in der Art, dass die Cams es nicht ganz so genau nehmen, zumal ja 255 auch noch im Bereich von 110 IRE (oder wie weit kann man maximal gehen: 120?) bleibt. Ob die da oben noch richtig encodieren/abbilden, ich weeeeeeeeees es nicht. (Teilweise aber schon.)



Antwort von WoWu:

Zunächst mal sehe ich bei den vielen Waveforms, dass die unteren Spikes alle für Nutzsignal gehalten werden und Schwarz gar nicht "aufsitzt".
Damit haben wir schon mal die erste Fehlinterpretation, die oben dann zur zweiten Fehlinterpretation führt.
Es folgt daraus eben nur eben die Frage, warum sitzt das Signal nicht auf ?
Aber das wäre der nächste Schritt, sobald wir wissen, mit was für einem Signal die Kamera überhaupt arbeitet.



Antwort von dienstag_01:

Bisher werden ja als Beispielbilder immer Bilder mit Himmel oder ähnlichem, also letztlich Weiss angebracht. Interessant wird das ganze ja erst, wenn es um z.B. einen völlig überstrahlten Hautton geht. Da die Farbe zurückzugewinnen, ich galube, das gelingt nichtmal ansatzweise.



Antwort von olja:

Eher denke ich sowas in der Art, dass die Cams es nicht ganz so genau nehmen Das ist doch der springende Punkt !
Erst dachte ich, evtl. ist ja nur am HDMI sauber, damit die ungeschnittenen Zoofilmchen gleich an dem Fernseher ooc gehen. Aber die kommen ja auch von Speicherkarte, also muß die Info ja irgendwo geflaggt sein. Und wenn man den Modus sogar umstellen kann, muß doch eigenlich ein Unterschied festzustellen sein.
Ganz schmutzig wär es natürlich, wenn das auch nur bei der Ausgabe von der Cam kommt, wenn die auf x.v color steht und gar nichts geflaggt ist, sondern generell full aufzeichnet und bei Standardeinstellung ein Limiter greift. Auf der Karte befindet sich aber immer Full. Blöder Gedanke, aber wär sowas denkbar ?



Antwort von Reiner M:

Auf dem Computer kann man selbstverständlich FullRange darstellen (0-255), muss nur der Player verstehen. Flash (Youtube) macht das aber nicht. Dennoch sollte man zwei Speicherbereiche strikt unterscheiden, die völlig getrennt verwaltet und bedient werden im NLE.

Im ersten Speicher liegen die YCbCr-Daten, wie sie aus dem Cam-File eingelesen werden. Aus diesem Speicher wird die Luminanzwelle gewonnen.
Auf ihn können auch Effekte angewendet werden. In Premiere Pro sind diese Effekte mit "YUV"-Symbol markiert. Sie wirken vor der RGB-Umsetzung. Der Effekt "Luminanzkurve" gehört dazu.

Im zweiten Speicher liegt die daraus folgende RGB-Umsetzung, die zeitlich später passiert. Richtig: Die kann "normal" oder full-range vorgenommen werden. In beiden Fällen wird der Bereich der Luma-Kurve oberhalb "100" und unterhalb "0" (egal wie Skala tatsächlich heißt) nicht im RGB-Speicher landen.
Das ist das, was oljas Grafik zeigt.

Das Vorhandensein der Wellen außerhalb des bildgebenden Bereichs hat mit dem danach folgenden RGB-Mapping erstmal nichts zu tun.

Wellen oberhalb "100" bedeuten nun eindeutig, dass in der YCbCr-Speicherung Signale oberhalb Y235 vorkommen.

Wären das Fremdaten oder Ausreisser und kämen sie nicht vom Sensor, dürften sie erstens nicht so geballt und massiv erscheinen, wie sie manch ein Screenshot hier zeigt (es geht nicht um ein paar versprengte Spitzen), und sie dürften zweitens nicht so positiv auf die Bilder wirken. - Es sind echte Bildinhalte. Man kann sie eindeutig sichbar machen und durch bloses hinsehen als Bildbestandteile identifizieren. Einfach mal immer weiter runterdrücken.

Natürlich führen diese Signale nicht zu einem weißeren Weiß im Bild - das geht nicht. Denn entweder wird Y235 nach RGB 235/235/235 gemappt - dann gibt es keine Werte oberhalb RGB 235/235/235 im Videobild, oder es wird full-range nach RGB 255/255/255 gemappt - dann ist eh Anschlag erreicht.

Der Witz ist, dass durch Senken der Lumakurve ein vorhandenes Y254 auf ein Y235 runtergerechnet wird und dadurch unterhalb Y235 für das RGB-Mapping relevante Nutzdaten entstehen. Farben. Zeichnungen.

Da Video-Player auf PC-Systemen innerhalb und außerhalb des NLEs immer die RGB-Umsetzung anzeigen, auch auf YT & Co., und nicht die YCbCr-Speicherung direkt auswerten können und sich dabei strikt an yuv2rgb-Matrizen gemäß REC.709 (und nicht des SMTPE 240M/260) halten, empfiehlt es sich, die Quellfiles dahingehend zu untersuchen, ob Content oberhalb 100 vorhanden ist und ggf. bei Bedarf anzupassen.

Beste Grüße,
Reiner



Antwort von dienstag_01:

@Olja
Wowu hat es ja schon geschrieben: Schwarz sitzt bei euren Bildern nicht auf. In einem erweiterten Farbraum sollte das dann aber auch nach unten erweitert sein.



Antwort von olja:

Wowu hat es ja schon geschrieben: Schwarz sitzt bei euren Bildern nicht auf. In einem erweiterten Farbraum sollte das dann aber auch nach unten erweitert sein. Muß das aufsitzen, wenn kein Superblack vorhanden ist ?



Antwort von dienstag_01:

Denk schon ;)



Antwort von Reiner M:

Muß das aufsitzen, ...? Nein. Der Footroom Y1 bis Y15 ist Speicherbereich. Wenn solche Werte vorkommen, kommen sie eben vor. Ins Bild fließt ab Reference Black (Y16). Nur insofern sitzt das auf.

Beste Grüße,
Reiner



Antwort von WoWu:

Wowu hat es ja schon geschrieben: Schwarz sitzt bei euren Bildern nicht auf. In einem erweiterten Farbraum sollte das dann aber auch nach unten erweitert sein. Muß das aufsitzen, wenn kein Superblack vorhanden ist ? @Olja

Es gibt keinen "Super Black".
Die Kamera überträgt IMMER vom Noise-Level bis zum PeakWeiss.
Nur mal werden die beiden Werte in 16/235 übertragen und bei xvYCC in 1/255. Dein NLE hat aber immer nur diese beiden Werte.
Das, was Du "Superblack" nennst ist eine Mischung aus den beiden Übertragungsverfahren und über irgendwelche Kanäle, egal ob Ytube oder DVD oder was auch immer, sowieso nicht transportierbar.

Ein Signal hat aber immer mit dem Schwarzlevel auf NULL aufzusitzen und nicht mit dem Spike-Boden. Der gehört hinterher mit "Broadcast-Save" abgeschnitten (Weil es sowieso keine Videosignale sind !!!)
Wir arbeiten hier mit Videosignalen und nicht mit technischen Überschwingern.



Antwort von olja:

Ich nehme heute nochmal 2 Cams und nen Farbchart. Die eine kann's, die andere liegt immer bei 100.

Hier dürfte dann Zuordnung eindeitiger sein, als nen paar Zweiglein



Antwort von WoWu:

Ich nehme heute nochmal 2 Cams und nen Farbchart. Die eine kann's, die andere liegt immer bei 100.

Hier dürfte dann Zuordnung eindeitiger sein, als nen paar Zweiglein Nur sinnvoller ist es natürlich, wenn man an einer der Kameras einmal nachvollziehbar definiert, was für ein Signal vorliegt und wie es signalisiert wird.
Daher wäre so ein Vergleich an einem Weg sinnvoll, von dem man davon ausgehen kann, dass er beide Wege unterstützt. (HDMI)
Erst wenn man weiss, wie sich die Kamera verhält, kann man den nächsten Schritt machen und untersuchen, wie sich das NLE verhält.
Sonst ist das ein ungeordneter Wust an unbedeutenden Informationen.
Das ist nicht besonders zielführend.



Antwort von Reiner M:

Vielleicht erklärst Du noch mal Deine Überschwinger.

In der digitalen Speicherung macht das ja wenig Sinn.
Die YCbCr-Werte sind als digtale Byte-Werte gespeichert, nicht analog. Dort machte es Sinn. Ebenso wie im nicht digitalen Sendebtrieb.

Die YCbCr-Speicherung in JPEG, die schon immer digital war, kannte solche Überschwinger noch nie. Selbstverständlich wird dort bereits YCbCr full-range gespeichert (0-255). Obwohl mit den selben Sensoren aufgezeichnet.

Der A/D-Wandler in der Cam wäre doch sehr leicht in der Lage, digitale Werte oberhalb 235 zu unterbinden, gar nicht erst entstehen zu lassen? Dann gäbe es aber auch genau Null Überschwinger.

Du hast selbst ein Beispiel dafür aufgezeigt. Manche Cams machen das so. Und deren Files weisen auch keine Überschwinger auf.

Andere Cams begrenzen erst bei 254.

Beste Grüße,
Reiner



Antwort von dienstag_01:

Im ersten Speicher liegen die YCbCr-Daten, wie sie aus dem Cam-File eingelesen werden. Aus diesem Speicher wird die Luminanzwelle gewonnen.
Auf ihn können auch Effekte angewendet werden. In Premiere Pro sind diese Effekte mit "YUV"-Symbol markiert. Sie wirken vor der RGB-Umsetzung. Der Effekt "Luminanzkurve" gehört dazu. Reiner, sorry, macht einfach zuviel Spass mit dir, kleine Frage: Die Luminanzkurve wird ja nach deiner Ansicht aus den YCbCr-Daten gewonnen/berechnet. Warum, in Drei-Teufels-Namen, hat die aber auch ein 32bit Symbol?
Du hast bis SONNENUNTERGANG Zeit ;)
(Um mal bisschen im Märchenkontext zu bleiben.)



Antwort von Reiner M:

@Dienstag
Das eine ist der Ort, an dem der Effekt greift,
das andere das Format der Speicherzelle, in dem das Datum liegt.

Beste Grüße,
Reiner



Antwort von TheBubble:

Der A/D-Wandler in der Cam wäre doch sehr leicht in der Lage, digitale Werte oberhalb 235 zu unterbinden, gar nicht erst entstehen zu lassen? Dann gäbe es aber auch genau Null Überschwinger. Klar. Aber wenn man Werte abschneidet, dann gäbe es ggf. auch einen "Knick". Dies ist ggf. dann problematisch, wenn das ursprünglich analoge Signal möglichst exakt rekonstruiert und wieder analog ausgegeben werden soll. Man hat ja früher, insbesondere die Sendetechnik, nicht von heute auf morgen digitalisiert, sondern Stück für Stück umgestellt.



Antwort von WoWu:

@Reiner
Jedes Filter 2. Ordnung macht relativ starke Überschwinger.
Davon gibt es ja nun einige im Signalprozessing.

Die Verhinderung solcher Nebeneffekte ist eine Frage des Aufwands.
Kameras mit hochwertiger Signalführung haben sehr deutlich weniger Überschwinger als Consumerkameras.
Dazu gehört auch die Frage -ob und wenn, dann wo- man begrenzt, denn im Standard ist exakt der Raum dafür ohnehin vorgesehen, gerade um den Konstruktionsaufwand der einzelnen Kameras gering zu halten.
Schliesslich ist die SMPTE eine Vereinigung (überwiegend) der Hersteller.
Warum also sollte man mehr als notwendigen Aufwand betreiben.

Das "schräge Aufsitzen" des Signals kann übrigens auch daher kommen, dass es nicht, wie bei Y"Cb'Cr' vorgesehen von der Mitte gemapped wird, sondern ala RGB von 1. Dann kommt sowas dabei raus.

Wenn wir Signale in Y'Cb'Cr' einspielen, sind die Transienten immer in beiden Richtungen und auch eben unterhalb der Aufsatzlinie.



Antwort von dienstag_01:

@Dienstag
Das eine ist der Ort, an dem der Effekt greift,
das andere das Format der Speicherzelle, in dem das Datum liegt. ;)
Und nun nochmal ohne Märchen.



Antwort von Reiner M:

Klar. Aber wenn man Werte abschneidet, dann gäbe es ggf. auch einen "Knick". Dies ist ggf. dann problematisch, wenn das ursprünglich analoge Signal möglichst exakt rekonstruiert und wieder analog ausgegeben werden soll. Man hat ja früher, insbesondere die Sendetechnik, nicht von heute auf morgen digitalisiert, sondern Stück für Stück umgestellt. Sehe ich auch so. Aber es würde ja nicht unbedingt einfach abgeschnitten, oder? Die Werte würden doch hoffentlich zwischen Min und Max anders verteilt sein? Entlang eines definierten Profils vermutlich?
Meine Canon 60D, die da bei 235 begrenzt, clippt nicht dauernd und knickt nicht ein. Sie zeigt ein sehr schönes, ausgewogenes Bild, wie ich meine.

Natürlich ist das evolutionär gewachsen. Stück für Stück aus der analogen Welt in die digitale hinein. Und diese Welten koexistieren auch noch und werden es noch lange. Genau da hat ja SMPTE 240M seine Wurzeln: Analog, und zudem 60Hz. Das Erbe steckt in den Standards, die irgendwie den unterschiedlichen Belangen gerecht werden müssen. Im REC.709 ist es wohl weitgehend realisiert.

Beste Grüße,
Reiner



Antwort von Reiner M:

@Dienstag
Das eine ist der Ort, an dem der Effekt greift,
das andere das Format der Speicherzelle, in dem das Datum liegt. ;)
Und nun nochmal ohne Märchen. Nochmal?
Das eine ist der Ort, an dem der Effekt greift,
das andere das Format der Speicherzelle, in dem das Datum liegt.

Lies es nach.

Beste Grüße,
Reiner



Antwort von dienstag_01:

Nochmal?
Das eine ist der Ort, an dem der Effekt greift,
das andere das Format der Speicherzelle, in dem das Datum liegt. Ort, Format?!
Reiner, ich muss dich leider auf Viertel-Wissen runterstufen ;)
(Hab mir aber schon sowas gedacht, in der Art, wie du oben wieder in deiner Beschreibung wortreich ausgeholt hast.)

Wie arbeitet Premiere WIRKLICH:

Wende ich auf ein 8bit Video einen der Color Correction Effects mit 32bit/YUV an, erfolgt die Berechnung auf Grundlage der YUV (also YCrCb) Werte.

Wende ich denselben Effekt auf ein Video an, dass schon durch einen anderen Effekt auf 32bit-Basis berechnet wurde, wird der Color Effekt jetzt mit 32bit RGB berechnet.

Und das macht Sinn.
Natürlich nur in mit der Einstellung *maximale Bittiefe* ;)



Antwort von Reiner M:

@Reiner
Jedes Filter 2. Ordnung macht relativ starke Überschwinger.
Davon gibt es ja nun einige im Signalprozessing.

Die Verhinderung solcher Nebeneffekte ist eine Frage des Aufwands. Wolfgang,
in der digitalen Welt gibt es genau 2 Zustände: Ein Wert existiert, oder er exitsiert nicht. Dazwischen gibt es nichts. Das Ergebnis einer Berechnung von Analog nach Digital ergibt genau einen Wert oder auch nicht.

Wo sollen dabei "Überschwinger" herkommen? Verstehe ich nicht. Also mehr als ein Ergebnis aus einer Berechnung? oder Bereichsüberläufe? Und wenn es tatsächlich entstehen sollte, warum wird es überhaupt aufwändig gespeichert, wenn das gar nicht zulässig ist? Welchen Sinn macht das?

Der "Filter", zu verhindern, dass Werte größer 235 gespeichert werden, ist in der Programmierung überhaupt kein Aufwand. Genauso wenig, wie zu verhindern, dass Werte größer 254 entstehen. Auch das muss der Digiprozessor ja garantieren. Es ist im Grunde das selbe Verfahren, nur mit anderen Konstanten. Die Formeln, die der Umrechnung zugrunde liegen, sehen das alles entsprechend vor.

Beste Grüße,
Reiner



Antwort von WoWu:

Verstehe ich nicht. Das drückt die Sache wohl zutreffend aus.
Als nächstes wirst Du jetzt wahrscheinlich sagen, es gibt im Videosignal keine Überschwinger ...

Alles klar.
Wenn ich heisse Luft brauche, geh ich vor sie Tür.



Antwort von dienstag_01:

WoWu, erklärs doch mal kurz (ist ja nicht nur der Reiner, der hier auf dem Schlauch steht). Ich kenn das auch nur von Software- vs Hardware-Limitern. Aber warum das so ist...



Antwort von WoWu:

Du must Dir nur mal anschauen, wie Kantenschärfung funktioniert.
Da hast Du das beste Beispiel.
Das bezieht sich aber generell auf den Einsatz von Gradientenfiltern.



Antwort von dienstag_01:

WoWu, das ist nicht lieb ;)
Dann erklärts uns der Reiner wieder (kleiner gemeiner Scherz, geb ich zu)



Antwort von Reiner M:

Reiner, ich muss dich leider auf Viertel-Wissen runterstufen ;) O, Du darfst mich gerne auf Null-Wissen herabstufen - Hauptsache Du bist glücklich. ;)

Was ist die Botschaft?
Wie arbeitet Premiere WIRKLICH:

Wende ich auf ein 8bit Video einen der Color Correction Effects mit 32bit/YUV an, erfolgt die Berechnung auf Grundlage der YUV (also YCrCb) Werte. Und worüber reden wir hier die ganze Zeit? Video rein - Luminanzkurve drauf. Fertig.

Wenn Du gerne ein anderes Thema mit mir besprechen möchtest, sags einfach. ;) Oder möchtest Du mir nur mitteilen, dass Du auch was weißt? Das glaube ich Dir doch auch so. Stelle ich nicht Frage. Haben uns ja schon oft genug unterhalten. ;)

Beste Grüße,
Reiner



Antwort von dienstag_01:

Ich wollte niemanden zu nahe treten.
Bissel überspitzt formulieren, das ja ;)



Antwort von Reiner M:

Verstehe ich nicht. Das drückt die Sache wohl zutreffend aus.
Als nächstes wirst Du jetzt wahrscheinlich sagen, es gibt im Videosignal keine Überschwinger ... Habe ich nicht behauptet und werde ich nicht tun.

Wir reden hier aber nicht verallgemeinernd über ein "Videosignal", sondern sehr konkret über Byte-Werte in einer YCbCr-Speicherung.

Du sagst: a) Da dürfen keine Werte über 235 drin sein. Und b) Wenn welche drin sind, sind das Überschwinger.

Ich sage: Wenn da keine drin sein dürfen, ist das programmierungstechnisch seitens der Cam kein Problem, dafür zu sorgen. Ungekehrt ist es ein riesen Aufwand und bläht die Datein zudem auf, diese sinnlosen Daten zu produzieren zu speichern und mitzuschleppen.

Es sind aber Daten da, und ich möchte gerne wissen, wieso, wenn es keine nutzbaren Daten sind. Denn genau das ist offensichtlich der springende Punkt. Daten, die gar nicht da sein dürften, tauchen in den NLEs auf.

Beste Grüße,
Reiner



Antwort von TheBubble:

Sehe ich auch so. Aber es würde ja nicht unbedingt einfach abgeschnitten, oder? Die Werte würden doch hoffentlich zwischen Min und Max anders verteilt sein? Entlang eines definierten Profils vermutlich? Ich weiß nicht, warum es Dir noch nicht klar ist, aber ich versuche es noch einmal vereinfacht, auf die unklaren Dinge reduziert, zu erklären:

Die "Kamera" (oder Filmabtaster, Testgenerator, ...) will - vereinfach gesagt - Helligkeiten (bei RGB wären des die Helligkeiten der einzelnen Farbkanäle) zwischen 0% Helligkeit (Schwarz) und 100% Helligkeit (Weiß) ausgeben. Dazu bildet sie die Messwerte, bzw. einen Bereich aus ihnen, in diesen Bereich ab. Wie das geht, interessiert für die weiteren Erklärungen nicht weiter.

Dieser Bereich (0% bis 100%) wird nun wieder abgebildet: In der analogen Welt z.B. auf einen festgelegten Spannungsbereich, in der digitalen Welt auf einen diskreteten Wertebereich. Dieser könnte als 0-255, aber auch als 70-200, gewählt werden. Die Wahl ist erst einmal willkürlich. Je mehr Abstufungen vorhanden sind, desto besser ist jedoch die Auflösung eines einzelnen Messwerts.

Warum wurde nun 16-235 und nicht 0-255 gewählt, wie bei Computerdarstellungen üblich, wo das doch schnell zu Verwirrungen führen kann (siehe dieser Thread...)?

Der Grund ist die analoge Signalverarbeitung: Wird das analoge Signal - vor der Digitalisierung gab es nur analoge Übertragungen - gefiltert (z.B. Kantenanhebung für mehr Schärfe, usw.), dann können (bzw. werden!) Überschwinger auftreten, die den festgelegten Bereich verlassen.

Für die Darstellung am Fernseher war das kein Problem: Da es weder dunkler als Schwarz gibt, noch heller als Weiß, konnten diese "illegalen" Ausreisser vernachlässigt werden, insbesondere da sie letztlich im Vergleich zum Nutzsignal nicht so groß sind und bei der Konstruktion der Geräte ohnehin berücksichtigt werden mussten.

Nun sollte digitalisiert werden, z.B. mit 8-Bit A/D-Wandlern. Vereinfacht gesagt hat man sich dafür entschieden, die Überschwinger quasi einfach mit zu digitalisieren (sofern es keine enormen Ausreisser sind), obwohl sie keinen Nutzen haben, sondern ein Artefakt sind. Man legte dazu einen Bereich für Überschwinger fest und definierte 16 als 0% Hellikeit und 235 als 100% Helligkeit. Alles ausserhalb dieses Nutzbereiches gehört zwar noch zum ursprünglichen Videosignal, enthält jedoch keine beabsichtigten Helligkeitswerte.

Wo liegt nun der Vorteil? Wenn das digitale Signal wieder analog ausgegeben werden soll, können eventuelle Überschwinger ebenfalls rekonstruiert werden. Es sind also nützliche Daten für die Rekonstruktion des ursprünglichen analogen Signals, jedoch keine nützlichen Daten bezüglich der Helligkeitswerte.

Wo ist jetzt das Missverständnis? Computer Nutzer und Programmierer gehen (leider) häufig davon aus, dass 0 Schwarz und 255 Weiß sein muss. Ist es aber nicht unbedingt.



Antwort von WoWu:

@Reiner
Alles bereits mehrfach und hinreichend beantwortet.

Nachtrag: wie ich sehe sogar wiederholt.

@dienstag_01

http://et.fh-duesseldorf.de/c_personen/ ... _V_K07.pdf

Gradientenfunktionen sind gleichfalls (sogar am Beispiel) erklärt.


@Bubble

Gleich kommt bestimmt : "...aber wir leben doch in einer digitalen Welt".
Zu Deiner Erklärung möchte ich noch hinzufügen, dass es darüber Hinaus noch eine Handvoll weiterer Gründe gibt, (ein paar habe ich oben schon angeführt) für die die Wertebereiche wichtig sind. Also nicht nur Überschwinger.



Antwort von dienstag_01:

Mann o Mann, zweite Ableitung!!!
Aber Dank an euch, allen beiden.

Mal bissel vereinfacht formuliert: Wenn wir rein in der digitalen Welt bleiben würden, könnte man auch wirklich exakt bei 0 und 100 cutten (und bekäme das auch technisch hin). Den *Headroom* benötigt man eher aus Gründen der Reproduzierbarkeit Richtung analog?



Antwort von WoWu:

Nein, nicht nur .... siehe Gründe oben.
So ein Signalweg besteht ja nicht nur aus einem A/D Wandler, einem Kabel und einem D/A Wandler im Monitor.



Antwort von domain:

Manche Cams machen das so. Und deren Files weisen auch keine Überschwinger auf.
Andere Cams begrenzen erst bei 254. Ich habe noch nie eine digitale Kamera gehabt, die bei 235 begrenzt hätte, weder bei Foto noch bei Video.
Habe gerade mal einige alte Videofiles der FX1 gecaptured. Auch dort gab es schon massive "Überschwinger" über 100% hinaus.
Alle Versuche aber, 235-er Werte zu generieren schlagen prinzipiell fehl, egal ob bei Screenshots (über die Printtaste in Photoshop kopiert) oder direkt über Snapshots aus dem NLE heraus. Immer und unter allen Umständen zeigt die RGB-Pipette Werte um die 255 an.
Wenn ich die Rec709-Option im NLE anklicke, dann wird das gesamte Video neu gerendert, wobei die über 100% liegenden Werte, wie im Waveformmonitor ersichtlich, schön brav abgeschnitten werden, aber selbst dann kommt es niemals zu 235-er Werten, sondern bei allen Messmethoden kommt immer 255 bei den maximalen Lichtern heraus.
Wo liegt der Hund begraben?



Antwort von dienstag_01:

Wo liegt der Hund begraben? Ich nehme mal an (hatte ich schon mehrmals geschrieben), auf deinem Computermonitor wird 16 zu 235 auf 0-255 gemapped. Sonst hättest du ein ganz flaues Bild.



Antwort von TheBubble:

Gleich kommt bestimmt : "...aber wir leben doch in einer digitalen Welt". Mit so etwas recht ich schon fast.
Zu Deiner Erklärung möchte ich noch hinzufügen, dass es darüber Hinaus noch eine Handvoll weiterer Gründe gibt, (ein paar habe ich oben schon angeführt) für die die Wertebereiche wichtig sind. Also nicht nur Überschwinger. Machen wir es lieber nicht noch komplizierter, sonst wird der Thread noch gefühlt endlos. Im Grunde würde es mir reichen wenn rüberkommt, dass es diesen Bereich eben gibt und er ursprünglich nicht dazu gedacht war, "noch dunkleres Schwarz" unterzubringen.



Antwort von domain:

Ich habe aber keinen Computermonitor, sondern einen HDMI-Fernseher als Monitor und außerdem ergibt sich immer das gleiche Ergebnis, egal ob vom NLE oder von einem Player heraus der Frame gewonnen wurde.
Und bitteschön was misst Photoshop eigentlich? Ev. die gemappten Werte? Wieso zeigt es dann beim Belle-Nuit Testchart exakt die richtigen Werte an? Die sind doch gar nicht gemapped sondern im png-Original doch wohl eher wirklich 255.
Kann schon sein, dass du recht hast, aber wirklich glauben will ich es nicht.



Antwort von dienstag_01:

Das Belle Nuit Chart kenne ich jetzt nicht so. Aber, 255 dürfte eigentlich an einem TV keinen Unterschied zu 235 geben. Wenn doch, dann kann dein TV über HDMI FullRange oder aber, jetzt wirds tricky, das Testchart wird im NLE konvertiert in 16-235 und dann wieder auf 0-255 gemapped. Weiss aber nicht genau.
WoWu kennt sich mit HDMI aus.

Photoshop nimmt schon die angezeigten (gemappten) Werte ab. Sicher.

Edit: Player müssen ja auch mappen.



Antwort von WoWu:

@ Bubble

"da core".



Antwort von WoWu:

@ Domain

Du bringst bereits den nächsten Schritt mit in die Diskussion, das Mapping nach RGB. Ich geh mal davon aus, dass PS direkt nach AdobeRGB mapped.

Grundsätzlich ist es aber so, wenn Du ein Chart abfilmst, dass der höchste Helligkeitswert entlang der Spezifikation behandelt wird, also das, was als 255 ausgewiesen ist, als 235 "transprtiert" wird.
Trifft der 235er Wert mit dem Datenbit: "ich bin 709" auf den HDMI Eingang und hat der Fernseher Colormanagement, wird es dafür sorgen, dass der Wert mit maximaler Leuchtkraft den Monitor verlässt.
Hat der Fernseher kein CM, wird der Wert wie die 235er Fläche dargestellt.

Filmst Du in xvYCC dann wird die 255 Fläche als 255 transportiert und im Monitor (mit oder ohne CM) mit max Helligkeit dargestellt.

Ein Monitor "mapped" nicht sondern wirkt analog auf die Bildhelligkeit bzw. digital auf die Slewrate.



Antwort von dienstag_01:

Domain hat das Chart sicherlich nicht abgefilmt, oder ;)



Antwort von WoWu:

Ja, aber irgendwie muss er sie ja digitalisiert haben und wenn er es mit PS gemacht hat ...
Aber ich glaube, wir verzetteln uns mit diesen Experimenten und sollten bei dem konkreten Beispiel der panssonic bleiben.
Sonst kommt auch noch die Grafik mit ins Spiel, die das ganze dann beliebig verkompliziert.



Antwort von domain:

Natürlich nicht selbst digitalisiert, sondern so heruntergeladen.
Wenn ich WoWu richtig verstanden habe, dann ist es dem Monitor oder dem TV-Gerät also egal ob mit 235 oder 255 angeliefert wird, die Helligkeit wird immer dieselbe bleiben. Finde ich eigentlich sehr intelligent.
Insgesamt aber wird mir alles immer "spanischer" je länger der Thread andauert :-)



Antwort von WoWu:

Nur wenn der Monitor Color-Management kann.
Insgesamt aber wird mir alles immer "spanischer" je länger der Thread andauert :-) Das muss nicht so sein, Du musst nur wissen, was an welchen Stellen wie passiert und wie es mitgeteilt wird.

Eigentlich ist es geradezu trivial.



Antwort von dienstag_01:

@Domain
Egal ist es nicht, ob 235 oder 255
Grafik wird aber im allgemeinen nach 16-235 beim Import konvertiert (und dann wieder 0-255 angezeigt - nunja, so ist es nun mal bei uns Spaniern)

@WoWu
Bilder von meiner HVX 200, mit Neonröhren direkt im Bild, alles Avid:



Antwort von WoWu:

Grafik wird aber im allgemeinen nach 16-235 beim Import konvertiert (und dann wieder 0-255 angezeigt Dann hast Du irgendwo einen falsch convertierten Übergang drin oder eine falsche Messung.
Maximal Weiss bringt in RGB einen andern Wert als in Y'Cb'C'r.
(Wie schon oben erklärt) und ist dazu noch bei NULL aufgesetzt und nicht bei 128



Antwort von dienstag_01:

@WoWu
Wo oben?



Antwort von WoWu:

"sei nicht so faul" :-))

Aber die beiden Bilder stehen wie folgt zueinander:
In YCbCr eingefügt stehen sie genau im Wertesystem, übrigens auch sehr schön die Differenz zwischen Y und C zu sehen.
Es entsprechen die Werte 16-240 also 100%
100% für RGB entspricht aber nicht 700mV sonder 1 V.
Die Messung "übersetzt" also die 100% und nicht den Wertebereich.
Wenn Du den wertebereich in RGB anzeigen kannst, müsste, wenn es reine Messungen und keine unterschiedlichen Mappings sind, die Welt wieder stimmen.



Antwort von dienstag_01:

@WoWu
Ich versteh dich jetzt nicht so ganz.
Aber, vielleicht wirds so einfacher, die Kurve einer 0-255 Grafik in Avid importiert. Man sieht schön, dass sie genau bei 16-235 angekommen ist.

DU KANNST MIR DOCH NICHTS ERZÄHLEN ;)



Antwort von WoWu:

Einbisschen stutzig macht mich das RGB Bild, denn die Rasterung sieht einwenig danach aus, als ob da Werte fehlen (gestreckt).



Antwort von WoWu:

@WoWu
Ich versteh dich jetzt nicht so ganz.
Aber, vielleicht wirds so einfacher, die Kurve einer 0-255 Grafik in Avid importiert. Man sieht schön, dass sie genau bei 16-235 angekommen ist.

DU KANNST MIR DOCH NICHTS ERZÄHLEN ;) Nun bin ich einwenig aus der Kurve getragen und weiss nicht mehr so ganz genau, was Du da von wo nach wo schaufelst :-(



Antwort von dienstag_01:

@WoWu
Warum das RGB-Bild (Parade) so angezeigt wird, keine Ahnung.

Die Grafik meint das, was ich oben geschrieben hatte: Tiff-Grafik aus Photoshop mit Schwarz=0 und Weiss=255, dann importiert in Avid und das Ergebnis ist 16-235.



Antwort von WoWu:

Ja, genauso sieht das auch aus ... die fehlenden Messwerte deuten darauf hin.



Antwort von dienstag_01:

Natürlich, es ging ja darum (in Bezug auf das Chart von Domain), dass 0-255 Grafiken importiert ins NLE dort mit 16-235 landen.
Und DU HATTEST WIDERSPROCHEN.



Antwort von WoWu:

Sorry, ich kann nicht folgen ....
sorry ... domain hat da soviel unterschiedliche Dinge eingeworfen, dass ich das nicht wirklich nachvollziehen kann.



Antwort von dienstag_01:

Ich versteh gerade och nichts mehr ;)
Das lass ich einfach mal so stehen: Aber die beiden Bilder stehen wie folgt zueinander:
In YCbCr eingefügt stehen sie genau im Wertesystem, übrigens auch sehr schön die Differenz zwischen Y und C zu sehen.
Es entsprechen die Werte 16-240 also 100%
100% für RGB entspricht aber nicht 700mV sonder 1 V.
Die Messung "übersetzt" also die 100% und nicht den Wertebereich.
Wenn Du den wertebereich in RGB anzeigen kannst, müsste, wenn es reine Messungen und keine unterschiedlichen Mappings sind, die Welt wieder stimmen. Das ist YCbCr



Antwort von WoWu:

Jau, das ist klar, aber eben mit einem Messfehler in RGB.

Ich spring jetzt mal raus .... schwimmen.
Traumhaftes Wetter.



Antwort von dienstag_01:

Ich spring jetzt mal raus .... schwimmen.
Traumhaftes Wetter. DAS gibts doch wohl nicht ;)



Antwort von Alf_300:

So traumhaft ist es in D auch

http://www.wetter.com/kolumbien/bogota/COXY00001.html



Antwort von olja:

Extrembeispiel, bis Kante. 2 mal überbelichtet. Canon Legria und GH2. Die GH2 bleibt bei 100 stehen, der Camcorder schiebt bis 255. (bild 3 und 4)

Übrigens korrekt belichtet sieht man bei identischen Bedingungen des Testcharts (bild 1,2), wie x.v. Color erweitert (bild2 ). am besten im Vectorscope (Urknall).

Bitte jetzt nicht wieder, das Schwarz nicht aufsetzt und der Farbraum daher nicht genutzt wird.



Antwort von WoWu:

@Olja

Du kannst in den Wertebereich reinlegen, was Du willst, Du gewinnst damit kein einziges Sample, Du erhöhst nur das Offset damit.
Es gab/gibt US Kameras, die unten noch ein Offset von 7,5 IRE, also rd 50 mV serienmässig bedienen und den gleichen "Betrag" oben über 100% hinausgehen, um die dazwischen liegenden 700mV zu erhalten.
Das bedeutet lediglich, dass man das Offset beseitigen muss.
Das bedeutet nicht, dass Du auch nur einen Wert mehr hast und es bedeutet, das jedes Equipment, das dem Standard entspricht, Dir Deine Signale abhackt.
Der Standard beschreibt, die Menge der Werte mit 220 und die Lage des korrekten Signals mit 16/235 innerhalb von sRGB mit 1/255.
Verschiebst Du nun Dein Signal nach oben, geht es unten flöten. Verzerrst Du das Signal (spreizen) im NLE hast Du jede Menge Dither, weil es keine aufgenommenen Werte für die fehlenden Plätze gibt.

Würde jetzt Dein so aufgenommenes Signal auf einen standardisierten Monitor treffen, würden alle Werte oberhalb von 235 auf diesen Wert gesetzt und Du hast dann ausserdem noch ein gepflegtes Banding.

Gute Kameras haben Farbbalken-Generatoren, die eindeutig aufzeigen, in welchem Bereich, mit welcher Einstellung gearbeitet wird.
Man sieht, das hatte schon seine Berechtigung.



Antwort von olja:

@Olja

Du kannst in den Wertebereich reinlegen, was Du willst, Du gewinnst damit kein einziges Sample, Du erhöhst nur das Offset damit.
Es gab/gibt US Kameras, die unten noch ein Offset von 7,5 IRE, also rd 50 mV serienmässig bedienen und den gleichen "Betrag" oben über 100% hinausgehen, um die dazwischen liegenden 700mV zu erhalten.
Das bedeutet lediglich, dass man das Offset beseitigen muss.
Das bedeutet nicht, dass Du auch nur einen Wert mehr hast und es bedeutet, das jedes Equipment, das dem Standard entspricht, Dir Deine Signale abhackt.
Der Standard beschreibt, die Menge der Werte mit 220 und die Lage des korrekten Signals mit 16/235 innerhalb von sRGB mit 1/255.
Verschiebst Du nun Dein Signal nach oben, geht es unten flöten. Verzerrst Du das Signal (spreizen) im NLE hast Du jede Menge Dither, weil es keine aufgenommenen Werte für die fehlenden Plätze gibt.

Würde jetzt Dein so aufgenommenes Signal auf einen standardisierten Monitor treffen, würden alle Werte oberhalb von 235 auf diesen Wert gesetzt und Du hast dann ausserdem noch ein gepflegtes Banding. Erklär mir einfach nur, warum Cam A das Ergebnis liefert, Cam B aber nicht. ICH lege gar nichts rein, sondern gucke mir ooc an. Mehr nicht.

Wenn es korrkt belichtet ist, ist alles in Butter ;-)



Antwort von WoWu:

Weil Cam B die billigste Methode benutzt, ein Signal zu transportieren und einfach clippt.
Und weil A u.U. NTSC bedient und mit einem Offset versehen ist.
Dann sehen die Bilder so ähnlich aus:



Antwort von domain:

Recht schönen Dank an Dienstag und WoWu für ihre geduldige Aufklärungsarbeit. Ihr habt ja so recht.
Die RGB-Pipette von Photoshop ist für diese Art von Messungen zu grob. Habe jetzt mal ein Differenzbild zwischen dem original BelleNuit-Testchart und einem Snapshot aus dem NLE von eben diesem importierten Testchart gemacht. Zunächst keine Differenzen zu bemerken. Dann das Schwarz aufgehellt und enorm im Kontrast verstärkt.
Jetzt erst sieht man, was passiert, wenn zuerst auf 220 Bit-Stufen umgemappt und dann wieder auf 255 aufgeblasen wird.
Es stimmt also, dass importierte Grafiken und Fotos immer auf 16-235 gestaucht werden. Wenn dann später ein Frame zur Ansicht herausgelöst wird, egal auf welchem Weg, dann erfolgt immer eine Rückführung auf 0-255 allerdings mit den von WoWu vorhergesagten Fehlern.
Die zebraartigen Streifen stellen übrigens die Fehler im Graukeil dar.

zum Bild http://www.fotos-hochladen.net/uploads/difbild1pf0dijgxkm.jpg


zum Bild




Antwort von olja:

Kann man nicht direkt mit einem Eyedropper die Werte aus dem NLE nehmen ?



Antwort von dienstag_01:

Kann man nicht direkt mit einem Eyedropper die Werte aus dem NLE nehmen ? Kann man eigentlich schon.
Domain hat aber versucht rauszubekommen, ob meine/unsere Aussage zutrifft, dass auch Grafiken im Video letztlich 16-235 sind - auch wenn 0 und 255 DRAUFSTEHT (wie bei dem Chart) ;)
Und da die Anzeige im NLE wiederum nach 0-255 gemapped ist, hat er sich über das Differenzbild beholfen.
So hab ich das verstanden.



Antwort von domain:

Der eigentliche Krampf und das eigentliche Thema dieses Threads ist ja der unsägliche Kampf mit der 16-235 RGB-Umrechnung. Aus meiner eingeschränkten Sicht ein Anachronismus aus der Analogwelt und aus alten TV-Zeiten, wo mit realen Anzeigeinstrumenten die Signalstärke in Millivolt gemessen wurde und ein Spielraum für Über- und Unterschwinger existieren musste.
So und jetzt zum eigentlichen Problem: so gut wie alle Kameras zeichnen in diesem 236 -255 Überschwingerbereich auf und damit kommt es im Normalfall im NLE zu Luminanzverlusten und Farbverfälschungen der nicht mehr dargestellten Überschwingerbereiche.
Also haben Generationen speziell von Panabesitzern einiges an Durchzeichnung in den Lichtern verschenkt und unwissend einen Türkishimmel in Kauf genommen und könnten sich im Nachhinein die Haare raufen, weil sie die obligate und völlig verrückte Luminzkorrektur nicht als eine der ersten durchgeführt haben.



Antwort von Frank B.:

Könnt ihr mal für einen technischen Deppen erklären, warum der Himmel da türkisfarben wird und nicht einfach nur überstrahlt/ clippt?

Meine Erfahrung mit der Panasonic SD 300 ist, dass das gesamte Bild türkisstichig ist, allerdings nur im Automatikbereich, weniger oder gar nicht in der manuellen Einstellung.



Antwort von domain:

Der Türkisstich im Himmel kommt zustande, wenn der Blaukanal über 235 gekappt ist, obwohl er noch bis 255 vorhanden wäre, sich aber gleichzeitig Grün und Rot noch im zulässigen Bereich bewegen.
Habe ich weiter oben an zwei Beispielbildern demonstriert.
Kann mit manueller Belichtung oder generell mit leichter Unterbelichtung vermieden werden oder mit flacheren Pictureprofilen.



Antwort von Angry_C:

Kann mit manueller Belichtung oder generell mit leichter Unterbelichtung vermieden werden oder mit flacheren Pictureprofilen. Wobei man dann bei den Panasonic Consumer Camcordern nicht nur leicht unterbelichten müsste, und dann lässt das Resultat auch zu wünschen übrig.

Dann belichte ich lieber normal und ziehe die Luminanzkurve runter.



Antwort von domain:

Richtig, aber sag das mal dem Tiefflieger.
Er glaubt wirklich, ohne diese obligaten Luminanzkorrekturen auskommen zu können und zeigt uns andauernd Bilder mit indiskutablen Kontrasten, also speziell mit ausgebrannten Lichtern.
Dabei kann diese Kameraserie viel mehr, aber ihre Qualitäten können sich nur mit diesen Luminanzkorrekturen wirklich entfalten.



Antwort von Frank B.:

Danke, domain, für Deine Ausführungen. Ich verstehe allerdings noch nicht, warum nur der Blauanteil so hoch ist, dass er gekappt wird, denn der Himmel (eigentlich blau) müsste ja noch richtig belichtet sein. Meist sind es ja die Wolken, die dann überstrahlen und in einer weißen Soße untergehen, so dass darin kaum noch Strukturen zu erkennen sind. Die Wolken sind aber Weiß, d.h. die roten, blauen und grünen Anteile müssten gleichmäßig gekappt werden. Auch verstehe ich nicht, warum dann das ganze Bild mit einem Türkisschleier überzogen wird, also auch die anderen korrekt belichteten Anteile.



Antwort von Angry_C:

Richtig, aber sag das mal dem Tiefflieger.
Er glaubt wirklich, ohne diese obligaten Luminanzkorrekturen auskommen zu können und zeigt uns andauernd Bilder mit indiskutablen Kontrasten, also speziell mit ausgebrannten Lichtern.
Dabei kann diese Kameraserie viel mehr, aber ihre Qualitäten können sich nur mit diesen Luminanzkorrekturen wirklich entfalten. Tja, wie lange habe ich mit den Pana-Mühlen gehadert. Ich wusste einfach nicht, wie dem beizukommen ist. Dabei war die Lösung so einfach. Man muss die Luminanzkurve einfach VOR der Farbkorrektur herunterziehen und nicht hinterher.

Das man nun neben der hohen Detailauflösung mit ganz einfacher Nachbearbeitung nun auch noch stimmige Farben und eine angenehme Gradation erhält, ist der Grund, warum ich es diesmal mit der X929 länger aushalten werde. (Auch wenn mich die Canon G30 so lieb anschaut) :-)



Antwort von olja:

Wenn ich so an die Tiefgaragenbilder denke, liegen doch Welten zwischen dem Bildeindruck von Pana und Canon. Mit ein bischen Lumastauchen soll jetzt alles o.K. sein ? Irgendwie schwer vorstellbar



Antwort von Angry_C:

Wenn ich so an die Tiefgaragenbilder denke, liegen doch Welten zwischen dem Bildeindruck von Pana und Canon. Mit ein bischen Lumastauchen soll jetzt alles o.K. sein ? Irgendwie schwer vorstellbar Bei den Lichtverhältnissen sieht die Panasonic natürlich keinen Stich gegen die Canon. Da geht"s mit der Detailauflösung steil bergab.

Bei guten Lichtverhältnissen wendet sich aber das Blatt.



Antwort von WoWu:

Moin,

So, wie ich das sehe, liegt es daran, dass nicht das gesamte C Signal im NLE bearbeitet wird, sondern R'G'B' in Einzelsignalen. Und dass das Gesamtsignal offenbar schon (zu hoch) also mit einem Offset versehen, eingespielt wird.
Mit andern Worten ... das mapping ins NLE ist nicht in Ordnung.
((Vermutung)-ohne jetzt zu wissen, wie das Signal aus der Kamera wirklich aussieht)
Denn ich vermute mal, das Signal über HDMI auf ein TV-Gerät sieht ok aus.

Komischerweise kann das ja hier keiner mal eben prüfen ??!!
Hat keiner, der die Kamera hat ein TV Gerät mit HDMI Eingang ?


@Dienstag
Ich hab mir nochmal Deine beiden Messungen angesehen .... eigentlich ist doch alles i.O. Beide "Neon"Bilder zeigen Luma 235/700mV und darüber (weiss) Chroma 240/714mV an.



Antwort von Angry_C:


Komischerweise kann das ja hier keiner mal eben prüfen ??!!
Hat keiner, der die Kamera hat ein TV Gerät mit HDMI Eingang ?
Ich mache das heute Abend einfach mal, wenn niemand etwas dagegen hat. ;-)



Antwort von dienstag_01:

@Dienstag
Ich hab mir nochmal Deine beiden Messungen angesehen .... eigentlich ist doch alles i.O. Beide "Neon"Bilder zeigen Luma 235/700mV und darüber (weiss) Chroma 240/714mV an. Aber die Werte gehen ja höher, oder?
Und diesen Bereich (gesamt oder teilweise) kann ich *zurück holen*?



Antwort von WoWu:

Die brauchst Du nicht zurückholen, die sind standardkonform:
Die 235 für Luma entsprechen 700 mV .... alles ok
Die 240 für Chroma entsprechen 714 mV .... da ist zwar keine Skale mehr dran, aber wenn 235 stimmen, müssten die (identische) Analogskala für 240 auch stimmen, zumal auf dem andern Bild ja auch die Verhältnisse exakt stimmten.

Für mich sieht das wie ein astreines Signal aus.

Übrigens: Alle Achtung an AVID, das ist eine super gute Darstellung des Gesamtsignals.



Antwort von dienstag_01:

@WoWu
Aber die (Bild-) Werte rauschen doch voll drüber.



Antwort von domain:

Übrigens: Alle Achtung an AVID, das ist eine super gute Darstellung des Gesamtsignals. Das habe ich mir auch schon gedacht. Scheint das einzig ehrliche im Reigen zu sein.



Antwort von WoWu:

@WoWu
Aber die (Bild-) Werte rauschen doch voll drüber. Nee, wo denn ?
Das Einzige, was nicht ablesbar ist, ist der analogwert für Chroma zwischen 235 und 240, weil da keine Skalierung mehr dran ist.

Aber wenn das identische Signal auf der andern Darstellung ebenfalls 235/240 repräsentiert, dann stimmt das, obwohl da auch keine Skalierung dran ist.
Geht man also davon aus, dass das Verhälnis zwischen Luma und Chroma stimmt, wenn effektiv die Luma Werte stimmen, dann passt das.

Aber, wie gesagt, es wäre schöner, würden die Skalierungen weitergehen, weil das der einzige Raum für Spekulationen ist, der bleibt.

Sowas wie Skalierungen sollen die sich mal (alle NLE Hersteller) von R&S oder Tektronix abgucken.

Denn die Frage in diesem Fall wäre nämlich:
Wie stelle ich den Chromapegel ein, wenn ich keine Skala habe.



Antwort von dienstag_01:

@WoWu
Wenn alles i.O. wäre, warum greift dann der Safe Color Limiter mit diesen Werten:



Antwort von WoWu:

@WoWu
Wenn alles i.O. wäre, warum greift dann der Safe Color Limiter mit diesen Werten: Ich kann auch nur deuten, was ich auf den beiden Bildern sehe.
Es wäre beispielsweise hilfreich, zu jeder Messung das Bild zu sehen, dann könnte man nämlich besser beurteilen, ob in den oberen Bereichen clippt oder ob das schon aus der Kamera so gekommen ist.
Wenn Du jetzt sagst, ein Zusatz clipped bereits, dann wäre die Indormation zusätzlich zum Bild schon hilfreich gewesen.
Ich bin davon ausgegangen, dass es sich um ein Originalsignal handelt und nicht um ein bearbeitetes Signal.

Das würde also auch bedeuten, dass (je nachdem wie der Kompressor eingestellt ist), das Limit nicht 240 sondern 255 ist. (Wie gesagt, mit einer Skalierung wäre das offensichtlicher gewesen).

Ist die Frage jetzt ... warum ist das so,
oder ist die Frage, wie bekommt man das zurück ?

Ich würde aber erst mal den Limiter da rausnehmen und das Originalsignal anschauen und dann entscheiden, denn der Limiter sollte eigentlich wirklich nur die Spitzen wegnehmen.

Diese "Broadcast save" Filter sind wirklich nur für "HauRuck" Editoren oder wenn's mal extrem schnell gehen muss.



Antwort von dienstag_01:

@WoWu
Die bisherigen Bilder waren immer unbearbeitetes Material.
Dazu hast du gesagt, sie wären i.O.
Jetzt habe ich mal testweise einen Safe Color Limiter drauf gelegt.
Wenn alles in der Norm wäre, sollte der doch gar nicht greifen, oder.
Macht er aber (sieht man in den Curves, die habe ich hier NICHT reingestellt.)
Wichtig: Im eigentlichen Bild mit ohne und ohne Limiter sehe ich keinerlei Differenz.



Antwort von WoWu:

Dann ist der falsch eingestellt oder für's falsche Signal.

Es gibt doch nur einen Standard und der sagt 235/240. Mit den richtigen Messmethoden brauch ich keinen Limiter, wen alles stimmt. Also, schau Dir mal das Setting des Limiters an, wie der eingestellt ist.
Und wo liest Du bei dem Teil denn ab, um welchen Betrag er komprimiert ??
Wie sieht denn das Signal aus, wenn Du ihn rausnimmst ... vielleicht macht er ja gar nichts.



Antwort von dienstag_01:

Die Limiter Settings siehst du oben im Bild.
Und wo liest Du bei dem Teil denn ab, um welchen Betrag er komprimiert ?? Das wiederum sehe ich in den Kurve.



Antwort von WoWu:

Dann zeig mal die beiden Kurven, einmal mit und einmal ohne Limiter.



Antwort von dienstag_01:

Es wird einem heutzutage einfach nicht vertraut!



Antwort von domain:

Die Limiter bringen doch im Privatbereich nichts, außer dass ev. verwertbare Bereiche endgültig abgeschnitten werden.
Allerdings sieht das für TV-Techniker anders aus, denn die bekommen mit stierem Blick auf ihr vu-Meter Flatulenzen, wenn der Bereich 700 mV überschreitet :-)



Antwort von WoWu:

Wenn ich das jetzt richtig definiere, führt er alle Werte im Luma, die sich oberhalb von 700 mV befinden auf den Wert 235 zurück. Das können aber eben auch Transienten sein sodass es im Bild nicht einmal sichtbar wird.
Schöner wäre ein Limite, der die Werte auch "verwerfen" könnte, kann man das anwählen ? Denn Limitieren heisst ja nicht unbedingt, dass man die illegalen Werte weiter, nur auf einer andern Position nutzen will. Limitieren kann ja auch (wie hier) heissen, dass man oberhalb eines eingestellten Wertes die Werte nicht mehr verwenden will.
Sonst wäre es ja eine Kompression mit den entsprechenden Parametern.

Im Chroma scheint das Teil nichts zu machen, also eigentlich dürfte sich am Bildsignal nur wenig, bis gar nichts ändern und wenn, dann nur in den Spitzen, die ohnehin kein wirkliches Nutzsignal darstellen.

@Domain

Wenn Du als privaten Bereich den Weg vom Camcorder ins TV gerät siehst, hast Du Recht.
Aber jeder, der sein Signal weggibt, sollte alle unbeabsichtigten Beeinträchtigungen berücksichtigen.
Das hat mit VU-Meter nur insofern was zu tun, als dass die selbsternannten Praktiker keine Ahnung von der Materie haben und das auf den Rest der Welt übertragen wollen.



Antwort von dienstag_01:

Das Bildsignal ändert sich nicht.
Auf die Art des Zugriffs hat man keinen Einfluss. Es gibt aber noch einen anderen, da müsste ich mal nachlesen.
Sollte/Könnte man die Limiter Einstellungen noch etwas weniger eingrenzen?
Oder ist das OK so (für PAL).



Antwort von WoWu:

Wenn man im Bild nichts sieht, bearbeitet das Teil an der Stelle auch nur die Transienten. Das ist total ok.
Eigentlich sollte das auch genau die Funktion von "Broadcast save" sein.
Also: So sehen gute Signale aus, die man dann auch "auf die Reise" schicken kann.



Antwort von dienstag_01:

Ich habe die beiden Bilder nochmal neu gemacht, da war vorher ausversehen eine Bearbeitung drin:



Antwort von WoWu:

ach nee... :-(((
Lass die Bearbeitung drin ... und gut iss.



Antwort von dienstag_01:

Ja, vom Rumspielen.



Antwort von WoWu:

Das wird ja wie bei Tieffliegers unendlicher Bildgeschichte.

Es ist eigentlich alles erwähnt, sodass Du selbst eine fundierte Beurteilung vornehmen können müsstest.



Antwort von dienstag_01:

Ich hätte noch zwei Fragen:
Nochmal zurück zu deiner Aussage, schon das unberabeitete Originalvideo wäre eigentlich i.O. Dann könnte ich das doch eigentlich ohne Limiter wetergeben, oder?
Und, du hast es vorhin schon angesprochen, mit welcher Art Farbkorrektur veränder ich nur die Chromawerte?

Edit: Und wenn du mich noch EINMAL mit Tiefflieger vergleichst...



Antwort von WoWu:

...;-)

Das "broadcast save" legt man drauf, um die Transienten aus den "geschlossenen Bereichen" zu beseitigen weil automatisierte Abnahmesysteme in TV-Anstalten nur untersuchen, ob die Werte gesetzt sind, sie aber nicht interessiert, was eigentlich darin steckt.
Insofern "putzt" man den Bereich. Man achtet eben nur drauf, dass man Bildinhalte vorher durch die entsprechende Farb/Luma Korrektur so bearbeitet hat, dass das Bild ordentlich aussieht.

Hackt der Limiter noch was weg, hat man noch nicht gut genug gearbeitet.
Insofern : Limiter = ja, aber nur, um den Wertebereich zu bereinigen.

Das Verhältnis Luma/Chroma muss eigentlich von der Kamera her stimmen. Stimmt das nicht, ist die Kamera verkurbelt !!!


Womit:
Proc-Amps sind das magische Tool, also Werkzeuge, die den gesamten Wertebereich Luma/Chroma -in einem Stück- packen und anheben oder absenken können.

Solche Tools, wie die Gammakurve sind in dem Zusammenhang nicht geeignet, weil sie die Kurve verändern und damit die Verhältnisse innerhalb des Arbeitsbereiches.
Sowas ist, wenn nötig einer Farbkorrektur vorbehalten.

Nun kommt bestimmt gleich wieder einer der Praktiker aus dem Busch und sagt: "macht man doch sowieso".
Nee, mach man nicht "sowieso" ... es soll auch einwandfreie Kamerasignale geben, von exakt arbeitenden Profis und guten Kameras, an die man keine Hand mehr anlegen muss.



Antwort von dienstag_01:

Ok, danke.
Kommt bestimmt nochmal ne Frage, muss aber erstmal los.



Antwort von Angry_C:

@Wowu:

Ich habe übrigens gerade Clips der X929, die im NLE überbelichtet waren, per HDMI an meinem Fernseher angeschaut. Dort sehen sie einwandfrei aus.

Schaut also so aus, als wenn der HDMI Datenstrom die richtigen Informationen an den Fernseher sendet.



Antwort von WoWu:

Sehr schön, vielen Dank.
Mich interessieren nur eben beide Zustände, um

a) zu sehen, dass beide Zustände in der Kamera auch aktiviert werden können

b) dass entlang der beiden Zustände auch unterschiedliche Versionen auf HDMI durchgereicht werden.

Nur so läst sich feststellen, ob eine unterschiedliche Signalisierung nach HDMI stattfindet, also ob auch ein NLE sich daran orientieren könnte.

Es geht ja hier darum festzustellen, ob ein Bug im NLE ist oder nicht.

(Falls Dein TV ein Farbmangement hat, stell das für den Test bitte ab.)
Die Frage zu Deiner Message ist auch: was für ein File war das: xvYCC oder standard ?

Wenn es ein Standardfile war, ist das ja schon mal der erste Schritt in die Richtung, dass das Kamerafile offenbar o.k. ist aber wir brauchen "quasi" die Gegenprobe.



Antwort von Angry_C:

Es war ein Standardfile und xvycc wird zwar vom Fernseher unterstützt, war aber abgeschaltet.

Weitere Tests werden folgen, aber erst einmal lässt mich meine bessere Hälfte da nicht ran:-)

Ich habe aber extra noch einmal ein Motiv mit normalem Farbumfang und erweitertem Umfang aufgenommen.

Im NLE sehen sehe ich am Waveform keinen Unterschied. Was sagt uns das?



Antwort von WoWu:

Das wundert mich jetzt nicht wirklich. Es deutet einmal mehr darauf hin, dass das Programm keine 'gamut specific datas' ausliest und nach "schema'F" alles mapped, was es zu fassen bekommt.

Aber lass uns die Gegenprobe machen und dann wissen wir mehr.
Erst einmal müssen wir sicherstellen, dass es auch im Strom korrekt signalisiert wird.

"Take you're time" .... es ist nicht eilig.



Antwort von Angry_C:

So, durfte nun doch nochmal an den Fernseher.

1. Ich habe den HDMI Eingang am Panasonic Plasma auf Auto gestellt.
2. X929 angeschlossen und und auf Recmode gestellt.
3. Im Kamera Menü auf Digital Cinema Colour eingeschaltet, Fernseher erkennt 1080p50 x.v.colour und zeigt es per Onscreenanzeige kurz an. Kurze Aufnahme gestartet.

4. Im Kamera Menü Digital Cinema Colour ausgeschaltet, Fernseher zeigt nur 1080p50 an. Kurze Aufnahme gestartet.

5. Kamera in den Playbackmodus geschaltet und beide Clips abgespielt.
Beim ersten wird vom Fernseher auch wieder x.v.colour angezeigt, beim zweiten nicht.

Somit dürfte klar sein, dass die Kamera einwandfrei arbeitet und das NLE das nur besser interpretieren muss.



Antwort von WoWu:

Hat sich in der Bildqualität was im TV geändert, weil wir noch mal sehen müssen, ob die Kamera nur das Signaling wechselt und erwartet, dass das Folgegerät das Mapping erledigt oder ob die Kamera auch einen standardkonformes File herstellt.
Mit andern Worten: Produziert die Kamera 235er Files und signalisiert "standard"
oder produziert sie 255er Files und signalisiert nur "standard".

das ist jetzt die grosse Frage.
xvYCC files müssten eigentlich etwas heller sein und kräftigere Farben haben, also Standardfiles.

Deswegen ist es wichtig, dass ggf. CM nicht dagegen anwirbt und abgeschaltet ist.

Wie gesagt, keine Eile ... und das ist dann auch der letzte Versuch.
Gruss an die Frau :-))



Antwort von Angry_C:

Am Fernseher ist das x.v.colour video gesättigter und ist in der Tat etwas heller.

Auch am Computer ist das der Fall. Ich habe jeweils ein Snapshot aus VLC gemacht. Nicht erschrecken, die Kamera ist schlecht bei schlechtem Licht (+15DB).

Aber beide Clips verursachen in Premiere Highlights bei ca. 1.07V oder 107%.

Daher würde ich sagen, dass die Kamera immer von 0-255 aufzeichnet, ob x.v. color oder net.

1. Bild x.v.colour
2. Bild normal



Antwort von olja:


Aber beide Clips verursachen in Premiere Highlights bei ca. 1.07V oder 107%.

Daher würde ich sagen, dass die Kamera immer von 0-255 aufzeichnet, ob x.v. color oder net. Genau das habe ich eben auch festgestellt und mich gewundert, warum ich Werte über 100 bekomme. Du kannst übrigens das sehr schön im Vectorscope sehen. Gleiches Motiv und nur mal x.v color umgeschaltet. Da siehst Du, warum die Farben kräftiger wirken.



Antwort von Angry_C:

Ja, das ist schon nen Ding. Da die Panasonic ja eher flau aufzeichnet, macht es meiner Meinung nach ja Sinn, mit x.v.colour aufzunehmen, wenn es in der Amplitude eh kenen Unterschied zu machen scheint, und man bei beiden Modi die Highlights "retten muss".

Zumindest hat man dann out of cam schonmal kräftigere Farben, wenn man es mag. Ich mag's ;-)



Antwort von olja:

Davon abgesehn scheinen sich die Waveformanzeigen der NLE's auch noch zu unterscheiden.
Im Moment traue ich nur DaVinci. Zumindest bringt er Übereinstimmung bein Belle Nuit Chart (also auch den Wert 255) Bei FCPX kann ich den mit der Pipette nehmen, aber Waveform endet bei 100 ! Könnte man jetzt auf die Verarbeitung von dem Tiff schieben, aber sehen kann man 255, nur der Waveform zeigt es nicht an.

Mein Wolkenbild sieht im Waveform bei DaVinci auch anders aus.



Antwort von WoWu:

Aber beide Clips verursachen in Premiere Highlights bei ca. 1.07V oder 107%.

Daher würde ich sagen, dass die Kamera immer von 0-255 aufzeichnet, ob x.v. color oder net. Nein, eben nicht !!

Wenn beide Signale am HDMI Eingang die korrekten Werte anstellen (signalisierung) und dazu beide Signale unterschiedlich dargestellt werden, nimmt die Kamera entlang der Spezifikationen korrekt auf !

Premiere baut den Mist.

Nun wird man untersuchen müssen, wieso die nicht mal ein standardisiertes Signal vernünftig gemapped kriegen.

Und damit haben wir auch die erste Antwort auf die Eingangsfrage:
Durch die Änderung im Begrenzungsverhalten haben sie einen bestehenden Bug beseitigt, weil sie, würden sie ein Standardsignal korrekt mappen, bei 235/240 mit einem Clip korrekt handeln würden (die GH2 macht das sogar schon in der Kamera, vermutlich um Datenrate zu sparen).



Antwort von gast5:

Jetzt wäre natürlich noch interessant wie sich speedgrade im Verhältnis zu Premiere verhält...ein Vegas ein Edius ein smoke ein Piranha ..

Der colorpipete Test ist nicht uninteressant zumindest um zu sehen wie sich schon alleine die unterschiedliche monitortechnologie auf das Sehen auswirkt..



Antwort von Angry_C:


Und damit haben wir auch die erste Antwort auf die Eingangsfrage:
Durch die Änderung im Begrenzungsverhalten haben sie einen bestehenden Bug beseitigt, weil sie, würden sie ein Standardsignal korrekt mappen, bei 235/240 mit einem Clip korrekt handeln würden (die GH2 macht das sogar schon in der Kamera, vermutlich um Datenrate zu sparen). Naja, das neue Premiere macht beim Import der Clips nichts anderes als die Vorgängerversionen. Nur der neue Lumininanzkurvenfilter cuttet einfach mal die Highlights weg. Das ist das schlimmste, was Premiere mit dem Material anstellen kann. Von Bugbeseitigung kann eigentlich keine Rede sein.



Antwort von domain:

Jetzt wäre natürlich noch interessant wie sich speedgrade im Verhältnis zu Premiere verhält...ein Vegas ein Edius ein smoke ein Piranha .. Eric Olson hat schon 2009 auf eine spezielle Vegas-Eigenschaft hingewiesen:

Although the 709 transfer function specifies 16 as black and 241 as white. The 8-bit video rendering path in Sony Vegas processes the full 0 to 254. As a result super blacks and super whites are automatically available when color grading. Note, however, that Adobe Premier may delete the x.v.color information. I'm not sure about other NLEs.
Let's featurerequest/bugreport about superwhite and chromaproblems
http://www.hv20.com/showthread.php?1219 ... maproblems
There is no harm recording x.v.color mode, because in the worst case, the extra dynamic range is simply ignored.

Aus: http://www.dvinfo.net/forum/canon-xa-vi ... u-use.html



Antwort von gast5:

ich habe die Geschichte nun auch einmal angetestet mit FCpx und Davinci..

zwischen den beiden sind Programmen ist mir nichts unterschiedliches aufgefallen..

links Ohne x.v.Color und rechts mit.. als Prores gewandelt aus AVCHD
https://www.dropbox.com/s/ww7mxlg5v92z9 ... rores.tiff

und als Original...

https://www.dropbox.com/s/i3m0a4noraj5giy/xvcolor.tiff



Antwort von olja:

ich habe die Geschichte nun auch einmal angetestet mit FCpx und Davinci..

zwischen den beiden sind Programmen ist mir nichts unterschiedliches aufgefallen..

links Ohne x.v.Color und rechts mit.. als Prores gewandelt auch AVCHD
https://www.dropbox.com/s/ww7mxlg5v92z9 ... rores.tiff

und als Original...

https://www.dropbox.com/s/i3m0a4noraj5giy/xvcolor.tiff Kann auf Dropbox von hier nicht zugreifen. Hast du mal den Testchart angeguckt ?
http://www.belle-nuit.com/test-chart

Bei Davinci sehe ich die 255 im Waveform, bei Fcpx ist bei 100% Ende (obwohl die Pipette auch 255 sagt). Ok, ist nen Tiff, aber trotzdem.



Antwort von gast5:

das TIFF geht in FCPX von 0 bis 100 und von 0-700

bei meinen Testvideos komme ich in einen Bereich ohne x.v von -4 bei blau bis 107 über alle drei Kanäle..

Beim Testvideo mit x.v auf -4 bei blau und maximal 100 Prozent bei allen Kanälen



Antwort von Angry_C:

ich habe die Geschichte nun auch einmal angetestet mit FCpx und Davinci..

zwischen den beiden sind Programmen ist mir nichts unterschiedliches aufgefallen..

links Ohne x.v.Color und rechts mit.. als Prores gewandelt aus AVCHD
https://www.dropbox.com/s/ww7mxlg5v92z9 ... rores.tiff

und als Original...

https://www.dropbox.com/s/i3m0a4noraj5giy/xvcolor.tiff Von welcher Kamera stammen diese Clips?



Antwort von olja:

das TIFF geht in FCPX von 0 bis 100 und von 0-700
Und das Tiff in Davinci müßte höher gehen. Die Ecke oben, die die 255 repräsentiert.

Ja, und ich sehe mit oder ohne x.v. color auch nicht, das hier irgendwas konsequent innerhalb von 16-235 landet, so wie bei der GH2.

Unterschiede sind aber trotzdem zu erkenennen zwischen x.v color an oder aus (Farbsättigung, Vectorscope).

Kleiner Vortrag gefällig ?
http://pro.sony.com/bbsc/video/videoCha ... d-int:home

TC 20:00 !



Antwort von gast5:

der RecLevel Unterschied in Davinci

http://forum.blackmagicdesign.com/viewt ... ope#p23386
Because you’re evaluating the internal state of the image data, the scales of the WFM and Parade scopes always reflect 10-bit full range data from 0-1023, regardless of your project’s Colorspace Conversion settings. die Files stammen aus einer Pana v707



Antwort von olja:

Motion, danke. Somit bleibt noch die Frage, warum der Eyedropper 255 anzeigt, Waveform aber bei 700 max ist. Dachte eigentlich, das das Vorschaubild irgendwie analog dem Waveform ist, dachte..
Wie solche Sachen bei FCP behandelt werden, kann man wohl einstellen (White,oder Superwhite), aber bei FCPX wohl nicht (d.h. wie solche Bilder behandelt werden sollen, RGB).

Trotzdem, wohl sehr beliebtes Thema ,-)
http://www.eoshd.com/comments/topic/661 ... d/?p=12589



Antwort von dienstag_01:

Somit bleibt noch die Frage, warum der Eyedropper 255 anzeigt, Waveform aber bei 700 max ist. Dachte eigentlich, das das Vorschaubild irgendwie analog dem Waveform ist, dachte.. Ich hatte ja schon mehrmals darauf hingewiesen, dass die meisten NLEs das Video für die Anzeige nach 0-255 mappen müssen. Wenn man mal genau schaut, sieht man auch, dass sie in den Waveforms nie 16 oder 235 oder auch 255 als Einheiten benutzen. Immer Prozent oder IRE oder mV.
Überleg mal, was eine korrekte Anzeige von 16-235 für das Grading bedeuten würde!!!



Antwort von WoWu:

Ihr setzt jetzt genau das fort, was die Blogs schon viel Jahre tun .... ihr testet einfach wild in der Gegend herum, bekommt 'random" irgendwelche Ergebnisse, völlig egal, was die Ursache ist und ob sie überhaupt vergleichbar sind und streut dazwischen dann noch irgendwelche Stellungnahmen, statt systematisch nun zu untersuchen, warum Premiere das so verarbeitet und es zu einem solchen, falschen Ergebnis führt.

@domain

Die Aussage von dem "Vegas" mann "pflegt" natürlich das eigene Programm.
Grundsätzlich ist es aber so, das alle Programme die Contents richtig mappen sollten (tun sie nicht) und auch die Gamet Informationen korrekt auslesen sollten. (offensichtlich auch nicht)
Denn dann gäbe es keine Unterschiede mehr.
Aber die Gamut Informationen auch nicht richtig auszulesen und den Mangel dann als Vorzug gegenüber andern Programmen zu deklarieren ist natürlich auch nichts anderes als ein Marketingtrick.



Antwort von domain:

Die Thematik wird in der Tat schon seit Jahren diskutiert und betrifft natürlich nicht nur Adobe, aber auch. Ja und? Werden wir mit einer gewissenhaften Ursachenforschung Adobe zu irgend einem Umdenken oder zu irgendeiner Änderung bewegen können?
Im Grunde doch egal. Bei den allermeisten Clps tritt das Problem ja gar nicht auf und wenn, dann weiß man ohnehin was zu tun ist und das ist eine 2cm Mausbewegung auf dem Pad und fertig.
Ärgerlich ist nur, dass man bisher einiges verschenkt hat und neu schneiden wird man deswegen wohl kaum.



Antwort von olja:

Um mal auf Premiere zurückzukommen, der Bug wurde doch bereits von Adobe bestätigt und das er schnell gefixt wird. Was soll man da denn in einem vom Hersteller fehlerhaft bestätigten Programm rumpopeln ?

Der Thread wurde einfach gehijackt und im Moment ist eher der Stand, was die Panas oder meinetwegen auch die Canon, Sonys mit ihren x.v. Colors da in diesem Zusammenhang so treiben und wie sich das Material im NLE od. Fernseher verhält. So richtig klare Aussagen hab ich noch nirgends finden können, da hast Du recht. Überall das gleiche schwammige Gestochere ;-) Wer oder was flagt da, bzw.was wird von wem wie erkannt.


@Domain, so sehe ich das auch. Wir reden hier von Consumercams, wo man evtl. noch ein paar Regler drehen kann, um ein angenehmeres Bild zu bekommen.



Antwort von gast5:

Das kannst du selbst leicht nachprüfen indem du einen 0 -255 Gradient BW in verschiedenen Formaten in die Timeline legst als pip nebeneinander legst und kontrollierst.. In fcpx werden sie immer wie auch bei davinci im Normalfall in 10bit verarbeitet..

Anders herum, die xv werden in fcpx bis 100% gemappt was ohne x.v nicht umgesetzt wird.. Bei den Blauwerten geht's bei beiden Varianten bis NULL

sprich für fcpx hab ich einen Schritt weniger zu beachten wenn ich xv aufzeichne mit den panas in diesem Fall, denn bei der Ausgabe ist es so oder so vollkommen egal da ich kein xv bei der Ausgabe aktivieren kann..

Was noch so anfällt.. Bei fcpx ist die Anpassung, Spreizung oder Mapping nicht erst ab der Timeline sondern ab Import resp. schon im Event aktuell..die Scopes schon mal im Eventbrowser antesten..

Interessant wäre es nur wie sich die Geschichte beim SDI HDMI Ausgang verhält ...



Antwort von WoWu:

@Olja

Von Adobe gibt es dazu ja keine offizielle Aussage und so, wie sie es jetzt machen, ist es ja auch korrekt.

Bleibt als abzuwarten ob sich was ändert.
Vielleicht ändern sie ja auch ihr Mapping endlich mal so, wie es den Flags entspricht .... das wäre dann endlich mal eine richtige Bugbeseitigung.
Davon hätten dann auch die Amateure mal was und müssten nicht ständig an ihrem Signal kurbeln, um es halbwegs passend zu machen.



Antwort von olja:

Meinst du, das sie es so lassen ? http://forums.adobe.com/message/5427944

Ist doch irgendwie Horror.



Antwort von WoWu:

Kann gut sein, denn so, wie es gehandhabt wird, ist es eigentlich richtig.
Auch wenn alle Amatuere schreine.
Man kann eben nur hoffen, dass sie durch die "Bug-Reports" angestossen werden und mal nachschaun'n, ob sie nicht lieber die Files standard-konform mappen.

In dem Link steht ja auch nichts anderes, als dass sie es zur Kenntnis genommen haben und man einen Report schreiben könnte.

Ich stimme da Bubbles Ansicht zu, dass es bei der Überführung nach RGB (Floating-Point Bearbeitung) passiert.
Aber dazu müsste man eben den Workflow mal beleuchten.

(Mal ganz abgesehen davon ... wer "Superweiss" haben will, weil sein Monitor kein Colormanagement hat, kann ja YCC machen. Dafür ist es ja vorgesehen.
Der muss ja nicht in 709 arbeiten und erwarten, dass es wie YCC funktioniert.
Da hat er doch genau das, was er sucht.
Ich verstehe also die ganze Aufregung nicht.



Antwort von olja:

der RecLevel Unterschied in Davinci

http://forum.blackmagicdesign.com/viewt ... ope#p23386
Because you’re evaluating the internal state of the image data, the scales of the WFM and Parade scopes always reflect 10-bit full range data from 0-1023, regardless of your project’s Colorspace Conversion settings. Ok, ich geb jetzt keine Ruhe ;-) Der Belle Nuit in DaVinci schlägt doch bis 1023. Hier kommt mir alles plausibel vor (Colorpicker und Waveform, die Werte sieht man noch vom Picker) Bei FCPX (gleiches Bild) endet der bei 700mV, also 235 !? Da stimmt er nicht.

Lieg jetzt damit falsch ?



Antwort von gast5:

Ich bin gerade unterwegs.. Melde mich später..



Antwort von dienstag_01:

@Olja
Ich kenn mich leider mit Resolve nicht so gut aus, habe es bei mir wieder gelöscht. Aber teste doch mal: die Charts exportiert (als Video) aus FCP und dann importiert nach Resolve. Und dann mal schauen, was verschiedene Color Managment Einstellungen bringen.



Antwort von olja:

@Olja
Ich kenn mich leider mit Resolve nicht so gut aus, habe es bei mir wieder gelöscht. Aber teste doch mal: die Charts exportiert (als Video) aus FCP und dann importiert nach Resolve. Und dann mal schauen, was verschiedene Color Managment Einstellungen bringen. Ich kenne Resolve auch nicht gut, ist nicht unbedingt meine Baustelle. Der Tag hat nur 24h ;-)

Aber, der Testchart, der in FCPX bei 700 endet, kommt mit ProRes exportiert und importiert in Resolve wieder auf 1023. Also das gleich Ergebnis :-O. Der fliegt mit auch 10-Bit ein.



Antwort von dienstag_01:

@Olja
Daran siehst du schon mal, dass dein FCP keen Quatsch macht ;)
Ob das der richtige Workflow mit Resolve ist, weiss ich nicht.
(Sieht so aus, als würde dort wieder auf FullRange gespreizt. Vielleicht muss das so sein. Aber vielleicht funktioniert es mit Color Managment auch anders.)



Antwort von WoWu:

Lasst doch diese 10 Bit daraus, da entsteht doch bereits ein neues Problem.
Sorgt doch erst einmal dafür dass die 8Bit korrekt verarbeitet werden.

Diese kreuz und quer Testerei ist der reinste Dilettantismus.



Antwort von dienstag_01:

Diese kreuz und quer Testerei ist der reinste Dilettantismus. Ok, 10 bit ist Quatsch. Aber sonst, irgendwie muss man doch rausbekommen, wie der optimale Workflow funktioniert.



Antwort von olja:

Ich habe ich ProRes exportiert ! Mehr nicht. Deshalb hab ich es nochmal hinzugeschrieben.Von mir aus nochmal in h264. Wird nur unsauberer, ändert aber nichts.
Büddeschön



Antwort von domain:

Schön langsam kommt mir vor, dass Tiefflieger gar keinen so blöden Workflow für sich entwickelt hat, denn Veränderungen in der Originalfootage verfolgt er ja nicht.
Schneidet in Magix und lässt die Originalqualität wieder smart rausrendern. Damit werden offenbar alle relevanten Flags über HDMI an seinen Plasma weitergeleitet und dort auch korrekt interpretiert.
Aus dem Grund sieht er daheim auch viel mehr (und betont das ja auch) als wir jemals in seinen unzähligen übermittelten Bildern imstande sein werden zu erkennen: keine überstrahlten Lichter und auch kein Türkis im Himmel.



Antwort von Angry_C:

Schön langsam kommt mir vor, dass Tiefflieger gar keinen so blöden Workflow für sich entwickelt hat, denn Veränderungen in der Originalfootage verfolgt er ja nicht.
Schneidet in Magix und lässt die Originalqualität wieder smart rausrendern. Damit werden offenbar alle relevanten Flags über HDMI an seinen Plasma weitergeleitet und dort auch korrekt interpretiert.
Aus dem Grund sieht er daheim auch viel mehr (und betont das ja auch) als wir jemals in seinen unzähligen übermittelten Bildern imstande sein werden zu erkennen: keine überstrahlten Lichter und auch kein Türkis im Himmel. Du vergisst dabei aber den Weißabgleich, der so gut wie nie zufriedenstellend sitzt.

Aus dem Material kann man mit der Luminanzkurve, einer 3-Wege Farbkorrektur, einem unscharf maskieren Filter und natürlich einem guten Rendercodec noch wesentlich mehr herausholen.



Antwort von olja:

Schön langsam kommt mir vor, dass Tiefflieger gar keinen so blöden Workflow für sich entwickelt hat, denn Veränderungen in der Originalfootage verfolgt er ja nicht.
Schneidet in Magix und lässt die Originalqualität wieder smart rausrendern. Damit werden offenbar alle relevanten Flags über HDMI an seinen Plasma weitergeleitet und dort auch korrekt interpretiert.
Aus dem Grund sieht er daheim auch viel mehr (und betont das ja auch) als wir jemals in seinen unzähligen übermittelten Bildern imstande sein werden zu erkennen: keine überstrahlten Lichter und auch kein Türkis im Himmel. Ja, für sich. Aber damit würde ich nicht weiterkommen ;-). Ich liefer auch mal ein paar Filmchen ab und bekomme ein paar Taler dafür.

Ich habe ihm auch mal unrecht getan mit den Lichtern, wobei ich mich an dieser Stelle auch mal entschuldigen möchte. Nie habe ich irgendwie groß Gedanken dran verschwendet, sichtbar ausgebranntes Material zu untersuchen, bzw zu verbessern. Allerdings ist das bei der GH2 auch nicht nötig, bzw. auch nicht machbar. Nur bei dem Camcorder .

Unterschiedliche Ausgangsparameter eben. Aber wenn der Thread nur so ein bischen aufklärt, ist ja auch o.k. ;-)



Antwort von WoWu:

Diese kreuz und quer Testerei ist der reinste Dilettantismus. Ok, 10 bit ist Quatsch. Aber sonst, irgendwie muss man doch rausbekommen, wie der optimale Workflow funktioniert. Als erstes würde ich mal das Material so bearbeiten, wie es kommt und die Finger von der Floating Point Konvertierung lassen, denn sobald Du ein Projekt auf 32 Bit umstellst fliegen dir auch in jeder andern Bearbeitung erst einmal die Werte an den Poller.

Und das, mit dem Weisspunkt .... ich wette, den kurbelst Du erst mit solchen Tranformationen weg. Da musst Du schon ganz schön schief belichten, um den zu ziehen. Denn wenn die Farbverhältnisse untereinander stimmen, stimmt der auch. Die stimmen natürlich nicht untereinander, sobald du oben anfängst zu stauchen und unten zu spreizen.

Ich wette fast, der Workflow liegt im 8 oder 10 Bit Integer am besten.
Deswegen hat bei mir das Material von Reiner auch keinen Ärger gemacht und ist prompt korrekt gelandet, weil ich solche "Floating-Point-Ausfllüge" gelassen habe.
Und Tiefflieger scheint das auch zu lassen.



Antwort von dienstag_01:

@WoWu
Du sprichst hier mit dem Falschen:
Als erstes würde ich mal das Material so bearbeiten, wie es kommt und die Finger von der Floating Point Konvertierung lassen, denn sobald Du ein Projekt auf 32 Bit umstellst fliegen dir auch in jeder andern Bearbeitung erst einmal die Werte an den Poller.

...

Deswegen hat bei mir das Material von Reiner auch keinen Ärger gemacht und ist prompt korrekt gelandet, weil ich solche "Floating-Point-Ausfllüge" gelassen habe. Aber ich kann dir trotzdem sagen, wie Premiere arbeitet: Das Material landet nativ im NLE. Da wird nichts in 32bit umkonvertiert oder sonst was. ERST wenn man einen Color Effect oder Corrector anwendet, erfolgt dessen Berechnung entweder in YCbCr (die nennen das YUV, wird ja scheinbar gerne getan), aber nicht RGB, oder, wenn vorher schon ein anderer Effekt angewendet wurde (z.B. Blur), dessen Berechnung in 32bit erfolgte, wird auch die Farbbearbeitung in 32bit weitergeführt. Das aber auch nur bei speziellen Einstellungen für die Berechnung/den Export.

After Effects arbeitet natürlich anders, dort kann man seine Bearbeitungstiefe selber auswählen.

Deine Vermutung, das File von Reiner könnte irgendwie durch Floating-Point falsch gemapped sein oder dadurch Übertragungsfehler beinhalten, kann demnach nicht richtig sein.

Die letzten Bilder von Olja sind aus Davinci Resolve. Ich bin mir auch nicht sicher, ob das einfache Importieren schon eine Konvertierung des Files in 10bit verursacht. Genausogut könnte es sein, dass, weil Resolve prinzipiell in 10bit arbeitet, der Waveform Monitor mit dieser Anzeige versehen ist, egal ob das File in 8 oder 10 vorliegt. Aber weiss ich nicht genau.



Antwort von WoWu:

Ich würde trotzdem, fast wetten, das hat damit zu tun denn das ist genau der Effekt, der auch auftritt, wenn man ein Fixpoint Projekt auf Floting Point umstellt.
Dann schiessen auch erstmal alle Werte nach oben und man muss sie "von Hand" wieder "einfangen"

Woher weisst Du, wie gemapped wird und woher, dass das Material transparent importiert wird ?
Der Waveform Monitor spricht da eine ganz andere Sprache.
So wie ich das bisher verfolgt (und verstanden) habe, ist das Material doch gleich nach dem Import schon so verschoben.



Antwort von dienstag_01:

Woher weisst Du, wie gemapped wird und woher, dass das Material transparent importiert wird ? Weil Adobe selber immer nur von 32bit Verarbeitung von BESTIMMTEN Effekten spricht, nicht von einem 32bit Workflow.



Antwort von gast5:

Morgen Olja, ich habe mir den Belle Nuit in FCPX und Davici angesehen, da ist kein Unterschied.. die Skalierung geht in beiden Anwendungen 0-100%.

In davinci ist es klar die 10bit Skalierung von 0-1023 und in Fcpx von 0-255 aka 0-100 konform in V.. auch die 0 und 255 Werte werden korrekt ausgewiesen..

https://www.dropbox.com/s/3i6ht6zza29gfcn/Belle.tiff

aufpassen musst du nur beim jpeg Format im Vergleich zu PNG, PSD und TIFF

von links nach rechts...

https://www.dropbox.com/s/8ubesx5c8qmwg ... leich.tiff



Antwort von olja:

Ich kann hier leider keine Dropbox öffnen (Policy).
Bin jetzt ein bischen verwirrt ;-)Du hattest doch selbst geschrieben
das TIFF geht in FCPX von 0 bis 100 und von 0-700 Richtig, bei mir auch. Es liegt also zumindest sichtbar im "sicheren" Bereich
(max 700mV;235)

Das gleiche Tiff (oder auch ausgerendert aus FCPX, wie auch immer) geht in Davinci auf 1023.

so wie ich es verstanden habe, liegt dieser Bereich im 10Bit bei 64-940, ab da "Superwhite"

Das würde doch bedeuten, das hier zumindest sichtbar im Waveform 255 zu sehen ist, oder ?

zusammenfassend

broadcast equipment typically uses broadcast range values (16-235 in 8 bit, 64-940 in 10 bit).



Antwort von Tiefflieger:

Da sind ja 10 Seiten an Information zusammengekommen. :-)
Ich schreibe hier abends um 2300.

***** OT *******
Kurz vorweg, Weissabgleich X909: Man muss beim automatischen Abgleich wissen, was man tut. Grundsätzlich bei Tageslicht und Mischlicht mit Tageslichteinfall (blau) kein Problem. Bei Kunstlicht (Mischlicht) wird von mir manuell abgeglichen (und bleibt so). Bei Tageslicht würde ich höchstens im Innenraum bei kleinem Tageslichtfenster und Gold gelber Glühlampenbeleuchtung aus Stimmungsgrūnden eine Entscheidung mit manuellem WB treffen.
Bezüglich Detaildarstellung ausserhalb von dunklen Garagen. Ab 150 Lux Helligkeit kann man "echt" FullHD aufgelöste Bilddetails erwarten.
Fast alle meine veröffentlichten Video-Standbilder entsprechen in Gamma und Farbsättigung dem normalen Videoumfang. Bei der SD909 satt und der X909 mehr neutral weiss).
Und real im FlatTV darstellbar in den Spitzen ist noch Zeichnung, wie auch in dunkel schwarzen Kirchenszenen noch Zeichnung ist.

Mit 8 Bit muss man in jedem Fall korrekt belichten ;-)
Bei einem Consumercamcorder kann ich auch ohne NLE Korrektur ein gutes Ergebnis erwarten.
(Bei 10 Bit und mehr muss man auch noch das Rauschen berücksichtigen, was ein 8 Bit Consumercamcorder in jedem Fall ganz gut in der Bildverarbeitung erledigt.)
***** OT Ende *******

Klar kann man im NLE "normieren", man verändert so oder so Bilddetails und Farbstufungen (und verliert schlimmstenfalls 2/3 der Farbnuancen beim einlesen in einen professionellen MPEG2 Codec ;-)
- Weil man Werte komprimiert um Videonormgerecht zu sein (inkl. Gamma der Darstellungskette)
- Oder extreme Werte geclippt werden.
Dessweiteren sind aus AVCHD diverse Bildsignalisierungen nach einem neu Encoding nicht mehr vorhanden und somit für immer verloren.

Für mich privat erhalte ich "geschnitten" die umfängliche "native" Kamera-Bildqualität (für den Consumer nicht relevant oder nicht "einfach" nachvollziehbar. D.h. Die komplette Darstellungskette muss einstellbar, oder die Signalisierung stimmen. Moderne FlatTV können RGB 0..255, aber nicht unbedingt Zeichnung in superweiss darstellen.)

Es ist für mich klar, dass eine 3-Chip RGB Sensorquelle eine "saubere" Basis bildet als ein single Sensor mit Bayer-Filter.
Insofern das auch die Zusammensetzung der RGB Sensorempfindlichkeit verändert werden könnte (einzel Sensor Clipping).
Hier haben wir ja nur ein NLE Clipping- und nicht ein 8 bit Kameraproblem, da der Sensor in der hochwertigen Consumer Cam weit mehr kann als in "echt" heute dargestellt wird.
Denn die dargestellte absolute Helligkeit ist nicht abhängig von 8, 10 oder mehr Bit (Banding).

Ich sage es immer gerne 3x 8 Bit ist True Color mit über 16 Mio Farben.
8 Bit in 16-235 ist nicht schlecht, ist aber bereits eine Qualitätsreduktion im Helligkeitsumfang und den Farbstufungen.

In einem hochwertigen gerenderten Workflow (upgrade) erhalte ich bestenfalls normgerecht die Qualität, bis zum erneuten Rendern für das Zielsystem. Was im Normallfall immer noch gut aussieht (in jedem Fall ist jede Normwandlung verlustbehaftet).

Darum ist ein Consumercamcorder auch wenn er die detaillierteren besseren Bilder machen würde, keine Broadcastcamera mit entsprechendem professionellen Codec (Eingangsqualität nach Norm).

Gruss Tiefflieger



Antwort von gast5:

Hallo olja, ich hab hier noch ne PDF von Tektronix zu dem Thema...

http://www1.tek.com/Measurement/program ... e_easy.pdf

Ich sehe die Ergebnisse in beiden Programmen als korrekt angezeigt über die spezifizierten Bereiche..

Ich kann morgen noch in Piranha nachsehen wie es sich dort verhält.. Liegt auf der ubuntu Umgebung..



Antwort von domain:

Sind unterscheidbare und quantitativ aufsummierte Farbnuancen (Tieffliegerspezialität) eigentlich identisch mit dem Tonwertumfang?
Wie ermittelt man die Menge der unterscheidbaren Farbnuancen eigentlich?
Hat ein flacheres Profil, also ohne starke Kontraste weniger oder gleich viel Farbnuancen zu bieten als ein kontrastreicheres?



Antwort von TheBubble:

Unabhängig von dem eigentlichen Thema des Threads habe ich mir heute Abend mal mit dem hier schon öfter beschriebenen "Türkis anstelle von Hellblau"-Problem befasst, dass scheinbar nicht für jeden ein Problem ist.

Eine erste Analyse deutet darauf hin, dass tatsächlich Y Werte in den reservierten Bereichen (0-15, 236-255) aus dem H.264 Decoder herauskommen. Mangels Tageslicht, dafür aber auch noch mit Bewölkung, kann ich derzeit leider keine geeigneten Testaufnahmen für weitere Versuche erzeugen. Auch konnte ich noch nicht völlig ausschließen, dass der von mir verwendete H.264 Decoder keine Werte spreizt (ich gehe allerdings nach Betrachten der Y-Werte eher nicht davon aus).

Bei Interesse kann ich das Thema noch einmal aufgreifen.



Antwort von Tiefflieger:

Sind unterscheidbare und quantitativ aufsummierte Farbnuancen (Tieffliegerspezialität) eigentlich identisch mit dem Tonwertumfang?
Wie ermittelt man die Menge der unterscheidbaren Farbnuancen eigentlich?
Hat ein flacheres Profil, also ohne starke Kontraste weniger oder gleich viel Farbnuancen zu bieten als ein kontrastreicheres? Mit Farbnuancen meine ich unique colors
Ab einem Standbild (Frame) mit wenig motion blur zählt man bsp. weise die unique colors (Bildbearbeitungsprogramm) und kann auch mit Histogrammen die Tonwertverteilung sehen (inkl. Tonwertspreizung bei Nachbearbeitung).

Mit Upscaling oder Bildbearbeitung kann ich mehr Farbnuancen erhalten (Interpolation).
Bei einem natūrlichen Bild ab Kamera haben 3-4 Pixel die gleiche Farbnuance.
In Stadtszenen können es 10 - 20 Pixel sein die die gleiche Farbnuance haben.

Im schlimmsten Fall ist der Farbumfang in 3x16 Bit enthalten, was zu 8 Bit limitiert zu weniger Farbnuancen fūhrt.
So erkläre ich mir den teilweise eingeschränkten Filmcontent den ich habe, da ist in 4K Bildauflösung und 14 Bit weniger im Farbumfang enthalten als bei meiner 3-Chip in 8 Bit (Farbnuancen als 48 bit TIFF absolut gezählt)

Grundsätzlich empfinde ich auch ein Bild mit wenigen Farbtonwerten gut, da es den Lichteinfall und Farbverlauf zeigt.
Aber es ist eine eingeschränkte Farbpalette, da "echte" gemessene Farbnuancen aus der Kamera fehlen (in 3-Chip aus deckungsgleichen RGB Werten und nicht interpoliert).
So sind normalerweise auch die farbigen Bilddetails höher aufgelöst als bei einer single Chip mit Interpolation.

Sony z.B. erkennt bei neueren Consumer Cams (Smartphones) inhaltliche Bildteile (Objekte) und versucht die farbliche Detailauflösung zu erhöhen (gilt auch für Upscaling von Blurays zu ~4K, wo sogar zusätzliche echte 4K Pattern/Objekte im Datenstrom sind.)

Gruss Tiefflieger



Antwort von domain:

Mir kommt vor, dass die Anzahl der Unique Colors an sich kein Qualitätskriterium für ein gutes Bild sein kann, eher sollte das ganze Bild eine einzigartige Farbe aufweisen.
Wie behandelt Magix eigentlich die Werte über 100% ?
Ich meine, selbst beim Smartrendern gibt es nach einem Schnitt in der Timeline ja zumindest eine GOP, die neu gerechnet werden muss. Sieht man in den ersten Bildern dieser GOP einen Sprung z.B. in den Lichtern?



Antwort von olja:

Motion, danke. Seite 7 dürfte für den BellNuit der Fall sein.
Der liegt bei mir in FCPX innerhalb von BroadcastSave (700mV, 8Bit), bei DaVinci außerhalb (Spitze bei 1023,10 bit). Und wenn 2 Programme auf den ersten Blick unterschiedliche Interpretationen zulassen, wird es schwierig.

Davon abgesehen, das ich mich gar nicht so weit reinhängen wollte, aber für mich jetzt mitgenommen habe (was WoWu eigentlich auch meinte), dieser ganze Quatsch in diesen Bereichen rumzufummeln bringt nichts. Es wär besser, wenn solche Werte erst gar nicht zustande kommen. Was nützt mir ein Camcorder, dessen Bild ich nur am TV nativ sehe, aber die Bearbeitung im NLE komische Ergebnisse bringt, weil er halt über der Norm liegt. Und das machen die. Zumal das Rückholen der "scheinbar" ausgebrannten Lichter auch nicht die Qualität mehr bringt (Pixelwolken, Banding)

Weder die GH2 läßt sich in die Wertebereiche bewegen um solchen Mist zu erzeugen, die GoPro staucht das im Protune sogar zusammen (Log) und man erhält wesentlich bessere Ergebnisse für die Post, als irgendwie in Lichtern rumzufummeln.

Wenn die Pana da generell irgendwie ein Problem hat, was nutzt das ? Ich muß das Material vernünfig in allen NLE's bearbeiten können und das muß auch vernünftig gemappt werden. Wenn man sich im BroadcastSave-Bereich bewegt, sollte es bei allen keine Probleme geben.

Von daher macht es schon Sinn (im Moment jedenfalls noch), einfach sich auch nur darin zu bewegen.

Der kleine Exkurs war ja nicht schlecht ;-)



Antwort von dienstag_01:

Motion, danke. Seite 7 dürfte für den BellNuit der Fall sein. Olja, Olja. Was hat denn nun YPbPr mit deinem Chart zu tun?!
Du hast immer noch nicht verstranden, dass die Problematik an einer ganz anderen Stelle liegt: Wie und wo wird ein standardkonformes Signal, dass mit 16-235 in der Rec 709 beschrieben ist, für ein Ausgabegerät, wie es der Computermonitor ist, auf dessen Farbraum, der nun mal 0-255 hat, umgemapped, konvertiert oder was weiss ich. Genau deshalb nämlich zeigt dir FCP 100% für Weiss an, was laut Spezifikation 235 ist, auf deinem Vorschaubild aber 255.

Und Davinci zeigt wiederum die 255 (in 10bit 1023) an.

Darüber wunderst du dich nun die ganze Zeit.

Motiongroup brauchst du dazu nicht zu befragen, weil ihm das alles LOGISCH ist. Ist es auch, aber als Erklärung taugt logisch ja nun wenig (und das von ihm verlinkte Dokumente auch nicht) bis gar nichts.

Man muss das auch alles nicht verstehen, arbeiten kann man (weitestgehend) auch ohne dieses Wissen. Wenn man aber nach mehrtägigem Exkurs zu einem Fazit wie diesem von dir oben kommt, kann man nur sagen: FALSCH.



Antwort von olja:

Nö, da ging es um RGB Mapping, wie bei dem Chart.

Aber egal, ich wunder mich nun gar nicht mehr und du hast recht, man kann auch ohne damit arbeiten.
Mein Fazit bleibt aber trotzdem, ich arbeite dann lieber im "BraodcastSave". Denn wegen dem "außerhalb" ist eigentlich dieser ganze Zauber hier erst enstanden. Und auch bei Adobe



Antwort von dienstag_01:

Nö, da ging es um RGB Mapping, wie bei dem Chart. RGB to YPbPr Format Conversion. Steht da als Überschrift. Oder meintest du was anderes?



Antwort von olja:

Nö, da ging es um RGB Mapping, wie bei dem Chart. RGB to YPbPr Format Conversion. Steht da als Überschrift. Oder meintest du was anderes? Ich will nicht Krümelkacken.. YPbPr ist die ursprüngliche analoge Version des digitalen YCbCr, mit dem u. a. die auf der DVD gespeicherten sowie die bei DVB per Sat, Kabel oder Antenne übertragenen Videodaten farbkodiert sind. War einfach nur meine generelle Beobachtung eines mappings aus RGB, vor allem, wie sich das auf die Anzeige auswirkt. Mehr eigentlich nicht. Aber auch wurscht.

Ich filter eben den Thread jetzt ganz grob und sage mir, bleib einfach in dem Raum und schneide endlich deine Filme weiter. Ich hab wirklich 2 Tage mit Testgeflime verplemert ;-). Ich wolle nur die Anzeige einigermaßen deuten können. Es muß und darf nicht meine Baustelle sein. Vermutungen helfen auch nicht weiter (könnte gemappt sein ,evtl. )

Genau so wenig, wie ein Koch Thermodynamik beherschen muß, wenn er nur den Kühlschrank bedient.

Evtl. steig ich wieder ein, wenn Cameras über Turbinen betrieben werden und man über h-ds diagramme diskutiert. Oder Statik, technische Mechnik, oder Hydraulik.

Jeder Vollhorst sollte eigentlich wissen, welche Kräfte beim Stativ wirken und die auch kennen. Ansonsten wird er nie einen Film machen können. Logisch, oder ?

Aber manche klemmen einfach nur ihre Kamera rauf und machen ihren Film. Einfach unglaublich...



Antwort von dienstag_01:

@Olja
Du sagst es, die analoge Version. Aber bei dir sind scheinbar analoge Signale auf der digitalen DVD gespeihert ;)

Oder anderes ausgedrückt, man muss schon auch im richtigen Wikipedia-Eintrag stöbern (oder ihn richtig interpretieren).

Aber egal.

Wenn du mich fragst, Thermodynamik ist wirklich gerade voll Out, für dich wäre eher die Heisenbergsche Unschärferelation was ;)



Antwort von olja:

@Olja
Du sagst es, die analoge Version. Aber bei dir sind scheinbar analoge Signale auf der digitalen DVD gespeihert ;)

Oder anderes ausgedrückt, man muss schon auch im richtigen Wikipedia-Eintrag stöbern (oder ihn richtig interpretieren).

Aber egal.

Wenn du mich fragst, Thermodynamik ist wirklich gerade voll Out, für dich wäre eher die Heisenbergsche Unschärferelation was ;) Es ging ja nur um den Effekt eines Mappings.

Out ist Vieles. Wird man aber bitter bereuen, wenn es nur noch IMM oder BWL geben wird ;-). Aber die Leute sind wenigstens weg von der Straße bzw. Harz4 und machen keinen Blödsinn. Über den Nutzen braucht man nicht zu diskutieren, dann müßten wir alle Bauern sein.



Antwort von dienstag_01:

Es ging ja nur um den Effekt eines Mappings. Aber doch nicht in ein analoges Signal!



Antwort von olja:

Stimmt, war völliger Blödsinn.



Antwort von dienstag_01:

Darum gehts doch hier (auch), dass man was dazu lernt.
Wie weit, bleibt jedem selbst überlassen.

Und einen optimalen Workflow zwischen NLE und Resolve oder After Effects hinzubekommen, ist doch auch was wert.



Antwort von Tiefflieger:

Mir kommt vor, dass die Anzahl der Unique Colors an sich kein Qualitätskriterium für ein gutes Bild sein kann, eher sollte das ganze Bild eine einzigartige Farbe aufweisen.
Wie behandelt Magix eigentlich die Werte über 100% ?
Ich meine, selbst beim Smartrendern gibt es nach einem Schnitt in der Timeline ja zumindest eine GOP, die neu gerechnet werden muss. Sieht man in den ersten Bildern dieser GOP einen Sprung z.B. in den Lichtern? Mit unique colors habe ich einfach die unveränderten "originalen" Farbwerte ab Kamera (Farbwerte kann man auch relativ zueinander betrachten).
Klar kann man ein grünes Baumblatt in 5 grüntönen (Farbnuancen) darstellen ;-)

Magix brauche ich nur zum Smart Rednern mit hartem Schnitt, aber mehrheitlich das Tool AVCMerge.
http://videotreffpunkt.com/thread.php?t ... r=0&page=1

Der Vorteil von Magix wäre noch, dass nur veränderte Bildfolgen neu gerendert werden (Inhaltlich verändert mit z.B. einem Titeltext oder an hübschen Szenübergängen). Der Rest ist Smart und somit unverändert.
Um 100% Farbpegel muss ich mich nicht kümmern, da ich auch in der Darstellungskette möglichst native bleibe.
Keine Motion Kompensation (Doppelkonturen), keine automatische Kontrast- oder Farbanpassung sowie Nachchschärfung während der Wiedergabe.

Grundsätzlich kann man GOP oder Framegenau schneiden, technisch bleiben wie bei Aufnahme die Zwischenbildinformationen erhalten. Es gibt keine "unruhigen" Szenenübergänge, wie "steppende Fussgänger" bei hartem Schnitt (Für Farben mit WB ist man bei Aufnahme selbst verantwortlich).
Bei Magix hatte ich schon einmal einen "grauen" Szenenübergang nach einer 20 Minütigen Szene, dafür keinen Ton Gap (AVCMerge macht keinerlei Effekte, es ist auch kein Szenen kürzen möglich).

Gruss Tiefflieger



Antwort von Tiefflieger:

@All
Auf Broadcast save brauche ich für mich keine Rücksicht nehmen.
Ich nehme einfach für mich privat die volle Qualität aus der Kamera mit (und nicht die Politur ;-).
Und Pixelwolken sind das bei der X909 nicht, es ist ggf. eine helle Tönung die sonst im Bild ausgebrannt fehlt (z.B. auf weissem Flugzeug im gleissenden Sonnenlicht sind kleinste Türbeschriftungen in rot erkennbar).
Schlimmstenfalls werden mit herunterziehen lineare (Schwarzwerte, Stauchung) oder nichtlineare (Gamma) Effekte zum tragen kommen.

In ein paar Jahren ist das kein Thema mehr, da werden haufenweise neue "Directors Cut" in vollem 10 oder 12 Bit erscheinen.
D.h. alle Bildanpassungen entsprechen dem heutigen Stand und Qualitätsanspruch mit der Option Retro.
(Bis dahin habe ich meine 20m VR Brillen Leinwand oder Kontaktlinse)



Antwort von WoWu:

Unabhängig von dem eigentlichen Thema des Threads habe ich mir heute Abend mal mit dem hier schon öfter beschriebenen "Türkis anstelle von Hellblau"-Problem befasst, dass scheinbar nicht für jeden ein Problem ist.

Eine erste Analyse deutet darauf hin, dass tatsächlich Y Werte in den reservierten Bereichen (0-15, 236-255) aus dem H.264 Decoder herauskommen. Mangels Tageslicht, dafür aber auch noch mit Bewölkung, kann ich derzeit leider keine geeigneten Testaufnahmen für weitere Versuche erzeugen. Auch konnte ich noch nicht völlig ausschließen, dass der von mir verwendete H.264 Decoder keine Werte spreizt (ich gehe allerdings nach Betrachten der Y-Werte eher nicht davon aus).

Bei Interesse kann ich das Thema noch einmal aufgreifen.

Also, ich hab mir jetzt auch mal das Premiere Pro runter geladen und es scheint in der Tat so zu sein, dass das 7,5 IRE Offset (in den USA nach wie vor noch gültig) nicht abgestreift wird.

Das erledigt man manuell mit einem Proc-Amp, der in der deutschen Version von PP: StabVerst. heisst und in den "YUV/32" Effekten liegt.
Also: YUV oder 32 => Videoeffekte => Anpassen => StabVerst => Helligkeit => -7,5
und alles ist in Butter ... kein Stauchen, kein Clipper, kein Banding und kein Dither.

(Sowas machen andere Programme eben automatisch).

Mein Vorschlag ist nach wie vor, in Y'CbCr (bei Adobe: YUV) zu arbeiten, dann klappt das auch mit den guten Qualitäten, weil es keine Wandelverluste mehr gibt.



Antwort von dienstag_01:

Also, ich hab mir jetzt auch mal das Premiere Pro runter geladen und es scheint in der Tat so zu sein, dass das 7,5 IRE Offset (in den USA nach wie vor noch gültig) nicht abgestreift wird. 1. Was hat das 7,5 IRE Offset in einem PAL-Land zu suchen?
2. Warum benutzt du nicht einfach den Schalter in der YC-Waveform für dieses Offset?

Du kannst dir nochmal die Vergleichsbilder von Avid und Premiere hier im Thread auf Seite 1 und 2 anschauen, du wirst keinen Unterschied feststellen.



Antwort von WoWu:

1)
Es ist immer eine Frage, für welchen Markt das Produkt gemacht ist. Immerhin ist das Offset noch ATC Vorschrift in Nordamerika.
Einige Kameras machen das daher nur bei 30/60; 29,97/59,94 und 23,976 und nicht bei 25/50/24.
Aber die Kamera entspricht damit dem ATSC Standard.
Vielleicht kann man den Standard in der Kamera ja sogar anwählen und er steht nur Default-mässig falsch.
Warum benutzt du nicht einfach den Schalter in der YC-Waveform für dieses Offset? 2)
Ich tippe mal drauf, dass so ein "Schalter" im WFM nur was an der Anzeige macht, aber nichts am Signal.
Es geht aber nicht darum, die Anzeige umzuschalten sondern das Signal korrekt zu mappen, ohne die ganzen internen Verhältnisse im Signal zueinander zu verkurbeln.

Ich hab das Programm auch nur angeworfen und ein paar Minuten damit probiert, um zu sehen, was der Unterschied ist und warum alle das "buggige"- Color Clip Curves brauchen.
Vielleicht gibt's ja so eine, für das Offset vorgesehene Methode.



Antwort von dienstag_01:

@WoWu
Ich wollte eigentlich nur zum Ausdruck bringen, dass das 7,5 IRE Setup nur im NTSC Raum eine Rolle spielt, und da auch nur in einem Teil.

Eventuelle Fehler im Mapping von PAL-Material - die es meiner Meinzúng nach gar nicht gibt - wird man damit nicht erklären können.

Übrigens, meine Vergleichsbilder auf den Seiten 1 und 2 sind NTSC. Da sieht man auch, dass sie korrekt erkannt werden (YC-Waveform aus Avid und Premiere).



Antwort von WoWu:

Aber die Vergleichsbilder waren ja nicht von der Panasonic 9xx ?

Denn hier ging es ja auch darum, dass die Kamera den 'Türkisstich' haben sollte, der dann nur mit dem "Color Curves-Tool" zu beseitigen wäre, das ja nun clipped und daher als verbugged gilt.
Mal ganz abgesehen davon, dass das ohnehin das ungeeignete Tool gewesen wäre.
Was das Off-set betrifft, so ist es leider noch sehr "lebendig" und im ATSC Raum nicht nur -nach wie vor- Teil der Spezifikation, sondern auch tatsächlich 'gelebte Gegenwart".

Ergo: Beseitigt man mit dem Proc-Amp das Offset, hat man ein ganz normales Signal (ohne Türkisstich).



Antwort von dienstag_01:

Ach so, du bist in der türkisen Bilderwelt mit Milliarden JUNIC KOLORS von Tiefflieger. Vergebene Liebesmüh, der WILL das so. Ausserdem war doch weiter vorn schon ein Weg beschrieben, der Fehler der clippenden Curves tritt doch nur bei ein oder zwei Tools der CC auf.
Aber auch hier sollte ganz allgemein gelten: Tieffliegers bewunderte Cam sollte kein dem NTSC-Format geschuldetes Offset liefern.

Edit: Mit Tieffliegers Cam meine ich einfach nur die PAL-Version.



Antwort von WoWu:

Nun ja, das kann gut sein, dass er eine "PAL" Version hat, die das richtig mapped.
Ansonsten bin ich ziemlich weit bei ihm, dass Bilder nicht erst durch möglichst kräftiges Nachbearbeiten "gut" werden.
Die besten Bilder kommen nach wie vor aus der Kamera und mit solche Tools, wie "Color Curves" werden sie sowieso nicht unbedingt besser.
Jedenfalls hat das Tool, indem es Clipper, keinen Bug.
(War das nicht irgendwie der Kern des Threads) ?



Antwort von dienstag_01:

Jedenfalls hat das Tool, indem es Clipper, keinen Bug.
(War das nicht irgendwie der Kern des Threads) ? Ob Bug oder nicht Bug, darüber kann man wirklich geteilter Meinung sein. Für alle, die in ihren bisherigen Projekten mit den Curves gearbeitet haben, und zwar nach der Methode, die Werte oben etwas abzusenken, für die könnte es die VOLL-Katastrophe sein. Wenn sie viel abgesenkt haben, fehlt ihnen jetzt das richtige Weiss im Bild.
Muss man aber nicht unbedingt Bug nennen ... ;)



Antwort von WoWu:

fehlt ihnen jetzt das richtige Weiss im Bild. Das meinst Du jetzt aber nicht im Ernst.



Antwort von dienstag_01:

Das meinst Du jetzt aber nicht im Ernst. Ei freilich.
Schau dir mal den Link im Eröffnungspost an.



Antwort von k_munic:

Der Kleinbetrieb und Farb-Amateur Technicolor hat übrigens aufgegeben, das alles zu verstehen:
http://blog.technicolorcinestyle.com/bl ... d-programs

... wird als Ursache hierfür gesehen:
http://www.fcp.co/final-cut-pro/news/11 ... sist-looks



Antwort von dienstag_01:

Deswegen sage ich ja: Avid ;)
Aber nicht für den Hausgebrauch ;)



Antwort von WoWu:

Das meinst Du jetzt aber nicht im Ernst. Ei freilich.
Schau dir mal den Link im Eröffnungspost an. Den hab ich sehr genau angeschaut, aber dann hast Du über die ganze Strecke nicht wirklich verstanden, was ich gemeint habe.

Nun ja, egal.



Antwort von dienstag_01:

aber dann hast Du über die ganze Strecke nicht wirklich verstanden, was ich gemeint habe. Das will ich nicht ausschließen ;)
Aber was Premiere da macht, versteh ich schon.



Antwort von olja:

Der Kleinbetrieb und Farb-Amateur Technicolor hat übrigens aufgegeben, das alles zu verstehen:
http://blog.technicolorcinestyle.com/bl ... d-programs

... wird als Ursache hierfür gesehen:
http://www.fcp.co/final-cut-pro/news/11 ... sist-looks Sehr interessant der erste. Doch wohl nicht alles so korrekt....;-)



Antwort von olja:

These graphs show the signal is being legalized for the scopes. A legal signal was introduced for the TV mastering industry and it shrinks the full dynamic range of a 10-bit signal from 0 – 1023 into 64 – 940. There is absolutely no reason for these tools to falsely display the pixel values as legal.

Even the actual screen representation of the pixels is correct in full range.

The result: Only Technicolor Color Assist shows a correct waveform monitor, all the other applications are showing it wrong. Ach wat...;-)



Antwort von WoWu:

Deswegen stellen sie es jetzt auch ein ;-)



Antwort von olja:

Deswegen stellen sie es jetzt auch ein ;-) Und deswegen kann man solche Ausflüge in diese Regionen auch lassen, wenn das auch noch fehlinterpretiert wird. Hast recht, wenn man sich innerhalb 16-235, bzw. 64-940 ooc bewegt , braucht man sich nicht allzuviel Gedanken machen. Die GH2 z.B zeigt das Clipping ab 100% an, mehr macht die dann auch nicht.
Ansonsten hat man dann einen Wust von Camcordern, die drüber hinausgehen und Tools, die das noch nicht mal handeln können. Ist doch Irrsinn.



Antwort von WoWu:

Vor allen Dingen fragt man sich, ob es wirklich nötig ist, denn 10Bit kostet heute nicht mehr "die Welt" und wem 220 Steps zuwenig sind, soll doch 10Bit machen.
Funktioniert genauso gut wie 8 Bit und ist auch standardisiert.
Wer braucht also solche Exoten.
Betrachtet man auch mal die Imlementierungsstatistik von xvYCC, dann könnte man auch vermuten, dass das Thema bald "Geschichte" ist.



Antwort von Reiner M:

Ergo: Beseitigt man mit dem Proc-Amp das Offset, hat man ein ganz normales Signal (ohne Türkisstich). Das ist nur die halbe Wahrheit, Wolfgang. Und das auch nur bezogen aufs Ergebnis. Natürlich klappt das - gegebenfalls. Grundsätzlich ist das kein "Entfernen" eines Offsets.

Premiere Pro kennt mehrere Effekte, die sich direkt auf die Luma-Kurve auswirken. Alle sind irgendwie geeignet, die Aufgabe anzugehen.

ProcAmp (StabVerst) hat den Nachteil, dass es den gesamten Bereich fasst und schiebt. Es entfernt nichts. Folglich schiebt es unten raus, wenn die Helligkeit abgesenkt wird. Das geht gut, wenn die tiefsten Tiefen eben weit genug oberhalb Unterkante sind. Ansonsten clippts dann unten. Kein gutes Ergebnis.
Du gehst davon aus, dass die Aufnahmen grundsätzlich zu hoch stehen. Das ist falsch.

Am NTSC 7,5-IRE-Offset kann es nicht liegen. Erstens PAL, zweitens müssten die Aufnahmen tatsächlich zu hoch stehen, drittens darf eine NSTC-IRE-Korrektur nur unten wirken, nicht oben. Eine solche Korrektur würde also 100IRE bei 100IRE lassen müssen und von unten stauchen von 0 auf 7,5IRE hoch, bzw. beim Entfernen des Offsets von 7.5 auf 0 runter. Oben tut sich nichts, weil eben 100IRE auch für NTSC die Grenze ist. Wenn das Material nicht so aufgenommen ist, erzeugt man damit ebenfalls Banding oder Abrisse in der Wave.
Premiere Pro erlaubt eine automatisierte Offset-Korrektur auch nur für Material, das eindeutig NSTC-basiert ist. PAL müsste man händisch korrigieren, was aber Unfug ist.

Der Effekt Luminanzkurve hat den Vorteil, dass er nichts übers Knie bricht. Ich kann individuell an der Kurve arbeiten, oben nur soviel runter, wie nötig, unten optimieren und z. B. mit S-Kurven die Bildwirkung anpassen. Sehr individuell, abhängig vom Bild.

Anzumerken bleibt noch bezüglich der X909, dass nur ein sehr kleiner Teil der Aufnahmen den "Türkisstich" zeigt. Nämlich dann, wenn extrem helle Bereiche im Bild(hintergrund) gleichzeitig mit Blautönen vorkommen (typisch Himmel) und für das Hauptmotiv korrekte Belichtung bei extremen Helligkeitsunterschieden erzwungen wird. Die meisten Aufnahmen - auch mit Himmelsbildern - sind frei von Türkis. Dies nur, damit kein falscher Eindruck ensteht.

Beste Grüße,
Reiner



Antwort von Reiner M:

Wenn man sich im BroadcastSave-Bereich bewegt, sollte es bei allen keine Probleme geben.

Von daher macht es schon Sinn (im Moment jedenfalls noch), einfach sich auch nur darin zu bewegen. Wunsch und Wirklichkeit.
Die Wirklichkeit wird durch die verfügbaren Cams und NLEs bestimmt.
Davon handelt dieser Thread.

Du hast ja Recht: man muss nichts tun. Die Korrektur ist nicht zwingend nötig.

Ich produziere (wie viele andere auch) nicht für Analogbetrieb, nicht für NTSC, nicht für Broadcast, sondern für PCs, Webbrowser, Mobile, Messen, Ausstellungen, Präsentationen. In jedem Fall wird die Aufnahme resp. das fertige Video über übliche und gewünschte Post-Prozesse hinaus an das Zielmedium anzupassen sein. Die Luma-Korrektur ist da das geringste Übel. ;)
Das Ergebnis wird für diese Medien optimal sein, und man kann es trotzdem auf einem TV ansehen, wenn gewünscht. Ist doch was.

Beste Grüße,
Reiner



Antwort von WoWu:

Grundsätzlich ist das kein "Entfernen" eines Offsets. Natürlich ist es das .... was denn sonst?
ProcAmp (StabVerst) hat den Nachteil, dass es den gesamten Bereich fasst und schiebt. Das ist kein Nachteil, sondern ein Vorteil, weil die Verhältnisse innerhalb des Signals erhalten bleiben.
Du gehst davon aus, dass die Aufnahmen grundsätzlich zu hoch stehen. Das ist falsch. Bei allen Deinen Beispielen war das immer so. Bisher hat noch niemand von einem "geclippten" Schwarz gesprochen und sich niemand darüber beklagt, dass zuviel Zeichnung im Weiss war. Am NTSC 7,5-IRE-Offset kann es nicht liegen. Ach nee. Erstens PAL, zweitens müssten die Aufnahmen tatsächlich zu hoch stehen, drittens darf eine NSTC-IRE-Korrektur nur unten wirken, nicht oben. All Deine Aufnahmen waren IMMER zu hoch, und ein Offset wirkt sich NIE auf "nur unten" aus, dann wäre es kein Offset und man würde das Signal stauchen, bzw. bei der Beseitigung strecken.
Eine solche Korrektur würde also 100IRE bei 100IRE lassen müssen und von unten stauchen von 0 auf 7,5IRE hoch, bzw. beim Entfernen des Offsets von 7.5 auf 0 runter. Unfug. Erkundige Dich mal, wie ein 7,5 IRE Signal aussieht.
Der Effekt Luminanzkurve hat den Vorteil, dass er nichts übers Knie bricht. Ich kann individuell an der Kurve arbeiten, oben nur soviel runter, wie nötig, unten optimieren und z. B. mit S-Kurven die Bildwirkung anpassen. Sehr individuell, abhängig vom Bild. Machs doch damit und verkurbel das Signal soviel Du willst.
Ich hab schon mal gesagt, es ist nichts gegen Dein Workaround einzuwenden, wenn Du damit zufrieden bist.
Ich erinnere mich noch an ein Mail, da hast Du gesagt, PP hat gar keinen ProcAmp. War auch quatsch, wie sich jetzt herausstellt.

Also, mach's wie Du willst, ich habe hier nur eine andere Methode aufgezeigt, die zu einem einwandfreien Bild aus dem "Türkisstich" heraus führt und kein verkurbeltes Signal, mit all seinen Artefakten enthält.



Antwort von Reiner M:

All Deine Aufnahmen waren IMMER zu hoch, ... Vertraue mir. Ich HABE die Cam. ;)
Aber das gilt ja auch für andere Cams und andere NLEs, wie dieser Thread ganz klar aufgezeigt hat.

Das Signal sitzt korrekt auf. Wir reden hier über oben, weil es unten kein Problem gibt.
Deine Idee in allen Ehren, aber sie führt nur dann zum Erfolg, wenn das Motiv, das Signal des Motivs, es anbietet. Das muss man einfach wissen und das lässt sich sehr leicht AUSTESTEN.
Es ist nicht die generelle Lösung. Nur eine für einen Spezialfall. Dann aber möglicherweise die Beste (obwohl sich das mit der Luminanzkurve dann genauso lösen lässt). Warum auch nicht?

Schau Dir noch mal in Ruhe die Bilder in diesem Thread an. Wenn eine generelle Verschiebung von +7.5 IRE vorläge, und nur deshalb etwas oben über "100" hinausragt, dann dürfte kein einziges Bild unterhalb 7.5 was zeigen, oder doch? Bilder ansehen, bitte!

..., und ein Offset wirkt sich NIE auf "nur unten" aus, dann wäre es kein Offset und man würde das Signal stauchen, bzw. bei der Beseitigung strecken. Also läuft ein Bild ohne Offset von 0-100 IRE mit Offset von 7.5-107.5 IRE? Oder wie?

Nun könnte man natürlich annehmen, dass zwar ein korrektes 700mV PAL Signal erkannt, aber falsch ausgerichtet wird.
Dem widerspricht eindeutig die unwiderlegbare Tatsache, dass die Signale ab 0mV (300mV in Premiere Pro) beginnen: Sie sind absolut korrekt ausgerichtet.

Egal. Jedenfalls schiebst Du das Signal auf -7.5 IRE und damit aus dem Bild, wenn Du die Helligkeit mit ProcAmp wie beschrieben um 7.5 IRE absenkst. Ist doch logisch, oder nicht?
Du darfst das ja gerne so machen, ich würde das niemanden ohne vorherige Analyse des Clips raten.


Beste Grüße,
Reiner



Antwort von WoWu:

Ja, ja,
alles klar...



Antwort von domain:

Ein allgemeines Offset nach unten kann ich mir schwer vorstellen, da saufen einem ja die Schatten teilweise ganz schön ab. In dieser Waveform sind sie ja bereits auf Null, wie man im linken Bild sieht.
Im rechten Bild habe ich nur die Lichter im Monitor auf 100% heruntergeholt und nachdem die primäre Farbkorrektur ebenfalls eingeblendet ist, sieht man auch, was passiert ist, nämlich ausschließlich eine -21 Korrektur in den Lichtern (rechtes Bild).
Also, man braucht keine Luminanzkurven etc., sondern auf Verdacht hin nur mal probeweise die Lichter in der simplen primären Dreiwegekorrektur vermindern. Dann sieht man sofort ob dort noch was vorhanden ist, oder nicht und die Lichter nur Grau werden.
Und WoWu lass uns doch kurbeln, jede Farkorrektur und erst recht jedes Colograding ist doch nichts anderes als KURBELEI :-)

zum Bild http://img4.fotos-hochladen.net/uploads/primkorr2j59quznegk.jpg



Antwort von olja:

Wunsch und Wirklichkeit.
Die Wirklichkeit wird durch die verfügbaren Cams und NLEs bestimmt.
Davon handelt dieser Thread.
Verfügbare NLE's ? Eben.

Genau DAS, was mich hier 2 Tage beschäftigt hat, steht in dem Techicolor-Blog. There is absolutely no reason for these tools to falsely display the pixel values as legal. Wenn man noch nichtmal ein Werkzeug hat, welches verlässliche Werte anzeigt, worüber will man dann eigentlich noch reden ? Auch Premiere zeigt Mist, genau so wie FCPX und FCP.


Dazu noch eine Camera, die irgendwie in dem Bereich aufzeichnet , das ganze aber nur schwer kontrollierbar ist. Es besteht nur die Chance, die scheinbar ausgefressenen Lichter "sichtbarer" zu machen. Ich würde das aber gerne schon vor der Aufnahme wissen und nicht versuchen, ob da noch was in der Wundertüte ist. Das betrifft nunmal vorwiegend die Höhen, den Tiefen verzeiche ich schonmal das Absaufen.

Besser ist doch, wenn die Cam sich nur im definierten Broadcast-Save Bereich bewegt und das Clipping auch optisch signalisiert. Damit hat man dann keinen Blues und weiß, was rauskommt ;-)
Und genau das macht die GH2 so (sogar als Fotoknipse)
Von dem "Supercamcorder" erwarte ich das eh und nicht ständig fürchterlich ausgefressene Stellen in diversen Testbildern.



Antwort von Jott:

Am Rande, ohne den Schlagabtausch stören zu wollen:

Das angeschnittene Bild von der Dampflok ist gnadenlos überbelichtet. Wie viele eurer Probleme würden sich durch korrektes manuelles Belichten z.B. mittels Zebra einfach in Luft auflösen? Ist nicht primär die hilflos ratende Belichtungsautomatik (wie wohl auch in diesem Beispiel, wo die dunkle Dampflok die Automatik komplett aus dem Tritt bringt) das, was euch den berühmten Türkishimmel beschert?



Antwort von Tiefflieger:

Wer meint bei Aufnahme korrigieren zu müssen kann die manuellen Offsets der Halbautomatik von elCutty aus dem Videotreffpunkt Forum verwenden (als generelle Einstellung).

Bei der X909 (Offset im manuellen Mode, Halbautomatik)
Menü Bildeinstellung,
Belichtung -1
Farbe 0
Schärfe +1
WB -1 (gegen rot)



Antwort von Reiner M:

Genau DAS, was mich hier 2 Tage beschäftigt hat, steht in dem Techicolor-Blog. There is absolutely no reason for these tools to falsely display the pixel values as legal. Wenn man noch nichtmal ein Werkzeug hat, welches verlässliche Werte anzeigt, worüber will man dann eigentlich noch reden ? Auch Premiere zeigt Mist, genau so wie FCPX und FCP. So, wie es aussieht, ist der gezeigte Graph aus Premiere Pro die RGB-Parade.
1) Da darf es keine Werte unterhalb 0 und oberhalb 100 geben, denn es sind Prozent. Alles andere wären ja RGB-Werte kleiner 0 und größer 255 - was ganz einfach nicht geht. Die Ausgabe ist korrekt. Hier sind keine IRE zu sehen.
2) Auch die y-Achse stimmt im Premiere-Pro-Graph vollkommen: Die Parade zeigt von links nach rechts wie zu erwarten jeweils die Rot/Grün/Blau-Werte, und zwar folgerichtig als Punkte, die in Summe über die drei Farbbalken die korrespondierenden Grauwerte des abgestuften Graukeils der Quelle ergeben. Da ist nichts falsch.

Ich denke, Premiere Pro baut da KEINEN Mist. ;)
Besser ist doch, wenn die Cam sich nur im definierten Broadcast-Save Bereich bewegt und das Clipping auch optisch signalisiert. Damit hat man dann keinen Blues und weiß, was rauskommt ;-)
Und genau das macht die GH2 so (sogar als Fotoknipse)
Von dem "Supercamcorder" erwarte ich das eh und nicht ständig fürchterlich ausgefressene Stellen in diversen Testbildern. Korrekt. Auch bei den Clips aus meiner Canon DSLR brauchts keinerlei Eingriffe, weil das Signal genau zwischen 0 und 100IRE liegt. Ist eben so.

Fakt ist aber, dass eine Vielzahl Cams in Userhand anders aufzeichnen.

Beste Grüße,
Reiner



Antwort von Tiefflieger:

Schon kleine Veränderungen im Bildauschnitt, lässt die Automatik anders belichten (als Initalwerte vor Aufnahme, oder transient während).
Dann werden noch (Schutz-)Filter draufgeschraubt.......
Dann wird noch im NLE, Player und am Fernseher "geschraubt".

Wie soll da jemals etwas stimmen? (Wie bei Aufnahme gedacht)



Antwort von Reiner M:

Ist nicht primär die hilflos ratende Belichtungsautomatik (wie wohl auch in diesem Beispiel, wo die dunkle Dampflok die Automatik komplett aus dem Tritt bringt) das, was euch den berühmten Türkishimmel beschert? Korrekt! ;)
Zumindest in den meisten Fällen. Manuell bekommt man das durchaus auch hin ...

Aber es nützt ja nichts, wenn das Material so auf dem Tisch liegt? Dann ist es doch gut, einen Lösungsansatz zu kennen. Muss man nicht nutzen. Für Türkis, aber auch für ausgebrannt erscheindende Stellen allgemein. Türkis ist ja nur ein Seiteneffekt, doch leider ein sehr störender, wohingegen sich wohl viele mit flachen Lichtern längst abgefunden haben. Schade eigentlich.

Beste Grüße,
Reiner



Antwort von domain:

Am Rande, ohne den Schlagabtausch stören zu wollen:
Das angeschnittene Bild von der Dampflok ist gnadenlos überbelichtet. Stimmt, habe auch länger nach so einem Schrott suchen müssen (GZ HD40). Wie überlichtet es ist, sieht man schon daran, dass die Lichter oben am Plafond ohne Fransen nur so andonnern. In solchen Fällen ist auch nichts mehr zu retten.
Kommt bei meiner XF100 aber nicht mehr vor.
Gerade getestet: wenn das 100% Zebra verschwindet, befinden sich die Lichter im Waveformmonitor genau auf oder knapp unter der 100%-Linie.
Außerdem verwende ich ein flacheres als das Standprofil und belichte leicht unter, was aber eigentlich eine normale Belichtung ist, denn fast alle heutigen Kameras belichten über.
So also komme ich nie in die Verlegenheit, von oben etwas herunterklauben zu müssen.



Antwort von Reiner M:

Dann wird noch im NLE, Player und am Fernseher "geschraubt".

Wie soll da jemals etwas stimmen? (Wie bei Aufnahme gedacht) Gar nicht.

Nimm mal eine beliebige Kauf-DVD und stapf damit durch die Wohnzimmer an die PCs und TVs Deiner Nachbarn. Du wirst vermutlich sehr unterschiedliche "Sehgewohnheiten" entdecken.

Ist nicht zum guten Schluss das Ganze auch eine Frage des persönlichen Geschmacks (welchen Kriterien er auch immer folgen mag)? Sowohl bei den Autoren wie auch bei den Zuschauern? Coloristen vedienen damit ihr Brot, Tools fürs Graden erfreuen sich großer Beliebtheit, Fragen nach speziellen "Looks" tauchen immer wieder auf, usw.

Das ist auch gut so. Die Cam liefert einen Werkstoff, Rohmaterial, nicht das Ergebnis der Arbeit.
Ich weiß, Du denkst anders. :)

Beste Grüße,
Reiner



Antwort von olja:


Ich denke, Premiere Pro baut da KEINEN Mist. ;)
Lies doch bitte nochmal den Blog
http://blog.technicolorcinestyle.com/bl ... d-programs

Die richtige Anzeige für den Chart sieht so aus.





Und außerdem achte mal auf die Darstellung der "Signal Range" aus dem Testchart.

Ich sag ja...Verwirrung komplett ;-)



Antwort von dienstag_01:

Olja, was hast du in diesem Thread hier (u.a.) gelernt?
Grafiken werden beim Import in ein NLE in die Video-Range 16-235 (Rec709) gemapped.
Technicolor macht das nun irgendwie anders und dann stellen sie alle anderen als Falschdarsteller hin.
Gewagt.
Ist das eine Grafik? Ist das ein im Programm generirter Frame? Was wissen wir darüber? Nichts.
Ich habe leider kein solches Bild/keine solche Grafik, in Avid könnte ich das einfach überprüfen.
Ich würde mich da jetzt aber nicht verrückt machen.



Antwort von srone:

das, was mir auffällt ist, daß ausser fcx und eben dem referenztool kein anderes nle einen negativen wertebereich für schwarz zulässt, so dass hier fcx, eigentlich den grössten fehler verursacht, da hier zum skalieren der werte noch ein offset dazu kommt. die frage ist jedoch, wie interpretiert fcx (und auch die anderen nles) nun dieses signal beim rausrendern in eine fertige datei?

eine beweisführung nur über unterschiedlich skalierende messsysteme, halte ich für bedenklich und würde anraten das finale ergebnis(die gerenderte datei), mit den messwerten gegenzukoppeln, um auszuschliessen, dass es sich lediglich um einen temporären interpretationsoffset der beteiligten nles handelt.

lg

srone



Antwort von dienstag_01:

einen temporären interpretationsoffset der beteiligten DIT jefällt mir ;)



Antwort von srone:

einen temporären interpretationsoffset der beteiligten DIT jefällt mir ;) wo ich mir doch so viel mühe gab, dem thema gerecht zu werden ;-)

lg

srone



Antwort von olja:

Jepp deshalb hab ich ja den Belle Nuit ausgerendert und wieder in DaVinci eingelesen. Und das Ergebnis war korrekt (0-255), obwohl FCPX nur bis 700mV angezeigt hat.

Negative Wertebereiche ? Natürlich. Kurz vorher bei Technicolor zu sehen und Davinci bringt das auch.

Aber egal. Nicht verrückt machen.

Für mich ist das jetzt ein Schätzeisen, was sich verändert seh ich eh, ausgebrannt sowieso. Nur mit irgendwelchen Werten sollte man nicht kreuz und quer über sämtliche NLE's diskutieren.



Antwort von WoWu:

@Olja

Wenn Dir die Kamera nur 220 Werte liefert und Du die in 254 Werte einliest, werden 34 Werte mit Dither aufgefüllt.
Du gewinnst nicht einen einzigen zusätzlichen Wert und Dein hellstes Weiss ist sowieso lediglich der Maximalwert des Sensors. (in beiden Fällen).



Antwort von dienstag_01:

Nur mit irgendwelchen Werten sollte man nicht kreuz und quer über sämtliche NLE's diskutieren. Genauso isses.
Aber bissel Durchblick bei einem Workflow über mehrere Applications schadet auch nicht.



Antwort von olja:

@Olja

Wenn Dir die Kamera nur 220 Werte liefert und Du die in 254 Werte einliest, werden 34 Werte mit Dither aufgefüllt.
Du gewinnst nicht einen einzigen zusätzlichen Wert und Dein hellstes Weiss ist sowieso lediglich der Maximalwert des Sensors. (in beiden Fällen). Wowu, ich rede ja gar nicht von der Camera, sondern nur von unterschiedlichen Interpretationen der NLS's. Wenn A sagt, es ist Broadcastsave und B es liegt außerhalb, bei dem exakt gleichen Testchart, dann grübel ich halt.

Ich hab ja eh kein Problem, weil ich mich gar nicht in diesen Bereichen tummel. Andere schon ;-)
Und wenn sie dann noch ein Programm benutzen, welches das wieder anders als der Vorgänger behandelt (Threadtitel) dann eben noch mehr ;-).



Antwort von srone:

Jepp deshalb hab ich ja den Belle Nuit ausgerendert und wieder in DaVinci eingelesen. Und das Ergebnis war korrekt (0-255), obwohl FCPX nur bis 700mV angezeigt hat.

Negative Wertebereiche ? Natürlich. Kurz vorher bei Technicolor zu sehen und Davinci bringt das auch.

Aber egal. Nicht verrückt machen.

Für mich ist das jetzt ein Schätzeisen, was sich verändert seh ich eh, ausgebrannt sowieso. Nur mit irgendwelchen Werten sollte man nicht kreuz und quer über sämtliche NLE's diskutieren. darauf wollte ich hinaus, die wertebezeichnungen der y-achsen in den nles ist wohl anders skaliert als bei dem referenztool, jedoch absolut gesehen passt es.

ich sehe es wie du, ein schätzeisen, jedoch für 98% aller fälle ausreichend.

lg

srone



Antwort von dienstag_01:

Wenn A sagt, es ist Broadcastsave und B es liegt außerhalb, bei dem exakt gleichen Testchart, dann grübel ich halt. Woher nimmst du denn das jetzt.

@WoWu
Vielleich kapier ich"s ja nur nicht, aber dein 7.5 IRE Offset hat doch nun hier im PAL Raum wirklich nichts verloren. Wie kommst du nur darauf?



Antwort von olja:

Woher nimmst du denn das jetzt.


Steht alles hier, sogar mit Screenshots. ;-)

700mV max (8bit) in FCPX, über 940 (10Bit) in DaVinci. Gleicher Chart, zur Probe sogar nochmal aus FCPX gerendert (einmal Prores, einmal H264). Du erinnerst dich ?



Antwort von dienstag_01:

So geht das nicht. Du musst in DaVinci mit Color Magament arbeiten. Oder bringst es zurück in dein NLE.



Antwort von olja:

So geht das nicht. Du musst in DaVinci mit Color Magament arbeiten. Oder bringst es zurück un den NLE. Dann nimm doch ein anders Programm, meinetwegen dann eben mit Technicolor.

Oder guck dir das eben in dem Blog an.

Gleiches Ergebnis, gleiche Meinung. Ich wiederhole jetzt zum nochmal den Satz, die Leute sind auch nicht blöd.

. There is absolutely no reason for these tools to falsely display the pixel values as legal.




Antwort von dienstag_01:

Also ich verstehe das nicht: die geben den NLEs ein legal Signal und beschweren sich dann, dass es als legal angezeigt wird.

Alles nicht so einfach.



Antwort von olja:

Also ich verstehe das nicht: die geben den NLEs ein legal Signal und beschweren sich dann, dass es als legal angezeigt wird.

Alles nicht so einfach. Nö, die geben nicht legal. 255 ist nicht "legal".
Und wenn es trotzdem so wär, dann wurde ja wieder ein anderes Programm was anders behaupten.


Davon abgesehn, was sagt eigentlich Avid, wenn Du den BelleNuit da mal einfach so einliest ? Ist zwar ein Mapping, aber es kommt ja trotzdem zu unterschiedlichen Ergebnissen. Auch mit Ex- und wieder Import (als Videofile)

http://www.belle-nuit.com/test-chart


Thread des Monats..Eigentlich gings um den Premiere-Bug ;-) Aber auf meinen Abtrennvorschlag hat kein Admin reagiert ..



Antwort von Auf Achse:

Thread des Monats..Eigentlich gings um den Premiere-Bug ;-) ..
Immerhin mittlerweile 420 Antworten und fast 83 000 (!!!) Klicks!! Soviel zur Statistik und damit ich mich als Mitlesender und Klicks - Produzierender auch mal zu Wort melde.

Danke für eure Nachforschungen und Infos,
Auf Achse



Antwort von dienstag_01:

Im Avid habe ich die Wahl, ob ich die Grafik in die Videorange mappen lasse oder Full Range importiere.

Hier beide Varianten.

Bei der Full Range Variante sollte ich noch hinzufügen, dass die Ausgabe auf meinem Computermonitor 1 zu 1 funktioniert, auf meinem Videomonitor die hohen Weisswerte und tiefen Schwarzwerte abgeschnitten werden. Und so muss es auch sein.



Antwort von olja:

Im Avid habe ich die Wahl, ob ich die Grafik in die Videorange mappen lasse oder Full Range importiere.

Hier beide Varianten.

Bei der Full Range Variante sollte ich noch hinzufügen, dass die Ausgabe auf meinem Computermonitor 1 zu 1 funktioniert, auf meinem Videomonitor die hohen Weisswerte und tiefen Schwarzwerte abgeschnitten werden. Und so muss es auch sein. Perfekt, danke ! Und genau diese Wahl machen halt einige NLE's selbstständig. Woher soll man wissen, was die da gemacht haben ? In FCP gab es glaube ich auch die Möglichkeit (Dialogfeld, White oder Superwhite).

Vor allem ist bei Dir eine Anzeige, die auch keinen Interpretationsspielraum läßt.

Jetzt guck ich mal, wie das mit richtigen Videomaterial oberhalb von 700mV aussieht ;-)



Antwort von WoWu:

auf meinem Videomonitor die hohen Weisswerte und tiefen Schwarzwerte abgeschnitten werden. Und so muss es auch sein. Nein, der Monitor sollte das nicht abschneiden.
Der sollte sRGB darstellen, also seine höchste Leuchtstärke bei 255 erzeugen und den dunkelsten Punkt bei 1.
Nur wenn er über Colormangement verfügt sollte er sich nach den Gamut-Daten im Videostrom richten und im Fall eines standardisierten Signals bei 16 schwarz zeigen und bei 235 maximum Ws.
@WoWu
Vielleich kapier ich"s ja nur nicht, aber dein 7.5 IRE Offset hat doch nun hier im PAL Raum wirklich nichts verloren. Wie kommst du nur darauf? Das ist sehr einfach, weil der Thread eigentlich um das Tool in PP geht, das bei Werten oberhalb des standardisierten Signals abschneidet.
Nach meiner Auffassung korrekt.
Andere meinen, es gäbe auch Kameras, die korrekterweise im nicht zugelassenen Bereichen arbeite.
Meine Antwort: ja, im Fall von xvYCC und im fall von ATSC normierten Camcordern.
Denn der Bereich 16/235 ist völiig losgelöst von NTSC/PAL und gilt für beide Bereiche, es sei denn, ein Hersteller entscheidet sich die Kamera nach den ATSC Bestimmungen für die 23.xx;29.xx und 59.xx Bereiche zu bauen.
Darin ist die Benutzung eines Offsets vorgeschrieben, der solche Illegalitäten legalisiert, aber im NLE die entsprechende Korrektur vorsieht.
Also .... wir reden hier gar nicht über PAL, weil der Bereich 16/232 (SMPTE240M) eine übergreifende Normierung ist.



Antwort von domain:

Wie auch immer, der Waveformmonitor muss den gesamten Bereich von 1-255 anzeigen. Siehe hier den unteren Graukeil, der den gesamten Wertebereich in der Waveform durchläuft. Im Monitorbild aber wird er mir unten und oben bereits beschnitten angezeigt.
Die anderen schrägen Linien zeigen übrigens den Luminanzverlauf der farbigen Keile, die alle mit Null, also mit 16 beginnen.
Die dicke Linie bei 50 stellt die drei farbigen Flächen dar, die offenbar durchgehend dieselben Luminanzwerte aufweisen.

zum Bild http://img4.fotos-hochladen.net/uploads/1255ab8i95mrfu.jpg



Antwort von WoWu:

Das ist absolut korrekt, der Waveform Monitor ist lediglich eine Sichtbarmachung des Werftenbereiches, solang man keine Bewertungsfilter benutzt.
Der häufigste Benuterfehler dabei ist allerdings, dass irgendwelche Skalierungen benutzt werden, die dann falsch gedeutet werden oder sogar in den Anleitungen falsch beschrieben werden oder bei denen der Bezug dem Anwender überhaupt nicht klar ist.
Allerdings ist auch manchmal der Ursprung der Skalierung eine Ursache.
So hat 1 IRE in einer Pal Umgebung den Wert 7 mV und in einer NTSC Umgebung von 7,14 mV.
Waveform ist also nur für den gut, der weiss, was er da eigentlich angezeigt bekommt.



Antwort von domain:

Alles klar, danke für die Erklärung.
Ich hatte weiter oben ja geschrieben, dass das Waveform-Vorschaubild in Liquid nicht mit dem Timeline-Vorschaubild übereinstimmt. Einerseits sieht man in ihm u.a. sofort eine mögliche Verbesserung im Türkishimmel im vorhinein, anderseits ist das Bild flacher in der Darstellung und zeigt keine richtigen Schwärzen, wie z.B. in dem angeschnittenen Lok-Bild, kein Wunder, denn dort erfordert Schwarz nämlich wirklich 1 und nicht 16.
Dachte an einen Bug, aber dem ist offenbar nicht so.



Antwort von gast5:

Das ist absolut korrekt, der Waveform Monitor ist lediglich eine Sichtbarmachung des Werftenbereiches, solang man keine Bewertungsfilter benutzt.
Der häufigste Benuterfehler dabei ist allerdings, dass irgendwelche Skalierungen benutzt werden, die dann falsch gedeutet werden oder sogar in den Anleitungen falsch beschrieben werden oder bei denen der Bezug dem Anwender überhaupt nicht klar ist.
Allerdings ist auch manchmal der Ursprung der Skalierung eine Ursache.
So hat 1 IRE in einer Pal Umgebung den Wert 7 mV und in einer NTSC Umgebung von 7,14 mV.
Waveform ist also nur für den gut, der weiss, was er da eigentlich angezeigt bekommt. Topp die Antwort.. wir erinnern uns noch gut an die DV Zeiten und den guten Canopus DV Codec der auch den vollen Wertebereich von 0-255 genutzt hat und auch an eine falsche zum Update ausgewiesene DirectX8.1x Version bei der die ebenso diese Stauchung aufgetreten ist..



Antwort von olja:

Hier mal so eine Stilblüte
http://www.flickr.com/photos/davedugdale/6326846722/

So wie ich es verstanden habe, geht die Sony in Premiere über 100, die Canon bleibt bei 100.

Danach hat er die selben Files in Vegas eingelesen, da gehen sie beide über 100
(denke auf 109).unteres Bild. Da stellt sich eben dem gemeinen Anwender die Frage, warum ;-)



Antwort von dienstag_01:

auf meinem Videomonitor die hohen Weisswerte und tiefen Schwarzwerte abgeschnitten werden. Und so muss es auch sein. Nein, der Monitor sollte das nicht abschneiden.
Der sollte sRGB darstellen, also seine höchste Leuchtstärke bei 255 erzeugen und den dunkelsten Punkt bei 1.
Nur wenn er über Colormangement verfügt sollte er sich nach den Gamut-Daten im Videostrom richten und im Fall eines standardisierten Signals bei 16 schwarz zeigen und bei 235 maximum Ws. Wenn ich Videomonitor schreibe, meine ich natürlich mit Colormanagment.
(Wie sollte ich mir sonst eine Grafik, wie die von Belle Nuit, lagal mit 16-235 importiert, richtig anzeigen lassen)

Das ist ja der wesentliche Punkt, der hier Verwirrung stiftet, laut Standard ist der Videostrom 16-235, innerhalb des NLE dann aber 0-255 (sonst wäre es nur ein Matschbild - so wie bei Avid, und vielleicht auch wie bei Domain).
Dann spricht einer von Werten oberhalb von 235, der andere meint, bei ihm seien die sowieso immer da und der dritte rettet Werte von oberhalb 255. Usw. usw., da dreht sich alles im Kreis.



Antwort von domain:

(Wie sollte ich mir sonst eine Grafik, wie die von Belle Nuit, legal mit 16-235 importiert, richtig anzeigen lassen) Ja aber gerade dieses in einem vorauseilenden Gehorsam erfolgende „legale" Ummappen von Grafiken und Fotos auf 16-235 ist ja m.E. die reinste Dummheit bzw. zumindest ein Missverständnis.
Wieso sollte Tiefflieger z.B., dessen gesamte Wiedergabekette auf Fullrange eingestellt ist, ein wunderschönes importiertes dynamisches Foto jetzt in seiner gestauchten Form akzeptieren können?
Nun gut, er macht es ohnehin nicht, aber gesetzt den Fall.



Antwort von WoWu:

@Olja So wie ich es verstanden habe, geht die Sony in Premiere über 100, die Canon bleibt bei 100. Wenn Du Dir "100" anschaust, musst Du automatisch auch "1" anschauen, weil Du, wenn Du nur die "100" betrachtest, nicht "die ganze Wahrheit" siehst. Denn erst aus den beiden werten erkennst Du, ob ein Signal ein Offset hat oder eine Stauchung.
(Der Unterschied ist hier offenbar sowieso einigen nicht wirklich klar).
Frage ist also:
Ist der Wertebereich des Videos grösser als 220 und wo liegt er.

Hat er ein Offset, aber 220 Werte, dann entspricht er den Spezifikationen der ATSC und generiert bei einer Wandlung von Digital nach Analog eine Schwarzwertabhebung. Einige NLEs streifen das Offset bereits automatisch ab, andere nicht, dafür ist der Proc-Amp da, weil er das gesamte Signal nur ummapped, aber in sich nicht verändert.

Hat er kein Offset und liegt Schwarz bei 0, und hat das Signal 254 Werte, ist es mit grosser Wahrscheinlichkeit ein xvYCC Signal.

Wer also hergeht, nur die 100 betrachtet und dann den oberen Bereich "justiert", verändert sich die gesamten Verhältnisse innerhalb des Signals. Es hat also dann nicht mehr viel mit dem zu tun, was aus der Kamera gekommen ist.



Antwort von WoWu:

@dienstag laut Standard ist der Videostrom 16-235, innerhalb des NLE dann aber 0-255 Das ist nicht richtig. ProRes z.B. kann gar keine 255 in den 4:2:2 Versionen.
Egal, was für ein Signal es vorher war, es wird gleich in den eingeschränkten Wertebereich gemapped.
Die 255 siehst Du erst auf deinem Monitor wieder, (Colormanagement), der den Wert 235 als "volles Licht" ausgibt, also als analogen Spitzenwert.



Antwort von dienstag_01:

Ja aber gerade dieses in einem vorauseilenden Gehorsam erfolgende „legale" Ummappen von Grafiken und Fotos auf 16-235 ist ja m.E. die reinste Dummheit bzw. zumindest ein Missverständnis. Die Grafik muss ja zu dem (in den) Videodatenstrom passen, sonst kann man ja gleich in einem Grafikprogramm arbeiten ;)
Und der ist nun mal 16-235.



Antwort von WoWu:

Sprechen wir jetzt von einer abgefilmten Grafik (also von einem standard-Videostrom) oder von einem Testbild, das aus dem Computer kommt ?

Denn im standard Videostrom ist FullWell der Wert 235.
Egal, was auf dem Testchart steht.

Kommt das Testchart aber aus dem Computer, kann es 255 sein, wenn das Chart das so angibt.

Dswegen sind Farbbalken aus der Kamera ja so wichtig, weil man sofort einen Hinweis bekommt, was als Signal vorliegt.
Bei Amateuren aber nicht mehr gebräuchlich.



Antwort von dienstag_01:

@WoWu
Die Arbeit mit Avid ist da in gewisser Weise eine Ausnahme: hier wird das Signal nicht auf 0-255 gemapped. Ich arbeite also immer in einer Art 1:1 Ansicht, die Waveforms zeigen mir genau den Wert, den auch die Pipette im Color Correction Mode anzeigt. Dafür ist das Bild auf einem Computerbildschirm nicht zu gebrauchen, das geht dann wirklich nur von 16-235 (auf einem Monitor, der 0 als Schwarz und 255 als Weiss darstellt). Alles flau. Zur Vorschau braucht man dann eben einen externen Videomonitor, der das 16-235 Signal korrekt darstellt (oder den Avid eigenen Fullscreen *Player*, der kann auch auf 0-255 mappen).
Vorteil ist, es gibt keine Verwechslungen, was 235 ist und was 255.
Nachteil ist, dass auch einige Avid User keinen ordentlichen Videoexport hinbekommen, weil sie ihr Bild nach dem Computermonitor farbkorrigieren.



Antwort von olja:

@Wowu, es geht da eigentlich nur um die unterschiedliche Darstellung Premiere/Sony Vegas. Bei Premiere liegt nur eine Cam über 100, bei Vegas alle beide.

Die Skalen sind meiner Meinung nach korrekt (IRE) und enden jeweils bei 109/109 (Vegas) bzw. 100/109 in Premiere. Jeweils mit dem gleichen Footage

Premiere
http://www.flickr.com/photos/davedugdal ... /lightbox/

Vegas
http://www.flickr.com/photos/davedugdal ... /lightbox/

Das sieht doch auf den ersten Blick komisch aus. Darüber hat er sich aus diesem Blog eben gewundert, bzw sucht eine Erklärung. Ist aber auch schon ein Weilchen her.
http://www.flickr.com/photos/davedugdale/6326846722/

Jedenfalls läßt das auf den ersten Blick unterschiedliche Interpretationen zu.



Antwort von WoWu:

@dienstag_01

So ist es auch eigentlich richtig, wie AVID das macht.
Dann hatte ich das (ggf.) anders verstanden -sorry-. Aber jetzt hab' ich das.
So arbeiten wir auch.

@Olja

Bezüglich der Skalierung muss man sich fragen, ob es % sind oder IRE. Denn ein ATSC Signal bezieht sich auf andere Voraussetzungen und ist immer auf 140 IRE bezogen. Die einfache Gleichung 100 IRE entspr. 100% trifft nicht auf ATSC Signale zu.

Berechnung: 140 IRE level in Volt:
140/40 = 1000 mV/s , s = 1000:40/140
s = 285.7 mV gerundet auf 286 mV

Pegelmarken in mV:
peak white = 100 IRE = 714 mV

75% white (mit setup) = 77 IRE = 550 mV
sync amplitude = 40 IRE = 286 mV

setup = 7.5 IRE = 54 mV

Was in einem "PAL" Signal also 700mVeff sind entspricht in einem ATSC Signal 714 mVeff.
Das kommt daher, weil in NTSC sich der Synchronwert von PAL unterscheidet
(286mV zu 300mV)

Ich will mir die Bilder aber nochmal in Ruhe ansehen. Es ist nur sehr schwer, weil nichts über den Ursprung gesagt wird sondern nur die unterschiedlichen NLEs gezeigt werden.



Antwort von domain:

Die Grafik muss ja zu dem (in den) Videodatenstrom passen, sonst kann man ja gleich in einem Grafikprogramm arbeiten ;)
Und der ist nun mal 16-235. Dejure schon, defacto aber nicht. Habe noch keinen Camcorder gehabt, der nicht bis 255 codieren konnte. Warum also sollten gerade Fotos schon beschnitten und amputiert Einzug in das NLE halten?
Außerdem erinnere ich mich noch lebhaft an alte Sony Vegas-Diskussionen, wo die User besonders stolz auf den Einzug von Superweiß waren, das auch rausgerendert werden konnte und zwar für die tollen neuen LCD-Displays und Plasmas, die das bereits alle darstellen konnten. Vegas ging halt mit der Zeit :)



Antwort von WoWu:

@domain

Solange Du in deinem eigenen kleiner Universum für Oma und Opa arbeitest, geht das.
Aber schon, wenn Du irgendwo über eine HDMI Schnittstelle musst, ist das kleine Universum schon implodiert.



Antwort von dienstag_01:

@domain
Ich kenne mich mit diesem erweiterten Farbraum nicht aus. Wenn ein NLE den beherrscht, sollte es auch Grafiken in diesen Farbraum importieren können. Wenn man aber standardkonform in 709 16-235 arbeitet, wärs das Quatsch.



Antwort von domain:

Das ist mir vollkommen klar, aber wenn ich schon andere Cips früher mal vom Plafond auf 235 herunterholen musste, dann ist es doch wohl nur billig, dass man das nach eigenem Ermessen auch bei den Fotos machen kann oder muss. Oder wird angenommen, dass die Mehrzahl der NLE-User dazu unfähig oder unwillig ist?



Antwort von dienstag_01:

Das ist mir vollkommen klar, aber wenn ich schon andere Cips früher mal vom Plafond auf 235 herunterholen musste, dann ist es doch wohl nur billig, dass man das nach eigenem Ermessen auch bei den Fotos machen kann oder muss. Oder wird angenommen, dass die Mehrzahl der NLE-User dazu unfähig oder unwillig ist? Nein.
Ich denke, es wird angenommen, dass diejenigen User, die ihre Grafiken clippen lassen wollen, das auch ganz alleine schaffen ;)



Antwort von WoWu:

Da ist aber bestimmt der Wunsch, Vater des Gedankens.

Die meisten User wissen nicht besonders viel über Videoprocessing. Und noch weniger über Mappings.
Die meisten wissen nur, wie man Content in die Timeline zieht.
Ein paar wissen noch, wie man einen Waveform-Monitor benutzt und, wie man sieht, nur noch ganz wenige, wie man die entsprechenden Tools anwendet und was sie (exakt) bewirken.



Antwort von domain:

Was mich am meisten wundert ist, dass sich bisher noch keine einziger Vegas-Benutzer in dieser Angelegenheit zu Wort gemeldet hat. Gibt ja recht prominente Teilnehmer dahier.
Könnte es sein, dass der ganze damalige Hype um Superweiß heute schamhaft verschwiegen wird?
Außerdem wäre doch mal ein Vergleich zwischen den div. NLEs ganz interessant, um die allgemeinen Verwirrungen und Verirrungen noch deutlicher zu machen.



Antwort von WoWu:

Diese ganze Bezeichnung ist "Kinderkram" und gehört eigentlich in die Play Station Ecke, aus der sie auch ursprünglich mal kam.
Im Videobereich gibt es nämlich nur ein Weiss, das ist FullWell und ob ich den Wert jetzt mit 235 oder 255 übertrage ist scheissegal, solange ich meinem Monitor signalisiere, wo er Weiss zu erwarten hat.
Nur dazu muss man eben seinen Processweg kennen.
Und ich weiss auch nicht, was Du Dir da von einem NLE vergleich versprichst.
Die NLEs werden entweder den Videostandard unterstützen, oder den Grafikstandard. beides ist möglich. Der Anwender muss es nur wissen.
Nur wenn der Anwender dann hergeht und Video- und Grafikstandard wieder mischt, dann kommt der Blödsinn dabei heraus.
Amateurfehler.



Antwort von olja:

Anwender zu verurteilen, wenn die Hersteller den Mist fabrizieren ist aber nun auch nicht gerade schön. Was kann man dafür, wenn der BelleNuit in mV 0-700 angezeigt wird, in Vegas aber FullRange ? (gerade getestet) Es gibt 0 Information von den Programmen darüber, was sie da machen. Warum muß ich das nun wissen.

Aber egeal, wir sind eh alle blöde, Technicolor eingeschlossen.

Den nächsten Koch, der mir ein fantastisches Essen serviert, werd ich erstmal rundmachen. Wahrscheinlich ist der auch zu dämlich mir die Carnot-Prozesse zu erklären, die in seinem Kühlschrank ablaufen. Amateur eben.

Dann kommen noch diese ganzen Vollidioten von Filmern, schnallen ihre Cam auf gegossene Mounts und können noch nichtmal ein Eisen- Kohlenstoff Diagramm interpretieren....Vollpfosten und Amateure eben.

Man, man man.. Die Leute wollen filmen und ein paar Hilfsmittel lesen wollen. Wie ein Thermometer. Aber wenn sich die Skalen zwischen Fahrenheit und Celsius ständig ändern, ist das nicht einfach.

Arrogant und überheblich sollte man sich deshalb nicht darüber äußern. Könnte nach hinten losgehen, definitiv



Antwort von WoWu:

Das ist wohl richtig, aber wenn man schon keine Ahnung hat sollte man ebensowenig die Hersteller auch für seine eigenen Bedienfehler und sein eigenes Unvermögen verantwortlich machen.

Wir können uns natürlich auch lustig ideologisch unterhalten oder uns mit den Fakten auseinandersetzen.



Antwort von olja:

Das ist wohl richtig, aber wenn man schon keine Ahnung hat sollte man ebensowenig die Hersteller auch für seine eigenen Bedienfehler und sein eigenes Unvermögen verantwortlich machen.

Wir können uns natürlich auch lustig ideologisch unterhalten oder uns mit den Fakten auseinandersetzen. Das lustige ist, man kann gar nichts falsch bedienen.

Die Hersteller ? Guck mal in den Thread-Titel. Offensichtlich herrscht ja da noch sogar etwas Erklärungsbedarf. Außerdem hab ich mich nicht drum zu kümmen, ob die Meilen auf dem Tacho nun nautische oder preussische Landmeilen oder gar persische bzw. römische sind.
Ich will nur wissen, auf welcher Basis die Anzeige basiert.

Aber das Rästelraten geht weiter...FCPX 700mV, Vegas FullWell.

Kann jeder nachprüfen und eine Erklärung dafür abgeben. Testversionen sind downloadbar



Antwort von WoWu:

Das sollte Dich aber interessieren, welchen Ursprungs die Meilen sind, weil spätestens bei der nächsten Radarfalle wird sich das rächen.
Aber das Rästelraten geht weiter...FCPX 700mV, Vegas FullWell. Stimmt, weil da wieder die unterschiedlichsten Dinge in einen Topf geworfen worden sind denn FCPx zeigt auch FullWell bei 700mV.



Antwort von olja:

Das sollte Dich aber interessieren, welchen Ursprungs die Meilen sind, weil spätestens bei der nächsten Radarfalle wird sich das rächen.
Aber das Rästelraten geht weiter...FCPX 700mV, Vegas FullWell. Stimmt, weil da wieder die unterschiedlichsten Dinge in einen Topf geworfen worden sind denn FCPx zeigt auch FullWell bei 700mV. Ok. Also FCPX zeigt 700mV als Fullwell ?



Antwort von WoWu:

Mann, das ist doch nun alles mehrmals und ausfführlich beschrieben.
Du must es nur lesen.
Vorne gibt es sogar noch eine Zeichnung dazu.



Antwort von olja:

Mann, das ist doch nun alles mehrmals und ausfführlich beschrieben.
Du must es nur lesen.
Vorne gibt es sogar noch eine Zeichnung dazu. Nö, ich habe mehrmals Dinge gepostet, die du ignoriert hast. Es gibt nur einen Chart, den ich von IRE auf mV umschalten kann. Dieser zeigt 700mV und 100 IRE,
bei dem BelleNuit (auch als Videoimport)

Was ist das jetzt ? Es gibt keine weitere Erklärung dazu.
Nach deiner Meinung ist das jetzt Fullwell ?

Ich will nur wissen, ob ich mich im 16-235 bewege und nicht raten.



Antwort von WoWu:

Ich sag's gern nochmal:
Eine standardkonforme Kamera überträgt FullWell bei einem ausgeleuchteten Bild immer im Wert 235 oder bei xvYCC bei 255.
Einzige Ausnahme sind Kameras, die der ATSC Spezifikation entsprechen, bei denen die Signallage im Wertebereich um 7,5 IRE versetzt ist. Häufig -oft bei Profikameras- auch nur für die relevanten Bildformate.
Ansonsten gibt es im Signalfluss 3 Bits, die den Farbraum signalisieren.
Ob das nun alle NLEs nutzen oder ob sie nicht standardkonform arbeiten, müsstest Du mit den Kenntnissen (und vielleicht ein paar Verifizierungen) selbst herausbekommen können.

Wenn Du jetzt Interpretationen von irgendwelchen Bildchen brauchst, musst Du die schon selbst machen, weil man dazu einige weitere Angaben braucht, sonst ist das ein "Fischen im Trüben" und genau aus dem Grund ist in den Blogs auch so ein Durcheinander entstanden.

Ach, übrigens noch einen Hinweis auf die Blogs .... da würde ich immer sehr genau schauen, wo sie entstehen, denn die Amis zählen in ihrer kleinen Welt bis 140 IRE, daraus resultieren dann Werte, wo wir uns an den Kopf fassen.



Antwort von Reiner M:

Eine standardkonforme Kamera überträgt FullWell bei einem ausgeleuchteten Bild immer im Wert 235 oder bei xvYCC bei 255. Die Frage ist aber, ob die Kameras "standardkonform" in diesem Sinne überhaupt aufzeichnen.
Die Sensoren sind schon lange in der Lage, einen deutlich größeren Dynamikumfang aufzuzeichnen, als REC.709 zwischen Reference Black und Reference White zulässt.
Die Aufnahmen der Pana sind übrings REC.709 kodiert.

REC.709 hat sich aus seinen Broadcast-Vorläufern wie SMTPE240M entwicklet und aus dieser Zeit den Weißpunkt auf einen bestimmten Signalwert fixiert, damit die Broadcast-Linie unverändert bleibt. Die 700mV sind nun mal REC.709. Das hat mit dem Sensor heute nur noch bedingt was zu tun. Das Weiß wird auf dem TV weiß sein, der Headroom kann für Broadcast ausgeblendet werden. Das ist der Sinn.
Die Cams liefern jedoch mehr, nutzen den Sensor und nutzen den Spielraum, den REC.709 bietet. Sie arbeiten in diesem Sinne durchaus standardkonform, jedoch nicht broadcast-like, um einen größeren Dynamikumfang zu erreichen - den übrigens der Kunde wünscht und nicht von Ungefähr kommt.

Beste Grüße,
Reiner



Antwort von WoWu:

Die Sensoren sind schon lange in der Lage, einen deutlich größeren Dynamikumfang aufzuzeichnen, als REC.709 zulässt. Hallooooo: wir reden hier über 8 Bit (ausserdem deckt 709 noch 10 Bit ab) also komm doch jetzt nicht mit so einem "Ding".
Das hat mit dem Sensor heute nur noch bedingt was zu tun Na und ob das was damit zu tun hat, weil jeder Sensor hat an irgend einem Punkt FullWell und eben dieser wert, egal, ob der nun bei 2000 Photonen oder bei 60.000 Photonen entstanden ist, wird in den obersten Wert eingesetzt, egal, ob du nun 8 oder 10 oder 12 oder was auch immer überträgst.
Schau Dir mal das Thema Quantisierung näher an. Dann weisst Du, wie es funktioniert.

Die Cams liefern jedoch mehr, nutzen den Sensor und nutzen den Spielraum, den REC.709 bietet. Sie arbeiten in diesem Sinne durchaus standardkonform, jedoch nicht broadcast-like, Ja, aber dann sprichst Du von einer andern Kamera, bei der Du deinen eigenen Standard gern machen würdest.... oder einer, die entsprechend verkurbelt ist. Vielleicht haben die Chinesen ja auch einen eigenen Standart?
Und mit Broadcast hat die 240 überhaupt nichts zu tun, denn die SMPTE ist keine Broadcastervereinigung sondern ein Zusammenschluss der Geräteindustrie.
Und Sony war bei dem Standard federführend.
Orientier Dich mal richtig.

um einen größeren Dynamikumfang zu erreichen - den übrigens der Kunde wünscht und nicht von Ungefähr kommt. Komisch, dass dann xvYCC seit Jahren stetig zurück geht, wenns doch so "riesig" nachgefragt wird.

Aber mal 'ne Gegenfrage: Warum benutzt Du kein xvYCC, wenn Du doch so verpicht bist auf mehr Werte ? Da hast Du dann sogar auch noch mehr Farben ...


Das alles hat aber mit dem hier besprochenen Thema absolut nichts zu tun.
Aber schön, dass wir mal drüber gesprochen haben.



Antwort von TheBubble:

Die Sensoren sind schon lange in der Lage, einen deutlich größeren Dynamikumfang aufzuzeichnen, als REC.709 zwischen Reference Black und Reference White zulässt. Der Dynamikumfang/Kontrastumfang sagt nur etwas darüber aus, wie groß der Bereich ist, in dem Graustufen vom Sensor aufgelöst werden können. Das ist von BT.709 letztlich unabhängig.

Die "ungenutzten Werte" in der YCbCr-Repräsentation sinnvoll zu nutzen war die Idee von xvYCC, welches dadurch den Farbraum gegenüber sRGB/BT.709 vergrößert hat, d.h. es ist ein zusätzlicher Bereich an Farbtönen darstellbar. Eine gute Idee, bisher leider ohne Unterstützung von TV-Programmen und sonstigen Medien, wodurch die Verbreitung gering ist.



Antwort von Reiner M:

Der Dynamikumfang/Kontrastumfang sagt nur etwas darüber aus, wie groß der Bereich ist, in dem Graustufen vom Sensor aufgelöst werden können. Das ist von BT.709 letztlich unabhängig. Das erste ist klar, das zweite verstehe ich nicht. Durch Wertebereich und Gamma der REC.709-Spezifikation ist doch zum guten Schluss der Dymanikbereich gefixt. Oder nicht? Mal so rum: Wenn 3 Kameras mit völlig unterschiedlichen Sensoren ausgestattet sind, aber alle genau nach REC.709 aufzeichnen, werden sie alle den selben Dynamik-Umfang zeigen.

Aber zum Thema:
Es geht mir um eine praxisrelevante, nützliche Lösung. Rundumschläge, wie: Alle User, Hersteller, Cams und NLEs machen alles falsch, gehören nicht dazu.

Ich habe eine praktikable Lösung geboten. Bisher keine weitere Lösung hier entdeckt. Oder habe ich etwas überlesen? Kommt manchmal vor ...
Der ProcAmp-Ansatz ist ja wirklich gut, ist aber nur in besonderen Fällen nutzbar und zum Schluss auch nur ein Spezialfall des Luminanzkurveneffektes, mit dem das genauso erzielbar ist. Im Prinzip ist das der gleiche Ansatz - nämlich das Zeug von oberhalb der Linie nach unten zu ziehen! -, nur ein anderes Werkzeug. Ist es doch die Lösung?

Die Interpretation des Bereichs oberhalb der "Linie" ist für das Verständnis wichtig.
Die Erklärung der "Überschwinger" ist wohl zutreffend. Eine Offset-Verschiebung liegt jedenfalls nicht vor. Ich störe mich derzeit nur daran, dass der Begriff Überschwinger hier mit einer Geringschätzigkeit einhergeht, fast im Sinne von Datenmüll (ich übertreibe mal etwas). Also zu ignorieren sei.

Denn interessant und wichtig ist, dass diese Überschwinger aus vielen gebräulichen Cams massiv vorliegen (der erlaubte Bereich wird gut belegt) und nachgewiesener Maßen eine so starke bildgebende Wirkung besitzen. Ein Teil der Cams nutzt also solche "Extended Data", ein anderer Teil ganz klar nicht. Diese Überschwinger sind also kein Muss, sondern ein Kann. Technisch sind sie offensichtlich nicht erforderlich. Wenn sie eine Option darstellen, geht damit ein Sinn einher.

Wie nun diese Überschwinger in einer ordentlichen Broadcast-Kette behandelt werden und welchen Sinn sie dort haben, ist für MICH sekundär. Ich arbeite für das Zielmedium PC. Wäre ich im Broadcast, würde ich das Ergebnis selbstverständlich mit den passenden Monitoren kontrollieren und daran ausrichten. Das Ergebnis wäre womöglich: Es ist kein Eingriff nötig.

Meine Ziele sind aber PCs, Web, Software-Player. Die Kontrolle läuft über diese Systeme. Das Ergebnis ist manchmal (längst nicht immer!): Eingriff nötig. Denn ich will ja anschaubare Videos abliefern und nicht erklären müssen, dass das miese Ergebnis nur am PC liegt ...

Die Praxis beweist tagtäglich (nicht nur bei mir), dass Videos, die für PC-Systeme erzeugt werden aus Aufnahmen, die das nachweisen, davon profitieren können (konjunktiv), wenn man diesen Bereich nutzt. Denn unabhängig von den NLEs reagieren die Software-Player auf PCs und im Web identisch.

Frage:
Wenn ich nun in der Produktionskette Cam -> Web-Video stecke: Ist es nun richtig oder falsch, diesen Bereich zu nutzen?

Absolut klar ist, dass ich mir durch eine Stauchung ggf. ein Problem an einer anderen Stelle einhandle. Aber auch das lässt sich nicht universell beantworten. Es ist abhängig vom Bildinhalt. Zudem gilt ganz sicher die Überlegung, welches das kleinere Übel ist. Danach kann man entscheiden.
Die individuelle Betrachtung und Bearbeitung ist absolut wichtig, meine ich. Da mit einer Universal-Einstellung dran zu gehen, die alle Clips gleich behandelt, ist nicht sinnvoll.

Ich bin für jede andere praxistaugliche, nützliche Lösung offen. Für Hinweise, dass ich, meine Cam, mein NLE und deren Hersteller alles falsch machen, nicht.
Sie nützen mir nichts.

Beste Grüße,
Reiner



Antwort von olja:

Wenn ich nun in der Produktionskette Cam -> Web-Video stecke: Ist es nun richtig oder falsch, diesen Bereich zu nutzen? Ich hatte es glaube schon geschrieben. Wie willst du den Bereich sinnvoll kontrollieren ? Um in den Bereichen rumzufilmen, fehlt doch jede optische Kontrolle, wenn keine elektronische da ist. Ich kann geclippte oder nicht geklippte Wolken 255 jedenfalls nicht in der Vorschau von 253 unterscheiden. Du kommst also immer mit ner Wundertüte nach Hause und versuchst, dann noch was zu retten, was auch nur teilweise gelingt. Meiner Meinung nach schon der falsche Ansatz und daher auch nicht sinnvoll (was deine Frage war).

Guck dir doch das ganze ausgebrannte Zeugs von Tiefflieger an. Das sind es keine Wolken, sondern irgendwas im Bild. Pflanzen, Steine..immer irgendwas. Sowas sieht doch scheußlich aus und landet bei mir in der Tonne.

Sieh einfach zu, das du mit der Cam so belichtest, das du nicht in die Bereiche kommst.

Wie man selbst 8 Bit vernünftig verarbeiten kann, zeigt sogar GoPro mit Protune und LOG. Da wird ein Schuh draus. Allerdings kann man das Material nicht unbearbeitet dann gucken. Aber das geht nichts über 100 oder so, nicht mal annähernd. Das sieht sehr flach aus, bietet aber enorme Reserven. Völlig anders, auch von der Bildwirkung her.

Ansonsten sind die Cams doch eher dafür gemacht, damit Hans Müller seinen Zoobesuch von einer Stunde ungeschnitten per HDMI direkt an der Glotze gucken kann, die dann hoffentlich x.v color versteht. Muß man auch mal so sehen, dafür ist die Cam gemacht und das hat auch seine Berechtigung.

Außerdem gibt es ja bald für alle eine preiswerte Alternative, bei der sich diese ganze "Problematik" (zu der sie gemacht wurde) hoffentlich in Luft auflöst.

Hat eure Pana eigentlich sowas wie Cinestyle, flaches Profil oder irgendwas ?



Antwort von Reiner M:


Sieh einfach zu, das du mit der Cam so belichtest, das du nicht in die Bereiche kommst. Olja, das ist völlig richtig.
Nur: den Tipp muss man dem Kameramann geben. (ich persönlich beherzige das weitgehend, klappt nicht immer. Nicht immer ist Zeit da, die Cam optimal einzustellen, nicht jede Cam bietet dafür übersichtliche, leicht kontrollierbare Parameter.)

Aufnahme und Post sind zwei räumlich und zeitlich getrennte Prozesse, ggf: sogar in der Verantwortung unterschiedlicher Menschen.

Wir sind hier in der Post.

Wenn ich nun in der Post entdecke, dass das Problem vorliegt, habe ich drei Möglichkeiten: Ich ignoriere es, ich gehe es an oder ich werfe den Clip weg.
Ignorieren ist schlecht. Also die Augen davor verschließen.
Ich bin zunächst für angehen. Wegwerfen kann man immer noch, wenn kein zufriedenstellendes Ergebnis erreichbar ist.

Wenn der Tipp "sofort wegwerfen" lautet, dann darf nun gerne jeder mal seine Archive der letzten Jahre durchstöbern, egal ob SD oder HD, und sehen, was da auszudünnen wäre, wenn seine Cams so aufzeichnen. ;)

Beste Grüße,
Reiner



Antwort von domain:

@ Olja
Was Tiefflieger so gezeigt hat, ist eigentlich nur der Landschaftsmodus brauchbar. Der zeichnet relativ weich auf. Aber da muss ein anderer Hund begraben sein, denn sonst würde er ja nur diesen verwenden. Er sprach von Schärfepriorität auf Unendlich. Ich tippe mal eher darauf, dass in diesem Fall überhaupt nur eine Scharfstellung auf Unendlich existiert und Nahaufnahmen gar nicht möglich sind.



Antwort von dienstag_01:

Wenn ich nun in der Produktionskette Cam -> Web-Video stecke: Ist es nun richtig oder falsch, diesen Bereich zu nutzen? Ganz egal ob Broadcast oder nicht: das Video wird nur von 0-100 *sichtbar* sein. Also: Schwarzwert setzten (0%), Weisswert setzen (100%).
Bei extrem überbelichtetem Material (Clipping) ist es mir schon passiert, dass Videos Fehler (farbige Klötzchen) aufwiesen. Aber nicht mit dem h264 Codec.



Antwort von Reiner M:

Ganz egal ob Broadcast oder nicht: das Video wird nur von 0-100 *sichtbar* sein. Also: Schwarzwert setzten (0%), Weisswert setzen (100%). Dass der sichtbare Bereich 0-100 ist, ist klar.
Nur gibt es ja offensichtlich einen Bildunterschied, wenn die Cam direkt am TV wiedergibt. Wurde oben diskutiert. Sie zeigt/nutzt dann offensichtlich die Bereiche, die wir am PC oberhalb 100 sehen.
Sonst hätten wir auf beiden Schirmen die selben ausgebrannten Stellen, das selbe Türkis, usw.

Ein Argument ist ja, es muss nichts getan werden, weils am TV korrekt kommt. - Hilft mir nicht.

Nur wenn Dein Weisswert setzen im Endeffekt das Runterholen der 109%-Bereiche auf 100% impliziert, ist es derzeit eine Lösung.

Beste Grüße,
Reiner



Antwort von olja:

@Domain...kann gut sein. Evtl. so ein Bergsymbol ;-)


@Reiner. Das ist richtig. Im Nachhinein denke ich auch, das ich einige Aufnahmen vom Camcorder hätte retten können.
Mir fallen da auf Anhieb immer wieder (sichtbar) geclippte Steine ein, die ich verworfen habe. Ich hab das neulich aufgrund dieses Threads mal nachgestellt. Nur diesmal so belichtet, wie ich es für richtig halte. Und siehe da, da muß man nichts rumkurbeln.

Also, für das vorhandene Material oder wenn was schiefgegegangen ist es natürlich eine Möglichkeit die man versuchen sollte. Aber ich würde es eben für die Zukunft nicht drauf anlegen, weil das Ergebnis schwer zu kontrollieren ist. Und das war ja wohl deine Frage

Wenn die BMCC Pocket einschlägt, werden die Karten eh neu gemischt. Ich warte nur noch drauf. Der Consumerbereich wird sich dahingehend nicht ändern. Weder 10bit ProRes, LOG noch 4:2:2 oder irgendwas. Eher werden geclippte Wolken oder Steine in voller Pracht und 4k zu bestaunen sein. Dafür mit Katzenfratzenlächelautomatik und was weiß ich noch.. Dazu noch gleich die 4k-Glotze verkauft, perfekt. Die Zoo-Filmchen werden aber weiterhin sch*** und nach Automatikgefilme aussehen. Es wird sich nichts ändern.

Aber das ist auch gut so. Irgendwie muß sich die Mühe und die Arbeit auch in im Bild, Schnitt und Montage ja wiederspiegeln.


Edit: 95395 Klicks, die 100.000 machen wir aber noch voll ;-)



Antwort von Reiner M:

Also, für das vorhandene Material oder wenn was schiefgegegangen ist es natürlich eine Möglichkeit die man versuchen sollte. Aber ich würde es eben für die Zukunft nicht drauf anlegen. Und das war ja wohl diene Frage Wir sind uns einig, Olja. Nur in der Frage nicht ;)
Die Frage hatte ich wohl tatsächlich etwas mißverständlich formuliert, aber ich hoffte, es mit folgenden Beitrag geschärft zu haben.

Die Frage ist: Was mache ich, wenn mir solch Material auf den Tisch kommt (unabhängig davon, woher) und ich nun für die PC-Welt produzieren muss?

Es geht hier ja um das, was in Software-Playern und im NLE zu sehen ist, und wie man darauf reagiert.

Dem vorgelagert ist ganz klar die Frage der korrekten Aufnahme. Jeder Hinweis ist da wichtig, aber keine Lösung für die Arbeit im NLE, wenn denn nötig.

Beste Grüße,
Reiner



Antwort von dienstag_01:

Wir fragen mal die Experten (WoWu).
Avid bietet mir standardmäßig für 50i Material folgende Ranges (Warnings) an:
Composite: -20 bis 110 IRE
Luma: 0 bis 100 IRE
RGB Gamut: 0 bis 255 Bit

Ist das korrekt?

Edit: Nur wenn Dein Weisswert setzen im Endeffekt das Runterholen der 109%-Bereiche auf 100% impliziert, ist es derzeit eine Lösung. Ich sags mal so: alles was du siehst, kannst du machen. Out of Range kommt man ja nur, wenn man wahllos verschiedene Tools anwendet. Also Weiss in den Bereich von 100 *runterholen* ist richtig. Nur nicht mit einem Tool, was dafür das Schwarz unten raus katapultiert.



Antwort von olja:

Bereich von 100 *runterholen* ist richtig. Nur nicht mit einem Tool, was dafür das Schwarz unten raus katapultiert.
@Reiner
Genau nur DAS würde ich auch machen! Man fasst ja auch nur die Höhen an und schiebt nicht komplett.



Antwort von Tiefflieger:

Um mal den realen Belichtungsumfang der X900M zu betrachten.
Effektiv ausgebrannt sind bei meinen Aufnahmen im Extremfall 10 Pixel mit 255/255/255 im vollen 8 bit Belichtungsumfang.

Ausgenommen ich korrigiere bei Aufnahme von Hand um bestimmte Effekte zu erzielen.

Der Thread kommt mir so langsam vor, wie DSLR Video User mit extra flachem Profil aufnehmen um ja keine ausgebrannten Bereiche zur Nachbearbeitung zu haben. (dabei wird nicht der volle Dynamikbereich verwendet).
Fakt ist, ein Bild wirkt auch/wegen Spitzlichtern etc.



Antwort von WoWu:

@ dienstag_01
Avid bietet mir standardmäßig für 50i Material folgende Ranges (Warnings) an:
Composite: -20 bis 110 IRE
Luma: 0 bis 100 IRE
RGB Gamut: 0 bis 255 Bit Ich tippe mal darauf, dass das aus Angeben aus dem "Color safe setting" ist, in dem Du ja Vorgaben für die Anzeige eingibst.
Da kannst Du eigentlich einstellen, was Du willst.
Für Composit müsste da statt -20, -40 stehen ansonsten kannst Du die Limits setzen, wie Du willst, je nachdem, wo Deine Colore safe Warnung ansetzen soll.
Bei Luma kannst Du dann auch die 7,5 setzen, sofern Du für NTSC arbeitest.
Und in welchem Codiermodell Du arbeiten willst bleibt Dir auch überlassen, wenn Du einen Abnehme für AdobeRGB hast ... kein Problem.

Apropos Abnehmer:
Reiner hat oben gefragt, wie man denn für das "WEB" arbeitet .... er soll doch mal ein Video, in dem seine "109%" berücksichtigt sind, bei Vimeo oder YouTube reinstellen .... dann wird er schon sehen, wo seine 9% bleiben.



Antwort von WoWu:

......DSLR Video User mit extra flachem Profil aufnehmen um ja keine ausgebrannten Bereiche zur Nachbearbeitung zu haben. (dabei wird nicht der volle Dynamikbereich verwendet.... Tiefflieger, das ist nicht richtig.
Auch bei flachen Profilen wir der volle Dynamikumfang ausgenutzt, ganz im Gegenteil, er ist geringfügig grösser, weil die Quantisierung in den Bereichen, in denen sich rauschen befindet dadurch verändert wird und in kleineren Schritten das Rauschen abgegrenzt werden kann.
Streng genommen wird der Dynamikbereich dadurch also größer.



Antwort von domain:

Ich sags mal so: alles was du siehst, kannst du machen. Out of Range kommt man ja nur, wenn man wahllos verschiedene Tools anwendet. Also Weiss in den Bereich von 100 *runterholen* ist richtig. Nur nicht mit einem Tool, was dafür das Schwarz unten raus katapultiert. Im Grunde braucht man keine komplexen Instrumente, um die Lichter versuchsweise mal runterzuholen, kein Luminanzkurven, keinen Waveformmonitor, etc.
Man sollte allerdings schon wissen, was bei einer simplen primären Farbkorrektur geschieht.
Im zweiten Bild wurden nur die Lichter auf 100 gezogen. Wie man sieht, wirkt sich diese Veränderung auf alle Bereiche aus, aber zunehmend weniger auf die Schatten und gar nicht auf den Nullpunkt der Schatten.
Umgekehrtes passiert, wenn man nur die Schatten anhebt (drittes Bild). Die korrigierte Luminanzkurve bleibt eine lineare Funktion über alle Bereiche.
Nichtlinear wird die Sache nur, wenn man die Mitteltöne verändert, hier zweites Bild mit Anhebung der Mitteltöne. Wird seit einiger Zeit als Gammakorrektur bezeichnet.

zum Bild http://img4.fotos-hochladen.net/uploads/primrn2gp06a8mf.jpg



Antwort von WoWu:

Ja, domain .... machen kannst Du alles, nur werden dann die darunter liegenden Werte zusammengefasst (gestaucht -die Quantisierungswerte werden kleiner und an ihren "Schwellen" zusammengefasst) und das nennt man dann Banding, im ungünstigsten Fall wird das dann auch sichtbar.

Es geht ja bei einer korrekten Signalbearbeitung darum, solche Effekte zu vermeiden und genau aus dem Grund beseitigt man Offsets dadurch, dass man das gesamte Signal (in sich) unverändert lässt (also die Quantiiserungswerte nicht verändert) , aber innerhalb der Wertebereiche verschiebt.
Es geht ja um eine möglichst "Effektfreie" Signalverarbeitung, nicht daum, an welchen Stellen man alles mögliche einstellen kann.



Antwort von Tiefflieger:

......DSLR Video User mit extra flachem Profil aufnehmen um ja keine ausgebrannten Bereiche zur Nachbearbeitung zu haben. (dabei wird nicht der volle Dynamikbereich verwendet.... Tiefflieger, das ist nicht richtig.
Auch bei flachen Profilen wir der volle Dynamikumfang ausgenutzt, ganz im Gegenteil, er ist geringfügig grösser, weil die Quantisierung in den Bereichen, in denen sich rauschen befindet dadurch verändert wird und in kleineren Schritten das Rauschen abgegrenzt werden kann.
Streng genommen wird der Dynamikbereich dadurch also größer. In 8 bit?

Ein Camcorder hat eine optimierte Video-Bildverarbeitung und mehr Rechenleistung als eine DSLR.
Insofern wird bei Aufnahme der 8 bit Bereich im Camcorder "entrauscht" und mit mehr gezeichneten Details aufgenommen.



Antwort von WoWu:

Die Log Kurve liegt bereits vor der "8 Bit "Transportquantisierung".
Es ist also egal, ob ich das für 8, 10 12 oder mehr Bit aufbereite.
Und mit der Entrauschung in einem Prozessweg hat das auch nur sehr begrenzt zu tun, denn zunächst einmal werden die, vom Sensor erzeugten Rauschanteile gar nicht mehr in den Signalweg eingebracht und genau dort geschieht die Dynamikerweiterung, weil man die relativ grobe Quantisierung im dunklen Bereich durch die Log Kurve verfeinert und die eigentlich vorher "verschwendeten" -nicht Rauschanteile- wieder nutzt.
Das Rauschen, von dem Du sprichst, wird durch Filter im Prozessweg erzeugt, nicht aber durch den Sensor.



Antwort von dienstag_01:

Und in welchem Codiermodell Du arbeiten willst bleibt Dir auch überlassen, wenn Du einen Abnehme für AdobeRGB hast ... kein Problem. Was heisst das? Ich arbeite z.B. für ein digitales Ausspiel auf XDCAM HD.
Also Rec. 709 (hier mal Europa).
Und was beideuten diese Gamut-Werte? So ne Art Sättigung? Bzw. mit welcher Korrektur greife ich diese Werte an?



Antwort von WoWu:

Aber das haben wir doch nun über den ganzen Thread besprochen.
Der Gamut-Wert sind die 3 Bit, die in den Gamet-Indicator eingefügt werden und da soll in Deinem Fall 16-235 drin stehen (bei 8 Bit), es soll also 709 signalisiert werden ansonsten kommt da, (bei 1-255) xvYCC raus oder eben AdobeRGB

Aber ich hab das so verstanden, dass diese Einstellung ohnehin nur für die Begrenzungswarnung zu machen ist und keine Projekteinstellung ist.



Antwort von dienstag_01:

Aber ich hab das so verstanden, dass diese Einstellung ohnehin nur für die Begrenzungswarnung zu machen ist und keine Projekteinstellung ist. Ja, Warnungen. Aber im Zweifel halte ich mich dran ;)

Ich schau mal, was der Avid mir bei 60i liefert.

EDIT: Luma L mit 7,5
Aber Gamut auch mit 0-255. Was ist denn das?

EDIT 2: Ah, sind die Werte, die man in der RGB Parade sieht.



Antwort von Reiner M:

Bereich von 100 *runterholen* ist richtig. Nur nicht mit einem Tool, was dafür das Schwarz unten raus katapultiert. Danke, so sehe ich es auch.
@Reiner
Genau nur DAS würde ich auch machen! Man fasst ja auch nur die Höhen an und schiebt nicht komplett. Ja. Danke. ;)
Im Grunde braucht man keine komplexen Instrumente, um die Lichter versuchsweise mal runterzuholen, kein Luminanzkurven, keinen Waveformmonitor, etc.
Man sollte allerdings schon wissen, was bei einer simplen primären Farbkorrektur geschieht. @domain
Das was Du da beschreibst, ist genau die Handhabung und Vorgehensweise mit dem Effekt "Luminanzkurve" in Premiere Pro. Nur, dass damit nicht gleichzeitig Farben manipuliert werden können.
Von daher gehst Du identisch vor. Nur mit einem anderen Tool.

Nur noch als Hinweis: die Absenkung der Lichter so vorzunehmen, dass die Luminanzkurve weiterhin linear verläuft ist gut. Es kann aber aus verschiedenen Gründen sinnvoll sein, gleichzeitig am anderen Ende nachzubessern. Hängt vom Bild ab. Insofern ist Linear kein zwingendes Ergebnis der Tat, aber im ersten Teilschritt das richtige.

Beste Grüße,
Reiner



Antwort von domain:

Ich habe ja schon mal geschrieben, dass sämtliche Luminanz- und Chrominanzveränderungen in allen drei Helligkeitsbereichen in Liquid über die beiden Maustasten bei gleichzeitigem Ziehen der Maus über das Bild der Waveformanzeige möglich sind.
Das Problem ist nur, dass das Waveformmonitorbild nicht mit dem Vorschaubild aus der Timeline übereinstimmt. Dort wird es plötzlich viel knackiger dargestellt. Das Anzeigeproblem ist wohl so eine Mischung aus dem original-Avid und den speziellen Liquid-Eigenschaften.
Interessiert aber ohnehin keinen mehr, da Liquid schon halb mumifiziert ist :-)



Antwort von dienstag_01:

Dort wird es plötzlich viel knackiger dargestellt. Wo ist dort?
Ich sag mal so, das *knackigere* Bild sollte in irgendweiner Form als Vorschaubild während der Farbkorrektur ausgegeben werden. Möglicherweise auf dem zweiten Monitor.



Antwort von domain:

..das *knackigere* Bild sollte in irgendweiner Form als Vorschaubild während der Farbkorrektur ausgegeben werden. Möglicherweise auf dem zweiten Monitor. Sollte schon, ist aber nicht so und einen zweiten Monitor benutze ich nicht.
Also heißt es gedanklich zu extrapolieren, wie es wohl aussehen wird :-)
Ist mir aber ziemlich wurst, denn ich schiele ohnehin schon längere Zeit auf Edius.
Ein Phänomen aber ist das min. 7 Jahre alte Liquid für mich immer noch: viele Effekte über die GPU schon damals in Echtzeit, weiters permanentes Hintergrundrendern neben der eigentlichen Arbeit in der Timeline und außerdem auch heute noch MXF-fähig bei der Canon XF100 und zwar ganz schön rasant, sowohl beim Import, als auch bei der eigentlichen Verarbeitung mit einem ebenso alten primitiven Dual-Core



Antwort von olja:

Um mal den realen Belichtungsumfang der X900M zu betrachten.
Effektiv ausgebrannt sind bei meinen Aufnahmen im Extremfall 10 Pixel mit 255/255/255 im vollen 8 bit Belichtungsumfang.

Ausgenommen ich korrigiere bei Aufnahme von Hand um bestimmte Effekte zu erzielen.

Der Thread kommt mir so langsam vor, wie DSLR Video User mit extra flachem Profil aufnehmen um ja keine ausgebrannten Bereiche zur Nachbearbeitung zu haben. (dabei wird nicht der volle Dynamikbereich verwendet).
Fakt ist, ein Bild wirkt auch/wegen Spitzlichtern etc. Hast du eigentlich schon mal solches Material in den Fingern gehabt ? Selbst meine GoPro schafft mittlerweile mit 45mbit und LOG aufzuzeichnen. Erstmal ganz weit weg von deinem sichtbaren Pana-Universum. Erstmal
Wahrscheinlich würdest du damit auch gar nichts anfangen können. Guckmal, schrecklich gell ? Überhaupt nicht ausgenutzt, fürchertlich flach alles. Vor allem, gar nicht nachgeschärft. Danach gehts weiter, für die meisten. Nur für dich nicht.



Antwort von TheBubble:

Der Dynamikumfang/Kontrastumfang sagt nur etwas darüber aus, wie groß der Bereich ist, in dem Graustufen vom Sensor aufgelöst werden können. Das ist von BT.709 letztlich unabhängig. Das erste ist klar, das zweite verstehe ich nicht. Durch Wertebereich und Gamma der REC.709-Spezifikation ist doch zum guten Schluss der Dymanikbereich gefixt. Oder nicht? Die Aufnahmen werden, egal auf welchen tatsächlichen Helligkeitsunterschieden sie basieren, in einen immer einheitlichen Wertebereich abgebildet (von z.B. 0 für dunkel bis 1 für maximal hell), der zwischen diesen Extremen eine gewisse Anzahl an Helligkeitsabstufungen erlaubt.

BT.709 beschreibt nun, wie dieser Bereich an Abstufungen codiert wird, quasi das Datenformat.

Daraus lässt sich natürlich nicht mehr ohne weitere Zusatzangaben die tatsächliche Lichtsituation mit den ursprünglichen Helligkeiten rekonstruieren. Dies macht aber nichts, da sowieso kein Display die Helligkeit erreicht, die z.B. Sonneneschein hat. Es reicht den Eindruck derart zu reproduzieren, das die Szene vom Betrachter entsprechend wahrgenommen wird.

Auch haben verschiedene Displays auch sehr unterschiedliche Kontrastwerte, d.h. der Helligkeitsunterschied zwischen Schwarz und Weiß ist unterschiedlich. Mit möglichst großen Kontrasten wird gerne geworben, daher kann man diese Angabe für Displays oft nachlesen.
Mal so rum: Wenn 3 Kameras mit völlig unterschiedlichen Sensoren ausgestattet sind, aber alle genau nach REC.709 aufzeichnen, werden sie alle den selben Dynamik-Umfang zeigen. Das ist ünabhängig. Kamera A kann einen größeren Kontrastumfang als Kamera B haben, wodurch z.B. helle Bereiche von Kamara A gegenüber Kamera B differenziert dargestellt weden können. Das ändert natürlich nichts an der Anzahl verfügbarer Helligkeitsstufen.
Es geht mir um eine praxisrelevante, nützliche Lösung. Rundumschläge, wie: Alle User, Hersteller, Cams und NLEs machen alles falsch, gehören nicht dazu. Es ist leider wirklich so, dass viele Programme vieles "falsch" machen. Zumeist deswegen, weil es performanter ist (vor meinetwegen 10 Jahren war das noch ein viel wichtigeres Kriterium, als heute) und es oft unbemerkt bleibt. Ein gutes Beispiel ist z.B. wie viele Programme z.B. sRGB Bitmaps skalieren. Viele machen es falsch, da sie die Übertragungsfunktion nicht berücksichtigen.



Antwort von domain:

Dies macht aber nichts, da sowieso kein Display die Helligkeit erreicht, die z.B. Sonneneschein hat. Es reicht den Eindruck derart zu reproduzieren, das die Szene vom Betrachter entsprechend wahrgenommen wird.
Sehe ich genau so.
Tatsache ist jedenfalls, dass die allermeisten NL-Editoren sowohl in Rec.709 anzeigen als auch so rausrendern, egal ob eine 709-Option angeklickt wurde oder nicht.
Was ich nicht verstehe: beim Importieren von Fotos oder Grafiken wird (mit Ausnahme von Vegas) automatisch auf 16-235 umgemapped, bei importierten Videofiles aber nicht, warum eigentlich nicht?
Wie auch immer, die Lösung wurde oben schon demonstriert: wenn die Waveform Bereiche über 100 anzeigt, dann ganz einfach die darüberliegenden Lichter auf 100 herunterholen und wenn der NLE keinen Waveformonitor hat, dann mal auf Verdacht hin dieses versuchen, aber nur so viel, als die Lichter nicht grau werden. Das geht ganz simpel mit einer primären (Farb-) Luminanzkorrektur in den Lichtern.
Im Prinzip geschieht dann genau dasselbe, wie beim Ummappen von Fotos. Die Steigung der Luminanzkurve wird insgesamt vermindert, bleibt aber linear, wobei die Schatten sinnvoller Weise nicht angetastet werden (beim Foto ev. auf 16 angehoben), denn ich habe noch keinen Camcorder besessen, der unter 15 codierte und was darunter sein sollte wird ohnehin auf keinem Display mehr deutlich unterscheidbar angezeigt.
Und das soll verkurbeln sein? Bei den Fotos hat sich ja auch keiner aufgeregt.
Es geht also darum, im Lichte der hier mühsam erarbeiteten Erkenntnisse, ausgehend von der hoffentlich nicht mehr allzu oft vorkommenden Grenzüberschreitung:

zum Bild http://www.fotos-hochladen.net/uploads/lumkorr1n2ygjw0m6z.jpg

einen Zustand herzustellen, der über den Superweiß-Privatkosmos hinausgehend standardkonform ist, aber nicht in der Art:



sondern in der Art:





Antwort von dienstag_01:

Was ich nicht verstehe: beim Importieren von Fotos oder Grafiken wird (mit Ausnahme von Vegas) automatisch auf 16-235 umgemapped, bei importierten Videofiles aber nicht, warum eigentlich nicht? Videofiles SIND ja eigentlich schon im richtigen Farbraum.



Antwort von domain:

Ja eigentlich schon, aber uneigentlich haben bei mir noch locker alle Camcorder bis 255 aufgezeichnet. Ausnahme offenbar GH2 etc. und so sollte es ja wohl auch sein.



Antwort von dienstag_01:

Ja eigentlich schon, aber uneigentlich haben bei mir noch locker alle Camcorder bis 255 aufgezeichnet. Ausnahme offenbar GH2 etc. und so sollte es ja wohl auch sein. Nee.



Antwort von Reiner M:

Mal so rum: Wenn 3 Kameras mit völlig unterschiedlichen Sensoren ausgestattet sind, aber alle genau nach REC.709 aufzeichnen, werden sie alle den selben Dynamik-Umfang zeigen. Das ist ünabhängig. Kamera A kann einen größeren Kontrastumfang als Kamera B haben, wodurch z.B. helle Bereiche von Kamara A gegenüber Kamera B differenziert dargestellt weden können. Das ändert natürlich nichts an der Anzahl verfügbarer Helligkeitsstufen. Also haben Cams, die 100% standardkonform nach REC.709 aufzeichnen, alle den selben Dynamik-Umfang. Oder? 5 Stopps?
Aber das ist nicht das Thema.
Es geht mir um eine praxisrelevante, nützliche Lösung. Rundumschläge, wie: Alle User, Hersteller, Cams und NLEs machen alles falsch, gehören nicht dazu. Es ist leider wirklich so, dass viele Programme vieles "falsch" machen. Das ist klar. Doch ist mehr als hinreichend bewiesen, dass es nicht "falsch" sein kann an den vermuteten Stellen im Sinne eines produktbezogenen Bugs:

----------

Da die Software-Player identisch reagieren, also Clips out of the Cam genau so zeigen, kann das "Problem" nicht in den NLEs stecken, schon gar nicht in einem einzelnen. Eine völlig hinreichende Beweisführung, wie ich meine.
In den NLEs sehen wir es nur in einer anderen Darstellungsform, im Waveform-Monitor. Wer da nicht reinguckt und damit nicht arbeitet, bemerkt es nicht einmal, wie wir erkannt haben, und ist zumeist trotzdem rundum zufrieden.

Da die Cams (mindestens eine) das Bild bei direkter Wiedergabe am TV offensichtlich "korrekt" anzeigen, kann das "Problem" nicht in der Aufzeichnung stecken. Ein hinreichender Beweis, wie ich meine.
Ob und wie da womöglich aus Überschwingern was "rekonstruiert" wird (wie Du weiter oben erläutert hattest)? Möglich. Ein anderer Grund? Möglich. Das ist aber auch egal. Es ist so.

Es geht nicht um "mein" NLE und "meine" Cam. Geräte und Systeme sind seit Jahren von unterschiedlichsten Herstellern millionenfach so ausgeliefert worden. Das ist keineswegs ein neues Phänomen, wenn es auch hier so überraschend, quasi wie neu, erkannt wird.

Bleibt also interpretativ(!) nur übrig anzunehmen, dass die Daten oberhalb 100 an PCs nicht (oder anders?), in der Broadcast-Kette vermutlich sehr wohl auf das Bild wirken? Wie auch immer das geht. Das jedenfals zeigen die Ergebnisse auf den Bildschirmen. Um die gehts.
Und für diesen Unterschied gab es bisher keinerlei hinreichende Erklärungen. Man muss es auch nicht erklären. Es genügt, es zu wissen.

Denn auf diese Situationen, auf beide Fälle, sollte sich der Anwender einstellen.

Die Folge aus der Interpretation wäre ja, ich MUSS am PC korrigieren, wenn ich das gleiche Bild auf PC-Playern, im Web und in der Broadcast-Kette sehen möchte.
(Interessant wäre übrigens, die Cam mal direkt an einem Röhren-TV zu sehen, was ich bei mir mangels Hardware nicht mehr nachstellen kann.)

Mal ganz praktisch:
Es wäre fatal, einen Fehler anzunehmen und die Daten oberhalb 100 einfach wegzulöschen, wenn es sie gibt. Absenken ja, aber bitte nicht löschen. Den PC-Usern wäre das zwar egal. Die sehen danach das gleiche Bild wie vorher.
Wohl aber, wenn man das Bild dann rausrendert und wieder direkt ohne PC in der TV-Kette zeigt. Dann wird das Bild dem des PCs entsprechen. Wenn das gewollt ist, ist alles gut.
Wenn da also z. B. "Türkisstich" am PC auftaucht, ist er nun tatsächlich in allen Wiedergabenketten drin, weil gefixt, quasi ins Video eingebrannt.
Beim Rausrendern nehmen viele Codecs den Bereich oberhalb 100 nämlich mit, wenn er noch da ist. Er wird nicht neu aufgebaut (was eigentlich gegen "Überschwinger" spräche?). - Zumindest ist das so zu beobachten. Und von daher sehr praxisrelevant.

Nötig ist also eine Handlungsempfehlung, um einerseits die Software-Player dieser Welt - mindestens aber meine und die meiner Kunden - mit optimal eingestellten Videos zu versorgen und gleichzeitig ein gutes Bild auf dem TV zu ermöglichen, wenn erforderlich. Je nach Aufgabenstellung. Am Besten ein identisches Bild.

Liegt vor. Kann jeder mal ausprobieren, sehen, wie es in seiner Umgebung arbeitet und es ggf. in seinen Workflows nutzen - oder auch nicht.

Beste Grüße,
Reiner



Antwort von dienstag_01:

Reiner, solange du dich im Standard Rec 709 bewegst (was man ja mit Video in HD gemeinhin macht), siehst du immer das gleiche Bild, egal ob am TV, an deinem PC, was weiss ich, wo noch. Egal ob Broadcast oder nicht. Deswegen ist es ja ein Standard. Und der geht von 16-235. Alles was drüber oder drunter ist, ist nicht *sichtbar*, da kannst du auf und nieder springen.



Antwort von Reiner M:

Korrekt, Dienstag. Soviel zur Theorie.
Das Bild muss also auf allen Wiedergabegeräten gleich sein, egal ob direkt am TV angeschlossen, oder über den PC gezeigt.
Ist es aber nicht. Praktisch sehen wir unterschiedliche Ausgaben.

Wir drehen uns im Kreis. ;)

Beste Grüße,
Reiner



Antwort von WoWu:

@domain
Und das soll verkurbeln sein? Auch für Dich noch einmal:

"verkurbeln" ist die individuelle Absenkung /Stauchung der hellen Bildteile und/oder die individuelle Spreizung der dunklen Bildteile. Weil dadurch Dither sowie Banding entsteht.

Eben das Gegenteil von dem, was ich etliche Male als korrekten Weg beschrieben habe und Du es nun wiederholt hast. Die Steigung der Luminanzkurve wird insgesamt vermindert, bleibt aber linear, wobei die Schatten sinnvoller Weise nicht angetastet werden Siehst Du, es geht doch.



Antwort von Reiner M:

Jetzt sind wir wohl uns endlich alle einig. Freut mich!

Denn was domain nicht gemacht hat, ist, Schwarz unten raus zu zu schieben - sehr sinnvoll. Er hat nur die Neigung der linear verlaufenden Lumakurve reduziert. Solange, bis 109% auf 100% liegt, aber 0% bei 0% stehen bleibt. Oder?

Doch leider: Dadurch entsteht Banding. Ob das kritisch ist, hängt vom Bild und dem persönlichen Empfinden ab.

Beste Grüße,
Reiner



Antwort von olja:

Davon abgesehen stimmt die Aussage mit den 5 Blenden nicht..._Nur mal so zwischendurch ;-)

Ich habe in einem Parallelthread hier einen eigentlich schönen Satz vom Skeptiker gelesen und erlaube mir , ihn hier mal zu zitieren
Eines weiss ich jetzt schon: Bei der ersten, sich bietenden, überzeugenden, bezahlbaren Gelegenheit, werde ich diese Hauptstrasse, diesen Wettbewerb des Nonsens, verlassen.

Und die ist bald gegeben. Hoffentlich.



Antwort von dienstag_01:

Praktisch sehen wir unterschiedliche Ausgaben. Praktisch heisst was? Du hast an deinem TV *gekurbelt*?



Antwort von WoWu:

Jetzt sind wir wohl uns endlich alle einig. Freut mich!

Denn was domain nicht gemacht hat, ist, Schwarz unten raus zu zu schieben - sehr sinnvoll. Er hat nur die Neigung der linear verlaufenden Lumakurve reduziert. Solange, bis 109% auf 100% liegt, aber 0% bei 0% stehen bleibt. Oder?

Doch leider: Dadurch entsteht Banding. Ob das kritisch ist, hängt vom Bild und dem persönlichen Empfinden ab.

Beste Grüße,
Reiner Dann zeig mir doch nochmal kurz, wo ich bei DEINEM VIDEOMATERIAL durch die Beseitigung des Offset etwas geclippet habe ?
Und, wie gesagt, das ist Dein Originalmaterial.
Also sag mal, wovon Du sprichst ?



Antwort von Reiner M:

Davon abgesehen stimmt die Aussage mit den 5 Blenden nicht..._Nur mal so zwischendurch ;-) Sondern? Es geht um 100% Standard, ohne "Superwhites" und Gamma-Specials.
Kann sein, dass ich mich im genauen Wert täusche. Fakt ist, auch Sensoren, die mehr können, werden Dank Rec.709 nicht mehr bieten. Sie werden alle "gleichgeschaltet", wie die Anzeigegeräte auch. Theoretisch. Wenn sie praktisch Unterschiede zeigen, weichen sie von 100% Standard ab, wo auch immer. Oder?
Was nicht heißt, dass sie ihm gar nicht folgen: Es passiert innerhalb der zulässigen Grenzen.


Beste Grüße,
Reiner



Antwort von Reiner M:


Dann zeig mir doch nochmal kurz, wo ich bei DEINEM VIDEOMATERIAL durch die Beseitigung des Offset etwas geclippet habe ?
Und, wie gesagt, das ist Dein Originalmaterial.
Also sag mal, wovon Du sprichst ? Wolfgang, es wurde wurde Dir hier in diesem Thread MEHRFACH von verschiedenen Teilnehmern erklärt, dass Du mit Deiner Lösung - ProcAmp -7.5 IRE Helligkeit - Schwarz unten rausschiebst.
Ignorierst Du das alles? Solltest Du nicht. Es ist wichtig.

Dieser Punkt war längst abgehakt!

Die Tatsache, dass Du eine einzelne Landschaftsaufnahme besitzt, in der keine Werte unterhalb 400mV, also schönes, dunkles, durchgezeichnetes Schwarz vorkommen, ist ZUFALL. ;)
Ich habe viele Aufnahmen, die enthalten nur Mid-Tones. Mit denen geht das auch.

Beste Grüße,
Reiner



Antwort von WoWu:

Wolfgang, es wurde wurde Dir hier in diesem Thread MEHRFACH von verschiedenen Teilnehmern erklärt, dass Du mit Deiner Lösung Schwarz unten rausschiebst. Zeig doch mal, wo.
Zitier doch mal.


Thema Blenden:
Auch das ist nicht richtig.
Denn es wird im Standard immer PeakWeiss als oberster Wert übertragen.
Was Du also als "Superweiss" bezeichnest ist immer Signalbestandteil.
Und SMPTE240 sieht bei einem SN von 50db in 220 Quantisierungsschritten 9 Blenden Dynamik vor.
Die Tatsache, dass Du eine einzelne Landschaftsaufnahme besitzt, in der keine Werte unterhalb 400mV, also schönes, dunkles, durchgezeichnetes Schwarz vorkommen, ist ZUFALL. ;)
Ich habe viele Aufnahmen, die enthalten nur Mid-Tones. Mit denen geht das auch. Das Material hast Du mir als "kritisches" Material geschickt.
Und nun sagst Du, nee, nee, das ist ganz tolles Material.
Was soll ich nun von deinen zwei Aussagen glauben ?



Antwort von domain:

Wenn das (irgenwas von weiter oben) stimmt, dann frage ich mich allerdings, was ein Rausrendern der Daten über 235 eigentlich bringt. Gut möglich, dass das Mitnehmen des Wertebereiches über 235 genau in der Art erfolgt, denn in Liquid ergibt das Anklicken der Rec. 709-Option tatsächlich einen komplett neuen Rendervorgang, dessen Wirkung aber nicht sichtbar wird, jedenfalls nicht mit meinen bisher getesteten Möglichkeiten.
Wie das in dem Fall gehandelt wird ist auch klar ersichtlich, siehe zweites Bild von oben mit der plötzlich wagrecht verlaufenden und auf 100 veharrenden Luminanzkurve. Kannst du vergessen, dann sind die gekappten Daten nämlich wirklich zementiert.
Anderseits hilft aber auch nichts, wenn sie sowieso in keinem Fall sichtbar gemacht werden können, außer vielleicht direkt aus der Kamera über HDMI.
Man braucht das Kinderkarussel nur wieder ein wenig antauchen, dann gehts schon weiter :-))



Antwort von dienstag_01:

Dieser Punkt war längst abgehakt! Besser noch nicht, denn du hast ihn noch nicht verstanden.

WoWu spricht von einem Offset im Bild. Und das korrigiert man auf die von ihm beschriebene Art am besten.



Antwort von Reiner M:

Dieser Punkt war längst abgehakt! Besser noch nicht, denn du hast ihn noch nicht verstanden.

WoWu spricht von einem Offset im Bild. Und das korrigiert man auf die von ihm beschriebene Art am besten. Heißt das, du revidierst Deine Meinung? Zitat von gestern:
Bereich von 100 *runterholen* ist richtig. Nur nicht mit einem Tool, was dafür das Schwarz unten raus katapultiert. Danke, so sehe ich es auch.
@Reiner
Genau nur DAS würde ich auch machen! Man fasst ja auch nur die Höhen an und schiebt nicht komplett. Ja. Danke. ;)
Im Grunde braucht man keine komplexen Instrumente, um die Lichter versuchsweise mal runterzuholen, kein Luminanzkurven, keinen Waveformmonitor, etc.
Man sollte allerdings schon wissen, was bei einer simplen primären Farbkorrektur geschieht. @domain
Das was Du da beschreibst, ist genau die Handhabung und Vorgehensweise mit dem Effekt "Luminanzkurve" in Premiere Pro. Nur, dass damit nicht gleichzeitig Farben manipuliert werden können.
Von daher gehst Du identisch vor. Nur mit einem anderen Tool.

Nur noch als Hinweis: die Absenkung der Lichter so vorzunehmen, dass die Luminanzkurve weiterhin linear verläuft ist gut. Es kann aber aus verschiedenen Gründen sinnvoll sein, gleichzeitig am anderen Ende nachzubessern. Hängt vom Bild ab. Insofern ist Linear kein zwingendes Ergebnis der Tat, aber im ersten Teilschritt das richtige. Abgehakt.

Beste Grüße,
Reiner



Antwort von olja:

Davon abgesehen stimmt die Aussage mit den 5 Blenden nicht..._Nur mal so zwischendurch ;-) Sondern? Es geht um 100% Standard, ohne "Superwhites" und Gamma-Specials.
Kann sein, dass ich mich im genauen Wert täusche. Fakt ist, auch Sensoren, die mehr können, werden Dank Rec.709 nicht mehr bieten. Sie werden alle "gleichgeschaltet", wie die Anzeigegeräte auch. Theoretisch. Wenn sie praktisch Unterschiede zeigen, weichen sie von 100% Standard ab, wo auch immer. Oder?
Was nicht heißt, dass sie ihm gar nicht folgen: Es passiert innerhalb der zulässigen Grenzen.


Beste Grüße,
Reiner Das hat doch Bubble hier schon geschrieben.
viewtopic.php?p=658002#658002 Also haben Cams, die 100% standardkonform nach REC.709 aufzeichnen, alle den selben Dynamik-Umfang. Oder? 5 Stopps? Das ließt sich so, als wenn diese Geräte nur 5 Blenden Umfang haben, oder ?



Antwort von WoWu:

@Olja

Schon der Standard sieht 9 Blenden in 8 Bit vor denn schon seit 1987 wird nicht mehr linear übertragen.
Das ist mittlerweile Grundwissen der Videotechnik.



Antwort von dienstag_01:

Heißt das, du revidierst Deine Meinung? Ganz im Gegenteil ;)
Ihr sprecht nur von zwei unterschiedlichen Szenarien. WoWu hat Material von dir, in dem er ein Offset ausmacht. Also korrigiert er es mit dem Verschieben des gesamten Wertebereichs.
Wenn dein Bild im Schwarz schon richtig sitzt, in der Helligkeit aber etwas über den 235 liegt, dann korrigiert man so wie du und domain beschrieben haben. Ganz einfach. Man darf es nur nicht vermischen. WoWus Weg ist einfach der nicht-destruktivere, aber nicht immer anwendbar.



Antwort von Reiner M:

Die Tatsache, dass Du eine einzelne Landschaftsaufnahme besitzt, in der keine Werte unterhalb 400mV, also schönes, dunkles, durchgezeichnetes Schwarz vorkommen, ist ZUFALL. ;)
Ich habe viele Aufnahmen, die enthalten nur Mid-Tones. Mit denen geht das auch. Das Material hast Du mir als "kritisches" Material geschickt.
Und nun sagst Du, nee, nee, das ist ganz tolles Material.
Was soll ich nun von deinen zwei Aussagen glauben ? Wolfgang, ich habe Dir den Clip wegen "oben" geschickt.

Ich habe es jetzt mehrfach geschrieben, tue es (sehr ungern) noch mal (weil Du es nur weiter oben nachlesen musst):

Das Signal sitzt korrekt auf. Es startet bei 0mV (300mv in Premiere Pro).
Der unumstößliche Beweis (ich bat dich schon mal darum, und tue es wieder:) BITTE! Schau Dir in Ruhe die verschiedenen Bilder der Waveforms an, die hier im Thread aufgelaufen sind...
Die muss ich Dir bestimmt nicht noch mal posten ... ;)

Beste Grüße,
Reiner



Antwort von dienstag_01:

Schon der Standard sieht 9 Blenden in 8 Bit vor.
Das ist mittlerweile Grundwissen der Videotechnik. Mit Hilfe welcher technischen Mittel schafft man das eigentlich, die 9 Blenden auf *zu wenig* Helligkeitsstufen zu verteilen, damit nicht schon in der Originalaufnahme Banding entsteht?



Antwort von olja:

@Olja

Schon der Standard sieht 9 Blenden in 8 Bit vor denn schon seit 1987 wird nicht mehr linear übertragen.
Das ist mittlerweile Grundwissen der Videotechnik. eben..deshalb hab ich das ja angemerkt, manche eben ne bissel drunter.



Antwort von WoWu:

Ja Reiner, dann hast Du ein xvYCC Signal und vergessen, die Kamera umzuschalten.

Was Du hier behauptest ist, dass die meisten Kameras nicht standardkonform verhalten.

Dann aber hätten alle Videobetreiber der Welt geklippte Bilder.

Wenn Du eine Kamera hast, die Videosignale (keine Spikes) in erheblichem Mass oberhalb von 235 ablegt (und sich nicht im xvYCC Modus befindet) ist sie schlicht und ergreifend defekt oder "verkurbelt".
Lass sie reparieren.

Aber wenn Du sagst, Dich interessiert sowieso kein Banding oder Dither, dann wundert es mich, dass das Clippen Dich stört.
Denn dann ist Dein Qualitätsanspruch ohnehin nicht zu diskutieren.



Antwort von Reiner M:

Heißt das, du revidierst Deine Meinung? Ganz im Gegenteil ;)
Ihr sprecht nur von zwei unterschiedlichen Szenarien. WoWu hat Material von dir, in dem er ein Offset ausmacht. Also korrigiert er es mit dem Verschieben des gesamten Wertebereichs.
Wenn dein Bild im Schwarz schon richtig sitzt, in der Helligkeit aber etwas über den 235 liegt, dann korrigiert man so wie du und domain beschrieben haben. Ganz einfach. Man darf es nur nicht vermischen. WoWus Weg ist einfach der nicht-destruktivere, aber nicht immer anwendbar. Danke, Dienstag.

Auch das hatte ich geschrieben. Wie alle anderen Tools, die diekt auf Luma wirken, funktioniert ProcAmp natürlich auch. Aber nur in besonderen Fällen sinnvoll. Diese Vorgehensweise ist keine generelle Lösung. Man sollte sie auch nicht so hinstellen.

@Wolfgang,
Wenn Du aus dem zufällig vorliegenden Clip eine generalisierte Lösung ableitest, irrst Du. ProcAmp gehört für dieses "Problem" durchaus zu den empfehlenswerten Tools, - man muss nur wissen, was man wann einsetzt.

Dann dreh ichs eben sorum, wenns Dir mehr zusagt: Immer dann, wenn ProcAmp unten rausschieben würde: Finger weg! (Und das wird in den meisten Fällen so sein) - Luminanzkurve ist angesagt (oder ein anderes Tool, das so arbeitet, ohne größeren Schaden anzurichten - wie domains Drei-Wege-Korrektur).

Beste Grüße,
Reiner



Antwort von WoWu:

Schon der Standard sieht 9 Blenden in 8 Bit vor.
Das ist mittlerweile Grundwissen der Videotechnik. Mit Hilfe welcher technischen Mittel schafft man das eigentlich, die 9 Blenden auf *zu wenig* Helligkeitsstufen zu verteilen, damit nicht schon in der Originalaufnahme Banding entsteht? Die 9 Blenden entstehen aufgrund des vorgeschriebenen Gamaverlaufs.
Da muss man nur dafür sorgen, dass anständig belichtet ist, dann ist das ganz normal.



Antwort von WoWu:

@Reiner

Nochmal: Wenn die Kamera 700mV generiert und oben im NLE Clipper, dann kann eine Proc Amp unten das Signal gar nicht herausschieben.

Du gehst immer von einer defekten Kamera aus.

Und komm bitte jetzt nicht wieder mit 109%.
Es gibt im Standard keine 109%. Full Well ist der oberste übertragene Wert.
Ref.White ist nur ein Bezugsweiss, ebenso, wie bestimmte Grauangaben, die zur Kurvenbeschreibung dienen.



Antwort von dienstag_01:

Die 9 Blenden entstehen aufgrund des vorgeschriebenen Gamaverlaufs. Das heisst, dass durch den Gammaverlauf etwas mehr als 1 Blende gewonen wird im Verhältnis zu einer linearen Übertragung?
Nochmal: Wenn die Kamera 700mV generiert und oben im NLE Clipper, dann kann eine Proc Amp unten das Signal gar nicht herausschieben. Haste eigentlich och wieder recht.

Edit: Der Regler wird immer wichtiger für mich ;)



Antwort von WoWu:

Das heisst, dass durch den Gammaverlauf etwas mehr als 1 Blende gewonen wird im Verhältnis zu einer linearen Übertragung? Nee, dabei machst Du jetzt den Denkfehler, es wieder auf 255 zu beziehen, es sind aber nur 220 Werte, also rd. 7 Blenden (bei 6db/Blende).
Dabei sind 2,5 Blenden zwischen 45% und 109% enthalten.
Streng genommen, kann man sogar 10 Blenden übertragen, aber der Standard sieht 55db Rauschen vor, also "nur" 9 Blenden.



Antwort von dienstag_01:

Naja, ich hatte schon mit 219 gerechnet. 7 Blenden wären ja nur 128. Deshalb etwas mehr als 1 Blende.



Antwort von Angry_C:

Ich lese hier immer Proc Amp? Welcher Effekt(Regler) ist das in Premiere Pro?



Antwort von Reiner M:

@Reiner

Nochmal: Wenn die Kamera 700mV generiert und oben im NLE Clipper, dann kann eine Proc Amp unten das Signal gar nicht herausschieben. Aha.
Dann probiere mal ProcAmp in Premiere Pro mit einem gut gefüllten Clip, bei dem das Signal unten aufsitzt. Schön wäre natürlich, wenn er oben auch noch drüber läuft, so wie viele Clips, die hier präsentiert wurden.
Du gehst immer von einer defekten Kamera aus. Klar. ;)
Du tust so, als hätte es den größten Teil der Diskussion hier und die Vorstellung der vielen Erfahrungsberichte gar nicht gegeben.
Soll ich Dir die "defekten" Cams noch mal aufzählen, die hier genannt wurden?
Ich bin für jede andere praxistaugliche, nützliche Lösung offen. Für Hinweise, dass ich, meine Cam, mein NLE und deren Hersteller alles falsch machen, nicht.
Sie nützen mir nichts. :-)))

Beste Grüße,
Reiner

Edit: Inzwischen könnten wir die Diskussion einfach beliebig verlängern , in dem wir nur noch vom oben zitieren .... - Ist wohl alles gesagt, keine neuen Erkenntnisse, meine ich. ;)



Antwort von Reiner M:

Ich lese hier immer Proc Amp? Welcher Effekt(Regler) ist das in Premiere Pro? In der deutschen Umgebung heißt er "StabVerst".

Beste Grüße,
Reiner



Antwort von Angry_C:

Ich lese hier immer Proc Amp? Welcher Effekt(Regler) ist das in Premiere Pro? In der deutschen Umgebung heißt er "StabVerst".

Beste Grüße,
Reiner Danke:-)



Antwort von WoWu:

Dann probiere mal ProcAmp in Premiere Pro mit einem gut gefüllten Clip, bei dem das Signal unten aufsitzt. Schön wäre natürlich, wenn er oben auch noch drüber läuft, so wie viele Clips, die hier präsentiert wurden. Reiner, Du wirst jetzt lustig denn nun sagst Du, ein Videosignal hat mehr als 700mV, auch wenn die Kamera nicht defekt ist. (Von den Spikes mal ganz abgesehen, das hatten wir ja geklärt)

Aber dass ein korrektes Videosignal mehr als 700 mV haben soll (und gut gefüllt vom Boden bis zum Überlauf, das hat eine neue Qualität.

(Übrigens hatte ich Dich gebeten, doch -diesbezüglich- einmal die Liste der Camcorder aufzuführen, die, vom Hersteller beabsichtigt, vom Standard abweichen.
Das müsste ja in den technischen Werten der Camcorder nachvollziehbar sein). -Liste fehlt-

Ich glaube wirklich langsam, Du blickst durch die Videotechnik nur sehr oberflächlich durch und es fehlt in der Tat an Hintergrundwissen.
Eben praxisnah, wenn es Dir reicht, an irgendeinem Knopf zu drehen und das Signal irgendwie hinzubiegen. -Klar, so geht das auch, wenn man keinen besonderen Anspruch an die Qualität des Videosignals hat.

Aber, lass es gut sein. Mach Dir dein eigenes Videosignal, dass Deinem Monitor angepasst ist und Deinen Kunden gefällt ...
Glücklicherweise scheint es ja mittlerweile durchgedrungen zu sein, dass es ein Standardsignal gibt, das von 16-235 geht ..... oder auch nicht ?Dann probiere mal ProcAmp in Premiere Pro mit einem gut gefüllten Clip, bei dem das Signal unten aufsitzt. Schön wäre natürlich, wenn er oben auch noch drüber läuft, so wie viele Clips, die hier präsentiert wurden. Ich sehe gerade Deine Anmerkung:
Bei einem Clip, der unten aufsitzt und oben nicht "überläuft" setzt kein normaler Mensch einen ProcAmp ein, weil das Signal so in Ordnung ist.

Was also wolltest Du (genau) damit sagen ?



Antwort von olja:

Glücklicherweise scheint es ja mittlerweile durchgedrungen zu sein, dass es ein Standardsignal gibt, das von 16-235 geht ..... Jo, lang und breit erklärt. Davon abgesehen halte ich die Wahl von Log Aufzeichnung für angebrachter, wenn man noch im 8 Bit Bereich irgendwas optimieren will. Allerdings ist das eben nichts für Leute, die ihr Videomaterial gleich über die Glotze gucken, bzw. sich weigern, nochmal im NLE Hand anzulegen.

Wie stelle ich es mit Hausmitteln(Waveform..usw.) sicher fest, ob das Signal über 700mV geht, bzw den 16-235er verläßt (ohne jetzt irgendwelche Peaks deuten zu müssen) ?



Antwort von gast5:

Irgendwie olja verstehe ich die Frage nicht.. Über die x Seiten dieses Freds ging es doch nur um eben dieses Thema, Beurteilung, Darstellung , Fehlinterpretation und Verlässlichkeit der Programme beim Umgang mit eben diesem Material..?????

Ihr habt die Bereiche für Pal und NTSC abgesteckt ebenso für HD und du weist in welchem Bereich in Abhängigkeit des Projektes die Werte ausschlagen dürfen..

Selbst wenn eine verwendete Cam bei korrekter Einstellung über diese Bereiche ausschlägt können wir es nur korrigieren in den vorgesehenen Bereichen.. Mit den Mitteln die die Anwendung zu Verfügung stellen..

Was aber tun wenn eine NLE wie prox5 bspw. keinen waveformmonitor und Vektorscope bereitstellt ? Mit dem colorpicker jedes Pixel kontrollieren? Wohl eher nicht..

Die Log Geschichte in davinci.. Die Steuerung zur Behandlung via LUT Log zu 709 ist in den clipsettings zu manipulieren..



Antwort von olja:

Irgendwie olja verstehe ich die Frage nicht.. Über die x Seiten dieses Freds ging es doch nur um eben dieses Thema, Beurteilung, Darstellung , Fehlinterpretation und Verlässlichkeit der Programme beim Umgang mit eben diesem Material..????? Teilweise. Jetzt geht es darum, welche Cam solches Material erzeugt. Und daran wird eben gezweifelt. Die Theorien gehen von Kamera kaputt bis zu doof, bzw sind es eh nur Überschwinger.

Deshalb ja die Frage, wie kann ich sicher sein, das das, was ich über 700mV erkenne zu dem verwertbaren Videosignal gehört.



Antwort von olja:

Auch egal, los gehts. Das geclippte Zewatuch zeigt meiner Meinung nach Anschlag im Waveform und setzt auch auf. Auch die Pipette zeigt 255,255,255. Die waagerechte Line deutet auch nicht auf einen Peak hin. XV. Color ist eingeschaltet.

Frage ist, ob das die hier Beteiligten hier auch so sehen ?



Antwort von WoWu:

Da ist aber irgendwas gestreckt in Deinem Signal.



Antwort von olja:

Out of Cam, Automatikmodus on. Ich guck mehr auf die Höhen im Moment und auf das, was ab -3db wieder möglich ist, wenn man diesen "komischen" Bereich verläßt.

Zeichnung der Poren im Zewatuch bekomme ich jetzt erstmal nicht. Da kann man kurbeln, was man will ;-), sobald das Signal auf 255 aufläuft und eine Linie bildet, ist Ende. Gecrushte Höhen, wie so oft zu sehen.

Übrigens ist durch Zufall ein schönes Beispiel enstanden. Die Poren in dem Zewatuch sind wichtig ;-) Es geht weiter...



Antwort von WoWu:

-kryptisch-



Antwort von olja:

Kryptisch , was ? Ein Bild ooc mit dem Waveform dazu ? Kann man doch erstmal so zu Kenntnis nehmen.

@Reiner, das meine ich, du weißt nie, wann das Signal aufschlägt. Da ist nichts mehr zu retten. Optische Kontrolle in den Bereichen ist auch Fehlanzeige.

Jetzt das Ganze nochmal -6db (hab während des Filmes runterschaltet)



Antwort von olja:

Ab da gehts weiter. Zeichnung (fast) im Zewatuch und man kann auch noch ein wenig aus der Kohle holen.



Antwort von olja:

Und das Schönste an der Sache ist, wenn man XV. color abschaltet, ändert sich...NICHTS! ebenfalls drüber (Unterschiede sieht man aber im Vectorscope)
Genau so wird es bei den Panas sein.



Antwort von WoWu:

@Olja

Das Thema haben wir doch schon in diesem Thread abgehandelt.
Solche "Quervermutungen" sind der Grund weshalb bisher im Netz nichts vernünftiges entstanden ist und solche Sachen wie "Superweiss" und Superschwarz durch die Köpfe schwirren.

Du kannst es nachlesen: Die xvYCC Umschaltung und der Effekt sind von Angry_C verifiziert worden.
Das kannst Du mit Deiner Kamera auch machen, wenn Du einen Fernseher mit HDMI hast.
Probiers doch zunächst mal aus, bevor Du sagst ... so wird das auch bei den andern Kameras sein.
Stell doch erst einmal sicher ... dass die Signalisierung da ist und auch korrekt gelesen wird und ob die Signale unterschiedlich aufgezeichnet werde.

Danach weisst Du, wo Du den weiteren Fehler zu suchen hast.



Antwort von Reiner M:

@Reiner, das meine ich, du weißt nie, wann das Signal aufschlägt. Da ist nichts mehr zu retten. Optische Kontrolle in den Bereichen ist auch Fehlanzeige. Olja, natürlich ist irgendwann Ende Gelände. Aber der Spielraum ist da, wie Du siehst.

Hier mal ein Beispiel aus der X909. Ich habe einen Clip gewählt der oben, ganz oben, clippt und eine Linie bildet, um jede Fehlinterpretation zu vermeiden:

Bild 1 zeigt den Clip unbehandelt. Der grüne senkrechte Strich rechts außen am Waveform-Monitor zeigt übrigens den maximal genutzten Bereich in diesem Frame an. Wie man sieht: Sitzt auf 300mV und läuft deutlich über 1V. (Im Premiere Pro Monitor befindet sich der bildgebende Bereich von 700mV in der Skala zwischen 0.3 V und 1.0V.)

Bild 2 zeigt die Korrektur mit ProcAmp, Helligkeit -7.5%.
a) das Signal läuft unter 300mV raus und damit aus dem Bild.
b) das Signal liegt immer noch über 1V und damit außerhalb des Bildes. Die Korrektur reicht nicht.

Bild 3 zeigt eine Korrektur um -9%.

Wenns gefällt ... - Ist effektiv der gleiche Lösungsansatz wie ich ihn beschrieben habe (was oberhalb 1V liegt nach unten drücken), nur leiden hier die Tiefen. Ich würde vermutlich leichtes Banding in Kauf nehmen, um die Tiefen zu retten. Müsste man abwägen.
Aber jeder, wie er will. Viele machen ja gar nichts. Die sehen dann aber auch nicht, dass der Himmel zwischen Wolken blau zeigt.

So. Genügt irgendwie. ;)

Beste Grüße,
Reiner



Antwort von TheBubble:

Hier mal ein Beispiel aus der X909. Ich habe einen Clip gewählt der oben, ganz oben, clippt und eine Linie bildet, um jede Fehlinterpretation zu vermeiden: Ich hab's leider bisher noch nicht geschafft Test-Clips mit dieser Kamera zu erstellen, die für die hier disktuierten Probleme besonders geeignet erscheinen.

Ich könnte ein paar Statistiken zu Deinem Frame liefern, wenn Du den ursprünglichen Clip von der Kamera hochladen könntest, oder besser ein einzelnes RAW-Frame unbehandelt, möglichst so wie es aus dem dem H.264 Decoder kommt, im YUV-4:2:0-RAW-Format exportieren würdest (z.B. mit libav oder ffmpeg). Dann kann ich mehr zu dem Clip und den Korrekturvarianten sagen.



Antwort von WoWu:

Reiner, da hast Du uns jetzt ein Bild geboten, das von der kamera schon geclippt ist. Da hilf auch kein Procamp mehr.
(Siehe Dein Original, in dem Deine Kamera bei richtiger Belichtung auch noch Zeichnung über 1V aufzeigt. (Anhang)

Gib doch mal das identische Bild, nach Deiner "Gewinnmethode", die dann anschliessend auch die Zeichnung dort noch zeigt, wo jetzt ein harter Clip vorliegt. Dann müssten wir mit Deiner Methode ja wieder den blauen Himmel sehen können.
Komisch ist auch, dass die Fläche gar nicht türkis geworden ist, denn der Kameraclip wirkt parallel auf alle drei Farben, vohingegen der NLE Clip erst auf Blau wirkt.

Also, zeig doch mal, dass das kein Taschenspielertrick war.

Und zeig doch einfach mal, was der Tonwertumfang in der Farbkorrektur für Werte anzeigt.
(Mein Tipp: 0-255)



Antwort von gast5:

ich bin Heute mal dazugekommen den BellNuit in Piranha 7 zu betrachten..
interessant ist das sich bei Piranha die PAL NTSC Geschichte im Gegensatz zu FCPX und Davinci sehr wohl auswirkt..



Antwort von domain:

Zitat:
„Denn was domain nicht gemacht hat, ist, Schwarz unten raus zu zu schieben - sehr sinnvoll. Er hat nur die Neigung der linear verlaufenden Lumakurve reduziert. Solange, bis 109% auf 100% liegt, aber 0% bei 0% stehen bleibt. Oder?

Doch leider: Dadurch entsteht Banding. Ob das kritisch ist, hängt vom Bild und dem persönlichen Empfinden ab. „


Banding entsteht dadurch noch lange nicht, nur eine gröbere Quantisierung, so wie beim Importieren des BelleNuit-Charts, das gleich mal auf 16-235 gebracht wird. Erst beim nachträglichen Aufblasen auf die ursprünglichen 0-255, also beim Export könnte ohne interpolierendes Dithern Banding entstehen, aber davon ist dieser Vorgang ja meilenweit entfernt.

Mir erscheint immer mehr die Arbeitsweise von Avid, bzw. jene von WoWus NLE als die einzig richtige. Unabhängig von der erfassten Eingangsdynamik einer Kamera (Anzahl der Stops) und von der Anzahl der Bits bei der Codierung (8,10, 12 oder 14) sollte die Waveform und natürlich auch das Waveform-Kontrollbild in Abhängigkeit vom maximal darstellbaren Monitorkontrast immer den gesamten überhaupt existierenden Wertebereich anzeigen, also zunächst mal ohne jede Berücksichtigung von 709 und zwar auch im kleinen Timeline-Vorschaubild auf dem Hauptmonitor.
Nur durch diese Darstellungsart ist nämlich auf den ersten Blick zu erkennen, was aus einem erweiterten Aufzeichnungsmodus unter der 709-Spezifikation überhaupt herauszuholen wäre und wie stark zu kurbeln ist.
(WoWu macht ja einen großen Unterschied zwischen apriori verkurbelt sein und nachträglich zulässigem Kurbeln :-)
Unabdingbar muss es dann aber ein zweiter Monitor zur Vorschau geben, der perfekt das eingeengte 709-Spektrum simuliert.
Scheint aber bei den meisten NLE nicht der Fall zu sein, sie zeigen schon im Waveform-Kontrollbild die 709-Limitierungen.



Antwort von Reiner M:

Gib doch mal das identische Bild, nach Deiner "Gewinnmethode", die dann anschliessend auch die Zeichnung dort noch zeigt, wo jetzt ein harter Clip vorliegt. Dann müssten wir mit Deiner Methode ja wieder den blauen Himmel sehen können.
Komisch ist auch, dass die Fläche gar nicht türkis geworden ist, denn der Kameraclip wirkt parallel auf alle drei Farben, vohingegen der NLE Clip erst auf Blau wirkt.

Also, zeig doch mal, dass das kein Taschenspielertrick war. Wolfgang, Wolfgang ...

Taschenspielertricks?

Ich habe nirgends behauptet, dass ich aus dieser geclippten Linie, einem sigulären Byte-Wert, ein komplexes Bild basteln könnte. ???

Sag mal ... wieso sollte ich das überhaupt nur probieren? :-)))

Welcher Motivation entspringen eigentlich solch bemerkenswerte Verdrehungen und Spitzen?
Es kommt wohl immer irgendwann der Punkt, da bekommen "Argumente" eine andere Qualität. In meinen Augen ist das eine Frage des Stils. Traurig.

Du hast nach 15 Seiten Thread weder Erklärungen, noch Antworten. Bis auf ProcAmp, wobei Du aber nachgewiesener Maßen eine falsche Voraussetzung annimmst. 7.5IRE-Offset. Und jetzt fangen wir wieder von vorne an, als wäre zwischenzeitlich nichts passiert ...

Das wäre ja alles nicht schlimm, deswegen diskutieren wir. Aber wenn schon, dann bitte a) sachlich, b) ohne Fakten zu ignorieren, die längst abgehakt waren, und c) ohne den Versuch, Beweise mit unsachlichen Behauptungen zu entkräften.

Wie x-fach geschrieben: Bin offen für das, was uns weiterbringt! ;)

Beste Grüße,
Reiner



Antwort von Reiner M:

Reiner, da hast Du uns jetzt ein Bild geboten, das von der kamera schon geclippt ist. Da hilf auch kein Procamp mehr.
(Siehe Dein Original, in dem Deine Kamera bei richtiger Belichtung auch noch Zeichnung über 1V aufzeigt. (Anhang) Für mich quasi als Schluss des Ganzen - etwas länger, was der Länge des Threads aber gerecht wird:

Halten wir ganz einfach die unumstößlichen Fakten fest.
Die sind nicht wegzudiskutieren, Wolfgang. ;)

a) ProcAmp in Premiere Pro schiebt unten raus. - Fakt. Haken dran.
b) Ein 7.5 IRE Offset liegt nicht vor. - Fakt. Haken dran.
c) Es geht in der ganzen Diskussion ausschließlich um das, was einmal mehr in diesem Beispiel gezeigt wird: Es gibt Signale oberhalb 1V (700mV), die bildgebende Wirkung haben, WENN man sie nach unten zieht. - Fakt. Haken dran.
d) Dieser Bereich beträgt ca +9%. - Fakt. Haken dran.

Das kann nun wirklich jeder selbst AUSPROBIEREN.
Wie es in anderen NLEs wirkt, beschreiben dann deren Besitzer bzw. haben sie schon beschrieben.

Dein Argument für ProcAmp ist ja gerade, dass er das gesamte Signal nach unten schiebt. Nur leider liegt eben kein Offset vor, was den ProcAmp in diesen Fällen effektiv zum Datenkiller macht und er Bildinhalte zerstört. Ist nun klar bewiesen.

Dass dieser Frame oben clippt, ist eben so. Ich habe ihn ja genau DESHALB sehr bewußt als Beispiel hier gewählt, damit die Welle eine scharfe Kante bildet und die Lage im Monitor haargenau ausgemacht werden kann. Ideal, um zu zeigen, wie groß der Bereich ist, und ob es 7.5IRE sind. Er hat seinen Zweck erfüllt.

Diese geclippte dünne Linie zeigt nun eindeutig auf hervorragende Weise den Bereich, der bei JEDER Aufnahme von dieser Cam genutzt wird. IMMER! Ist so.

Ob er dann tatsächlich mit Werten gefüllt wird und Signalanteile im Waverform-Monitor zeigt, ist motiv-/belichtungsabhängig.
Der Bereich ist aber als solcher vorhanden und kann von dieser Cam (andere machen das ebenso) mit Werten gefüllt werden. IMMER verfügbar. Oft ist da dann was drin, oft auch nicht.

----------
Zum alten Clip:

Dass der Clip, den ich Dir geschickt hatte, nur wenige Signale oberhalb 1.0V zeigt, dort nicht clippt, und motivbedingt keine ausgeprägten Tiefen besitzt, ist eben so. Dieser Clip ist nun kein Beweis, dass da technisch ein anderer Hintergrund vorläge. Auch wenn Du das gerne so hättest. Wieso sollte das denn gegeben sein? Erklär mal. Wenn ich die Blende anders einstelle, funktioniert die komplette Speicherung der Video-Daten anders? Oder ProcAmp behandelt das Signal anders?

Dieser Beispiel-Clip war ganz bewußt so gewählt, um zu demonstrieren, wie Türkis zu Blau wird. Denn darum ging es. Das geht mit dem neuen Beispiel nicht. Bei ihm gehts um die Demonstration von anderen Dingen. Und nun?

----------

Das Thema, um das es hier geht - ist nur das: Es gibt bewiesener Maßen Signale oberhalb 1V (700mV), die bildgebende Wirkung haben. Punkt. Ist nicht wegzudiskutieren.
Unklar bleibt im Hin und Her der Diskussion: warum?

Jedenfalls ist für die Praxis von Bedeutung: Wenn ich sie nach unten ziehe, passiert OPTISCH (im bildgebenden Bereich also, und damit für den, der Videos bearbeitet, sehr wichtig!):
- ggf. nichts auffälliges (was völlig okay wäre),
- oder Lichter bekommen Zeichnung,
- oder Lichter bekommen Farben,
- oder wie im konkreten Fall der X909 kann Türkis zu Blau werden.

Das ist ABHÄNGIG von der Aufnahme, wie Lichter und Farben verteilt sind und hat nichts mit "Taschenspielertricks" zu tun. Das heißt nicht, dass jeder Himmel blau wird und jede Ausbrennung aufgelöst.
Für jede dieser Wirkungen, auch in Kombinationen, lassen sich beliebig Beispiele zeigen.

Aber wozu? Brauchst DU die wirklich? Erstens kannt Du das selbst ausprobieren, zweitens:

Im Waveform-Monitor zeigen sie ALLE das selbe: Daten oberhalb 1.0V. Sie basieren auf den selben technischen Gegebenheiten. Die Korrektur ist immer die selbe, wenn nötig: Ein Tool, das ggf. vorhandene Signalanteile oberhalb 1.0V in den bildgebenden Bereich zieht. Ob es Luminanzkurve, ProcAmp, Drei-Wege-Korrektur oder sonstwie heißt - völlig egal.
Das Korrekturergebnis ist abhängig vom Bild und vom tatsächlich eingesetzten Werkzeug (siehe beispielsweise Banding oder Verlust der Tiefen oder Verfügbarkeit der Luma/Farbwerte usw.).

Ich kann umgekehrt aus der selben Cam tausende Frames zeigen, bei denen GAR KEINE Signale oberhalb 1.0V sichtbar sind.
Und? Wären die technisch anders zu interpretieren? Nein!
Nein, wären sie nicht! Auch dann existiert dieser Bereich oberhalb 1.0V, er ist nur nicht gefüllt. Punkt.
Ein Statistisker nennt das dann Zufall. Ein Kamermann womöglich Können.

Und das "Problem" - das ja in diesem Sinne gar keines ist, sondern ein Feature! - nun an geclippten Wolken oder fehlendem Türkis, das manchmal nach Blau gerettet werden kann und in diesem Fall nicht, festzumachen oder kleinzureden, ist in meinen Augen Nonsens.

Mir ist klar, dass Du den Beitrag so nicht stehen lassen KANNST. ;)
Eine nützliche Lösung, eine Idee, ein Ansatz wäre angenehm.

- Jedoch scheint mir umfassend und deutlich alles mehr als einmal diskutiert, belegt und bewiesen zu sein. Neues erwarte ich daher mit sehr hoher Wahrscheinlichkeit nicht, bin aber offen dafür. ;)
- Eine ganz klare Handlungsempfehlung liegt vor. Ist mehr als hinreichend für die Praxis.
- Jede weitere Diskussion mit vielen Wenns und Abers oder gar unsachlich geführt ohne neue Erkenntnisse und Lösungsansätze erübrigt sich für mich vollkommen.

Mitnehmen kann ich als FAZIT, dass es auch Deine Empfehlung ist, den Bereich nach unten zu drücken, mehrfach von Dir so gegeben. Insofern sind wir uns einig. Ob ich dann den von Dir präferierten ProcAmp oder die Luminanzkurve oder sonstwas wähle, werde ich fallweise entscheiden. ;)

Danke für die Aufmerksamkeit und die teilweise sehr fruchtbare Diskussion mit vielen neuen Erkenntnissen.

Beste Grüße,
Reiner



Antwort von olja:

@Motion, ich kann zwar das Flippen erkennen, aber nicht den Maximalwert (zu klein;-)). Was zeigt denn der belleNuit . Oberhalb von 235 ?

@Reiner, hast Du die Cam jetzt schonmal so eingestellt, das sie eher nicht in die Bereiche kommt und wie sich dann das Material bearbeiten läßt ? Ich staune, wieviel Standardszenen die Dinger eigentlich immer überbelichten. Wie gesagt, ich hab gestern auf -6 runterdrehen müssen, verliere aber keine Tiefen, bzw. hebe die lieber notfalls an. Siehe Beispiele.


Es ist doch eher eine Krux, was die Dinger da produzieren, bzw. wie sie versagen.
Was dann wirklich Schade ist, sind die permanent überbelichteten Sachen vom Rolf Hankel. Klassisches Beispiel. Er gibt sich wirklich Mühe mit seinen Filmchen und investiert Zeit, aber leider verläßt er sich offensichtlich zu sehr auf die Herstellersettings.
Dabei muß das gar nicht sein, die Canons kann man so einstellen, das das nicht passiert, bzw. mit Cinestyle oder manuell arbeiten. Geht alles, nur ist irgendwann bis auf die Zoomwippe der schnelle Camcordereffekt gegenüber der DSRL verpufft.


Jetzt würde mich nur noch interessieren, ob Domain seine aktuelle Cam auch über 235 liegt und in welchem Modus.

@Wowu, warum sollte ich einen Fehler suchen ? Ich hab keinen und meine Cam ist auch nicht kaputt, bzw. filme ich nicht, bis ich schon helle Stellen im Display sehe, die förmlich nach Clipping riechen. Ich verstehe sowieso nicht, warum die Displayanzeigen igoriert werden, auch wenn man keine Helferlein an Board für's Clipping hat.
Man sieht es doch mit bloßem Auge, das da was schiefgehen kann. Dazu muß das Display gar micht mal so dolle sein, wenn man die Cam kennt.

Das ist der Fehler bei dieser ganzen Geschichte hier, auch wenn manche zu geizig sind, weil sie meinen durch ausnutzen des "vollen Tonwertumfangs" bessere Bilder zu bekommen und an denen auch nichts mehr geändert werden darf, weil bei 800% Crop evtl. eine Störung im Schmetterling zu sehen ist. Präsentiert wird dann lieber geclipptes Zeugs, oder ausgerannte Blätter, Wiese..was weiß ich.

Außerdem kann ich HDMI am Fernseher eh nicht testen, weil ich seit 15 Jahren eh keinen mehr besitze. ;-)



Antwort von WoWu:

@domain


(WoWu macht ja einen großen Unterschied zwischen apriori verkurbelt sein und nachträglich zulässigem Kurbeln :-) Ja genau. Wnn man das Bild, so wie es von der Kamera kommt erst einmal korrekt im NLE sieht (und im zugelassenen Wertebereich), dann kann man anschliessend sehr bewusst entscheiden, welche Korrekturen dann gewünscht sind.
Nehme ich hingegen ein "geclipptes" Bild, und beginne von vorn herein, es zu stauchen, um überhaupt in den Wertebereich zu kommen, nenne ich das "verkurbeln", weil weil ich dann von Anfang an mit einem Bild beginne, wie die Kamera es nie geliefert hat.

"Verkurbeln" klingt vielleicht etwas ungeschickt, trifft die Sache aber ziemlich genau.



Antwort von domain:

Jetzt würde mich nur noch interessieren, ob Domain seine aktuelle Cam auch über 235 liegt und in welchem Modus. Na klar kann die XF100 das jederzeit, wenn Bedienungs- bzw. Belichtungsfehler vorliegen. Habe ich schon auf Seite 2 gezeigt, wo ich vom dunklen Wasser in Rügen einen Reißschwenk in den Himmel machte, um die noch nicht sichtbaren Möven zu erwischen, die im freien Flug futtern können, wenn man ihnen Brot zuwirft, aber die Belichtungsautomatik mit der rasanten Lichtveränderung zunächst überfordert war..
Diese zwei Bilder zeigen eben genau die Möglichkeiten z.B. einer noch realisierbaren Himmelsfarbenveränderung in Richtung Blau an, wobei dieses (im zweiten Bild) bereits im Waveformmonitor genau in der Art vorherzusehen war. Ich wusste also schon, dass es in Punkto Himmelsfarbe und Wolkendurchzeichnung zu retten war, nur halt mit ein wenig "Kurbeln" ohne jede Farbmanipulation.
Dieses vorhersehende Abschätzen ist aber nicht möglich, wenn bereits das Waveform-Kontrollbild in 709 gehalten ist.
Daher alle Punkte an AVID etc.






Antwort von Reiner M:

@Reiner, hast Du die Cam jetzt schonmal so eingestellt, das sie eher nicht in die Bereiche kommt und wie sich dann das Material bearbeiten läßt ? Ich staune, wieviel Standardszenen die Dinger eigentlich immer überbelichten. Wie gesagt, ich hab gestern auf -6 runterdrehen müssen, verliere aber keine Tiefen, bzw. hebe die lieber notfalls an. Siehe Beispiele. Selbstverständlich, Olja.
Mit einer manuellen, auf das Motiv ausgelegten Belichtung kann man dem entgegenwirken. Deine Beispiele zeigen sehr gut, welche Variationsmöglichkeiten zur Verfügung stehen. Besten Dank dafür.

Überbelichtungen oder "Türkisstich" kommen sehr selten vor - ich muss geeignete Beispielclips immer recht lange suchen. ;)
Aber es gibt sie.

Wichtig an unsere Diskussion war mir auch das Ergebnis: Es ist kein Merkmal allein der Panas (in meiner alten Pana SD PAL DV finde ich die gleichen "Überschwinger"). Es ist kein Merkmal allein des Premiere Pro usw.

Dafür Danke an alle, die da mirtgewirkt haben!

Es gibt sicher User die freuen sich, wenn nun weiße Henden ihrer Interviewpartner plötzlich Struktur bekommen, weils mit der Aufnahme nicht ganz so geklappt hat, wie vorgesehen?. - Ggf.
Und es gibt definitiv User, die ägern sich, dass Ihre X909 am PC "alles türkis" oder so "flau" zeigt. Dieses Forum hier enthält zahlreiche Beiträge zu diesem Thema von angesäuert bis heftig verärgert. Wie sie vorbeugen können (richtig belichten), wissen sie nun. Wie sie ggf. bereits "verdorbene" Aufnahmen noch retten können, auch.

Insofern betrachte ich persönlich dieses Feature als Bonus. Als Möglichkeit, einen vorhanden Zustand, der nun mal so ist, wie er ist, ggf. zu verbessern. Warum sollte ich das nicht tun?

Unabhängig davon ändert das nichts an der technischen Gegegebenheit: Auch wenn der Bereich oberhalb 100% nicht mit Daten vollgeschrieben wurde, ist er da. Die Kamera arbeit deshalb nicht in einem anderen Modus. Technisch betrachtet. Oder doch? Wenn also die Diskussion technisch geführt wird, ist das immer zu berücksichtigen.

Die korrekte Belichtung befreit mich auch nicht davon, manuell einzugreifen. Wenn nicht technisch erforderlich, dann doch wenigstens geschmacklich. Der Geschmack des "Profilers" beim Hersteller ist doch längst nicht meiner.

Das Ziel ist ja nicht (jedenfalls für mich) ein Bild zu konservieren, das nun über Jahre dokumentiert, wie toll oder mies die Kamera einst war.
Es geht sehr praktisch darum, ein Bild zu gewinnen, das auf dem gewünschten Zielmedium die Bildaussage optimal unterstreicht.

Die Aufnahme ist ein Rohdiamant. Wer verschenkt schon Rohdiamanten?

Insofern ist eine Anpassung der Lumawerte keine wirklich zusätzliche Arbeit - auch Du hebst dann die zu dunkel geratenen Stellen etwas an. Und warum? - Weils was bringt! ;) - In Deinen Augen. Und dann hoffentlich auch in den Augen Deiner Zuschauer. Das ist der Sinn. Nichts anderes.

Beste Grüße,
Reiner



Antwort von olja:

So gesehen ist die Zusammenfassung richtig und deckt sich wohl mit meiner Meinung. Für den ernsthaften Filmer, der sein Material auch mal im NLE anfasst, würde ich mir im Semi-Pro-Preissegment aber trotzdem die Wahl der Logaufzeichnung wünschen. Das ist wirklich ein AHA-Effekt und man geht da den ungekehrten Weg.

Und vor allem, war hier die sagenumworbene Pana im Spiel, mit der gerne der "volle Tonwertumfang" ohne Rücksicht auf Verluste geschwafelt wird. Wie blöd die Sache eigentlich ist, sowas bewußt auszunutzen dürfte jetzt auch klar sein.

So, und nun warte ich auf BlackMagic ;-) Mal gucken, wie das Zewatuch neben der Kohle da so aussieht...



Antwort von domain:

Und vor allem, war hier die sagenumworbene Pana im Spiel, mit der gerne der "volle Tonwertumfang" ohne Rücksicht auf Verluste geschwafelt wird. Wie blöd die Sache eigentlich ist, sowas bewußt auszunutzen dürfte jetzt auch klar sein. Verstehe kein Wort deiner Aussage :-)
Könntest du das etwas näher erläutern?



Antwort von olja:

Und vor allem, war hier die sagenumworbene Pana im Spiel, mit der gerne der "volle Tonwertumfang" ohne Rücksicht auf Verluste geschwafelt wird. Wie blöd die Sache eigentlich ist, sowas bewußt auszunutzen dürfte jetzt auch klar sein. Verstehe kein Wort deiner Aussage :-)
Könntest du das etwas näher erläutern? Ja, konkret sind es die Tieffliegerbilder, der gerne mit "vollem Tonwertumfang" (so nennt es es) wirbt und sogar noch den Sinn von flachen Profilen in Frage stellt (hier im Thread). Wer nicht runterregelt, weil man dann evtl. ja was verschenken könnte..Naja, präsentiert eben geclippe Bilder. Das meine ich mit bewußt den Bereich ausnutzen, anstatt die Cam erstmal in den richtigen Bereich zu bringen. Aber es könnten ja ein paar Farben verloren gehen. WO die eigentlich liegen scheint ja auch egal zu sein. ;-) Ausgefressene Stellen werden dann einfach als stimmungvolle Spitzlichter deklariert. So einfach ist das....;-)